[要約] 要約：RFC 4542は、インターネットプロトコルスイートにおけるリアルタイムサービスのための緊急通信サービス（ETS）の実装に関するものです。 目的：このRFCの目的は、緊急通信サービスの実装に関するガイドラインを提供し、リアルタイムサービスにおける緊急通信の信頼性と効率性を向上させることです。
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
インターネットプロトコルスイートでのリアルタイムサービス用の緊急通信サービス（ETS）の実装
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
RFCS 3689および3690緊急時電子通信サービス（ETS）の詳細な要件。これらのタイプのサービスの一部は、コールプリエンプションが必要です。その他は、コールキューイングやその他のメカニズムが必要です。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.
このドキュメントは、主に米国政府とNATOのコンテキストでETSのサポートをサポートすることについて説明します。これは、マルチレベルの優先順位と先制（MLPP）および政府の緊急通信サービス（GETS）の基準に焦点を当てているためです。ここで説明するアーキテクチャは、これらの組織を超えて適用されます。
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
[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]は、緊急電子通信サービス（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（したがってIEP）が解決することを目的としている問題とシステムのアーキテクチャについて説明しましょう。緊急時電子通信サービス[ITU.ETS.E106]は、米国で使用される2つのサービスの後継者であり、マルチレベルの優先順位と先制（MLPP）と政府の緊急通信サービス（GETS）の後継者であり、一般化されています。これらのモデルに基づくサービスは、世界中のさまざまな国でも使用されています。これは、公共の切り替え電話ネットワーク（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.
Assured Serviceは、マルチレベルの優先順位と先制として知られる既存のITU-T/NATO/DOD電話システムアーキテクチャのIP実装として設計されています[itu.mlpp.1990] [ansi.mlpp.spec] [ansi.mlpp.supppec]、またはMLPP。MLPPは、関連するNATOおよびDODコマンドの緊急時に、さまざまな種類の通信の相対的な重要性が厳密に定義され、低学年コミュニケーションを犠牲にしてより高い前提条件のコミュニケーションを可能にする優先順位付けされたコール処理サービスのアーキテクチャです。このドキュメントでは、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.
Flash Override Override：司令官が司令官、国防長官、および議長の共同長官、戦争状態の存在を宣言する際の戦闘員の司令官。戦闘員の司令官は、防衛条件1または防衛緊急事態または防空緊急事態およびその他の国家当局を宣言した場合、大統領が世界中の安全な音声会議システム会議と協力して承認する可能性があります。フラッシュオーバーライドオーバーライドは先制できません。この優先レベルは、すべての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.
Flash Override：司令官が司令官、国防長官、および戦争状態の存在を宣言する際の戦闘員の司令官である共同長官、共同長官。戦闘員の司令官は、防衛条件1または防衛緊急事態およびその他の国家当局を宣言する場合、大統領が承認する可能性があります。フラッシュオーバーライドは、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は、発信者がコールイニシエーションで上記の優先レベルの1つを割り当てる必要があるプロアクティブシステムとして構築されています。このコール全体でこの優先順位を変更することはできません。コール開始時にユーザーによってステータスの上昇が割り当てられない場合、通話は「ルーチン」であると想定されます。通話を行うエンドツーエンドの容量がある場合、いつでも電話をかけることができます。ただし、トランクグループ（回路の世界）またはインターフェイス（IPの世界）が利用のしきい値に達する場合、どの呼び出しを受け入れるか、継続することを許可するかを選択する必要があります。システムは、より重要な呼び出しを優先してより重要な呼び出しを優先して、より低い優先順位のより重要な呼び出しを優先して、より重要なコール（またはコール）を優先して、より高い前提条件の呼び出しを許可することにより、トランクまたは帯域幅を押収します。
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つの方法でMLPPとは異なります。先制を使用するのではなく、帯域幅またはキューコールを予約して、コール完了の高い確率を取得し、「ルーチン」と「優先度」の2つのレベルのサービスしかありません。
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）には、利用可能なしきい値を実装する責任がありました（たとえば、一部のトラフィックで消費されるリソースを制限するため）、発信者が許可を持っているかどうか（例えば、識別されたサブスクライバーであり、識別された識別が認められているかどうかを判断します。適切な資格情報によって）利用可能な回路を使用する。IEP、または緊急電話サービスには、通話完了の確率を改善するために使用できる追加のオプションがあります。
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、GMPLなどの回路が切り替えられたネットワーキングソリューションを使用して、明示的にルートを配置することができ、オッズが少し改善されます。
Between those networks, in places commonly called "inter-campus links", "access links", or "access networks", for various reasons including technology (e.g., satellite links) and cost, it is common to find links whose offered load can approximate or exceed the available capacity. Such events may be momentary or may occur for extended periods of time.
これらのネットワーク間で、一般的に「キャンパス間リンク」、「アクセスリンク」、または「アクセスネットワーク」と呼ばれる場所で、テクノロジー（衛星リンクなど）やコストなど、さまざまな理由で、提供された負荷が缶詰にできるリンクを見つけるのが一般的です。利用可能な容量を近似または超えてください。このようなイベントは瞬間的であるか、長期間発生する場合があります。
In addition, primarily in tactical deployments, it is common to find bandwidth constraints in the local infrastructure of networks. For example, the US Navy's network afloat connects approximately 300 ships, via satellite, to five network operation centers (NOCs), and those NOCs are in turn interconnected via the Defense Information Systems Agency (DISA) backbone. A typical ship may have between two and six radio systems aboard, often at speeds of 64 KBPS or less. In US Army networks, current radio technology likewise limits tactical communications to links below 100 KBPS.
さらに、主に戦術的な展開では、ネットワークのローカルインフラストラクチャに帯域幅の制約を見つけることが一般的です。たとえば、米海軍のネットワークは、衛星を介して約300隻の船を5つのネットワーク操作センター（NOC）に接続し、これらのNOCは、防衛情報システム機関（DISA）バックボーンを介して相互接続されています。典型的な船は、多くの場合、64 kbps以下の速度で、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.
このインフラストラクチャにおいて、軍事コミュニケーションは、音声通信システム（セッションごとに30〜80 kbps）を展開し、MPEG 2（3〜7 Mbps）とMPEG 4（80 kbpsから800 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とGallagherは、一連の論文[Parekh1] [Parekh2]を発表しました。一言で言えば、彼らはネットワーク内のトラフィックの流れの動作を予測するために、2つのことを知っている必要があることを示しました。
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の最初の要件を確保するためにしなければならないことは基本的に2つのことがあります。アプリケーションが提示している負荷の提供量を確実に認識するために、ネットワークに入る警察（提供された負荷を測定し、余分な負荷を廃棄する）トラフィックを警察する必要があります。そのポリシングの行動がアプリケーションに衰弱させる効果がある場合、目的のない損失が音声またはビデオにあるように、いくつかのポリシーに従ってセッションを賢明に認めなければなりません。そのポリシーの重要な特徴は、提供された負荷がアプリケーション専用の容量を超えないことです。
In the network, the other thing one must do is ensure that the application's needs are met in terms of loss, variation in delay, and end-to-end delay. One way to do this is to supply sufficient bandwidth so that loss and jitter are nominal. Where that cannot be accomplished, one must use queuing technology to deterministically apply bandwidth to accomplish the goal.
ネットワークでは、もう1つのことは、アプリケーションのニーズが損失、遅延の変動、およびエンドツーエンドの遅延の観点から満たされることを確認することです。これを行う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システムでは、本質的に同じサービスを期待しています。
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.
定義されたユーザーインターフェイス：コールが先制された場合、発信者とCalleeは定義された信号を介して通知され、その場合、その瞬間にその優先順位レベルで使用できる代替回路がないことがわかります。
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手順との関係に関するインターネットサークルで議論があります。これは、この手順を適切に分析する前に就寝する必要があります。問題は、インターネットの特定の部分で帯域幅の問題を解決することが可能かつ一般的であることです。たとえば、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
SIP = SIPプロキシH = SIP対応ホスト（電話、コールゲートウェイまたはPC）r = router / --- / =イーサネットまたはイーサネットスイッチ
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）スイッチやマルチプレクサなどのデータ処理サービスを制御します。それらは物理的に共同配置されていない可能性がありますが、コントロールプレーンソフトウェアとデータプレーンサービスは密接に接続されています。スイッチは、利用可能であることがわかっている帯域幅を使用して呼び出しをルーティングします。音声/ビデオオンイップネットワークでは、コールコントロールはデータプレーンから完全に離婚しています。米国の電話機器がスウェーデンの電話番号を持つことができます。アジア/太平洋地域のデータパスのみ、別の企業が提供するデータパス、および多くの場合、複数の企業/プロバイダーが提供するデータパスを使用するように、特定の呼びかけで。
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 この電話番号またはSIP URIとどのIPアドレスが相関していますか？
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の目的です。「Calleeはどの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 Communications Resource Priority Header（または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.
構文の「名前空間」部分は、コールの発信者にとって重要な領域を保証し、これは宛先（電話）デバイス（電話）にエンドツーエンドを移動します。受信電話が名前空間をサポートしていない場合、セットアップリクエストを簡単に無視できます。原産地のドメインを示すこの能力により、未知の要求者がIEPSドメインに優先的な治療を得る能力を制限するために、サービスレベル契約（SLA）を整えることができます。
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には、下降順序で5つの優先レベルのIEPがあります。
dsn.flash-override
dsn.flash-override
dsn.flash
dsn.flash
dsn.immediate
dsn.immediate
dsn.priority
dsn.priority
dsn.routine
dsn.routine
The US Defense Red Switched Network (DRSN), as another example that was IANA-registered in [RFC4412], has 6 levels of precedence. The DRSN simply adds one precedence level higher than flash-override to be used by the President and a select few others:
[RFC4412]でIANA登録されている別の例として、米国防衛レッドスイッチネットワーク（DRSN）には、6レベルの優先順位があります。DRSNは、大統領が使用するフラッシュオーバーライドよりも高い1つの優先レベルを追加し、他のいくつかの優先順位を追加するだけです。
drsn.flash-override-override
drsn.flash-override-override
Note that the namespace changed for this level. The lower 5 levels within the DRSN would also have this as their namespace for all DRSN-originated call setup requests.
このレベルの名前空間が変更されたことに注意してください。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）は、Callee（同じデータパスサービスを取得するために発信者と同じDSCPを使用する必要がある）による差別化されたサービスコードポイント（DSCP）の使用と、ポリシーベースの先制を促進することの両方を通知します。必要に応じて進行中の通話。
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]に記載されている先制ヘッダーが、すべてのSIPノードがエンドポイントまたは包摂を経験するルーターのいずれかで発生する先制イベントに同期することを保証します。SIPでは、セッションの終了の通常の表示は、[RFC3261]で指定されているように、一方のエンドシステムがBYEメソッドリクエストを送信することです。これも、プリエンプションイベントによるコールの終了を通知するための適切な手段です。これは、突然の終わりの理由をピアに通知する追加情報を基本的に実行するため、基本的に正常な終了を実行するためです。これは、関連するすべての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シグナル伝達を含む例は付録にあります）、ボブのユーザーエージェント（電話）がキャロルから招待メッセージを受け取ると、彼の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ヘッダーのフラグを使用してデータストリームを識別し、PERホップ動作または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.
リアルタイムの音声/ビデオアプリケーションは、コンテンツとコーデックに適したレートでトラフィックを生成する必要があります。これは、一定のビットレートストリームまたは指定された範囲内でレートが変動するストリームです。最初のホップルーターは、Frame RelayやATMなどの従来の仮想回路ネットワークで実行されるように、アプリケーションから発信されるポリシングトラフィックである必要があります。これら2つのチェック（一部のネットワークがデータ端子機器（DTE）と呼ぶものとデータ通信機器（DCE）と呼ばれるもの）の間で、アプリケーショントラフィックは許容できる制限内に保証する必要があります。そのため、帯域幅を意識した呼び出し入場制御を考えると、実際の損失が最小限に抑えられるはずです。損失が発生する場合には、ルーティングが最近変更され、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と統合されていません。
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].
図3は、[RFC2209]に示すように、両方のホスト（エンドシステム）とルーターの両方の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は、「トラフィックコントロール」というフレーズを使用して、データフローがサービス品質をどのように受信するかのメカニズムを説明します。交通制御には3つの異なるメカニズムがあります（ホストとルーターの両方で図2に示す）。彼らです：
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に満足のいくリソースがあるかどうかを判断することは、入場制御の機能です。ユーザーがそのようなリソースを要求する許可を持っているかどうかを判断することは、ポリシー制御の機能です。このフロー内で運ばれたパラメーターが失敗した場合、これら2つのモジュールのいずれかのいずれかがRSVPを使用して要求をエラーします。
A packet scheduler mechanism: At each outbound interface, the scheduler attains the guaranteed QoS for that flow.
パケットスケジューラメカニズム：各アウトバウンドインターフェイスで、スケジューラはそのフローの保証されたQOを達成します。
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]。これは、事実であることが証明されていないか、やがて大部分が修正されています。テレフォニーサービスには、一般に、1分あたりの数千のコールの順序でピークコール入場料が必要です。問題のラインの容量に匹敵するピークコールレベルは、一般に数千から数万のコールの順にあります。現在の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パケット内に包まれています。IPv6がIPv4ネットワーク上で輸送される場合、V4パケット内のV6パケット全体をカプセル化することは、このタスクを達成するための効果的な手段です。このタイプのトンネルでは、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トンネルの仕組みに似ています。外部のIPパケットヘッダーでRSVPインジケーターをコピーまたは搬送せずに、セキュリティ目的で暗号化されたパケット内にRSVPパケットをカプセル化すると、この形式のトンネルにいる間、RSVPが動作できなくなります。[RFC2207]は、トンネル内のフローまたはフローにQoSを提供する必要があるノードによるRSVP認識を可能にするIPSECパケットヘッダーを変更する方法について説明します。
Other networks may simply choose to aggregate the reservations across themselves as described in [RFC3175]. The problem with an individual reservation architecture is that each flow requires a non-trivial amount of message exchange, computation, and memory resources in each router between each endpoint. Aggregation of flows reduces the number of completely individual reservations into groups of individual flows that can act as one for part or all of the journey between end systems. Aggregates are not intended to be from the first router to the last router within a flow, but to cover common paths of a large number of individual flows.
他のネットワークは、[RFC3175]に記載されているように、それ自体にわたって予約を集約することを選択するだけです。個々の予約アーキテクチャの問題は、各フローには、各エンドポイント間の各ルーターの非些細な量のメッセージ交換、計算、およびメモリリソースが必要であることです。フローの集約により、完全に個別の予約の数が、エンドシステム間の一部またはすべての旅のために作用する可能性のある個々のフローのグループに減少します。集合体は、最初のルーターからフロー内の最後のルーターまでのものではなく、多数の個々のフローの一般的な経路をカバーすることを目的としています。
Examples of aggregated data flows include streams of IP data that traverse common ingress and egress points in a network and also include tunnels of various kinds. MPLS LSPs, IPsec Security Associations between VPN edge routers, IP/IP tunnels, and Generic Routing Encapsulation (GRE) tunnels all fall into this general category. The distinguishing factor is that the system injecting an aggregate into the aggregated network sums the PATH and RESV statistical information on the un-aggregated side and produces a reservation for the tunnel on the aggregated side. If the bandwidth for the tunnel cannot be expanded, RSVP leaves the existing reservation in place and returns an error to the aggregator, which can then apply a policy such as IEPS to determine which session to refuse. In the data plane, the DSCP for the traffic must be copied from the inner to the outer header, to preserve the PHB's effect.
集約されたデータフローの例には、ネットワーク内の一般的なイングレスポイントと出口ポイントを横断し、さまざまな種類のトンネルを含むIPデータのストリームが含まれます。MPLS LSPS、VPNエッジルーター、IP/IPトンネル、および一般的なルーティングカプセル化（GRE）トンネル間のIPSECセキュリティアソシエーションはすべて、この一般カテゴリに分類されます。際立った要因は、集約されたネットワークに凝集体を注入するシステムが、凝集していない側のパスとRESVの統計情報を合計し、集約された側のトンネルの予約を生成することです。トンネルの帯域幅を拡張できない場合、RSVPは既存の予約を配置し、アグリゲーターにエラーを返し、IEPなどのポリシーを適用して拒否するセッションを決定できます。データプレーンでは、PHBの効果を維持するために、トラフィックのDSCPを内側から外側ヘッダーにコピーする必要があります。
One concern with this approach is that this leaks information into the aggregated zone concerning the number of active calls or the bandwidth they consume. In fact, it does not, as the data itself is identifiable by aggregator address, deaggregator address, and DSCP. As such, even if it is not advertised, such information is measurable.
このアプローチに関する懸念の1つは、このアプローチが、アクティブコールの数またはそれらが消費する帯域幅に関する集約ゾーンに情報をリークすることです。実際、データ自体はアグリゲーターアドレス、Deaggregatorアドレス、および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.
パスメッセージでは、[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.
MPEG-1を使用したブロードキャストビデオやアクティビティ検出のない音声やG.711などの一定のビットレートコーデックなどの特定のアプリケーションの場合、この基本ポリシーは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.
また、平均負荷に近似することもできますが、これはおそらくより信頼性の高い手順です。この場合、認められたデータのキューを介して実際のトラフィックを測定する変数を維持し、指数関数的に重み付けされた移動平均を使用して近似します。新しい予約要求が届くと、要求されたレートが構成された上限と移動平均の現在の値の差よりも少ない場合、予約は受け入れられ、移動平均はすぐに予約額だけ増加し、確実に増加します。帯域幅が同時に複数のユーザーに約束されていないこと。やがて、移動平均はこのガード位置から真の負荷の推定値に減少します。
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.
これらのような統計的予約スキームは、その構成の正確性と使用中のコーデックの適切性に圧倒的に依存しています。しかし、彼らはそうでなければ見逃される可能性のある統計的多重化ゲインを利用する機会を提供します。
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 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.
ネットワークノードは、ネットワーク内のルーターを表します。ポリシーサーバーは、ネットワークオペレーターによる入学とポリシー管理のポイントを表します。ポリシー執行ポイント（PEP）（ルーター）は、ポリシーアクションが実行される場所です。ポリシーの決定は、ローカルポリシーの決定ポイント（LPDP）の形式でローカルに存在するか、ポリシー決定ポイントと呼ばれるネットワーク上の別のサーバーに存在する可能性があります。ルールの命令セットが簡単になればなるほど、このセットがアクセスの理由でLPDPに存在する可能性が高くなります。ルールセットが複雑になるほど、リモートサーバーでアクティブになる可能性が高くなります。PDPは、他のプロトコル（LDAP、SNMPなど）を使用して、ネットワークコンポーネントのルールセットを作成する際に使用される情報（例：ユーザー認証と優先レベルの使用の許可）を要求します。また、このリモートPDPは、非反応性ポリシーがLPDPに分配される場合にも考慮する必要があります。
Taking the above model as a framework, [RFC2750] extends RSVP's concept of a simple reservation to include policy controls, including the concepts of Preemption [RFC3181] and Identity [RFC3182], specifically speaking to the usage of policies that preempt calls under the control of either a local or remote policy manager. The policy manager assigns a precedence level to the admitted data flow. If it admits a data flow that exceeds the available capacity of a system, the expectation is that the RSVP-affected RSVP process will tear down a session among the lowest precedence sessions it has admitted. The RESV Error resulting from that will go to the receiver of the data flow and be reported to the application (SIP or H.323). That application is responsible for disconnecting its call, with a reason code of "bandwidth preemption".
上記のモデルをフレームワークとして取得する[RFC2750]は、RSVPの単純な予約という概念を拡張し、先制概念[RFC3181]やアイデンティティ[RFC3182]を含む政策制御を含むように拡張され、特に制御下の呼び出しの下で呼び出しを予測するポリシーの使用法を特に言えば、ローカルまたはリモートのポリシーマネージャーのいずれか。ポリシーマネージャーは、認められたデータフローに優先レベルを割り当てます。システムの利用可能な容量を超えるデータフローを認めた場合、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.
このドキュメントは、多くの人々の知識と入力で開発されましたが、名前で言及するには多すぎます。しかし、思考の重要な貢献者には、フランソワ・ル・ファウチュール、ハルク・ケスキナー、ロハン・マヒー、スコット・ブラッドナー、スコット・モリソン、スバ・ディカン、トニー・デ・シモーネが含まれます。ピート・バベンドライアー、ケン・カールバーグ、マイク・ピアスは有用なレビューを提供しました。
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[RFC3689] Carlberg、K。およびR. Atkinson、「緊急通信サービス（ETS）の一般的な要件」、RFC 3689、2004年2月。
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004.
[RFC3690] Carlberg、K。およびR. Atkinson、「緊急通信サービス（ETS）のIPテレフォニー要件」、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] Braden、B.、Clark、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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207] Berger、L。およびT. O'Malley、「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] Mankin、A.、Baker、F.、Braden、B.、Bradner、S.、O'Dell、M.、Romanow、A.、Weinrib、A.、およびL. Zhang、「リソース予約プロトコル（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] Braden、B。およびL. Zhang、「リソース予約プロトコル（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. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750] Herzog、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. Guerin、「政策ベースの入場管理の枠組み」、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.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J。、およびEFelstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、RFC 2998、2000年11月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097] Braden、R。およびL. Zhang、「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] Baker、F.、Iturralde、C.、Le Faucheur、F.、およびB. Davie、「IPv4およびIPv6予約のRSVPの集約」、RFC 3175、2001年9月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181] Herzog、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.、Ford、P.、Moore、T.、Herzog、S。、およびR. Hess、「RSVPのアイデンティティ表現」、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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
Differentiated Services Architecture References
差別化されたサービスアーキテクチャリファレンス
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、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。、チャーニー、A。、ベネット、J。、ベンソン、K。、ル・ブーデック、J。、コートニー、W。、ダバリ、S。、フィロウ、V。、およびD.スティリアディス、 "迅速な転送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.、Bennet、J.、Benson、K.、Boudec、J.、Chiu、A.、Courtney、W.、Davari、S.、Firoiu、V.、Kalmanek、C。、およびKRamakrishnan、「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] Handley、M。and 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.
[RFC4411] Polk、J。、「セッション開始プロトコル（SIP）前提条件ヘッダーの拡張」、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. Polk、「セッション開始プロトコル（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] American National Standards Institute、「Telecommunications -Integrated Services Digital Network（ISDN）-Multi -Level Predence and Preemption（MLPP）サービス機能」、ANSI T1.619-1992（R1999）、1992。
[ANSI.MLPP.Supp] American National Standards Institute, "MLPP Service Domain Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990.
[ansi.mlpp.supp] American National Standards Institute、「MLPP Service Domainは値の変更を引き起こします」、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] Viola Networks、「Netally VoIP Evaluator」、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] Nortel Networks、「パケット損失とパケット損失の隠蔽」、2000、<http://www.nortelnetworks.com/ Products/01/Subness/es/collateral/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. Gallager、「統合サービスネットワークにおけるフロー制御への一般化プロセッサ共有アプローチ：複数ノードケース」、Infocom 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. Gallager、「統合サービスネットワークにおけるフロー制御への一般化プロセッサ共有アプローチ：単一ノードケース」、Infocom 1992：915-924、1992。
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シグナル伝達は、アプリケーションレイヤーで発生し、UDP/IPまたはTCP/IP（TLS/TCP/IP/IPを含む）に乗って、BGPやOSPFなどのルーティングプロトコルに拘束され、パケットがソース間のネットワークを通過するルートを決定するルーティングプロトコルに拘束されます。および宛先デバイス。RSVPはIPの上にも乗っています。つまり、RSVPはIPルーティングプロトコルに翻弄されて、エンドポイント間のネットワークを通るパスを決定します。RSVPはルーティングプロトコルではありません。この付録では、SIPに多くのレイヤーがどのように関与しているかについて、ビルディングブロックのエスカレーションがあります。QoSの前提条件では、セッションのセットアップ（音声、ビデオ、またはその両方）を正常に認める前に、エンドポイント間の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があります。これらは、ユーザーのアリス、ボブ、キャロル、デイブ向けです。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 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).
RESVメッセージは、パスメッセージによって実行される逆パスでルーターを通過します。パスメッセージは、ネットワーク部分を介して宛先エンドポイントに撮影されたルートの記録を確立しますが、リソースを予約しません（帯域幅）。RSVメッセージは、帯域幅リソースのRSVPフロー要求の元のリクエスト担当者に戻ります。これは、RESVメッセージを開始するエンドポイントが予約のパラメーターを制御することを意味します。このドキュメントは、Bodyテキストで、SIPイニシエーター（UAC）が招待メッセージでセッションのパラメーターを確立し、招待者（UAS）がその招待メッセージで確立されたパラメーターに従う必要があることを指定します。これの1つの例外は、UACがUASに複数のものを提供した場合に使用するコーデックです。この例外は、招待メッセージの後半で詳細に説明されている場合に表示されます。InviteメッセージのSDPにコーデックが1つしかなかった場合、予約のパラメーターは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つのUASとそれぞれの間にメッシュ化されたルーティングされたインフラストラクチャを備えた最初の数字です。この説明を簡単にするために、この付録では、アリスからボブ（ワン方向）とキャロルからデイブ（ワン方向）からの予約のみについて説明します。インタラクティブな音声サービスには、各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:
アリスからボブへのパスメッセージ（RESVメッセージのルートの確立）は、ルーターを介して行われます。
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
The RESV message (and therefore the reservation of resources) from Bob to Alice will be through routers:
ボブからアリスへのRESVメッセージ（したがって、リソースの予約）はルーターを介して行われます。
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
The PATH message from Carol to Dave (establishing the route for the RESV message) will be through routers:
キャロルからデイブへのパスメッセージ（RESVメッセージのルートの確立）は、ルーターを介して行われます。
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
The RESV message (and therefore the reservation of resources) from Dave to Carol will be through routers:
デイブからキャロルへのRESVメッセージ（したがって、リソースの留保）はルーターを介して行われます。
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
The reservations from Alice to Bob traverse a common router link: between R3 and R2 and thus a common interface at R2. Here is where there will be congestion in this example, on the link between R2 and R3. 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とR2の間で共通のルーターリンクを横断し、したがってR2の共通インターフェースです。この例では、R2とR3の間のリンクに混雑が発生する場所があります。データのフロー（この場合、音声メディアパケット）がパスメッセージの方向を移動し、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は、[RFC3312]で確立されたバインディング（このドキュメントの観点からの「QOSのSIP前処理」と題されたタイトル）で確立されたバインディングを理解するために、UASとRSVPメッセージ間のメッセージングがどのように表示されるかを示しています。
We will assume all devices have powered up and received whatever registration or remote policy downloads were necessary for proper operation. The routing protocol of choice has performed its routing table update throughout this part of the network. Now we are left to focus only on end-to-end communications and how that affects the infrastructure between endpoints.
適切な操作に必要な登録またはリモートポリシーのダウンロードが何であれ、すべてのデバイスが電源を入れて受け取ったと仮定します。選択したルーティングプロトコルは、ネットワークのこの部分全体でルーティングテーブル更新を実行しました。これで、エンドツーエンドの通信と、エンドポイント間のインフラストラクチャにどのように影響するかにのみ焦点を当てる必要があります。
The next diagram (Figure 7) (nearly identical to Figure 1 from [RFC3312]) shows the minimum SIP messaging (at layer 7) between Alice and Bob for a good-quality voice call. The SIP messages are numbered to identify special qualities of each. During the SIP signaling, RSVP will be initiated. That messaging will also be discussed below.
次の図（[RFC3312]の図1とほぼ同じ）は、良質の音声コールのためのアリスとボブの間の最小SIPメッセージング（レイヤー7）を示しています。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ボブのアドレスと優先順位レベルに入れ、（事実上）送信ボタンにヒットします。これは、招待方法要求メッセージ[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
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
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.
上記の招待から、アリスはボブをセッションに招待しています。線の上半分（線「V = 0」の上）はSIPヘッダーとヘッダー値であり、下半分はセッション説明プロトコル（SDP）行です。SIPヘッダー（最初の行の後、ステータスラインと呼ばれます）は、特定の順序で義務付けられていませんが、1つの例外があります。これは、各SIP要素によって追加されたヘッダーラインを備えた新しい（SIPプロキシ）ルートパスを（SIPプロキシ）ルートパスで、このメッセージが宛先UAに向かって横断します。これは、関数がRSVPパスメッセージ（メッセージのオリジネーターに戻る逆パスを構築する）に似ています。メッセージのパスの任意の時点で、SIP要素はメッセージの発信者へのパスを知っています。この例には、Preconditionsの場合、プロキシは（ViaとMax-Forwardsのヘッダーを除く）より多くのメッセージのみを作成するだけであり、行われたことを複製することはここでのスペースに値しないため、SIPプロキシはありません。SIP RFCS既に。
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.
o 3つのオプションタグを含むヘッダーが必要です。「100REL」は、この招待状で要求する条件（特別なことを知っている）、「前提条件」が前提条件が試みられることを義務付け、「リソース優先度」がサポートを義務付けていることを義務付けます。リソース優先ヘッダー。これらの各オプションタグは、呼び出された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.
この招待メッセージが受け入れられるように受信された場合、これにより、ボブのUAからの183の「セッションの進行」メッセージが発生します。
o Resource-Priority header, which denotes the domain namespace and precedence level of the call on an end-to-end basis.
o リソース優先ヘッダー。これは、ドメインの名前空間とコールの優先順位レベルをエンドツーエンドベースで示します。
This completes SIP's functions in session initiation. Preconditions are requested, required, and signaled for in the SDP portion of the message. SDP is carried in what's called a SIP message body (much like the text in an email message is carried). SDP has special properties (see [RFC2327] for more on SDP, or the MMUSIC WG for ongoing efforts regarding SDP). SDP lines are in a specific order for parsing by end systems. Dialog-generating (or call-generating) SDP message bodies all must have an "m=" line (or media description line). Following the "m=" line are zero or more "a=" lines (or Attribute lines). The "m=" line in Alice's INVITE calls for a voice session (this is where video is identified also) using one of 3 different codecs that Alice supports (0 = G.711, 4 = G.723, and 18 = G.729) that Bob gets to choose from for this session. Bob can choose any of the 3. The first a=rtpmap line is specific to the type of codec these 3 are (PCMU). The next two "a=" lines are the only identifiers that RSVP is to be used for this call. The second "a=" line:
これにより、セッション開始時にSIPの機能が完了します。メッセージのSDP部分では、前提条件が要求され、必要であり、信号が必要です。SDPは、SIPメッセージ本文と呼ばれるものに携帯されています（電子メールメッセージのテキストが掲載されているように）。SDPには特別な特性があります（SDPの詳細については[RFC2327]、またはSDPに関する継続的な努力についてはMMUSIC WGを参照）。SDPラインは、エンドシステムによる解析のために特定の順序であります。ダイアログ生成（または呼び出しの）SDPメッセージ本文には、すべて「m =」行（またはメディアの説明行）が必要です。「m =」行はゼロ以上の「a =」行（または属性行）に続きます。アリスの招待状の「m =」行は、アリスがサポートする3つの異なるコーデックのいずれかを使用して、音声セッション（ビデオも識別されます）を求めています（0 = g.711、4 = g.723、および18 = g。729）このセッションのためにボブが選択できるようになりました。ボブは3のいずれかを選択できます。最初のa = rtpmap行は、これら3が（PCMU）のコーデックのタイプに固有です。次の2つの「a =」行は、RSVPがこの呼び出しに使用する唯一の識別子です。2番目の「a =」行：
a=curr:qos e2e none
a = curr：qos e2eなし
identifies the "current" status of qos at Alice's UA. Note: everything in SDP is with respect to the sender of the SDP message body (Alice will never tell Bob how his SDP is; she will only tell Bob about her SDP).
アリスのUAでのQoSの「現在の」ステータスを識別します。注：SDPのすべては、SDPメッセージボディの送信者に関するものです（アリスはボブに自分のSDPがどのようになるかを決して伝えません。
"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 =」行（a = des）は、qosの「望ましい」レベルを識別します。
a=des:qos mandatory e2e sendrecv
a = des：qos必須e2e sendrecv
"mandatory" means this request for qos MUST be successful, or the call fails.
「必須」とは、QoSのこの要求が成功する必要があるか、コールが失敗する必要があることを意味します。
"e2e" means RSVP is required from Alice's UA to Bob's UA.
「E2E」は、AliceのUAからBobのUAにRSVPが必要であることを意味します。
"sendrecv" means the reservation is in both directions.
「sendrecv」とは、予約が両方向にあることを意味します。
As discussed, RSVP does not reserve bandwidth in both directions, and it is up to the endpoints to have 2 one-way reservations if that particular application (here, voice) requires it. Voice between Alice and Bob requires 2 one-way reservations. The UAs will be the focal points for both reservations in both directions.
説明したように、RSVPは両方向の帯域幅を予約せず、その特定のアプリケーション（ここ、音声）がそれを必要とする場合、2つの一方向予約を持つのはエンドポイント次第です。アリスとボブの間の音声には、2つの片道予約が必要です。UASは、両方向の両方の予約の焦点となります。
Message 2 is the 183 "Session Progress" message sent by Bob to Alice, which indicates to Alice that Bob understands that preconditions are required for this call.
メッセージ2は、ボブからアリスに送信された183の「セッションの進行状況」メッセージであり、これはアリスに、ボブがこの呼び出しに必要な前提条件が必要であることを理解していることを示しています。
[M2 - 183 "Session Progress"]
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
RSeq: 813520
Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 210
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
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).
ボブのSDPは、いくつかの「a =」行のステータスを示し、コールのコーデックを選択します。選択したコーデックはM =オーディオラインにあります（この行の最後の「0」は、G.711がコーデックになることを意味します）。
The a=curr line gives Alice Bob's status with regard to RSVP (currently "none").
A = Curr Lineは、RSVP（現在は「なし」）に関してAlice Bobのステータスを示しています。
The a=des line also states the desire for mandatory qos e2e in both directions.
A = des Lineは、両方向に必須の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:
これは、「Note-1」が図7に適用される場所です。Bob'sUAがこの183メッセージを送信するポイントで、Bob's UA（コーデックを選んだものであるため、予約する帯域幅の量を知っています）がRSVPパスメッセージを送信します。アリスのUA。このパスメッセージは、以前に図5で説明したルートを取得します。
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
This is the path of the PATH message, and the reverse will be the path of the reservation setup RESV message, or:
これがパスメッセージのパスであり、逆は予約セットアップRESVメッセージのパスになります。
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
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メッセージをボブに送信した直後、アリスは彼女自身のパスメッセージを送信して、他の一方向予約を開始します。そのパスメッセージを受信するボブは、RESVで返信します。
All this is independent of SIP. However, during this time of reservation establishment, a Provisional Acknowledgement (PRACK) [M3] is sent from Alice to Bob to confirm the request for confirmation of 2 one-way reservations at Alice's UA. This message is acknowledged with a normal 200 OK message [M4]. This is shown in Figure 7.
これはすべてSIPから独立しています。ただし、留保施設のこの時期には、アリスのUAでの2つの片道予約の確認のリクエストを確認するために、アリスからボブに暫定的な謝辞（PRACK）[M3]が送信されます。このメッセージは、通常の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レイヤーで更新メッセージ[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
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
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 Lineおよびa = des Lineから構築できる一致するテーブルによって表示されます。2行が一致する場合、「Qos」に関してはこれ以上のシグナル伝達のニーズはありません。[M6]は、2つのUAS間のこの同期の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
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
At this point, the reservation is operational and both UAs know it. Bob's UA now rings, telling Bob the user that Alice is calling him. ([M7] is the SIP indication to Alice that this is taking place). Nothing up until now has involved Bob the user. Bob picks up the phone (generating [M10], from which Alice's UA responds with the final ACK), and RTP is now operating within the reservations between the two UAs.
この時点で、予約は動作しており、両方のUASがそれを知っています。ボブのUAが鳴り響き、ボブにアリスが彼を呼んでいることをユーザーに伝えます。（[M7]は、これが行われていることをアリスにSIPの兆候です）。これまで、ボブのユーザーを巻き込んでいませんでした。ボブは電話（[M10]を生成し、アリスのUAが最終的なACKで応答します）を拾い、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は、アリスからボブへの予約のための一般的なルーターインターフェイスと、キャロルからデイブへの予約の1つのルートでもあるものを示しています。このインターフェイスは、私たちの例で輻輳を発生させます。
Carol is now calling Dave at a Resource-Priority level of "Immediate", which is higher in priority than Alice to Bob's "routine". In this continuing example, Router 2's Interface-7 is congested and cannot accept any more RSVP traffic. Perhaps the offered load is at interface capacity. Perhaps Interface-7 is configured with a fixed amount of bandwidth it can allocate for RSVP traffic, and it has reached its maximum without one of the reservations going away through normal termination or forced termination (preemption).
キャロルは現在、アリスよりも優先度が高い「即時」のリソース優先レベルでデイブを呼んでいます。この継続的な例では、Router 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:
Interface-7には提供された負荷があまりなく、キャロルのSIPメッセージングなど、デイブへの呼び出しを設定するなど、信号パケットを送信できません。これは、設計によるものでなければなりません（すべてのRSVPトラフィックがシグナリングパケットからインターフェイスを飢えさせるわけではありません）。キャロルは、次の重要な特徴を自分の招待状に送ります。
[M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
This packet does *not* affect the reservations between Alice and Bob (SIP and RSVP are at different layers, and all routers are passing signaling packets without problems). Dave sends his M2:
このパケットは、アリスとボブの間の予約に影響を与えません（SIPとRSVPは異なるレイヤーにあり、すべてのルーターは問題なくシグナリングパケットを通過しています）。デイブは彼のM2を送ります：
[M2 - 183 "Session Progress"]
[M2-183 "セッションの進行"]
with the SDP chart of:
のSDPチャートで：
a=curr:qos e2e none
a = curr：qos e2eなし
a=des:qos mandatory e2e sendrecv
a = des：qos必須e2e sendrecv
a=conf:qos e2e recv
a = conf：qos e2e recv
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の予約が必要であることを理解していることを示しています。デイブは彼のパスメッセージを送ります。パスメッセージは、アリスの予約に影響を与えません。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):
この例をシンプルにするために、デイブからキャロルへのパスメッセージがこのルートを取りました（これは逆方向のルートとは異なります）：
Dave -> R8 -> R7 -> R6 -> R5 -> Carol
causing the reservation to be this route:
予約をこのルートにします：
Carol -> R5 -> R6 -> R7 -> R8 -> Dave
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メッセージをデイブに送信すると、彼女はすぐにパスメッセージを送信して補完的な予約を設定します。
The PATH message from Carol to Dave be through routers:
キャロルからデイブへのパスメッセージはルーターを介して行われます。
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
Thus, the RESV message will be through routers:
したがって、RESVメッセージはルーターを介して行われます。
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
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メッセージは、Alice-to-BOBの予約と同じルーターR3とR2を横断します。このRESVメッセージは、R2のInterface-7で受信した場合、R2が次のかどうかを決定する必要があるため、混雑状況が作成されます。
o to keep the Alice-to-Bob reservation and error the new RESV from Dave, or
o Alice-to-BOBの予約を維持し、デイブから新しいRESVをエラーにするため、または
o to error the reservation from Alice to Bob in order to make room for the Carol-to-Dave reservation.
o キャロルからデイブの予約の余地を作るために、アリスからボブへの予約をエラーします。
Alice's reservation was set up in SIP at the "routine" precedence level. This will equate to a comparable RSVP priority number (RSVP has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave's RESV equates to a precedence value of "immediate", which is a higher priority. Thus, R2 will preempt the reservation from Alice to Bob and allow the reservation request from Dave to Carol. The proper RSVP error is the ResvErr that indicates preemption. This message travels downstream towards the originator of the RESV message (Bob). This clears the reservation in all routers downstream of R2 (meaning 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.
アリスの予約は、「ルーチン」の優先順位レベルでSIPで設定されました。これは、同等のRSVP優先度数に相当します（RSVPには65,535の優先度値、つまり[RFC3181]あたり2*32ビット）。DaveのRESVは、「即時」の優先値に相当します。これは優先度が高いです。したがって、R2はアリスからボブへの予約を先取りし、デイブからキャロルへの予約要求を許可します。適切なRSVPエラーは、先制を示すRESVERRです。このメッセージは、RESVメッセージ（BOB）の発信者に向かって下流に移動します。これにより、R2の下流のすべてのルーターの予約がクリアされます（R3とR4を意味します）。ボブがこの予約で先制が発生したことを示すRESVERRメッセージを受信すると、ボブのUAはアリスのUAに向かってSIP先制の表示を送信します。これは2つのことを達成します。1つ目は、[RFC3261]ごとに「ダイアログステートフル」を維持したいセッションセットアップパスにあるすべてのSIPサーバーを通知し、第二に、これは意図的な終了であり、プレイするためにアリスのUAに通知します。プリエンプショントーン。先制によるこの終了のSIPの適切な兆候は、これが発生した理由を示す理由ヘッダー（この場合は「予約されたリソースを先取りする」）を含む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>
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.
AliceのUAがこのメッセージを受け取ると、彼女のUAがコールを終了し、BOBに200 OKを送信してByeメッセージの受信を確認し、ユーザーのAliceに先制トーンを再生します。
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.
DaveからのRESVメッセージはR2を正常に通過し、CarolのUAはそれを受け取ります。Alice-to-Bobのコールのセットアップと同様に、CarolはDaveに更新メッセージを送信し、「SendRecv」の指示でQoS "E2E"を持っていることを確認します。ボブは、現在のステータス（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を使用してボブに電話をかけました。キャロルがデイブを最優先事項で呼んだとき、彼らの呼び出しは、リソースの争いがあった場合、より低い優先順位の呼び出しを先取りしていたでしょう。この場合、アリスとボブの間の呼び出しに発生し、影響を与えました。この混雑ポイントのルーターは、キャロルとデイブの間に優先順位のコールを行うために、アリスのボブへの呼びかけを先取りしました。アリスとボブはどちらも先制イベントについて知らされました。アリスとボブのUASの両方が先制兆候を演奏しました。この付録で言及されていなかったのは、このドキュメントでは、Router R2（この例で）がドメイン管理者にSyslogメッセージを生成して、このドメイン内のこのようなイベントを適切に管理および追跡することを推奨することでした。これにより、ドメイン管理者がそのようなイベントがどこで発生するか、そしてそれらが何であるかについての知識を記録したことが保証されます。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
フレッドベイカーシスコシステム1121
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。