RFC4542 日本語訳
4542 Implementing an Emergency Telecommunications Service (ETS) forReal-Time Services in the Internet Protocol Suite. F. Baker, J. Polk. May 2006. (Format: TXT=99770 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Baker
Request for Comments: 4542 J. Polk
Category: Informational Cisco Systems
May 2006
コメントを求めるワーキンググループF.ベイカー要求をネットワークでつないでください: 4542年のJ.ポークカテゴリ: 情報のシスコシステムズ2006年5月
Implementing an Emergency Telecommunications Service (ETS) for
Real-Time Services in the Internet Protocol Suite
非常時のテレコムサービス(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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.
RFCs3689と3690はEmergency Telecommunications Service(ETS)のための要件を詳しく述べます。(そこでは、インターネットEmergency Preparedness Service(IEPS)は部分でしょう)。 これらのタイプのサービスのいくつかが呼び出し先取りを必要とします。 他のものは呼び出しの列を作りか他のメカニズムを必要とします。IEPSはこの構造の需要を満たすデータのために、Call Admission Control(CAC)手順とPer Hop Behavior(PHB)を必要とします。 そのようなCAC手順とPHBはリアルタイムのセッションをセットアップするのにH.323かSIPを使用するかもしれないどんなサービスにも適切です。 主要な要件は危機について時間内に呼び出し完成の高い確率を認定ユーザに保証することです。
This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations.
このドキュメントは、米国政府とNATOの文脈でETSを支持するのを主として議論します、Multi-レベルPrecedence、Preemption(MLPP)、および政府Emergency Telecommunication Service(GETS)規格に焦点を合わせるので。 ここで説明された構造はこれらの組織を超えて適切です。
Baker & Polk Informational [Page 1] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[1ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
Table of Contents
目次
1. Overview of the Internet Emergency Preference Service
Problem and Proposed Solutions ..................................3
1.1. Emergency Telecommunications Services ......................3
1.1.1. Multi-Level Preemption and Precedence ...............4
1.1.2. Government Emergency Telecommunications Service .....6
1.2. Definition of Call Admission ...............................6
1.3. Assumptions about the Network ..............................7
1.4. Assumptions about Application Behavior .....................7
1.5. Desired Characteristics in an Internet Environment .........9
1.6. The Use of Bandwidth as a Solution for QoS ................10
2. Solution Proposal ..............................................11
2.1. Call Admission/Preemption Procedure .......................12
2.2. Voice Handling Characteristics ............................15
2.3. Bandwidth Admission Procedure .............................17
2.3.1. RSVP Admission Using Policy for Both
Unicast and Multicast Sessions .....................17
2.3.2. RSVP Scaling Issues ................................19
2.3.3. RSVP Operation in Backbones and Virtual
Private Networks (VPNs) ............................19
2.3.4. Interaction with the Differentiated
Services Architecture ..............................21
2.3.5. Admission Policy ...................................21
2.4. Authentication and Authorization of Calls Placed ..........23
2.5. Defined User Interface ....................................23
3. Security Considerations ........................................24
4. Acknowledgements ...............................................24
5. References .....................................................25
5.1. Normative References ......................................25
5.2. Informative References ....................................27
Appendix A. 2-Call Preemption Example using RSVP .................29
1. インターネット非常時の好みのサービス問題と提案されたソリューションの概観…3 1.1. 非常時の遠距離通信サービス…3 1.1.1. マルチ平らな先取りと先行…4 1.1.2. 政府非常時のテレコムサービス…6 1.2. コール許可の定義…6 1.3. ネットワークに関する仮定…7 1.4. アプリケーションの振舞いに関する仮定…7 1.5. インターネット環境における特性を望んでいます…9 1.6. ソリューションとしての帯域幅のQoSの使用…10 2. ソリューション提案…11 2.1. 手順に入場/先取りに電話をしてください…12 2.2. 取り扱いの特性を声に出してください…15 2.3. 帯域幅入学者選抜…17 2.3.1. ユニキャストとマルチキャストセッションの両方に方針を使用するRSVP入場…17 2.3.2. RSVPスケーリング問題…19 2.3.3. 背骨と仮想私設網(VPNs)におけるRSVP操作…19 2.3.4. 微分されたサービス構造との相互作用…21 2.3.5. 入場方針…21 2.4. 出された電話の認証と認可…23 2.5. ユーザーインタフェースを定義します…23 3. セキュリティ問題…24 4. 承認…24 5. 参照…25 5.1. 標準の参照…25 5.2. 有益な参照…RSVPを使用する27の付録のA.の2呼び出ししている先取りの例…29
Baker & Polk Informational [Page 2] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[2ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
1. Overview of the Internet Emergency Preference Service Problem and
Proposed Solutions
1. インターネット非常時の好みのサービス問題と提案されたソリューションの概観
[RFC3689] and [RFC3690] detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preference Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.
[RFC3689]と[RFC3690]はEmergency Telecommunications Service(ETS)のための要件を詳しく述べます。(そこでは、インターネットEmergency Preference Service(IEPS)は部分でしょう)。 これらのタイプのサービスのいくつかが呼び出し先取りを必要とします。 他のものは呼び出しの列を作りか他のメカニズムを必要とします。主要な要件は危機について時間内に呼び出し完成の高い確率を認定ユーザに保証することです。
IEPS requires a Call Admission Control procedure and a Per Hop Behavior for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. These obviously include but are not limited to Voice and Video applications, although at this writing the community is mostly thinking about Voice on IP, and many of the examples in the document are taken from that environment.
IEPSはこの構造の需要を満たすデータのためにCall Admission Control手順とPer Hop Behaviorを必要とします。 そのようなCAC手順とPHBはリアルタイムのセッションをセットアップするのにH.323かSIPを使用するかもしれないどんなサービスにも適切です。 VoiceとVideoアプリケーションに含んでいますが、これらは明らかに限られていません、この文を草するときに共同体がIPでVoiceについてほとんど考えています、そして、その環境からドキュメントの例の多くを取りますが。
In a network where a call permitted initially is not denied or rejected at a later time, capacity admission procedures performed only at the time of call setup may be sufficient. However, in a network where session status can be reviewed by the network and preempted or denied due to changes in routing (when the new routes lack capacity to carry calls switched to them) or changes in offered load (where higher precedence calls supersede existing calls), maintaining a continuing model of the status of the various calls is required.
初めは受入れられた呼び出しが後で否定もされませんし、拒絶もされないネットワークでは、呼び出しセットアップ単に時点で実行された容量入学者選抜は十分であるかもしれません。 しかしながら、提供された負荷(より高い先行呼び出しが既存の呼び出しに取って代わるところ)におけるセッション状態がルーティングにおける変化のためネットワークによって調査されて、先取りされる場合があるか、または否定される場合がある(新しいルートがそれらに切り換えられた呼び出しを運ぶ能力を欠いていると)ネットワークか変化で様々な呼び出しの状態の継続するモデルを維持するのが必要です。
1.1. Emergency Telecommunications Services
1.1. 非常時の遠距離通信サービス
Before doing so, however, let us discuss the problem that ETS (and therefore IEPS) is intended to solve and the architecture of the system. The Emergency Telecommunications Service [ITU.ETS.E106] is a successor to and generalization of two services used in the United States: Multi-Level Precedence and Preemption (MLPP), and the Government Emergency Telecommunication Service (GETS). Services based on these models are also used in a variety of countries throughout the world, both Public Switched Telephone Network (PSTN) and Global System for Mobile Communications (GSM)-based. Both of these services are designed to enable an authorized user to obtain service from the telephone network in times of crisis. They differ primarily in the mechanisms used and number of levels of precedence acknowledged.
しかしながら、そうする前に、ETS(そして、したがって、IEPS)が解決することを意図する問題とシステムの構造について議論しましょう。 Emergency Telecommunications Service[ITU.ETS.E106]は合衆国で利用された2つのサービスの後継者と一般化です: マルチレベル先行、先取り(MLPP)、および政府非常時の電気通信サービス(得ます)。 また、これらのモデルに基づくサービスは世界、Public Switched Telephone Network(PSTN)と汎欧州デジタルセルラーシステムの両方中で(GSM)を拠点とするさまざまな国で利用されます。 これらのサービスの両方が、認定ユーザが危機の時代に電話網からサービスを得るのを可能にするように設計されています。 彼らは主として使用されるメカニズムと承諾された先行のレベルの数において異なります。
Baker & Polk Informational [Page 3] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[3ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
1.1.1. Multi-Level Preemption and Precedence
1.1.1. マルチレベル先取りと先行
The Assured Service is designed as an IP implementation of an existing ITU-T/NATO/DoD telephone system architecture known as Multi-Level Precedence and Preemption [ITU.MLPP.1990] [ANSI.MLPP.Spec] [ANSI.MLPP.Supp], or MLPP. MLPP is an architecture for a prioritized call handling service such that in times of emergency in the relevant NATO and DoD commands, the relative importance of various kinds of communications is strictly defined, allowing higher-precedence communication at the expense of lower- precedence communications. This document describes NATO and US Department of Defense uses of MLPP, but the architecture and standard are applicable outside of these organizations.
Assured ServiceはMulti-レベルPrecedenceとPreemption[ITU.MLPP.1990][ANSI.MLPP.Spec][ANSI.MLPP.Supp]か、MLPPとして知られている既存のITU-T/NATO/DoD電話システム構築のIP実現として設計されています。 MLPPが最優先する呼び出し取り扱いサービスのための構造であるので、非常のときに関連NATOとDoDコマンドでは、様々な種類に関するコミュニケーションの相対的な重要性は厳密に定義されます、低い先行コミュニケーションを犠牲にして、より高い先行コミュニケーションを許容して。 このドキュメントはMLPPのNATOと米国国防総省用途について説明しますが、構造と規格は外でこれらの組織で適切です。
These precedences, in descending order, are:
これらの先行は降順に以下の通りです。
Flash Override Override: used by the Commander in Chief, Secretary
of Defense, and Joint Chiefs of Staff, commanders of combatant
commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency or Air Defense Emergency and other
national authorities that the President may authorize in
conjunction with Worldwide Secure Voice Conferencing System
conferences. Flash Override Override cannot be preempted. This
precedence level is not enabled on all DoD networks.
オーバーライドオーバーライドをひらめかせてください: 戦争の状態の存在を宣言するとき、最高司令官、国防長官、および統合参謀本部のそばで使用されていて、戦闘員の指揮官は命令します。 Defense Condition OneかDefense EmergencyかAir Defense Emergencyと社長がWorldwide Secure Voice Conferencing System会議に関連して認可するかもしれない他の国内当局を申告するとき、戦闘員の指揮官は命令します。 フラッシュOverride Overrideを先取りできません。 この先行レベルはすべてのDoDネットワークで可能にされません。
Flash Override: used by the Commander in Chief, Secretary of
Defense, and Joint Chiefs of Staff, commanders of combatant
commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency and other national authorities the
President may authorize. Flash Override cannot be preempted in
the DSN.
オーバーライドをひらめかせてください: 戦争の状態の存在を宣言するとき、最高司令官、国防長官、および統合参謀本部のそばで使用されていて、戦闘員の指揮官は命令します。 Defense Condition OneかDefense Emergencyと社長が認可するかもしれない他の国内当局を申告するとき、戦闘員の指揮官は命令します。 DSNでフラッシュOverrideを先取りできません。
Flash: reserved generally for telephone calls pertaining to command
and control of military forces essential to defense and
retaliation, critical intelligence essential to national survival,
conduct of diplomatic negotiations critical to the arresting or
limiting of hostilities, dissemination of critical civil alert
information essential to national survival, continuity of federal
government functions essential to national survival, fulfillment
of critical internal security functions essential to national
survival, or catastrophic events of national or international
significance.
フラッシュ: ディフェンスと報復に不可欠の軍事力を一般に、コマンドに関係する通話のために控えて、制御してください、国家の生存に不可欠のきわどい知性、戦争の心臓発作を起こすか制限に重要な外交交渉の行為; 国家の生存に不可欠の批判的な民間注意深い情報の普及、連邦政府の連続は国家の生存に不可欠の状態で機能します、国家の生存、または国家的、または、国際的な意味の大惨事に不可欠のきわどい国内保安機能の遂行。
Immediate: reserved generally for telephone calls pertaining to
situations that gravely affect the security of national and allied
forces, reconstitution of forces in a post-attack period,
即座: 一般に、ポスト攻撃時代に国家のセキュリティと同盟軍部隊、力の再構成に厳粛に影響する状況に関係する通話において、予約されています。
Baker & Polk Informational [Page 4] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[4ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
intelligence essential to national security, conduct of diplomatic
negotiations to reduce or limit the threat of war, implementation
of federal government actions essential to national survival,
situations that gravely affect the internal security of the
nation, Civil Defense actions, disasters or events of extensive
seriousness having an immediate and detrimental effect on the
welfare of the population, or vital information having an
immediate effect on aircraft, spacecraft, or missile operations.
国家安全保障に不可欠の知性、戦争の脅威を抑えるか、または制限する外交交渉の行為、国家の生存に不可欠の連邦政府動きの実現、大規模な重大さの国、Civil Defense動作、災害または出来事が人口の福祉に即座の、そして、有害な効果を持っているか、または極めて重要な情報が航空機の上でてきめんに利く国内保安に厳粛に影響する状況、宇宙船、またはミサイル操作。
Priority: reserved generally for telephone calls requiring
expeditious action by called parties and/or furnishing essential
information for the conduct of government operations.
優先権: 一般に、迅速な動作を必要とする通話のために被呼者によって予約される、そして/または、官営の行為のために不可欠の情報を提供すること。
Routine: designation applied to those official government
communications that require rapid transmission by telephonic means
but do not require preferential handling.
ルーチン: 名称は電話の手段で速い伝達を必要としますが、優先の取り扱いは必要としないそれらの公式の政府コミュニケーションに適用されました。
MLPP is intended to deliver a higher probability of call completion to the more important calls. The rule, in MLPP, is that more important calls override less important calls when congestion occurs within a network. Station-based preemption is used when a more important call needs to be placed to either party in an existing call. Trunk-based preemption is used when trunk bandwidth needs to be reallocated to facilitate a higher-precedence call over a given path in the network. In both station- and trunk-based preemption scenarios, preempted parties are positively notified, via preemption tone, that their call can no longer be supported. The same preemption tone is used, regardless of whether calls are terminated for the purposes of station- of trunk-based preemption. The remainder of this discussion focuses on trunk-based preemption issues.
MLPPが呼び出し完成の、より高い確率をより重要な呼び出しに送ることを意図します。 MLPPでは、規則は混雑がネットワークの中に起こると、より重要な呼び出しがそれほど重要でない呼び出しをくつがえすということです。 より重要な呼び出しが、既存の呼び出しで何れの当事者に置かれる必要があるとき、駅のベースの先取りは使用されています。 トランク帯域幅が、ネットワークで与えられた経路の上の、より高い先行呼び出しを容易にするために再割当てされる必要があるとき、トランクベースの先取りは使用されています。 ステーションとトランクベースの先取りシナリオの両方では、先取りトーンで先取りされたパーティーはもう彼らの呼び出しを支持できないように明確に通知されます。 呼び出しがトランクベースの先取りのステーションの目的のために終えられるかどうかにかかわらず同じ先取りトーンは使用されます。 この議論の残りはトランクベースの先取り問題に焦点を合わせます。
MLPP is built as a proactive system in which callers must assign one of the precedence levels listed above at call initiation; this precedence level cannot be changed throughout that call. If an elevated status is not assigned by a user at call initiation time, the call is assumed to be "routine". If there is end-to-end capacity to place a call, any call may be placed at any time. However, when any trunk group (in the circuit world) or interface (in an IP world) reaches a utilization threshold, a choice must be made as to which calls to accept or allow to continue. The system will seize the trunk(s) or bandwidth necessary to place the more important calls in preference to less important calls by preempting an existing call (or calls) of lower precedence to permit a higher-precedence call to be placed.
訪問者が先行レベルの1つを割り当てなければならない先を見越すシステムが呼び出し開始に上に記載したようにMLPPは組立しています。 その呼び出しの間中ときのこの先行レベルを変えることができません。 高い状態が呼び出し開始時間にユーザによって割り当てられないなら、呼び出しが「通常である」と思われます。 電話をする終わりから終わりへの能力があれば、どんな電話もいつでも、出されるかもしれません。 しかしながら、どんなトランクグループ(サーキット世界の)やインタフェース(IP世界の)も利用敷居に達するとき、どの呼び出しが続くのを受け入れたらよいか、または許容したらよいかに関して選択をしなければなりません。 システムは下側の先行が置かれるというより高い先行要求を可能にするという既存の要求(または、呼ぶ)を先取りするのによるそれほど重要でない呼び出しに優先して、より重要な電話をするのに必要なトランクか帯域幅を捕らえるでしょう。
Baker & Polk Informational [Page 5] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[5ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
More than one call might properly be preempted if more trunks or bandwidth is necessary for this higher precedence call. A video call (perhaps of 384 KBPS, or 6 trunks) competing with several lower- precedence voice calls is a good example of this situation.
1つ以上の呼び出しが、より多くのトランクスであるなら適切に先取りされるかもしれませんか、または帯域幅がこのより高い先行呼び出しに必要です。 いくつかの下側の先行音声通話と競争するビデオ通話(恐らく384KBPS、または6個のトランクスの)はこの状況の好例です。
1.1.2. Government Emergency Telecommunications Service
1.1.2. 政府非常時のテレコムサービス
A US service similar to MLPP and using MLPP signaling technology, but built for use in civilian networks, is the Government Emergency Telecommunications Service (GETS). This differs from MLPP in two ways: it does not use preemption, but rather reserves bandwidth or queues calls to obtain a high probability of call completion, and it has only two levels of service: "Routine" and "Priority".
MLPPと同様の米国のサービスと民間ネットワークにおける使用のために技術に合図しますが、造られたMLPPを使用するのは、政府Emergency Telecommunications Service(GETS)です。 これは2つの方法でMLPPと異なっています: それは、先取りを使用しませんが、むしろ帯域幅を控えるか、または呼び出し完成の高い確率を得るという要求を列に並ばせます、そして、2つのレベルのサービスしかありません: 「ルーチン」と「優先権。」
GETS is described here as another example. Similar architectures are applied by other governments and organizations.
GETSはここで別の例と説明されます。 同様の構造は他の政府と組織によって適用されます。
1.2. Definition of Call Admission
1.2. コール許可の定義
Traditionally, in the PSTN, Call Admission Control (CAC) has had the responsibility of implementing bandwidth available thresholds (e.g., to limit resources consumed by some traffic) and determining whether a caller has permission (e.g., is an identified subscriber, with identify attested to by appropriate credentials) to use an available circuit. IEPS, or any emergency telephone service, has additional options that it may employ to improve the probability of call completion:
PSTNでは、伝統的に、Call Admission Control(CAC)が帯域幅の利用可能な敷居(例えば何らかの交通で消費されたリソースを制限する)を実行して、訪問者には許可があるかどうか決定する責任を持っていた、(例えば、特定された加入者、証明されて、同一視する、適切な信任状) 利用可能なサーキットを使用するために。 IEPS、またはどんな緊急電話サービスにも、それが呼び出し完成の確率を改良するのに使うかもしれない追加オプションがあります:
o The call may be authorized to use other networks that it would not
normally use;
o 呼び出しが通常、それが使用しない他のネットワークを使用するのが認可されるかもしれません。
o The network may preempt other calls to free bandwidth;
o ネットワークは帯域幅を解放するという他の要求を先取りするかもしれません。
o The network may hold the call and place it when other calls
complete; or
o ネットワークは他ときにそれが完全な状態で呼ぶ電話と場所を保持するかもしれません。 または
o The network may use different bandwidth availability thresholds
than are used for other calls.
o ネットワークは他の呼び出しに使用されるのと異なった帯域幅有用性敷居を使用するかもしれません。
At the completion of CAC, however, the caller either has a circuit that he or she is authorized to use or has no circuit. Since the act of preemption or consideration of alternative bandwidth sources is part and parcel of the problem of providing bandwidth, the authorization step in bandwidth provision also affects the choice of networks that may be authorized to be considered. The three cannot be separated. The CAC procedure finds available bandwidth that the caller is authorized to use and preemption may in some networks be part of making that happen.
しかしながら、CACの完成のときに、訪問者には、その人が使用するのを権限を与えられるサーキットを持っているか、またはサーキットが全くありません。 先取りの行為か代替の帯域幅源の考慮が帯域幅を供給するという問題の重要部分であるので、また、帯域幅支給における認可ステップは考えられるのが認可されるかもしれないネットワークの選択に影響します。 3を切り離すことができません。 CAC手順によって、訪問者が使用するのに権限を与えられて、先取りがいくつかのネットワークでそうするかもしれない利用可能な帯域幅がそれを起こらせる一部であることがわかります。
Baker & Polk Informational [Page 6] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[6ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
1.3. Assumptions about the Network
1.3. ネットワークに関する仮定
IP networks generally fall into two categories: those with constrained bandwidth, and those that are massively over-provisioned. In a network where over any interval that can be measured (including sub-second intervals) capacity exceeds offered load by at least 2:1, the jitter and loss incurred in transit are nominal. This is generally a characteristic of properly engineered Ethernet LANs and of optical networks (networks that measure their link speeds in multiples of 51 MBPS); in the latter, circuit-switched networking solutions such as Asynchronous Transfer Mode (ATM), MPLS, and GMPLS can be used to explicitly place routes, which improves the odds a bit.
一般に、IPネットワークは2つのカテゴリになります: 強制的な帯域幅があるそれら、および膨大に食糧を供給され過ぎるもの。 測定できるどんな間隔にわたっても容量が超えている(サブ2番目の間隔を含んでいます)が少なくとも2:1までに負荷を提供したネットワークでは、トランジットで被られたジターと損失はわずかです。 一般に、これは適切に設計されたイーサネットLANと光学ネットワークの特性(51MBPSの倍数におけるそれらのリンク速度を測定するネットワーク)です。 後者では、明らかにルートを置くのにAsynchronous Transfer Mode(ATM)や、MPLSや、GMPLSなどのサーキットで切り換えられたネットワークソリューションを使用できます(可能性を少し改良します)。
Between those networks, in places commonly called "inter-campus links", "access links", or "access networks", for various reasons including technology (e.g., satellite links) and cost, it is common to find links whose offered load can approximate or exceed the available capacity. Such events may be momentary or may occur for extended periods of time.
それらのネットワークの間では、一般的に「インターキャンパスリンク」、「アクセスリンク」、または「アクセスネットワーク」と呼ばれる場所では技術を含む様々な理由(例えば、衛星中継)と費用で、提供された負荷が有効な容量を近似するか、または超えることができるリンクを見つけるのが一般的です。 そのような出来事は、瞬間であるかもしれない、または延ばされた期間に起こるかもしれません。
In addition, primarily in tactical deployments, it is common to find bandwidth constraints in the local infrastructure of networks. For example, the US Navy's network afloat connects approximately 300 ships, via satellite, to five network operation centers (NOCs), and those NOCs are in turn interconnected via the Defense Information Systems Agency (DISA) backbone. A typical ship may have between two and six radio systems aboard, often at speeds of 64 KBPS or less. In US Army networks, current radio technology likewise limits tactical communications to links below 100 KBPS.
さらに、主として戦術の展開では、ネットワークのローカルのインフラストラクチャにおける帯域幅規制を見つけるのは一般的です。 例えば、海軍のものが浮かんでネットワークでつなぐ米国はおよそ300隻の船を接続します、衛星を通して、5つのネットワークオペレーション・センター(NOCs)に、そして、それらのNOCsが防衛情報システム庁(DISA)背骨で順番にインタコネクトされます。 典型的な船は船舶にしばしば64KBPSの速度で2〜6台のラジオシステムを持っているかもしれません。 米国陸軍ネットワークでは、現在のラジオ技術は同様に戦術のコミュニケーションを100KBPSの下のリンクに制限します。
Over this infrastructure, military communications expect to deploy voice communication systems (30-80 KBPS per session) and video conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800 KBPS), in addition to traditional mail, file transfer, and transaction traffic.
このインフラストラクチャに関して、軍事通信は、MPEG2(3-7 MBPS)とMPEG4(800KBPSへの80KBPS)を使用することで音声通信系(30-80 1セッションあたりのKBPS)とビデオ会議を配備すると予想します、伝統的なメール、ファイル転送、および取引交通に加えて。
1.4. Assumptions about Application Behavior
1.4. アプリケーションの振舞いに関する仮定
Parekh and Gallagher published a series of papers [Parekh1] [Parekh2] analyzing what is necessary to ensure a specified service level for a stream of traffic. In a nutshell, they showed that to predict the behavior of a stream of traffic in a network, one must know two things:
Parekhとギャラガーは、交通の流れのために指定されたサービスレベルを確実にするのに必要なことを分析しながら、一連の論文[Parekh1][Parekh2]を発行しました。 殻では、彼らは、ネットワークの交通の流れの働きを予測するために、2つのことを知らなければならないのを示しました:
o the rate and arrival distribution with which traffic in a class is
introduced to the network, and
o そしてどの交通がクラスにあるか状態でレートと到着分配がネットワークに取り入れられる。
Baker & Polk Informational [Page 7] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[7ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
o what network elements will do, in terms of the departure
distribution, injected delay jitter, and loss characteristics,
with the traffic they see.
o ネットワーク要素が出発分配ですることは遅れジター、および損失の特性を注入しました、それらが見る交通で。
For example, TCP tunes its effective window (the amount of data it sends per round trip interval) so that the ratio of the window and the round trip interval approximate the available capacity in the network. As long as the round trip delay remains roughly stable and loss is nominal (which are primarily behaviors of the network), TCP is able to maintain a predictable level of throughput. In an environment where loss is random or in which delays wildly vary, TCP behaves in a far less predictable manner.
例えば、TCPが有効な窓(それが周遊旅行間隔単位で送るデータ量)を調整するので、窓の比率と周遊旅行間隔はネットワークで有効な容量に近似します。 周遊旅行遅れがおよそ安定した状態を保って、損失がわずかである(主としてネットワークの振舞いです)限り、TCPは予測できるレベルに関するスループットを維持できます。 損失が無作為であるか、または遅れがむやみやたらに異なる環境で、TCPははるかに予測できない態度で振る舞います。
Voice and video systems, in the main, are designed to deliver a fixed level of quality as perceived by the user. (Exceptions are systems that select rate options over a broad range to adapt to ambient loss characteristics. These deliver broadly fluctuating perceived quality and have not found significant commercial applicability.) Rather, they send traffic at a rate specified by the codec depending on what it perceives is required. In an MPEG-4 system, for example, if the camera is pointed at a wall, the codec determines that an 80 KBPS data stream will describe that wall and issues that amount of traffic. If a person walks in front of the wall or the camera is pointed an a moving object, the codec may easily send 800 KBPS in its effort to accurately describe what it sees. In commercial broadcast sports, which may line up periods in which advertisements are displayed, the effect is that traffic rates suddenly jump across all channels at certain times because the eye-catching ads require much more bandwidth than the camera pointing at the green football field.
メインでは、声とビデオシステムは、ユーザによって知覚されるように固定レベルの品質を送るように設計されています。 (例外は周囲の損失の特性に順応するために広い声域の上のレートオプションを選択するシステムです。 これらは、品質であると知覚された変動を広く渡して、重要な商業適用性を見つけていません。) むしろ、彼らはことに必要であるそれが知覚するよるコーデックによって指定されたレートで交通を送ります。 MPEG-4システムでは、例えば、カメラは壁を指されているなら、コーデックが、データが流す80KBPSが交通のその壁と達する問題について説明することを決定します。 人が壁の正面を歩くか、またはカメラが向けられているなら、aが物体を動かす場合、コーデックはそれが何を見るかを正確に説明するための努力で容易に800KBPSを送るかもしれません。 広告放送スポーツでは、効果は人目を惹いた広告が緑色のフットボール競技場を指し示すカメラよりはるかに多くの帯域幅を必要とするので交通率が、ある時に突然オール・チャンネルを飛び越えるということです。(スポーツは広告が表示される期間まで立ち並ぶかもしれません)。
As described in [RFC1633], when dealing with a real-time application, there are basically two things one must do to ensure Parekh's first requirement. To ensure that one knows how much offered load the application is presenting, one must police (measure load offered and discard excess) traffic entering the network. If that policing behavior has a debilitating effect on the application, as non- negligible loss has on voice or video, one must admit sessions judiciously according to some policy. A key characteristic of that policy must be that the offered load does not exceed the capacity dedicated to the application.
リアルタイムのアプリケーションに対処するとき、[RFC1633]で説明されるように、Parekhの最初の要件を確実にするためにしなければならない2つのことが基本的にあります。 人が、いくらがアプリケーションが提示している負荷を提供したかを知っているのを保証するために、ネットワークに入る交通を取り締まらなければなりません(提供された負荷を測定して、過剰を捨てます)。 その取り締まりの振舞いが非取るにたらない損失が与えたように声かビデオの上に弱らせる影響をアプリケーションに与えるなら、何らかの方針によると、賢明にセッションを認めなければなりません。 その方針の主要な特性は提供された負荷がアプリケーションに捧げられた容量を超えていないということであるに違いありません。
In the network, the other thing one must do is ensure that the application's needs are met in terms of loss, variation in delay, and end-to-end delay. One way to do this is to supply sufficient bandwidth so that loss and jitter are nominal. Where that cannot be accomplished, one must use queuing technology to deterministically apply bandwidth to accomplish the goal.
ネットワークでは、もう片方の人がしなければならないことはアプリケーションの需要が損失、遅れの変化、および終わりから終わりへの遅れで満たされるのを確実にすることです。 これをする1つの方法が十分な帯域幅を供給することであるので、損失とジターはわずかです。 それを達成できないところでは、目標を達成するのに決定論的に帯域幅を適用する列を作り技術を使用しなければなりません。
Baker & Polk Informational [Page 8] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[8ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
1.5. Desired Characteristics in an Internet Environment
1.5. インターネット環境における必要な特性
The key elements of the Internet Emergency Preference Service include the following:
インターネットEmergency Preference Serviceの主要な要素は以下を含んでいます:
Precedence Level Marking each call: Call initiators choose the
appropriate precedence level for each call based on the user-
perceived importance of the call. This level is not to be changed
for the duration of the call. The call before and the call after
are independent with regard to this level choice.
先行Level Markingはそれぞれ呼びます: 呼び出し創始者は呼び出しの重要性であると知覚されたユーザに基づく各呼び出しのための適切な先行レベルを選びます。 このレベルは呼び出しの持続時間のために変えられないことです。 以前、電話をしてください。そうすれば、呼び出しはこの平らな選択に関して後に独立しています。
Call Admission/Preemption Policy: There is likewise a clear policy
regarding calls that may be in progress at the called instrument.
During call admission (SIP/H.323), if they are of lower
precedence, they must make way according to a prescribed
procedure. All callers on the preempted call must be informed
that the call has been preempted, and the call must make way for
the higher-precedence call.
方針に入場/先取りに電話をしてください: 同様に、呼ばれた器具で進行しているかもしれない呼び出しに関する明確な方針があります。 コール許可(SIP/H.323)の間、それらが下側に上位であるなら、処方された手順によると、彼らは出世しなければなりません。 呼び出しが先取りされて、呼び出しが、より高い先行呼び出しに道をあけなければならないと先取りされた呼び出しでのすべての訪問者を知らさなければなりません。
Bandwidth Admission Policy: There is a clear bandwidth admission
policy: sessions may be placed that assert any of several levels
of precedence, and in the event that there is demand and
authorization is granted, other sessions will be preempted to make
way for a call of higher precedence.
帯域幅入場方針: 明確な帯域幅入場方針があります: 先行のいくつかのレベルのいずれも断言するセッションは置かれるかもしれません、そして、要求があって、認可が承諾されると、他のセッションは、より高い先行の呼び出しに道をあけるために先取りされるでしょう。
Authentication and Authorization of calls placed: Unauthorized
attempts to place a call at an elevated status are not permitted.
In the telephone system, this is managed by controlling the policy
applied to an instrument by its switch plus a code produced by the
caller identifying himself or herself to the switch. In the
Internet, such characteristics must be explicitly signaled.
呼び出しの認証とAuthorizationは入賞しました: 高い状態に呼び出しをみなす権限のない試みは受入れられません。 電話では、これは、スイッチによって器具に適用された方針と自分か身元をスイッチに明らかにする訪問者によって作成されたコードを制御することによって、管理されます。 インターネットでは、明らかにそのような特性に合図しなければなりません。
Voice handling characteristics: A call made, in the telephone
system, gets a circuit and provides the means for the callers to
conduct their business without significant impact as long as their
call is not preempted. In a VoIP system, one would hope for
essentially the same service.
取り扱いの特性を声に出してください: 電話でかけられる電話は、サーキットを手に入れて、彼らの呼び出しが先取りされない限り、訪問者が重要な影響なしで彼らの業務を行う手段を提供します。 VoIPシステムでは、人は本質的には同じサービスを期待するでしょう。
Defined User Interface: If a call is preempted, the caller and the
callee are notified via a defined signal, so that they know that
their call has been preempted and that at this instant there is no
alternative circuit available to them at that precedence level.
定義されたユーザーインタフェース: 呼び出しが先取りされるなら、定義された信号で訪問者と訪問される人は通知されます、彼らが彼らの呼び出しが先取りされて、そこのこの瞬間のそれがそれらに、その先行レベルで利用可能な代替のサーキットでないことを知るように。
A VoIP implementation of the Internet Emergency Preference Service must, by definition, provide those characteristics.
インターネットEmergency Preference ServiceのVoIP実現は定義上それらの特性を提供しなければなりません。
Baker & Polk Informational [Page 9] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[9ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
1.6. The Use of Bandwidth as a Solution for QoS
1.6. ソリューションとしての帯域幅のQoSの使用
There is a discussion in Internet circles concerning the relationship of bandwidth to QoS procedures, which needs to be put to bed before this procedure can be adequately analyzed. The issue is that it is possible and common in certain parts of the Internet to solve the problem with bandwidth. In LAN environments, for example, if there is significant loss between any two switches or between a switch and a server, the simplest and cheapest solution is to buy the next faster interface: substitute 100 MBPS for 10 MBPS Ethernet, 1 gigabit for 100 MBPS, or, for that matter, upgrade to a 10-gigabit Ethernet. Similarly, in optical networking environments, the simplest and cheapest solution is often to increase the data rate of the optical path either by selecting a faster optical carrier or deploying an additional lambda. In places where the bandwidth can be over- provisioned to a point where loss or queuing delay are negligible, 10:1 over-provisioning is often the cheapest and surest solution and, by the way, offers a growth path for future requirements. However, there are many places in communication networks where the provision of effectively infinite bandwidth is not feasible, including many access networks, satellite communications, fixed wireless, airborne and marine communications, island connections, and connections to regions in which fiber optic connections are not cost-effective. It is in these places where the question of resource management is relevant. Specifically, we do not recommend the deployment of significant QoS procedures on links in excess of 100 MBPS apart from the provision of aggregated services that provide specific protection to the stability of the network or the continuity of real-time traffic as a class, as the mathematics of such circuits do not support this as a requirement.
There is a discussion in Internet circles concerning the relationship of bandwidth to QoS procedures, which needs to be put to bed before this procedure can be adequately analyzed. The issue is that it is possible and common in certain parts of the Internet to solve the problem with bandwidth. In LAN environments, for example, if there is significant loss between any two switches or between a switch and a server, the simplest and cheapest solution is to buy the next faster interface: substitute 100 MBPS for 10 MBPS Ethernet, 1 gigabit for 100 MBPS, or, for that matter, upgrade to a 10-gigabit Ethernet. Similarly, in optical networking environments, the simplest and cheapest solution is often to increase the data rate of the optical path either by selecting a faster optical carrier or deploying an additional lambda. In places where the bandwidth can be over- provisioned to a point where loss or queuing delay are negligible, 10:1 over-provisioning is often the cheapest and surest solution and, by the way, offers a growth path for future requirements. However, there are many places in communication networks where the provision of effectively infinite bandwidth is not feasible, including many access networks, satellite communications, fixed wireless, airborne and marine communications, island connections, and connections to regions in which fiber optic connections are not cost-effective. It is in these places where the question of resource management is relevant. Specifically, we do not recommend the deployment of significant QoS procedures on links in excess of 100 MBPS apart from the provision of aggregated services that provide specific protection to the stability of the network or the continuity of real-time traffic as a class, as the mathematics of such circuits do not support this as a requirement.
In short, the fact that we are discussing this class of policy control says that such constrictions in the network exist and must be dealt with. However much we might like to, in those places we are not solving the problem with bandwidth.
In short, the fact that we are discussing this class of policy control says that such constrictions in the network exist and must be dealt with. However much we might like to, in those places we are not solving the problem with bandwidth.
Baker & Polk Informational [Page 10] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 10] RFC 4542 ETS in an IP Network May 2006
2. Solution Proposal
2. Solution Proposal
A typical voice or video network, including a backbone domain, is shown in Figure 1.
A typical voice or video network, including a backbone domain, is shown in Figure 1.
............... ......................
. . . .
. H H H H . . H H H H .
. /----------/ . . /----------/ .
. R SIP . . R R .
. \ . . / \ .
. R H H H . ....... / \ .
. /----------/ .. ../ R SIP .
. R .. /. /----------/ .
..... ..\. R-----R . H H H H .
...... .\ / \ . .
. \ / \ . .
. R-----------R ....................
. \ / .
. \ / .
. R-----R .
. .
............
............... ...................... . . . . . H H H H . . H H H H . . /----------/ . . /----------/ . . R SIP . . R R . . \ . . / \ . . R H H H . ....... / \ . . /----------/ .. ../ R SIP . . R .. /. /----------/ . ..... ..\. R-----R . H H H H . ...... .\ / \ . . . \ / \ . . . R-----------R .................... . \ / . . \ / . . R-----R . . . ............
SIP = SIP Proxy
H = SIP-enabled Host (Telephone, call gateway or PC)
R = Router
/---/ = Ethernet or Ethernet Switch
SIP = SIP Proxy H = SIP-enabled Host (Telephone, call gateway or PC) R = Router /---/ = Ethernet or Ethernet Switch
Figure 1: Typical VoIP or Video/IP Network
Figure 1: Typical VoIP or Video/IP Network
Reviewing the figure above, it becomes obvious that Voice/IP and Video/IP call flows are very different than call flows in the PSTN. In the PSTN, call control traverses a switch, which in turn controls data handling services like ATM or Time Division Multiplexing (TDM) switches or multiplexers. While they may not be physically co- located, the control plane software and the data plane services are closely connected; the switch routes a call using bandwidth that it knows is available. In a voice/video-on-IP network, call control is completely divorced from the data plane: It is possible for a telephone instrument in the United States to have a Swedish telephone number if that is where its SIP proxy happens to be, but on any given call for it to use only data paths in the Asia/Pacific region, data paths provided by a different company, and, often, data paths provided by multiple companies/providers.
Reviewing the figure above, it becomes obvious that Voice/IP and Video/IP call flows are very different than call flows in the PSTN. In the PSTN, call control traverses a switch, which in turn controls data handling services like ATM or Time Division Multiplexing (TDM) switches or multiplexers. While they may not be physically co- located, the control plane software and the data plane services are closely connected; the switch routes a call using bandwidth that it knows is available. In a voice/video-on-IP network, call control is completely divorced from the data plane: It is possible for a telephone instrument in the United States to have a Swedish telephone number if that is where its SIP proxy happens to be, but on any given call for it to use only data paths in the Asia/Pacific region, data paths provided by a different company, and, often, data paths provided by multiple companies/providers.
Baker & Polk Informational [Page 11] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 11] RFC 4542 ETS in an IP Network May 2006
Call management therefore addresses a variety of questions, all of which must be answered:
Call management therefore addresses a variety of questions, all of which must be answered:
o May I make this call from an administrative policy perspective?
Am I authorized to make this call?
o May I make this call from an administrative policy perspective? Am I authorized to make this call?
o What IP address correlates with this telephone number or SIP URI?
o What IP address correlates with this telephone number or SIP URI?
o Is the other instrument "on hook"? If it is busy, under what
circumstances may I interrupt?
o Is the other instrument "on hook"? If it is busy, under what circumstances may I interrupt?
o Is there bandwidth available to support the call?
o Is there bandwidth available to support the call?
o Does the call actually work, or do other impairments (loss, delay)
make the call unusable?
o Does the call actually work, or do other impairments (loss, delay) make the call unusable?
2.1. Call Admission/Preemption Procedure
2.1. Call Admission/Preemption Procedure
Administrative Call Admission is the objective of SIP and H.323. It asks fundamental questions like "What IP address is the callee at?" and "Did you pay your bill?".
Administrative Call Admission is the objective of SIP and H.323. It asks fundamental questions like "What IP address is the callee at?" and "Did you pay your bill?".
For a specialized policy like call preemption, two capabilities are necessary from an administrative perspective: [RFC4412] provides a way to communicate policy-related information regarding the precedence of the call; and [RFC4411] provides a reason code when a call fails or is refused, indicating the cause of the event. If it is a failure, it may make sense to redial the call. If it is a policy-driven preemption, even if the call is redialed it may not be possible to place the call. Requirements for this service are further discussed in [RFC3689].
For a specialized policy like call preemption, two capabilities are necessary from an administrative perspective: [RFC4412] provides a way to communicate policy-related information regarding the precedence of the call; and [RFC4411] provides a reason code when a call fails or is refused, indicating the cause of the event. If it is a failure, it may make sense to redial the call. If it is a policy-driven preemption, even if the call is redialed it may not be possible to place the call. Requirements for this service are further discussed in [RFC3689].
The SIP Communications Resource Priority Header (or RP Header) serves the call setup process with the precedence level chosen by the initiator of the call. The syntax is in the form:
The SIP Communications Resource Priority Header (or RP Header) serves the call setup process with the precedence level chosen by the initiator of the call. The syntax is in the form:
Resource Priority: namespace.priority level
Resource Priority: namespace.priority level
The "namespace" part of the syntax ensures the domain of significance to the originator of the call, and this travels end-to-end to the destination (called) device (telephone). If the receiving phone does not support the namespace, it can easily ignore the setup request. This ability to denote the domain of origin allows Service Level Agreements (SLAs) to be in place to limit the ability of an unknown requester to gain preferential treatment into an IEPS domain.
The "namespace" part of the syntax ensures the domain of significance to the originator of the call, and this travels end-to-end to the destination (called) device (telephone). If the receiving phone does not support the namespace, it can easily ignore the setup request. This ability to denote the domain of origin allows Service Level Agreements (SLAs) to be in place to limit the ability of an unknown requester to gain preferential treatment into an IEPS domain.
Baker & Polk Informational [Page 12] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 12] RFC 4542 ETS in an IP Network May 2006
For the DSN infrastructure, the header would look like this for a routine precedence level call:
For the DSN infrastructure, the header would look like this for a routine precedence level call:
Resource Priority: dsn.routine
Resource Priority: dsn.routine
The precedence level chosen in this header would be compared to the requester's authorization profile to use that precedence level. This would typically occur in the SIP first-hop Proxy, which can challenge many aspects of the call setup request including the requester's choice of precedence levels (verifying that they are not using a level they are not authorized to use).
The precedence level chosen in this header would be compared to the requester's authorization profile to use that precedence level. This would typically occur in the SIP first-hop Proxy, which can challenge many aspects of the call setup request including the requester's choice of precedence levels (verifying that they are not using a level they are not authorized to use).
The DSN has 5 precedence levels of IEPS, in descending order:
The DSN has 5 precedence levels of IEPS, in descending order:
dsn.flash-override
dsn.flash-override
dsn.flash
dsn.flash
dsn.immediate
dsn.immediate
dsn.priority
dsn.priority
dsn.routine
dsn.routine
The US Defense Red Switched Network (DRSN), as another example that was IANA-registered in [RFC4412], has 6 levels of precedence. The DRSN simply adds one precedence level higher than flash-override to be used by the President and a select few others:
The US Defense Red Switched Network (DRSN), as another example that was IANA-registered in [RFC4412], has 6 levels of precedence. The DRSN simply adds one precedence level higher than flash-override to be used by the President and a select few others:
drsn.flash-override-override
drsn.flash-override-override
Note that the namespace changed for this level. The lower 5 levels within the DRSN would also have this as their namespace for all DRSN-originated call setup requests.
Note that the namespace changed for this level. The lower 5 levels within the DRSN would also have this as their namespace for all DRSN-originated call setup requests.
The Resource-Priority Header (RPH) informs both the use of Differentiated Services Code Points (DSCPs) by the callee (who needs to use the same DSCP as the caller to obtain the same data path service) and to facilitate policy-based preemption of calls in progress, when appropriate.
The Resource-Priority Header (RPH) informs both the use of Differentiated Services Code Points (DSCPs) by the callee (who needs to use the same DSCP as the caller to obtain the same data path service) and to facilitate policy-based preemption of calls in progress, when appropriate.
Once a call is established in an IEPS domain, the Reason Header for Preemption, described in [RFC4411], ensures that all SIP nodes are synchronized to a preemption event occurring either at the endpoint or in a router that experiences congestion. In SIP, the normal indication for the end of a session is for one end system to send a BYE Method request as specified in [RFC3261]. This, too, is the proper means for signaling a termination of a call due to a
Once a call is established in an IEPS domain, the Reason Header for Preemption, described in [RFC4411], ensures that all SIP nodes are synchronized to a preemption event occurring either at the endpoint or in a router that experiences congestion. In SIP, the normal indication for the end of a session is for one end system to send a BYE Method request as specified in [RFC3261]. This, too, is the proper means for signaling a termination of a call due to a
Baker & Polk Informational [Page 13] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 13] RFC 4542 ETS in an IP Network May 2006
preemption event, as it essentially performs a normal termination with additional information informing the peer of the reason for the abrupt end: it indicates that a preemption occurred. This will be used to inform all relevant SIP entities, and whether this was an endpoint-generated preemption event, or that the preemption event occurred within a router along the communications path (described in Section 2.3.1).
preemption event, as it essentially performs a normal termination with additional information informing the peer of the reason for the abrupt end: it indicates that a preemption occurred. This will be used to inform all relevant SIP entities, and whether this was an endpoint-generated preemption event, or that the preemption event occurred within a router along the communications path (described in Section 2.3.1).
Figure 2 is a simple example of a SIP call setup that includes the layer 7 precedence of a call between Alice and Bob. After Alice successfully sets up a call to Bob at the "Routine" precedence level, Carol calls Bob at a higher precedence level (Immediate). At the SIP layer (this has nothing to do with RSVP yet; that example, involving SIP and RSVP signaling, is in the appendix), once Bob's user agent (phone) receives the INVITE message from Carol, his UA needs to make a choice between retaining the call to Alice and sending Carol a "busy" indication, or preempting the call to Alice in favor of accepting the call from Carol. That choice in IEPS networks is a comparison of Resource Priority headers. Alice, who controlled the precedence level of the call to Bob, sent the precedence level of her call to him at "Routine" (the lowest level within the network). Carol, who controls the priority of the call signal to Bob, sent her priority level to "Immediate" (higher than "Routine"). Bob's UA needs to (under IEPS policy) preempt the call from Alice (and provide her with a preemption indication in the call termination message). Bob needs to successfully answer the call setup from Carol.
Figure 2 is a simple example of a SIP call setup that includes the layer 7 precedence of a call between Alice and Bob. After Alice successfully sets up a call to Bob at the "Routine" precedence level, Carol calls Bob at a higher precedence level (Immediate). At the SIP layer (this has nothing to do with RSVP yet; that example, involving SIP and RSVP signaling, is in the appendix), once Bob's user agent (phone) receives the INVITE message from Carol, his UA needs to make a choice between retaining the call to Alice and sending Carol a "busy" indication, or preempting the call to Alice in favor of accepting the call from Carol. That choice in IEPS networks is a comparison of Resource Priority headers. Alice, who controlled the precedence level of the call to Bob, sent the precedence level of her call to him at "Routine" (the lowest level within the network). Carol, who controls the priority of the call signal to Bob, sent her priority level to "Immediate" (higher than "Routine"). Bob's UA needs to (under IEPS policy) preempt the call from Alice (and provide her with a preemption indication in the call termination message). Bob needs to successfully answer the call setup from Carol.
Baker & Polk Informational [Page 14] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 14] RFC 4542 ETS in an IP Network May 2006
UA Alice UA Bob UA Carol
| INVITE (RP: Routine) | |
|--------------------------->| |
| 200 OK | |
|<---------------------------| |
| ACK | |
|--------------------------->| |
| RTP | |
|<==========================>| |
| | |
| | INVITE (RP: Immediate) |
| |<----------------------------|
| ************************************************ |
| *Resource Priority value comparison by Bob's UA* |
| ************************************************ |
| | |
| BYE (Reason: UA preemption) |
|<---------------------------| |
| | 200 OK |
| |---------------------------->|
| 200 OK (BYE) | |
|--------------------------->| |
| | ACK |
| |<----------------------------|
| | RTP |
| |<===========================>|
| | |
UA Alice UA Bob UA Carol | INVITE (RP: Routine) | | |--------------------------->| | | 200 OK | | |<---------------------------| | | ACK | | |--------------------------->| | | RTP | | |<==========================>| | | | | | | INVITE (RP: Immediate) | | |<----------------------------| | ************************************************ | | *Resource Priority value comparison by Bob's UA* | | ************************************************ | | | | | BYE (Reason: UA preemption) | |<---------------------------| | | | 200 OK | | |---------------------------->| | 200 OK (BYE) | | |--------------------------->| | | | ACK | | |<----------------------------| | | RTP | | |<===========================>| | | |
Figure 2: Priority Call Establishment and Termination at SIP Layer
Figure 2: Priority Call Establishment and Termination at SIP Layer
Nothing in this example involved mechanisms other than SIP. It is also assumed each user agent recognized the Resource-Priority header namespace value in each message. Therefore, it is assumed that the domain allowed Alice, Bob, and Carol to communicate. Authentication and Authorization are discussed later in this document.
Nothing in this example involved mechanisms other than SIP. It is also assumed each user agent recognized the Resource-Priority header namespace value in each message. Therefore, it is assumed that the domain allowed Alice, Bob, and Carol to communicate. Authentication and Authorization are discussed later in this document.
2.2. Voice Handling Characteristics
2.2. Voice Handling Characteristics
The Quality of Service architecture used in the data path is that of [RFC2475]. Differentiated Services uses a flag in the IP header called the DSCP [RFC2474] to identify a data stream, and then applies a procedure called a Per Hop Behavior, or PHB, to it. This is largely as described in [RFC2998].
The Quality of Service architecture used in the data path is that of [RFC2475]. Differentiated Services uses a flag in the IP header called the DSCP [RFC2474] to identify a data stream, and then applies a procedure called a Per Hop Behavior, or PHB, to it. This is largely as described in [RFC2998].
In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] describes the fundamental needs of voice and video traffic. This PHB entails ensuring that sufficient bandwidth is dedicated to real-time traffic to ensure that variation in delay and loss rate are minimal,
In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] describes the fundamental needs of voice and video traffic. This PHB entails ensuring that sufficient bandwidth is dedicated to real-time traffic to ensure that variation in delay and loss rate are minimal,
Baker & Polk Informational [Page 15] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 15] RFC 4542 ETS in an IP Network May 2006
as codecs are hampered by excessive loss [G711.1] [G711.3]. In parts of the network where bandwidth is heavily over-provisioned, there may be no remaining concern. In places in the network where bandwidth is more constrained, this may require the use of a priority queue. If a priority queue is used, the potential for abuse exists, meaning that it is also necessary to police traffic placed into the queue to detect and manage abuse. A fundamental question is "where does this policing need to take place?". The obvious places would be the first-hop routers and any place where converging data streams might congest a link.
as codecs are hampered by excessive loss [G711.1] [G711.3]. In parts of the network where bandwidth is heavily over-provisioned, there may be no remaining concern. In places in the network where bandwidth is more constrained, this may require the use of a priority queue. If a priority queue is used, the potential for abuse exists, meaning that it is also necessary to police traffic placed into the queue to detect and manage abuse. A fundamental question is "where does this policing need to take place?". The obvious places would be the first-hop routers and any place where converging data streams might congest a link.
Some proposals mark traffic with various code points appropriate to the service precedence of the call. In normal service, if the traffic is all in the same queue and EF service requirements are met (applied capacity exceeds offered load, variation in delay is minimal, and loss is negligible), details of traffic marking should be irrelevant, as long as packets get into the right service class. Then, the major issues are appropriate policing of traffic, especially around route changes, and ensuring that the path has sufficient capacity.
Some proposals mark traffic with various code points appropriate to the service precedence of the call. In normal service, if the traffic is all in the same queue and EF service requirements are met (applied capacity exceeds offered load, variation in delay is minimal, and loss is negligible), details of traffic marking should be irrelevant, as long as packets get into the right service class. Then, the major issues are appropriate policing of traffic, especially around route changes, and ensuring that the path has sufficient capacity.
The real-time voice/video application should be generating traffic at a rate appropriate to its content and codec, which is either a constant bit rate stream or a stream whose rate is variable within a specified range. The first-hop router should be policing traffic originated by the application, as is performed in traditional virtual circuit networks like Frame Relay and ATM. Between these two checks (at what some networks call the Data Terminal Equipment (DTE) and Data Communications Equipment (DCE)), the application traffic should be guaranteed to be within acceptable limits. As such, given bandwidth-aware call admission control, there should be minimal actual loss. The cases where loss would occur include cases where routing has recently changed and CAC has not caught up, or cases where statistical thresholds are in use in CAC and the data streams happen to coincide at their peak rates.
The real-time voice/video application should be generating traffic at a rate appropriate to its content and codec, which is either a constant bit rate stream or a stream whose rate is variable within a specified range. The first-hop router should be policing traffic originated by the application, as is performed in traditional virtual circuit networks like Frame Relay and ATM. Between these two checks (at what some networks call the Data Terminal Equipment (DTE) and Data Communications Equipment (DCE)), the application traffic should be guaranteed to be within acceptable limits. As such, given bandwidth-aware call admission control, there should be minimal actual loss. The cases where loss would occur include cases where routing has recently changed and CAC has not caught up, or cases where statistical thresholds are in use in CAC and the data streams happen to coincide at their peak rates.
If it is demonstrated that routing transients and variable rate beat frequencies present a sufficient problem, it is possible to provide a policing mechanism that isolates intentional loss among an ordered set of classes. While the ability to do so, by various algorithms, has been demonstrated, the technical requirement has not. If dropping random packets from all calls is not appropriate, concentrating random loss in a subset of the calls makes the problem for those calls worse; a superior approach would reject or preempt an entire call.
If it is demonstrated that routing transients and variable rate beat frequencies present a sufficient problem, it is possible to provide a policing mechanism that isolates intentional loss among an ordered set of classes. While the ability to do so, by various algorithms, has been demonstrated, the technical requirement has not. If dropping random packets from all calls is not appropriate, concentrating random loss in a subset of the calls makes the problem for those calls worse; a superior approach would reject or preempt an entire call.
Parekh's second condition has been met: we must know what the network will do with the traffic. If the offered load exceeds the available
Parekh's second condition has been met: we must know what the network will do with the traffic. If the offered load exceeds the available
Baker & Polk Informational [Page 16] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 16] RFC 4542 ETS in an IP Network May 2006
bandwidth, the network will remark and drop the excess traffic. The key questions become "How does one limit offered load to a rate less than or equal to available bandwidth?" and "How much traffic does one admit with each appropriate marking?"
bandwidth, the network will remark and drop the excess traffic. The key questions become "How does one limit offered load to a rate less than or equal to available bandwidth?" and "How much traffic does one admit with each appropriate marking?"
2.3. Bandwidth Admission Procedure
2.3. Bandwidth Admission Procedure
Since many available voice and video codecs require a nominal loss rate to deliver acceptable performance, Parekh's first requirement is that offered load be within the available capacity. There are several possible approaches.
Since many available voice and video codecs require a nominal loss rate to deliver acceptable performance, Parekh's first requirement is that offered load be within the available capacity. There are several possible approaches.
An approach that is commonly used in H.323 networks is to limit the number of calls simultaneously accepted by the gatekeeper. SIP networks do something similar when they place a stateful SIP proxy near a single ingress/egress to the network. This is able to impose an upper bound on the total number of calls in the network or the total number of calls crossing the significant link. However, the gatekeeper has no knowledge of routing, so the engineering must be very conservative and usually presumes a single ingress/egress or the failure of one of its data paths. While this may serve as a short- term work-around, it is not a general solution that is readily deployed. This limits the options in network design.
An approach that is commonly used in H.323 networks is to limit the number of calls simultaneously accepted by the gatekeeper. SIP networks do something similar when they place a stateful SIP proxy near a single ingress/egress to the network. This is able to impose an upper bound on the total number of calls in the network or the total number of calls crossing the significant link. However, the gatekeeper has no knowledge of routing, so the engineering must be very conservative and usually presumes a single ingress/egress or the failure of one of its data paths. While this may serve as a short- term work-around, it is not a general solution that is readily deployed. This limits the options in network design.
[RFC1633] provides for signaled admission for the use of capacity. The recommended approach is explicit capacity admission, supporting the concepts of preemption. An example of such a procedure uses the Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of Capacity Admission using RSVP with SIP is described in [RFC3312]. While call counting is specified in H.323, network capacity admission is not integrated with H.323 at this time.
[RFC1633] provides for signaled admission for the use of capacity. The recommended approach is explicit capacity admission, supporting the concepts of preemption. An example of such a procedure uses the Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of Capacity Admission using RSVP with SIP is described in [RFC3312]. While call counting is specified in H.323, network capacity admission is not integrated with H.323 at this time.
2.3.1. RSVP Admission Using Policy for Both Unicast and Multicast
Sessions
2.3.1. RSVP Admission Using Policy for Both Unicast and Multicast Sessions
RSVP is a resource reservation setup protocol providing the one-way (at a time) setup of resource reservations for multicast and unicast flows. Each reservation is set up in one direction (meaning one reservation from each end system; in a multicast environment, N senders set up N reservations). These reservations complete a communication path with a deterministic bandwidth allocation through each router along that path between end systems. These reservations set up a known quality of service for end-to-end communications and maintain a "soft-state" within a node. The meaning of the term "soft state" is that in the event of a network outage or change of routing, these reservations are cleared without manual intervention, but must be periodically refreshed. In RSVP, the refresh period is by default 30 seconds, but may be as long as is appropriate.
RSVP is a resource reservation setup protocol providing the one-way (at a time) setup of resource reservations for multicast and unicast flows. Each reservation is set up in one direction (meaning one reservation from each end system; in a multicast environment, N senders set up N reservations). These reservations complete a communication path with a deterministic bandwidth allocation through each router along that path between end systems. These reservations set up a known quality of service for end-to-end communications and maintain a "soft-state" within a node. The meaning of the term "soft state" is that in the event of a network outage or change of routing, these reservations are cleared without manual intervention, but must be periodically refreshed. In RSVP, the refresh period is by default 30 seconds, but may be as long as is appropriate.
Baker & Polk Informational [Page 17] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 17] RFC 4542 ETS in an IP Network May 2006
RSVP is a locally-oriented process, not a globally- or domain- oriented one like a routing protocol or H.323 Call Counting. Although it uses the local routing databases to determine the routing path, it is only concerned with the quality of service for a particular or aggregate flow through a device. RSVP is not aware of anything other than the local goal of QoS and its RSVP-enabled adjacencies, operating below the network layer. The process by itself neither requires nor has any end-to-end network knowledge or state. Thus, RSVP can be effective when it is enabled at some nodes in a network without the need to have every node participate.
RSVP is a locally-oriented process, not a globally- or domain- oriented one like a routing protocol or H.323 Call Counting. Although it uses the local routing databases to determine the routing path, it is only concerned with the quality of service for a particular or aggregate flow through a device. RSVP is not aware of anything other than the local goal of QoS and its RSVP-enabled adjacencies, operating below the network layer. The process by itself neither requires nor has any end-to-end network knowledge or state. Thus, RSVP can be effective when it is enabled at some nodes in a network without the need to have every node participate.
HOST ROUTER
_____________________________ ____________________________
| _______ | | |
| | | _______ | | _______ |
| |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Policy| || <--> -->Policy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|=========>
| |______| |________| |data | |______| |________| data
| | | |
|_____________________________| |____________________________|
HOST ROUTER _____________________________ ____________________________ | _______ | | | | | | _______ | | _______ | | |Appli- | | | |RSVP | | | | | | cation| | RSVP <---------------------------> RSVP <----------> | | <--> | | | _______ | | | | | | |process| _____ | ||Routing| |process| _____ | | |_._____| | -->Policy| || <--> -->Policy|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| | |data | | |_____|| ||__.____| | | |_____|| |===|===========|==|==========| |===|==========|==|==========| | | --------| | _____ | | | --------| | _____ | | | | | ---->Admis|| | | | | ---->Admis|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | | | | | |_____|| | | | | ||_____|| | |Class-| | Packet | | | |Class-| | Packet | | | | ifier|==>Schedulr|================> ifier|==>Schedulr|=========> | |______| |________| |data | |______| |________| data | | | | |_____________________________| |____________________________|
Figure 3: RSVP in Hosts and Routers
Figure 3: RSVP in Hosts and Routers
Figure 3 shows the internal process of RSVP in both hosts (end systems) and routers, as shown in [RFC2209].
Figure 3 shows the internal process of RSVP in both hosts (end systems) and routers, as shown in [RFC2209].
RSVP uses the phrase "traffic control" to describe the mechanisms of how a data flow receives quality of service. There are 3 different mechanisms to traffic control (shown in Figure 2 in both hosts and routers). They are:
RSVP uses the phrase "traffic control" to describe the mechanisms of how a data flow receives quality of service. There are 3 different mechanisms to traffic control (shown in Figure 2 in both hosts and routers). They are:
A packet classifier mechanism: This resolves the QoS class for each
packet; this can determine the route as well.
A packet classifier mechanism: This resolves the QoS class for each packet; this can determine the route as well.
Baker & Polk Informational [Page 18] RFC 4542 ETS in an IP Network May 2006
Baker & Polk Informational [Page 18] RFC 4542 ETS in an IP Network May 2006
An admission control mechanism: This consists of two decision
modules: admission control and policy control. Determining
whether there are satisfactory resources for the requested QoS is
the function of admission control. Determining whether the user
has the authorization to request such resources is the function of
policy control. If the parameters carried within this flow fail,
either of these two modules errors the request using RSVP.
An admission control mechanism: This consists of two decision modules: admission control and policy control. Determining whether there are satisfactory resources for the requested QoS is the function of admission control. Determining whether the user has the authorization to request such resources is the function of policy control. If the parameters carried within this flow fail, either of these two modules errors the request using RSVP.
A packet scheduler mechanism: At each outbound interface, the
scheduler attains the guaranteed QoS for that flow.
A packet scheduler mechanism: At each outbound interface, the scheduler attains the guaranteed QoS for that flow.
2.3.2. RSVP Scaling Issues
2.3.2. RSVP Scaling Issues
As originally written, there was concern that RSVP had scaling limitations due to its data plane behavior [RFC2208]. This either has not proven to be the case or has in time largely been corrected. Telephony services generally require peak call admission rates on the order of thousands of calls per minute and peak call levels comparable to the capacities of the lines in question, which is generally on the order of thousands to tens of thousands of calls. Current RSVP implementations admit calls at the rate of hundreds of calls per second and maintain as many calls in progress as memory configurations allow.
As originally written, there was concern that RSVP had scaling limitations due to its data plane behavior [RFC2208]. This either has not proven to be the case or has in time largely been corrected. Telephony services generally require peak call admission rates on the order of thousands of calls per minute and peak call levels comparable to the capacities of the lines in question, which is generally on the order of thousands to tens of thousands of calls. Current RSVP implementations admit calls at the rate of hundreds of calls per second and maintain as many calls in progress as memory configurations allow.
In edge networks, RSVP is used to signal for individual microflows, admitting the bandwidth. However, Differentiated Services is used for the data plane behavior. Admission and policing may be performed anywhere, but need only be performed in the first-hop router (which, if the end system sending the traffic is a DTE, constitutes a DCE for the remaining network) and in routers that have interfaces threatened by congestion. In Figure 1, these would normally be the links that cross network boundaries.
縁のネットワークでは、帯域幅を認めて、RSVPは、個々のmicroflowsのために合図するのに使用されます。 しかしながら、Differentiated Servicesはデータ飛行機の振舞いに使用されます。 入場と取り締まりは、どこでも実行されるかもしれませんが、最初に、ホップルータ(トラフィックを送るエンドシステムがDTEであるなら残っているネットワークのためにDCEを構成する)と混雑でインタフェースを脅かすルータで実行されるだけでよいです。 図1では、通常、これらはネットワーク限界に交差するリンクでしょう。
2.3.3. RSVP Operation in Backbones and Virtual Private Networks (VPNs)
2.3.3. バックボーンにおけるRSVP操作と仮想私設網(VPNs)
In backbone networks, networks that are normally awash in bandwidth, RSVP and its affected data flows may be carried in a variety of ways. If the backbone is a maze of tunnels between its edges (true of MPLS networks, networks that carry traffic from an encryptor to a decryptor, and also VPNs), applicable technologies include [RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is, simplistically put, a IP packet enveloped inside another IP packet as a payload. When IPv6 is transported over an IPv4 network, encapsulating the entire v6 packet inside a v4 packet is an effective means to accomplish this task. In this type of tunnel, the IPv6 packet is not read by any of the routers while inside the IPv4 envelope. If the inner packet is RSVP
バックボーンネットワークでは、通常、帯域幅、RSVP、およびその影響を受けるデータフローで水面すれすれのネットワークはさまざまな方法で運ばれるかもしれません。 バックボーンが縁(MPLSネットワーク、暗号化する人からdecryptorまでトラフィックを運ぶネットワーク、およびVPNsに関しても本当の)の間のトンネルの迷宮であるなら、適切な技術は[RFC2207]、[RFC2746]、および[RFC2983]を含んでいます。 simplisticallyは、IPトンネルがペイロードとして別のIPパケットの中でおおわれたIPパケットであることを置きました。 IPv6がIPv4ネットワークの上で輸送されるとき、v4パケットの中で全体のv6パケットをカプセルに入れるのは、このタスクを達成する効果的な手段です。 IPv4封筒の中にある間、このタイプのトンネルでは、IPv6パケットがルータのいずれによっても読まれません。 内側のパケットがRSVPであるなら
Baker & Polk Informational [Page 19] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[19ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
enabled, there must be an active configuration to ensure that all relevant backbone nodes read the RSVP fields; [RFC2746] describes this.
可能にされて、すべての関連バックボーンノードがRSVP分野を読むのを保証するアクティブな構成があるに違いありません。 [RFC2746]はこれについて説明します。
This is similar to how IPsec tunnels work. Encapsulating an RSVP packet inside an encrypted packet for security purposes without copying or conveying the RSVP indicators in the outside IP packet header would make RSVP inoperable while in this form of a tunnel. [RFC2207] describes how to modify an IPsec packet header to allow for RSVP awareness by nodes that need to provide QoS for the flow or flows inside a tunnel.
これはIPsecトンネルがどう働いているかと同様です。 トンネルのこの形にある間、セキュリティ目的のために暗号化されたパケットの中で外部のIPパケットのヘッダーでRSVPインディケータをコピーするか、または伝えないでRSVPパケットをカプセルに入れるのに、RSVPは手術不能になるでしょう。 [RFC2207]は、QoSを流れに提供する必要があるノードでRSVP認識を考慮するようにIPsecパケットのヘッダーを変更する方法を説明するか、またはトンネルの中を流れます。
Other networks may simply choose to aggregate the reservations across themselves as described in [RFC3175]. The problem with an individual reservation architecture is that each flow requires a non-trivial amount of message exchange, computation, and memory resources in each router between each endpoint. Aggregation of flows reduces the number of completely individual reservations into groups of individual flows that can act as one for part or all of the journey between end systems. Aggregates are not intended to be from the first router to the last router within a flow, but to cover common paths of a large number of individual flows.
他のネットワークは、[RFC3175]で説明されるように自分たちの向こう側に予約に集めるのを単に選ぶかもしれません。 個々の予約アーキテクチャに関する問題は各流れが各終点の間の各ルータにおける重要な量の交換処理、計算、およびメモリリソースを必要とするということです。 流れの集合は部分への1として機能できる個々の流れのグループかエンドシステムの間の旅行のすべてに完全に個々の予約の数を減少させます。集合は、流れの中に最初のルータから最後のルータまであるつもりであるのではなく、多くの個々の流れの共通路をカバーするために意図します。
Examples of aggregated data flows include streams of IP data that traverse common ingress and egress points in a network and also include tunnels of various kinds. MPLS LSPs, IPsec Security Associations between VPN edge routers, IP/IP tunnels, and Generic Routing Encapsulation (GRE) tunnels all fall into this general category. The distinguishing factor is that the system injecting an aggregate into the aggregated network sums the PATH and RESV statistical information on the un-aggregated side and produces a reservation for the tunnel on the aggregated side. If the bandwidth for the tunnel cannot be expanded, RSVP leaves the existing reservation in place and returns an error to the aggregator, which can then apply a policy such as IEPS to determine which session to refuse. In the data plane, the DSCP for the traffic must be copied from the inner to the outer header, to preserve the PHB's effect.
集められたデータフローに関する例はネットワークで一般的なイングレスと出口ポイントを横断して、また様々な種類のトンネルを含んでいるIPデータのストリームを含んでいます。 MPLS LSPs、VPN縁のルータと、IP/IPトンネルと、Genericルート設定Encapsulation(GRE)の間のIPsec Security Associationsは秋中にこの一般的なカテゴリにトンネルを堀ります。 区別要素は集められたネットワークに集合を注ぐシステムが不-集められた側でPATHとRESV統計情報をまとめて、集める側の上のトンネルの予約を作成するということです。 トンネルへの帯域幅を広げることができないなら、RSVPはアグリゲータに適所に既存の予約を残して、誤りを返します。(次に、そのアグリゲータは、拒否するためにどのセッションを決定するかためにIEPSなどの方針を適用できます)。 データ飛行機では、PHBの効果を保存するために内側のヘッダーから外側のヘッダーまでトラフィックのためのDSCPをコピーしなければなりません。
One concern with this approach is that this leaks information into the aggregated zone concerning the number of active calls or the bandwidth they consume. In fact, it does not, as the data itself is identifiable by aggregator address, deaggregator address, and DSCP. As such, even if it is not advertised, such information is measurable.
このアプローチがある1回の関心はこれが活発な呼び出しの数かそれらが消費する帯域幅に関して集められたゾーンに情報を漏らすということです。 事実上、データ自体がアグリゲータアドレス、「反-アグリゲータ」アドレス、およびDSCPが身元保証可能であることで、それはそうしません。 そういうものとして、それが広告に掲載されないでも、そのような情報は測定できます。
Baker & Polk Informational [Page 20] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[20ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
2.3.4. Interaction with the Differentiated Services Architecture
2.3.4. 差別化されたサービスアーキテクチャとの相互作用
In the PATH message, the DCLASS object described in [RFC2996] is used to carry the determined DSCP for the precedence level of that call in the stream. This is reflected back in the RESV message. The DSCP will be determined from the authorized SIP message exchange between end systems by using the R-P header. The DCLASS object permits both bandwidth admission within a class and the building up of the various rates or token buckets.
PATHメッセージでは、[RFC2996]で説明されたDCLASSオブジェクトは、ストリームにおける、その呼び出しの先行レベルのために断固としたDSCPを運ぶのに使用されます。 これはRESVメッセージで映し出されます。 DSCPはR-Pヘッダーを使用するのによるエンドシステムの間の認可されたSIP交換処理から断固とするでしょう。 DCLASSオブジェクトはクラスの中の帯域幅入場と様々なレートかトークンバケツを上がっているビルの両方を可能にします。
2.3.5. Admission Policy
2.3.5. 入場方針
RSVP's basic admission policy, as defined, is to grant any user bandwidth if there is bandwidth available within the current configuration. In other words, if a new request arrives and the difference between the configured upper bound and the currently reserved bandwidth is sufficiently large, RSVP grants use of that bandwidth. This basic policy may be augmented in various ways, such as using a local or remote policy engine to apply AAA procedures and further qualify the reservation.
RSVPの基本入場料方針は現在の構成の中で利用可能な帯域幅があれば定義されるようにどんなユーザ帯域幅も与えることです。 言い換えれば、新しい要求が到着して、構成された上限と現在予約された帯域幅の違いが十分大きいなら、RSVPはその帯域幅の使用を承諾します。 この基本方針はいろいろ増大するかもしれません、AAA手順を適用して、さらに予約に資格を与えるのに地方の、または、リモートな方針エンジンを使用するのなどように。
2.3.5.1. Admission for Variable Rate Codecs
2.3.5.1. 変動金利コーデックのための入場
For certain applications, such as broadcast video using MPEG-1 or voice without activity detection and using a constant bit rate codec such as G.711, this basic policy is adequate apart from AAA. For variable rate codecs, such as MPEG-4 or a voice codec with Voice Activity Detection, however, this may be deemed too conservative. In such cases, two basic types of statistical policy have been studied and reported on in the literature: simple over-provisioning, and approximation to ambient load.
アクティビティ検出なしでMPEG-1か声を使用して、G.711などの固定ビットレートコーデックを使用する放送ビデオなどのあるアプリケーションにおいて、AAAは別として、この基本方針は適切です。 しかしながら、MPEG-4かVoice Activity Detectionがある音声コーデックなどの変動金利コーデックに関しては、これは保守的過ぎると考えられるかもしれません。 そのような場合、統計的な方針の2人の基本型が、研究されて、文学でオンであると報告されました: 簡単な食糧を供給し過ぎる、および周囲の負荷への近似。
Simple over-provisioning sets the bandwidth admission limit higher than the desired load, on the assumption that a session that admits a certain bandwidth will in fact use a fraction of the bandwidth. For example, if MPEG-4 data streams are known to use data rates between 80 and 800 KBPS and there is no obvious reason that sessions would synchronize (such as having commercial breaks on 15 minute boundaries), one could imagine estimating that the average session consumes 400 KBPS and treating an admission of 800 KBPS as actually consuming half the amount.
簡単な食糧を供給し過ぎるのは帯域幅入場限界を必要な負荷より高く設定します、事実上、ある一定の帯域幅を認めるセッションが帯域幅の部分を使用するという前提で。 例えば、MPEG-4つのデータ・ストリームがデータ信号速度80〜800KBPSを使用するのが知られて、セッションが同期するだろうという明白な理由(15分の境界にコマーシャルブレイクを持つことなどの)が全くなければ、人は、平均したセッションが400KBPSを消費すると見積もって、実際に量の半分を消費するとして800KBPSの入場を扱うと想像するかもしれません。
One can also approximate to average load, which is perhaps a more reliable procedure. In this case, one maintains a variable that measures actual traffic through the admitted data's queue, approximating it using an exponentially weighted moving average. When a new reservation request arrives, if the requested rate is less than the difference between the configured upper bound and the
また、1つは平均荷重に近づくことができます。(それは、恐らくより信頼できる手順です)。 この場合、人は認められたデータの待ち行列で実際のトラフィックを測定する変数を維持します、指数加重移動平均を使用することでそれに近似して。 そして新しい予約の要請が到着するとき、間の違い以下が要求されたレートであるなら構成された上限である。
Baker & Polk Informational [Page 21] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[21ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
current value of the moving average, the reservation is accepted, and the moving average is immediately increased by the amount of the reservation to ensure that the bandwidth is not promised out to several users simultaneously. In time, the moving average will decay from this guard position to an estimate of true load, which may offer a chance to another session to be reserved that would otherwise have been refused.
移動平均線の現行価値、予約を受け入れます、そして、すぐに、予約の量で移動平均線を増強して、帯域幅が同時に数人のユーザへの外で約束されないのを保証します。 時間内に、移動平均線はこのガードから本当の負荷の見積りに腐食するでしょう。(負荷はそうでなければ拒否された別の予約されるべきセッションまで機会を提供するかもしれません)。
Statistical reservation schemes such as these are overwhelmingly dependent on the correctness of their configuration and its appropriateness for the codecs in use. However, they offer the opportunity to take advantage of statistical multiplexing gains that might otherwise be missed.
使用中のコーデックにおいて、これらなどの統計的な予約体系はそれらの構成とその適切さの正当性に圧倒的に依存しています。 しかしながら、彼らは別の方法でなくなるかもしれない統計的多重化利得を利用する機会を提供します。
2.3.5.2. Interaction with Complex Admission Policies, AAA, and
Preemption of Bandwidth
2.3.5.2. 帯域幅の複雑な入場方針、AAA、および先取りとの相互作用
Policy is carried and applied as described in [RFC2753]. Figure 4, below, is the basic conceptual model for policy decisions and enforcement in an Integrated Services model. This model was created to provide the ability to monitor and control reservation flows based on user identify, specific traffic and security requirements, and conditions that might change for various reasons, including a reaction to a disaster or emergency event involving the network or its users.
方針は、[RFC2753]で説明されるように運ばれて、適用されます。 図4はIntegrated Servicesモデルにおける政策決定と実施のための以下の基本的な概念モデルです。 このモデルは様々な理由で変化するかもしれないモニターする能力、ユーザに基づいた流れが特定するコントロールの予約、特定のトラフィック、セキュリティ要件、および状態を提供するために創造されました、ネットワークかそのユーザにかかわる災害か非常時のイベントへの反応を含んでいて。
Network Node Policy server
______________
| ______ |
| | | | _____
| | PEP | | | |------------->
| |______|<---|---->| PDP |May use LDAP,SNMP,COPS...for accessing
| ^ | | | policy database, authentication, etc.
| | | |_____|------------->
| __v___ |
| | | | PDP = Policy Decision Point
| | LPDP | | PEP = Policy Enforcement Point
| |______| | LPDP = Local Policy Decision Point
|______________|
ネットワークNode Policyサーバ______________ | ______ | | | | | _____ | | 気力| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>| |______| <、-、--、|、-、-、--、>| PDP|LDAP、SNMP、COPSを使用するかもしれません…アクセスのために| ^ | | | 方針データベース、認証など | | | |_____|、-、-、-、-、-、-、-、-、-、-、-、--、>| __v___ | | | | | PDPは政策決定ポイントと等しいです。| | LPDP| | 気力は方針実施ポイントと等しいです。| |______| | LPDPはローカルの政策決定ポイントと等しいです。|______________|
Figure 4: Conceptual Model for Policy Control of Routers
図4: ルータの方針コントロールのための概念モデル
The Network Node represents a router in the network. The Policy Server represents the point of admission and policy control by the network operator. Policy Enforcement Point (PEP) (the router) is where the policy action is carried out. Policy decisions can be either locally present in the form of a Local Policy Decision Point (LPDP), or in a separate server on the network called the Policy
Network Nodeはネットワークでルータを表します。 Policy Serverはネットワーク・オペレータによる入場と方針コントロールのポイントを表します。 方針Enforcement Point(PEP)(ルータ)は政策的措置が行われるところです。 政策決定はLocal Policy Decision Point(LPDP)の形、またはPolicyと呼ばれるネットワークの別々のサーバで局所的に存在している場合があります。
Baker & Polk Informational [Page 22] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[22ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
Decision Point. The easier the instruction set of rules, the more likely this set can reside in the LPDP for speed of access reasons. The more complex the rule set, the more likely this is active on a remote server. The PDP will use other protocols (LDAP, SNMP, etc.) to request information (e.g., user authentication and authorization for precedence level usage) to be used in creating the rule sets of network components. This remote PDP should also be considered where non-reactive policies are distributed out to the LPDPs.
決定ポイント。 規則の命令セットが簡単であれば簡単であるほど、このセットがLPDPにあることができるのがアクセス理由の速度には、よりありそうです。 規則セットが複雑であれば複雑であるほど、これがリモートサーバでアクティブであることが、よりありそうです。PDPは、ネットワーク要素の規則セットを創設する際に使用されるよう情報(先行レベル用法のための例えば、ユーザー認証と承認)に要求するのに、他のプロトコル(LDAP、SNMPなど)を使用するでしょう。 また、非反応性方針がLPDPsへの外で分配されるところでこのリモートPDPは考えられるべきです。
Taking the above model as a framework, [RFC2750] extends RSVP's concept of a simple reservation to include policy controls, including the concepts of Preemption [RFC3181] and Identity [RFC3182], specifically speaking to the usage of policies that preempt calls under the control of either a local or remote policy manager. The policy manager assigns a precedence level to the admitted data flow. If it admits a data flow that exceeds the available capacity of a system, the expectation is that the RSVP-affected RSVP process will tear down a session among the lowest precedence sessions it has admitted. The RESV Error resulting from that will go to the receiver of the data flow and be reported to the application (SIP or H.323). That application is responsible for disconnecting its call, with a reason code of "bandwidth preemption".
フレームワークとして上のモデルをみなして、[RFC2750]は方針コントロールを含むようにRSVPの簡単な予約の概念について敷衍しています、Preemption[RFC3181]とIdentity[RFC3182]の概念を含んでいて、明確に地方の、または、リモートな方針マネージャのコントロールの下で呼び出しを先取りする方針の用法に話して。 方針マネージャは先行レベルを認められたデータフローに割り当てます。 システムの有効な容量を超えているデータフローを認めるなら、期待はRSVPが影響を受けるRSVPプロセスが認めた中で最も低い先行セッションまでセッションを取りこわすということです。 それから生じるRESV Errorはデータフローの受信機に行って、アプリケーション(SIPかH.323)に報告されるでしょう。 そのアプリケーションは「帯域幅先取り」の理由コードで呼び出しから切断するのに原因となります。
2.4. Authentication and Authorization of Calls Placed
2.4. 出された電話の認証と承認
It will be necessary, of course, to ensure that any policy is applied to an authenticated user; the capabilities assigned to an authenticated user may be considered authorized for use in the network. For bandwidth admission, this will require the utilization of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures will also be needed.
もちろん、どんな方針も認証されたユーザに適用されるのを保証するのが必要でしょう。 認証されたユーザに割り当てられた能力はネットワークにおける使用において認可されていると考えられるかもしれません。 帯域幅入場のために、これは[RFC2747][RFC3097]の利用を必要とするでしょう。 また、SIPとH.323では、AAA手順が必要でしょう。
2.5. Defined User Interface
2.5. 定義されたユーザーインタフェース
The user interface -- the chimes and tones heard by the user -- should ideally remain the same as in the PSTN for those indications that are still applicable to an IP network. There should be some new effort generated to update the list of announcements sent to the user that don't necessarily apply. All indications to the user, of course, depend on positive signals, not unreliable measures based on changing measurements.
ユーザーインタフェース(ユーザによって聞かれたチャイムとトーン)はまだIPネットワークに適切なそれらの指摘のためのPSTNのように理想的に同じままで残っているはずです。 必ず適用するというわけではないユーザに送られた発表のリストをアップデートするために生成された何らかの新しい取り組みがあるべきです。 ユーザへのすべての指摘がもちろん測定を変えることに基づいた頼り無い測定ではなく、積極的な信号によります。
Baker & Polk Informational [Page 23] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[23ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
3. Security Considerations
3. セキュリティ問題
This document outlines a networking capability composed entirely of existing specifications. It has significant security issues, in the sense that a failure of the various authentication or authorization procedures can cause a fundamental breakdown in communications. However, the issues are internal to the various component protocols and are covered by their various security procedures.
このドキュメントは完全な既存の仕様で構成されたネットワーク能力について概説します。 それには、重要な安全保障問題があります、様々な認証か承認手順の失敗がコミュニケーションの基本的な故障を引き起こす場合があるという意味で。 しかしながら、問題は、様々なコンポーネントプロトコルに内部であり、それらの様々なセキュリティ手順でカバーされています。
4. Acknowledgements
4. 承認
This document was developed with the knowledge and input of many people, far too numerous to be mentioned by name. However, key contributors of thoughts include Francois Le Faucheur, Haluk Keskiner, Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan, and Tony De Simone. Pete Babendreier, Ken Carlberg, and Mike Pierce provided useful reviews.
このドキュメントははるかに名前で言及できないくらいの多数の多くの人々の知識と入力で開発されました。 しかしながら、考えの主要な貢献者はフランソアLe Faucheur、Haluk Keskiner、Rohanマーイ、スコット・ブラドナー、スコットモリソン、Subha Dhesikan、およびトニー・Deシモンを入れます。 ピートBabendreier、ケンCarlberg、およびマイク・ピアスは役に立つレビューを提供しました。
Baker & Polk Informational [Page 24] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[24ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements
for Emergency Telecommunication Service (ETS)", RFC
3689, February 2004.
[RFC3689] CarlbergとK.とR.アトキンソン、「非常時の電気通信サービス(ETS)のための一般要件」、RFC3689、2004年2月。
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony
Requirements for Emergency Telecommunication
Service (ETS)", RFC 3690, February 2004.
[RFC3690] CarlbergとK.とR.アトキンソン、「非常時の電気通信サービス(ETS)のためのIP電話要件」、RFC3690、2004年2月。
Integrated Services Architecture References
統合サービスアーキテクチャ参照
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an
Overview", RFC 1633, June 1994.
[RFC1633] ブレーデン、B.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205] ブレーデン、B.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for
IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S.,
O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
"Resource ReSerVation Protocol (RSVP) Version 1
Applicability Statement Some Guidelines on
Deployment", RFC 2208, September 1997.
[RFC2208] マンキン、A.、ベイカー、F.、ブレーデン、B.、ブラドナー、S.、オデル、M.、Romanow、A.、Weinrib、A.、およびL.チャン、「資源予約がバージョン1つの(RSVP)適用性証明についていくつか議定書の中で述べる、展開に関するガイドライン、」、RFC2208(1997年9月)
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2209] ブレーデンとB.とL.チャン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1メッセージ処理は統治する」RFC2209、1997年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
2000年1月の[RFC2746]TerzisとA.とKrawczykとJ.とWroclawski、J.とL.チャン、「IP Tunnelsの上のRSVP操作」RFC2746。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January
2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000.
[RFC2750] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
Baker & Polk Informational [Page 25] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[25ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
Framework for Policy-based Admission Control", RFC
2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D.、およびR.ゲラン、「方針ベースの入場コントロールのためのフレームワーク」、RFC2753、2000年1月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[RFC2996] Bernet、Y.、「RSVP DCLASSオブジェクトの形式」、RFC2996、2000年11月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F.,
Zhang, L., Speer, M., Braden, R., Davie, B.,
Wroclawski, J., and E. Felstaine, "A Framework for
Integrated Services Operation over Diffserv
Networks", RFC 2998, November 2000.
[RFC2998] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE.Felstaine、「Diffservネットワークの上の統合サービス操作のためのフレームワーク」、RFC2998(2000年11月)。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RFC3097] ブレーデンとR.とL.チャン、「RSVPの暗号の認証--メッセージタイプ価値をアップデートする」RFC3097、2001年4月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC3175] ベイカー、F.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001.
[RFC3181] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC3181、2001年10月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
Moore, T., Herzog, S., and R. Hess, "Identity
Representation for RSVP", RFC 3182, October 2001.
[RFC3182]YadavとS.とYavatkarとR.とPabbatiとR.とフォードとP.とムーアとT.とハーツォグ、S.とR.ヘス、「RSVPのアイデンティティ表現」RFC3182(2001年10月)。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session
Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(2002年10月)。
Differentiated Services Architecture References
差別化されたサービスアーキテクチャ参照
[RFC2474] 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.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E.,
Wang, Z., and W. Weiss, "An Architecture for
Differentiated Services", RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」RFC2475、1998年12月。
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC2983]黒(D.)が「サービスとトンネルを差別化した」、RFC2983、10月2000日
Baker & Polk Informational [Page 26] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[26ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
[RFC3246] Davie, B., Charny, A., Bennet, J., 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.
[RFC3246] デイビー、B.、シャルニー、A.、アメリカダイコンソウ、J.、ベンソン、K.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J.,
Chiu, A., Courtney, W., Davari, S., Firoiu, V.,
Kalmanek, C., and K. Ramakrishnan, "Supplemental
Information for the New Definition of the EF PHB
(Expedited Forwarding Per-Hop Behavior)", RFC 3247,
March 2002.
[RFC3247] シャルニー、A.、アメリカダイコンソウ、J.、ベンソン、K.、Boudec、J.、チウ、A.、コートニー、W.、Davari、S.、Firoiu、V.、Kalmanek、C.、およびK.Ramakrishnan、「EF PHB(1ホップあたりの完全優先転送の振舞い)の新しい定義のための補足的情報」、RFC3247(2002年3月)。
Session Initiation Protocol and Related References
セッション開始プロトコルと関連参照
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session
Description Protocol", RFC 2327, April 1998.
[RFC2327] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[RFC3261] 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.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC4411] Polk, J., "Extending the Session Initiation
Protocol (SIP) Reason Header for Preemption
Events", RFC 4411, February 2006.
[RFC4411] ポーク、J.、「先取りイベントのためにセッション開始プロトコル(一口)理由ヘッダーを広げています」、RFC4411、2006年2月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications
Resource Priority for the Session Initiation
Protocol (SIP)", RFC 4412, February 2006.
[RFC4412]SchulzrinneとH.とJ.ポーク、「セッション開始プロトコル(一口)のためのコミュニケーションリソース優先権」、RFC4412、2006年2月。
5.2. Informative References
5.2. 有益な参照
[ANSI.MLPP.Spec] American National Standards Institute,
"Telecommunications - Integrated Services Digital
Network (ISDN) - Multi-Level Precedence and
Preemption (MLPP) Service Capability", ANSI
T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Spec]American National Standards Institut、「テレコミュニケーション--サービス統合ディジタル網(ISDN)--マルチ平らな先行と先取り(MLPP)サービス能力」、ANSI T1.619-1992(R1999)、1992。
[ANSI.MLPP.Supp] American National Standards Institute, "MLPP
Service Domain Cause Value Changes", ANSI ANSI
T1.619a-1994 (R1999), 1990.
[ANSI.MLPP.Supp]American National Standards Institut、「MLPPサービスドメイン原因値の変化」、ANSI ANSI T1.619a-1994(R1999)、1990。
[G711.1] Viola Networks, "Netally VoIP Evaluator", January
2003, <http://www.brainworks.de/Site/hersteller/
viola_networks/Dokumente/Compr_Report_Sample.pdf>.
[G711.1]スミレネットワーク、「Netally VoIP評価者」、2003年1月、<http://www.brainworks.de/サイト/hersteller/スミレ_ネットワーク/Dokumente/Compr_は_Sample.pdf>を報告します。
Baker & Polk Informational [Page 27] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[27ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
[G711.3] Nortel Networks, "Packet Loss and Packet Loss
Concealment", 2000, <http://www.nortelnetworks.com/
products/01/succession/es/collateral/
tb_pktloss.pdf>.
[G711.3]ノーテルNetworksと、「パケット損失とパケット損失隠すこと」、2000 _<http://www.nortelnetworks.com/製品/01/継承/es/傍系親族/Tb pktloss.pdf>。
[ITU.ETS.E106] International Telecommunications Union,
"International Emergency Preference Scheme for
disaster relief operations (IEPS)", ITU-T
Recommendation E.106, October 2003.
2003年10月の[ITU.ETS.E106]国際Telecommunications Union、「災害救助操作(IEPS)のための国際Emergency Preference Scheme」ITU-T Recommendation E.106。
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel
Precedence and Preemption Service (MLPP)", ITU-T
Recommendation I.255.3, 1990.
[ITU.MLPP.1990] 国際電気通信組合、「多レベル先行と先取りは(MLPP)を修理する」ITU-T推薦I.255.3、1990。
[Parekh1] Parekh, A. and R. Gallager, "A Generalized
Processor Sharing Approach to Flow Control in
Integrated Services Networks: The Multiple Node
Case", INFOCOM 1993: 521-530, 1993.
[Parekh1] Parekh、A.、およびR.Gallager、「フロー制御へのアプローチを分担する一般化されたプロセッサはサービスネットワークを統合しました」。 「複数のノードケース」、INFOCOM1993: 521-530, 1993.
[Parekh2] Parekh, A. and R. Gallager, "A Generalized
Processor Sharing Approach to Flow Control in
Integrated Services Networks: The Single Node
Case", INFOCOM 1992: 915-924, 1992.
[Parekh2] Parekh、A.、およびR.Gallager、「フロー制御へのアプローチを分担する一般化されたプロセッサはサービスネットワークを統合しました」。 「ただ一つのノードケース」、INFOCOM1992: 915-924, 1992.
Baker & Polk Informational [Page 28] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[28ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
Appendix A. 2-Call Preemption Example Using RSVP
RSVPを使用する付録のA.の2呼び出ししている先取りの例
This appendix will present a more complete view of the interaction among SIP, SDP, and RSVP. The bulk of the material is referenced from [RFC2327], [RFC3312], [RFC4411], and [RFC4412]. There will be some discussion on basic RSVP operations regarding reservation paths; this will be mostly from [RFC2205].
この付録はSIP、SDP、およびRSVPの中に相互作用の、より完全な視点を提示するでしょう。 材料の大半が[RFC2327]、[RFC3312]、[RFC4411]、および[RFC4412]から参照をつけられます。 予約経路に関して基本的なRSVP操作についての何らかの議論があるでしょう。 これはほとんど[RFC2205]からあるでしょう。
SIP signaling occurs at the Application Layer, riding on a UDP/IP or TCP/IP (including TLS/TCP/IP) transport that is bound by routing protocols such as BGP and OSPF to determine the route the packets traverse through a network between source and destination devices. RSVP is riding on top of IP as well, which means RSVP is at the mercy of the IP routing protocols to determine a path through the network between endpoints. RSVP is not a routing protocol. In this appendix, there will be an escalation of building blocks getting to how the many layers are involved in SIP. QoS Preconditions require successful RSVP signaling between endpoints prior to SIP successfully acknowledging the setup of the session (for voice, video, or both). Then we will present what occurs when a network overload occurs (congestion), causing a SIP session to be preempted.
SIPシグナリングはApplication Layerに起こります、ソースと目的地デバイスの間でパケットがネットワークを通して横断するルートを決定するためにBGPやOSPFなどのプロトコルを発送することによって縛られるUDP/IPかTCP/IP(TLS/TCP/IPを含んでいる)輸送に乗って。 RSVPはまた、IPの上に乗っています。IPは終点の間のネットワークを通して経路を決定するためにRSVPがIPルーティング・プロトコルの思うままにあることを意味します。 RSVPはルーティング・プロトコルではありません。 この付録には、多くの層がどうSIPにかかわるか始めるブロックの増大があるでしょう。 QoS Preconditionsは首尾よくセッション(声、ビデオ、または両方のための)のセットアップを承諾するSIPの前で終点の間で合図するうまくいっているRSVPを必要とします。 そして、SIPセッションが先取りされることを引き起こして、私たちはネットワークオーバーロードが起こると起こること(混雑)を提示するつもりです。
Three diagrams in this appendix show multiple views of the same example of connectivity for discussion throughout this appendix. The first diagram (Figure 5) is of many routers between many endpoints (SIP user agents, or UAs). There are 4 UAs of interest; those are for users Alice, Bob, Carol, and Dave. When a user (the human) of a UA gets involved and must do something to a UA to progress a SIP process, this will be explicitly mentioned to avoid confusion; otherwise, when Alice is referred to, it means Alice's UA (her phone).
この付録の3個のダイヤグラムがこの付録中の議論のために接続性に関する同じ例の複数の視点を示しています。 最初のダイヤグラム(図5)は多くの終点(SIPユーザエージェント、またはUAs)の間の多くのルータのものです。 興味がある4UAsがあります。 それらはユーザアリス、ボブ、キャロル、およびデーヴのためのものです。 UAのユーザ(人間)がかかわって、SIPプロセスを進行するようにUAに何かをしなければならないと、これは混乱を避けるために明らかに言及されるでしょう。 アリスが言及されるとき、さもなければ、それはアリスのUA(彼女の電話)を意味します。
RSVP reserves bandwidth in one direction only (the direction of the RESV message), as has been discussed, IP forwarding of packets are dictated by the routing protocol for that portion of the infrastructure from the point of view of where the packet is to go next.
一方向(RESVメッセージの方向)だけのRSVP蓄えの帯域幅、議論していたように、パケットのIP推進はルーティング・プロトコルでパケットが次に行くことになっているところに関する観点からインフラストラクチャのその部分に書き取られます。
The RESV message traverses the routers in the reverse path taken by the PATH message. The PATH message establishes a record of the route taken through a network portion to the destination endpoint, but it does not reserve resources (bandwidth). The RESV message back to the original requester of the RSVP flow requests for the bandwidth resources. This means the endpoint that initiates the RESV message controls the parameters of the reservation. This document specifies in the body text that the SIP initiator (the UAC) establishes the parameters of the session in an INVITE message, and that the INVITE recipient (the UAS) must follow the parameters established in that
RESVメッセージはPATHメッセージによって取られた逆の経路でルータを横断します。 PATHメッセージはネットワーク部分を通って目的地終点に持って行かれたルートに関する記録を確立しますが、それはリソース(帯域幅)を予約しません。 RSVP流動のオリジナルのリクエスタへのRESVメッセージは帯域幅にリソースを要求します。 これはRESVメッセージ制御に着手する終点を意味します。予約のパラメタ。 このドキュメントは、本文でSIP創始者(UAC)がINVITEメッセージのセッションのパラメタを確立して、INVITE受取人(UAS)がそれに確立されたパラメタに従わなければならないと指定します。
Baker & Polk Informational [Page 29] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[29ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
INVITE message. One exception to this is which codec to use if the UAC offered more than one to the UAS. This exception will be shown when the INVITE message is discussed in detail later in the appendix. If there was only one codec in the SDP of the INVITE message, the parameters of the reservation will follow what the UAC requested (specifically to include the Resource-Priority header namespace and priority value).
INVITEメッセージ。 これへの1つの例外は使用へのどのコーデックがUACであるなら1つ以上をUASに提供したかということです。 この例外は後でいつ付録で詳細にINVITEメッセージについて議論するかが示されるでしょう。 1つのコーデックしかINVITEメッセージのSDPになかったなら、予約のパラメタはUACが要求した(特にResource-優先権ヘッダー名前空間と優先順位の値を含む)ことに続くでしょう。
Here is the first figure with the 4 UAs and a meshed routed infrastructure between each. For simplicity of this explanation, this appendix will only discuss the reservations from Alice to Bob (one direction) and from Carol to Dave (one direction). An interactive voice service will require two one-way reservations that end in each UA. This gives the appearance of a two-way reservation, when indeed it is not.
ここに、それぞれの間には、最初の図が4UAsとかみ合っている発送されたインフラストラクチャと共にあります。 この説明の簡単さのために、この付録はアリスからボブ(一方向)までキャロルからデーヴ(一方向)までの予約について議論するだけでしょう。 対話的なボイスサービスはその終わりに各UAで2つの片道予約を必要とするでしょう。 本当にそれが与えないとき、これは両用予約の外観を与えます。
Alice -----R1----R2----R3----R4------ Bob
| \ / \ / \ / |
| \/ \/ \/ |
| /\ /\ /\ |
| / \ / \ / \ |
Carol -----R5----R6----R7----R8------ Dave
アリス-----R1----R2----R3----R4------ ボブ| \ / \ / \ / | | \/ \/ \/ | | /\ /\ /\ | | / \ / \ / \ | キャロル-----R5----R6----R7----R8------ デーヴ
Figure 5: Complex Routing and Reservation Topology
図5: 複雑なルート設定と予約トポロジー
The PATH message from Alice to Bob (establishing the route for the RESV message) will be through routers:
ルータを通してアリスからボブ(RESVメッセージのためにルートを確立する)までのPATHメッセージがあるでしょう:
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
アリス・->R1->R2->R3->R4->ボブ
The RESV message (and therefore the reservation of resources) from Bob to Alice will be through routers:
ルータを通してボブからアリスまでのRESVメッセージ(そして、したがって、リソースの予約)があるでしょう:
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
ボブ・->R4->R3->R2->R1->アリス
The PATH message from Carol to Dave (establishing the route for the RESV message) will be through routers:
ルータを通してキャロルからデーヴ(RESVメッセージのためにルートを確立する)までのPATHメッセージがあるでしょう:
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
キャロル・->R5->R2->R3->R8->デーヴ
The RESV message (and therefore the reservation of resources) from Dave to Carol will be through routers:
ルータを通してデーヴからキャロルまでのRESVメッセージ(そして、したがって、リソースの予約)があるでしょう:
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
デーヴ・->R8->R3->R2->R5->キャロル
The reservations from Alice to Bob traverse a common router link: between R3 and R2 and thus a common interface at R2. Here is where there will be congestion in this example, on the link between R2 and
アリスからボブまでの予約は一般的なルータリンクを横断します: その結果、R3と、R2とR2の一般的なインタフェースの間で。 そしてR2の間のリンクに関するこの例には混雑があるところにここにある。
Baker & Polk Informational [Page 30] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[30ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
R3. Since the flow of data (in this case voice media packets) travels the direction of the PATH message, and RSVP establishes reservation of resources at the egress interface of a router, the interface in Figure 6 shows that Int7 will be what first knows about a congestion condition.
R3。 データ(この場合声のメディア向けの資料セット)の流れがPATHメッセージの指示を旅行して、RSVPがルータの出口のインタフェースでリソースの予約を確立するので、図6のインタフェースは、Int7が最初に混雑状態に関して知っているものになるのを示します。
Alice Bob
\ /
\ /
+--------+ +--------+
| | | |
| R2 | | R3 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
Carol Dave
アリスボブ\/\/+--------+ +--------+ | | | | | R2| | R3| | Int7-------Int5| | | | | +--------+ +--------+/\/\キャロル・デーヴ
Figure 6: Reduced Reservation Topology
図6: 減少している予約トポロジー
Figure 6 illustrates how the messaging between the UAs and the RSVP messages between the relevant routers can be shown to understand the binding that was established in [RFC3312] (more suitably titled "SIP Preconditions for QoS" from this document's point of view).
図6は[RFC3312](このドキュメントの観点から「QoSのための一口前提条件」と適当により題をつけられた)に確立された結合を理解するためにどう関連ルータの間のUAsとRSVPメッセージの間のメッセージングを示すことができるかを例証します。
We will assume all devices have powered up and received whatever registration or remote policy downloads were necessary for proper operation. The routing protocol of choice has performed its routing table update throughout this part of the network. Now we are left to focus only on end-to-end communications and how that affects the infrastructure between endpoints.
私たちは、すべての装置がエネルギー消費量を上げて、どんな登録も受けたか、またはリモート方針ダウンロードが適切な操作に必要であったと思うつもりです。 選択のルーティング・プロトコルはネットワークのこの部分中で経路指定テーブルアップデートを実行しました。 今、私たちが終わらせる終わりだけのコミュニケーションとそれがどう終点の間のインフラストラクチャに影響するかの焦点を合わせるのが残されます。
The next diagram (Figure 7) (nearly identical to Figure 1 from [RFC3312]) shows the minimum SIP messaging (at layer 7) between Alice and Bob for a good-quality voice call. The SIP messages are numbered to identify special qualities of each. During the SIP signaling, RSVP will be initiated. That messaging will also be discussed below.
次のダイヤグラム(図7)([RFC3312]からの図1とほとんど同じ)は、最小のSIPが良質の音声通話のためにアリスとボブの間で通信するのを(層7で)示します。 SIPメッセージは、それぞれの特別な品質を特定するために付番されます。 SIPシグナリングの間、RSVPは開始されるでしょう。 また、以下でそのメッセージングについて議論するでしょう。
Baker & Polk Informational [Page 31] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[31ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
UA Alice UA Bob
| |
| |
|-------------(1) INVITE SDP1--------------->|
| | Note 1
|<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+
* |----------------(3) PRACK------------------>| *
* | | * Where
* |<-----------(4) 200 OK (PRACK)--------------| * RSVP
* | | * is
* | | * signaled
***|********************************************|***
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| RTP (within the reservation) |
|<==========================================>|
| |
UAアリス・UAボブ| | | | |-------------(1) SDP1を招待してください。--------------->|、|、| 注意1| <、-、-、-、-、--(2) 183 セッション進歩SDP2--------| | ***|********************************************|***<。+ * |----------------(3) PRACK------------------>| * * | | * どこ、*| <、-、-、-、-、-、-、-、-、-、--(4) 200OK(PRACK)--------------| * RSVP*| | * *です。| | * 合図された***|********************************************|*** |-------------(5) アップデートSDP3--------------->|、|、| | <、-、-、-、-、-、-、--(6) 200 OK(アップデート)SDP4-----------| | | | <、-、-、-、-、-、-、-、-、-、-、-、--(7) 180 鳴ること---------------| | | |-----------------(8) PRACK----------------->|、|、| | <、-、-、-、-、-、-、-、-、-、-、--(9) 200OK(PRACK)-------------| | | | | | <、-、-、-、-、-、-、-、-、-、--(10) 200OK(招待します)------------| | | |------------------(11) ACK----------------->|、|、|、| RTP(予約の中の)| |<=====================>|、|、|
Figure 7: SIP Reservation Establishment Using Preconditions
図7: 前提条件を使用する一口予約設立
The session initiation starts with Alice wanting to communicate with Bob. Alice decides on an IEPS precedence level for their call (the default is the "routine" level, which is for normal everyday calls, but a priority level has to be chosen for each call). Alice puts into her UA Bob's address and precedence level and (effectively) hits the send button. This is reflected in SIP with an INVITE Method Request message [M1]. Below is what SIP folks call a well-formed SIP message (meaning it has all the headers that are mandatory to function properly). We will pick on the US Marine Corps (USMC) for the addressing of this message exchange.
セッション開始はボブとコミュニケートしたがっているアリスから始めます。 アリスは彼らの呼び出しのためにIEPS先行レベルを決めます(デフォルトが通常の毎日の呼び出しのためのものである「通常」のレベルですが、優先順位は各呼び出しに選ばれなければなりません)。 アリスは彼女のUAボブのアドレス、先行レベル、および(事実上)ヒットに発信ボタンを置きます。 これはINVITE Method Requestメッセージ[M1]でSIPに反映されます。 以下に、SIP人々がよく形成されたSIPメッセージを呼ぶものがあります(それを意味するのにおいて、すべての適切に機能するように義務的なヘッダーがあります)。 私たちはこの交換処理のアドレシングのために、米国海兵隊(USMC)をいじめるつもりです。
Baker & Polk Informational [Page 32] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[32ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
[M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
INVITE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
Require: 100rel, preconditions, resource-priority
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 191
[M1--アリスからQOS=e2eの、そして、義務的なボブ、RP=ルーチンまでのINVITE] INVITE一口: bob@usmc.example.mil SIP/2.0Via: SIP/2.0/TCP pc33.usmc.example.mil: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: アリス<一口: alice@usmc.example.mil 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@usmc.example.mil 、gt;、呼び出しID: 3848276298220188511@pc33.usmc.example.mil CSeq: 31862 招待は以下を必要とします。 100rel、前提条件、リソース優先権Resource-優先権: dsn.routine Contact: <一口: alice@usmc.example.mil 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 191
v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
v=0 o=alice2890844526 2890844526IN IP4 usmc.example.mil c=IN IP4 10.1.3.33tがなにもに0 0m=オーディオの49172RTP/AVP0 4 8a=rtpmap: 0PCMU/8000a=curr: qos e2eと等しい、a=des: qosの義務的なe2e sendrecv
From the INVITE above, Alice is inviting Bob to a session. The upper half of the lines (above the line "v=0") is SIP headers and header values, and the lower half is Session Description Protocol (SDP) lines. SIP headers (after the first line, called the Status line) are not mandated in any particular order, with one exception: the Via header. It is a SIP hop (through a SIP Proxy) route path that has a new Via header line added by each SIP element this message traverses towards the destination UA. This is similar in function to an RSVP PATH message (building a reverse path back to the originator of the message). At any point in the message's path, a SIP element knows the path to the originator of the message. There will be no SIP Proxies in this example, because for Preconditions, Proxies only make more messages that look identical (with the exception of the Via and Max-Forwards headers), and it is not worth the space here to replicate what has been done in SIP RFCs already.
INVITEから、上では、アリスがセッションにボブを招待しています。 立ち並んでください。線の上半分、(上、「v=0インチ) SIPはヘッダーとヘッダー値です、そして、下半分はSession記述プロトコル(SDP)線です」。 SIPヘッダー(最初の線のStatus線と呼ばれる後)は1つの例外があるどんな特定のオーダーでも強制されません: Viaヘッダー。 それはこのメッセージが目的地UAに向かって横断するそれぞれのSIP要素で新しいViaヘッダー線を加えるSIPホップ(SIP Proxyを通した)ルート経路です。 これは機能においてRSVP PATHメッセージと同様です(逆の経路をメッセージの創始者に造って戻して)。 メッセージの経路の任意な点では、SIP要素がメッセージについて創始者にとって経路を知っています。 この例にはSIP Proxiesが全くないでしょう、ProxiesがPreconditionsに関して同じに(Viaと前方へマックスヘッダーを除いた)見えてください。そうすれば、SIP RFCsで既に行われたことを模写するのはここのスペースの価値がないというより多くのメッセージを作るだけであるので。
Baker & Polk Informational [Page 33] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[33ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
SIP headers that are used for Preconditions are as follows:
Preconditionsに使用されるSIPヘッダーは以下の通りです:
o Require header, which contains 3 option tags: "100rel" mandates a
reliable provisional response message to the conditions requesting
in this INVITE (knowing they are special), "preconditions"
mandates that preconditions are attempted, and "resource-priority"
mandates support for the Resource-Priority header. Each of these
option tags can be explicitly identified in a message failure
indication from the called UA to tell the calling UA exactly what
was not supported.
o ヘッダーを必要としてください:(ヘッダーは3個のオプションタグを含みます)。 "100rel"はこのINVITE(それらが特別であることを知っている)、「前提条件」でそれがあらかじめ調整する命令が試みられるよう要求する状態、および命令がResource-優先権ヘッダーのために支持する「リソース優先権」に信頼できる暫定的な応答メッセージを強制します。 まさに何が支持されなかったかを呼んでいるUAに言うために呼ばれたUAからメッセージ失敗指示でそれぞれのこれらのオプションタグを明らかに特定できます。
Provided that this INVITE message is received as acceptable, this
will result in the 183 "Session Progress" message from Bob's UA, a
reliable confirmation that preconditions are required for this
call.
許容できるとしてこのINVITEメッセージを受け取ると、これはボブのUA、信頼できる確認からの前提条件がこの呼び出しに必要であるという183「セッション進歩」メッセージをもたらすでしょう。
o Resource-Priority header, which denotes the domain namespace and
precedence level of the call on an end-to-end basis.
o リソース優先権ヘッダー。(そのヘッダーは終わりから終わりへのベースで呼び出しのドメイン名前空間と先行レベルを指示します)。
This completes SIP's functions in session initiation. Preconditions are requested, required, and signaled for in the SDP portion of the message. SDP is carried in what's called a SIP message body (much like the text in an email message is carried). SDP has special properties (see [RFC2327] for more on SDP, or the MMUSIC WG for ongoing efforts regarding SDP). SDP lines are in a specific order for parsing by end systems. Dialog-generating (or call-generating) SDP message bodies all must have an "m=" line (or media description line). Following the "m=" line are zero or more "a=" lines (or Attribute lines). The "m=" line in Alice's INVITE calls for a voice session (this is where video is identified also) using one of 3 different codecs that Alice supports (0 = G.711, 4 = G.723, and 18 = G.729) that Bob gets to choose from for this session. Bob can choose any of the 3. The first a=rtpmap line is specific to the type of codec these 3 are (PCMU). The next two "a=" lines are the only identifiers that RSVP is to be used for this call. The second "a=" line:
これはセッション開始でSIPの機能を完成します。 前提条件のためにメッセージのSDP部分で要求されていて、必要であり、合図されます。 SDPはSIPメッセージボディーと呼ばれるもので運ばれます(メールメッセージのテキストが運ばれるように)。 SDPには、特別な性質があります(SDPの上の以上で[RFC2327]を見るか、またはSDPでの進行中の努力のためにMMUSIC WGを見てください)。 SDP線は、特定の順序でエンドシステムすべてが「m=」に裏打ちさせなければならない対話を発生させていて(呼び出しを発生させています)のSDPメッセージボディーで分析するもの(メディア記述は立ち並んでいる)です。 「m=」線に従うのは、ゼロであるか以上が「=」線(または、Attribute線)です。 アリスのINVITEの「m=」線はアリスが支持する(0がG.711と等しいです、そして、4はG.723と等しいです、そして、18はG.729と等しいです)3つの異なったコーデックの1つを使用するこのセッションのために選ぶボブが、始める声のセッション(これはまたビデオが特定されるところである)を求めます。 ボブは3つのもののいずれも選ぶことができます。 コーデックのタイプに、最初のa=rtpmap線は特定です。これらの3はこと(PCMU)です。 「=」が裏打ちする次の2はこの呼び出しに使用されて、RSVPがいる唯一の識別子です。 「=」が立ち並ぶ秒:
a=curr:qos e2e none
a=curr: qos e2e、なし
identifies the "current" status of qos at Alice's UA. Note: everything in SDP is with respect to the sender of the SDP message body (Alice will never tell Bob how his SDP is; she will only tell Bob about her SDP).
アリスのUAでqosの「現在」の状態を特定します。 以下に注意してください。 SDPメッセージボディーの送付者に関してSDPのすべてがあります(アリスは、彼のSDPがどのようにあるかをボブに決して言わないでしょう; 彼女は彼女のSDPに関してボブに話すだけでしょう)。
"e2e" means that capacity assurance is required from Alice's UA to
Bob's UA; thus, a lack of available capacity assurance in either
direction will fail the call attempt.
"e2e"は、容量保証がアリスのUAからボブのUAまで必要であることを意味します。 したがって、どちらかの指示に基づく、利用可能な容量保証の不足は呼び出し試みに失敗するでしょう。
Baker & Polk Informational [Page 34] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[34ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
"none" means there is no reservation at Alice's UA (to Bob) at
this time.
「なにも」は、予約が全くこのときアリスのUA(ボブへの)にないことを意味します。
The final "a=" line (a=des) identifies the "desired" level of qos:
「=」最終的な線(a=des)はqosの「必要な」レベルを特定します:
a=des:qos mandatory e2e sendrecv
a=des: qosの義務的なe2e sendrecv
"mandatory" means this request for qos MUST be successful, or the
call fails.
「義務的」が、qosを求めるこの要求がうまくいくに違いないことを意味するか、または呼び出しは失敗します。
"e2e" means RSVP is required from Alice's UA to Bob's UA.
"e2e"は、RSVPがアリスのUAからボブのUAまで必要であることを意味します。
"sendrecv" means the reservation is in both directions.
"sendrecv"は、両方の方向には予約があることを意味します。
As discussed, RSVP does not reserve bandwidth in both directions, and it is up to the endpoints to have 2 one-way reservations if that particular application (here, voice) requires it. Voice between Alice and Bob requires 2 one-way reservations. The UAs will be the focal points for both reservations in both directions.
RSVPが議論するように両方の方向に帯域幅を控えないで、その特定用途であるならそれが2つの片道予約を持つためには終点次第である、(ここ、声) それを必要とします。 アリスとボブの間の声は2つの片道予約を必要とします。 UAsは両方の方向への両方の予約のために焦点になるでしょう。
Message 2 is the 183 "Session Progress" message sent by Bob to Alice, which indicates to Alice that Bob understands that preconditions are required for this call.
メッセージ2はボブによってボブが、前提条件がこの呼び出しに必要であることを理解しているのをアリスに示すアリスに送られた183「セッション進歩」メッセージです。
[M2 - 183 "Session Progress"]
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
RSeq: 813520
Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 210
[M2--183「セッション進歩」] 以下を通って一口/2.0 183セッション進歩 SIP/2.0/TCP pc33.usmc.example.mil: 5060; ブランチ=z9hG4bK74bf9;は=10.1.3.33From:を受けました。 アリス<一口: alice@usmc.example.mil 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@usmc.example.mil 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@pc33.usmc.example.mil CSeq: 31862 RSeqを招待してください: 813520リソース優先権: dsn.routine Contact: <一口: bob@usmc.example.mil 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 210
v=0
o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
c=IN IP4 10.100.50.51
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
ボブの2890844527 2890844527IN IP4 usmc.example.mil c=IN IP4 10.100.50.51v=0o=tがなにもに0 0m=オーディオの3456RTP/AVP0a=rtpmap: 0PCMU/8000a=curr: qos e2eと等しい、a=des: qosの義務的なe2e sendrecv a=conf: qos e2e recv
Baker & Polk Informational [Page 35] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[35ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
The only interesting header in the SIP portion of this message is the RSeq header, which is the "Reliable Sequence" header. The value is incremented for every Reliable message that's sent in this call setup (to make sure none are lost or to ignore duplicates).
このメッセージのSIP部分における唯一のおもしろいヘッダーがRSeqヘッダーです。(そのヘッダーは「信頼できる系列」ヘッダーです)。 値はこの呼び出しセットアップ(なにも無くならないのを確実にするか、または写しを無視する)を送ったあらゆるReliableメッセージのために増加されます。
Bob's SDP indicates several "a=" line statuses and picks a codec for the call. The codec picked is in the m=audio line (the "0" at the end of this line means G.711 will be the codec).
ボブのSDPは数人の「=」線状態を示して、呼び出しにコーデックを選びます。 m=音声回線には選ばれたコーデックがある、(「この線手段では、G.711がコーデックであるために望んでいる終わりの0インチ)」
The a=curr line gives Alice Bob's status with regard to RSVP (currently "none").
a=curr線はRSVP(現在の「なにも」)に関してアリス・ボブの状態を与えます。
The a=des line also states the desire for mandatory qos e2e in both directions.
また、a=des線は義務的なqos e2eに関する願望を両方の方向に述べます。
The a=conf line is new. This line means Bob wants confirmation that Alice has 2 one-way reservations before Bob's UA proceeds with the SIP session setup.
a=conf線は新しいです。 この線は、ボブがアリスがボブのUAがSIPセッションを続ける前の2つの片道予約にセットアップさせる確認が欲しいことを意味します。
This is where "Note-1" applies in Figure 7. At the point that Bob's UA transmits this 183 message, Bob's UA (the one that picked the codec, so it knows the amount of bandwidth to reserve) transmits an RSVP PATH message to Alice's UA. This PATH message will take the route previously discussed in Figure 5:
これは「図7で-1インチが適用されることに注意している」ところのそうです。 ボブのUAがこの183メッセージを送るというポイントでは、ボブのUA(コーデックを選んだものによって、それは控える帯域幅の量を知っている)はRSVP PATHメッセージをアリスのUAに送ります。 このPATHメッセージは以前に図5で議論したルートを取るでしょう:
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
ボブ・->R4->R3->R2->R1->アリス
This is the path of the PATH message, and the reverse will be the path of the reservation setup RESV message, or:
または、これがPATHメッセージの経路であり、逆が予約セットアップRESVメッセージの経路になる、:
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
アリス・->R1->R2->R3->R4->ボブ
Immediately after Alice transmits the RESV message towards Bob, Alice sends her own PATH message to initiate the other one-way reservation. Bob, receiving that PATH message, will reply with a RESV.
RESVメッセージをボブに向かって送る直後、アリスは他の1方法の予約を開始する彼女自身のPATHメッセージを送ります。 そのPATHメッセージを受け取って、ボブはRESVと共に返答するでしょう。
All this is independent of SIP. However, during this time of reservation establishment, a Provisional Acknowledgement (PRACK) [M3] is sent from Alice to Bob to confirm the request for confirmation of 2 one-way reservations at Alice's UA. This message is acknowledged with a normal 200 OK message [M4]. This is shown in Figure 7.
このすべてがSIPから独立しています。 しかしながら、予約設立の今回、アリスのUAでの2つの片道予約の確認を求める要求を確認するために、Provisional Acknowledgement(PRACK)[M3]をアリスからボブに送ります。 このメッセージは正常な200OKメッセージ[M4]で承認されます。 これは図7に示されます。
As soon as the RSVP is successfully completed at Alice's UA (knowing that it was the last in the two-way cycle or reservation establishment), at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform his UA that the current status of RSVP (or qos) is "e2e" and "sendrecv".
RSVPが首尾よくアリスのUAに完成すると(それが両用サイクルか予約設立で最終であったのを知っていて)すぐに、SIP層では、RSVP(または、qos)の現在の状態が"e2e"と"sendrecv"であると彼のUAに知らせるために、UPDATEメッセージ[M5]をボブのUAに送ります。
Baker & Polk Informational [Page 36] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[36ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
[M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
UPDATE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 191
[M5--アリスがqos e2eとsendrecv] UPDATEにちびちび飲ませるボブへのUPDATE: bob@usmc.example.mil SIP/2.0Via: SIP/2.0/TCP pc33.usmc.example.mil:5060; ブランチ=z9hG4bK74bfa From: アリス<一口: alice@usmc.example.mil 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@usmc.example.mil 、gt;、呼び出しID: 3848276298220188511@pc33.usmc.example.mil リソース優先権: dsn.routine Contact: <一口: alice@usmc.example.mil 、gt;、CSeq: 10197 コンテントタイプをアップデートしてください: sdp Contentアプリケーション/長さ: 191
v=0
o=alice 2890844528 2890844528 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
RTP/AVP0a=rtpmap: 0PCMU/8000a=curr: qos e2eがa=desを送るオーディオの0 0v=0 o=alice2890844528 2890844528IN IP4 usmc.example.mil c=IN IP4 10.1.3.33t=m=49172: qosの義務的なe2e sendrecv
This is shown by the matching table that can be built from the a=curr line and a=des line. If the two lines match, then no further signaling needs take place with regard to "qos". [M6] is the 200 OK acknowledgement of this synchronization between the two UAs.
これは合っているテーブルによってa=curr線とa=des線からそれを建てることができるのが示されます。 2つの線が合っているなら、これ以上合図していない必要性は"qos"に関して行われます。 [M6]は2UAsの間のこの同期の200OK承認です。
[M6 - 200 OK to the UPDATE from Bob indicating synchronization]
SIP/2.0 200 OK sip:bob@usmc.example.mil
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: < sip:alice@usmc.example.mil >
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 195
[M6--同期を示すボブからのUPDATEへの200OK] SIP/2.0 200 OK一口: bob@usmc.example.mil Via: SIP/2.0/TCP pc33.usmc.example.mil:5060; ブランチ=z9hG4bK74bfa From: アリス<一口: alice@usmc.example.mil 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@usmc.example.mil 、gt;、呼び出しID: 3848276298220188511@pc33.usmc.example.mil リソース優先権: dsn.routine Contact: <一口: alice@usmc.example.mil 、gt;、CSeq: 10197 コンテントタイプをアップデートしてください: sdp Contentアプリケーション/長さ: 195
v=0
o=alice 2890844529 2890844529 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
0 0v=0 o=alice2890844529 2890844529IN IP4 usmc.example.mil c=IN IP4 10.1.3.33t=m=オーディオの49172RTP/AVP0a=rtpmap: 0のPCMU/8000のa=curr:qos e2e sendrecv a=des:qosの義務的なe2e sendrecv
Baker & Polk Informational [Page 37] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[37ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
At this point, the reservation is operational and both UAs know it. Bob's UA now rings, telling Bob the user that Alice is calling him. ([M7] is the SIP indication to Alice that this is taking place). Nothing up until now has involved Bob the user. Bob picks up the phone (generating [M10], from which Alice's UA responds with the final ACK), and RTP is now operating within the reservations between the two UAs.
ここに、予約は操作上です、そして、両方のUAsはそれを知っています。 アリスが彼と呼んでいるユーザをボブに言って、ボブのUAは現在、鳴ります。 ([M7]はアリスへのこれが行われているというSIP指示です。) 現在までの何もユーザのボブにかかわっていません。 ボブは電話をします、そして、(アリスのUAが最終的なACKと共に応じる[M10]を発生させて)RTPは現在、2UAsの間の予約の中で作動しています。
Now we get to Carol calling Dave. Figure 6 shows a common router interface for the reservation between Alice to Bob, and one that will also be the route for one of the reservations between Carol to Dave. This interface will experience congestion in our example.
今、私たちはデーヴに電話をするキャロルに着きます。 図6は、ボブへのアリスと、また、そうするものの間の予約のための一般的なルータインタフェースがデーヴへのキャロルの間の予約の1つのためのルートであることを示します。 このインタフェースは私たちの例における混雑を経験するでしょう。
Carol is now calling Dave at a Resource-Priority level of "Immediate", which is higher in priority than Alice to Bob's "routine". In this continuing example, Router 2's Interface-7 is congested and cannot accept any more RSVP traffic. Perhaps the offered load is at interface capacity. Perhaps Interface-7 is configured with a fixed amount of bandwidth it can allocate for RSVP traffic, and it has reached its maximum without one of the reservations going away through normal termination or forced termination (preemption).
キャロルは、現在、「即座」のResource-優先順位でデーヴに電話をしています。(優先権ではそれは、アリスよりボブの「ルーチン」に高いです)。 この継続する例では、Router2のInterface-7は混雑していて、それ以上のRSVP交通を受け入れることができません。 恐らく、提供された負荷がインタフェース容量であります。 恐らく、Interface-7はそれがRSVP交通に割り当てることができる帯域幅の定額によって構成されます、そして、正常終了か強制終了(先取り)で予約の1つが遠ざからないで、それは最大に達しました。
Interface-7 is not so full of offered load that it cannot transmit signaling packets, such as Carol's SIP messaging to set up a call to Dave. This should be by design (that not all RSVP traffic can starve an interface from signaling packets). Carol sends her own INVITE with the following important characteristics:
インタフェース-7が提供された負荷で非常にいっぱいでないので、シグナリングパケットを伝えることができません、デーヴに呼び出しをセットアップするために通信するキャロルのSIPなどのように。 これは意図的であるべきです(すべてのRSVP交通ではなく、それがシグナリングパケットからのインタフェースを飢えさせることができます)。 キャロルは以下の重要な特性がある彼女自身のINVITEを送ります:
[M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
[M1--キャロルからRP=即座の、そして、QOS=e2eの、そして、義務的なデーヴまでのINVITE]
This packet does *not* affect the reservations between Alice and Bob (SIP and RSVP are at different layers, and all routers are passing signaling packets without problems). Dave sends his M2:
このパケットはアリスとボブの間で*でないのが影響する*に予約します(SIPとRSVPが異なった層にあります、そして、すべてのルータが問題なしでシグナリングパケットを通過しています)。 デーヴは彼のM2を送ります:
[M2 - 183 "Session Progress"]
[M2--183「セッション進歩」]
with the SDP chart of:
以下のSDP図で
a=curr:qos e2e none
a=curr: qos e2e、なし
a=des:qos mandatory e2e sendrecv
a=des: qosの義務的なe2e sendrecv
a=conf:qos e2e recv
a=conf: qos e2e recv
Baker & Polk Informational [Page 38] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[38ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
indicating he understands RSVP reservations are required e2e for this call to be considered successful. Dave sends his PATH message. The PATH message does *not* affect Alice's reservation; it merely establishes a path for the RESV reservation setup message to take.
彼が分かるのを示して、RSVPの予約はうまくいくと考えられるというこの要求のための必要なe2eです。 デーヴは彼のPATHメッセージを送ります。 PATHメッセージは*でないのが影響する*にアリスの予約をします。 それは取るRESV予約セットアップメッセージのために単に経路を確立します。
To keep this example simple, the PATH message from Dave to Carol took this route (which we make different from the route in the reverse direction):
この例を簡単に保つために、デーヴからキャロルまでのPATHメッセージはこのルート(私たちがルートと反対の方向に異なるようにする)を取りました:
Dave -> R8 -> R7 -> R6 -> R5 -> Carol
デーヴ・->R8->R7->R6->R5->キャロル
causing the reservation to be this route:
予約がこれであることを引き起こして、以下を発送してください。
Carol -> R5 -> R6 -> R7 -> R8 -> Dave
キャロル・->R5->R6->R7->R8->デーヴ
The Carol-to-Dave reservation above will not traverse any of the same routers as the Alice-to-Bob reservation. When Carol transmits her RESV message towards Dave, she immediately transmits her PATH message to set up the complementary reservation.
キャロルからデーヴへの上の予約はアリスからボブへの予約と同じルータのいずれも横断しないでしょう。 キャロルがすぐに彼女のRESVメッセージをデーヴに向かって送るとき、彼女は補足的な予約をセットアップするPATHメッセージを送ります。
The PATH message from Carol to Dave be through routers:
ルータを通してキャロルからデーヴまでのPATHメッセージは以下の通りです。
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
キャロル・->R5->R2->R3->R8->デーヴ
Thus, the RESV message will be through routers:
したがって、ルータを通してRESVメッセージがあるでしょう:
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
デーヴ・->R8->R3->R2->R5->キャロル
This RESV message will traverse the same routers, R3 and R2, as the Alice-to-Bob reservation. This RESV message, when received at Interface-7 of R2, will create a congestion situation such that R2 will need to make a decision on whether:
このRESVメッセージはアリスからボブへの予約として同じルータ、R3、およびR2を横断するでしょう。 R2のInterface-7に受け取るとこのRESVメッセージが決定するR2がそうするようなものがそうしなければならない混雑状況を作成する、:
o to keep the Alice-to-Bob reservation and error the new RESV from
Dave, or
o またはデーヴからアリスからボブへの予約と誤りが新しいRESVであることを保つために。
o to error the reservation from Alice to Bob in order to make room
for the Carol-to-Dave reservation.
o 誤りへのアリスからボブまでの予約、キャロルからデーヴへの予約に場所を開けてください。
Alice's reservation was set up in SIP at the "routine" precedence level. This will equate to a comparable RSVP priority number (RSVP has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave's RESV equates to a precedence value of "immediate", which is a higher priority. Thus, R2 will preempt the reservation from Alice to Bob and allow the reservation request from Dave to Carol. The proper RSVP error is the ResvErr that indicates preemption. This message travels downstream towards the originator of the RESV message (Bob). This clears the reservation in all routers downstream of R2 (meaning
アリスの予約はSIPに「通常」の先行レベルで設定されました。 これは匹敵するRSVP優先順位番号に一致するでしょう(RSVPには、6万5535の優先順位の値、または[RFC3181]あたり2*32ビットがあります)。 デーヴのRESVは「即座」の先行値に一致しています。(それは、より高い優先度です)。 したがって、R2はアリスからボブまで予約を先取りして、デーヴからキャロルまで予約の要請を許容するでしょう。 適切なRSVP誤りは先取りを示すResvErrです。 このメッセージはRESVメッセージ(ボブ)の創始者に向かって川下を旅行します。 これが川下ですべてのルータにおける予約からR2を取り除く、(意味
Baker & Polk Informational [Page 39] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[39ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
R3 and R4). Once Bob receives the ResvErr message indicating preemption has occurred on this reservation, Bob's UA transmits a SIP preemption indication back towards Alice's UA. This accomplishes two things: first, it informs all SIP Servers that were in the session setup path that wanted to remain "dialog stateful" per [RFC3261], and second, it informs Alice's UA that this was a purposeful termination, and to play a preemption tone. The proper indication in SIP of this termination due to preemption is a BYE Method message that includes a Reason Header indicating why this occurred (in this case, "Reserved Resources Preempted"). Here is the message from Bob to Alice that terminates the call in SIP.
R3とR4) ボブがいったん先取りがこの予約に起こったのを示すResvErrメッセージを受け取ると、ボブのUAはSIP先取り指示をアリスのUAに向かって伝えて戻します。 これは2つのものを達成します: まず最初に、それは、[RFC3261]あたりの「対話stateful」、2番目のままで残って欲しくて、これが故意の終了であり、プレーするために、先取りが調子を変えることをアリスのUAに知らせることをセッションセットアップ経路にあったすべてのSIP Serversに知らせます。 先取りによるこの終了のSIPの適切な指示はこれがなぜ起こったかを示すReason Header(この場合「先取りされた予約されたリソース」)を含んでいるBYE Methodメッセージです。 ここに、ボブからSIPで呼び出しを終えるアリスまでメッセージがあります。
BYE sip:alice@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP swp34.usmc.example.mil
;branch=z9hG4bK776asegma
To: Alice <sip:alice@usmc.example.mil>
From: Bob <sip:bob@usmc.example.mil>;tag=192820774
Reason: preemption ;cause=2 ;text=reserved resourced preempted
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 6187 BYE
Contact: <sip:bob@usmc.example.mil>
BYE一口: alice@usmc.example.mil SIP/2.0Via: SIP/2.0/TCP swp34.usmc.example.mil; ブランチ=z9hG4bK776asegma To: アリス<一口: alice@usmc.example.mil 、gt;、From: ボブ<一口: bob@usmc.example.mil 、gt;、; タグ=192820774は推論します: 先取り; 原因=2; =が予約したテキストは先取りされたCall-IDの再出典を明示しました: 3848276298220188511@pc33.usmc.example.mil CSeq: 6187年のさようなら接触: <一口: bob@usmc.example.mil 、gt。
When Alice's UA receives this message, her UA terminates the call, sends a 200 OK to Bob to confirm reception of the BYE message, and plays a preemption tone to Alice the user.
アリスのUAがこのメッセージを受け取るとき、彼女のUAは呼び出しを終えて、BYEメッセージのレセプションを確認するために200OKをボブに送って、ユーザのアリスに先取りトーンをプレーします。
The RESV message from Dave successfully traverses R2, and Carol's UA receives it. Just as with the Alice-to-Bob call setup, Carol sends an UPDATE message to Dave, confirming she has QoS "e2e" in "sendrecv" directions. Bob acknowledges this with a 200 OK that gives his current status (QoS "e2e" and "sendrecv"), and the call setup in SIP continues to completion.
デーヴからのRESVメッセージは首尾よくR2を横断します、そして、キャロルのUAはそれを受けます。 ちょうどアリスからボブへの呼び出しセットアップのように、キャロルはUPDATEメッセージをデーヴに送ります、彼女が"sendrecv"方向にQoS"e2e"を持っていると確認して。 ボブは彼の現在の状態(QoS"e2e"と"sendrecv")を与える200OKでこれを承認します、そして、SIPでの呼び出しセットアップは完成に続きます。
In summary, Alice set up a call to Bob with RSVP at a priority level of Routine. When Carol called Dave at a high priority, their call would have preempted any lower priority calls if there were a contention for resources. In this case, it occurred and affected the call between Alice and Bob. A router at this congestion point preempted Alice's call to Bob in order to place the higher-priority call between Carol and Dave. Alice and Bob were both informed of the preemption event. Both Alice and Bob's UAs played preemption indications. What was not mentioned in this appendix was that this document RECOMMENDS that router R2 (in this example) generate a syslog message to the domain administrator to properly manage and track such events within this domain. This will ensure that the domain administrators have recorded knowledge of where such events occur, and what the conditions were that caused them.
概要では、アリスはRoutineの優先順位におけるRSVPと共にボブへの呼び出しにセットしました。 キャロルが、高い優先度でデーヴに電話をしたとき、リソースのための主張があるなら、彼らの呼び出しはどんな低優先度呼び出しも先取りしたでしょうに。 この場合、それは、起こって、アリスとボブの間の呼び出しに影響しました。 この混雑ポイントのルータは、より高い優先度電話をキャロルとデーヴの間にするためにアリスの呼び出しをボブに先取りしました。 アリスとボブは先取り出来事においてともに知識がありました。 アリスとボブのUAsの両方が先取り指摘をプレーしました。 この付録で言及されなかったことはこれがルータR2(この例の)が適切に管理するためにドメイン管理者へのsyslogメッセージを発生させるRECOMMENDSを記録して、このドメインの中でそのような出来事を追跡するということでした。 これは、ドメイン管理者がそれがそれらを引き起こしたというそのような出来事がどこに起こるか、そして、状態が何であったかに関する知識を記録したのを確実にするでしょう。
Baker & Polk Informational [Page 40] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[40ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
Authors' Addresses
作者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
デル・レイカリフォルニア93117サンタバーバラ(米国)経由でフレッドベイカーシスコシステムズ1121
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
以下に電話をしてください。 +1-408-526-4257 Fax: +1-413-473-2403 メールしてください: fred@cisco.com
James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェイムズ・ポークシスコシステムズ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
Phone: +1-817-271-3552 EMail: jmpolk@cisco.com
以下に電話をしてください。 +1-817-271-3552 メールしてください: jmpolk@cisco.com
Baker & Polk Informational [Page 41] RFC 4542 ETS in an IP Network May 2006
IPにおけるベイカーとポーク情報[41ページ]のRFC4542ETSは2006年5月をネットワークでつなぎます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Baker & Polk Informational [Page 42]
ベイカーとポークInformationalです。[42ページ]
一覧
スポンサーリンク
