Network Working Group K. Carlberg
Request for Comments: 4190 G11
Category: Informational I. Brown
UCL
C. Beard
UMKC
November 2005
Framework for Supporting
Emergency Telecommunications Service (ETS) in IP Telephony
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.
この文書では、IPテレフォニーのコンテキスト内で許可、緊急関連の通信をサポートするためのフレームワークを提示します。私たちは、緊急通信サービス（ETS）に沿って、今日のIPアーキテクチャとサービスモデル内で実現されなければならない、どのように許可された緊急サービスの一般的な見解を反映する目的のシリーズを発表します。これらの目的から、我々は既存のIETFプロトコルに関する勧告のより具体的なセットを提供プロトコルと機能の対応するセットを提示します。最後に、私たちは、この文書に記載された目的や機能のためのモデルを導くとしての役割を果たす2つのシナリオを提示します。公衆交換電話網（PSTN）に存在するサービスの一例と相まってこれらのモデルは、制約された解空間に貢献しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Emergency Related Data .....................................4
1.1.1. Government Emergency Telecommunications
Service (GETS) ......................................4
1.1.2. International Emergency Preparedness Scheme (IEPS) ..5
1.2. Scope of This Document .....................................5
2. Objective .......................................................7
3. Considerations ..................................................7
4. Protocols and Capabilities ......................................7
4.1. Signaling and State Information ............................8
4.1.1. SIP .................................................8
4.1.2. Diff-Serv ...........................................8
4.1.3. Variations Related to Diff-Serv and Queuing .........9
4.1.4. RTP ................................................10
4.1.5. GCP/H.248 ..........................................11
4.2. Policy ....................................................12
4.3. Traffic Engineering .......................................12
4.4. Security ..................................................13
4.4.1. Denial of Service ..................................13
4.4.2. User Authorization .................................14
4.4.3. Confidentiality and Integrity ......................15
4.5. Alternate Path Routing ....................................16
4.6. End-to-End Fault Tolerance ................................17
5. Key Scenarios ..................................................18
5.1. Single IP Administrative Domain ...........................18
5.2. Multiple IP Administrative Domains ........................19
6. Security Considerations ........................................20
7. Informative References .........................................20
Appendix A: Government Telephone Preference Scheme (GTPS) .........24
A.1. GTPS and the Framework Document ..........................24
Appendix B: Related Standards Work ................................24
B.1. Study Group 16 (ITU) .....................................25
Acknowledgements ..................................................26
The Internet has become the primary target for worldwide communications in terms of recreation, business, and various imaginative reasons for information distribution. A constant fixture in the evolution of the Internet has been the support of Best Effort as the default service model. Best Effort, in general terms, implies that the network will attempt to forward traffic to the destination as best as it can, with no guarantees being made, nor any resources reserved, to support specific measures of Quality of Service (QoS). An underlying goal is to be "fair" to all the traffic in terms of the resources used to forward it to the destination.
インターネットは娯楽、ビジネス、および情報配信のための様々な想像力豊かな理由の面で世界的な通信のための主要な標的となっています。インターネットの進化における一定の固定具は、デフォルトのサービスモデルとしてベストエフォートのサポートされています。ベストエフォートは、一般的に、ネットワークは、サービス品質の具体策（QoS）をサポートするために、それは、無保証で作られていることができ、また任意のリソースが予約として最もよくとして先にトラフィックを転送しようとすることを意味します。根本的な目標は、先にそれを転送するために使用されるリソースの面ですべてのトラフィックに「公正」になることです。
In an attempt to go beyond best effort service, [1] presented an overview of Integrated Services (int-serv) and its inclusion into the Internet architecture. This was followed by [2], which specified the RSVP signaling protocol used to convey QoS requirements. With the addition of [3] and [4], specifying controlled load (bandwidth bounds) and guaranteed service (bandwidth & delay bounds), respectively, a design existed to achieve specific measures of QoS for an end-to-end flow of traffic traversing an IP network. In this case, our reference to a flow is one that is granular in definition and applies to specific application sessions.
超えたベストエフォート型のサービスを行くための試みでは、[1]インターネットアーキテクチャに統合サービス（INT-SERV）とそのインクルージョンの概要を発表しました。これは、[2]、QoS要件を伝えるために使用されるRSVPシグナリングプロトコルを指定しているが続きました。添加した[3]及び[4]、制御された負荷（帯域範囲）と保証されたサービス（帯域幅及び遅延限界）を指定し、それぞれ、デザインは、トラフィックのエンドツーエンドのフローのためのQoSの具体策を達成するために存在していIPネットワークを横断します。この場合、流れに対する当社の参照は定義で粒状であり、特定のアプリケーションセッションに適用されるものです。
From a deployment perspective (as of the date of this document), int-serv has been predominantly constrained to intra-domain paths, at best resembling isolated "island" reservations for specific types of traffic (e.g., audio and video) by stub domains. [5] and [6] will probably contribute to additional deployment of int-serv to Internet Service Providers (ISP) and possibly some inter-domain paths, but it seems unlikely that the original vision of end-to-end int-serv between hosts in source and destination stub domains will become a reality in the near future (the mid- to far-term is a subject for others to contemplate).
（本書の日付現在）展開の観点から、INT-SERVは、主にせいぜいスタブドメインで特定のタイプのトラフィックのための単離された「島」の予約（例えば、オーディオおよびビデオを）似ている、ドメイン内のパスに拘束されています。 [5]と[6]おそらく、インターネットサービスプロバイダ（ISP）と、おそらくいくつかのドメイン間のパスにINT-SERVの追加の展開に貢献していきますが、それは間のエンドツーエンドのINT-SERVの本来のビジョンとは考えにくいです（他の人が意図する被写体遠用語に半ばれる）ソースおよび宛先スタブドメイン内のホストは、近い将来に現実のものとなるであろう。
In 1998, the IETF produced [7], which presented an architecture for Differentiated Services (diff-serv). This effort focused on a more aggregated perspective and classification of packets than that of [1]. This is accomplished with the recent specification of the diff-serv field in the IP header (in the case of IPv4, it replaced the old ToS field). This new field is used for code points established by IANA, or set aside as experimental. It can be expected that sets of microflows, a granular identification of a set of packets, will correspond to a given code point, thereby achieving an aggregated treatment of data.
1998年に、IETFは、差別化サービス（差分-SERV）のアーキテクチャを提示している[7]生成しました。この努力は、[1]に比べてパケットのより凝集観点および分類に焦点を当てました。これは、IPヘッダ内のdiff-SERVフィールドの最近の仕様（のIPv4の場合には、それは古いToSフィールドを置換）によって達成されます。この新しいフィールドは、IANAによって確立されたコードポイントのために使用される、又は実験用として確保されています。マイクロフローのセットは、パケットの組の粒状同定は、それによってデータの集約処理を達成する、所定のコードポイントに対応することが期待できます。
One constant in the introduction of new service models has been the designation of Best Effort as the default service model. If traffic is not, or cannot be, associated as diff-serv or int-serv, then it is treated as Best Effort and uses what resources are made available to it.
新しいサービスモデルの導入における一つの定数は、デフォルトのサービスモデルとして、ベストエフォートの指定されています。トラフィックがない場合、または、差分-SERVまたはINT-SERVと関連し、それはベストエフォートとして扱われることができないとリソースがそれに利用可能とされるものを使用している場合。
Beyond the introduction of new services, the continued pace of additional traffic load experienced by ISPs over the years has continued to place a high importance on intra-domain traffic engineering. The explosion of IETF contributions, in the form of drafts and RFCs produced in the area of Multi-Protocol Label Switching (MPLS), exemplifies the interest in versatile and manageable mechanisms for intra-domain traffic engineering. One interesting observation is the work involved in supporting QoS related traffic engineering. Specifically, we refer to MPLS support of differentiated services [8], and the ongoing work in the inclusion of fast bandwidth recovery of routing failures for MPLS [9].
新サービスの導入を超え、年間でのISPが経験する追加のトラフィック負荷の継続的なペースは、ドメイン内のトラフィックエンジニアリングに高い重要性を置くために続けています。 IETF貢献の爆発は、マルチプロトコルラベルスイッチング（MPLS）の地域で生産さ草案およびRFCの形で、ドメイン内のトラフィックエンジニアリングのための汎用性と管理しやすい仕組みに興味を例示しています。一つの興味深い観察は、トラフィックエンジニアリング関連のQoSをサポートするに関与した作品です。具体的には、[9] [8]差別化サービスのMPLSサポートを参照して、MPLSのルーティング障害の高速帯域幅の回復を含めることで進行中の作業。
The evolution of the IP service model architecture has traditionally centered on the type of application protocols used over a network. By this we mean that the distinction, and possible bounds on QoS, usually centers on the type of application (e.g., audio video tools) that is being referred to.
IPサービスモデルアーキテクチャの進化は、伝統的にネットワーク上で使用されるアプリケーションプロトコルの種類に集中しています。これにより、我々は、QoSの区別、可能な範囲は、通常、参照されているアプリケーション（例えば、オーディオビデオツール）のタイプを中心としたということを意味します。
[10] has defined a priority field for SMTP, but it is only for mapping with X.400 and is not meant for general usage. SIP [11] has an embedded field denoting "priority", but it is only targeted toward the end-user and is not meant to provide an indication to the underlying network or end-to-end applications.
[10] SMTPのための優先順位フィールドを定義しているが、それはX.400のみマッピングするためのものであり、一般的な使用のために意図されていません。 SIP [11]「優先度」を表す埋め込みフィールドを有し、それは唯一のエンドユーザーを対象として、基礎となるネットワークへの指示やエンドツーエンドのアプリケーションを提供するものではありません。
Given the emergence of IP telephony, a natural inclusion of its service is an ability to support existing emergency related services. Typically, one associates emergency calls with "911" telephone service in the U.S., or "999" in the U.K. -- both of which are attributed to national boundaries and accessible by the general public. Outside of this there exist emergency telephone services that involve authorized usage, as described in the following subsection.
IPテレフォニーの出現を考えると、そのサービスの自然含めることは、既存の緊急事態に関連するサービスをサポートする機能です。国境に起因し、一般市民からアクセスされているどちらも - 一般的に、1はU.K.で「911」の電話米国でのサービス、または「999」との緊急通話を関連付けます。この外、次のサブセクションで説明するように、権限の使用を伴う緊急電話サービスが存在します。
GETS is an emergency telecommunications service available in the U.S. and is overseen by the National Communications System (NCS) -- an office established by the White House under an executive order [27] and now a part of the Department of Homeland Security. Unlike "911", it is only accessible by authorized individuals. The majority of these individuals are from various government agencies like the Department of Transportation, NASA, the Department of Defense, and the Federal Emergency Management Agency (to name a few). In addition, a select set of individuals from private industry (telecommunications companies, utilities, etc.) that are involved in critical infrastructure recovery operations are also provided access to GETS.
GETS米国で利用可能な緊急通信サービスで、全国通信システム（NCS）によって監督される - エグゼクティブため[27]と国土安全保障省の今一部の下でホワイトハウスによって確立されたオフィス。 「911」とは異なり、それが承認された個人によってのみアクセス可能です。これらの個人の大半は交通、NASA、国防総省の部門、および連邦緊急事態管理庁（数名に）のような様々な政府機関からです。また、重要なインフラの復旧作業に関与している民間企業（通信会社、ユーティリティなど）から個人の選択セットがGETSへのアクセスをも提供されます。
The purpose of GETS is to achieve a high probability that phone service will be available to selected authorized personnel in times of emergencies, such as hurricanes, earthquakes, and other disasters, that may produce a burden in the form of call blocking (i.e., congestion) on the U.S. Public Switched Telephone Network by the general public.
GETSの目的は、ブロッキング呼び出しの形で負担をもたらすかもしれない電話サービスは、ハリケーン、地震、その他の災害などの緊急事態の時代に選ば関係者に利用できるようになり、高い確率を達成することである（すなわち、混雑）米国で公開は一般市民による交換電話網。
GETS is based in part on the ANSI T1.631 standard, specifying a High Probability of Completion (HPC) for SS7 signaling [12][24].
SS7シグナリング[12] [24]のための完了（HPC）の高い確率を指定し、ANSI T1.631規格に部分的に基づいて取得します。
[25] is a recent ITU standard that describes emergency-related communications over the international telephone service. While systems like GETS are national in scope, IEPS acts as an extension to local or national authorized emergency call establishment and provides a building block for a global service.
[25]国際電話サービスを介して緊急関連の通信を説明し、最近のITU規格です。 GETSのようなシステムがスコープ内に国家のですが、IEPSは、ローカルまたは国の認可緊急呼の確立への拡張として機能し、グローバルなサービスのためのビルディングブロックを提供します。
As in the case of GETS, IEPS promotes mechanisms like extended queuing, alternate routing, and exemption from restrictive management controls in order to increase the probability that international emergency calls will be established. The specifics of how this is to be accomplished are to be defined in future ITU document(s).
GETSの場合のように、IEPSは、拡張キューイング、代替ルーティング、及び国際緊急コールが確立される確率を高めるために制限管理コントロールから免除のようなメカニズムを促進します。これを達成する方法の詳細は、今後のITU文書（複数可）で定義されるべきです。
The scope of this document centers on the near and mid-term support of ETS within the context of IP telephony versus Voice over IP. We make a distinction between these two by treating IP telephony as a subset of VoIP, where in the former case, we assume that some form of application layer signaling is used to explicitly establish and maintain voice data traffic. This explicit signaling capability provides the hooks from which VoIP traffic can be bridged to the PSTN.
ボイスオーバーIP対IPテレフォニーのコンテキスト内でETSの近くと中期的な支持体上に、このドキュメントセンターの範囲。私たちは、前者の場合には、我々はアプリケーション層シグナリングのいくつかのフォームを明示的に確立し、音声データトラフィックを維持するために使用されていることを前提としたVoIPのサブセットとしてIPテレフォニーを処理することによって、これらの2つの間の区別をします。この明示的なシグナリング機能は、VoIPトラフィックは、PSTNにブリッジすることができ、そこからフックを提供します。
An example of this distinction is when the Robust Audio Tool (RAT) [13] begins sending VoIP packets to a unicast (or multicast) destination. RAT does not use explicit signaling like SIP to establish an end-to-end call between two users. It simply sends data packets to the target destination. On the other hand, "SIP phones" are host devices that use a signaling protocol to establish a call before sending data towards the destination.
ロバストなオーディオツール（RAT）[13]ユニキャスト（またはマルチキャスト）宛先にVoIPパケットの送信を開始するとき、この区別の例です。 RATは、二人のユーザ間のエンドツーエンドのコールを確立するために、SIPのような明示的なシグナリングを使用していません。これは単に、ターゲットの宛先にデータパケットを送信します。一方、「SIP電話機は、」宛先に向けてデータを送信する前に、コールを確立するためのシグナリングプロトコルを使用するホストデバイスです。
One other aspect we should probably assume exists with IP Telephony is an association of a target level of QoS per session or flow. [28] makes an argument that there is a maximum packet loss and delay for VoIP traffic, and that both are interdependent. For delays of ~200ms, a corresponding drop rate of 5% is deemed acceptable. When delay is lower, a 15-20% drop rate can be experienced and still be considered acceptable. [29] discusses the same topic and makes an argument that packet size plays a significant role in what users tolerate as "intelligible" VoIP. The larger the packet, correlating to a longer sampling rate, the lower the acceptable rate of loss. Note that [28, 29] provide only two of several perspectives in examining VoIP. A more in-depth discussion on this topic is outside the scope of this document, though it should be noted that the choice of codec can significantly alter the above results.
私たちは、おそらくIPテレフォニーに存在すると仮定しなければならないもう一つの側面は、セッションまたはフローごとのQoSの目標レベルの団体です。 [28]は、VoIPトラフィックの最大パケットロスや遅延があるという議論を行い、双方が相互に依存していること。 〜200msの遅延のために、5％の対応するドロップ率が許容されるとみなされます。遅延が低い場合には、15~20％の低下率が経験することができ、それでも許容されるとみなされます。 [29]同じトピックについて説明し、パケットサイズは、ユーザーが「分かりやすい」のVoIPとして容認するもので重要な役割を果たしているという議論になります。より大きなパケット、より長いサンプリング速度に相関する、損失の許容される速度より低いです。 [28、29]のVoIPを調べるにはいくつかの視点の2つだけを提供しています。コーデックの選択が大幅に上記の結果を変えることができることに留意すべきであるにもかかわらず、このトピックに関するより詳細な議論は、この文書の範囲外です。
Regardless of a single and definitive characteristic for stressed conditions, it would seem that interactive voice has a lower threshold of some combinations of loss/delay/jitter than elastic applications such as email or web browsers. This places a higher burden on the problem of supporting VoIP over the Internet. This problem is further compounded when toll-quality service is expected because it assumes a default service model that is better than best effort. This, in turn, can increase the probability that a form of call-blocking can occur with VoIP or IP telephony traffic.
かかわらず、ストレスを条件に、単一および決定的な特徴の、対話型の音声は、電子メールやWebブラウザなどの弾性アプリケーションよりも損失/遅延/ジッタのいくつかの組み合わせの低いしきい値を持っていることと思われます。これは、インターネット上でのVoIPをサポートする問題に高い負荷がかかります。トール品質のサービスが期待されているとき、それは最善の努力よりも優れているデフォルトのサービスモデルを想定しているため、この問題はさらに悪化します。これは、順番に、コールブロッキングの形式は、VoIPやIPテレフォニートラフィックで発生する可能性があるという確率を高めることができます。
Beyond this, part of our motivation in writing this document is to provide a framework for ISPs and telephony carriers to understand the objectives used to support ETS-related IP telephony traffic. In addition, we also wish to provide a reference point for potential customers in order to constrain their expectations. In particular, we wish to avoid any temptation of trying to replicate the exact capabilities of existing emergency voice service that are currently available in the PSTN to that of IP and the Internet. If nothing else, intrinsic differences between the two communications architectures precludes this from happening. Note, this does not prevent us from borrowing design concepts or objectives from existing systems.
これを越えて、この文書を書くことで私たちの動機の一部は、ETS関連のIPテレフォニートラフィックをサポートするために使用目的を理解するためのISPや電話キャリアのためのフレームワークを提供することです。また、我々はまた、彼らの期待を制限するために、潜在的な顧客のための基準点を提供したいです。特に、我々はIPとインターネットとPSTNに現在使用可能な既存の緊急音声サービスの正確な機能を複製しようとしているのいずれかの誘惑を避けたいと思います。何もない場合は、2つの通信アーキテクチャ間の本質的な違いが起きてからこれを排除します。これは、既存のシステムからのデザインコンセプトや目標を借りてから私たちを防ぐことはできません、注意してください。
Section 2 presents several primary objectives that articulate what is considered important in supporting ETS-related IP telephony traffic. These objectives represent a generic set of goals and desired capabilities. Section 3 presents additional value-added objectives, which are viewed as useful, but not critical. Section 4 presents protocols and capabilities that relate or can play a role in support of the objectives articulated in Section 2. Finally, Section 5 presents two scenarios that currently exist or are being deployed in the near term over IP networks. These are not all-inclusive scenarios, nor are they the only ones that can be articulated ([34] provides a more extensive discussion on the topology scenarios related to IP telephony). However, these scenarios do show cases where some of the protocols discussed in Section 4 apply, and where some do not.
第2章では、ETS関連のIPテレフォニートラフィックをサポートする上で重要と考えられるもの明確にいくつかの主要な目標を提示しています。これらの目的は、目標や希望の機能の一般的なセットを表します。第3節では便利な、しかし重要ではないと見ている追加の付加価値の目標を提示します。第4節が関係か、最後に第2節では、多関節の目標をサポートする役割を担うことができるプロトコルや能力を提示し、第5節では、現在存在するか、IPネットワーク上で短期的に展開されている2つのシナリオを提示します。これらは、すべて込みのシナリオしているわけではなく、多関節ことができる唯一のものである（[34]はIPテレフォニーに関連するトポロジのシナリオのより広範な議論を提供します）。しかし、これらのシナリオは、第4節で説明したプロトコルの一部が適用例を示してやる、とどこ一部はしないでください。
Finally, we need to state that this document focuses its attention on the IP layer and above. Specific operational procedures pertaining to Network Operation Centers (NOC) or Network Information Centers (NIC) are outside the scope of this document. This includes the "bits" below IP, other specific technologies, and service-level agreements between ISPs and telephony carriers with regard to dedicated links.
最後に、私たちは、この文書は、IP層と上記上の注意を焦点を当てていることを述べる必要があります。ネットワークオペレーションセンター（NOC）またはネットワークインフォメーションセンター（NIC）に関連する具体的な操作手順は、この文書の範囲外です。これは、IP、他の特定の技術、および専用リンクに関してISPや電話キャリア間のサービスレベル契約以下「ビット」を含みます。
The objective of this document is to present a framework that describes how various protocols and capabilities (or mechanisms) can facilitate and support the traffic from ETS users. In several cases, we provide a bit of background in each area so that the reader is given some context and a more in-depth understanding. We also provide some discussion on aspects about a given protocol or capability that could be explored and potentially advanced to support ETS. This exploration is not to be confused with specific solutions since we do not articulate exactly what must be done (e.g., a new header field, or a new code point).
この文書の目的は、様々なプロトコル及び機能（または機構）を促進し、ETSユーザからのトラフィックをサポートすることができる方法について説明フレームワークを提示することです。いくつかのケースでは、我々は、読者が、いくつかの文脈より深い理解が与えられるように、各領域内の背景のビットを提供します。また、調査し、潜在的にETSをサポートするために進めることができ与えられたプロトコルや機能についての側面にいくつかの議論を提供しています。私たちは何をしなければならないかを正確にはっきりしていないので、この探査は、特定のソリューションと混同すべきではない（例えば、新しいヘッダフィールド、または新しいコードポイント）。
When producing a solution, or examining existing protocols and mechanisms, there are some things that should be considered. One is that inter-domain ETS communications should not rely on ubiquitous or even widespread support along the path between the end points. Potentially, at the network layer there may exist islands of support realized in the form of overlay networks. There may also be cases where solutions may be constrained on an end-to-end basis (i.e., at the transport or application layer). It is this diversity and possibly partial support that needs to be taken into account by those designing and deploying ETS-related solutions.
溶液を生成、または既存のプロトコルとメカニズムを調べるときは、考慮すべきいくつかのものがあります。一つは、ドメイン間ETS通信はエンドポイント間のパスに沿ったユビキタスあるいは幅広い支持に頼るべきではないということです。潜在的に、ネットワーク層でオーバーレイネットワークの形で実現サポートの島が存在してもよいです。また、溶液（すなわち、トランスポート又はアプリケーション層で）エンドツーエンドベースで拘束することができる場合があります。これは、ETS関連のソリューションを設計およびデプロイ、それらによって考慮される必要があり、この多様性と可能性部分的なサポートです。
Another aspect to consider is that there are existing architectures and protocols from other standards bodies that support emergency-related communications. The effort in interoperating with these systems, presumably through gateways or similar types of nodes with IETF protocols, would foster a need to distinguish ETS flows from other flows. One reason would be the scenario of triggering ETS service from an IP network.
考慮すべきもう一つの側面は、緊急関連の通信をサポートする他の標準化団体から既存のアーキテクチャやプロトコルがあるということです。おそらくゲートウェイまたはIETFプロトコルとノードの同様のタイプを介して、これらのシステムとの相互運用に努力は、他のフローからETSフローを区別する必要性を育てることになります。一つの理由は、IPネットワークからETSサービスをトリガーのシナリオだろう。
Finally, we take into consideration the requirements of [35, 36] in discussing the protocols and mechanisms below in Section 4. In doing this, we do not make a one-to-one mapping of protocol discussion a requirement. Rather, we make sure the discussion of Section 4 does not violate any of the requirements in [35, 36].
最後に、我々は、これを行うには第4節では、以下のプロトコルやメカニズムを議論するには、[35、36]の要件を考慮して、我々は、プロトコルの議論の1対1のマッピング要件ことはありません。むしろ、我々は、第4節の議論は[35、36]に要件のいずれにも違反していないことを確認してください。
In this section, we take the objectives presented above and present a set of protocols and capabilities that can be used to achieve them. Given that the objectives are predominantly atomic in nature, the measures used to address them are to be viewed separately with no specific dependency upon each other as a whole. Various protocols and capabilities may be complimentary to each other, but there is no need for all to exist, given different scenarios of operation; and ETS support is not expected to be an ubiquitously available service. We divide this section into 5 areas:
このセクションでは、上記の目的を取り、それらを達成するために使用することができるプロトコルおよび機能のセットを提示します。目的は自然の中で主にアトミックであることを考えると、それらに対処するために使用される措置は、全体としてお互いになんら具体的な依存関係を個別に見られることです。様々なプロトコル及び機能は、互いに相補的であってもよいが、操作の異なるシナリオ所与の全てが存在する必要がなく、。そして、ETSのサポートが普遍的に利用可能なサービスであることが予想されていません。私たちは、5つの領域には、このセクションを分割します：
1) Signaling 2) Policy 3) Traffic Engineering 4) Security 5) Routing
1）2）方針3）トラフィックエンジニアリング4）セキュリティ5）ルーティングシグナリング
Signaling is used to convey various information to either intermediate nodes or end nodes. It can be out-of-band of a data flow, and thus in a separate flow of its own, such as SIP messages. It can be in-band and part of the state information in a datagram containing the voice data. This latter example could be realized in the form of diff-serv code points in the IP packet.
シグナリングは、中間ノードまたはエンド・ノードのいずれかに様々な情報を伝えるために使用されます。これは、帯域外データフローの、したがってそのようなSIPメッセージのような独自の別個の流れであってもよいです。これは、インバンドおよび音声データを含むデータグラム内の状態情報の一部とすることができます。この後者の例では、IPパケットに差分-SERVコードポイントの形で実現することができます。
In the following subsections, we discuss the current state of some protocols and their use in providing support for ETS. We also discuss potential augmentations to different types of signaling and state information to help support the distinction of emergency-related communications in general.
以下のサブセクションでは、我々は現在、いくつかのプロトコルの状態と、ETSのサポートを提供する上での使用を議論します。我々はまた、一般的に緊急に関連する通信の区別を支援するためのシグナリングと状態のさまざまな種類の情報への潜在的な拡張製品を議論します。
With respect to application-level signaling for IP telephony, we focus our attention on the Session Initiation Protocol (SIP). Currently, SIP has an existing "priority" field in the Request-Header-Field that distinguishes different types of sessions. The five values currently defined are: "emergency", "urgent", "normal", "non-urgent", "other-priority". These values are meant to convey importance to the end-user and have no additional semantics associated with them.
IPテレフォニーのためのアプリケーションレベルのシグナリングに関しては、我々は、セッション開始プロトコル（SIP）に注目します。現在、SIPは、リクエスト・ヘッダー・フィールドのセッションの種類を区別して、既存の「優先順位」フィールドがあります。現在定義されている5つの値は以下のとおりです。「緊急」、「緊急」、「ノーマル」、「非緊急」、「他の優先順位」。これらの値は、エンドユーザーへの重要性を伝え、それに関連した追加の意味を持たないことを意味しています。
[14] is an RFC that defines the requirements for a new header field for SIP in reference to resource priority. The requirements are meant to lead to a means of providing an additional measure of distinction that can influence the behavior of gateways and SIP proxies.
[14]リソースの優先順位を参照してSIPのための新たなヘッダフィールドのための要件を定義するRFCです。要件は、ゲートウェイとSIPプロキシの動作に影響を与えることができ区別の追加措置を提供する手段につながることを意味しています。
In accordance with [15], the differentiated services code point (DSCP) field is divided into three sets of values. The first set is assigned by IANA. Within this set, there are currently, three types of Per Hop Behaviors that have been specified: Default (correlating to best effort forwarding), Assured Forwarding, and Expedited Forwarding. The second set of DSCP values are set aside for local or experimental use. The third set of DSCP values are also set aside for local or experimental use, but may later be reassigned to IANA if the first set has been completely assigned.
[15]に従って、差別化サービスコードポイント（DSCP）フィールドは、値の3つのセットに分割されます。最初のセットは、IANAによって割り当てられます。このセット内では、現在存在し、指定されているパーホップ行動の3種類：デフォルト（ベストエフォート転送に相関する）、保証転送、および緊急転送。 DSCP値の第2のセットは、ローカルまたは実験的使用のために確保されています。 DSCP値の第三のセットはまた、局所的または実験的使用のために確保されているが、第1のセットは完全に割り当てられている場合、後にIANAに再割り当てすることができます。
One approach discussed on the IEPREP mailing list is the specification of a new Per-Hop Behaviour (PHB) for emergency-related flows. The rationale behind this idea is that it would provide a baseline by which specific code points may be defined for various emergency-related traffic: authorized emergency sessions (e.g., ETS), general public emergency calls (e.g., "911"), Multi-Level Precedence and Preemption (MLPP) [19], etc. However, in order to define a new set of code points, a forwarding characteristic must also be defined. In other words, one cannot simply identify a set of bits without defining their intended meaning (e.g., the drop precedence approach of Assured Forwarding). The one caveat to this statement are the set of DSCP bits set aside for experimental purposes. But as the name implies, experimental is for internal examination and use and not for standardization.
IEPREPのメーリングリストで議論の一つのアプローチは、緊急関連のフローのための新しいホップ単位動作（PHB）の仕様です。このアイデアの背後にある理由は、それが特定のコード・ポイントは、様々な緊急関連のトラフィックのために定義されるかもしれないベースラインを提供することである：緊急セッション（例えば、ETS）、一般公衆緊急通報（例えば、「911」）、マルチを許可しましたレベル優先順位およびプリエンプション（MLPP）[19]などが、コードポイントの新しいセットを定義するために、転送特性も定義されなければなりません。換言すれば、一つは単純に（例えば、保証転送のドロップ優先アプローチ）それらの意図意味を定義しないビットの組を識別することができません。この文の1つの注意点は、実験の目的のために確保されたDSCPビットのセットです。名前が示すようにしかし、実験的には、内部検査し、使用のためではなく、標準化のためです。
Note:
注意：
It is important to note that at the time this document was written, the IETF had been taking a conservative approach in specifying new PHBs. This is because the number of code points that can be defined is relatively small and is understandably considered a scarce resource. Therefore, the possibility of a new PHB being defined for emergency-related traffic is, at best, a long term project that may or may not be accepted by the IETF.
この文書が書かれた時点で、IETFが新しいのPHBを指定するには保守的なアプローチを取っていたことに注意することが重要です。定義できるコードポイントの数が比較的少なく、当然希少資源であると考えられるからです。そのため、緊急関連のトラフィックのために定義されている新しいPHBの可能性は、せいぜい、またはしないことがありIETFによって受け入れられる長期的なプロジェクトです。
In the near term, we would initially suggest using the Assured Forwarding (AF) PHB [18] for distinguishing emergency traffic from other types of flows. At a minimum, AF could be used for the different SIP call signaling messages. If the Expedited Forwarding (EF) PHB [40] was also supported by the domain, then it would be used for IP telephony data packets. Otherwise, another AF class would be used for those data flows.
短期的には、我々は最初の流れの他のタイプからの緊急のトラフィックを区別するための保証転送（AF）PHB [18]を使用してお勧めします。最低でも、AFは、シグナリングメッセージを異なるSIPコールのために使用することができます。緊急転送（EF）PHB [40]は、ドメインによってサポートされていた場合、それはIPテレフォニーデータパケットのために使用されます。そうでない場合は、別のAFクラスは、それらのデータ・フローのために使用されます。
Scheduling mechanisms like Weighted Fair Queueing and Class Based Queueing are used to designate a percentage of the output link bandwidth that would be used for each class if all queues were backlogged. Its purpose, therefore, is to manage the rates and delays experienced by each class. But emergency traffic may not necessarily require QoS perform any better or differently than non- emergency traffic. It may just need higher probability of being forwarded to the next hop, which could be accomplished simply by dropping precedences within a class.
均等化キューイングおよびクラスベースキューイングのようなスケジューリングメカニズムは、すべてのキューがバックログされた場合には、各クラスのために使用される出力リンクの帯域幅の割合を指定するために使用されています。その目的は、それゆえ、各クラスが経験率および遅延を管理することです。しかし、緊急時のトラフィックは、必ずしもQoSが任意のより良いまたは異なっ非緊急トラフィックより行う必要はないかもしれません。それはちょうど、クラス内優先順位をドロップすることによって簡単に達成することができる次のホップに転送されているのより高い確率が必要な場合があります。
To implement preferential dropping between classes of traffic, one of which is emergency traffic, one would probably need to use a more advanced form of Active Queue Management (AQM). Current implementations use an overall queue fill measurement to make decisions; this might cause emergency classified packets to be dropped. One new form of AQM could be a Multiple Average-Multiple Threshold approach, instead of the Single Average-Multiple Threshold approach used today. This allows creation of drop probabilities based on counting the number of packets in the queue for each drop precedence individually.
緊急交通そのうちの1つは、トラフィックのクラス間の優先ドロップを実装するためには、おそらくアクティブキュー管理（AQM）のより高度なフォームを使用する必要があります。現在の実装では、意思決定を行うために、全体的なキューフィル測定を使用します。これは緊急事態分類されたパケットが廃棄されることがあります。 AQMの一つの新しい形ではなく、現在使用されて単一の平均-複数のしきい値アプローチで、複数の平均-複数のしきい値アプローチである可能性があります。これは、個別に廃棄優先順位のキュー内のパケットの数をカウントに基づいて、ドロップ確率を作成することができます。
So, it could be possible to use the current set of AF PHBs if each class were reasonably homogenous in the traffic mix. But one might still have a need to differentiate three drop precedences within non-emergency traffic. If so, more drop precedences could be implemented. Also, if one wanted discrimination within emergency traffic, as with MLPP's five levels of precedence, more drop precedences might also be considered. The five levels would also correlate to a recent effort in Study Group 11 of the ITU to define 5 levels for Emergency Telecommunications Service.
各クラスは、トラフィックミックスで合理的に均質たのであれば、AFのPHBの現在のセットを使用することが可能である可能性があります。しかし、一つは、まだ非緊急トラフィック内の3つの廃棄優先順位を区別する必要があるかもしれません。その場合は、より多くの廃棄優先順位を実施することができます。 1緊急トラフィック内差別を望んでいた場合にも、優先のMLPPの5つの段階と同様に、より多くの廃棄優先順位も考えられるかもしれません。 5つのレベルがまた、緊急通信サービスのための5つのレベルを定義するためのITUの研究グループ11の最近の努力に相関するであろう。
The Real-Time Transport Protocol (RTP) provides end-to-end delivery services for data with real-time characteristics. The type of data is generally in the form of audio or video type applications, and is frequently interactive in nature. RTP is typically run over UDP and has been designed with a fixed header that identifies a specific type of payload representing a specific form of application media. The designers of RTP also assumed an underlying network providing best effort service. As such, RTP does not provide any mechanism to ensure timely delivery or provide other QoS guarantees. However, the emergence of applications like IP telephony, as well as new service models, present new environments where RTP traffic may be forwarded over networks that support better than best effort service. Hence, the original scope and target environment for RTP has expanded to include networks providing services other than best effort.
リアルタイムトランスポートプロトコル（RTP）は、リアルタイムの特性を持つデータのエンドツーエンドの配信サービスを提供しています。データの種類は、オーディオやビデオタイプのアプリケーションの形で一般的であり、自然の中で頻繁にインタラクティブです。 RTPは、典型的には、UDP上で実行され、アプリケーションメディアの特定の形態を表すペイロードの特定のタイプを識別する固定ヘッダで設計されています。 RTPの設計者はまた、ベストエフォート型のサービスを提供する基盤となるネットワークを想定しました。そのように、RTPは、タイムリーな配送を確保するか、他のQoS保証を提供するために、任意のメカニズムを提供しません。しかし、IPテレフォニー、および新しいサービスモデル、RTPトラフィックはベストエフォートサービスより良いサポートするネットワーク上で転送することができる存在新しい環境などのアプリケーションの登場。したがって、RTPのためのオリジナルスコープとターゲット環境は、ベストエフォート以外のサービスを提供するネットワークを含むように拡大してきました。
In 4.1.2, we discussed one means of marking a data packet for emergencies under the context of the diff-serv architecture. However, we also pointed out that diff-serv markings for specific PHBs are not globally unique, and may be arbitrarily removed or even changed by intermediary nodes or domains. Hence, with respect to emergency related data packets, we are still missing an in-band marking in a data packet that stays constant on an end-to-end basis.
4.1.2において、我々は、差分-SERVアーキテクチャのコンテキストで緊急事態のためのデータパケットをマーキングの一つの手段を検討しました。しかし、我々はまた、特定のPHBのためのdiff-SERVマーキングがグローバルに一意ではなく、中間ノードまたはドメインによって任意に除去し、あるいは変更されてもよいことを指摘しました。このため、緊急に関連するデータパケットに関して、我々はまだ、帯域内のエンドツーエンドベースで一定でデータパケットにマーキング表示されません。
There are three choices in defining a persistent marking of data packets and thus avoiding the transitory marking of diff-serv code points. One can propose a new PHB dedicated for emergency type traffic as discussed in 4.1.2. One can propose a specification of a new shim layer protocol at some location above IP. Or, one can add a new specification to an existing application layer protocol. The first two cases are probably the "cleanest" architecturally, but they are long term efforts that may not come to pass because of a limited number of diff-serv code points and the contention that yet another shim layer will make the IP stack too large. The third case, placing a marking in an application layer packet, also has drawbacks; the key weakness being the specification of a marking on a per-application basis.
永続的なデータパケットのマーキングので、差分-SERVコードポイントのマーキング一時の回避を定義する3つの選択肢があります。 4.1.2で述べたように、1つは、緊急タイプのトラフィック専用の新しいPHBを提案することができます。一つは、IP上、いくつかの場所で新しいシム層プロトコルの仕様を提案することができます。それとも、1は、既存のアプリケーション層プロトコルに新しい仕様を追加することができます。最初の2例は、おそらく建築「クリーン」ですが、彼らは理由差分-SERVコード・ポイントの数が限られ、まだ別のシム層は、IPスタックが大きすぎるようになりますことを、競合の渡すために来ないかもしれない長期的な努力です。第三の場合は、アプリケーション層パケットにマーキングを配置することも欠点を有します。キーの弱点は、アプリケーションごとにマーキングの仕様であること。
Discussions have been held in the Audio/Visual Transport (AVT) working group on augmenting RTP so that it can carry a marking that distinguishes emergency-related traffic from that which is not. Specifically, these discussions centered on defining a new extension that contains a "classifier" field indicating the condition associated with the packet (e.g., authorized-emergency, emergency, normal) [26]. The rationale behind this idea was that focusing on RTP would allow one to rely on a point of aggregation that would apply to all payloads that it encapsulates. However, the AVT group has expressed a rough consensus that placing an additional classifier state in the RTP header to denote the importance of one flow over another is not an approach they wish to advance. Objections ranging from relying on SIP to convey the importance of a flow, to the possibility of adversely affecting header compression, were expressed. There was also the general feeling that the extension header for RTP that acts as a signal should not be used.
それはそれがされていないことから、緊急関連のトラフィックを区別マーキング運ぶことができるように、議論がRTPを増大させる上でワーキンググループオーディオ/ビジュアルトランスポート（AVT）に開催されています。具体的には、これらの議論は、パケット（例えば、許可された緊急、救急、ノーマル）[26]に関連付けられている状態を示す「分類器」フィールドを含む新しい拡張を定義する上で中心。この考え方の根拠は、RTPに注力すると1は、それがカプセル化するすべてのペイロードに適用される集約のポイントに依存することが可能になるということでした。しかし、AVT基は、別の上に一つのフローの重要性を示すために、RTPヘッダ内の追加的な分類器の状態を確定することは、彼らが前進することを望む方法ではないことをラフコンセンサスを表明しています。不利なヘッダ圧縮に影響を与える可能性のために、流れの重要性を伝えるためにSIPに依存する範囲異議は、発現されました。シグナルとして作用するRTPの拡張ヘッダを使用すべきではないことが一般的な感じがありました。
The Gateway Control Protocol (GCP) [21] defines the interaction between a media gateway and a media gateway controller. [21] is viewed as an updated version of common text with ITU-T Recommendation H.248 [41] and is a result of applying the changes of RFC 2886 (Megaco Errata) [43] to the text of RFC 2885 (Megaco Protocol version 0.8) [42].
ゲートウェイコントロールプロトコル（GCP）[21]は、メディアゲートウェイとメディアゲートウェイコントローラとの間の相互作用を規定します。 [21] Megacoのプロトコル（RFC 2885のテキストに[43] ITU-T勧告H.248と共通テキストの更新バージョン[41]のように表示およびRFC 2886（Megacoの正誤表）の変更を適用した結果でありますバージョン0.8）[42]。
In [21], the protocol specifies a Priority and Emergency field for a context attribute and descriptor. The Emergency is an optional boolean (True or False) condition. The Priority value, which ranges from 0 through 15, specifies the precedence handling for a context.
[21]では、プロトコルは、コンテキスト属性と記述のための優先度と緊急フィールドを指定します。緊急時には、オプションのブール（真または偽）状態です。 0から15の範囲を通じて優先順位の値は、コンテキストの処理の優先順位を指定します。
The protocol does not specify individual values for priority. We also do not recommend the definition of a well known value for the GCP priority as this is out of scope of this document. Any values set should be a function of any SLAs that have been established regarding the handling of emergency traffic.
プロトコルは、優先順位のための個々の値を指定していません。これはこの文書の範囲外であるとして、我々はまた、GCPの優先順位のためのよく知られた値の定義をお勧めしません。任意の値のセットは、緊急トラフィックの取り扱いに関する確立されているすべてのSLAに機能する必要があります。
One of the objectives listed in Section 3 above is to treat ETS signaling, and related data traffic, as non-preemptive in nature. Further, this treatment is to be the default mode of operation or service. This is in recognition that existing regulations or laws of certain countries governing the establishment of SLAs may not allow preemptive actions (e.g., dropping existing telephony flows). On the other hand, the laws and regulations of other countries influencing the specification of SLA(s) may allow preemption, or even require its existence. Given this disparity, we rely on local policy to determine the degree by which emergency-related traffic affects existing traffic load of a given network or ISP. Important note: we reiterate our earlier comment that laws and regulations are generally outside the scope of the IETF and its specification of designs and protocols. However, these constraints can be used as a guide in producing a baseline capability to be supported; in our case, a default policy for non-preemptive call establishment of ETS signaling and data.
上記のセクション3に記載された目的の一つは、自然の中でノンプリエンプティブとして、ETSシグナリング、および関連するデータトラフィックを処理することです。さらに、この治療法は、操作またはサービスのデフォルトモードになることです。これは、SLAのの確立を管理する特定の国の既存の規制や法律が先制行動が（例えば、既存のテレフォニー・フローをドロップする）ことができないかもしれない認識です。一方、SLA（S）の仕様に影響を与える他の国の法律や規制は、プリエンプションを許可する、あるいはその存在を必要とするかもしれません。この格差を考えると、我々は緊急関連のトラフィックは、特定のネットワークやISPの既存のトラフィック負荷に影響を与える度合いを決定するために、ローカルポリシーに依存しています。重要な注意：私たちは法律や規制は、IETFやデザインとプロトコルのその仕様の範囲外で、一般的であることを私たちの以前のコメントを改めて表明する。しかしながら、これらの制約をサポートするベースライン性能を製造する際のガイドとして使用することができます。私たちの場合は、ETSシグナリング及びデータのノンプリエンプティブな呼確立のためのデフォルトのポリシー。
Policy can be in the form of static information embedded in various components (e.g., SIP servers or bandwidth brokers), or it can be realized and supported via COPS with respect to allocation of a domain's resources [16]. There is no requirement as to how policy is accomplished. Instead, if a domain follows actions outside of the default non-preemptive action of ETS-related communication, then we stipulate that some type of policy mechanism be in place to satisfy the local policies of an SLA established for ETS-type traffic.
[16]ポリシーは、様々な構成要素（例えば、SIPサーバまたは帯域幅ブローカー）に埋め込まれた静的情報の形態とすることができる、またはそれは、ドメインのリソースの割り当てに対して、COPSを介して実現されて支持することができます。ポリシーが達成される方法についての要件はありません。ドメインはETS関連の通信のデフォルトの非先制行動の外のアクションを以下の場合は代わりに、我々は政策のメカニズムのいくつかのタイプがETS-タイプのトラフィックのために設立されたSLAのローカルポリシーを満たすために適切なものであることを規定しています。
In those cases where a network operates under the constraints of SLAs, one or more of which pertains to ETS-based traffic, it can be expected that some form of traffic engineering is applied to the operation of the network. We make no recommendations as to which type of traffic engineering mechanism is used, but that such a system exists in some form and can distinguish and support ETS signaling and/or data traffic. We recommend a review of [32] by clients and prospective providers of ETS service that gives an overview and a set of principles of Internet traffic engineering.
ネットワークはSLAの、一つまたはそのETSベースのトラフィックに関するより多くの制約の下で動作するような場合には、トラフィックエンジニアリングのいくつかの形態は、ネットワークの動作に適用されることが期待できます。我々は、トラフィックエンジニアリング機構の種類が使用されているためにどのように何の勧告をしないが、そのようなシステムは、いくつかの形で存在し、区別しETSシグナリングおよび/またはデータトラフィックをサポートすることができます。私たちは、クライアントと概要とインターネットトラフィックエンジニアリングの原則のセットを与えるETSサービスの将来のプロバイダによる[32]のレビューをお勧めします。
MPLS is generally the first protocol that comes to mind when the subject of traffic engineering is brought up. This notion is heightened concerning the subject of IP telephony because of MPLS's ability to permit a quasi-circuit switching capability to be superimposed on the current Internet routing model [30].
MPLSは、一般的にトラフィックエンジニアリングの対象を育てているとき心に来る最初のプロトコルです。この概念があるため、現在のインターネットルーティングモデル[30]に重畳する疑似回線交換機能を可能にするMPLSの能力のIP電話の主題に関する高められます。
However, having cited MPLS, we need to stress that it is an intradomain protocol, and so may or may not exist within a given ISP. Other forms of traffic engineering, such as weighted OSPF, may be the mechanism of choice by an ISP.
しかしながら、引用したMPLSは、我々はそれがドメイン内のプロトコルであることを強調する必要があり、そのため、または所与のISP内に存在してもしなくてもよいです。こうした加重OSPFなどのトラフィックエンジニアリングの他の形態は、ISPによって選択の機構であってもよいです。
As a counter example of using a specific protocol to achieve traffic engineering, [37] presents an example of one ISP relying on a high amount of overprovisioning within its core to satisfy potentially dramatic spikes or bursts of traffic load. In this approach, any configuring of queues for specific customers (neighbors) to support the target QoS is done on the egress edge of the transit network.
[37]、トラフィックエンジニアリングを達成するために特定のプロトコルを使用してのカウンタ例として、トラフィック負荷の潜在的に劇的にスパイクまたはバーストを満たすために、そのコア内オーバープロビジョニングの高い量に依存する1つのISPの例を示します。このアプローチでは、ターゲットQoSをサポートするために、特定の顧客（ネイバー）のためのキューのいずれかの設定は、トランジットネットワークの出口エッジで行われます。
Note: As a point of reference, existing SLAs established by the NCS for GETS service tend to focus on a loosely defined maximum allocation of, for example, 1% to 10% of calls allowed to be established through a given LEC using HPC. It is expected, and encouraged, that ETS related SLAs of ISPs will be limited with respect to the amount of traffic distinguished as being emergency related and initiated by an authorized user.
注：基準点として、のためには、サービスを取得NCSによって確立された既存のSLAは、例えば、1％のHPCを使用して、指定されたLECを介して確立することが許可されたコールの10％の緩く定義された最大割り当てに集中する傾向があります。 ISPののETS関連のSLAは緊急事態が関連しており、正当なユーザによって開始されたものとして区別し、トラフィックの量に関して制限されることを、期待、および奨励されます。
This section provides a brief overview of the security issues raised by ETS support.
このセクションでは、ETSのサポートが提起したセキュリティ問題の概要を説明します。
Any network mechanism that enables a higher level of priority for a specific set of flows could be abused to enhance the effectiveness of denial of service (DoS) attacks. Priority would magnify the effects of attack traffic on bandwidth availability in lower-capacity links, and increase the likelihood of it reaching its target(s). An attack could also tie up resources such as circuits in a PSTN gateway.
フローの特定のセットのための優先順位のより高いレベルを可能にする任意のネットワーク・メカニズムは、サービス拒否（DoS）攻撃の拒否の有効性を高めるために悪用される可能性があります。優先順位は、低容量のリンクでの帯域幅の可用性に攻撃トラフィックの影響を拡大して、その対象（複数可）に到達することの可能性を増加させます。攻撃はまた、PSTNゲートウェイ内の回路などのリソースを占有できました。
Any provider deploying a priority mechanism (such as the QoS systems described in Section 4.1) must therefore carefully apply the associated access controls and security mechanisms. For example, the priority level for traffic originating from an unauthorized part of a network or ingress point should be reset to normal. Users must also be authenticated before being allowed to use a priority service (see Section 4.4.2). However, this authentication process should be lightweight to minimise opportunities for denial of service attacks on the authentication service itself, and ideally should include its own anti-DoS mechanisms. Other security mechanisms may impose an overhead that should be carefully considered to avoid creating other opportunities for DoS attacks.
（例えば、セクション4.1に記載のQoSシステムなど）の優先順位機構を展開任意のプロバイダは、したがって注意深く関連するアクセス制御およびセキュリティメカニズムを適用する必要があります。例えば、ネットワークまたは入力ポイントの不正な部分に由来するトラフィックの優先度は、正常にリセットされなければなりません。また、ユーザーは優先順位のサービスを（4.4.2項を参照）を使用することが許可される前に認証されなければなりません。しかし、この認証プロセスは、認証サービス自体のサービス拒否攻撃の機会を最小限にするために、軽量であるべきであり、理想的に独自のアンチDoS攻撃メカニズムを含める必要があります。他のセキュリティ・メカニズムは慎重にDoS攻撃のための他の機会を作成しないように考慮しなければならないオーバーヘッドを課すことができます。
As mentioned in Section 4.3, SLAs for ETS facilities often contain maximum limits on the level of ETS traffic that should be prioritised in a particular network (say 1% of the maximum network capacity). This should also be the case in IP networks to again reduce the level of resources that a denial of service attack can consume.
セクション4.3で述べたように、ETS施設のSLAは、多くの場合、特定のネットワークに優先されるべきであるETSトラフィックのレベルに上限を含む（例えば最大ネットワーク容量の1％）。また、これは、再び、サービス拒否攻撃が消費できるリソースのレベルを減らすために、IPネットワークにおける場合でなければなりません。
As of this writing, a typical inter-provider IP link uses 1 Gbps Ethernet, OC-48 SONET/SDH, or some similar or faster technology. Also, as of this writing, it is not practical to deploy per-IP packet cryptographic authentication on such inter-provider links, although such authentication might well be needed to provide assurance of IP-layer label integrity in the inter-provider scenario.
これを書いているように、一般的なインタープロバイダIPリンクは1Gbpsのイーサネット、OC-48 SONET / SDH、またはいくつかの類似またはより高速な技術を使用しています。そのような認証はうまく相互プロバイダーシナリオにおけるIPレイヤのラベルの整合性の保証を提供するために必要かもしれませんが。また、これを書いているとして、インタープロバイダのリンク上あたり-IPパケットの暗号化認証を展開することは現実的ではありません。
While Moore's Law will speed up cryptographic authentication, it is unclear whether that is helpful because the speed of the typical inter-domain link is also increasing rapidly.
ムーアの法則は、暗号認証をスピードアップしますが、典型的なドメイン間リンクの速度も急速に増加しているので、それが役に立つかどうかは不明です。
To prevent theft of service and reduce the opportunities for denial of service attacks, it is essential that service providers properly verify the authorization of a specific traffic flow before providing it with ETS facilities.
サービスの盗難を防止し、サービス拒否攻撃の機会を減らすために、サービスプロバイダが適切にETS施設でそれを提供する前に特定のトラフィックフローの許可を確認することが不可欠です。
Where an ETS call is carried from PSTN to PSTN via one telephony carrier's backbone IP network, very little IP-specific user authorization support is required. The user authenticates itself to the PSTN as usual -- for example, using a PIN in the US GETS. The gateway from the PSTN connection into the backbone IP network must be able to signal that the flow has an ETS label. Conversely, the gateway back into the PSTN must similarly signal the call's label. A secure link between the gateways may be set up using IPSec or SIP security functionality to protect the integrity of the signaling information against attackers who have gained access to the backbone network, and to prevent such attackers from placing ETS calls using the egress PSTN gateway. If the destination of a call is an IP device, the signaling should be protected directly between the IP ingress gateway and the end device.
ETSのコールが1つの電話キャリアのバックボーンIPネットワークを介してPSTNにPSTNから実施される場合、非常に小さなIP固有のユーザー認証のサポートが必要です。米国はGETSでPINを使用して、例えば - ユーザーは、いつものようにPSTNに自分自身を認証します。バックボーンIPネットワークへのPSTN接続からゲートウェイは、流れがETSラベルを持っていることを知らせることができなければなりません。逆に、バックPSTNへのゲートウェイは、同様に、コールのラベルを通知しなければなりません。ゲートウェイ間の安全なリンクは、バックボーンネットワークへのアクセスを得ている攻撃者に対してシグナリング情報の完全性を保護するためのIPSecやSIPのセキュリティ機能を使用して設定することができる、そして出口PSTNゲートウェイを使用して、ETSの呼び出しを配置するから、このような攻撃を防ぐために。呼の宛先はIPデバイスである場合、シグナリングは、IP入力ゲートウェイとエンドデバイス間で直接保護されるべきです。
When ETS priority is being provided to a flow within one domain, that network must use the security features of the priority mechanism being deployed to ensure that the flow has originated from an authorized user or process.
ETSの優先度は、1つのドメイン内のフローに提供されている場合、そのネットワークは、フローが許可されたユーザまたはプロセスに由来していることを確認するために展開される優先機構のセキュリティ機能を使用しなければなりません。
The access network may authorize ETS traffic over a link as part of its user authentication procedures. These procedures may occur at the link, network, or higher layers, but are at the discretion of a single domain network. That network must decide how often it should update its list of authorized ETS users based on the bounds it is prepared to accept on traffic from recently-revoked users.
アクセスネットワークは、そのユーザーの認証手順の一部として、リンク上ETSトラフィックを許可することができます。これらの手順は、リンク、ネットワーク、又はより高い層で起こるが、単一ドメインネットワークの裁量であることができます。そのネットワークは、最近取り消されたユーザーからのトラフィックに受け入れる用意がある境界に基づいて認可ETSのユーザーのリストを更新する頻度を決定する必要があります。
If ETS support moves from intra-domain PSTN and IP networks to inter-domain end-to-end IP, verifying the authorization of a given flow becomes more complex. The user's access network must verify a user's ETS authorization if network-layer priority is to be provided at that point.
ドメイン内のPSTNとIPネットワークからのドメイン間のエンドツーエンドIPへETSサポートを移動する場合は、所定のフローの許可を検証することは、より複雑になります。ネットワーク層の優先順位は、その時点で提供される場合、ユーザーのアクセスネットワークは、ユーザーのETS認可を確認する必要があります。
Administrative domains that agree to exchange ETS traffic must have the means to securely signal to each other a given flow's ETS status. They may use physical link security combined with traffic conditioning measures to limit the amount of ETS traffic that may pass between the two domains. This agreement must require the originating network to take responsibility for ensuring that only authorized traffic is marked with ETS priority, but the recipient network cannot rely on this happening with 100% reliability. Both domains should perform conditioning to prevent the propagation of theft and denial of service attacks. Note that administrative domains that agree to exchange ETS traffic must deploy facilities that perform these conditioning and security services at every point at which they interconnect with one another.
ETSトラフィックを交換することに同意するものとし、管理ドメインはしっかりと互いに所定のフローのETS状態に合図する手段を持っている必要があります。これら2つのドメイン間を通過できるETSトラフィックの量を制限するために、トラフィック調整措置と組み合わせた物理リンクセキュリティを使用してもよいです。この契約は、許可トラフィックがETSの優先順位でマークされますが、受信者のネットワークは、100％の信頼度で、この出来事に頼ることができないことを確実にするための責任を取るために、発信ネットワークを必要としなければなりません。両方のドメインは、盗難やサービス拒否攻撃の伝播を防止するためのコンディショニングを行うべきです。 ETSトラフィックを交換することに同意する管理ドメインは、彼らがお互いに相互接続した時にすべての点で、これらのコンディショニングおよびセキュリティサービスを行う施設を展開しなければならないことに注意してください。
Processes using application-layer protocols, such as SIP, should use the security functionality in those protocols to verify the authorization of a session before allowing it to use ETS mechanisms.
SIPなどのアプリケーション層プロトコルを使用するプロセスは、それがETSメカニズムを使用することを可能にする前に、セッションの許可を確認するためにそれらのプロトコルのセキュリティ機能を使用すべきです。
When ETS communications are being used to respond to a deliberate attack, it is important that they cannot be altered or intercepted to worsen the situation -- for example, by changing the orders to first responders such as firefighters, or by using knowledge of the emergency response to cause further damage.
ETSの通信は意図的な攻撃に対応するために使用されている場合は、彼らが状況を悪化させる変更または傍受することができないことが重要である - 例えば、消防士などの最初の応答者に注文を変更することで、または緊急の知識を使って、さらなる損傷を引き起こす応答。
The integrity and confidentiality of such communications should therefore be protected as far as possible using end-to-end security protocols such as IPSec or the security functionality in SIP and SRTP [39]. Where communications involve other types of networks such as the PSTN, the IP side should be protected and any security functionality available in the other network should be used.
このような通信の完全性と機密性は、したがって、そのようなIPSecまたはSIPおよびSRTPのセキュリティ機能[39]などのエンドツーエンドのセキュリティプロトコルを使用して可能な限り保護されるべきです。通信は、PSTNなどのネットワークの他のタイプを含む場合、IP側は、保護されるべきであり、他のネットワークで利用可能な任意のセキュリティ機能を使用すべきです。
This subject involves the ability to discover and use a different path to route IP telephony traffic around congestion points, and thus avoid them. Ideally, the discovery process would be accomplished in an expedient manner (possibly even a priori to the need of its existence). At this level, we make no assumptions as to how the alternate path is accomplished, or even at which layer it is achieved -- e.g., the network versus the application layer. But this kind of capability, at least in a minimal form, would help contribute to increasing the probability of ETS call completion by making use of noncongested alternate paths. We use the term "minimal form" to emphasize the fact that care must be taken in how the system provides alternate paths so that it does not significantly contribute to the congestion that is to be avoided (e.g., via excess control/discovery messages).
この主題は、輻輳ポイントの周りのルートIPテレフォニートラフィックに別のパスを発見し、使用する能力を必要とするので、それらを避けます。理想的には、発見プロセスは、好都合な方法（その存在の必要に可能性も先験的）で達成されるであろう。このレベルでは、我々は、代替パスが達成される方法について何ら仮定を行わない、あるいはそれが実現されてもその層に - 例えば、アプリケーション層対ネットワーク。しかし、機能のこの種は、少なくとも最低限の形式で、noncongested代替パスを利用することにより、ETSコール完了の確率を高めることに貢献します。我々はそれを大幅に避けるべきである輻輳に寄与しないように注意が（例えば、過剰制御/発見メッセージを介して、）システムが代替パスを提供してどのように取られなければならないという事実を強調するために、用語「最小限のフォーム」を使用します。
Routing protocols at the IP network layer, such as BGP and OSPF, contain mechanisms for determining link failure between routing peers. The discovery of this failure automatically causes information to be propagated to other routers. The form of this information, the extent of its propagation, and the convergence time in determining new routes is dependent on the routing protocol in use. In the example of OSPF's Equal Cost Multiple Path (ECMP), the impact of link failure is minimized because of pre-existing alternate paths to a destination.
そのようなBGPやOSPFなどのIPネットワーク層におけるルーティングプロトコルは、ルーティングピア間のリンク障害を決定するためのメカニズムを含みます。この障害の発見は、自動的に情報が他のルータに伝搬されます。この情報の形態、その増殖の程度、及び新たなルートを決定する際の収束時間は、使用中のルーティングプロトコルに依存しています。 OSPFの等コストマルチパス（ECMP）の例では、リンク障害の影響があるため、宛先に既存の代替パスを最小限に抑えられます。
At the time this document was written, we can identify two additional areas in the IETF that can be helpful in providing alternate paths for the specific case of call signaling. The first is [9], which is focused on network layer routing and describes a framework for enhancements to the LDP specification of MPLS to help achieve fault tolerance. This, in itself, does not provide alternate path routing, but rather helps minimize loss in intradomain connectivity when MPLS is used within a domain.
この文書が書かれた時点で、我々は、コールシグナリングの特定の場合のための代替経路を提供するのに役立つことができるIETFに2つの追加の領域を識別することができます。最初は、ネットワーク層ルーティングに着目し、フォールトトレランスを達成するためにMPLS LDPの仕様に拡張するためのフレームワークについて説明している[9]、です。これは、それ自体では、代替パスルーティングを提供するのではなく、MPLSは、ドメイン内で使用される場合、ドメイン内の接続の損失を最小限に抑えることができません。
The second effort comes from the IP Telephony working group and involves Telephony Routing over IP (TRIP). To date, a framework document [17] has been published as an RFC that describes the discovery and exchange of IP telephony gateway routing tables between providers. The TRIP protocol [20] specifies application level telephony routing regardless of the signaling protocol being used (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises reachability and attributes of destinations. In its current form, several attributes have already been defined, such as LocalPreference and MultiExitDisc. Additional attributes can be registered with IANA.
第二の努力は、IPテレフォニーワーキンググループから来て、IP（TRIP）上テレフォニールーティングを必要とします。現在までに、フレームワークドキュメント[17]はプロバイダー間のIPテレフォニーゲートウェイのルーティングテーブルの発見と交換を記述するRFCとして公開されています。 TRIPプロトコル[20]（例えば、SIPまたはH.323）使用されているにかかわらず、シグナリングプロトコルのアプリケーションレベルの電話ルーティングを指定します。 TRIPは、BGP-4をモデルにしたと到達可能性と目的地の属性をアドバタイズしています。現在の形では、いくつかの属性はすでに、このようなLocalPreferenceとMultiExitDiscとして、定義されています。追加の属性は、IANAに登録することができます。
Inter-domain routing is not an area that should be considered in terms of additional alternate path routing support for ETS. The Border Gateway Protocol is currently strained in meeting its existing requirements, and thus adding additional features that would generate an increase in advertised routes will not be well received by the IETF. Refer to [38] for a commentary on Inter-Domain routing.
ドメイン間ルーティングはETSのためのサポートをルーティングする追加の代替パスの観点から考慮されるべき領域ではありません。ボーダーゲートウェイプロトコルは、現在、既存の要件を満たすため、十分にIETFによって受信されることはありません広告を出したルートの増加を生成する追加機能を追加することで緊張しています。ドメイン間ルーティングの解説のための[38]を参照してください。
This topic involves work that has been done in trying to compensate for lossy networks providing best effort service. In particular, we focus on the use of a) Forward Error Correction (FEC), and b) redundant transmissions that can be used to compensate for lost data packets. (Note that our aim is fault tolerance, as opposed to an expectation of always achieving it.)
このトピックでは、ベストエフォート型のサービスを提供する非可逆のネットワークを補うためにしようとして行われている作業を必要とします。特に、我々は）前方誤り訂正（FEC）の使用に焦点を当てると、b）を使用することができる冗長送信が失われたデータパケットを補償します。 （常にそれを達成するための期待とは対照的に、私たちの目的は、耐障害性であることに注意してください。）
In the former case, additional FEC data packets are constructed from a set of original data packets and inserted into the end-to-end stream. Depending on the algorithm used, these FEC packets can reconstruct one or more of the original set that were lost by the network. An example may be in the form of a 10:3 ratio, in which 10 original packets are used to generate three additional FEC packets. Thus, if the network loses 30% of packets or less, then the FEC scheme will be able to compensate for that loss. The drawback to this approach is that, to compensate for the loss, a steady state increase in offered load has been injected into the network. This makes an argument that the act of protection against loss has contributed to additional pressures leading to congestion, which in turn helps trigger packet loss. In addition, by using a ratio of 10:3, the source (or some proxy) must "hold" all 10 packets in order to construct the three FEC packets. This contributes to the end-to-end delay of the packets, as well as minor bursts of load, in addition to changes in jitter.
前者の場合、追加のFECデータ・パケットは、元のデータ・パケットのセットから構成され、エンドツーエンド・ストリームに挿入されます。使用されるアルゴリズムによっては、これらのFECパケットがネットワークによって失われたオリジナルのセットの1つまたは複数を再構築することができます。 10元のパケットは、3つの追加のFECパケットを生成するために使用される3比、実施例10の形態であってもよいです。ネットワークパケット以下の30％を失った場合したがって、その後FECスキームは、その損失を補償することができるであろう。このアプローチの欠点は、提供された負荷において定常状態増加がネットワークに注入された、損失を補償することです。これは損失に対する保護の行為が順番にトリガーパケットロスを助け渋滞につながる追加の圧力に貢献してきた引数になります。加えて、10の比率使用して：3を、ソース（またはプロキシ）は、3つのFECパケットを構築するために、すべての10個のパケットを「保持」しなければなりません。これは、ジッタの変化に加えて、エンド・ツー・エンドのパケットの遅延だけでなく、負荷のマイナーバーストに貢献しています。
The other form of fault tolerance we discuss involves the use of redundant transmissions. By this we mean the case in which an original data packet is followed by one or more redundant packets. At first glance, this would appear to be even less friendly to the network than that of adding FEC packets. However, the encodings of the redundant packets can be of a different type (or even transcoded into a lower quality) that produce redundant data packets that are significantly smaller than the original packet.
私たちが議論するフォールトトレランスの他の形式は、冗長送信の使用を含みます。これによって我々は、元のデータパケットは、1つの以上の冗長パケットが続いた場合を意味します。一見すると、これはFECパケットを追加するよりもネットワークにさえあまり友好的であるように思われます。しかし、冗長パケットの符号化は、元のパケットよりも著しく小さい冗長データパケットを生成する異なるタイプ（又はより低い品質にトランスコード）とすることができます。
Two RFCs [22, 23] have been produced that define RTP payloads for FEC and redundant audio data. An implementation example of a redundant audio application can be found in [13]. We note that both FEC and redundant transmissions can be viewed as rather specific, and to a degree tangential, solutions regarding packet loss and emergency communications. Hence, these topics are placed under the category of value-added objectives.
FEC冗長オーディオデータのためのRTPペイロードを定義する2つのRFC [22、23]製造されてきました。冗長オーディオ・アプリケーションの実施例は、[13]に見出すことができます。私たちは、パケット損失や緊急通信に関するソリューション、FEC冗長両方の送信はとしてではなく、特定見ることができることに注意してください、と接線程度に。したがって、これらのトピックは、付加価値の目的のカテゴリの下に置かれています。
There are various scenarios in which IP telephony can be realized, each of which can imply a unique set of functional requirements that may include just a subset of those listed above. We acknowledge that a scenario may exist whose functional requirements are not listed above. Our intention is not to consider every possible scenario by which support for emergency related IP telephony can be realized. Rather, we narrow our scope using a single guideline; we assume there is a signaling and data interaction between the PSTN and the IP network with respect to supporting emergency-related telephony traffic. We stress that this does not preclude an IP-only end-to-end model, but rather the inclusion of the PSTN expands the problem space and includes the current dominant form of voice communication.
上記に列挙したもののサブセットのみを含むことができる機能要件の固有のセットを意味することができるそれぞれがIP電話を実現することができるさまざまなシナリオがあります。私たちは、シナリオがその機能要件上記記載されていない存在する可能性があることを認めています。我々の意図を実現することができる緊急に関連するIPテレフォニーのためにサポートすることにより、すべての可能なシナリオを考慮することはありません。むしろ、我々は、単一のガイドラインを使用して私たちの範囲を狭めます。私たちは、PSTNと緊急関連の電話トラフィックをサポートに関しては、IPネットワークとの間のシグナリングおよびデータ相互作用があると仮定します。これはIPのみのエンドツーエンドモデルを排除するものではないことを強調ではなく、PSTNを含めることは、問題空間を拡大し、音声通信の現在の支配的な形を含んでいます。
Note: as stated in Section 1.2, [32] provides a more extensive set of scenarios in which IP telephony can be deployed. Our selected set below is only meant to provide a couple of examples of how the protocols and capabilities presented in Section 3 can play a role.
注：1.2節で述べたように、[32] IP電話を展開することができるシナリオのより広範なセットを提供します。私たちの選択は第3節で提示したプロトコルと機能が役割を果たすことができる方法の例をいくつか提供することを意図している以下の設定します。
This scenario is a direct reflection of the evolution of the PSTN. Specifically, we refer to the case in which data networks have emerged in various degrees as a backbone infrastructure connecting PSTN switches at its edges. This scenario represents a single isolated IP administrative domain that has no directly adjacent IP domains connected to it. We show an example of this scenario below in Figure 1. In this example, we show two types of telephony carriers. One is the legacy carrier, whose infrastructure retains the classic switching architecture attributed to the PSTN. The other is the next generation carrier, which uses a data network (e.g., IP) as its core infrastructure, and Signaling Gateways at its edges. These gateways "speak" SS7 externally with peering carriers, and another protocol (e.g., SIP) internally, which rides on top of the IP infrastructure.
このシナリオでは、PSTNの進化を直接反映しています。具体的には、データ・ネットワークは、その縁部にPSTNスイッチを接続するバックボーンインフラとして様々な程度に現れている場合を指します。このシナリオでは、それに接続されていない直接隣接IPドメインを有する単一の単離されたIP管理ドメインを表します。我々は、電話キャリアの2種類を示し、この例では、図1に、以下のこのシナリオの例を示しています。一つは、そのインフラPSTNに起因する古典的なスイッチング・アーキテクチャを保持レガシーキャリアです。もう一つは、その端部でそのコアインフラストラクチャのようなデータネットワーク（例えば、IP）を使用する次世代のキャリア、およびシグナリングゲートウェイです。これらのゲートウェイは、IPインフラストラクチャの上に乗っており、内部ピアリング担体と外部SS7を「話す」、および他のプロトコル（例えば、SIP）。
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * ISUP * *
SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
* * (SS7) * (SIP) * (SS7) * (SIP) *
******* *************** **************
SW - Telco Switch, SG - Signaling Gateway
SW - telcoスイッチ、SG - シグナリングゲートウェイ
Figure 1
図1
The significant aspect of this scenario is that all the resources f each IP "island" falls within a given administrative authority. Hence, there is not a problem in retaining PSTN type QoS for voice traffic (data and signaling) exiting the IP network. Thus, the need for support of mechanisms like diff-serv in the presence of overprovisioning, and an expansion of the defined set of Per-Hop Behaviors, is reduced under this scenario.
このシナリオの重要な側面は、各IP「島」Fすべてのリソースが与えられた職務権限内にあるということです。従って、IPネットワークを出る音声トラフィック（データ及びシグナリング）のためのPSTNタイプのQoSを維持するに問題がありません。したがって、オーバープロビジョニングの存在下でのdiff-SERV、およびホップ単位動作の定義された一連の膨張等のメカニズムのサポートの必要性は、このシナリオの下で低減されます。
Another function that has little or no importance within the closed IP environment of Figure 1 is that of IP security. The fact that each administrative domain peers with each other as part of the PSTN, means that existing security, in the form of Personal Identification Number (PIN) authentication (under the context of telephony infrastructure protection), is the default scope of security. We do not claim that the reliance on a PIN-based security system is highly secure or even desirable. But, we use this system as a default mechanism in order to avoid placing additional requirements on existing authorized emergency telephony systems.
図1のクローズドIP環境内ほとんど、あるいはまったく重要性を持っている別の機能は、IPセキュリティのことです。 PSTNの一部として互いにそれぞれの管理ドメインのピアは、（テレフォニーインフラストラクチャ保護の文脈の下で）個人識別番号（PIN）認証の形で、セキュリティを既存の、セキュリティのデフォルトの範囲であることを意味しているという事実。私たちは、PINベースのセキュリティシステムへの依存度が非常に安全な、あるいは望ましいと主張しません。しかし、我々は、既存の承認済みの緊急電話システムに追加の要件を配置しないようにするために、デフォルトのメカニズムとして、このシステムを使用しています。
We view the scenario of multiple IP administrative domains as a superset of the previous scenario. Specifically, we retain the notion that the IP telephony system peers with the existing PSTN. In addition, segments (i.e., portions of the Internet) may exchange signaling with other IP administrative domains via non-PSTN signaling protocols like SIP.
私たちは前のシナリオのスーパーセットとして複数のIP管理ドメインのシナリオを表示します。具体的には、IPテレフォニーシステムは、既存のPSTNとピアという概念を保持しています。また、セグメント（インターネットのすなわち、部分）SIPなどの非PSTNのシグナリングプロトコルを介して他のIP管理ドメインとシグナリングを交換することができます。
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * * *
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) *
******* *************** **************
SW - Telco Switch
SG - Signaling Gateway
Figure 2
図2
Given multiple IP domains, and the presumption that SLAs relating to ETS traffic may exist between them, the need for something like diff-serv grows with respect to being able to distinguish the emergency related traffic from other types of traffic. In addition, IP security becomes more important between domains in order to ensure that the act of distinguishing ETS-type traffic is indeed valid for the given source.
複数のIPドメイン、およびETSトラフィックに関連するSLAは、それらの間に存在する可能性が推定を考えると、差分-SERVのようなものの必要性は、他のタイプのトラフィックからの緊急関連のトラフィックを区別することができることに関連して成長します。また、IPセキュリティは、ETS-タイプのトラフィックを区別するという行為が実際に与えられたソースのために有効であることを確実にするために、ドメイン間でより重要になります。
We conclude this section by mentioning a complementary work in progress in providing ISUP transparency across SS7-SIP interworking [33]. The objective of this effort is to access services in the SIP network and yet maintain transparency of end-to-end PSTN services.
我々は、SS7-SIPインターワーキング[33]を横切っISUP透過性を提供している進行中の相補的な作業を言及することにより、このセクションを終えます。この取り組みの目的は、SIPネットワーク内のサービスにアクセスして、まだエンドツーエンドのPSTNサービスの透明性を維持することです。
Not all services are mapped (as per the design goals of [33]), so we anticipate the need for an additional document to specify the mapping between new SIP labels and existing PSTN code points like NS/EP and MLPP.
すべてのサービスは、（[33]の設計目標どおり）マッピングされたので、私たちは新しいSIPラベルおよびNS / EPとMLPPなどの既存のPSTNのコードポイント間のマッピングを指定するための追加の文書のための必要性を予測しているわけではありません。
Information on this topic is presented in sections 2 and 4.
このトピックの情報はセクション2と4に示されています。
[1] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[1]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[2]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[3] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[3] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[4] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[4] Wroclawski、J.、RFC 2211 "制御負荷ネットワーク要素サービスの仕様"、1997年9月。
[5] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[5]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[6]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[7]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[8]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[9] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[9]シャルマ、V.とF. Hellstrand、RFC 3469、2003月 "マルチプロトコルラベルスイッチング（MPLS）のためのフレームワークは、回復ベース"。
[10] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[10] Kille、S.、 "MIXER（MIMEインターネットX.400拡張リレー）：X.400およびRFC 822 / MIMEの間のマッピング"、RFC 2156、1998年1月。
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[11]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[12] ANSI, "Signaling System No. 7(SS7), High Probability of Completion (HPC) Network Capability", ANSI T1.631-1993, (R1999).
[12] ANSI、 "信号システム第7号（SS7）、完了（HPC）ネットワーク能力の高い確率"、ANSI T1.631-1993（R1999）。
[13] Robust Audio Tool (RAT): http://www-mice.cs.ucl.ac.uk/multimedia/software/rat
[13]強力なオーディオツール（RAT）：http://www-mice.cs.ucl.ac.uk/multimedia/software/rat
[14] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[14] Schulzrinneと、H.、RFC 3487 "セッション開始プロトコル（SIP）のためのリソースプライオリティメカニズムのための要件"、2003年2月。
[15] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[15]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.ブラック、RFC 2474、1998年12月 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"。
[16] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[16]ダラム、D.、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.、およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[17] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[17]ローゼンバーグ、J.、およびH. Schulzrinneと、 "IP上テレフォニールーティングの枠組み"、RFC 2871、2000年6月。
[18] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[18] Heinanen、J.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[19] ITU, "Multi-Level Precedence and Preemption Service, ITU, Recommendation, I.255.3, July, 1990.
[19] ITU、「マルチレベル優先順位および優先処理サービス、ITU、勧告、I.255.3、1990年7月。
[20] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[20]ローゼンバーグ、J.、サラマ、H.、およびM.スクワイア、 "オーバーIPテレフォニールーティング（TRIP）"、RFC 3219、2002年1月。
[21] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[21]グローブ、C.、パンタレオ、M.、アンダーソン、T.、およびT.テイラー、 "ゲートウェイ制御プロトコルバージョン1"、RFC 3525、2003年6月。
[22] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[22]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[23]ローゼンバーグ、J.とH. Schulzrinne、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"、RFC 2733、1999年12月。
[24] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113- 2000, 2000.
[24] ANSI、 "信号システム第7号、ISDNユーザ部"、ANSI T1.113- 2000、2000。
[25] "Description of an International Emergency Preference Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002
[25] "国際緊急優先スキームの説明（IEPS）"、ITU-T勧告E.106 2002年3月
[26] Carlberg, K., "The Classifier Extension Header for RTP", Work In Progress, October 2001.
[26]カールバーグ氏、K.、 "RTPのための分類子拡張ヘッダ"、進歩、2001年10月で働いています。
[27] National Communications System: http://www.ncs.gov
[27]ナショナル・通信システム：http://www.ncs.gov
[28] Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, IETF Presentation: IPPM-Voiceip, Aug, 1997
[28] Bansal氏、R.、Ravikanth、R.、 "IP上の声のパフォーマンス対策"、http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/、IETFプレゼンテーション：IPPM- Voiceip、8月、1997
[29] Hardman, V., et al, "Reliable Audio for Use over the Internet", Proceedings, INET'95, Aug, 1995.
[29]ハードマン、V.ら、 "信頼性の高いインターネット上での使用のためのオーディオ"、議事録、INET'95、8月、1995。
[30] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[30] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィック過剰性能MPLSのための要件"、RFC 2702、1999年9月。
[31] "Service Class Designations for H.323 Calls", ITU Recommendation H.460.4, November, 2002.
[31] 2002年11月、ITU勧告H.460.4、 "H.323のためのサービスクラスの指定はコール"。
[32] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[32] Awduche、D.、チウ、A.、Elwalid、A.、Widjaja、I.、およびX.シャオ、 "インターネットトラフィックエンジニアリングの概要と原則"、RFC 3272、2002年5月。
[33] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[33] Vemuri、A.および "電話用のセッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ" J.ピーターソン、BCP 63、RFC 3372、2002年9月。
[34] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology", RFC 3523, April 2003.
[34]ポーク、J.、 "インターネット防災（IEPREP）テレフォニートポロジ用語"、RFC 3523、2003年4月。
[35] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[35]カールバーグ氏、K.とR.アトキンソン、RFC 3689、2004年2月 "緊急通信サービス（ETS）の一般的な要件"。
[36] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004.
[36]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービス（ETS）のためのIPテレフォニーの要件"、RFC 3690、2004年2月。
[37] Meyers, D., "Some Thoughts on CoS and Backbone Networks" http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf IETF Presentation: IEPREP, Dec, 2002.
[37]マイヤーズ、D.、 "CoSおよびバックボーンネットワーク上のいくつかの考えが" http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf IETFプレゼンテーション：IEPREP、12月、2002。
[38] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[38]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[39] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[39] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[40] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[40]デイビー、B.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、「アン緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[41] ITU, "Gateway Control Protocol", Version 3, ITU, September, 2005.
[41] ITU、 "ゲートウェイ制御プロトコル"、バージョン3、ITU、2005年9月。
[42] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B., and J. Segers, "Megaco Protocol version 0.8", RFC 2885, August 2000.
[42]クエルボ、F.、グリーン、N.、のHuitema、C.、Rayhan、A.、ローゼン、B.、およびJ. Segers、 "Megacoのプロトコルバージョン0.8"、RFC 2885、2000年8月。
[43] Taylor, T., "Megaco Errata", RFC 2886, August 2000.
[43]テイラー、T.、 "Megacoの正誤表"、RFC 2886、2000年8月。
Appendix A: Government Telephone Preference Scheme (GTPS)
付録A：政府電話優先スキーム（GTPS）
This framework document uses the T1.631 and ITU IEPS standard as a target model for defining a framework for supporting authorized emergency-related communication within the context of IP telephony. We also use GETS as a helpful model from which to draw experience. We take this position because of the various areas that must be considered; from the application layer to the (inter)network layer, in addition to policy, security (authorized access), and traffic engineering.
このフレームワークドキュメントは、IPテレフォニーのコンテキスト内で許可緊急関連の通信をサポートするためのフレームワークを定義するためのターゲットモデルとしてT1.631およびITU IEPS標準を使用しています。また、経験を描画するから有用なモデルとしてGETS使用します。私たちは、理由は考慮されなければならない様々な分野のこの位置を取ります。 （インター）ネットワーク層にアプリケーション層から、ポリシー、セキュリティ（権限のアクセス）、およびトラフィックエンジニアリングに加えてインチ
The U.K. has a different type of authorized use of telephony services, referred to as the Government Telephone Preference Scheme (GTPS). At present, GTPS only applies to a subset of the local loop lines within the UK. The lines are divided into Categories 1, 2, and 3. The first two categories involve authorized personnel involved in emergencies such as natural disasters. Category 3 identifies the general public. Priority marks, via C7/NUP, are used to bypass call-gapping for a given Category. The authority to activate GTPS has been extended to either a central or delegated authority.
U.K.は政府電話優先スキーム（GTPS）と呼ばれる電話サービスの認可使用の異なる種類があります。現在のところ、GTPSは、英国内のローカルループ線のサブセットに適用されます。線はカテゴリ1、2に分割され、前記第1の2つのカテゴリが、このような自然災害などの緊急事態に関与する関係者が関与しています。カテゴリー3は、一般市民を識別します。優先マークは、C7 / NUPを経由して、特定のカテゴリのコールギャッピングバイパスするために使用されています。 GTPSをアクティブにする権限は、いずれかの中央または委任された権限に拡張されました。
A.1. GTPS and the Framework Document
A.1。 GTPSとフレームワークのドキュメント
The design of the current GTPS, with its designation of preference based on physical static devices, precludes the need for several aspects presented in this document. However, one component that can have a direct correlation is the labeling capability of the proposed Resource Priority extension to SIP. A new label mechanism for SIP could allow a transparent interoperation between IP telephony and the U.K. PSTN that supports GTPS.
現在GTPSの設計は、物理的な静的デバイスに基づいて好みのその指定して、この文書のいくつかの側面の必要性を排除します。しかし、直接的な相関関係を持つことができる一つの成分は、SIPへの提案リソースプライオリティ延長のラベリング機能です。 SIPのための新しいラベルのメカニズムは、IPテレフォニーとGTPSをサポートU.K.のPSTNとの間に透明の相互運用を可能性があります。
Appendix B: Related Standards Work
付録B：関連規格仕事
The process of defining various labels to distinguish calls has been, and continues to be, pursued in other standards groups. As mentioned in Section 1.1.1, the ANSI T1S1 group has previously defined a label in the SS7 ISUP Initial Address Message. This single label or value is referred to as the National Security and Emergency Preparedness (NS/EP) indicator and is part of the T1.631 standard. The following subsections presents a snapshot of parallel, on-going efforts in various standards groups.
呼び出しを区別するために、様々なラベルを定義するプロセスはされて、とされ続け、他の標準グループで追求してきました。 1.1.1項で述べたように、ANSI T1S1グループは、以前SS7 ISUP初期アドレスメッセージにラベルを定義しています。この単一のラベルまたは値は、国家安全保障と防災（NS / EP）の指標と呼ばれ、T1.631標準の一部です。以下のサブセクションでは、進行中の様々な標準化グループでの取り組み並列のスナップショットを提示します。
It is important to note that the recent activity in other groups have gravitated to defining 5 labels or levels of priority. The impact of this approach is minimal in relation to this ETS framework document because it simply generates a need to define a set of corresponding labels for the resource priority header of SIP.
他のグループの最近の活動は5枚のラベルや優先順位のレベルを定義するに引き寄せていることに注意することが重要です。それは単にSIPのリソース優先順位ヘッダの対応するラベルのセットを定義する必要が発生するので、このアプローチの影響は、このETSフレームワーク文書に関して最小です。
B.1. Study Group 16 (ITU)
B.1。研究会16（ITU）
Study Group 16 (SG16) of the ITU is responsible for studies relating to multimedia service definition and multimedia systems, including protocols and signal processing.
ITUの研究グループ16（SG16）は、マルチメディアサービスの定義とプロトコルや信号処理などのマルチメディアシステム、に関する研究を担当しています。
A contribution [31] has been accepted by this group that adds a Priority Class parameter to the call establishment messages of H.323. This class is further divided into two parts; one for Priority Value and the other is a Priority Extension for indicating subclasses. It is this former part that roughly corresponds to the labels transported via the Resource Priority field for SIP [14].
貢献[31]はH.323の呼設定メッセージに優先クラスのパラメータを追加し、このグループによって受け入れられてきました。このクラスは、さらに2つの部分に分割されます。プライオリティ値および他のための1つのサブクラスを示すための優先順位の拡張機能です。それはおおよそSIP [14]のための資源優先度のフィールドを介して搬送ラベルに対応し、この前半部です。
The draft recommendation advocates defining PriorityClass information that would be carried in the GenericData parameter in the H323-UU-PDU or RAS messages. The GenericData parameter contains PriorityClassGenericData. The PriorityClassInfo of the PriorityClassGenericData contains the Priority and Priority Extension fields.
H323-UU-PDUまたはRASメッセージにGenericDataパラメータで搬送されるPriorityClass情報を定義勧告案を提唱しています。 GenericDataパラメータはPriorityClassGenericDataが含まれています。 PriorityClassGenericDataのPriorityClassInfoは、優先度と優先順位拡張フィールドが含まれています。
At present, 4 levels have been defined for the Priority Value part of the Priority Class parameter: Normal, High, Emergency-Public, Emergency-Authorized. An additional 8-bit priority extension has been defined to provide for subclasses of service at each priority.
現時点では、4つのレベルは、優先クラスのパラメータのプライオリティ値の一部のために定義されています：ノーマル、ハイ、緊急公開、緊急時には、認定します。追加の8ビットの優先拡張子は各優先順位のサービスのサブクラスを提供するために定義されています。
The suggested ASN.1 definition of the service class is the following:
サービスクラスの提案ASN.1定義は次のとおりであります：
CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)}
DEFINITIONS AUTOMATIC TAGS::=
BEGIN IMPORTS ClearToken, CryptoToken FROM H235-SECURITY-MESSAGES;
H235-SECURITY-MESSAGESからの輸入ClearToken、CryptoTokenをBEGIN;
CallPriorityInfo::= SEQUENCE
{
priorityValue CHOICE
{
emergencyAuthorized NULL,
emergencyPublic NULL,
high NULL,
normal NULL,
...
},
priorityExtension INTEGER (0..255) OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoToken OPTIONAL, rejectReason CHOICE { priorityUnavailable NULL, priorityUnauthorized NULL, priorityValueUnknown NULL, ... } OPTIONAL, -- Only used in CallPriorityConfirm ... }
priorityExtension INTEGER（0..255）OPTIONAL、ClearToken OPTIONALのシーケンスをトークンCryptoToken OPTIONALのシーケンスをcryptoTokens、rejectReason CHOICE {priorityUnavailable NULL、NULL priorityUnauthorized、priorityValueUnknown NULL、...} OPTIONAL、 - のみCallPriorityConfirmに使用...}
The advantage of using the GenericData parameter is that an existing parameter is used, as opposed to defining a new parameter and causing subsequent changes in existing H.323/H.225 documents.
新しいパラメータを定義し、既存のH.323 / H.225文書のその後の変化を引き起こすとは対照的にGenericDataパラメータを使用することの利点は、既存のパラメータを使用することです。
Acknowledgements
謝辞
The authors would like to acknowledge the helpful comments, opinions, and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran Atkinson as well as those comments received from the IEPS and IEPREP mailing lists. Additional thanks to Peter Walker of Oftel for private discussions on the operation of GTPS, and Gary Thom on clarifications of the SG16 draft contribution.
著者らはスチューゴールドマン、ジェームズ・ポーク、デニス・ベルクの有益なコメント、意見、と明確化を承認したいと思い、アトキンソンだけでなく、IEPSとIEPREPメーリングリストから受け取ったそれらのコメントを実行しました。 SG16ドラフト貢献の明確化にGTPS、とゲイリー・トムの操作上のプライベートな議論のためのOFTELのピーター・ウォーカーへの追加のおかげ。
Authors' Addresses
著者のアドレス
Ken Carlberg University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
コンピュータサイエンスガウアーストリートロンドン、WC1E 6BTイギリスのケン・カールバーグロンドン大学学部
EMail: k.carlberg@cs.ucl.ac.uk
メールアドレス：k.carlberg@cs.ucl.ac.uk
Ian Brown University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
イアン・ブラウン大学コンピュータサイエンスガウアーストリートロンドン、WC1E 6BTイギリスのカレッジ・ロンドン学科
EMail: I.Brown@cs.ucl.ac.uk
メールアドレス：I.Brown@cs.ucl.ac.uk
Cory Beard University of Missouri-Kansas City Division of Computer Science Electrical Engineering 5100 Rockhill Road Kansas City, MO 64110-2499 USA
コンピュータサイエンス電気工学のミズーリ州、カンザスシティ課5100ロックヒル道路カンザスシティ、MO 64110から2499アメリカのコーリーあごひげ大学
EMail: BeardC@umkc.edu
メールアドレス：BeardC@umkc.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。