RFC4190 日本語訳
4190 Framework for Supporting Emergency Telecommunications Service(ETS) in IP Telephony. K. Carlberg, I. Brown, C. Beard. November 2005. (Format: TXT=69447 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Carlberg
Request for Comments: 4190 G11
Category: Informational I. Brown
UCL
C. Beard
UMKC
November 2005
Carlbergがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4190年のG11カテゴリ: 情報のI.のブラウンUCL C.あごひげUMKC2005年11月
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)インターネット協会(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構造とサービスモデルの中にEmergency Telecommunications Service(ETS)に沿ってどう実現されるべきであるかの概観を反映する一連の目的を提示します。 これらの目的から、私たちはプロトコルと対応する能力を提示します。(能力は既存のIETFプロトコルに関して、より特定の推薦を提供します)。 最終的に、目的と機能のための誘導しているモデルが本書では記載したように私たちは2つのシナリオにその行為を提示します。 既存にPublic Switched Telephone Network(PSTN)でのサービスの例に結びつけられたこれらのモデルは強制的な解決策スペースに貢献します。
Carlberg, et al. Informational [Page 1] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [1ページ]情報のRFC4190IP電話枠組みの2005年11月
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
1. 序論…2 1.1. 非常時はデータについて話しました…4 1.1.1. 政府非常時のテレコムサービス(得ます)…4 1.1.2. 国際的非常事態の気構え計画(IEPS)。5 1.2. このドキュメントの範囲…5 2. 目的…7 3. 問題…7 4. プロトコルと能力…7 4.1. シグナリングと州の情報…8 4.1.1. ちびちび飲んでください…8 4.1.2. デフ-Serv…8 4.1.3. 変化はデフ-Servと列を作りに関連しました…9 4.1.4. RTP…10 4.1.5. GCP/H.248…11 4.2. 方針…12 4.3. 交通工学…12 4.4. セキュリティ…13 4.4.1. サービス妨害…13 4.4.2. ユーザ認可…14 4.4.3. 秘密性と保全…15 4.5. 経路ルート設定を交替してください…16 4.6. 終わりから終わりへの耐障害性…17 5. キーシナリオ…18 5.1. ただ一つのIP管理ドメイン…18 5.2. 複数のIPの管理ドメイン…19 6. セキュリティ問題…20 7. 有益な参照…20 付録A: 政府は好みの計画(GTPS)に電話をします…24 A.1。 GTPSと枠組みのドキュメント…24 付録B: 関連規格は働いています…24 B.1。 グループ16(ITU)を研究してください…25の承認…26
1. Introduction
1. 序論
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.
インターネットは情報流通のレクリエーション、ビジネス、および様々な想像的な理由に関して世界的なコミュニケーションのための第一の目標になりました。 インターネットの発展における一定の固定具はデフォルトサービスモデルとしてのBest Effortのサポートです。 最も良いEffortは、最もよくそうすることができるしない保証と全く何かリソースがService(QoS)のQualityの具体策を支えるために予約されているとネットワークが、交通を目的地に送るのを試みるのをあいまいな言葉で含意します。 「基本的な目標はそれを目的地に送るために運用資金ですべての交通に公正である」ことです。
Carlberg, et al. Informational [Page 2] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [2ページ]情報のRFC4190IP電話枠組みの2005年11月
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]はIntegrated Services(int-serv)とその包含の概観をインターネット構造に提示しました。 [2]はこれのあとに続きました。([2]はQoS要件を伝えるのに使用されるRSVPシグナリングプロトコルを指定しました)。 [3]と[4]の添加で、制御負荷(帯域幅領域)と保証されたサービス(帯域幅と遅れ領域)を指定して、それぞれ、デザインは、終わりから終わりへの交通の流動のためにIPネットワークを横断しながらQoSの具体策を達成するために存在しました。 この場合、流れの私たちの参照は定義で粒状であり、特定のアプリケーションセッションに適用されるものです。
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は[7]を生産しました。([7]はDifferentiated Services(デフ-serv)のために構造を提示しました)。 この努力は[1]のものよりパケットのさらに集められた見解と分類に焦点を合わせました。 これはIPヘッダーのデフ-serv分野の最近の仕様で達成されます(IPv4の場合では、それは古いToS野原を取り替えました)。 この新しい分野は実験的であるとしてIANAによって確立されるか、またはかたわらに置かれたコード・ポイントに使用されます。 microflowsのセット(1セットのパケットの粒状の識別)が与えられたコード・ポイントに対応すると予想できます、その結果、データの集められた処理を達成します。
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つの定数がデフォルトサービスモデルとしてのBest Effortの名称です。 交通はあるはずがありませんし、またあるはずがないなら、デフ-servかint-servとして関連していて、それが、Best Effortとして扱われて、リソースが作られていることを利用可能な状態でそれに使用します。
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
新種業務の導入を超えて、数年間ISPによって経験された追加トラヒック負荷の長引くペースは、イントラドメイン交通工学に高い重要性を置き続けていました。 Multi-プロトコルLabel Switching(MPLS)の領域で作成された草稿とRFCsの形における、IETF貢献の爆発はイントラドメイン交通工学のために多能で処理しやすいメカニズムへの関心を例示します。 1つのおもしろい観測はQoSの関連する交通工学をサポートするのにかかわる仕事です。 明確に、私たちはMPLSサポートについて言及します。
Carlberg, et al. Informational [Page 3] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [3ページ]情報のRFC4190IP電話枠組みの2005年11月
of differentiated services [8], and the ongoing work in the inclusion of fast bandwidth recovery of routing failures for MPLS [9].
微分されたサービス[8]、およびMPLS[9]のためのルーティング失敗の速い帯域幅回復の包含における進行中の仕事について。
1.1. Emergency Related Data
1.1. 非常時はデータについて話しました。
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つは米国での「911」電話サービスかイギリスそれの両方が、国境の結果と考えられて(一般はアクセスしやすい)の「999」に緊急通報を関連づけます。 この外では、以下の小区分で説明されるように認可された用法にかかわる緊急電話サービスが存在しています。
1.1.1. Government Emergency Telecommunications Service (GETS)
1.1.1. 政府非常時のテレコムサービス(得ます)
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は米国で利用可能な非常時のテレコムサービスであり、National Communications System(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の目的は非常時の時代に電話サービスが選択された任命された者にとって利用可能になるという高い確率を達成することです、呼び出しブロッキング(すなわち、混雑)の形で一般で米国Public Switched Telephone Networkに負担を生産するかもしれないハリケーンや、地震や、他の災害などのように。
Carlberg, et al. Informational [Page 4] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [4ページ]情報のRFC4190IP電話枠組みの2005年11月
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規格に一部基づいています、Completion(HPC)のHigh ProbabilityをSS7シグナリング[12][24]に指定して。
1.1.2. International Emergency Preparedness Scheme (IEPS)
1.1.2. 国際的非常事態の気構え計画(IEPS)
[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ドキュメントで定義されることです。
1.2. Scope of This Document
1.2. このドキュメントの範囲
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.
この区別に関する例はユニキャスト(または、マルチキャスト)の目的地へのRobust Audio Tool(RAT)[13]がパケットをVoIPに送り始める時です。 RATは、2人のユーザの間の終わりから終わりへの呼び出しを証明するのに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
私たちがIP Telephonyと共に存在するとたぶん思うべきである他の1つの局面が1セッションあたりのQoSか流れの目標レベルの協会です。 [28]はVoIP交通への最大のパケット損失と遅れがあって、両方が互いに依存しているという主張をします。 ~200msの遅れにおいて、5%の対応する低下率は許容できると考えられます。 遅れが低いときに、15-20%の低下率を経験して、許容できるとまだ考えることができます。 [29]は同じ話題について議論して、パケットサイズがユーザが「明瞭な」VoIPとして許容することにおける重要な役割をプレーするという主張をします。 パケットが大きければ大きいほど、より長い標本抽出率に関連して、許容できる損失係数は、より低いです。 [28、29]がいくつかの2つの見解だけをVoIPを調べるのに提供することに注意してください。 この話題についての、より徹底的な議論が外にあります。
Carlberg, et al. Informational [Page 5] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [5ページ]情報のRFC4190IP電話枠組みの2005年11月
the scope of this document, though it should be noted that the choice of codec can significantly alter the above results.
コーデックの選択が上の結果をかなり変更できることに注意されるべきですが、このドキュメントの範囲。
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.
圧力を加えられた状態のための単一の、そして、決定的な特性にかかわらず、対話的な声には損失/遅れ/ジターのいくつかの組み合わせの下側の敷居がメールかウェブブラウザなどの弾性の応用よりあるように思えるでしょう。 これはインターネットの上で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.
これを超えて、このドキュメントを書くことにおける私たちの動機の一部はISPと電話キャリヤーが、目的が以前はよくETS関連のIP電話技術交通を支持していたのを理解するように枠組みを提供することです。 また、さらに、彼らの期待を抑制するために基準点を見込み客に提供したいと思います。 特に、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は、現在存在する2つのシナリオを提示するか、または近いうちにIPネットワークの上で配備されています。 これらがすべてを含むシナリオでなく、またそれらが明確に話されて、([34]がIP電話技術に関連するトポロジーシナリオについてのaより大規模な議論を提供するということであるかもしれない唯一のものでない、) しかしながら、これらのシナリオはセクション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層に注意を集中していると述べる必要があります。 このドキュメントの範囲の外にNetwork Operationセンターズ(NOC)かNetwork Informationセンターズ(NIC)に関係する特定の操作手順があります。 これは専用リンクに関してISPと電話キャリヤーとのIP、他の独自技術、およびサービスレベル協定で「ビット」を含んでいます。
Carlberg, et al. Informational [Page 6] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [6ページ]情報のRFC4190IP電話枠組みの2005年11月
2. Objective
2. 目的
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を支持するために潜在的に唱えることができた与えられたプロトコルか能力に関して局面についての何らかの議論を提供します。 この探検は私たちがまさにしなければならないこと(例えば、新しいヘッダーフィールド、または新しいコード・ポイント)について明確に話さないので特定の解決策に混乱しないことです。
3. Considerations
3. 問題
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.
考えるもう一つの側面は既存の構造があるということです、そして、他の標準化団体からのプロトコルはそのサポート非常時にコミュニケーションについて話しました。 これらのシステムと、おそらくゲートウェイか同様のタイプのノードを通してIETFプロトコルで共同利用することにおける努力は他の流れとETS流れを区別する必要性を伸ばしているでしょう。 1つの理由がETSがIPネットワークから修理する引き金となることのシナリオでしょう。
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]における要件のいずれにも違反しないのを確実にします。
4. Protocols and Capabilities
4. プロトコルと能力
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
このセクションでは、私たちは、上に提示された目的を取って、それらを達成するのに使用できる1セットのプロトコルと能力を提示します。 目的が現実に支配的に原子であるなら、それらを記述するのに使用される測定は別々に互いで特定の依存なしで全体で見られることです。 互いにおいて、様々なプロトコルと能力は賞賛であるかもしれませんが、いいえがあります。
Carlberg, et al. Informational [Page 7] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [7ページ]情報のRFC4190IP電話枠組みの2005年11月
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) ルート設定
4.1. Signaling and State Information
4.1. シグナリングと州の情報
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のサポートを提供することにおけるいくつかのプロトコルと彼らの使用の現状について議論します。 また、私たちは、非常時一般に、関連するコミュニケーションの区別を支持するのを助けるために異なったタイプのシグナリングと州の情報と潜在的増大について議論します。
4.1.1. SIP
4.1.1. 一口
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電話技術のために合図するアプリケーションレベルに関して、私たちはSession Initiationプロトコル(SIP)に注意を集中しています。 現在、SIPは異なったタイプのセッションを区別するRequestヘッダー分野に既存の「優先権」分野を持っています。 現在定義されている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プロキシの振舞いに影響を及ぼすことができる区別の追加手段を提供する手段に通じることになっています。
4.1.2. Diff-Serv
4.1.2. デフ-Serv
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
[15]によると、微分されたサービスコード・ポイント(DSCP)分野は3セットの値に分割されます。 第一セットはIANAによって割り当てられます。 このセットの中に、現在の指定されたPer Hop Behaviorsの3つのタイプがあります: デフォルト、(関連
Carlberg, et al. Informational [Page 8] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [8ページ]情報のRFC4190IP電話枠組みの2005年11月
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.
ベストエフォート型推進)、Assured Forwarding、およびExpedited Forwarding。 2番目のセットのDSCP値は地方的、または、実験的な使用のためにかたわらに置かれます。 3番目のセットのDSCP値は、また、地方的、または、実験的な使用のためにかたわらに置かれますが、第一セットを完全に割り当ててあるなら、後で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つのアプローチが非常時の関連の流れのための新しいPer-ホップBehaviour(PHB)の仕様です。 この考えの後ろの原理は特定のコード・ポイントが様々な非常時の関連の交通と定義されるかもしれない基線を提供するだろうということです: 認可された緊急集会(例えば、ETS)、一般緊急通報(例えば、「911」)、マルチレベル先行、および先取り(MLPP)[19]など しかしながら、新しいコード・ポイントを定義するために、また、推進の特性を定義しなければなりません。 言い換えれば、それらの意図している意味(例えば、Assured Forwardingの低下先行アプローチ)を定義しないで、1つは1セットのビットを絶対に特定できません。 この声明への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が新しいPHBsを指定しながら保守的なアプローチを中に入れ続けていたことに注意するのは重要です。 これは定義できるコード・ポイントの数が比較的小さく、不十分なリソースであると目立って考えられるからです。 したがって、非常時の関連の交通と定義される新しい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]を使用することを提案するでしょう。 最小限では、異なったSIP呼び出しシグナリングメッセージにAFを使用できました。 また、Expedited Forwarding(EF)PHB[40]がドメインによって支持されるなら、それはIP電話技術データ・パケットに使用されるでしょうに。 さもなければ、もう1人のAFのクラスがそれらのデータフローに使用されるでしょう。
4.1.3. Variations Related to Diff-Serv and Queuing
4.1.3. デフ-Servと列を作りに関連する変化
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-
Weighted Fair QueueingとClass Based Queueingのようなスケジューリングメカニズムは、すべての待ち行列がバックログされるなら各クラスに使用されるリンク帯域幅に出力の割合を指定するのに使用されます。 目的はしたがって、各クラスによって経験されたレートと遅れを管理することです。 と異なってまたは、しかし、交通が必ずQoSを必要とするかもしれないというわけではない非常時が少しもよりよく実行する、非
Carlberg, et al. Informational [Page 9] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [9ページ]情報のRFC4190IP電話枠組みの2005年11月
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.
非常通信。 それはただ、クラスの中で単に先行を下げることによって達成できるだろう次のホップに送るというより高い確率を必要とするかもしれません。
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つが非常通信であるトラフィックのクラスの間の優先の低下を実装するために、人は、たぶんActive Queue Management(AQM)の、より高度なフォームを使用する必要があるでしょう。 現在の実装は決定をするのに総合的な待ち行列中詰め測定を使用します。 これは下げられるべき分類されたパケットを非常時に引き起こすかもしれません。 AQMの1つの新しいフォームがMultiple Average複数のThresholdアプローチであるかもしれません、今日使用されているSingle Average複数のThresholdアプローチの代わりに。 個別にそれぞれの低下先行のための待ち行列における、パケットの数を数えることに基づいてこれは低下確率の作成を許容します。
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 PHBsの現在のセットを使用するのは可能であるかもしれないでしょうに。 しかし、1つは非非常通信の中にまだ3つの低下先行を差別化する必要性を持っているかもしれません。 そうだとすれば、より多くの低下先行を実装することができました。 また、また、1つがMLPPの先行の5つのレベルのように非常通信の中で区別を必要とするなら、より多くの低下先行が考えられるでしょうに。 また、5つのレベルが、Emergency Telecommunications Serviceのために5つのレベルを定義するためにITUのStudy Group11の最近の取り組みに関連するでしょう。
4.1.4. RTP
4.1.4. RTP
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.
レアル-時間Transportプロトコル(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
中、4.1、.2、私たちは非常時にデフ-servアーキテクチャの文脈の下でデータ・パケットをマークする1つの手段について議論しました。 しかしながら、私たちは、また、特定のPHBsのためのデフ-serv印がグローバルにユニークでなく、任意に取り除かれるかもしれないと指摘したか、または仲介者ノードかドメインのそばで変化さえしました。 したがって
Carlberg, et al. Informational [Page 10] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [10ページ]情報のRFC4190IP電話フレームワーク2005年11月
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.
非常時はデータ・パケットを関係づけて、私たちが終わりから終わりへのベースで一定の状態で残っているデータ・パケットのバンドにおける的をまだ外れています。
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つの選択があります。 1つは非常時のタイプトラフィックのために4.1で.2に議論するように捧げられた新しいPHBを提案できます。 1つはIPの上のいくらかの位置で新しい詰め物の層のプロトコルの仕様を提案できます。 または、人は既存の応用層プロトコルに新しい仕様を追加できます。 最初の2つのケースがたぶん建築上「最も清潔です」が、それらは限られた数のデフ-servコード・ポイントとさらに別の詰め物の層でIPスタックが大きくなり過ぎるという主張で起こらないかもしれない長期取り組みです。 3番目のこの件には、応用層パケットにマークを置いて、また、欠点があります。 1アプリケーションあたり1個のベースでのマークの仕様である主要な弱点。
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を増大させるとき、議論がAudio/視覚のTransport(AVT)ワーキンググループで行われました。 明確に、パケット(例えば、非常時、非常時、標準を認可する)に関連している状態を示す「クラシファイア」分野を含む新しい拡大を定義するとき、これらの議論は[26]を中心に置きました。 この考えの後ろの原理は人がRTPに焦点を合わせるのにそれがカプセル化するすべてのペイロードに適用される集合のポイントを当てにすることができるだろうということでした。 しかしながら、AVTグループは別のものの上の1回の流れの重要性を指示するために追加クラシファイア状態をRTPヘッダーに置くのが、彼らが進めたがっているアプローチでないという荒いコンセンサスを述べました。 ヘッダー圧縮に悪影響を与える可能性に流れの重要性を伝えるためにSIPを当てにするので及ぶ反論は言い表されました。 また、信号として機能するRTPのための拡張ヘッダーを使用するべきでないという一般的な感じがありました。
4.1.5. GCP/H.248
4.1.5. GCP/H.248
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].
ゲートウェイControlプロトコル(GCP)[21]はメディアゲートウェイとメディアゲートウェイコントローラとの相互作用を定義します。 [21]はITU-T Recommendation H.248[41]と共にアップデートされたバージョンとして一般的なテキストについて見なされて、RFC2885(Megacoプロトコルバージョン0.8)[42]のテキストへのRFC2886(Megaco Errata)[43]の変化を適用するという結果です。
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]では、プロトコルは文脈属性と記述子にPriorityとEmergency分野を指定します。 Emergencyが任意の論理演算子である、(本当である、False) または、状態。 Priority値(0〜15まで及ぶ)は文脈のための先行取り扱いを指定します。
Carlberg, et al. Informational [Page 11] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [11ページ]情報のRFC4190IP電話フレームワーク2005年11月
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の機能であるべきです。
4.2. Policy
4.2. 方針
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サーバか帯域幅ブローカー)に埋め込まれた静的な情報の形にあることができるか、ドメインのリソース[16]の配分に関するCOPSを通してそれを実感して、サポートすることができます。 方針がどう優れるかに関して要件が全くありません。 代わりに、ドメインがETS関連のコミュニケーションのデフォルト非割込み型動作の外に動作に続くなら、私たちは、タイプの方針メカニズムがETS-タイプトラフィックのために設立されたSLAのローカルの方針を満たすために適所にあるのを規定します。
4.3. Traffic Engineering
4.3. 交通工学
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.
ネットワークがそれの1つ以上がETSベースのトラフィックに関係するSLAの規制で作動するそれらの場合では、何らかのフォームの交通工学がネットワークの操作に適用されると予想できます。 私たちはそのようなシステムが、ETSがシグナリング、そして/または、データであると何らかのフォームに存在して、区別して、サポートしたはずがないなら交通工学メカニズムのタイプが使用されている推薦状を全くトラフィックにしません。 私たちはインターネット交通工学の原理の概要とセットに与えるクライアントによる[32]のレビューと将来のETSサービスのプロバイダーを推薦します。
Carlberg, et al. Informational [Page 12] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [12ページ]情報のRFC4190IP電話フレームワーク2005年11月
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を引用したので、それがintradomainプロトコルであると強調するのが必要であるので、私たちは、与えられた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.
以下に注意してください。 参照のポイントとして、GETSサービスのためにNCSによって設立された既存のSLAは、与えられたLECを通してHPCを使用することで設立できるだろう例えば、1%から10%の呼び出しの緩く定義された最大の配分に焦点を合わせる傾向があります。 それは、予想されて、奨励されて、ETSがISPのSLAを関係づけたのは認定ユーザによって関係づけられて、開始された非常時であるとして区別されたトラフィックの量に関して制限されるでしょう。
4.4. Security
4.4. セキュリティ
This section provides a brief overview of the security issues raised by ETS support.
このセクションはETSサポートで提起された安全保障問題の簡潔な概要を提供します。
4.4.1. Denial of Service
4.4.1. サービス妨害
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
したがって、優先権メカニズム(セクション4.1で説明されたQoSシステムなどの)を配布するどんなプロバイダーも慎重に関連アクセス制御とセキュリティー対策を適用しなければなりません。例えば、ネットワークかイングレスポイントの権限のない部分から発するトラフィックのための優先順位は標準にリセットされるべきです。 また、優先サービスを使用するのが許容される前にユーザを認証しなければなりません(セクション4.4.2を見てください)。 しかしながら、この認証過程は、サービス不能攻撃の機会を最小とならせるように軽量であるべきです。
Carlberg, et al. Informational [Page 13] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [13ページ]情報のRFC4190IP電話フレームワーク2005年11月
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.
認証サービス的自体に、理想的に、それ自身の反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、または何らかの同様の、または、より速い技術を使用します。 また、この書くこと現在そのような相互プロバイダーリンクの上に1IPあたりのパケットの暗号の認証を配布するのも実用的ではありません、そのような認証が相互プロバイダーシナリオにおける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.
ムーアの法則は暗号の認証を早くするでしょうが、また、典型的な相互ドメインリンクの速度が雨後の竹の子のように出ているのでそれが役立っているかどうかが、不明瞭です。
4.4.2. User Authorization
4.4.2. ユーザ承認
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特有のユーザ承認サポートはほとんど必要ではありません。 US GETSの暗証番号を使用して、ユーザはいつものよう、例えばPSTNにそれ自体を認証します。 バックボーンIPネットワークとのPSTN接続からのゲートウェイは、流れにはETSラベルがあると合図できなければなりません。 逆に、PSTNへのゲートウェイは同様に呼び出しのラベルに合図しなければなりません。 ゲートウェイの間の安全なリンクはバックボーンネットワークへのアクセスを得た攻撃者に対してシグナリング情報の保全を保護して、そのような攻撃者が出口PSTNゲートウェイを使用することでETS電話をするのを防ぐためにIPSecを使用するか、SIPセキュリティの機能性をセットアップすることであるかもしれません。 呼び出しの目的地が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.
1つのドメインの中の流れにETS優先権を提供しているとき、そのネットワークは流れが認定ユーザかプロセスから発したのを保証するために配布される優先権メカニズムのセキュリティ機能を使用しなければなりません。
Carlberg, et al. Informational [Page 14] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [14ページ]情報のRFC4190IP電話フレームワーク2005年11月
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メカニズムを使用するのを許容する前にセッションの承認について確かめるのにそれらのプロトコルにセキュリティの機能性を使用するはずです。
4.4.3. Confidentiality and Integrity
4.4.3. 秘密性と保全
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.
したがって、そのようなコミュニケーションの保全と秘密性は、SIPとSRTP[39]でIPSecかセキュリティの機能性などの終わりから終わりへのセキュリティプロトコルをできるだけ使用することで保護されるべきです。 コミュニケーションが他のタイプのPSTNなどのネットワークにかかわるところでは、IP側は保護されるべきです、そして、もう片方のネットワークで利用可能などんなセキュリティの機能性も使用されるべきです。
Carlberg, et al. Informational [Page 15] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [15ページ]情報のRFC4190IP電話フレームワーク2005年11月
4.5. Alternate Path Routing
4.5. 代替パスルート設定
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.
IPネットワーク層における、BGPやOSPFなどのルーティング・プロトコルはルーティング同輩の間にリンクの故障を決定するためのメカニズムを含んでいます。 この失敗の発見で、自動的に他のルータに情報を伝播します。 この情報のフォーム、伝播の範囲、および新しいルートを決定することにおける集合時間は使用中のルーティング・プロトコルに依存しています。 OSPFのEqual Cost Multiple Path(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の自由民主党仕様への増進が、耐障害性を達成するのを助けるように、フレームワークについて説明します。([9]はネットワーク層ルーティングに焦点を合わせられます)。 これは、本来代替パスルーティングを提供しませんが、MPLSがドメインの中で使用されるとき、intradomainの接続性における損失を最小にするのをむしろ助けます。
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 Telephonyワーキンググループから来て、IP(TRIP)の上でTelephonyルート設定にかかわります。 これまで、フレームワークドキュメント[17]はプロバイダーの間のIP電話技術ゲートウェイ経路指定テーブルの発見と交換について説明するRFCとして発表されました。 TRIPプロトコル[20]は使用されるシグナリングプロトコル(例えば、SIPかH.323)にかかわらずアプリケーションレベル電話ルーティングを指定します。 TRIPはBGP-4に倣われて、目的地の可到達性と属性の広告を出します。 現在のフォームでは、いくつかの属性がLocalPreferenceやMultiExitDiscのように既に定義されました。 追加属性をIANAに示すことができます。
Carlberg, et al. Informational [Page 16] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [16ページ]情報のRFC4190IP電話フレームワーク2005年11月
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によってよく受け取られないでしょう。 Inter-ドメインルーティングの論評のための[38]を参照してください。
4.6. End-to-End Fault Tolerance
4.6. 終わりから終わりへの耐障害性
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)の使用に焦点を合わせます。 ロストデータパケットを補うのに使用できる余分なトランスミッションをError Correction(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データ・パケットは、1セットのオリジナルのデータ・パケットから組み立てられて、終わりから終わりへのストリームに挿入されます。 使用されるアルゴリズムによって、これらの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パケットのものほどネットワークに好意的でないのさえ見えるでしょう。 しかしながら、オリジナルのパケットよりかなり小さい冗長データパケットを作り出す異なったタイプ(または、やや劣る品質に、移コード化さえした)には余分なパケットのencodingsがあることができます。
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
FECと余分なオーディオデータのためにRTPペイロードを定義する2RFCs[22、23]が生産されました。 [13]で余分なオーディオアプリケーションに関する実装の例を見つけることができます。 私たちが、かなり特定で、度合いに付随的であるとしてFECと余分なトランスミッションの両方を見なすことができることに注意して、ソリューションは、パケット損失を見なして、非常時です。
Carlberg, et al. Informational [Page 17] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [17ページ]情報のRFC4190IP電話フレームワーク2005年11月
communications. Hence, these topics are placed under the category of value-added objectives.
コミュニケーション。 したがって、これらの話題は付加価値が付いた目的のカテゴリの下で置かれます。
5. Key Scenarios
5. 主要なシナリオ
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に提示されたプロトコルと能力がどう役割を果たすことができるかに関する2、3の例を提供するだけであることになっています。
5.1. Single IP Administrative Domain
5.1. ただ一つのIP管理ドメイン
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の結果と考えられた古典的な切り換え構造を保有します。 もう片方が、縁の次世代キャリヤーとSignaling Gatewaysです。(キャリヤーはコアインフラストラクチャとしてデータ網(例えば、IP)を使用します)。 これらのゲートウェイはじっと見ているキャリヤー、および別のプロトコル(例えば、SIP)で外部的に内部的にSS7を「話します」、IPインフラストラクチャの上に乗るどれ。
Carlberg, et al. Informational [Page 18] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [18ページ]情報のRFC4190IP電話枠組みの2005年11月
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * ISUP * *
SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
* * (SS7) * (SIP) * (SS7) * (SIP) *
******* *************** **************
遺産次世代次世代キャリヤーキャリヤーキャリヤー****************************************ISUP**SW<。--->SW<。----->SG<。---IP--->SG<--IAM-->SG<。---IP--->SG**(SS7)*(一口)*(SS7)*(一口)*************************************
SW - Telco Switch, SG - Signaling Gateway
SW--通信業者スイッチ、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.
それはすべて、リソースfです。このシナリオの重要な局面、それぞれのIP「島」は与えられた職務権限の中で低下します。 したがって、IPネットワークを出て、音声トラヒック(データとシグナリング)へのPSTNタイプQoSを保有するのにおいて問題がありません。 したがって、過剰食糧を供給することの面前でデフ-servのようなメカニズムのサポート、およびPer-ホップBehaviorsの定義されたセットの拡大の必要性はこのような筋書で減少します。
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の一部としてじっと見て、手段がその既存の保証であるというパーソナルIdentification Number(暗証番号)認証(電話インフラストラクチャ保護の文脈の下における)の形の事実はセキュリティのデフォルト範囲です。 私たちは、暗証番号ベースのセキュリティシステムへの信用が非常に安全であるか、または望ましくさえあると主張しません。 しかし、私たちは、既存の認可された非常時の電話技術システムに追加要件を置くのを避けるのにデフォルトメカニズムとしてこのシステムを使用します。
5.2. Multiple IP Administrative Domains
5.2. 複数のIPの管理ドメイン
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の管理ドメインとシグナリングを交換するかもしれません。
Carlberg, et al. Informational [Page 19] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [19ページ]情報のRFC4190IP電話枠組みの2005年11月
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * * *
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) *
******* *************** **************
遺産次世代次世代キャリヤーキャリヤーキャリヤー******************************************SW<。--->SW<。----->SG<。---IP--->SG<--IP-->SG<。---IP--->SG**(SS7)*(一口)*(一口)*(一口)*************************************
SW - Telco Switch
SG - Signaling Gateway
SW--通信業者スイッチSG--シグナリングゲートウェイ
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.
私たちは、[33]を織り込みながらSS7-SIPの向こう側に透明を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コード・ポイントを指定する必要性を予期します。
6. Security Considerations
6. セキュリティ問題
Information on this topic is presented in sections 2 and 4.
この話題に関する情報はセクション2と4で提示されます。
7. Informative References
7. 有益な参照
[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、「インターネット構造における統合サービス:」 「概観」、RFC1633、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の機能的な仕様」、RFC2205、1997年9月。
[3] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997.
1997年9月の[3]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
Carlberg, et al. Informational [Page 20] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [20ページ]情報のRFC4190IP電話枠組みの2005年11月
[4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[4]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、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.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(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.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(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.ウィス、「微分されたサービスのための構造」RFC2475、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.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
[9] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol
Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[9] シャルマとV.とF.Hellstrand、「マルチプロトコルラベルスイッチングの(MPLS)ベースの回復のための枠組み」、RFC3469、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.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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/マルチメディア/ソフトウェア/ネズミ
[14] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, February
2003.
[14]Schulzrinne、H.、「セッション開始プロトコル(一口)のためのリソース優先権メカニズムのための要件」、RFC3487、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.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(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] ダラム、D.、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
Carlberg, et al. Informational [Page 21] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [21ページ]情報のRFC4190IP電話枠組みの2005年11月
[17] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
Routing over IP", RFC 2871, June 2000.
[17] ローゼンバーグとJ.とH.Schulzrinne、「IPの上の電話ルート設定のための枠組み」、RFC2871、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は分類する」RFC2597、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.は2002年1月に「電話はIP(旅行)の上で掘る」RFC3219に付き添います。
[21] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.
[21] 木立とC.とPantaleoとM.とアンダーソン、T.とT.テイラー、「ゲートウェイ制御プロトコルバージョン1インチ、RFC3525、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有効搭載量」、RFC2198(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有効搭載量形式」、RFC2733、1999年12月。
[24] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-
2000, 2000.
[24]ANSI、ANSI T1.113 2000、2000の「シグナリングシステムNo.7、ISDNユーザ部分。」
[25] "Description of an International Emergency Preference Scheme
(IEPS)", ITU-T Recommendation E.106 March, 2002
[25] 「国際的非常事態の好みの計画(IEPS)の記述」、2002年のITU-T推薦E.106行進
[26] Carlberg, K., "The Classifier Extension Header for RTP", Work In
Progress, October 2001.
[26] K.、「RTPのためのクラシファイア拡張ヘッダー」というCarlbergは進歩、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 Presentation: IPPM-Voiceip、1997年8月
[29] Hardman, V., et al, "Reliable Audio for Use over the Internet",
Proceedings, INET'95, Aug, 1995.
[29] ハードマン、V.、他、「インターネットの上の使用のための高信頼のオーディオ」、Proceedings、INET95年、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.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(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月。
Carlberg, et al. Informational [Page 22] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [22ページ]情報のRFC4190IP電話枠組みの2005年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.、チウ、A.、Elwalid、A.、ウィジャヤ、I.、およびX.Xiao、「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。
[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.ピーターソン、「セッション開始は電話(一口T)のために議定書を作ります」。 「文脈と構造」、BCP63、RFC3372、9月2002日
[34] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony
Topology Terminology", RFC 3523, April 2003.
[34] ポーク、J.、「インターネット非常時の気構え(IEPREP)電話トポロジー用語」、RFC3523、2003年4月。
[35] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689, February
2004.
[35]CarlbergとK.とR.アトキンソン、「非常時の電気通信サービス(ETS)のための一般要件」、RFC3689、2004年2月。
[36] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for
Emergency Telecommunication Service (ETS)", RFC 3690, February
2004.
[36]CarlbergとK.とR.アトキンソン、「非常時の電気通信サービス(ETS)のためのIP電話要件」、RFC3690、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プレゼンテーション: 2002年12月のIEPREP。
[38] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[38] ヒューストン、G.、「インターネットの相互ドメインルート設定の論評」、RFC3221、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.
2004年の[39]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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.
2002年の[40]デイビー、B.、シャルニー、A.、アメリカダイコンソウ、J.C.、ベンソン、K.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[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.、グリーン、N.、Huitema、C.、Rayhan、A.、ローゼン、B.、そして、J.Segers、「Megaco、プロトコルバージョン0.8インチ、RFC2885(2000インチ年8月)
[43] Taylor, T., "Megaco Errata", RFC 2886, August 2000.
[43] テイラー、T.、「Megaco誤字」、RFC2886、2000年8月。
Carlberg, et al. Informational [Page 23] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [23ページ]情報のRFC4190IP電話枠組みの2005年11月
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.
イギリスには、電話サービスの政府Telephone Preference Scheme(GTPS)と呼ばれた異なったタイプの認可された使用があります。 現在のところ、GTPSはイギリスの中で回線折返し線の部分集合に適用するだけです。 線はCategories1、2、および3に分割されます。 最初の2つのカテゴリが天災などの非常時にかかわる任命された者にかかわります。 カテゴリ3は一般を特定します。 C7/NUPを通して、優先権マークは、与えられたCategoryのために呼び出し巻き巣を迂回させるのに使用されます。 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のデザインは本書では提示されたいくつかの局面の必要性を排除します。 しかしながら、ダイレクト相関関係を持つことができる1つのコンポーネントがSIPへの提案されたResource Priority拡張子のラベリング能力です。 SIPのための新しいラベルメカニズムはIP電話技術とU.K. PSTNの間のGTPSを支持する透明なinteroperationを許容するかもしれません。
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 Initial Address Messageでラベルを定義したと言及するので。 この単一のラベルか値が、国家安全保障とEmergency Preparedness(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のリソース優先権ヘッダーのために1セットの対応するラベルを定義する必要性を生むので、このアプローチの影響はこのETS枠組みのドキュメントと関連して最小限です。
Carlberg, et al. Informational [Page 24] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [24ページ]情報のRFC4190IP電話枠組みの2005年11月
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の研究Group16(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に関する呼び出し設立メッセージにPriority Classパラメタを追加するこのグループによって受け入れられました。 このクラスはさらに2つの部品に分割されます。 Priority Valueともう片方のための1つは、サブクラスを示すためのPriority Extensionです。 それはおよそSIP[14]のためのResource Priority分野を通って輸送されたラベルに対応するこの前の部分です。
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のGenericDataパラメタで運ばれるPriorityClass情報かRASメッセージを定義すると提唱します。 GenericDataパラメタはPriorityClassGenericDataを含んでいます。 PriorityClassGenericDataのPriorityClassInfoはPriorityとPriority Extension分野を含んでいます。
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つのレベルがPriority ClassパラメタのPriority Value部分と定義されました: 正常で、高く、非常時の公共で、非常時によって認可されています。 追加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::=
t(0)推薦(0)h(8)460 4version1(0)をituしているCALL-PRIORITY DEFINITIONS AUTOMATIC TAGS:、:=
BEGIN
IMPORTS
ClearToken,
CryptoToken
FROM H235-SECURITY-MESSAGES;
H235セキュリティメッセージから輸入ClearToken、CryptoTokenを始めてください。
CallPriorityInfo::= SEQUENCE
{
priorityValue CHOICE
{
emergencyAuthorized NULL,
emergencyPublic NULL,
high NULL,
normal NULL,
...
},
CallPriorityInfo:、:= SEQUENCE、priorityValue CHOICE、emergencyAuthorized NULL、emergencyPublic NULL、高いNULL、正常なNULL、…
priorityExtension INTEGER (0..255) OPTIONAL,
priorityExtension整数(0 .255)任意です。
Carlberg, et al. Informational [Page 25] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [25ページ]情報のRFC4190IP電話枠組みの2005年11月
tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoToken OPTIONAL,
rejectReason CHOICE
{
priorityUnavailable NULL,
priorityUnauthorized NULL,
priorityValueUnknown NULL,
...
} OPTIONAL, -- Only used in CallPriorityConfirm
...
}
象徴SEQUENCE OF ClearToken OPTIONAL、cryptoTokens SEQUENCE OF CryptoToken OPTIONAL、rejectReason CHOICE priorityUnavailable NULL、priorityUnauthorized NULL、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.
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.
作者はスチュー・ゴールドマンの役に立つコメント、意見、および明確化を承諾したがっています、ジェイムズ・ポーク、デニス・バーグ、IEPSとIEPREPメーリングリストから受けられたそれらのコメントと同様にRanアトキンソン。 GTPSの操作での個人的な議論のためのOftelのピーター・ウォーカー、およびSG16草稿貢献の明確化でのゲーリー・トムへの追加感謝。
Carlberg, et al. Informational [Page 26] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [26ページ]情報のRFC4190IP電話枠組みの2005年11月
Authors' Addresses
作者のアドレス
Ken Carlberg University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
ガウアー・ストリートロンドン、ケンCarlbergユニバーシティ・カレッジロンドンコンピュータサイエンス学部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ロックヒル・Road MO64110-2499カンザスシティー(米国)のミズーリ-カンザスシティー師団のコーリーあごひげ大学
EMail: BeardC@umkc.edu
メール: BeardC@umkc.edu
Carlberg, et al. Informational [Page 27] RFC 4190 IP Telephony Framework November 2005
Carlberg、他 [27ページ]情報のRFC4190IP電話枠組みの2005年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Carlberg, et al. Informational [Page 28]
Carlberg、他 情報[28ページ]
一覧
スポンサーリンク
