[要約] RFC 4190は、IP電話における緊急通信サービス（ETS）をサポートするためのフレームワークを提供しています。このRFCの目的は、IPベースの通信システムで緊急通信サービスを効果的に提供するためのガイドラインを提供することです。
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
IPテレフォニーで緊急通信サービス（ETS）をサポートするためのフレームワーク
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).
Copyright（c）The Internet Society（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テレフォニーのコンテキスト内で、認定された緊急関連のコミュニケーションをサポートするためのフレームワークを提示します。今日のIPアーキテクチャおよびサービスモデル内で、緊急通信サービス（ETS）に沿った承認された緊急サービスの一般的な見解を反映する一連の目的を提示します。これらの目的から、対応する一連のプロトコルと機能を提示します。これは、既存の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は主にドメイン内パスに制約されており、せいぜいStubドメインによる特定のタイプのトラフィック（音声やビデオなど）の孤立した「島」の予約に似ています。。[5]および[6]は、おそらくインターネットサービスプロバイダー（ISP）とおそらくいくつかのドメイン間パスの追加の展開に貢献するでしょうが、間のエンドツーエンドの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は[7]を作成し、差別化されたサービスのアーキテクチャを提示しました（diff-serv）。この取り組みは、[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.
新しいサービスモデルの導入における1つの定数は、デフォルトのサービスモデルとしての最善の努力の指定です。トラフィックがDiff-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が経験した追加のトラフィック負荷の継続的なペースは、ドメイン内の交通工学を非常に重要にし続けています。Multi-Protocolラベルスイッチング（MPLS）の分野で生成されたドラフトとRFCの形でのIETF貢献の爆発は、ドメイン内交通工学の汎用性と管理可能なメカニズムへの関心を例示しています。興味深い観察の1つは、QoS関連のトラフィックエンジニアリングのサポートに関与する作業です。具体的には、差別化されたサービスのMPLSサポート[8]と、MPLSのルーティング障害の高速帯域幅回復を含める継続的な研究[9]を参照します。
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テレフォニーの出現を考えると、そのサービスを自然に含めることは、既存の緊急関連サービスをサポートする能力です。通常、緊急電話を米国の「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、国防総省、連邦緊急事態管理局など、さまざまな政府機関から来ています（いくつかの例を挙げると）。さらに、重要なインフラ回復運用に関与する民間産業（通信会社、ユーティリティなど）の選択された個人のセットも、Getへのアクセスを提供されます。
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.
GETの目的は、ハリケーン、地震、その他の災害などの緊急時に、選択された認定担当者が電話サービスを利用できる可能性を高めることです。）米国では、一般の人々によって電話ネットワークを切り替えました。
GETS is based in part on the ANSI T1.631 standard, specifying a High Probability of Completion (HPC) for SS7 signaling [12][24].
GETSは、ANSI T1.631標準に一部基づいており、SS7シグナル伝達[12] [24]の完了（HPC）の高い確率（HPC）を指定しています。
[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テレフォニーとVoice over IPのコンテキスト内で、ETSの近くおよび中期的なサポートに集中しています。IPテレフォニーをVoIPのサブセットとして扱うことにより、これら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パケットをユニキャスト（またはマルチキャスト）宛先に送信し始めるときです。ラットは、SIPのような明示的なシグナル伝達を使用して、2人のユーザー間でエンドツーエンドの呼び出しを確立しません。データパケットをターゲット宛先に送信するだけです。一方、「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テレフォニーに存在すると仮定するもう1つの側面は、セッションまたはフローあたりの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とテレフォニーキャリアのフレームワークを提供することです。さらに、期待を制約するために、潜在的な顧客に基準点を提供したいと考えています。特に、現在PSTNで利用可能な既存の緊急音声サービスの正確な機能をIPおよびインターネットの緊急音声サービスの正確な機能を再現しようとする誘惑を避けたいと考えています。他に何もなければ、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以下の「BIT」、その他の特定のテクノロジー、および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.
ソリューションを生成したり、既存のプロトコルとメカニズムを調べたりする場合、考慮すべきことがいくつかあります。1つは、ドメイン間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.
考慮すべきもう1つの側面は、緊急関連の通信をサポートする他の標準団体からの既存のアーキテクチャとプロトコルがあることです。おそらくゲートウェイまたはIETFプロトコルを使用した同様のタイプのノードを介して、これらのシステムと相互運用する努力は、ETSフローを他のフローと区別する必要性を促進します。理由の1つは、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]の要件を考慮します。むしろ、セクション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パケットのDiff-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値の3番目のセットは、ローカルまたは実験的使用のために確保されますが、最初のセットが完全に割り当てられた場合、後に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メーリングリストで説明されているアプローチの1つは、緊急関連のフローの新しいホップごとの動作（PHB）の仕様です。このアイデアの背後にある理論的根拠は、さまざまな緊急関連トラフィックで特定のコードポイントを定義できるベースラインを提供するということです。認可された緊急セッション（ET、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.
近い条件では、最初に、他の種類のフローから緊急交通を区別するために、Assured Forwarding（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.
加重公正キューイングやクラスベースのキューイングなどのスケジューリングメカニズムは、すべてのキューがバックログされた場合に各クラスに使用される出力リンク帯域幅の割合を指定するために使用されます。したがって、その目的は、各クラスが経験するレートと遅延を管理することです。しかし、緊急交通は必ずしもQOが非緊急交通とより良いまたは異なるパフォーマンスを必要とするとは限りません。次のホップに転送される可能性が高い場合があります。これは、クラス内で優先順位を落とすだけで達成できます。
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の新しい形式の1つは、今日使用されている単一の平均マルチプルしきい値アプローチの代わりに、複数の平均測量閾値アプローチである可能性があります。これにより、各ドロップの優先順位のキュー内のパケットの数を個別にカウントすることに基づいて、ドロップ確率を作成できます。
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つのドロップの優先順位を区別する必要がある場合があります。その場合、より多くのドロップの優先順位を実装できます。また、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では、Dif-Servアーキテクチャのコンテキストの下で緊急事態のデータパケットをマークする1つの手段について説明しました。ただし、特定のPHBのDiff-Servマーキングはグローバルに一意ではなく、中間ノードまたはドメインによってarbitrarily意的に除去または変更される可能性があることも指摘しました。したがって、緊急関連のデータパケットに関して、エンドツーエンドベースで一定のままであるデータパケットのバンド内のマーキングがまだ欠落しています。
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.
データパケットの永続的なマーキングを定義することには3つの選択肢があり、したがって、Diff-Servコードポイントの一時的なマーキングを回避します。4.1.2で説明されているように、緊急タイプトラフィックに専念する新しいPHBを提案できます。IPの上のある場所で新しいShim層プロトコルの仕様を提案できます。または、既存のアプリケーションレイヤープロトコルに新しい仕様を追加できます。最初の2つのケースはおそらく「最もクリーンな」建築的ですが、限られた数の違いコードポイントと、さらに別のシム層がIPスタックを大きくするという競合のために通過することはできない長期的な努力です。。3番目のケースでは、アプリケーションレイヤーパケットにマーキングを配置することにも欠点があります。重要な弱点は、アプリケーションごとにマーキングの仕様です。
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の増強に関するオーディオ/Visual Transport（AVT）ワーキンググループで議論が行われているため、緊急関連のトラフィックを区別しないマーキングを運ぶことができます。具体的には、これらの議論は、パケットに関連する条件を示す「分類器」フィールドを含む新しい拡張機能を定義することに集中しました（例：認定緊急事態、緊急、正常）[26]。このアイデアの背後にある理論的根拠は、RTPに焦点を当てることで、カプセル化するすべてのペイロードに適用される集約点に依存することができるということでした。ただし、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]は、ITU-T推奨H.248 [41]を含む一般的なテキストの更新バージョンと見なされており、RFC 2886（Megaco errata）[43]の変更をRFC 2885（メガコプロトコルのテキストに適用した結果です。バージョン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にリストされている目的の1つは、ETSシグナル伝達と関連するデータトラフィックを、本質的に非領土として扱うことです。さらに、この処理は、操作またはサービスのデフォルトモードになることです。これは、SLAの確立を管理する特定の国の既存の規制または法律が、先制措置を許可しない可能性があることが認識されています（例えば、既存の電話フローの削除）。一方、SLAの仕様に影響を与える他の国の法律と規制は、先制を許可するか、その存在を必要とする場合さえあります。この格差を考えると、緊急関連のトラフィックが特定のネットワークまたは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.
ポリシーは、さまざまなコンポーネント（たとえば、SIPサーバーや帯域幅ブローカーなど）に埋め込まれた静的情報の形で、またはドメインのリソースの割り当てに関してCOPを介して実現およびサポートすることができます[16]。ポリシーがどのように達成されるかについては、要件はありません。代わりに、ドメインが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.
ETSベースのトラフィックに関する1つ以上のSLAの制約の下でネットワークが動作する場合、何らかの形のトラフィックエンジニアリングがネットワークの動作に適用されることが予想されます。どのタイプのトラフィックエンジニアリングメカニズムが使用されているかについては推奨しませんが、そのようなシステムは何らかの形で存在し、ETSシグナルおよび/またはデータトラフィックを区別およびサポートできることを推奨しません。ETS Serviceのクライアントと将来のプロバイダーによる[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]は、潜在的に劇的なスパイクまたはトラフィック負荷のバーストを満たすために、コア内での大量の過剰吸収に依存している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がGetSサービスのために確立した既存のSLAは、HPCを使用して特定のLECを通じて確立されるコールの1％〜10％の緩やかに定義された最大割り当てに焦点を当てる傾向があります。ETS関連のISPSのSLAは、緊急関連であると区別され、認定ユーザーによって開始されることに関して、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リンクでは、1つのGBPSイーサネット、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固有のユーザー認証サポートはほとんど必要ありません。ユーザーは、通常どおりPSTNに認証されます。たとえば、米国でピンを使用します。PSTN接続からBackbone IPネットワークへのゲートウェイは、フローに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.
ETSサポートがドメイン内のPSTNおよびIPネットワークからドメイン間のエンドツーエンドIPへの移動の移動を行うと、特定のフローの承認がより複雑になります。ユーザーのアクセスネットワークは、ネットワーク層の優先順位がその時点で提供される場合、ユーザーの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テレフォニートラフィックをルーティングし、それらを回避する能力が含まれます。理想的には、発見プロセスは便宜的な方法で達成されます（おそらくその存在の必要性の先験的なものでさえ）。このレベルでは、代替パスがどのように達成されるか、あるいはそれが達成されるレイヤー、例えばネットワーク対アプリケーション層についてさえ、仮定しません。しかし、少なくとも最小限の形では、この種の能力は、非合わせた代替パスを使用することにより、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つの追加領域を特定できます。これは、コールシグナリングの特定のケースの代替パスを提供するのに役立ちます。1つ目は[9]です。これは、ネットワークレイヤールーティングに焦点を当てており、MPLSのLDP仕様を強化するためのフレームワークを説明して、フォールトトレランスを実現するのに役立ちます。これ自体は、代替パスルーティングを提供するのではなく、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.
2番目の取り組みは、IPテレフォニーワーキンググループから来ており、IP（TRIP）を介したテレフォニールーティングが含まれます。これまで、フレームワークドキュメント[17]は、プロバイダー間のIPテレフォニーゲートウェイルーティングテーブルの発見と交換を説明するRFCとして公開されています。Trip Protocol [20]は、使用されているシグナリングプロトコル（SIPまたはH.323など）に関係なく、アプリケーションレベルテレフォニールーティングを指定します。旅行は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の追加の代替パスルーティングサポートの観点から考慮すべき領域ではありません。Border Gatewayプロトコルは現在、既存の要件を満たす際に緊張しているため、広告されたルートの増加を生成する追加機能を追加することは、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.)
このトピックには、最良の努力サービスを提供する損失のあるネットワークを補償しようとする際に行われた作業が含まれます。特に、a）順方向エラー補正（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の比率の形であり、そこでは10個の元のパケットを使用して3つの追加のFECパケットを生成します。したがって、ネットワークがパケットの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管理ドメインを表します。このシナリオの例を図1に示します。この例では、2種類のテレフォニーキャリアを示します。1つはレガシーキャリアで、そのインフラストラクチャはPSTNに起因する古典的なスイッチングアーキテクチャを保持しています。もう1つは次世代のキャリアで、データネットワーク（IPなど）をコアインフラストラクチャとして使用し、そのエッジでのシグナリングゲートウェイを使用します。これらのゲートウェイは、ピアリングキャリアと内部的に別のプロトコル（たとえば、SIP）を使用して、SS7を外部的に「話します」。
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 "Island"のすべてのリソースが特定の管理当局内に収まることです。したがって、音声トラフィック（データとシグナル伝達）のPSTNタイプQoSをIPネットワークを終了することに問題はありません。したがって、このシナリオの下では、過剰プロビジョニングの存在下での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
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がそれらの間に存在する可能性があるという推定を考えると、緊急関連のトラフィックを他のタイプのトラフィックと区別できることに関して、Diff-Servのようなものが増加します。さらに、ETSタイプのトラフィックを区別する行為が特定のソースに対して実際に有効であることを保証するために、ドメイン間でIPセキュリティがより重要になります。
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インターワーキング全体でISUPの透明性を提供する際に進行中の補完的な作業に言及することにより、このセクションを締めくくります[33]。この取り組みの目的は、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] Braden、R.、Clark、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-Protocol Label Switching（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] Sharma、V。およびF. Hellstrand、「マルチプロトコルラベルスイッチング（MPLS）ベースの回復のフレームワーク」、RFC 3469、2003年2月。
[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 Internet X.400 Enhanced Relay）：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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、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、「シグナリングシステムNo. 7（SS7）、完了の高い確率（HPC）ネットワーク機能」、ANSI T1.631-1993、（R1999）。
[13] Robust Audio Tool (RAT): http://www-mice.cs.ucl.ac.uk/multimedia/software/rat
[13] 堅牢なオーディオツール（ラット）：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。、「セッション開始プロトコル（SIP）のリソース優先メカニズムの要件」、RFC 3487、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[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] Durham、D.、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R。、およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、RFC 2748、2000年1月。
[17] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[17] Rosenberg、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.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、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] Rosenberg、J.、Salama、H。、およびM. Squire、「Thelephony Routing over 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] Groves、C.、Pantaleo、M.、Anderson、T。、およびT. Taylor、「Gateway Control Protocolバージョン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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTP Payload for Redundant Audioデータ」、RFC 2198、1997年9月。
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[23] Rosenberg、J。およびH. Schulzrinne、「一般的なフォワードエラー補正のためのRTPペイロード形式」、RFC 2733、1999年12月。
[24] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113- 2000, 2000.
[24] ANSI、「シグナリングシステムNo. 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] Carlberg、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] Hardman、V.、et al、「インターネットで使用するための信頼できるオーディオ」、Proceedings、Inet'95、1995年8月。
[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.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[31] "Service Class Designations for H.323 Calls", ITU Recommendation H.460.4, November, 2002.
[31] 「H.323コールのサービスクラス指定」、ITU推奨H.460.4、2002年11月。
[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.、Chiu、A.、Elwalid、A.、Widjaja、I。、およびX. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、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。およびJ. Peterson、「電話のセッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ」、BCP 63、RFC 3372、2002年9月。
[34] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology", RFC 3523, April 2003.
[34] Polk、J。、「インターネット緊急時対応（IEPREP）テレフォニートポロジー用語」、RFC 3523、2003年4月。
[35] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[35] Carlberg、K。およびR. Atkinson、「緊急通信サービス（ETS）の一般的な要件」、RFC 3689、2004年2月。
[36] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004.
[36] Carlberg、K。およびR. Atkinson、「緊急通信サービス（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] Meyers、D。、「COSおよびバックボーンネットワークに関するいくつかの考え」http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf ietfプレゼンテーション：Ieprep、Dec、2002。
[38] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[38] Huston、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.、McGrew、D.、Naslund、M.、Carrara、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] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis」（ホップあたりの動作）」、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] Cuervo、F.、Greene、N.、Huitema、C.、Rayhan、A.、Rosen、B。、およびJ. Segers、「Megaco Protocolバージョン0.8」、RFC 2885、2000年8月。
[43] Taylor, T., "Megaco Errata", RFC 2886, August 2000.
[43] Taylor、T。、「Megaco errata」、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標準を使用しています。また、Experienceを描くための役立つモデルとして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.
英国には、政府の電話選好スキーム（GTPS）と呼ばれるテレフォニーサービスの異なるタイプの承認された使用があります。現在、GTPは英国内のローカルループラインのサブセットにのみ適用されています。この行は、カテゴリ1、2、および3に分割されます。最初の2つのカテゴリには、自然災害などの緊急事態に関与する認定担当者が含まれます。カテゴリ3は、一般の人々を識別します。優先マークは、C7/NUPを介して、特定のカテゴリのコールギャップをバイパスするために使用されます。GTPをアクティブ化する権限は、中央または委任された当局のいずれかに拡張されました。
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.
物理的な静的デバイスに基づいた好みの指定により、現在のGTPの設計は、このドキュメントに示されているいくつかの側面の必要性を妨げています。ただし、直接的な相関を持つことができるコンポーネントの1つは、SIPの提案されたリソース優先度拡張のラベル能力です。SIPの新しいラベルメカニズムにより、IPテレフォニーとGTPをサポートする英国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フレームワークドキュメントに関連して最小限です。
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].
このグループは、h.323のコール確立メッセージに優先クラスのパラメーターを追加するこのグループによって受け入れられています。このクラスはさらに2つの部分に分かれています。1つは優先値のために、もう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パラメーターで実施される優先クラス情報を定義することを提唱しています。GenericDataパラメーターには、PriorityClassgenericDataが含まれています。PriorityClassgenericDataの優先度のclassinfoには、優先度と優先度の拡張フィールドが含まれています。
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からCrytoken、Cryptotokenを開始します。
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
...
}
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.
GenericDataパラメーターを使用する利点は、新しいパラメーターを定義し、既存のH.323/H.225ドキュメントにその後の変更を引き起こすのではなく、既存のパラメーターが使用されることです。
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.
著者は、Stu Goldman、James Polk、Dennis Berg、Ran Atkinsonの有用なコメント、意見、説明、およびIEPSおよびIEPREPメーリングリストから受け取ったコメントを認めたいと考えています。GTPの運用に関するプライベートディスカッションと、SG16ドラフト貢献の説明に関するGary ThomのPeter WalkerのPeter Walkerに感謝します。
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
Ian Brown University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
Ian Brown University College London Department of Computer Science Gower Street London、WC1E 6BT英国
EMail: 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ロックヒルロードカンザスシティ、ミズーリ州64110-2499 USAのコリービアード大学
EMail: BeardC@umkc.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。