Network Working Group F. Baker
Request for Comments: 4542 J. Polk
Category: Informational Cisco Systems
May 2006
Implementing an Emergency Telecommunications Service (ETS) for
Real-Time Services in the Internet Protocol Suite
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).
著作権（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.
RFC 3689およびInternet防災サービス（IEPS）は一部だろうそのうち緊急通信サービス（ETS）のための3690枚の詳細要件。この種のサービスの一部は、プリエンプションを呼び出す必要です。他の人は、コールキューイングまたは他のメカニズムが必要です。 IEPSは、このアーキテクチャのニーズを満たすデータのためのコールアドミッション制御（CAC）の手順とパーホップの動作（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.
それはマルチレベル優先順位および優先処理（MLPP）と政府の緊急通信サービス（GETS）規格に焦点を当てているため、この文書では、主に、米国政府とNATOの文脈でETSをサポートについて説明します。ここで説明するアーキテクチャは、これらの組織を越えて適用されます。
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. Overview of the Internet Emergency Preference Service Problem and Proposed Solutions
インターネット緊急時の優先サービスの問題と提案されたソリューションの概要
[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]インターネット緊急優先サービス（IEPS）の一部であると思われる緊急通信サービス（ETS）のための詳細な要件。この種のサービスの一部は、プリエンプションを呼び出す必要です。他の人は、コールキューイングまたは他のメカニズムが必要です。重要な要件は、危機の時に許可されたユーザへの呼完了の高い確率を保証することです。
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は、コールアドミッション制御手順と、このアーキテクチャのニーズを満たすデータのパーホップの動作を必要とします。このようなCAC手順とPHBは、リアルタイムのセッションを設定するには、H.323またはSIPを使用するかもしれない任意のサービスに適切です。これらは明らかに含まれるが、これでは、コミュニティのほとんどはIP上の声について考えている、とドキュメントの例の多くは、その環境から取得され書き込みが、音声およびビデオアプリケーションに限定されるものではありません。
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.
呼が後で拒否または拒絶されていない最初に許可ネットワークでは、容量許可手順が十分であり得る呼設定時にのみ実行します。しかし、より高い優先コールが既存のコールに優先提供負荷や変更（（新しいルートがそれらに切り替え呼び出しを実行する能力に欠けているとき）、セッションの状態が原因ルーティングの変化にネットワークによってレビューおよびプリエンプトまたは拒否することができ、ネットワーク内の）、様々な呼び出しの状態の継続的なモデルを維持することが必要となります。
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）を解決し、システムのアーキテクチャを意図している問題を議論しましょう。マルチレベル優先順位および優先処理（MLPP）、および政府の緊急通信サービス（GETS）：緊急通信サービス[ITU.ETS.E106]は後継と米国で使用される2つのサービスを一般化したものです。これらのモデルに基づいたサービスは、世界各国の様々な使用されている、両方の公衆交換電話網（PSTN）とモバイル通信用グローバルシステム（GSM）ベーススイッチ。これらのサービスの両方が、危機の時代に電話ネットワークからサービスを取得するために許可されたユーザを有効にするために設計されています。彼らは、主に使用し、優先度のレベル数が認めメカニズムが異なります。
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.
確実なサービスは、[ITU.MLPP.1990] [ANSI.MLPP.Spec] [ANSI.MLPP.Suppマルチレベル優先順位および優先処理として知られている既存のITU-T / NATO /国防総省電話システムアーキテクチャのIP実装として設計されています]、またはMLPP。 MLPPは、低優先順位の通信を犠牲にしてより高い優先順位の通信を可能に関連NATO及び国防総省コマンドにおける緊急時に、通信の各種の相対的重要性は、厳密に定義されているように、優先呼処理サービスのためのアーキテクチャです。この文書では、防衛のNATOと米国務省は、MLPPの使用について説明しますが、アーキテクチャおよび標準は、これらの組織の適用外です。
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.
フラッシュオーバーライドオーバーライド：最高司令官、国防長官、および統合参謀本部、戦闘コマンドの司令官戦争状態の存在を宣言することによって使用。戦闘コマンドの司令官大統領は音声会議システム会議をセキュア世界と連動して許可することができることを防衛条件の一つまたは防衛救急や防空緊急時やその他の国家機関を宣言する。フラッシュオーバーライドオーバーライドを先取りすることができません。この優先レベルは、すべての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.
フラッシュオーバーライド：最高司令官、国防長官、および統合参謀本部、戦闘コマンドの司令官戦争状態の存在を宣言することによって使用。防衛条件の一つまたは防衛緊急時やその他の国家機関を宣言するときに戦闘コマンドの司令官社長が承認することができます。フラッシュオーバーライドはDSNでプリエンプトすることはできません。
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, 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.
即時：重々しく国家と同盟軍のセキュリティに影響を与える状況に関連する電話の通話のために一般的に確保、攻撃後の期間における力の再構築、国家安全保障に不可欠なインテリジェンス、軽減または戦争の脅威を制限するための外交交渉の実施、国家の生存に不可欠な連邦政府の措置の実施、重大即時を有する内部国家の安全保障、民間防衛アクション、人口の福祉に即時かつ有害な作用を有する大規模な深刻さの災害やイベント、または重要な情報に影響を与える状況航空機、宇宙船、またはミサイル事業への影響。
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.
MLPPは、発信者が呼の開始時に上記優先レベルのいずれかを割り当てる必要がある積極的なシステムとして構築されています。この優先レベルは、その呼び出し全体で変更することはできません。上昇ステータスは通話開始時にユーザが割り当てられていない場合、コールは「日常的」であると想定されます。電話をかけるために、エンドツーエンドの容量がある場合は、任意の呼び出しはいつでも配置することができます。受け入れるか、継続できるようにするために呼び出すためにどのようしかし、任意の（回路の世界で）トランクグループまたは（IPの世界では）インタフェースが使用率のしきい値に達したときに、選択がなされなければなりません。システムが配置される高優先コールを可能にするために、優先順位の低い既存のコール（または呼び出し）を先取りすることによってそれほど重要コールに優先して、より重要なコールを発信する必要がトランク（S）または帯域幅をつかむであろう。
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.
より多くのトランクまたは帯域幅は、この優先順位の高いコールのために必要である場合は、複数の呼び出しが正常に横取りされる可能性があります。いくつかの優先順位の低い音声通話と競合（おそらく384 KBPS、もしくは6つのトランクの）ビデオ通話は、このような状況の良い例です。
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のシグナリング技術を使用して、しかし、民間のネットワークで使用するために構築された米国のサービスは、政府の緊急通信サービス（GETS）です。それは、プリエンプションを使用していませんが、むしろ埋蔵帯域幅やキューは、通話完了の高い確率を得るために呼び出して、それがサービスの2つのレベルだけがあります：これは、2つの方法でMLPP異なり「日常」と「優先順位」。
GETS is described here as another example. Similar architectures are applied by other governments and organizations.
別の例として、ここで説明されて取得します。同様のアーキテクチャは、他の政府機関や組織によって適用されます。
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に、アドミッション制御（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手順は、発信者が使用を許可され、プリエンプションが、いくつかのネットワークでそれが起こる作るの一部であってもよいことを、利用可能な帯域幅を検出します。
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によって提供される負荷を超えるネットワークでは：1、輸送中に発生したジッタ及び損失は、公称です。これは、一般に、適切に操作されたイーサネットLANのネットワークと光ネットワーク（51 MBPSの倍数でそのリンク速度を測定するネットワーク）の特性です。このような非同期転送モード（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.
また、主に戦術的な展開では、ネットワークの局所的なインフラで帯域幅の制約を見つけることが一般的です。例えば、米海軍のネットワークが浮かんで5つのネットワークオペレーションセンター（NOCが）に、衛星を介して、約300船を接続し、それらのNOCは、今度はアメリカ国防情報システム局（DISA）バックボーンを介して相互に接続されています。典型的な船はしばしばが64kbps以下の速度で、乗って2〜6の無線システムとの間に有していてもよいです。米軍のネットワークでは、現在の無線技術は、同様に、100 KBPS以下のリンクに戦術通信を制限します。
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.
このインフラストラクチャ上で、軍事通信は、伝統的なメールに加えて、MPEG 2（3-7 MBPS）とMPEG 4（800 kbpsに80 kbps）を使用してファイルを音声通信システム（セッションあたり30-80 KBPS）とビデオ会議を展開することを期待します転送、およびトランザクショントラフィック。
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]のシリーズを発表しました。一言で言えば、彼らは、ネットワーク内のトラフィックの流れの挙動を予測するために、1は二つのことを知っていなければならないことを示しました。
o the rate and arrival distribution with which traffic in a class is introduced to the network, and
クラスのトラフィックがネットワークに導入される速度と到着分布O、及び
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システムでは、例えば、コーデックは80 Kbpsのデータストリームは、その壁及び問題のトラフィックの量を説明することを決定します。人は壁の前で歩くか、カメラが動いている物体を指摘されている場合は、コーデックを簡単正確にそれが見るものを記述するための努力で800 KBPSを送信することができます。広告が表示される期間を並べることが商業放送のスポーツでは、効果が目を引く広告は緑のサッカー場を指しカメラよりもはるかに多くの帯域幅を必要とするので、トラフィックレートが突然特定の時間に、すべてのチャネル間でジャンプするということです。
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の初の要件を確保するためにしなければならない二つのものは基本的にあります。 1つの提案どのくらいのアプリケーションが提示している負荷を知っていることを確認するためには、警察（対策負荷が提供され、過剰捨てる）トラフィックがネットワークに入る必要があります。無視できない損失が音声やビデオに持っているように、そのポリシングの動作がアプリケーションに衰弱させる効果を持っている場合、1は、いくつかのポリシーに従って慎重にセッションを認めなければなりません。その政策の重要な特徴は、提供された負荷がアプリケーションに専用の容量を超えないようにする必要があります。
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がしなければならない他の事は、アプリケーションのニーズが損失、遅延の変動、およびエンドツーエンド遅延の面で満たされていることを確認しています。これを行う1つの方法は、損失やジッタが公称されているように、十分な帯域幅を提供することです。それが達成できない場合、一つは決定論の目標を達成するために、帯域幅を適用するためにキューイング技術を使用する必要があります。
The key elements of the Internet Emergency Preference Service include the following:
インターネット緊急時の優先サービスの重要な要素は、次のものがあります。
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.
各呼び出しをマーキング優先レベル：コールのユーザ知覚重要性に基づいて、イニシエータは、各コールのための適切な優先レベルを選択し呼び出します。このレベルでは、コールの期間中に変更されるべきではありません。前のコールと後の呼び出しは、このレベルの選択に関しては独立しています。
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.
呼び出しの認証と承認に置か：高い状態で電話をかけることへの不正な試みは許可されていません。電話システムでは、これは、スイッチプラススイッチに自分自身を識別する発呼者により生成されたコードによって、機器に適用されるポリシーを制御することによって管理されています。インターネットでは、このような特性を明示的にシグナリングされなければなりません。
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システムでは、1は基本的に同じサービスに対して望んでいるだろう。
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.
インターネット緊急時の優先サービスのVoIPの実装では、定義により、これらの特性を提供する必要があります。
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.
この手順を十分に分析することができます前に、ベッドに置かれる必要があるのQoS手順への帯域幅の関係について、インターネット界での議論があります。問題は、帯域幅の問題を解決することが可能とインターネットの特定の部分では一般的であるということです。 10 Mbpsイーサネット、100Mbpsの1つのギガビット100 MBPSを代入：LAN環境では、例えば、任意の2つのスイッチ間、またはスイッチとサーバの間の有意な損失がある場合、最も簡単で最も安価な解決策は、次の高速インタフェースを購入することです、または、そのことについては、10ギガビットイーサネットにアップグレードしてください。同様に、光ネットワーキング環境で、最も簡単で最も安価な解決策は、光路のいずれかのより速い光搬送波を選択するか、追加のラムダを展開することによって、データレートを増加することがしばしばあります。帯域幅が損失またはキューイング遅延が無視できる点までオーバープロビジョニングすることができる場所、10：1のオーバープロビジョニングの方法により、将来的な要件のための成長経路を提供しています、多くの場合、最も安いと最も確実なソリューションです。しかし、効果的に無限の帯域幅を提供するが、多くのアクセスネットワーク、衛星通信、固定無線、空中、海洋通信、島接続、光ファイバ接続がされていない領域への接続を含む、実行可能ではない通信ネットワークの多くの場所があります費用対効果の高いです。これは、リソース管理の問題が関連しているこれらの場所です。具体的には、我々はよう、ネットワークの安定性やクラスなどのリアルタイムトラフィックの継続性に固有の保護を提供集約サービスの提供から離れて100 Mbpsを超えるリンク上で有効なQoS手続きの導入をお勧めしません。このような回路の数学が要件としてこれをサポートしていません。
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.
要するに、我々はポリシー制御のこのクラスを議論しているという事実は、ネットワーク内の、このようなくびれが存在し、対処されなければならないと述べています。しかし、多くの我々は、それらの場所で私たちは、帯域幅の問題を解決していないのが好きかもしれません。
A typical voice or video network, including a backbone domain, is shown in Figure 1.
骨格ドメインを含む典型的な音声またはビデオネットワークは、図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 .
. .
............
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
図1：一般的なのVoIPやビデオ/ IPネットワーク
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.
上の図を見直し、それが音声/ IPおよびビデオ/ IPコールフローは、コールがPSTNに流れるよりも非常に異なっていることが明らかになりました。 PSTNでは、呼制御は、スイッチを横断するターンコントロールでATMや時分割多重（TDM）スイッチやマルチプレクサのようなサービスを扱うデータ。それらは物理的に同じ場所に配置されないかもしれないが、制御プレーンソフトウェアおよびデータプレーンサービスが密接に接続されています。スイッチのルートが使用可能であることを知っている帯域幅を使用してコール。音声/ビデオ・オン・IPネットワークでは、呼制御が完全にデータプレーンから離婚されています。それは、そのSIPプロキシがあることを起こるところであれば、スウェーデンの電話番号を持っている米国の電話機器用可能ですが、それは、アジア/太平洋地域でのみデータ・パスを使用するために任意の呼び出しで、データパスは、多くの場合、データパスが複数の企業/プロバイダが提供する、別の会社が提供する、と。
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私は行政政策の観点から、この電話をかけることはできますか？私はこの呼び出しを行うために許可されていますか？
o What IP address correlates with this telephone number or SIP URI?
OどのようなIPアドレスは、この電話番号またはSIP URIと相関しますか？
o Is the other instrument "on hook"? If it is busy, under what circumstances may I interrupt?
O「オンフック」他の楽器ですか？それがビジー状態の場合、どのような状況下で、私は中断できますか？
o Is there bandwidth available to support the call?
oは呼び出しをサポートするために利用可能な帯域幅がありますか？
o Does the call actually work, or do other impairments (loss, delay) make the call unusable?
oは呼び出しが実際に動作しない、または他の障害（損失、遅延が）呼び出しが使用できなくなるのですか？
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?".
行政コールアドミッションは、SIPとH.323の目的です。それはのような基本的な質問尋ねる「IPアドレスがで呼び出し先で何を？」そして「あなたの手形を支払うましたか」。
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].
コールプリエンプションのような専用のポリシーについて、の2つの機能は、管理の観点から必要である：[RFC4412]は、コールの優先順位に関するポリシー関連情報を通信するための方法を提供します。呼び出しが失敗した場合や、イベントの原因を示す、拒否されたときに、[RFC4411]は理由コードを提供します。それは障害がある場合は、コールをリダイヤルする意味があります。それは政策主導のプリエンプションの場合は、通話がリダイヤルされている場合でも、電話をかけることができないことがあります。このサービスの要求はさらに、[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:
SIP通信リソース優先順位ヘッダ（またはRPヘッダ）がコールの開始によって選択された優先レベルとの呼設定プロセスを提供しています。構文は次の形式であります：
Resource Priority: namespace.priority level
リソースプライオリティ：namespace.priorityレベル
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.
構文の「名前空間」部分は、コールの発信元に意義のドメインを確実にし、これは、エンドツーエンド（と呼ばれる）宛先装置（電話）へ移動します。受信電話は、名前空間をサポートしていない場合、それは簡単にセットアップ要求を無視することができます。起源のドメインを意味するこの機能は、サービスレベル契約（SLA）はIEPSドメインに優遇措置を得るために、未知の依頼者の能力を制限するための場所であることを可能にします。
For the DSN infrastructure, the header would look like this for a routine precedence level call:
DSNのインフラストラクチャのために、ヘッダは、ルーチン優先レベルのコールのために次のようになります。
Resource Priority: dsn.routine
リソースプライオリティ：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).
このヘッダに選択された優先レベルは、その優先レベルを使用するように要求者の権限プロファイルと比較されるであろう。これは通常、（彼らが使用を許可されていないレベルを使用していないことを確認する）優先レベルの要求者の選択を含む呼設定要求の多くの側面に挑戦することができSIP最初のホッププロキシに起こるであろう。
The DSN has 5 precedence levels of IEPS, in descending order:
DSNは、降順に、IEPSの5つの優先レベルを有しています。
dsn.flash-override
dsn.flashオーバーライド
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:
米国防衛レッドネットワーク（DRSN）を交換、[RFC4412]にIANAに登録された別の例として、優先順位の6つのレベルを有しています。 DRSNは単に社長と少数精鋭他の人が使用するフラッシュオーバーライドより1つの優先レベルが高いほど追加します。
drsn.flash-override-override
drsn.flashオーバーライドオーバーライド
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.
名前空間は、このレベルのために変更されたことに注意してください。 DRSN内の下の5つのレベルはまた、すべてのDRSN発信呼設定要求のための彼らの名前空間としてこれを持っているでしょう。
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.
ヘッダー（RPH）が通知リソース優先の両方とのポリシーベースのプリエンプションを容易にするために、（同じデータパスのサービスを取得するために、呼び出し元と同じDSCPを使用する必要がある）呼び出される側のDifferentiated Service Code Point（DSCP; DiffServコードポイント）を使用します適切な場合、進行中のコール。
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 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).
呼がIEPSドメインで確立されると、[RFC4411]に記載のプリエンプションのためのReasonヘッダは、すべてのSIPノードがエンドポイントでまたは輻輳を経験ルータのいずれかで発生するプリエンプションイベントに同期されることを保証します。 SIPにおいて、セッションの終了のための通常の指標は[RFC3261]で指定されるようにBYEメソッド要求を送信するために1つのエンドシステムのためのものです。これは、あまりにも、それは本質的に突然終了する理由のピアに通知する追加情報を正常終了を行うように、起因プリエンプションのイベントの呼び出しの終了をシグナリングするための適切な手段である：それはプリエンプションが発生したことを示します。これは、関連するすべてのSIPエンティティに通知するために使用され、このするかどうかをエンドポイント生成プリエンプションのイベントがあった、またはプリエンプションのイベントは、通信経路に沿ったルータ内に発生したこと（セクション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.
図2は、アリスとボブとの間の呼の層7の優先順位を含むSIPコールセットアップの簡単な例です。アリスは成功した「日常」の優先レベルでボブへの呼を設定した後、キャロルは、優先順位の高いレベル（即時）でボブを呼び出します。 SIP層（これはまだRSVPとは何の関係もありません。その一例を、SIPやRSVPシグナリングを含む、付録にある）で、Bobのユーザエージェント（電話が）キャロルからのINVITEメッセージを受信すると、彼のUAは選択をする必要がありますアリスへの呼び出しを保持し、「ビジー」表示キャロルを送信、またはキャロルからの呼び出しを受け入れることに賛成してアリスへの呼び出しを先取り間。 IEPSネットワークにおけるその選択は、リソースプライオリティヘッダーの比較です。ボブへのコールの優先レベルを制御アリスは、「ルーチン」（ネットワーク内の最低レベル）で彼に彼女のコールの優先レベルを送りました。ボブへの呼び出し信号の優先順位を制御キャロルは、「即時」（「日常」よりも高い）に彼女の優先度レベルを送りました。ボブのUAは（IEPSポリシーの下で）アリスからの呼び出しを先取り（通話終了メッセージでプリエンプション表示で彼女を提供）する必要があります。ボブが正常キャロルからのコールセットアップに答える必要があります。
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
図2：優先呼確立とSIPレイヤーで終了
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.
SIP以外のこの例では何も関与するメカニズム。また、各ユーザエージェントは、各メッセージにおけるリソース優先ヘッダ名前空間の値を認識しているものとします。したがって、ドメインがアリス、ボブ、およびキャロルは、通信を許可するものとします。認証と承認は、このドキュメントの後半で説明されています。
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].
データパスで使用されるサービスアーキテクチャの品質は、[RFC2475]のものです。差別化サービスは、データストリームを識別するためにDSCP [RFC2474]と呼ばれるIPヘッダ内のフラグを使用し、その後に、手順あたりホップの動作、またはPHBと呼ばれる適用します。これは、[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, 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.
データパスでは、緊急転送PHB [RFC3246] [RFC3247]は、音声およびビデオトラフィックの基本的なニーズを説明しています。このPHBは、十分な帯域幅、遅延及び損失率のばらつきを確実にするために、リアルタイムトラフィックに専用であることを確実にすることを伴うコーデックは過剰損失[G711.1] [G711.3]によって妨害されているように、最小です。帯域幅は、高濃度過剰プロビジョニングされるネットワークの部分で、残存懸念がなくてもよいです。帯域幅がより制約されたネットワーク内の場所では、これは、プライオリティキューを使用する必要があります。プライオリティキューを使用する場合は、乱用の可能性は、それが虐待を検出し、管理するキューに配置も警察のトラフィックに必要であることを意味し、存在しています。基本的な質問は、「どここのポリシングは場所を取る必要があるのか？」です。明白な場所は、ファーストホップルータと収束するデータストリームがリンクを混雑する可能性のある場所でしょう。
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.
いくつかの提案は、コールのサービスの優先順位に適切な様々なコードポイントでトラフィックをマーク。トラフィックが（適用能力が提供される荷重を超える、遅延のばらつきが最小であり、損失は無視できる）全て同じキューにあり、EFサービス要件が満たされている場合、通常のサービスでは、トラフィックマーキングの詳細があればパケットとして、無関係であるべきです右のサービスクラスに入ります。次に、主要な問題は、特にルート変更の周りに、トラフィックの適切なポリシングであり、パスが十分な容量を持っていることを保証します。
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.
リアルタイム音声/ビデオ・アプリケーションは、一定のビットレートストリームまたはそのレート指定された範囲内で可変であるストリームのいずれかであり、その内容およびコーデックに適切な速度でトラフィックを生成しなければなりません。フレームリレーやATMなどの伝統的な仮想回線網で行われた第1ホップルータは、アプリケーションによって発信されたトラフィックをポリシングする必要があります。 （いくつかのネットワークは、データ端末装置（DTE）とデータ通信装置（DCE）と呼んで）これら2つのチェックの間に、アプリケーショントラフィックが許容範囲内であることが保証されるべきです。そのため、帯域幅を意識したコールアドミッション制御与えられ、最小限の実際の損失があるはずです。損失が発生する場合は、ルーティングが最近変更されたとCACが追いついていない場合、または統計的しきい値がCACで使用されていると、データストリームは、それらのピークレートで一致して起こる場合があります。
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 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?"
Parekhのの第2の条件が満たされている：私たちは、ネットワークのトラフィックが何をするか知っている必要があります。提供され、負荷が利用可能な帯域幅を超えている場合、ネットワークが発言し、過剰なトラフィックをドロップします。キーの質問は、「1つの限界が利用可能な帯域幅以下のレートに負荷を与えない方法は？」となってそして「一つは、それぞれ適切なマーキングでどのくらいのトラフィックを認めるのか？」
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.
多くの利用可能な音声およびビデオコーデックが許容できるパフォーマンスを提供するために、名目損失率を必要とするので、Parekhの初の要件は、与えられた負荷が利用可能な容量の範囲内であることです。いくつかの可能なアプローチがあります。
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.
一般にH.323ネットワークで使用されるアプローチは、同時にゲートキーパーによって受け入れられたコールの数を制限することです。彼らはネットワークへの単一の入口/出口の近くにステートフルSIPプロキシを置くとSIPネットワークは、類似した何かをします。これは、ネットワークまたは重大なリンクを横断するコールの合計数のコールの合計数に上限を課すことが可能です。しかし、ゲートキーパーは、ルーティングの知識を持たないので、エンジニアリングは非常に保守的でなければならず、通常、単一の入口/出口またはそのデータ経路のうちの1つの故障を推定します。これは短期的な回避策として働くことができるが、それは容易に展開されている一般的なソリューションではありません。これは、ネットワーク設計の選択肢を制限します。
[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]は、容量の使用のための合図入場を提供します。推奨されるアプローチは、プリエンプションの概念をサポートする、明示的な容量の入場です。そのような手順の例は、リソース予約プロトコル[RFC2205]、[RFC2209]（RSVP）を使用します。 SIPとRSVPを使用して容量入場の使用は、[RFC3312]に記載されています。コールカウントがH.323で指定されている間、ネットワーク容量の入場は現時点ではH.323と統合されていません。
2.3.1. RSVP Admission Using Policy for Both Unicast and Multicast Sessions
2.3.1. ユニキャストとマルチキャストセッションの両方のためのポリシーを使用してRSVP入場
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は、マルチキャストおよびユニキャストフローのためのリソース予約の一方向（時）の設定を提供するリソース予約セットアッププロトコルです。各予約は、一つの方向に設定されている（各エンドシステムから1つの予約を意味し、マルチキャスト環境において、N個の送信者がN予約を設定します）。これらの予約は、エンドシステムとの間の経路に沿った各ルータを介して確定的帯域幅割り当てとの間の通信経路を完成します。これらの予約は、エンドツーエンド通信のためのサービスの既知の品質を設定し、ノード内の「ソフト状態」を維持します。用語「ソフト状態」の意味は、ネットワークの停止またはルーティングの変更の場合には、これらの予約は、手動による介入なしでクリアされますが、定期的にリフレッシュしなければならないということです。 RSVPでは、リフレッシュ期間は、デフォルトでは30秒ですが、限り適切であるようなものであってもよいです。
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は、ローカル指向のプロセスではなく、ルーティングプロトコルまたはH.323コールカウントのようなグローバルにまたはドメイン指向の一つです。それはルーティングパスを決定するために、ローカルルーティングデータベースを使用するが、それは、デバイスを介して特定のまたは集約フローのためのサービスの品質にのみ関係しています。 RSVPは、ネットワーク層の下に動作し、QoSおよびそのRSVP対応の隣接関係のローカル目的以外に気づいていないです。それ自体でプロセスはどちらも必要とすることも、いずれかのエンドツーエンドのネットワークの知識や状態を持っています。それはすべてのノードが参加していすることなく、ネットワーク内の一部のノードで有効になっているときにこのように、RSVPが有効であることができます。
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
図3：ホストおよびルータでRSVP
Figure 3 shows the internal process of RSVP in both hosts (end systems) and routers, as shown in [RFC2209].
[RFC2209]に示すように、図3は、両方のホスト（エンドシステム）やルータにRSVPの内部処理を示しています。
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は、データ・フローは、サービスの品質をどのように受け取るかのメカニズムを記述するために、フレーズ「トラフィック制御」を使用しています。 （ホストとルーターの両方で、図2に示されている）トラフィック制御の3つの異なるメカニズムが存在します。彼らです：
A packet classifier mechanism: This resolves the QoS class for each packet; this can determine the route as well.
パケット分類メカニズム：これは、各パケットのQoSクラスを解決します。これは、同様の経路を決定することができます。
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.
アドミッション制御メカニズム：アドミッション制御とポリシー制御：これは、2つの決定のモジュールから構成されています。要求されたQoSのための十分なリソースがあるかどうかを決定することは、アドミッション制御の関数です。ユーザーは、このようなリソースを要求する権限を持っているかどうかを決定することは、ポリシー制御の関数です。この流れの中に運ばパラメータは、これら二つのモジュールのエラーRSVPを使用して要求のどちらかを失敗した場合。
A packet scheduler mechanism: At each outbound interface, the scheduler attains the guaranteed QoS for that flow.
パケットスケジューラメカニズム：各発信インターフェイスでは、スケジューラはその流れのための保証されたQoSを達成。
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.
もともと書かれたとして、RSVPは、そのデータプレーンの挙動[RFC2208]に制限をスケーリングしていたという懸念がありました。これがケースであることが証明されていないか、時間に大幅に修正されましたか。テレフォニーサービスは、一般的に数十のコールの数千人のに何千人ものオーダーで、一般的に分あたりの通話や問題のラインの容量に匹敵するピークコールレベルの何千ものオーダーのピークコールアドミッション・レートを、必要としています。現在のRSVPの実装は、毎秒のコール数百人の割合で電話を認め、メモリ構成が許す限り、進行中のように多くのコールを維持します。
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は、帯域幅を認める、個々のマイクロフローのために知らせるために使用されます。しかし、差別化サービスは、データプレーンの振る舞いのために使用されています。入院とポリシングはどこに行ってもよいが、唯一の混雑によって脅かさ（トラフィックを送信するエンドシステムがDTEである場合、残りのネットワークのためのDCEを構成する）ファーストホップルータおよびインターフェイスを有するルータで実行することが必要。図1では、これらは通常、ネットワークの境界を越えてリンクになります。
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 enabled, there must be an active configuration to ensure that all relevant backbone nodes read the RSVP fields; [RFC2746] describes this.
バックボーンネットワーク、帯域幅、通常あふれているネットワークでは、RSVPとその影響を受けたデータフローは、種々の方法で実施することができます。骨格がその縁部（MPLSネットワークの真の、暗号化から復号にトラフィックを運ぶネットワーク、また、VPNの）間のトンネルの迷路である場合、適用可能な技術は、[RFC2207]、[RFC2746]及び[RFC2983]を含みます。 IPトンネルは、簡略化し、ペイロードとして別のIPパケット内部エンベロープIPパケットに入れています。 IPv6がV4パケット内部全体V6パケットをカプセル化し、IPv4ネットワーク上を搬送されるときに、このタスクを達成するための有効な手段です。トンネルのこのタイプでは、IPv6パケットをIPv4の一方エンベロープ内部ルータのいずれかによって読み取られません。内部パケットは、RSVPが有効になっている場合は、関連するすべてのバックボーンノードが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トンネルの仕組みに似ています。一方、トンネルのこの形態でRSVPが動作不能になるだろう外部IPパケットヘッダ内の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 LSPを、VPNエッジルータ間のIPsecセキュリティアソシエーション、IP / IPトンネル、および汎用ルーティングカプセル化（GRE）は、この一般的なカテゴリにすべての秋トンネル。区別因子は、集約ネットワークへの集約を注入システムは、非集約側の経路とRESV統計情報を合計し、集約側のトンネルの予約を生成することです。トンネルの帯域幅を拡張することができない場合、RSVPは、代わりに、既存の予約を残し、次に拒否するためにどのセッションを決定するためにそのようなIEPSようにポリシーを適用することができるアグリゲータにエラーを返します。データプレーンでは、トラフィックのDSCPは、PHBの効果を維持するために、外側のヘッダに内側からコピーされなければなりません。
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によって識別可能であるように、実際に、それはありません。このように、それが宣伝されていない場合でも、そのような情報は、測定可能です。
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オブジェクトは、クラス内の帯域幅の入場と様々な速度またはトークンバケットの建築アップの両方を可能にします。
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手続きを適用し、さらに予約を修飾するために、ローカルまたはリモートポリシーエンジンを使用するなど様々な方法で拡張することができます。
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.
例えばG.711のような一定のビットレートコーデックを活性検出することなく、MPEG-1または音声を使用し、使用して、放送映像などの特定の用途のために、この基本方針は、AAAから離れて十分です。例えばMPEG-4または音声アクティビティ検出との音声コーデックとして可変レートコーデック、のために、しかし、これはあまりにも保守的とみなされてもよいです。このような場合には、統計的な政策には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と800 KBPS間のデータレートを使用することが知られており（例えば、15分の境界にコマーシャルを有するように）セッションが同期であろうことは明白な理由が存在していない場合、例えば、一方は、平均セッションを推定想像できます400 KBPSを消費し、実際に半分の量を消費するとして800 KBPSの入場を処理します。
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 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.
一つは、また、おそらく、より信頼性の高い手法である負荷を平均化するために近似することができます。この場合、1は指数関数的加重移動平均を使用して、それを近似し、入院データのキューを介して実際のトラフィックを測定変数を保持します。新たな予約要求が到着したときに要求された速度が設定上限および移動平均の現在値との差よりも小さい場合に、予約が受け入れられ、移動平均を直ちに確保する予約の量だけ増加させます帯域幅は、同時に複数のユーザにアウトを約束されていないこと。時間では、移動平均は、そうでない場合は拒否されてしまう予約する別のセッションへの機会を提供することが、真の負荷の推定値、このガードポジションから減衰します。
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は、以下の、サービス統合型モデルでの政策決定と執行のための基本的な概念モデルです。このモデルは、予約がユーザーを識別、特定のトラフィックやセキュリティ要件、およびネットワークまたはそのユーザーが関与する災害や緊急イベントへの反応を含め、さまざまな理由で変更される可能性があります条件に基づいて流れを監視する機能と制御を提供するために作成されました。
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
|______________|
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
ネットワーク・ノードは、ネットワーク内のルータを表します。ポリシーサーバは、ネットワークオペレータによって入場とポリシー制御点を表します。ポリシーアクションが行われる場所ポリシー実行ポイント（PEP）（ルータ）があります。政策決定は、ローカルポリシー決定ポイント（LPDP）の形式のいずれかでローカルに存在することができる、またはネットワーク上の別のサーバにポリシーと呼ばれます
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]は、具体的制御下のコールを先取り方針の使用に言えば、プリエンプションの概念[RFC3181]とアイデンティティ[RFC3182]などのポリシー制御を含めるためのシンプルな予約のRSVPの概念を拡張しますいずれかのローカルまたはリモートポリシーマネージャ。ポリシーマネージャは認めデータフローに優先レベルを割り当てます。それは、システムの利用可能な容量を超えるデータフローを認める場合、期待は、RSVP-影響RSVPプロセスは、それが認めた最も低い優先順位のセッションの間でセッションを切断することです。その起因RESVエラーは、データフローの受信側に移動し、アプリケーション（SIPまたはH.323）に報告されます。この出願は、「帯域幅のプリエンプション」の理由コードと、そのコールを切断する責任があります。
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の手続きも必要になります。
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と同じままにしてください。必ずしも適用されないユーザーに送信された発表のリストを更新するために、生成されたいくつかの新しい試みがあるはずです。ユーザーへのすべての兆候は、当然のことながら、正の信号ではなく、測定結果の変化に基づいて、信頼性の低い措置に依存します。
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.
この文書は、完全に既存の仕様で構成されるネットワーク機能の概要を説明します。これは、さまざまな認証や承認手続きの失敗は、通信の基本的な故障を引き起こす可能性があることを意味において、重大なセキュリティ上の問題があります。しかし、問題は、さまざまなコンポーネント・プロトコルの内部にあり、その様々なセキュリティ手順によって覆われています。
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.
この文書は、多くの人々の知識と入力して、名前で挙げるにはあまりにも数多く開発されました。しかし、思考の主要な貢献者は、フランソワ・ルFaucheur、Haluk Keskiner、ロハンマーイ、スコット・ブラッドナー、スコット・モリソン、サブハDhesikan、そしてトニー・デ・シモーネが含まれます。ピートBabendreier、ケン・カールバーグ、そしてマイク・ピアースは便利なレビューを提供します。
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[RFC3689]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービスの一般的な要件（ETS）"、RFC 3689、2004年2月。
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004.
[RFC3690]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービスのためのIPテレフォニーの要件（ETS）"、RFC 3690、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、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、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機能仕様"、RFC 2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]バーガー、L.とT.オマリー、 "IPSECデータフローのためのRSVP拡張機能"、RFC 2207、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.チャン、「リソース予約プロトコル（ RSVP）バージョン1適用性に関する声明展開に関するいくつかのガイドライン」、RFC 2208、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つのメッセージ処理ルール"、RFC 2209、1997年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[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.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、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のネットワーク経由の統合サービス操作のための枠組み"、RFC 2998、2000年11月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]ブレーデン、R.とL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ価値"、RFC 3097、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.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]ヘルツォーク、S.、RFC 3181 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のID表現"、RFC 3182、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.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
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分野）の定義"、RFC 2474、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.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[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.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[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] Charny、A.、ベネット、J.、ベンソン、K.、Boudec、J.、チウ、A.、コートニー、W.、Davari、S.、Firoiu、V.、Kalmanek、C.、およびK 。ラマクリシュナン、「EFのPHBの新しい定義のための補足情報（優先転送ホップ単位動作）」、RFC 3247、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. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.
[RFC4411]ポーク、J.、 "プリエンプションのイベントのためのセッション開始プロトコル（SIP）Reasonヘッダの拡張"、RFC 4411、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.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年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]米国規格協会、 "通信 - 総合デジタル通信網（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]米国規格協会、 "値の変更原因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/Site/hersteller/ viola_networks / Dokumente / Compr_Report_Sample.pdf>。
[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]ノーテルネットワークス、 "パケット損失やパケット損失隠蔽"、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.
[ITU.ETS.E106]国際電気通信連合、 "災害救援活動（IEPS）のための国際緊急優先スキーム"、ITU-T勧告E.106、2003年10月。
[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.ギャラガー、「サービス統合型ネットワークにおけるフロー制御への汎用プロセッサ共有アプローチ：複数のノードのケース」、インフォコム1993：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.ギャラガー、「サービス統合型ネットワークにおけるフロー制御への汎用プロセッサ共有アプローチ：単一ノードケース」、インフォコム1992：915から924、1992。
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シグナリングは、パケットがソースとの間のネットワークを介してトラバース経路を決定するBGPおよびOSPFなどのルーティングプロトコルによって結合されているトランスポート（TLS / TCP / IPを含む）、UDP / IPまたはTCP / IPに乗って、アプリケーション層で発生しますそして、宛先デバイス。 RSVPは、RSVPは、エンドポイント間のネットワークを介して経路を決定するために、IPルーティングプロトコルのなすがままにされることを意味し、同様にIPの上に乗っています。 RSVPはルーティングプロトコルではありません。この付録では、多くの層は、SIPに関与しているかになったブロックを構築するのエスカレーションがあるでしょう。 QoSの前提条件は、（音声、ビデオ、またはその両方のための）セッションのセットアップを認め、正常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）との間の多くのルータです。関心の4つのUAはありますが、これらは、ユーザーアリス、ボブ、キャロル、とDaveのためのものです。 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.
議論されたようにRSVPの埋蔵量は、一方向のみ（RESVメッセージの方向）における帯域幅、パケットの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）は、その中で確立されたパラメータに従わなければならないこと
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がUASに複数を提供する場合に使用するコーデックたです。 INVITEメッセージは、後で付録で詳細に説明されている場合、この例外が表示されます。 INVITEメッセージのSDP内の唯一のコーデックがあった場合、予約のパラメータは、UACは、（リソース優先ヘッダ名前空間と優先順位値を含むように特異的に）要求されたものに従います。
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.
ここで4つのUAとそれぞれの間に噛合ルーティングインフラストラクチャとの最初の数字です。この説明を簡単にするために、この付録では、ボブ（一方向）へアリスからとキャロルのDave（一方向）に予約を説明します。対話型音声サービスは、各UAで終わる2つの一方向の予約が必要になります。これは確かにそうでないとき、双方向予約の外観を与えます。
Alice -----R1----R2----R3----R4------ Bob
| \ / \ / \ / |
| \/ \/ \/ |
| /\ /\ /\ |
| / \ / \ / \ |
Carol -----R5----R6----R7----R8------ Dave
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:
アリスからボブへPATHメッセージ（RESVメッセージのルートを確立する）がルータを介してであろう。
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
R2でR3とR2との間、したがって共通インタフェース：ボブにアリスからの予約は、共通のルータリンクを横切ります。 R2との間のリンク上で、この例では渋滞が発生しますのはここです
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
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は、UAと関連するルータ間RSVPメッセージとの間のメッセージングを理解するために示すことができる方法を示しているが[RFC3312]は（より好適ビューのこのドキュメントの点から「QoS用SIP前提条件」と題する）に設立された結合します。
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.
次の図（[RFC3312]から図1とほぼ同じ）（図7）は、良好な品質の音声通話のためにアリスとボブの間（レイヤ7で）最小のSIPメッセージングを示します。 SIPメッセージは、それぞれの特別な資質を識別するために番号が付けられています。 SIPシグナリング中に、RSVPが開始されます。それメッセージングはまた、以下に説明されます。
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) |
|<==========================================>|
| |
Figure 7: SIP Reservation Establishment Using Preconditions
図7：前提条件を使用してSIP予約の確立
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メソッド要求メッセージ[M1]とSIPに反映されます。以下は、SIPの人々が（それが正しく機能するために必須であるすべてのヘッダを持っているという意味）整形式のSIPメッセージを呼んでいます。我々は、このメッセージ交換のアドレッシングのために米海兵隊（USMC）に選択されます。
[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 - RP =ルーチン、QOS = E2Eと必須、アリスからボブへINVITE]をSIP INVITE：SIP / 2.0経由bob@usmc.example.mil：SIP / 2.0 / TCPのpc33.usmc.example.mil:5060、ブランチ= z9hG4bK74bf9マックス・フォワード：アリス<SIP：alice@usmc.example.mil>から70;タグ= 9fxced76slへ：ボブ<SIP：bob@usmc.example.mil>コールID：3848276298220188511@pc33.usmc.example .MILのCSeq：31862は必要INVITE：100rel、前提条件、リソースの優先度の資源優先度：dsn.routine連絡先：<SIP：alice@usmc.example.mil>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 =アリス2890844526 2890844526 IN IP4 usmc.example.milのC = IP4 10.1.3.33 T = 0、M =オーディオ49172 RTP / AVP 0 4 8 A = rtpmap：0 PCMU / 8000 = 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から、アリスは、セッションにボブを招いています。 （ライン「= 0 V」上記）の行の上半分は、SIPヘッダおよびヘッダの値であり、下半分には、セッション記述プロトコル（SDP）の線です。 Viaヘッダ：SIPヘッダーは（最初の行の後、ステータスラインと呼ばれる）1つの例外を除いて、任意の特定の順序で義務付けられていません。これは、このメッセージが宛先UAに向かって通過する各SIP要素によって追加された新たなViaヘッダーラインを有する（SIPプロキシを介して）SIPホップルートパスです。これは、RSVP PATHメッセージ（メッセージの発信元に戻す逆の経路を構築する）と機能的に類似しています。メッセージのパスの任意の時点で、SIP要素は、メッセージの発信元へのパスを知っています。前提条件のために、プロキシのみ（VIAとMax-転送し、ヘッダを除いて）同じに見える複数のメッセージを作り、それが行われていたものを複製するためにここにスペースの価値ではないので、この例では何のSIPプロキシは存在しませんすでにSIPのRFCインチ
SIP headers that are used for Preconditions are as follows:
次のように前提条件のために使用される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.
このINVITE（これらは特別な知る）、前提条件が試行されている「前提条件」任務、及び「資源優先」任務を支援する要求条件に「100rel」義務信頼できる暫定的な応答メッセージ：O 3個のオプションタグを含むヘッダを必要とリソースプライオリティヘッダーのため。これらのオプションタグのそれぞれは、明示的にサポートされていなかった、まさに呼び出す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に関する継続的な努力のためのSDPの詳細、またはMMUSIC WGのために[RFC2327]を参照）特別な特性を有します。 SDP線はエンドシステムによって解析するための特定の順序です。ダイアログ生成（または呼び出し発生）SDPメッセージ本体は、すべての「M =」行（またはメディア記述行）を有していなければなりません。 「M =」行以下ゼロ以上の「a =」行がある（又は行属性）。アリスがサポートする3つの異なるコーデックのいずれかを使用して、音声セッションのためにアリスのINVITEコール（ビデオも同定されている場合、これはある）（0 = G.711、G.723 4 =、及び18 = G.における「M =」行ボブはこのセッションの中から選択し得る729）。ボブは、第1のA = rtpmap線は、これら3はコーデックの種類（PCMU）に特異的である3のいずれかを選択することができます。次の二つの「a =」行は、このコールに使用されるRSVP唯一の識別子です。第二の「a =」行：
a=curr:qos e2e none
= 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から必要とされていることを意味します。このように、いずれかの方向に利用可能な容量保証の欠如は、コールの試みを失敗します。
"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
= DES：必須E2EをQOS 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一方向の予約が必要です。 UAは両方向の両方の予約のための焦点となります。
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 "セッションプログレス"] SIP / 2.0 183セッションプログレス経由：SIP / 2.0 / TCPのpc33.usmc.example.mil:5060;ブランチ= z9hG4bK74bf9は、受信=から10.1.3.33：アリス<SIP：アリス@ USMC .example.mil>;タグ= 9fxced76slへ：ボブ<SIP：bob@usmc.example.mil>; = 8321234356のCall-IDタグ：のCSeq 3848276298220188511@pc33.usmc.example.mil：31862はRSEQをINVITE：813520リソース優先：dsn.routine連絡先：<SIP：bob@usmc.example.mil>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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
V = 0 0 = IP4のusmc.example.mil Cにボブ2890844527 2890844527 = IP4 IN 10.100.50.51 T = 0、M =オーディオ3456 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = CURR：のQoS E2EなしA = DES：のQoSのE2Eのrecv：必須のE2Eのsendrecv A = CONFをQOS
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ヘッダです。値は、このコールセットアップ（必ず何も失われないようにするか、重複を無視する）に送られていますすべての信頼性の高いメッセージのためにインクリメントされます。
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).
BobのSDPには、いくつかの「A =」行の状態を示し、通話のためのコーデックを選択します。採取コーデックがm =オーディオラインである（この行の末尾に「0」G.711コーデックであることを意味します）。
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:
これは、「注1」をボブのUAは、この183メッセージ、ボブのUAに送信する（コーデックを選んだものを、それを予約する帯域幅の量を知っている）点で、図7に適用される場合であるに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メッセージを送信した直後に、アリスは、他の一方通行の予約を開始する彼女自身の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とは無関係です。しかし、予約の確立のこの時間の間、暫定応答（PRACK）[M3]は、アリスのUAで2一方向予約の確認のための要求を確認するために、アリスからボブに送信されます。このメッセージは、通常の200 OKメッセージ[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層UPDATEメッセージ[M5]で、（それは双方向のサイクルまたは予約の確立で最後だったことを知っているが）という彼のUAに知らせるためにボブのUAに送られますRSVP（またはQoS）の現在のステータスが "E2E" と "のsendrecv" です。
[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のSIP：SIP / 2.0経由bob@usmc.example.mil：SIP / 2.0 / TCPのpc33.usmc.example.mil:5060;分岐= z9hG4bK74bfaをより：アリス<一口：alice@usmc.example.mil>;タグ= 9fxced76slへ：ボブ<SIP：bob@usmc.example.mil>コール-IDを：3848276298220188511@pc33.usmc.example.milリソース優先：dsn.routine問い合わせ：<SIP：alice@usmc.example.mil>のCSeq：10197 UPDATEのContent-Type：アプリケーション/ SDPコンテンツの長さ：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
V = 0 0 =アリス2890844528 2890844528 IN IP4 usmc.example.milのC = IP4 10.1.3.33におけるT = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：= CURR 0 PCMU / 8000：のQoS E2Eを送ります= DES：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線及び= DESラインから構築することができるマッチングテーブルによって示されています。 2行が一致していれば、それ以上のシグナリングないニーズは、「QoSの」に関しては場所を取ります。 【M6は、2つのUA間のこの同期の200 OKの肯定応答です。
[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 - 同期示すボブから更新する200 OK] SIP / 2.0 200 OK SIP：経由bob@usmc.example.mil：SIP / 2.0 / TCPのpc33.usmc.example.mil:5060と、分岐= z9hG4bK74bfa者：アリス<一口：alice@usmc.example.mil>;タグ= 9fxced76slへ：ボブ<SIP：bob@usmc.example.mil>コール-IDを：3848276298220188511@pc33.usmc.example.milリソース優先：dsn.routine問い合わせ：<SIP：alice@usmc.example.mil>のCSeq：10197 UPDATEのContent-Type：アプリケーション/ SDPコンテンツの長さ：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
V = 0 0 =アリス2890844529 2890844529 IN IP4 usmc.example.milのC = IP4 10.1.3.33 T = 0 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = CURR：QoSのE2E SENDRECV A = DES：QoSの必須のE2E SENDRECV
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.
この時点で、予約が動作していると、両方のUAはそれを知っています。ボブのUAは現在、ボブアリスは彼を呼び出しているユーザーに伝える、リング。 （[M7]は、これが行われていることをアリスにSIPの指標です）。今まで何もアップがボブにユーザーが関与していません。ボブは、（アリスのUAは、最終的なACKで応答し、そこから[M10]を生成する）電話をピックアップし、RTPは現在2つのUA間の予約内で動作しています。
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は、ボブにアリスとの間の予約、また、デイブにキャロルの間の予約のための経路であろういずれかの一般的なルータインターフェイスを示します。このインタフェースは、私たちの例では渋滞が発生します。
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).
キャロルは今ボブの「日常」にアリスよりも優先順位が高い「即時」、のリソース優先レベルでデイブを呼んでいます。この継続的な例では、ルーター2のインターフェイス-7が混雑していると、それ以上RSVPトラフィックを受け入れることはできません。おそらく、与えられた負荷は、インタフェース容量です。おそらく、インターフェイス-7は、RSVPトラフィックに割り当てることができます一定の帯域幅で構成されており、それが正常終了または強制終了（プリエンプション）を介して離れていくの予約のひとつせずにその最大に達しました。
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は、異なる層であり、そしてすべてのルータが問題なくシグナリングパケットを渡している）間での予約には影響を与えません。 Daveは彼のM2を送信します。
[M2 - 183 "Session Progress"]
[M2 - 183 "セッションプログレス"]
with the SDP chart of:
のSDPチャートで：
a=curr:qos e2e none
= CURR：のQoS E2Eなし
a=des:qos mandatory e2e sendrecv
= DES：必須E2EをQOS SENDRECV
a=conf:qos e2e recv
= CONF：のQoSのE2Eのrecv
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を必要としています。 Daveは彼の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を横断します。インターフェイス-7 R2ので受信し、このRESVメッセージは、R2は、かどうかの決定を行う必要がありますような混雑状況を作成します。
o to keep the Alice-to-Bob reservation and error the new RESV from Dave, or
アリス・ツー・ボブ・予約を維持し、デイブから新しいRESVをErrorにO、または
o to error the reservation from Alice to Bob in order to make room for the Carol-to-Dave reservation.
キャロル・ツー・デイブ予約のための余地を作るために、アリスからボブに予約をErrorに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は65,535プライオリティ値を有するか、[RFC3181]あたり2×32ビット）に等しいであろう。 DaveのRESVは高い優先度である「即時」の優先順位値に相当します。したがって、R2は、アリスからボブに予約を先取りし、デイブからキャロルへ予約要求を許可します。適切なRSVPエラーがプリエンプションを示しResvErrです。このメッセージは、RESVメッセージ（ボブ）の創始者に向かって下流に移動します。これは、（意味R2の下流のすべてのルータでの予約をクリア
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は、バックアリスのUAに向かってSIPプリエンプション指示を送信します。まず、それは[RFC3261]あたりの「ダイアログステートフル」のままたかったセッションセットアップパスにあったすべてのSIPサーバに通知し、そして第二に、それは、これは意図的な終了したことをアリスのUAに通知し、再生するために：これは2つのことを達成しますプリエンプショントーン。プリエンプションこの終了のSIPにおける適切な指示は、これが（この場合、「予約されたリソースプリエンプト」）が発生した理由を示すReasonヘッダを含むBYEメソッドのメッセージです。ここでは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のSIP：SIP / 2.0を介してalice@usmc.example.mil：SIP / 2.0 / TCPのswp34.usmc.example.mil;ブランチ= z9hG4bK776asegmaへ：アリス<SIP：alice@usmc.example.mil>から：ボブ<一口：bob@usmc.example.mil>;タグ= 192820774理由：先取り;原因= 2;テキスト=予約資源不足、差し替えられたコール-ID：のCSeq 3848276298220188511@pc33.usmc.example.mil：6187 BYE連絡先：<SIP：ボブ@ usmc.example.mil>
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メッセージの受信を確認するために、ボブにOK 200を送信し、アリスにユーザーをプリエンプショントーンを再生します。
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は、それを受け取ります。ただ、アリス・ツー・ボブ・コール・セットアップと同様に、キャロルは、彼女が「SENDRECV」の方向でのQoS「E2E」を持って確認し、デイブにUPDATEメッセージを送信します。ボブは彼の現在の状態（QoSの「E2E」と「SENDRECV」）を提供します200 OKでこれを認識し、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.
要約すると、アリスは、ルーチンの優先順位レベルでRSVPとボブへの呼び出しを設定します。キャロルが高い優先度でデイブと呼ばれる場合は、その呼び出しがリソースの競合があった場合には任意の優先順位の低いコールを先取りしているでしょう。この場合は、それが発生し、アリスとボブの間のコールに影響を与えました。この輻輳点でのルータは、キャロルとDaveとの間に優先度の高い通話を発信するために、ボブにアリスの呼び出しを先取り。アリスとボブは、両方のプリエンプションイベントを知らされました。アリスとボブのUAの両方がプリエンプションの兆候を果たしました。何この付録で言及されなかったことは、この文書は（この例では）ルータR2は、適切に管理し、このドメイン内のこのようなイベントを追跡するために、ドメイン管理者にSyslogメッセージを生成することをお勧めしますということでした。これは、ドメイン管理者は、このような事象が発生した場所の知識、そしてどのような条件がそれらを原因となったが記録されていることを保証します。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムズ1121ヴィアデル・レイサンタバーバラ、カリフォルニア93117 USA
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
電話：+ 1-408-526-4257ファックス：+ 1-413-473-2403 Eメール：fred@cisco.com
James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームズ・ポークシスコシステムズ2200東ブッシュ大統領ターンパイクリチャードソン、テキサス州75082 USA
Phone: +1-817-271-3552 EMail: jmpolk@cisco.com
電話：+ 1-817-271-3552 Eメール：jmpolk@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。