Network Working Group J. Manner
Request for Comments: 4094 X. Fu
Category: Informational May 2005
Analysis of Existing Quality-of-Service Signaling Protocols
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.
この文書では、IPネットワークのためのサービス（QoS）の既存の品質のいくつかのシグナリングプロトコルをレビュー。ここでの目標は、彼らから学ぶことや一般的な誤解を避けるためです。さらに、我々はこの分野での新たなプロトコルの設計と実装の際にミスを避けるために必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. RSVP and RSVP Extensions ........................................4
2.1. Basic Design ...............................................4
2.1.1. Signaling Model .....................................4
2.1.2. Soft State ..........................................5
2.1.3. Two-Pass Signaling Message Exchanges ................5
2.1.4. Receiver-Based Resource Reservation .................5
2.1.5. Separation of QoS Signaling from Routing ............5
2.2. RSVP Extensions ............................................6
2.2.1. Simple Tunneling ....................................6
2.2.2. IPsec Interface .....................................6
2.2.3. Policy Interface ....................................6
2.2.4. Refresh Reduction ...................................7
2.2.5. RSVP over RSVP ......................................8
2.2.6. IEEE 802-Style LAN Interface ........................8
2.2.7. ATM Interface .......................................9
2.2.8. DiffServ Interface ..................................9
2.2.9. Null Service Type ...................................9
2.2.10. MPLS Traffic Engineering ..........................10
2.2.11. GMPLS and RSVP-TE .................................11
2.2.12. GMPLS Operation at UNI and E-NNI Reference
Points ............................................12
2.2.13. MPLS and GMPLS Future Extensions ..................12
2.2.14. ITU-T H.323 Interface .............................13
2.2.15. 3GPP Interface ....................................13
2.3. Extensions for New Deployment Scenarios ...................14
2.4. Conclusion ................................................15
3. RSVP Transport Mechanism Issues ................................16
3.1. Messaging Reliability .....................................16
3.2. Message Packing ...........................................17
3.3. MTU Problem ...............................................17
3.4. RSVP-TE vs. Signaling Protocol for RT Applications ........18
3.5. What Would Be a Better Alternative? .......................18
4. RSVP Protocol Performance Issues ...............................19
4.1. Processing Overhead .......................................19
4.2. Bandwidth Consumption .....................................20
5. RSVP Security and Mobility .....................................21
5.1. Security ..................................................21
5.2. Mobility Support ..........................................22
6. Other QoS Signaling Proposals ..................................23
6.1. Tenet and ST-II ...........................................23
6.2. YESSIR ....................................................24
6.2.1. Reservation Functionality ..........................24
6.2.2. Conclusion .........................................25
6.3. Boomerang .................................................25
6.3.1. Reservation Functionality ..........................25
6.3.2. Conclusions ........................................26
6.4. INSIGNIA ..................................................26
7. Inter-Domain Signaling .........................................27
7.1. BGRP ......................................................27
7.2. SICAP .....................................................27
7.3. DARIS .....................................................28
8. Security Considerations ........................................30
9. Summary ........................................................30
10. Contributors ..................................................31
11. Acknowledgements ..............................................31
12. Appendix A: Comparison of RSVP to the NSIS Requirements .......32
13. Normative References ..........................................38
14. Informative References ........................................38
This document reviews some of the existing QoS signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.
この文書では、IPネットワークのためのシグナリングプロトコル既存のQoSのいくつかをレビュー。ここでの目標は、彼らから学ぶことや一般的な誤解を避けるためです。さらに、我々はこの分野での新たなプロトコルの設計と実装の際にミスを避けるために必要があります。
There have been a number of historic attempts to deliver QoS or generic signaling to the Internet. In the early years, it was believed that multicast would be popular for the majority of communications; thus, both RSVP and earlier ST-II were designed in a way that is multicast-oriented.
インターネットへのQoSや一般的なシグナリングを提供する歴史的な多くの試みが行われてきました。年の初めには、マルチキャスト通信の大多数のために人気になると信じられていました。したがって、RSVP以前のST-IIの両方がマルチキャスト指向であるように設計しました。
ST-II was developed as a reservation protocol for point-to-multipoint communication. However, since it is sender-initiated, it does not scale with the number of receivers in a multicast group. Its processing is fairly complex. Since every sender needs to set up its own reservation, the total amount of reservation states is large. RSVP was then designed to provide support for multipoint-to-multipoint reservation setup in a more efficient way. However, its complexity, scalability, and ability to meet new requirements have been criticized.
ST-IIは、ポイントツーマルチポイント通信のために予約プロトコルとして開発されました。それは、送信者が開始しているので、しかし、それは、マルチキャストグループにおける受信機の数を拡張できません。その処理はかなり複雑です。すべての送信者は、自身の予約を設定する必要があるため、予約状態の総量が大きいです。 RSVPは、その後、より効率的な方法でマルチポイント・ツー・マルチポイント予約セットアップのためのサポートを提供するように設計されました。しかし、その複雑さ、拡張性、および新しい要件を満たす能力が批判されています。
YESSIR (YEt another Sender Session Internet Reservations) [PS98] and Boomerang [FNM+99] are examples of protocols designed after RSVP. Both were meant to be simpler than RSVP. YESSIR is an extension to RTCP, whereas Boomerang is used with ICMP.
YESSIR（さらに別のセンダセッションインターネット予約）[PS98]とブーメラン[FNM + 99] RSVP後に設計されたプロトコルの例です。どちらも、RSVPよりも簡単であることを意味していました。ブーメランがICMPで使用され、一方YESSIRは、RTCPの拡張です。
Previously, a lot of work has been targeted at creating a new signaling protocol for resource control. Istvan Cselenyi suggested having a QoSSIG BOF in IETF47, for identifying problems in QoS signaling, but failed to get enough support [URL1]. Some people argued, "in many ways, RSVP improved upon ST-2, and it did start out simpler, but it resulted in a design with complexity and scalability", while others thought that "new knowledge and requirements" made RSVP insufficient. Some concluded that there is no simpler way to handle the same problem than RSVP.
以前は、多くの作業は、リソース管理のための新たなシグナリングプロトコルの作成をターゲットにされています。イシュトヴァーンCselenyiは、QoSシグナリングに問題を特定するため、IETF47でQoSSIG BOFを持つ提案したが、十分なサポート[URL1]の取得に失敗しました。一部の人々は他の人が、「新しい知識と要件は、」RSVPが不足したこと考えながら、「多くの点で、RSVPは、ST-2大幅に改善し、それは単純に出始めたが、それは複雑さと拡張性を持つデザインになった」と主張しました。いくつかはRSVPよりも、同じ問題を処理するために、何の簡単な方法が存在しないと結論付けました。
Michael Welzl organized a special session "ABR to the Internet" in SCI 2001, and gathered some inputs for requesting an "ABR to the Internet" BOF in IETF#51, which was intended to introduce explicit rate-feedback-related mechanisms for the Internet (e2e, edge2edge). This failed because of "missing community interest".
マイケルWelzlは、SCI、2001年に「インターネットへのABR」特別セッションを組織し、そしてインターネットのための明示レートフィードバック関連メカニズムを導入することを意図したIETF＃51、に「ABRインターネットへの」BOFを要求するためのいくつかの入力を集め（E2E、edge2edge）。これは、「不足している地域社会の関心」に失敗しました。
OPENSIG [URL2] has been involved in the Internet signaling for years. Ping Pan initiated a SIGLITE [URL3] BOF mailing list to investigate lightweight Internet signaling. Finally, NSIS BOF was successful, and the NSIS WG was formed.
OPENSIG [URL2]年間、インターネットのシグナル伝達に関与してきました。 Pingのパンは、軽量インターネットシグナリングを調査するSIGLITE [URL3] BOFのメーリングリストを開始しました。最後に、NSIS BOFは成功した、とNSIS WGを形成しました。
The most mature and original protocols are presented in their own sections, and other QoS signaling protocols are presented in later subsections. The presented protocols are chosen based on relevance to the work within NSIS. The aim is not to review every existing protocol.
最も成熟した、オリジナルのプロトコルは、独自のセクションに提示され、およびシグナリングプロトコルを他のQoSは、後のサブセクションで提示されています。提示プロトコルはNSIS内の作業との関連性に基づいて選択されます。目的は、すべての既存のプロトコルを確認することではありません。
RSVP (the Resource Reservation Protocol) [ZDSZ93] [RFC2205] [BEBH96] has evolved from ST-II to provide end-to-end QoS signaling services for application data streams. Hosts use RSVP to request a specific quality of service (QoS) from the network for particular application flows. Routers use RSVP to deliver QoS requests to all routers along the data path. RSVP also can maintain and refresh states for a requested QoS application flow.
RSVP（リソース予約プロトコル）[ZDSZ93] [RFC2205]は[BEBH96】アプリケーション・データ・ストリームのためのサービスシグナリング、エンドツーエンドのQoSを提供するために、ST-IIから進化してきました。ホストは、特定のアプリケーションフローのためのネットワークからのサービスの特定品質（QoS）を要求するためにRSVPを使用します。ルータは、データパスに沿ってすべてのルータにQoS要求を実現するためにRSVPを使用しています。 RSVPはまた、要求されたQoSアプリケーションフローの状態を維持し、リフレッシュすることができます。
By original design, RSVP fits well into the framework of the Integrated Services (IntServ) [RFC2210] [BEBH96] with certain modularity and scalability.
オリジナル設計により、RSVPは、特定のモジュール性とスケーラビリティとの統合サービス（IntServの）[RFC2210] [BEBH96]のフレームワークによく適合する。
RSVP carries QoS signaling messages through the network, visiting each node along the data path. To make a resource reservation at a node, the RSVP module communicates with two local decision modules, admission control and policy control. Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control provides authorization for the QoS request. If either check fails, the RSVP module returns an error notification to the application process that originated the request. If both checks succeed, the RSVP module sets parameters in a packet classifier and packet scheduler to obtain the desired QoS.
RSVPは、データパスに沿った各ノードを訪問して、ネットワークを介してメッセージをQoSシグナリングを運びます。ノードのリソース予約をするには、RSVPモジュールは、2つのローカルの決定モジュール、アドミッション制御とポリシー制御と通信します。アドミッション制御は、ノードが要求されたQoSを供給するのに十分な利用可能なリソースを持っているかどうかを決定します。ポリシー制御は、QoS要求の認可を提供します。どちらかのチェックが失敗した場合、RSVPモジュールは、要求を発信アプリケーションプロセスにエラー通知を返します。両方のチェックが成功した場合、RSVPモジュールは、望ましいQoSを得るために、パケット分類器とパケットスケジューラにパラメータを設定します。
The design of RSVP distinguished itself by a number of fundamental ways; particularly, soft state management, two-pass signaling message exchanges, receiver-based resource reservation, and separation of QoS signaling from routing.
RSVPの設計は、基本的ないくつかの方法で自分自身を区別しました。特に、ソフト状態管理、ツーパスシグナリングメッセージ交換、受信機ベースのリソース予約、およびルーティングのQoSシグナリングの分離。
The RSVP signaling model is based on a special handling of multicast. The sender of a multicast flow advertises the traffic characteristics periodically to the receivers via "Path" messages. Upon receipt of an advertisement, a receiver may generate a "Resv" message to reserve resources along the flow path from the sender. Receiver reservations may be heterogeneous. To accommodate the multipoint-to-multipoint multicast applications, RSVP was designed to support a vector of reservation attributes called the "style". A style describes whether all senders of a multicast group share a single reservation and which receiver is applied. The "Scope" object additionally provides the explicit list of senders.
RSVPシグナリング・モデルは、マルチキャストの特別な処理に基づいています。マルチキャストフローの送信者は「パス」メッセージを介して受信者に定期的にトラフィック特性をアドバタイズします。広告を受信すると、受信機は、送信者からの流路に沿ってリソースを予約する「のResv」メッセージを生成してもよいです。レシーバの予約が不均一であってもよいです。マルチポイント・ツー・マルチポイントのマルチキャストアプリケーションに対応するために、RSVPは、「スタイル」と呼ばれる予約属性のベクトルをサポートするように設計されました。スタイルは、マルチキャストグループのすべての送信者が単一の予約を共有している受信機が適用されているかどうかを記述する。 「適用範囲」オブジェクトは、さらに送信者の明示的なリストを提供します。
Because the number of receivers in a multicast flow is likely to change, and the flow of delivery paths might change during the life of an application flow, RSVP takes a soft-state approach in its design, creating and removing the protocol states (Path and Resv states) in routers and hosts incrementally over time. RSVP sends periodic refresh messages (Path and Resv) to maintain its states and to recover from occasional lost messages. In the absence of refresh messages, the RSVP states automatically time out and are deleted. States may also be deleted explicitly by PathTear, PathErr with Path_State_Removed flag, or ResvTear Message.
マルチキャストフロー内の受信機の数が変化する可能性がある、と配信経路の流れはアプリケーションフローの寿命の間に変更される可能性があるため、RSVPは、プロトコル状態を作成および削除、その設計にソフトステートアプローチをとる（パスとインクリメンタルに時間をかけてルータとホストでのResv状態）。 RSVPは、その状態を維持し、時折失われたメッセージから回復するために定期的なリフレッシュメッセージ（パスとのResv）を送信します。リフレッシュメッセージがない場合には、RSVPの状態が自動的にタイムアウトして削除されます。国はまた、PathTear、Path_State_RemovedフラグとのPathErr、またはたResvTearメッセージによって明示的に削除されることがあります。
The receiver in an application flow is responsible for requesting the desired QoS from the sender. To do this, the receiver issues an RSVP QoS request on behalf of the local application. The request propagates to all routers in reverse direction of the data paths toward the sender. In this process, RSVP requests might be merged, resulting in a protocol that scales well when there are a large number of receivers.
アプリケーションフロー内の受信機は、送信者から所望のQoSを要求する責任があります。これを行うために、受信機は、ローカルアプリケーションの代わりにRSVPのQoS要求を発行します。要求は、送信者に向けてデータパスの逆方向のすべてのルータに伝搬します。このプロセスでは、RSVP要求は、受信機の数が多い場合もスケールのプロトコルで、その結果、マージされるかもしれません。
Receiver-initiation is critical for RSVP to set up multicast sessions with a large number of heterogeneous receivers. A receiver initiates a reservation request at a leaf of the multicast distribution tree, traveling toward the sender. Whenever a reservation is found to already exist in a node in the distribution tree, the new request will be merged with the existing reservation. This could result in fewer signaling operations for the RSVP nodes in the multicast tree close to the sender but could introduce a restriction to receiver-initiation.
RSVPは、異種の多数の受信機とのマルチキャストセッションをセットアップするための受信-開始が重要です。受信側は、送信側に向かう、マルチキャスト配信ツリーのリーフの予約要求を開始します。予約が既に配布ツリー内のノードに存在することが発見されたときはいつでも、新しい要求は既存の予約とマージされます。これは、送信者に近いマルチキャストツリーにおけるRSVPノードに少ないシグナリング動作につながる可能性がありますが、開始を受信機に制限を導入することができました。
RSVP messages follow normal IP routing. RSVP is not a routing protocol, but rather is designed to operate with current and future unicast and multicast routing protocols. The routing protocols are responsible for choosing the routes to use to forward packets, and RSVP consults local routing tables to obtain routes. RSVP is responsible only for reservation setup along a data path.
RSVPメッセージは、通常のIPルーティングに従ってください。 RSVPはルーティングプロトコルではなく、現在および将来のユニキャストおよびマルチキャストルーティングプロトコルで動作するように設計されています。ルーティングプロトコルは、パケットを転送するために使用するルートを選択するための責任がある、とRSVPはルートを取得するためにローカルルーティングテーブルを参照します。 RSVPは、データパスに沿って予約セットアップを担当しています。
A number of messages and objects have been defined for the protocol. A detailed description is given in [RFC2205].
メッセージやオブジェクトの数は、プロトコルのために定義されています。詳細な説明は、[RFC2205]に記載されています。
RSVP [RFC2205] was originally designed to support real-time applications over the Internet. Over the past several years, the demand for multicast-capable real-time teleconferencing, which many people had envisioned to be one of the key Internet applications that could benefit from network-wide deployment of RSVP, has never materialized. Instead, RSVP-TE [RFC3209], a RSVP extension for traffic engineering, has been widely deployed by a large number of network providers to support MPLS applications.
RSVP [RFC2205]は、もともとインターネット上でリアルタイムアプリケーションをサポートするように設計されました。過去数年にわたり、多くの人々がRSVPのネットワーク全体の展開から利益を得ることができる主要なインターネットアプリケーションの一つであることを想定していたマルチキャスト可能なリアルタイムのテレビ会議の需要は、マテリアライズドありませんでした。代わりに、RSVP-TE [RFC3209]、交通工学のためのRSVPの拡張は、広くMPLSアプリケーションをサポートするために、ネットワークプロバイダの多数によって展開されてきました。
There are a large number of protocol extensions based on RSVP. Some provide additional features, such as security and scalability, to the original protocol. Some introduce additional interfaces to other services, such as DiffServ. And some simply define new applications, such as MPLS and GMPLS, that are completely irrelevant from protocol's original intent.
RSVPに基づくプロトコル拡張が多数あります。いくつかは、元のプロトコルに、このようなセキュリティやスケーラビリティなどの追加機能を提供します。いくつかは、DiffServのようなその他のサービスに追加のインタフェースを紹介します。そして、いくつかは、単にプロトコルの本来の意図とは全く無関係で、このようなMPLSやGMPLSなどの新しいアプリケーションを、定義します。
In this section, we list only IETF-based RFCs and a limited set of other organizations' specifications. Informational RFCs (e.g., RFC2998 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not covered here.
このセクションでは、IETFのRFCベースや他の組織の仕様の限定セットのみをリストします。情報のRFC（例えば、RFC2998 [RFC2998]）と作業中のI-DS（例えば、プロキシ）は、ここではカバーされていません。
[RFC2746] describes an IP tunneling enhancement mechanism that allows RSVP to make reservations across all IP-in-IP tunnels, basically by recursively applying RSVP over the tunnel portion of the path.
[RFC2746]はRSVPを再帰的経路のトンネル部の上にRSVPを適用することにより、基本的に、すべてのIPインIPトンネルを横切って予約を行うことを可能にするIPトンネリング増強機構が記載されています。
RSVP can support IPsec on a per-address, per-protocol basis instead of on a per flow basis. [RFC2207] extends RSVP by using the IPsec Security Parameter Index (SPI) in place of the UDP/TCP-like ports. This introduces a new FILTER_SPEC object, which contains the IPsec SPI, and a new SESSION object.
RSVPごとのアドレス、プロトコルごとの基準ではなく、フローごとにIPsecをサポートすることができます。 [RFC2207]はUDP / TCPのようなポートの代わりに、IPsecのセキュリティパラメータインデックス（SPI）を使用して、RSVPを拡張します。これは、IPsecのSPIを含む新しいFILTER_SPECオブジェクト、および新しいSessionオブジェクトを紹介します。
[RFC2750] specifies the format of POLICY_DATA objects and RSVP's handling of policy events. It introduces objects that are interpreted only by policy-aware nodes (PEPs) that interact with policy decision points (PDPs). Nodes that are unable to interpret the POLICY_DATA objects are called policy-ignorant nodes (PINs). The content of the POLICY_DATA object itself is protected only between PEPs and therefore provides end-to-middle or middle-to-middle security.
[RFC2750]はPOLICY_DATAオブジェクトとポリシーイベントのRSVPの取り扱いの形式を指定します。それが唯一のポリシー決定ポイント（PDPの）と対話政策対応のノード（のPEP）によって解釈されているオブジェクトを紹介します。 POLICY_DATAオブジェクトを解釈することができないノードは、ポリシー無知ノード（ピン）と呼ばれています。 POLICY_DATAオブジェクト自体のコンテンツのみのPEP、したがってエンドツー中間又は中間対中央セキュリティを提供するとの間に保護されています。
[RFC2749] specifies the usage of COPS policy services in RSVP environments. [RFC3181] specifies a preemption priority policy element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object. [RFC3520] describes how authorization provided by a separate protocol (such as SIP) can be reused with the help of an authorization token within RSVP. The token might therefore contain either the authorized information itself (e.g., QoS parameters) or a reference to those values. The token might be unprotected (which is strongly discouraged) or protected based on symmetric or asymmetric cryptography. Moreover, the document describes how to provide the host with encoded session authorization information as a POLICY_DATA object.
[RFC2749]はRSVP環境でCOPSポリシーサービスの利用を指定します。 [RFC3181]はRSVP POLICY_DATAオブジェクトで使用するための先取り優先ポリシーエレメント（PREEMPTION_PRI）を指定します。 [RFC3520]は（SIPなどの）別のプロトコルによって提供許可がRSVP内の認証トークンの助けを借りて再使用することができる方法について説明します。トークンは、従って、許可情報自体（例えば、QoSパラメータ）、またはそれらの値への参照のいずれかを含む場合があります。トークンは（強く推奨されている）または対称または非対称暗号法に基づいて保護され、保護されていないかもしれません。また、文書がPOLICY_DATAオブジェクトとして符号化されたセッションの認証情報をホストに提供する方法について説明します。
[RFC2961] describes mechanisms to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP message is lost, and refresh state without the transmission of whole refresh messages. It defines the following objects: MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK, MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST objects. Three new RSVP message types are defined:
[RFC2961]は、リフレッシュメッセージの処理オーバーヘッド要件を低減RSVPメッセージが失われたときに生じる状態の同期待ち時間をなくし、全体リフレッシュメッセージを送信することなく、状態を更新するメカニズムを説明しています。 MESSAGE_ID、MESSAGE_ID_ACK、MESSAGE_ID_NACK、MESSAGE_ID LIST、MESSAGE_ID SRC_LIST、およびMESSAGE_ID MCAST_LISTオブジェクト：それは次のオブジェクトが定義されています。三つの新しいRSVPメッセージタイプが定義されています。
1) Bundle messages consist of a bundle header followed by a body consisting one or more standard RSVP messages. Bundle messages help in scaling RSVP to reduce processing overhead and bandwidth consumption.
1）バンドルメッセージは、1つまたは複数の標準RSVPメッセージからなる本体続いバンドルヘッダから成ります。バンドルメッセージは、処理オーバーヘッドと帯域幅の消費量を削減するためにRSVPのスケーリングに役立ちます。
2) ACK messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects. ACK messages are sent between neighboring RSVP nodes to detect message loss and to support reliable RSVP message delivery on a per-hop basis.
2）ACKメッセージは、一つ以上のMESSAGE_ID_ACKまたはMESSAGE_ID_NACKオブジェクトを運びます。 ACKメッセージは、メッセージの損失を検出し、ホップごとのベースで信頼RSVPメッセージの配信をサポートするために、隣接RSVPノード間で送信されます。
3) Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST objects. They correspond to Path and Resv messages that establish the states. Srefresh messages are used to refresh RSVP states without transmitting standard Path or Resv messages.
3）Srefreshメッセージは、一つ以上のMESSAGE_IDリストMESSAGE_ID SRC_LIST、及びMESSAGE_ID MCAST_LISTオブジェクトを運びます。彼らは、パスや状態を確立RESVメッセージに対応しています。 Srefreshメッセージは、標準パスまたはRESVメッセージを送信することなく、RSVP状態をリフレッシュするために使用されています。
[RFC3175] allows installation of one or more aggregated reservations in an aggregation region; thus, the number of individual RSVP sessions can be reduced. The protocol type is swapped from RSVP to RSVP-E2E-IGNORE in E2E (standard) Path, PathTear, and ResvConf messages when they enter the aggregation region, and is swapped back when they leave. In addition to a new PathErr code (NEW_AGGREGATE_NEEDED), three new objects are introduced:
[RFC3175]は集合領域内の1つまたは複数の集約の予約のインストールを可能にします。このように、個々のRSVPセッションの数を削減することができます。プロトコルタイプは、それらが凝集領域に入るときE2E（標準）パス、PathTear、およびResvConfメッセージにRSVP-E2Eは、無視するRSVPからスワップされ、それらが去るときに戻って交換されます。新しいたPathErrコード（NEW_AGGREGATE_NEEDED）に加えて、3つの新しいオブジェクトが導入されます。
1) SESSION object, which contains two values: the IP Address of the aggregate session destination, and the Differentiated Services Code Point (DSCP) that it will use on the E2E data the reservation contains.
それは予約が含まれていE2Eデータに使用することを集約セッションの宛先のIPアドレス、および差別化サービスコードポイント（DSCP）：1）2つの値を含むセッションオブジェクト。
2) SENDER_TEMPLATE object, which identifies the aggregating router for the aggregate reservation.
集約の予約のための集約ルータを識別する2）SENDER_TEMPLATEオブジェクト。
3) FILTER_SPEC object, which identifies the aggregating router for the aggregate reservation, and is syntactically identical to the SENDER_TEMPLATE object.
集約の予約のための集約ルータを識別し、SENDER_TEMPLATEオブジェクトに構文的に同一である3）FILTER_SPECオブジェクト。
From the perspective of RSVP signaling and the handling of data packets in the aggregation region, these cases are equivalent to that of aggregating E2E RSVP reservations. The only difference is that E2E RSVP signaling does not take place and cannot therefore be used as a trigger, so some additional knowledge is required for setting up the aggregate reservation.
RSVPシグナリングと凝集領域におけるデータパケットの取り扱いの観点から、これらの場合には、E2EのRSVP予約を集約することと等価です。唯一の違いは、E2EのRSVPシグナリングが行われていないため、トリガとして使用することはできませんので、いくつかの追加の知識が集約予約を設定するために必要とされることです。
[RFC2814] introduces an RSVP LAN_NHOP address object that keeps track of the next L3 hop as the PATH message traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP nodes). Both layer-2 and layer-3 addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is used to include the Layer-2 address (L2ADDR) of the previous hop, complementing the L3 address information included in the RSVP_HOP object (RSVP_HOP_L3 address).
[RFC2814]はPATHメッセージは、2つのL3エンティティ（PHOPとNHOPノードのRSVP）との間のL2ドメインを横断するように、次のL3ホップを追跡するのRSVP LAN_NHOPアドレスオブジェクトを導入します。両方のレイヤ2およびレイヤ3アドレスはLAN_NHOPに含まれています。 RSVP_HOP_L2オブジェクトはRSVP_HOPオブジェクト（RSVP_HOP_L3アドレス）に含まれるL3アドレス情報を補完する、前のホップのレイヤ2アドレス（L2ADDR）を含むために使用されます。
To provide sufficient information for debugging or resource management, RSVP diagnostic messages (DREQ and DREP) are defined in [RFC2745] to collect and report RSVP state information along the path from a receiver to a specific sender.
デバッグやリソース管理のための十分な情報を提供するために、診断メッセージ（DREQとDREP）をRSVPは、特定の受信側から送信側への経路に沿ってRSVP状態情報を収集及び報告するために[RFC2745]で定義されています。
[RFC2379] and [RFC2380] define RSVP over ATM implementation guidelines and requirements to interwork with the ATM (Forum) UNI 3.x/4.0. [RFC2380] states that the RSVP (control) messages and RSVP associated data packets must not be sent on the same virtual circuits (VCs), and that an explicit release of RSVP associated QoS VCs must be performed once the VC for forwarding RSVP control messages terminates. Although a separate control VC is also possible for forwarding RSVP control messages, [RFC2379] recommends creating a best-effort short-cut first (if one does not exist), which can allow setting up RSVP-triggered VCs to use the best-effort end-point. (A short-cut is a point-to-point VC where the two end-points are located in different IP subnets.) For data flows, the subnet senders must establish all QoS VCs, and the RSVP-enabled subnet receiver must be able to accept incoming QoS VCs. RSVP must request that the configurable inactivity timers of VCs be set to "infinite". If it is too complex to do this at the VC receiver, RSVP over ATM implementations are required not to use an inactivity timer to clear any received connections. For dynamic QoS, the replacement of VC should be done gracefully.
[RFC2379]と[RFC2380] ATM（フォーラム）UNI 3.xの/ 4.0と相互作用するためにATMの実装ガイドラインと要件の上にRSVPを定義します。 [RFC2380]はRSVP（制御）メッセージ及びRSVP関連するデータパケットが同じ仮想回線（VCS）に送られ、RSVPの明示的な解放関連付けられたQoS VCがRSVP制御メッセージを転送するためVC回実行されなければならないことをしてはならないと述べています終了します。別個の制御VCが転送RSVP制御メッセージも可能であるが、[RFC2379]は（が存在しない場合）、短いカット第ベストエフォート型の作成をお勧めし、ベストエフォートを使用するRSVP-トリガVCを設定可能にすることができます終点。データフローについて、サブネット送信者がすべてのQoS VCを確立しなければならない（ショートカットは、2つのエンドポイントが異なるIPサブネットに配置されているポイントツーポイントVCである）、およびRSVP対応サブネット受信機はできなければなりません入ってくるのQoS VCを受け入れます。 RSVPは、VCの設定可能な非アクティブタイマーが「無限」に設定することを要求しなければなりません。それはVCの受信機でこれを行うにはあまりにも複雑である場合には、RSVP over ATM実装は、任意の受信接続をクリアするために非アクティブタイマーを使用しないように要求されています。ダイナミックなQoSのために、VCの交換が優雅に行われるべきです。
RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated Services Code Points (DSCPs) in RSVP message objects. If the network element determines that the RSVP request is admissible to the DiffServ network, one or more DSCPs corresponding to the behavior aggregate are determined, and will be carried by the DCLASS Object added to the RESV message upstream toward the RSVP sender.
RFC2996 [RFC2996]はRSVPメッセージオブジェクトに差別化サービスコードポイント（DSCPを）を運ぶためにDCLASSオブジェクトを導入します。ネットワーク要素は、RSVP要求がのDiffServネットワークに許容であると判断した場合、行動集合に対応する1つのまたは複数のDSCPが決定され、RSVP送信側に向かって上流RESVメッセージに付加DCLASSオブジェクトによって運ばれます。
For some applications, service parameters are specified by the network, not by the application; e.g., enterprise resource planning (ERP) applications. The Null Service [RFC2997] allows applications to identify themselves to network QoS policy agents using RSVP signaling, but does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). The RSVP sender offers the new service type, 'Null Service Type', in the ADSPEC that is included with the PATH message. A new TSPEC corresponding to the new service type is added to the SENDER_TSPEC. In addition, the RSVP sender will typically include with the PATH message policy objects identifying the user, application and sub-flow, which will be used for network nodes to manage the correspondent traffic flow.
一部のアプリケーションでは、サービスパラメータはありません、アプリケーションによって、ネットワークによって指定されています。例えば、エンタープライズ・リソース・プランニング（ERP）アプリケーション。ヌルサービス[RFC2997]は、アプリケーションがRSVPシグナリングを使用してQoSポリシーエージェントをネットワークに自分自身を識別することができますが、リソース要件を指定するには、それらを必要としません。 （ネットワーク管理者によって決定される）アプリケーションのための適切なQoSポリシーを適用することにより、ネットワークの応答におけるQoSポリシーエージェント。 RSVPの送信者は、PATHメッセージに含まれているADSPECで、新しいサービスタイプ、「ヌルサービスタイプ」を提供しています。新しいサービスタイプに対応した新しいTSPECはSENDER_TSPECに追加されます。また、RSVP送信機は、典型的には、対応するトラフィックフローを管理するネットワークノードに使用されるユーザ、アプリケーションおよびサブフローを識別PATHメッセージポリシーオブジェクトで含むであろう。
RSVP-TE [RFC3209] specifies the core extensions to RSVP for establishing constraint-based explicitly routed LSPs in MPLS networks using RSVP as a signaling protocol. RSVP-TE is intended for use by label switching routers (as well as hosts) to establish and maintain LSP-tunnels and to reserve network resources for such LSP-tunnels.
RSVP-TE [RFC3209]は、シグナリングプロトコルとしてRSVPを使用して、MPLSネットワークにおける制約ベースの明示的ルーティングLSPを確立するためのRSVP、コアの拡張を指定します。 RSVP-TEを確立し、維持LSP-トンネルを、そのようなLSP、トンネルのためのネットワークリソースを予約するためのラベルスイッチングルータ（ならびにホスト）が使用するために意図されています。
RFC3209 defines a new Hello message (for rapid node failure detection).
RFC3209は（迅速なノード障害検出のための）新しいHelloメッセージを定義します。
RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects. Here, a session is the association of LSPs that support the LSP-tunnel. The traffic on an LSP can be classified as the set of packets that are assigned the same MPLS label value at the originating node of an LSP-tunnel.
RFC3209はまた、セッションのための新しいC-タイプ（LSP_TUNNEL_IPv4とLSP_TUNNEL_IPv6）を定義SENDER_TEMPLATE、およびFILTER_SPECオブジェクト。ここで、セッションは、LSPトンネルをサポートするLSPの関連です。 LSPのトラフィックは、LSPトンネルの送信元ノードに同一のMPLSラベル値が付与されたパケットのセットとして分類することができます。
The following 5 new objects are also defined:
以下の5つの新しいオブジェクトも定義されています。
1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path messages, encapsulating a concatenation of hops that constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined independently of conventional IP routing.
明示的にルーティングされたパスを構成するホップの連結を封入、RSVPパスメッセージに組み込まれている1）EXPLICIT_ROUTEオブジェクト（ERO）。このオブジェクトを使用して、ラベルスイッチRSVP-MPLS流れによって取られる経路は、独立して、従来のIPルーティングの予め決定することができます。
2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can create a Path message with a LABEL_REQUEST object. A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages.
2）LABEL_REQUESTオブジェクト。 LSPトンネルを確立するために、送信者はLABEL_REQUESTオブジェクトとPathメッセージを作成することができます。 LABEL_REQUEST・オブジェクトを送信したノードは、受け入れ、正しく対応するRESVメッセージにLABELオブジェクトを処理する準備ができなければなりません。
3) LABEL object. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel.
3）ラベルオブジェクト。 LABELオブジェクトを含むResvメッセージを受信する各ノードはこのLSPトンネルに関連付けられた発信トラフィックのためにそのラベルを使用します。
4) SESSION_ATTRIBUTE object, which can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as setup and holding priorities, resource affinities, and local-protection, are also included in this object.
セッション識別および診断を助けるためにPathメッセージに追加することができる4）SESSION_ATTRIBUTEオブジェクト。そのようなセットアップとホールドの優先順位、リソースの親和性、およびローカル保護などの追加の制御情報は、また、このオブジェクトに含まれています。
5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in both Path and Resv messages. It is used to collect detailed path information and is useful for loop detection and for diagnostics.
5）RECORD_ROUTEオブジェクト（RRO）。 RECORD_ROUTEオブジェクトは、パスとRESVメッセージの両方で表示されることがあります。詳細な経路情報を収集するために使用され、ループ検出および診断のために有用です。
Section 5 of [RFC3270] further specifies the extensions to RSVP to establish LSPs supporting DiffServ in MPLS networks, introducing a new DIFFSERV Object (applicable in the Path messages), and using pre-configured or signaled "EXP<-->PHB mapping" (e.g., [RFC3270]).
[RFC3270]のセクション5更（Pathメッセージに該当する）新しいDIFFSERVオブジェクトを導入し、MPLSネットワークでのDiffServをサポートするLSPを確立するために、RSVPへの拡張を指定し、事前に設定又はシグナリング用いて「EXP < - > PHBマッピング」 （例えば、[RFC3270]）。
RSVP-TE provides a way to indicate an unnumbered link in its Explicit Route and Record Route Objects through [RFC3477]. This specifies the following extensions:
RSVP-TEは、明示的経路に無数のリンクを示すための方法を提供し、レコードルートは、[RFC3477]を介してオブジェクト。これは、次の拡張子を指定します。
- An Unnumbered Interface ID Subobject, which is a subobject of the Explicit Route Object (ERO) used to specify unnumbered links.
- 明示的ルート・オブジェクト（ERO）のサブオブジェクトであるアンナンバードインターフェイスIDサブオブジェクトは、無数のリンクを指定するために使用されます。
- An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to form or use an identifier for an unnumbered Forwarding Adjacency.
- 隣接LSRが無数転送隣接の識別子を形成するか、または使用することを可能にするLSP_TUNNEL_INTERFACE_IDオブジェクト、。
- A new subobject of the Record Route Object, used to record that the LSP path traversed an unnumbered link.
- レコードルートオブジェクトの新しいサブオブジェクトは、LSPパスがアンナンバードリンクを横断することを記録するために使用しました。
GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It enables the provisioning of data-paths within networks supporting a variety of switching types including packet and cell switching networks, layer two networks, TDM networks, and photonic networks.
GMPLS RSVP-TE [RFC3473]はRSVP-TEの拡張です。これは、パケットとセル交換ネットワーク、レイヤ2つのネットワーク、TDMネットワーク、およびフォトニックネットワークを含むスイッチング様々なタイプのを支援するネットワーク内のデータ・パスのプロビジョニングを可能にします。
It defines the new Notify message (for general event notification), which may contain notifications being sent, with respect to each listed LSP, both upstream and downstream. Notify messages can be used for expedited notification of failures and other events to nodes responsible for restoring failed LSPs. A Notify message is sent without the router alert option.
これは、通知は、それぞれが、上流および下流の両方のLSPを列挙しに対して、送信されている含まれていてもよい（一般的なイベント通知のための）新たな通知メッセージを、定義します。メッセージを通知することはできなかったLSPを復元する責任ノードに障害やその他のイベントの迅速な通知のために使用することができます。通知メッセージは、ルータ警戒オプションなしで送信されます。
A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for general uses of MPLS:
新しいRSVP-TEの数は、（サブ）の目的は、MPLSの一般的な用途のためのGMPLS RSVP-TEで規定されています。
- a Generalized Label Request Object;
- 一般ラベル要求オブジェクト。
- a Generalized Label Object;
- 一般ラベルオブジェクト。
- a Suggested Label Object;
- 推奨ラベルオブジェクト。
- a Label Set Object (to restrict label choice);
- （ラベルの選択を制限するために）ラベルを設定したオブジェクトを表します。
- an Upstream_Label object (to support bidirectional LSPs);
- （双方向LSPをサポートする）UPSTREAM_LABELオブジェクト。
- a Label ERO subobject;
- ラベルEROサブオブジェクト。
- IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in out-of-band signaling or in bundled links);
- IF_ID RSVP_HOPオブジェクト（のIPv4およびIPv6の、アウトオブバンドシグナリングまたはバンドルリンクのインターフェイスを識別するために）。
- IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in out-of-band signaling or in bundled links);
- IF_ID ERROR_SPECオブジェクト（のIPv4およびIPv6の、アウトオブバンドシグナリングまたはバンドルリンクのインターフェイスを識別するために）。
- an Acceptable Label Set object (to support negotiation of label values in particular for bidirectional LSPs)
- （双方向のLSPのために特にラベル値のネゴシエーションをサポートするための）許容可能なラベルセットオブジェクト
- a Notify Request object (may be inserted in a Path or Resv message to indicate where a notification of LSP failure is to be sent)
- 通知要求オブジェクトは、（LSP障害の通知が送信される場所を示すパスまたはResvメッセージに挿入することができます）
- a Restart_Cap Object (used on Hello messages to identify recovery capabilities)
- （リカバリ機能を識別するために、Helloメッセージに使用）Restart_Capオブジェクト
- an Admin Status Object (to notify each node along the path of the status of the LSP, and to control that state).
- 管理ステータスオブジェクト（LSPの状態の経路に沿って各ノードに通知するために、その状態を制御します）。
The ITU-T defines network reference points that separate administrative or operational parts of the network. The reference points are designated as:
ITU-Tは、ネットワークの管理者または操作部を別のネットワーク基準点を規定します。基準点は、以下のように指定されています。
- User to Network Interfaces (UNIs) if they lie between the user or user network and the core network, or
- ネットワークインタフェース（UNIの）へのユーザそれらがユーザまたはユーザネットワークとコアネットワークの間にある場合、又は
- External Network to Network Interfaces (E-NNIs) if they lie between peer networks, network domains, or subnetworks.
- それらは、ピアネットワーク、ネットワークドメイン、またはサブネットワーク間にある場合、ネットワークインタフェース（E-のNNI）の外部ネットワーク。
GMPLS is applicable to the UNI and E-NNI without further modification, and no new messages, objects, or C-Types are required. See [OVERLAY].
GMPLSは、さらに変更を加えることなくUNIおよびE-NNIに適用可能であり、そして新しいメッセージ、オブジェクト、またはC-タイプは必要ありません。 [OVERLAY]を参照してください。
At the time of writing, MPLS and GMPLS are being extended by the MPLS and CCAMP Working Groups to support additional sophisticated functions. This will inevitably lead to the introduction of new C-Types for existing objects, and to the requirement for new objects (CNums). It is possible that new messages will also be introduced.
執筆時点では、MPLSとGMPLSは、追加の高度な機能をサポートするためにMPLSとCCAMPワーキンググループによって拡張されています。これは、必然的に、既存のオブジェクトのための新しいC-タイプの導入につながり、そして新しいオブジェクト（CNums）の要件になります。新しいメッセージも導入される可能性があります。
Some of the key features and functions being introduced include the following:
導入された主な機能と機能のいくつかは、次のものがあります。
- Protection and restoration. Features will be developed to provide - end-to-end protection - segment protection - various protection schemes (1+1, 1:1, 1:n) - support of extra traffic on backup LSPs - Diverse path establishment for protection and load sharing. - Establishment of point-to-multipoint paths. - Inter-area and inter-AS path establishment with - explicit path control - bandwidth reservation - path diversity - Support for the requirements of Automatic Switched Optical Network (ASON) signaling as defined by the ITU-T, including call and connection separation. - Crankback during LSP setup.
- 保護と回復。機能は提供するために開発される - エンドツーエンドの保護 - セグメント保護 - 各種保護スキーム（+ 1 1、1：1、1：N） - バックアップのLSP上の余分なトラフィックのサポート - 保護および負荷共有のための多様な経路設定。 - ポイント・ツー・マルチポイントパスの確立。 - インター領域とを有するインターASパス確立 - 明示的なパス制御 - 帯域予約 - パスダイバーシティ - 自動の要件をサポートするには、コールと接続分離を含む、ITU-Tによって定義されるようなシグナル光ネットワーク（ASON）のスイッチ。 - LSPのセットアップ中にクランクバック。
ITU-T H.323 ([H.323]) recommends the IntServ resource reservation procedure using RSVP. The information as to whether an endpoint supports RSVP should be conveyed during the H.245 [H.245] capability exchange phase, by setting appropriate qOSMode fields. If both endpoints are RSVP-capable, when opening an H.245 logical channel, a receiver port ID should be conveyed to the sender by the openLogicalChannelAck message. Only after that can a "Path - Resv - ResvConf" process take place. The timer of waiting for ResvConf message will be set by the endpoint. If this timer expires or RSVP reservation fails at any point during an H.323 call, the action is up to the vendor. Once a ResvConf message is sent or received, the endpoints should stop reservation timers and resume with the H.323 call procedures. Only explicit release of reservations are supported in [H.323]. Before sending a closeLogicalChannel message for a stream, a sender should send a PathTear message if an RSVP session has been previous created for that stream. After receiving a closeLogicalChannel, a receiver should send a ResvTear similarly. Only the FF style is supported, even for point-to-multipoint calls.
ITU-T H.323（[323]）は、RSVPを使用してのIntServリソース予約手順をお勧めします。エンドポイントがRSVPをサポートしているか否かの情報は、適切なqOSModeフィールドを設定することにより、H.245 [H.245]能力交換フェーズの間に搬送されなければなりません。両方のエンドポイントがRSVP対応である場合H.245論理チャネルを開くとき、受信ポートIDはopenLogicalChannelAckメッセージによって送信側に搬送されなければなりません。のみ、その後「パス - のResv - ResvConf」できるプロセスが行われます。 ResvConfメッセージを待っているのタイマーは、エンドポイントによって設定されます。このタイマーの期限が切れるか、RSVP予約がH.323通話中の任意の時点で失敗した場合、アクションはベンダー次第です。 ResvConfメッセージが送信または受信されると、エンドポイントは、予約タイマーを停止し、H.323コール手順に再開すべきです。予約の唯一の明示的なリリースでは、[H.323]でサポートされています。 RSVPセッションがそのストリームのために以前に作成されている場合は、ストリームのためcloseLogicalChannelメッセージを送信する前に、送信者はPathTearメッセージを送信する必要があります。 closeLogicalChannelを受信した後、受信機は、同様たResvTearを送信する必要があります。唯一のFFスタイルでも、ポイント・ツー・マルチポイントの呼び出しのために、サポートされています。
Third Generation Partnership Project (3GPP) TS 23.207 ([3GPP-TS23207]) specifies the QoS signaling procedure with policy control within the Universal Mobile Telecommunications System (UMTS) end-to-end QoS architecture. When using RSVP, the signaling source and/or destination are the User Equipments (UEs, devices that allow users access to network services) that locate in the Mobile
第三世代パートナーシッププロジェクト（3GPP）、TS 23.207は、（[3GPP-TS23207]）、ユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）、エンドツーエンドQoSアーキテクチャ内のポリシー制御と手順シグナリングQoSを指定します。 RSVPを使用する場合、シグナリング・ソース及び/又は宛先モバイルで見つけユーザ装置（UE、ユーザがネットワークサービスへのアクセスを可能にするデバイス）であります
Originating (MO) side and the Mobile Terminating (MT) side. An RSVP signaling process can either trigger or be triggered by the (COPS) PDP Context establishment/modification process. The operation of refreshing states is not specified in [3GPP-TS23207]. If a bidirectional reservation is needed, the RSVP signaling exchange must be performed twice between the end-points. The authorization token and flow identifier(s) in a policy data object should be included in the RSVP messages sent by the UE, if the token is available in the UE. When both RSVP and Service-based Local Policy are used, the Gateway GPRS Support Node (GGSN, the access point of the network) should use the policy information to decide whether to accept and forward Path/Resv messages.
発信（MO）側とモバイル終端（MT）側。 RSVPシグナリングプロセスは、トリガーまたは（COPS）によってトリガされるいずれかのPDPコンテキストの確立/変更処理することができます。リフレッシュ状態の動作は、[3GPP-TS23207]で指定されていません。双方向予約が必要な場合は、RSVPシグナリングの交換は、エンドポイント間に2回実施されなければなりません。トークンがUEに利用可能である場合、ポリシー・データ・オブジェクト内の許可トークン及びフロー識別子（単数または複数）は、UEによって送信されたRSVPメッセージに含まれるべきです。 RSVPとサービスベースのローカルポリシーの両方が使用される場合、ゲートウェイGPRSサポートノード（GGSN、ネットワークのアクセスポイントは）パス/ RESVメッセージを受け入れ、前進するかどうかを決定するために、ポリシー情報を使用する必要があります。
As a well-acknowledged protocol in the Internet, RSVP is expected more and more to provide a more generic service for various signaling applications. However, RSVP messages were designed in a way to support end-to-end QoS signaling optimally. To meet the increasing demand that a signaling protocol also operate in host-to-edge and edge-to-edge ways, and that it serve for some other signaling purposes in addition to end-to-end QoS signaling, RSVP needs to be made more flexible and applicable for more generic signaling.
インターネットではよく認めプロトコルとして、RSVPは、様々なシグナリングアプリケーションのためのより一般的なサービスを提供するために、ますます期待されています。ただし、RSVPメッセージを最適シグナリング・エンド・ツー・エンドのQoSをサポートするように設計されました。シグナリングプロトコルは、ホスト・エッジおよびエッジ・ツー・エッジの方法で動作増大する需要を満たすため、それはQoSシグナリングをエンドツーエンドに加えて、いくつかの他のシグナリングの目的のために役立つと、RSVPがなされる必要がありますより柔軟で、より汎用的なシグナリングのために適用。
RSVP proxies [BEGD02] extend RSVP by originating or receiving the RSVP message on behalf of the end node(s), so that applications may still benefit from reservations that are not truly end-to-end. However, there are certainly scenarios where an application would want to explicitly convey its non-QoS purposed (as well as QoS) data from a host into the network, or from an ingress node to an egress node of an administrative domain. It must do so without burdening the network with excess messaging overhead. Typical examples are an end host desiring a firewall service from its provider's network and MPLS label setup within an MPLS domain.
アプリケーションがまだ真にエンドツーエンドではない予約から利益を得ることができるように、RSVPプロキシは[BEGD02]、エンドノード（複数可）の代わりにRSVPメッセージを発信または受信することによって、RSVPを拡張します。しかし、ネットワークへのホストから、または管理ドメインの出口ノードへの入口ノードからのアプリケーションが明示的目的とその非QoSを伝えたいと思うのシナリオ（だけでなく、QoS）のデータは確かにあります。これは、過剰メッセージングオーバーヘッドでネットワークに負担をかけず、そうしなければなりません。典型的な例は、MPLSドメイン内のプロバイダのネットワークとMPLSラベルのセットアップからファイアウォールサービスを希望するエンドホストされています。
RSVP requires support from network routers and user space applications. Domains not supporting RSVP are traversed transparently. Unfortunately, like other IP options, RSVP messages implemented by way of IP alert option may be dropped by some routers [FJ02]. Although applications need to be built with RSVP libraries, one article presents a mechanism that would allow any host to benefit from RSVP mechanisms without applications' awareness [MHS02].
RSVPは、ネットワークルータとユーザ空間のアプリケーションからのサポートが必要です。 RSVPをサポートしていないドメインは透過的に横断しています。残念ながら、他のIPオプションのように、IPのアラートオプションの方法によって実装RSVPメッセージは、一部のルータ[FJ02]によって削除できます。アプリケーションは、RSVPライブラリで構築する必要がありますが、1品は、任意のホスト、アプリケーションの意識[MHS02]なしRSVPメカニズムから利益を得ることが可能になる仕組みを提示します。
A somewhat similar deployment benefit can be gained from the Localized RSVP (LRSVP) [JR03] [MSK+04]. The documents present the concept of local RSVP-based reservation that alone can be used to trigger reservation within an access network. In those cases, an end-host may request QoS from its own access network without the cooperation of a correspondent node outside the access network. This would be especially helpful when the correspondent node is unaware of RSVP. A proxy node responds to the messages sent by the end host and enables both upstream and downstream reservations. Furthermore, the scheme allows for faster reservation repairs following a handover by triggering the proxy to assist in an RSVP local repair.
幾分同様の展開の利点は、ローカライズされたRSVP（LRSVP）JR03] [MSK + 04]から得ることができます。書類だけでは、アクセスネットワーク内の予約をトリガするために使用することができますローカルRSVPベースの予約の概念を提示します。そのような場合、エンドホストは、アクセスネットワーク外部通信相手ノードの協力なしに、それ自身のアクセスネットワークからQoSを要求することができます。コレスポンデントノードは、RSVPを認識していない場合に特に有用であろう。プロキシノードは、エンドホストによって送信されたメッセージに応答し、上流および下流の両方の予約を可能にします。さらに、スキームは、RSVPローカル修復を補助するためにプロキシをトリガすることによって、ハンドオーバ以下速い予約修理を可能にします。
Still, in end-hosts that are low in processing power and functionality, having an RSVP daemon run and take care of the signaling may introduce unnecessary overhead. One article [Kars01] proposes to create a remote API so that the daemon would in fact run on the end-host's default router and the end-host application would send its requests to that daemon.
まだ、処理能力と機能が低いRSVPデーモンランを有し、不必要なオーバーヘッドを導入することができるシグナリングの世話をエンドホストです。一つの記事[Kars01]はデーモンが実際にそのデーモンにその要求を送信し、エンドホストのデフォルトルータとエンドホストアプリケーション上で実行されますように、リモートAPIを作成することを提案します。
Another potential problem lies in the limited size of signaled data due to the limitation of message size. An RSVP message must fit entirely into a single non-fragmented IP datagram. Bundle messages [RFC2961] can aggregate multiple RSVP messages within a single PDU, but they still only occupy one IP datagram (i.e., approximately 64K). If it exceeds the MTU, the datagram is fragmented by IP and reassembled at the recipient node.
別の潜在的な問題は、メッセージサイズの制限に起因するシグナリングデータの限られたサイズです。 RSVPメッセージは、単一の非断片化されたIPデータグラムに完全に適合しなければなりません。バンドルメッセージ[RFC2961]単一PDU内に複数のRSVPメッセージを集約し、それらは依然として1つのIPデータグラム（すなわち、約64K）を占めることができます。それがMTUを超えた場合、データグラムはIPによって断片化し、受信者ノードで再組み立てされます。
A good signaling protocol should be transparent to the applications. RSVP has proven to be a very well designed protocol. However, it has a number of fundamental protocol design issues that require more careful re-evaluation.
良いシグナリングプロトコルは、アプリケーションに対して透明であるべきです。 RSVPは非常によく設計されたプロトコルであることが証明されました。しかし、それはより慎重な再評価が必要な基本的なプロトコルの設計上の問題がいくつかあります。
The design of RSVP was originally targeted at multicast applications. The result has been that the message processing within nodes is somewhat heavy, mainly due to flow merging. Still, merging rules should not appear in the specification as they are QoS-specific.
RSVPの設計は、もともとマルチキャストアプリケーションをターゲットにしました。結果は、ノード内のメッセージ処理は、主に、合流流れに起因する多少重いことでした。彼らは、QoS固有のものとしてそれでも、マージルールは、仕様で表示されません。
RSVP has a comprehensive set of filtering styles, including Wildcard-Filter (WF), Fixed-Filter (FF), and Shared-Explicit (SE), and is not tied to certain QoS objects. (RSVP is not tied to IntServ Guaranteed Service/Controlled Load (GS/CL) specifications.) Objects were designed to be modular, but Xspecs (TSPEC, etc.) are more or less QoS-specific and should be more generalized; there is no clear layering/separation between the signaled data and signaling protocol.
RSVPは、ワイルドカード・フィルター（WF）、固定フィルター（FF）、および共有 - 明示的な（SE）を含むフィルタリングスタイルの包括的なセットを持っており、特定のQoSオブジェクトに関連付けられていません。 （。RSVPはIntServの保証サービス/負荷制御（GS / CL）の仕様に縛られていない）オブジェクトは、モジュール式になるように設計が、Xspecs（TSPECなど）は、多かれ少なかれのQoS固有であり、より一般化する必要がありました。シグナリングデータおよびシグナリングプロトコルの間には明確な階層化/分離が存在しません。
RSVP uses a soft state mechanism to maintain states and allows each node to define its own refresh timer. The protocol is also independent of underlying routing protocols. Still, in mobile networks the movement of the mobile nodes may not properly trigger a reservation refresh for the new path, and therefore a mobile node may be left without a reservation up to the length of the refresh timer.
RSVPは、状態を維持するためのソフト状態メカニズムを使用し、各ノードは、自身のリフレッシュタイマを定義することができます。プロトコルは、基礎となるルーティングプロトコルとは無関係です。依然として、モバイルネットワーク内のモバイルノードの移動が適切に新しいパスの予約の更新をトリガしないことがあり、したがって、モバイルノードは、リフレッシュタイマの長さまで予約することなく放置されてもよいです。
Furthermore, RSVP does not work properly with changing end-point identifiers; that is, if one of the IP addresses of a mobile node changes, the filters may not be able to identify the flow that had a reservation.
また、RSVPは、エンドポイント識別子を変更することで正常に動作しません。つまり、モバイルノードの変更のIPアドレスの1つが、フィルタが予約していたフローを識別することができないかもしれません。
From the security point of view, RSVP does provide the basic building blocks for deploying the protocol in various environments to protect its messages from forgery and modification. Hop-by-hop protection is provided. However, the current RSVP security mechanism does not provide non-repudiation and protection against message deletion; the two-way peer authentication and key management procedures are still missing.
セキュリティの観点から、RSVPは、偽造や変更からそのメッセージを保護するために、様々な環境でのプロトコルを展開するための基本的なビルディングブロックを提供します。ホップバイホップ保護が提供されます。しかし、現在のRSVPのセキュリティメカニズムは、否認防止およびメッセージの削除に対する保護を提供していません。双方向のピア認証と鍵管理手順がまだ不足しています。
Finally, since the publication of the RSVP standard, tens of extensions have emerged that allow for much wider deployment than RSVP was originally designed for -- for instance, the Subnet Bandwidth Manager, the NULL service type, aggregation, operation over tunneling, and MPLS, as well as diagnostic messages.
最後に、RSVP標準の出版以来、拡張子の数十は、RSVPが最初に設計されていたよりもはるかに広い展開を可能とすることが明らかになってきたために - たとえば、サブネット帯域幅マネージャー、トンネル経由NULLサービスタイプ、集計、操作、およびMPLS 、ならびに診断メッセージ。
Domains not supporting RSVP are traversed transparently by default. Unfortunately, like other IP options, RSVP messages implemented by way of IP alert option may be dropped by some routers. Also, the maximal size of RSVP message is limited.
RSVPをサポートしていないドメインがデフォルトで透過的に横断しています。残念ながら、他のIPオプションのように、IPのアラートオプションの方法によって実装RSVPメッセージは、一部のルータによって廃棄されることがあります。また、RSVPメッセージの最大サイズが制限されています。
The transport mechanisms, performance, security, and mobility issues are detailed in the following sections.
トランスポートメカニズム、パフォーマンス、セキュリティ、およびモビリティの問題は、次のセクションで詳しく説明されています。
RSVP messages are defined as a new IP protocol (that is, a new ptype in the IP header). RSVP Path messages must be delivered end-to-end. For the transit routers to intercept the Path messages, a new IP Router Alert option [RFC2113] was introduced. This design is simple to implement and efficient to run. As shown from the experiments in [PS00], with minor kernel changes IP option processing introduces very little overhead on a Free BSD box.
RSVPメッセージは新しいIPプロトコルとして定義される（つまり、IPヘッダ内の新しいp型）。 RSVP Pathメッセージは、エンドツーエンドを提供する必要があります。中継ルータがPathメッセージを傍受するために、新しいIPルータアラートオプション[RFC2113]は導入されました。この設計は、実装が簡単で、実行するのが効率的です。 [PS00]での実験から示されているように、マイナーカーネルでIPオプションの処理は、フリーBSDボックスに非常にわずかなオーバーヘッドが生じ変更します。
However, RSVP does not have a good message delivery mechanism. If a message is lost on the wire, the next re-transmit cycle by the network would be one soft-state refresh interval later. By default, a soft-state refresh interval is 30 seconds.
しかし、RSVPは良いメッセージ配信のメカニズムを持っていません。メッセージがワイヤ上に失われた場合、ネットワークによる次の再送信サイクルは、後つのソフトステートリフレッシュ間隔であろう。デフォルトでは、ソフトステートリフレッシュ間隔は30秒です。
To overcome this problem, [PS97] introduced a staged refresh timer mechanism, which has been defined as a RSVP extension in [RFC2961]. The staged refresh timer mechanism retransmits RSVP messages until the receiving node acknowledges. It can address the reliability problem in RSVP.
この問題を克服するために、[PS97]は[RFC2961]でRSVPの拡張として定義されている段階的なリフレッシュタイマメカニズムを導入しました。受信ノードが応答するまで、段階的リフレッシュタイマーメカニズムは、RSVPメッセージを再送信します。これは、RSVPで信頼性の問題に対処することができます。
However, during the mechanism's implementation, a lot of effort had to be spent on per-session timer maintenance, message retransmission (e.g., avoid message bursts), and message sequencing. In addition, we have to make an effort to try to separate the transport functions from protocol processing. For example, if a protocol extension requires a natural RSVP session time-out (such as RSVP-TE one-to-one fast-reroute [FAST-REROUTE]), we have to turn off the staged refresh timers.
しかし、メカニズムの実装の際に、多くの労力は、セッションごとのタイマーメンテナンス、メッセージの再送（例えば、メッセージバーストを避けるため）、およびメッセージの順序に費やさなければなりませんでした。また、当社は、プロトコル処理からの輸送機能を分離しようとする努力をしなければなりません。たとえば、プロトコル拡張は、自然RSVPセッションタイムアウト必要とする場合（例えばRSVP-TEなどを一対一高速リルート[FAST-REROUTE]）、私たちが上演リフレッシュタイマーをオフにする必要があります。
According to RSVP [RFC2205], each RSVP message can only contain information for one session. In a network that has a reasonably large number of RSVP sessions, this constraint imposes a heavy processing burden on the routers. Many router OSes are based on UNIX. [PS00] showed that the UNIX socket I/O processing is not very sensitive to packet size. In fact, processing small packets takes almost as much CPU overhead as processing large ones. However, processing too many individual messages can easily cause congestion at socket I/O interfaces.
RSVP [RFC2205]によれば、各RSVPメッセージは、一つのセッションのための情報を含むことができます。 RSVPセッションの合理的に数が多いネットワークでは、この制約は、ルータ上の重い処理負担を課します。多くのルータのOSはUNIXをベースにしています。 [PS00]はUNIXソケットのI / O処理は、パケットサイズに非常に敏感ではないことを示しました。実際には、小さなパケットを処理する大規模なものを処理するのと同じくらい多くのCPUオーバーヘッドがかかります。しかし、処理あまりにも多くの個々のメッセージを簡単にソケットI / Oインタフェースで輻輳が発生する可能性があります。
To overcome this problem, RFC2961 introduced the message bundling mechanism. The bundling mechanism packs multiple RSVP messages between two adjacent nodes into a single packet. In one deployed router platform, the bundling mechanism has improved the number of RSVP sessions that a router can handle from 2,000 to over 7,000.
この問題を克服するために、RFC2961は、メカニズムを束ねるメッセージを導入しました。バンドリング機構は、単一のパケットに2つの隣接ノード間の複数のRSVPメッセージをパック。 1つの展開ルータプラットフォームでは、同梱のメカニズムは、ルータが2,000から7,000以上に扱うことができるRSVPセッションの数を向上させました。
RSVP does not support message fragmentation and reassembly at protocol level. If the size of a RSVP message is larger than the link MTU, the message will be fragmented. The routers simply cannot detect and process RSVP message fragments.
RSVPは、プロトコルレベルでメッセージの断片化と再アセンブリをサポートしていません。 RSVPメッセージのサイズがリンクMTUよりも大きい場合、メッセージは断片化されます。ルータは単にRSVPメッセージ断片を検出し、処理することはできません。
There is no solution for the MTU problem. Fortunately, at places where RSVP-TE has been used, either the amount of per-session RSVP data is never too large, or the link MTU is adjustable; PPP and Frame Relay can always increase or decrease the MTU sizes. For example, on some routers, a Frame Relay interface can support a link MTU size up to 9600 bytes. Currently, the RSVP MTU problem is not a realistic concern in MPLS networks.
MTUの問題の解決策はありません。幸いなことに、RSVP-TEが使用されている、いずれかのセッションごとのRSVPデータの量が多すぎることはありません、またはリンクMTUが調整可能である場所で。 PPPとフレームリレーは常にMTUサイズを増減することができます。例えば、一部のルータで、フレームリレーインターフェイスは、9600のバイトへのリンクのMTUサイズアップをサポートすることができます。現在、RSVP MTUの問題は、MPLSネットワークにおける現実的な問題ではありません。
However, when and if RSVP is used for end-user applications, for which network security is an essential and critical concern, it is possible that the size of RSVP messages can be larger than the link MTU. Note that end-users will most likely have to deal with a small 1500-byte Ethernet MTU.
しかし、いつ、RSVPは、ネットワークセキュリティが不可欠と重要な関心事であるため、エンドユーザーの用途に使用されている場合、RSVPメッセージのサイズがリンクMTUよりも大きくすることが可能です。エンドユーザーが最も可能性の高い小型の1500バイトイーサネットのMTUに対処する必要があることに注意してください。
RSVP-TE works in an environment that is different from what the original RSVP has been designed for: in MPLS networks, the RSVP sessions that are used to support Label-Switched Paths (LSPs) do not change frequently.
MPLSネットワークでは、ラベルスイッチパス（LSPを）サポートするために使用されているRSVPセッションは、頻繁に変更されません：RSVP-TEは、元のRSVPはのために設計されたものと異なる環境で動作します。
In fact, the network operators typically set up the MPLS LSPs so that they cannot switch too quickly. For example, the operators often regulate the Constraint-based Shortest Path First (CSPF) computation interval to prevent or delay a large volume of user traffic from shifting from one session to another during LSP path optimization. (CSPF is a routing algorithm that operates from the network edge to compute the "most" optimal routes for the LSPs.) As a result, RSVP-TE does not have to handle a large amount of "triggered" (new or modified) messages. Most of the messages are refresh messages, which can be handled by the mechanisms introduced in RFC2961. In particular, in the Summary Refresh extension [RFC2961], each RSVP refresh message can be represented as a 4-byte ID. The routers can simply exchange the IDs to refresh RSVP sessions. With the full implementation of RFC2961, MPLS routers do not have any RSVP scaling issue. On one deployed router platform, it can support over 50,000 RSVP sessions in a stable backbone network.
彼らはあまりにも素早く切り替えることができないように、実際には、ネットワークオペレータは、通常のMPLS LSPを設定します。例えば、オペレータは、多くの場合、最初のLSPパスの最適化の間に別のセッションからずれるユーザトラフィックの大容量を予防または遅延させる（CSPF）計算間隔制約ベースの最短パスを調節します。 （CSPFはLSPsのための「最も」最適なルートを計算するために、ネットワークのエッジで動作するルーティング・アルゴリズムである。）その結果、RSVP-TEは、（新しいまたは変更された）メッセージ、「トリガ」を大量に処理する必要がありません。メッセージのほとんどは、RFC2961で導入されたメカニズムによって処理することができリフレッシュメッセージです。具体的には、サマリーリフレッシュ拡張[RFC2961]に、各RSVPリフレッシュメッセージは、4バイトのIDとして表すことができます。ルータは単にRSVPセッションをリフレッシュするためのIDを交換することができます。 RFC2961の完全な実装では、MPLSルータは、任意のRSVPスケーリングの問題を持っていません。 1つの展開ルータプラットフォームでは、安定したバックボーンネットワークで50,000以上のRSVPセッションをサポートすることができます。
On the other hand, in many of the new applications for which a signaling protocol is required, the user session duration can be relatively short. The dynamics of adding/dropping user sessions could introduce a large number of "triggered" messages in the network. This can clearly introduce a substantial amount of processing overhead to the routers. This is one area where a new signaling protocol may be needed to reduce the processing complexity in the resource reservation process.
一方、シグナリングプロトコルが必要とされる新たなアプリケーションの多くでは、ユーザセッション持続時間が比較的短くすることができます。追加/削除するユーザーセッションのダイナミクスは、ネットワーク内の「引き金」多数のメッセージをもたらす可能性があります。これは明らかに、ルータに処理オーバーヘッドのかなりの量を導入することができます。これは、新しいシグナリングプロトコルは、リソース予約処理における処理の複雑さを低減するために必要とされ得る1つの領域です。
A good signaling protocol should be transparent to the applications. On the other hand, the design of a signaling protocol must take the intended and potential applications into consideration.
良いシグナリングプロトコルは、アプリケーションに対して透明であるべきです。一方、シグナリングプロトコルの設計を考慮に意図して潜在的なアプリケーションを取る必要があります。
With the addition of RFC2961, RSVP-TE is sufficient to support its intended application, MPLS, within the backbone. There is no significant transport-layer problem that needs to be solved.
RFC2961の追加により、RSVP-TEは、バックボーン内、MPLS、その意図したアプリケーションをサポートするのに十分です。解決すべき有意なトランスポート層の問題はありません。
In the last several years, a number of new applications have emerged that are proposed to need IP signaling, beyond the traditional ones associated with quality of service and resource allocation. On-path firewall control/NAT traversal (synergistic with the midcom design of [RFC3303]) is one of these. There are far-out applications such as depositing active network code in network devices. Next-generation signaling protocols dealing with novel applications, with network security requirements, and with the MTU problems described above, will prevent the re-use of the existing RSVP transport mechanism.
ここ数年では、新しいアプリケーションの数は、サービスやリソース割り当ての品質に関連した伝統的なものを超えて、IPシグナリングを必要とするために提案されている浮上しています。オンパスファイアウォール制御/ NATトラバーサル（[RFC3303]のMIDCOM設計との相乗）は、これらの一つです。そのようなネットワーク・デバイスでアクティブなネットワークコードを堆積限りアウトのアプリケーションがあります。ネットワークセキュリティ要件に、上述したMTUの問題を有する新規なアプリケーションを扱う次世代シグナリングプロトコルは、既存のRSVP搬送機構の再使用を防止します。
If a new transport protocol is needed, the protocol must be able to handle the following:
新しいトランスポートプロトコルが必要な場合、プロトコルは、次のように扱うことができなければなりません。
- reliable messaging;
- 信頼性の高いメッセージング。
- message packing;
- メッセージ梱包。
- the MTU problem;
- MTUの問題。
- small triggered message volume.
- 小トリガメッセージボリューム。
By "processing overhead" we mean the amount of processing required to handle messages belonging to a reservation session. This is the processing required in addition to the processing needed for routing an (ordinary) IP packet. The processing overhead of RSVP originates from two major issues:
「処理のオーバーヘッド」とは、予約セッションに属するメッセージを処理するために必要な処理量を意味します。これは、（通常の）IPパケットをルーティングするために必要な処理に加えて、必要な処理です。 RSVPの処理オーバーヘッドは、2つの主要な問題に由来します：
1) Complexity of the protocol elements. First, RSVP itself is per-flow based; thus the number of states is proportional to RSVP session number. Path and Resv states have to be maintained in each RSVP router for each session (and Path state also has to record the reverse route for the correspondent Resv message). Second, being receiver-initiated, RSVP optimizes various merging operations for multicast reservations while the Resv message is processed. To handle multicast, other mechanisms such as reservation styles, scope object, and blockade state, are also required to be presented in the basic protocol. This not only adds sources of failures and errors, but also complicates the state machine [Fu02]. Third, the same RSVP signaling messages are used not only for maintaining the state, but also for dealing with recovery of signaling message loss and discovery of route change. Thus, although protocol elements that represent the actual data (e.g., QoS parameters) specification are separated from signaling elements, the processing overhead needed for all RSVP messages is not marginal. Finally, the possible variations of the order and existence of objects increases the complexity of message parsing and internal message and state representation.
プロトコル要素の1）複雑。まず、自身がフロー毎ベースでRSVP。これ状態の数は、RSVPセッションの数に比例しています。パスとのResv状態は、各セッションの各RSVPルータで維持されなければならない（とパス状態も対応Resvメッセージのための逆のルートを記録しなければなりません）。 Resvメッセージが処理される間に、第2、受信器で開始され、RSVPは、マルチキャスト予約のための様々なマージオペレーションを最適化します。マルチキャストを処理するために、そのような予約スタイル、スコープオブジェクト、及び封鎖状態のような他のメカニズムは、また、基本的なプロトコルに提示する必要があります。これは失敗し、エラーの発生源を追加するだけでなく、ステートマシン[Fu02]を複雑にするだけでなく。第三には、同じRSVPシグナリングメッセージは、状態を維持するために、だけでなく、ルート変更のメッセージの損失や発見を、シグナリングの回復に対応するためだけでなく、使用されています。したがって、実際のデータを表すプロトコル要素が（例えば、QoSパラメータ）仕様シグナリング要素から分離される、すべてのRSVPメッセージのために必要な処理オーバーヘッドが限界ではありません。最後に、オブジェクトの順序と存在の可能な変形は、メッセージ解析および内部メッセージと状態表現の複雑さを増大させます。
2) Implementation-specific Overhead. There are two ways to send and receive RSVP messages: either as "raw" IP datagrams with protocol number 46, or as encapsulated UDP datagrams, which increase the efficiency of RSVP processing. Typical RSVP implementations are user-space daemons interacting with the kernel; thus, state management, message sending, and reception would affect the efficiency of the protocol processing. For example, in the recent version of the implementation described in [KSS01], the relative execution costs for the message sending/reception system calls "sendto", "select", and "recvmsg" were 14-16%, 6-7%, 9-10%, individually, of the total execution cost. [KSS01] also found that state (memory) management can use up to 17-18% of the total execution cost, but it is possible to decrease that cost to 6-7%, if appropriate action is taken to replace the standard memory management with dedicated memory management for state information. RSVP/routing, RSVP/policy control, and RSVP/traffic control interfaces can also pose different overhead depending on implementation. For example, the RSVP/routing overhead has been measured to be approximately 11-12% of the total execution cost [KSS01].
2）実装固有のオーバーヘッド。プロトコル番号46を持つ「生の」IPデータグラムとして、またはRSVP処理の効率を向上させるカプセル化されたUDPデータグラムとして、次のいずれかのRSVPメッセージを送受信するには、2つの方法があります。典型的なRSVPの実装は、カーネルと相互作用するユーザ空間のデーモンです。従って、状態管理は、メッセージ送信、及び受信プロトコル処理の効率に影響を与えます。例えば、[KSS01]に記載の実施の最近のバージョンでは、メッセージ送信/受信システムは、「SendTo」を呼び出し、「選択」、および「のrecvmsg」の相対実行コストは14から16パーセント6-7％でした9-10％個別に、総執行費用の。 【KSS01】また状態（メモリ）管理は、総執行費用の17から18パーセントまで使用することができることを見出し、適切なアクションが標準的なメモリ管理を交換するために取られた場合6-7％とそのコストを低減することができます状態情報用の専用のメモリ管理と。 RSVP /ルーティング、RSVP /ポリシー制御、およびRSVP /トラフィック制御インタフェースも実装に応じて異なるオーバーヘッドをもたらすことができます。例えば、RSVP /ルーティングオーバーヘッドは総執行費用[KSS01]の約11から12パーセントであると測定されました。
By "bandwidth consumption" we mean the amount of bandwidth used during the lifetime of a session: to set up a reservation session, to keep the session alive, and finally to close it.
セッションを存続するために、そして最終的にそれを閉じるには、予約セッションを設定するには：「帯域幅の消費」とは、セッションの存続期間中に使用される帯域幅の量を意味します。
RSVP messages are sent either to trigger a new reservation or to refresh an existing reservation. In standard RSVP, Path/Resv messages are used for triggering and refreshing/recovering reservations, identically, which results in an increased size of refresh messages. The hop-by-hop refreshment may reduce the bandwidth consumption for RSVP, but could result in more sources of error/failure events. [RFC2961] presents a way to bundle standard RSVP messages and reduces the refreshment redundancy by Srefresh message.
RSVPメッセージは、新しい予約をトリガするか、既存の予約をリフレッシュするか送信されます。標準のRSVPでは、パス/ RESVメッセージは、リフレッシュメッセージの大型化、その結果、同様に、トリガーとさわやか/予約を回収するために使用されています。ホップバイホップリフレッシュはRSVPのための帯域幅の消費を減らすことができるが、エラー/失敗イベントの複数のソースにつながる可能性があります。 [RFC2961]は、標準のRSVPメッセージをバンドルする方法を提示し、Srefreshメッセージでリフレッシュ冗長性を低減します。
Thus, the following formula represents the bandwidth consumption in bytes for an RSVP session lasting n seconds:
したがって、以下の式がn秒持続RSVPセッションのバイト単位の帯域幅の消費を表します。
F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt
F（N）=（BP + BR）+（（N / RI）*（BP + BR））+ BPT
bP: IP payload size of Path message bR: IP payload size of Resv message bPt: IP payload size of Path Tear message Ri: refresh interval
BP：IP PathメッセージのbRのペイロードサイズ：ResvメッセージBPTのIPペイロードサイズ：パス涙メッセージ里IPペイロードサイズ：リフレッシュ間隔
For example, for a simple Controlled Load reservation without security and identification requirements (where bP is 172 bytes, bR is 92, bPt is 44 bytes, and Ri is 30 seconds), the bandwidth consumption would be as follows:
例えば、セキュリティおよび識別要件のない単純な制御されたロード予約のため（BPが172バイトであり、BRがBPTが44バイトであり、92であり、そしてRは30秒）以下のように帯域幅の消費は次のようになり、。
F(n) = (172 + 92) + ((n/30) * (172 + 92)) + 44
F（N）=（172 + 92）+（（N / 30）*（172 + 92））+ 44
= 308 + (264n/30) bytes
= 308 +（264n / 30）バイト
To allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and to convey this information in RSVP messages (PATH or RESV) in a secure manner, [RFC3182] specifies the encoding of identities as RSVP POLICY_DATA Object. However, to provide ironclad security protection, cryptographic authentication combined with authorization has to be provided. Such a functionality is typically offered by authentication and key exchange protocols. Solely including a user identifier is insufficient.
システム上のプロセスを確実に所有者と通信処理（例えば、ユーザID）のアプリケーションを識別し、安全な方法でRSVPメッセージ（PATHまたはRESV）にこの情報を伝えることができるように、[RFC3182]はのエンコーディングを指定しますRSVP POLICY_DATAオブジェクトとしてのアイデンティティ。しかし、鉄壁のセキュリティ保護を提供するために、認証と組み合わせて暗号化認証を提供する必要があります。このような機能は通常、認証と鍵交換プロトコルによって提供されています。単にユーザ識別子が不十分であるなど。
To provide hop-by-hop integrity and authentication of RSVP messages, an RSVP message may contain an INTEGRITY object ([RFC2747]) using a keyed message digest. Since intermediate routers need to modify and process the content of the signaling message, a hop-by-hop security architecture based on a chain-of-trust is used. However, with the different usage of RSVP as described throughout this document and with new requirements, a re-evaluation of the original assumptions might be necessary.
RSVPメッセージのホップバイホップ完全性及び認証を提供するために、RSVPメッセージは、鍵付きメッセージダイジェストを使用して完全性オブジェクト（[RFC2747]）を含んでいてもよいです。中間ルータは、シグナリングメッセージの内容を変更して処理する必要があるため、チェーンの信頼に基づいてホップバイホップセキュリティアーキテクチャが使用されます。しかし、この文書を通して、新たな要件に説明するようにRSVPの異なる使用して、オリジナルの仮定の再評価が必要になる場合があります。
RFC2747 provides protection against forgery and message modification. However, this does not provide non-repudiation or protect against message deletion. In the current RSVP security scheme, the two-way peer authentication and key management procedures are still missing.
RFC2747は、偽造やメッセージの変更に対する保護を提供します。しかし、これは、否認防止を提供したり、メッセージの削除を防ぐことはできません。現在のRSVPのセキュリティ方式では、双方向のピア認証と鍵管理手順がまだ不足しています。
The security issues have been well analyzed in [Tsch03].
セキュリティ上の問題はよく[Tsch03]で分析されています。
Two issues raise concern when a mobile node (MN) uses RSVP: the flow identifier and reservation refresh. When an MN changes locations, it may need to change one of its assigned IP addresses. An MN may have an IP address by which it is reachable by nodes outside the access network, and an IP address used to support local mobility management. Depending on the mobility management mechanism, a handover may force a change in any of these addresses. As a consequence, the filters associated with a reservation may not identify the flow anymore, and the resource reservation is ineffective until a refresh with a new set of filters is initialized.
フロー識別子と予約リフレッシュ：モバイルノード（MN）がRSVPを使用する場合、2つの問題が懸念を提起します。 MNは、場所を変更すると、それは、その割り当てられたIPアドレスの1つを変更する必要があります。 MNは、アクセスネットワーク外のノードから到達可能であることにより、IPアドレス、およびローカルモビリティ管理をサポートするために使用されるIPアドレスを持つことができます。モビリティ管理メカニズムに応じて、ハンドオーバは、これらのアドレスのいずれかの変更を強制することがあります。その結果、予約に関連したフィルタは、もはやフローを識別できず、フィルターの新しいセットとリフレッシュが初期化されるまで、リソース予約は無効です。
The second issue relates to following the movement of a mobile node. RFC2205 defines that Path messages can perform a local repair of reservation paths. When the route between the communicating end hosts changes, a Path message will set the state of the reservation on the new route, and a subsequent Resv message will make the resource reservation. Therefore, by sending a Resv message a host cannot alone update the reservation, and thus it cannot perform a local repair before a Path message has passed. Also, in order to provide fast adaptation to routing changes without the overhead of short refresh periods, the local routing protocol module can notify the RSVP process of route changes for particular destinations. The RSVP process should use this information to trigger a quick refresh of state for these destinations, using the new route (Section 3.6, [RFC2205]). However, not all local mobility protocols affect routing directly in routers (not even Mobile IP), and thus mobility may not be noticed at RSVP routers. Therefore, it may take a relatively long time before a reservation is refreshed following a handover.
第二の問題は、移動ノードの移動を以下に関します。 RFC2205は、Pathメッセージは、予約パスの局所的な修復を実行できることを定義します。通信端部との間の経路変更をホストする場合、Pathメッセージは、新しい経路上の予約の状態を設定し、その後のResvメッセージは、リソース予約を行います。そのため、Resvメッセージを送信することにより、ホストは、一人で予約を更新することはできませんし、Pathメッセージが経過する前に、これは地元の修復を実行することはできません。また、短いリフレッシュ周期のオーバーヘッドなしに変更をルーティングする高速適応を提供するために、ローカルルーティングプロトコルモジュールは、特定の宛先のルート変更のRSVPプロセスに通知することができます。 RSVPプロセスは、新たなルート（セクション3.6、[RFC2205]）を使用して、これらの宛先の状態の迅速な更新をトリガするために、この情報を使用する必要があります。ただし、すべてのローカルモビリティプロトコルは、ルータ（いなくても、モバイルIP）に直接ルーティングに影響するため、移動度がRSVPルータで気づいたことがないかもしれません。予約がハンドオーバ以下リフレッシュされる前に、したがって、それは比較的長い時間がかかることがあります。
There have been several designs for extensions to RSVP to allow for more seamless mobility. One solution is presented in [MSK+04], in which one section discusses the coupling of RSVP and the mobility management mechanisms and proposes small extensions to RSVP to handle the handover event better, among other things. The extension allows the mobile host to request a Path for the downstream reservation when a handover has happened.
よりシームレスなモビリティを可能にするためにRSVPへの拡張機能のためにいくつかのデザインがありました。一つの解決策は、一つのセクションは、RSVPとモビリティ管理メカニズムのカップリングを説明し、とりわけ、より良好なハンドオーバイベントを処理するためにRSVPに小さな拡張を提案する、[MSK + 04]に提示されています。拡張子は、ハンドオーバーが起こったときに、モバイルホストは、下流の予約のためのパスを要求することができます。
Another example is Mobile RSVP (MRSVP) [TBA01], which is an extension to standard RSVP. It is based on advance reservations, where neighboring access points keep resources reserved for mobile nodes moving to their coverage area. When a mobile node requests resources, the neighboring access points are checked, too, and a passive reservation is done around the mobile nodes' current location.
別の例は、標準的なRSVPの拡張された移動RSVP（MRSVP）TBA01]、です。これは、近隣のアクセスポイントは、そのカバレージエリアに移動する移動ノードのために予約しておくリソースを保つ事前予約に基づいています。モバイルノードがリソースを要求すると、近隣のアクセスポイントは、あまりにも、チェックされ、そして受動予約は、移動ノードの現在の位置の周りに行われます。
The problem with the various "advance reservation" schemes is that they require topological information of the access network and, usually, advance knowledge of the handover event. Furthermore, the way the resources reserved in advance are used in the neighboring service areas is an open issue. A good overview of these different schemes can be found in [MA01].
様々な「事前予約」制度の問題点は、アクセスネットワークのトポロジ情報と、ハンドオーバイベントの通常、事前知識を必要とすることです。さらに、事前に予約されたリソースが隣接サービスエリアで使用されている方法は、未解決の問題です。これらの異なる方式の優れた概要は、[MA01]で見つけることができます。
The interactions of RSVP and Mobile IP have been well documented in [Thom02].
RSVPとモバイルIPの相互作用がうまく[Thom02]に記載されています。
Tenet and ST-II are two original QoS signaling protocols for the Internet.
テネットとST-IIは、インターネットのためのシグナリングプロトコル2つの元のQoSです。
In the original Tenet architecture [BFM+96], the receiver sends a reservation request toward the source. Each network node along the way makes the reservation. Once the request arrives at the source, the source sends another Relax message back toward to the receiver, and has the option to modify the previous reservation at each node.
オリジナルテネットアーキテクチャ[BFM + 96]において、受信機は、ソースに向かって予約要求を送信します。道に沿って各ネットワーク・ノードは、予約を行います。要求元に到着すると、ソースは別のバック受信機に向けてメッセージをリラックス送信し、各ノードで、前の予約を変更するオプションを有しています。
ST-II [RFC1819] basically works in the following way: a sender originates a Connect message to a set of receivers. Each intermediate node determines the next hop subnets, and makes reservations on the links going to these next hops. Upon receiving a Connect indication, a receiver must send back either an Accept or a Refuse message to the sender. In the case of an Accept, the receiver may further reduce the resource request by updating the returned flow specifications.
ST-II [RFC1819]は、基本的に以下のように動作する：送信者が受信機のセットにConnectメッセージを発信します。各中間ノードは、次のホップのサブネットを決定し、これらの次のホップに行くのリンク上で予約を行います。接続指示を受信すると、受信機は、そのまま使用するか、送信者を拒否するメッセージのいずれか返送しなければなりません。同意の場合、受信機は、さらに、返さフロー仕様を更新することにより、リソース要求を低減することができます。
ST-II consists of two protocols: ST for the data transport and the Stream Control Message Protocol (SCMP) for all control functions. ST is simple and contains only a single PDU format, which is designed for fast and efficient data forwarding in order to achieve low communication delays. SCMP packets are transferred within ST packets.
すべての制御機能のためのデータ転送のためのSTおよびストリーム制御メッセージプロトコル（SCMP）：ST-IIは、2つのプロトコルから成ります。 STは、単純であり、低通信遅延を達成するために迅速かつ効率的なデータ転送のために設計された単一のPDUフォーマットを含んでいます。 SCMPパケットはSTパケット内で転送されます。
ST-II has no built-in soft states; thus, it requires that the network be responsible for correctness. It is sender-initiated, and the overhead for ST-II to handle group membership dynamics is higher than that for RSVP [MESZ94]. ST-II does not provide security, but [RFC1819] describes some objects related to charging.
ST-IIには内蔵のソフトの状態を持っていません。したがって、それは、ネットワークが正確に責任があることが必要です。これは、送信者によって開始され、ST-IIは、グループメンバーシップのダイナミクスを処理するためのオーバーヘッドは[MESZ94] RSVPのそれよりも高いです。 ST-IIは、セキュリティを提供しませんが、[RFC1819]は充電に関連するいくつかのオブジェクトについて説明します。
YESSIR (YEt another Sender Session Internet Reservations) [PS98] is a resource reservation protocol that seeks to simplify the process of establishing reserved flows while preserving many unique features introduced in RSVP. Simplicity is measured in terms of control message processing, data packet processing, and user-level flexibility. Features such as robustness, advertising network service availability, and resource sharing among multiple senders are also supported in the proposal.
YESSIR（さらに別のセンダセッションインターネット予約）[PS98]はRSVPに導入され、多くのユニークな特徴を維持しながら、予約フローを確立するプロセスを簡素化しようとする資源予約プロトコルです。簡潔には、制御メッセージ処理、データパケット処理、及びユーザレベルの柔軟性の点で測定されます。このよう堅牢性、広告ネットワークサービスの可用性、および複数の送信者間でのリソース共有などの機能も提案でサポートされています。
The proposed mechanism generates reservation requests by senders to reduce the processing overhead. It is built as an extension to the Real-Time Transport Control Protocol (RTCP), taking advantage of Real-Time Protocol (RTP). YESSIR also introduces a concept called partial reservation, in which, for certain types of applications, the reservation requests can be passed to the next hop, even though there are not enough resources on a local node. The local node can rely on optimized retries to complete the reservations.
提案されたメカニズムは、処理オーバーヘッドを減らすために送信者によって予約要求を生成します。これは、リアルタイムプロトコル（RTP）を利用して、リアルタイムトランスポート制御プロトコル（RTCP）の拡張として構築されています。 YESSIRも部分予約呼ばれる概念を導入し、ここで、アプリケーションの特定の種類のため、予約要求は、十分なリソースがローカル・ノードに存在しなくても、次のホップに渡すことができます。ローカル・ノードは、予約を完了するために最適化された再試行回数に依存することができます。
YESSIR [PS98] was designed for one-way, sender-initiated end-to-end resource reservation. It also uses soft state to maintain states. It supports resource query (similar to RSVP diagnosis message), advertising (similar to RSVP ADSPEC), shared reservation, partial reservations, and flow merging.
YESSIR [PS98]は片道、送信者が開始したエンド・ツー・エンドのリソース予約のために設計されました。また、状態を維持するために柔らかい状態を使用しています。これは、リソース（診断メッセージをRSVPと同様）、クエリ（ADSPECをRSVPと同様）、広告、共有予約、部分的な予約、およびマージ流れをサポートしています。
To support multicast, YESSIR simplifies the reservation styles to individual and shared reservation styles. Individual reservations are made separately for each sender, whereas shared reservations allocate resources that can be used by all senders in an RTP session. Although RSVP supports shared reservation (SE and WF styles) from the receiver's direction, YESSIR handles the shared reservation style from the sender's direction; thus, new receivers can re-use the existing reservation of the previous sender.
マルチキャストをサポートするために、YESSIRは個人と共有の予約スタイルに予約スタイルを簡素化します。共有の予約がRTPセッションですべての送信者によって使用されることができるリソースを割り当てる一方、個々の予約は、各送信者に対して別々に行われます。 RSVPは、受信機の方向から共有の予約（SEとWFスタイル）をサポートしていますが、YESSIRは、送信者の方向からの共有の予約スタイルを扱います。したがって、新しい受信機は、以前の送信者の既存の予約を再使用することができます。
It has been shown that the YESSIR one-pass reservation model has better performance and lower processing cost than a regular two-way signaling protocol, such as RSVP [PS98]. The bandwidth consumption of YESSIR is somewhat lower than that of, for example, RSVP, because it does not require additional IP and transport headers. Bandwidth consumption is limited to the extension header size.
YESSIRワンパス予約モデルは、RSVPのような規則的な双方向のシグナリングプロトコル、[PS98]よりも高いパフォーマンスとより低い処理コストを有することが示されています。それは、追加のIPおよびトランスポートヘッダを必要としないためYESSIRの帯域幅の消費量は、例えば、RSVPのそれよりもやや低くなっています。帯域幅の消費は、拡張ヘッダのサイズに制限されます。
YESSIR does not have any particular support for mobility, and the security of YESSIR relies on RTP/RTCP security measures.
YESSIRは、モビリティのための特定のサポートを持っていない、とYESSIRのセキュリティは、RTP / RTCPセキュリティ対策に依存しています。
YESSIR requires support in applications since it is an integral part of RTCP. Similarly, it requires network routers to inspect RTCP packets to identify reservation requests and refreshes. Routers unaware of YESSIR forward the RTCP packets transparently.
それはRTCPの不可欠な部分であるため、YESSIRは、アプリケーションでのサポートが必要です。同様に、予約要求とリフレッシュを識別するために、RTCPパケットを検査するネットワークルータを必要とします。気づかないYESSIRのルータは透過的にRTCPパケットを転送します。
Boomerang [FNM+99] is a another resource reservation protocol for IP networks. The protocol has only one message type and a single signaling loop for reservation setup and teardown, and it has no requirements on the far end node. Instead, it concentrates the intelligence in the Initiating Node (IN).
ブーメラン[FNM + 99] IPネットワークの他のリソース予約プロトコルです。プロトコルは、1つのメッセージタイプ及び予約セットアップおよびティアダウンのための単一のシグナリング・ループを有し、それは、遠端ノードには必要条件がありません。代わりに、開始ノード（IN）でのインテリジェンスを集中します。
In addition, the Boomerang protocol allows for sender- or receiver-oriented reservations and resource query. Flows are identified with the common 5-tuple, and the QoS can be specified by various means; e.g., service class and bit rate. In the initial implementation, Boomerang messages are transported in ICMP ECHO/REPLY messages.
また、ブーメランプロトコルは、センダまたはレシーバ指向予約およびリソースクエリを可能にします。フローは共通の5タプルで識別され、およびQoSは、様々な手段によって特定することができます。例えば、サービスクラスとビットレート。初期の実装では、ブーメランのメッセージは、ICMP ECHO / REPLYメッセージに輸送されます。
Boomerang can only be used for unicast sessions; no support for multicast exists. The requested QoS can be specified with various methods, and both ends of a communication session can make a reservation for their transmitted flow.
ブーメランは、ユニキャストセッションのためにのみ使用することができます。マルチキャストのサポートは存在しません。要求されたQoSは、様々な方法で指定することができ、通信セッションの両端は、それらの送信フローのための予約を行うことができます。
The authors of Boomerang show in [FNS02] that the processing of the protocol is considerably lower than that of the ISI RSVP daemon implementation. However, this is mainly due to the limited functionality provided by the protocol compared to that provided by RSVP.
ブーメランの著者らは、プロトコルの処理は、ISI RSVPデーモン実装のそれよりもかなり低いこと[FNS02]に示しています。しかしながら、これは、RSVPによって提供されるものに比べプロトコルによって提供される限定された機能に主に起因します。
Boomerang messages are quite short and consume a relatively low amount of link bandwidth. This is due to the limited functionality of the protocol; for example, no security-specific information or policy-based interaction is provided. Being sender oriented, the bandwidth consumption mostly affects the downstream direction, from the sender to the receiver.
ブーメランのメッセージは非常に短く、リンク帯域幅の比較的低い量を消費します。これは、プロトコルの限られた機能によるものです。例えば、何のセキュリティ固有の情報やポリシーベースの相互作用が提供されていません。送信者が配向され、帯域幅の消費量は、主に、送信側から受信側に、下流方向に影響を与えます。
As Boomerang is sender oriented, there is no need to store backward information. This reduces the signaling required. The rest of the issues that were identified with RSVP apply with Boomerang. No security mechanism is specified for Boomerang.
ブーメランは、送信者指向であるため、後方の情報を格納する必要はありません。これは、必要なシグナリングを低減します。 RSVPで特定された問題の残りの部分はブーメランで適用されます。いいえ、セキュリティ・メカニズムは、ブーメランのために指定されていません。
The Boomerang protocol has deployment issues similar to those of any host-network-host protocol. It requires an implementation at both communicating nodes and in routers. Boomerang-unaware routers should be able to forward Boomerang messages transparently. Still, firewalls often drop ICMP packets, making the protocol useless.
ブーメランプロトコルは、任意のホスト・ネットワーク・ホストプロトコルと同様の展開の問題があります。これは、両方の通信ノードにルータに実装を必要とします。ブーメラン非対応のルータが透過的にブーメランメッセージを転送することができるはずです。それでも、ファイアウォールは、多くの場合、プロトコルは無用作り、ICMPパケットをドロップします。
Boomerang seems to be a very lightweight protocol and efficient in its own scenarios. However, the apparent low processing overhead and bandwidth consumption results from the limited functionality. No support for multicast or any security features are present, which allows for a different functionality than RSVP, which the authors like to compare Boomerang to.
ブーメランは、独自のシナリオで非常に軽量なプロトコルで効率的であるように思われます。しかし、限られた機能から明らかな低処理オーバーヘッドと帯域幅の消費の結果。マルチキャストまたは任意のセキュリティ機能のサポートは著者がブーメランに比較したいRSVPとは異なる機能を可能にする、存在しません。
INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism for supporting QoS in mobile ad-hoc networks. It avoids the need for separate signaling by carrying the QoS signaling data along with the normal data in IP packets using IP packet header options. This approach, known as "in-band signaling", is proposed as more suitable in the rapidly changing environment of mobile networks since the signaled QoS information is not tied to a particular path. It also allows the flows to be rapidly established and, thus, is suitable for short-lived and dynamic flows.
INSIGNIAは[LGZC00】モバイルアドホックネットワークにおいてQoSをサポートするための非常に単純なシグナリングメカニズムとして提案されています。これは、IPパケットのヘッダのオプションを使用して、IPパケット内の通常のデータと一緒にデータをQoSシグナリングを搬送することにより、別のシグナリングの必要性を回避します。シグナリングQoS情報は、特定のパスに関連付けられていないので、「インバンド・シグナリング」と呼ばれるこのアプローチは、モバイルネットワークの急速に変化する環境に、より適していると提案されています。また、このように、短命と動的フローに適しており、フローが急速に確立されることを可能にすると。
INSIGNIA aims to minimize signaling by reducing the number of parameters that are provided to the network. It assumes that real-time flows may tolerate some loss, but are very delay sensitive so that the only QoS information needed is the required minimum and maximum bandwidth.
INSIGNIAは、ネットワークに提供されるパラメータの数を減らすことによって、シグナル伝達を最小化することを目的とします。これは、リアルタイム・フローは、いくつかの損失を許容するが、必要なだけのQoS情報が必要な最小値と最大帯域幅になるように非常に敏感遅延していることを前提としています。
The INSIGNIA protocol operates at the network layer and assumes that link status sensing and access schemes are provided by lower-layer entities. The usefulness of the scheme depends on the MAC layers, but this is undefined, so INSIGNIA can run over any MAC layer. The protocol requires that each router maintains per-flow state.
記章プロトコルは、ネットワーク層で動作し、リンク状態検知とアクセス方式は下位層エンティティによって提供されることを前提としています。スキームの有用性は、MAC層に依存しますが、これは定義されていませんので、INSIGNIAは、任意のMAC層の上に実行することができます。プロトコルは、各ルータはフロー単位の状態を維持する必要があります。
The INSIGNIA system implicitly supports mobility. A near-minimal amount of information is exchanged with the network. To achieve this, INSIGNIA makes many assumptions about the nature of traffic that a source will send. This may also simplify admission control and buffer allocation. The system basically assumes that "real-time" will be defined as a maximum delay, and the user can simply request real-time service for a particular quantity of traffic.
INSIGNIAシステムは、暗黙のうちにモビリティをサポートしています。情報の近い最小限の量は、ネットワークと交換されます。これを達成するために、INSIGNIAは、ソースがお送りしますトラフィックの性質について多くの仮定を行います。これはまた、アドミッション制御及びバッファ割り当てを単純化することができます。システムは、基本的に「リアルタイム」は最大遅延として定義され、ユーザは単にトラフィックの特定の量のリアルタイムサービスを要求することができることを前提としています。
After handover, data that was transmitted to the old base station can be forwarded to the new base station, so no data loss should occur. However, there is no way to differentiate between re-routed and new traffic, so priority cannot be given to handover traffic, for example.
ハンドオーバー後、旧基地局に送信されたデータは、新しい基地局に転送することができるので、データの損失は発生しません。しかし、再ルーティングされ、新しいトラフィックを区別する方法はありませんので、優先順位は、例えば、ハンドオーバトラフィックに与えることはできません。
INSIGNIA, however, (completely) lacks a security framework and does not investigate how to secure signaled QoS data in an ad-hoc network, where relatively weak trust or even no trust exists between the participating nodes. Therefore, authorization and charging especially might be a challenge. The security protection of in-band signaling is costly since the data delivery itself experiences increased latency if security processing is done hop-by-hop. Because the QoS signaling information is encoded into the flow label and end-to-end addressing is used, it is very difficult to provide security other than IPsec in tunnel mode.
INSIGNIAは、しかし、（完全に）セキュリティフレームワークを欠き、比較的弱い信頼あるいは無信頼が参加しているノード間に存在するアドホックネットワークにおいてシグナリングQoSデータを保護する方法を検討しません。そのため、認可および特に充電が課題かもしれません。セキュリティ処理は、ホップバイホップで行われる場合、データ配信自体が増加待ち時間を経験するので、帯域内シグナリングのセキュリティ保護は高価です。情報は、フローラベルに符号化され、エンドツーエンドのアドレス指定されたQoSシグナリングが使用されるので、トンネルモードのIPsec以外のセキュリティを提供することは非常に困難です。
This section gives a short overview of protocols designed for inter-domain signaling.
このセクションでは、ドメイン間のシグナリングのために設計されたプロトコルの短い概要を説明します。
Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling protocol for inter-domain aggregated resource reservation for unicast traffic. BGRP builds a sink tree for each of the stub domains. Each sink tree aggregates bandwidth reservations from all data sources in the network. BGRP maintains these aggregated reservations using soft state and relies on Differentiated Services for data forwarding.
ボーダーゲートウェイ予約プロトコル（BGRP）は[BGRP]ユニキャストトラフィックのドメイン間凝集リソース予約のためのシグナリングプロトコルです。 BGRPスタブドメインのそれぞれのためのシンクツリーを構築します。それぞれのネットワーク内のすべてのデータソースからの木の集合体の帯域幅の予約をシンクします。 BGRPソフト状態を使用して、これらの凝集予約を維持し、データ転送のために差別化されたサービスに依存しています。
In terms of message processing load, BGRP scales state storage and bandwidth. Because backbone routers only maintain the sink tree information, the total number of reservations at each router scales linearly with the number of Internet domains.
メッセージ処理負荷の観点から、BGRPはステートストレージと帯域幅をスケーリングします。バックボーンルータのみシンクツリー情報を保持しているため、各ルータでの予約の合計数は、インターネットドメインの数に比例して増大します。
SICAP (Shared-segment Inter-domain Control Aggregation protocol) [SGV03] is an inter-domain signaling solution that performs shared-segment aggregation [SGV02] on the Autonomous System (AS) level in order to reduce state required at Boundary Routers (BRs). SICAP performs aggregation based on path segments that different reservations share. Thus, reservations may be merged into aggregates that do not necessarily extend all the way to the reservation's destination. The motivation for creating "shorter" aggregates is that, on one hand, their ability to accommodate future requests more easily, and, on the other hand, the minimization of aggregates created and consequently, the reduction of state required to manage established reservations. However, in contrast to the sink-tree approach (used by BGRP [BGRP]), the shared-segment approach introduces intermediate de-aggregation locations. These are ASes where aggregates may experience "re-aggregation". At these locations, routers that perform aggregation (AS egress routers) have to keep track of the mapping between reservations and aggregates. One possible way to do this is to keep each reservation identifier and the corresponding resources stored at each aggregator. However, this solution incurs a high state penalty. SICAP avoids this state penalty by keeping track of the mapping between aggregates and reservations at the level of destination domains rather than explicitly map individual reservations to aggregates. In other words, SICAP maintains, per aggregate, a list of the destination prefixes advertised by the destination AS an aggregate provides access to.
SICAP（共有セグメントインタードメインコントロール集約プロトコル）[SGV03]のBR（境界ルータに必要な状態を低減するために、自律システム（AS）レベルの[SGV02]共有セグメントの集合を実行するドメイン間シグナリング溶液であります）。 SICAPは異なる予約が共有パスセグメントに基づいて集約を実行します。このため、予約は必ず予約の宛先へのすべての方法を拡張しない凝集体にマージされることがあります。 「短い」凝集体を作成するための動機は、他の一方で、凝集体の最小化が作成され、その結果、状態の低下が確立し、予約を管理するために必要な、一方では、彼らの能力をより簡単に今後の要求に対応するために、ということである、と。しかし、（BGRP [BGRP]によって使用される）シンクツリーアプローチとは対照的に、共有セグメントアプローチは、中間脱凝集場所を導入します。これらの凝集体は、「再凝集」を経験することのASです。これらの場所では、（出口ルータなど）の集約を行うルータは、予約と骨材との間のマッピングを追跡する必要があります。これを行う1つの可能な方法は、各予約識別子及び各アグリゲータに記憶された対応するリソースを保持することです。しかし、この解決策は、高い状態のペナルティを被ります。 SICAPは、宛先ドメインのレベルで凝集体と予約との間のマッピングを追跡するのではなく、明示的に凝集体に個々の予約をマッピングすることにより、この状態のペナルティを回避します。換言すれば、SICAPは、凝集体あたり、へのアクセスを提供する集合体として宛先によってアドバタイズ宛先プレフィックスのリストを維持します。
Pan et al. show that BGRP scales well in terms of control state, message processing, and bandwidth efficiency, when compared to RSVP without aggregation. However, partially given that BGRP was the first approach to explore the issue of inter-domain control aggregation in detail, they did not provide a comparison with other aggregation protocols.
らパン。凝集することなくRSVPと比較した場合BGRPは、制御状態、メッセージ処理、及び帯域幅効率の点で適切に拡張することを示しています。しかし、部分的にBGRPは詳細にドメイン間の制御凝集の問題を探求する最初のアプローチだったことを考えると、彼らは他の集約プロトコルとの比較を提供していませんでした。
SICAP and BGRP messaging sequences are similar, and consequently, these protocols attain the same signaling load. This load is exactly the same as that attained by proposals that do not perform aggregation, given that SICAP and BGRP exchange messages per individual reservation. In terms of bandwidth, both protocols provision aggregates with the exact bandwidth required by their merged reservations. Therefore, the major difference between SICAP and BGRP is state maintained at BRs, which is significantly reduced by SICAP. We consider this to be of importance not so much for offering a better-performing alternative to BGRP, but for quantifying the performance improvements that might still be available in the research field of control path aggregation. Finally, to deal with the possible problem of the signaling load, SICAP uses an over-reservation mechanism [SGV03b], whose design took into consideration a possible support for BGRP.
SICAPとBGRPメッセージング配列が類似しており、その結果、これらのプロトコルは、同一のシグナリング負荷を達成します。この負荷は、個々の予約につきSICAPとBGRP交換メッセージことを考えると、正確に集計を実行していない提案することによって達成ものと同じです。帯域幅の面では、両方のプロトコルの提供は、そのマージされた予約によって必要な正確な帯域幅を集約します。したがって、SICAPとBGRPの主な違いは有意SICAP減少するのBR、の状態に維持されます。私たちは、これがBGRPにパフォーマンスの向上の代替を提供するために、まだ制御パス凝集の研究分野で利用可能であるかもしれないパフォーマンスの改善を定量化するためではないので、あまり重要であると考えます。最後に、シグナリング負荷の可能性のある問題に対処するために、SICAPは、その設計考慮BGRPの可能なサポートを取った上、予約メカニズム[SGV03b]を、使用します。
Dynamic Aggregation of Reservations for Internet Services (DARIS) [Bless02] [Bless04] defines an inter-domain aggregation scheme for resource reservations. Basically, it aggregates reservations along Autonomous System (AS) paths (or parts thereof). A set of reservations whose data paths share a common sequence of ASes are integrated into a joint reservation aggregate along that shared sub- path. All entities within the aggregate, except for aggregate starting and end point, can remove state information of the included individual reservations, thereby saving states. They just need to hold the necessary information about the encompassing aggregate. Moreover, these intermediate ASes are no longer involved in signaling that is related to the aggregated reservations. If more aggregate resources are reserved than were actually required, the capacity of the aggregate does not need to be adapted with every new or released reservation (thereby reducing the number of message exchanges).
インターネットサービスのための予約の動的集約（DARIS）は[Bless02] [Bless04]リソース予約のためのドメイン間の集約方式を定義します。基本的には、自律システム（AS）パス（またはその一部）に沿って予約を集約します。データパスのASの共通配列を共有する共有副経路に沿って関節予約集合に統合されている予約のセット。集約内のすべてのエンティティは、集計開始と終了点を除いて、それによって、状態を保存し、含まれる個々の予約の状態情報を削除することができます。彼らはただ包み込む集約に関する必要な情報を保持する必要があります。また、これらの中間のASは、もはやそれが凝集予約に関連するシグナル伝達に関与していません。より集計リソースが実際に必要であったよりも予約されている場合、骨材の容量は、すべての新しいまたは解放予約（それによって、メッセージ交換の数を減らす）と適合させる必要はありません。
An aggregate between two ASes is created as soon as a threshold k is exceeded that describes the active number of unidirectional reservations between them. It is, however, possible to apply different aggregation triggers. Furthermore, DARIS allows aggregates to be nested hierarchically. Therefore, the existence of shorter aggregates does not prevent the creation of longer (and thus more efficient) aggregates, and vice versa. An evaluation of recent BGP routing information in [Bless02] showed that 92% of all end-to-end paths contain at least four ASes. Consequently, an aggregate from edge AS to edge AS can span four or more ASes, thus saving states and signaling message processing in at least two ASes.
2つのAS間の集約は、すぐに閾値kは、それらの間の一方向の予約のアクティブ数を記述した超えているとして作成されます。異なる集計トリガを適用することは可能です。さらに、DARISは、凝集体が階層的に入れ子にすることができます。そのため、短い凝集体の存在は長く（したがって、より効率的な）凝集体の作成、およびその逆を防ぐことはできません。 【Bless02]の最近のBGPルーティング情報の評価は、すべてのエンドツーエンドパスの92％が、少なくとも4つのASを含有することを示しました。したがって、ASエッジように端から骨材は、このように状態を保存し、少なくとも二つのASにメッセージ処理シグナリング、四の以上のASにまたがることができます。
There is, however, a small chance that a reservation cannot be included in a new aggregate, because it was already aggregated elsewhere. This so-called "aggregation conflict" is caused by the prior removal of state information related to individual reservations within intermediate ASes of the encompassing aggregate. This may also bring difficulties if reservations or aggregates are re-routed between ASes. One must be careful when considering how to define sophisticated adaptation techniques for these special cases, because they seem to become very complex.
それは、すでに他の場所で集約されたので予約は、新しい集計に含めることができないという小さなチャンスは、しかし、があります。このいわゆる「凝集競合は」包含する集合体の中間体のAS内の個々の予約に関連する状態情報の前に除去することによって引き起こされます。予約や凝集体はAS間再ルーティングされている場合にも、この困難をもたらす可能性があります。これらの特別な場合のための洗練された適応技術を定義する方法を考えるとき、彼らは非常に複雑になっているようですので、一つは、慎重でなければなりません。
The signaling protocol DMSP (Domain Manager Signaling Protocol) supports aggregation by special extensions that reduce the reservation setup time for more than one round-trip time in some cases (e.g., if an aggregate's capacity must be increased before a new reservation can be included). Details can be found in [Bless02].
シグナリングプロトコルDMSP（ドメインマネージャシグナリングプロトコル）（新しい予約を含めることができます前に、集約の容量を大きくする必要がある場合など、）いくつかのケースでは、複数の往復時間の予約セットアップ時間を短縮特殊な拡張子によって集約をサポートしています。詳細は[Bless02]で見つけることができます。
The DARIS concept was evaluated by using a simulation with a topology that was derived from real BGP routing table information and comprised more than 5500 ASes. In comparison to a non-aggregated scenario, the number of saved states lay in the range of one to two orders of magnitude, and similar results were obtained with respect to the number of signaling messages. Though [Bless02] describes DARIS in the context of distributed Domain Management entities (similar to a bandwidth broker), it can be applied in a router-based resource management environment, too. This will achieve a higher degree of distribution, which is beneficial for large ASes, which are highly interconnected.
DARISの概念は、実際のBGPルーティングテーブル情報とから構成される5500の以上のASから派生したトポロジーとシミュレーションを用いて評価しました。非凝集シナリオと比較して、保存された状態の数は、1~2桁の範囲にあった、そして同様の結果は、シグナリングメッセージの数に関して得られました。 [Bless02]（帯域ブローカーに類似）は、分散ドメイン管理エンティティのコンテキストでDARISを説明しますが、それはあまりにも、ルータベースのリソース管理環境で適用することができます。これは、高度に相互接続されている大型のASについて有益である、分布のより高い程度を達成します。
A general issue with aggregation is that it is not the aggregating and de-aggregating ASes that profit from their initiated aggregates, but all intermediate ASes within an aggregate. Therefore, some incentive for aggregate creation has to be given. This may lead to novel cost models that have to be developed for aggregation concepts in the future.
集約と一般的な問題は、それが凝集し、その開始集合体から利益解凝集のASが、集約内のすべての中間のASはないということです。そのため、集計を作成するためのいくつかのインセンティブが与えられることがあります。これは、将来的に集約概念のために開発する必要が新しいコストモデルにつながる可能性があります。
This document does not present new technology or protocols. Thus, there are no explicit security issues. Still, individual protocols include different levels of security issues and those are highlighted in the relevant sections and references.
この文書は、新しい技術やプロトコルを提示していません。このように、明示的なセキュリティ上の問題はありません。それでも、個々のプロトコルはセキュリティ上の問題のさまざまなレベルが含まれ、それらは関連セクションおよび参考文献に強調表示されます。
Supporting flow-based soft state reservations has been proven useful. Still, there have been different ways to improve the performance, including refresh reduction and aggregation. However, some of the main concerns with these signaling protocols are the complexity of the protocol, which affects implementations and processing overhead, and the security of the signaling. Especially, a proper scheme to handle authentication and authorization of QoS resource requests and a framework for providing signaling message security seem to be missing from most protocols. RSVP has a mechanism to protect signaling messages based on manually distributed keys and concepts for authorization, but they seem to be insufficient for a dynamic and mobile environment. [Tsch03] provides more details on security properties provided by RSVP. Moreover, secure and efficient signaling to and from mobile nodes has been one of the critical challenges not fully met by existing protocols.
フローベースのソフトステートの予約をサポートすることが有用であることが証明されました。それでも、リフレッシュ削減や集約などのパフォーマンスを向上させるためのさまざまな方法、ありました。しかしながら、これらのシグナリングプロトコルとの主な懸念のいくつかは、インプリメンテーションおよび処理オーバーヘッドに影響を与えるプロトコルの複雑さ、およびシグナリングのセキュリティです。特に、シグナリング・メッセージのセキュリティを提供するための認証および承認のQoSリソース要求のフレームワークを処理するための適切な方式では、ほとんどのプロトコルから欠落しているようです。 RSVPは、認可のために手動で分散キーと概念に基づいてシグナリングメッセージを保護するための機構を有しているが、彼らはダイナミックで、モバイル環境のためには不十分であるように見えます。 【Tsch03]はRSVPによって提供されるセキュリティ特性に関する詳細を提供します。また、へと移動ノードからの安全で効率的なシグナリングが完全に既存のプロトコルによって満たされていない重要な課題の一つとなっています。
Moving QoS signaling protocols into a generic messenger can provide much adoption. It is expected that the development of future protocols should learn from the lessons of existing ones. Nevertheless, the tradeoffs between the expected functionality, protocol complexity/performance would still be taken into account. For example, RSVP uses the two-way signaling mechanism, whereas YESSIR employs only one-pass signaling. Both can be shown to out-perform the other in specific carefully chosen signaling scenarios.
一般的なメッセンジャーにシグナリングプロトコルのQoSを移動すると、多くの採用を提供することができます。将来のプロトコルの開発は、既存の教訓から学ぶべきことが期待されます。それにもかかわらず、期待される機能間のトレードオフは、プロトコルの複雑性/パフォーマンスがまだ考慮されることになります。 YESSIRのみワンパスシグナリングを採用する一方、例えば、RSVPは、双方向シグナリングメカニズムを使用します。両方は、特定の注意深く選択されたシグナリングシナリオで他を実行外に示すことができます。
This document is part of the work done in the NSIS Working Group. The document was initially written by Jukka Manner and Xiaoming Fu. Since the first version, Martin Karsten has provided text about the processing overhead of RSVP, and Hannes Tschofenig has provided text about various security issues in the protocols. Henning Schulzrinne and Ping Pan have provided more information on RSVP transportation after the second revision. Kireeti Kompella and Adrian Farrel provided a review and updates to the discussion on RSVP-TE and GMPLS.
この文書では、NSISワーキンググループで行われた作業の一部です。文書は、最初ユッカマナーと暁明フーによって書かれました。最初のバージョン以来、マーティン・カルステンはRSVPの処理オーバヘッドに関するテキストを提供している、とハンネスTschofenigはプロトコルで、さまざまなセキュリティ問題に関するテキストを提供してきました。ヘニングSchulzrinneととPingパンは、第二の改正後のRSVP交通に関する詳細な情報を提供しています。 Kireeti Kompellaとエイドリアン・ファレルは、RSVP-TEとGMPLS上の議論にレビューし、更新情報を提供しました。
We would like to acknowledge Bob Braden and Vlora Rexhepi for their useful comments.
私たちは彼らの有益なコメントをボブブレーデンとVlora Rexhepiを確認したいと思います。
This section provides a comparison of RSVP to the requirements identified as part of the work in NSIS [RFC3726]. The numbering follows the division in the requirements document.
このセクションでは、NSIS [RFC3726]での作業の一環として特定された要件にRSVPの比較を提供します。ナンバリングは、要件文書の区分に従っています。
5.1. Architecture and Design Goals
5.1. アーキテクチャと設計目標
5.1.1. NSIS SHOULD Provide Availability Information on Request
5.1.1. NSISは、リクエストに応じて利用可能情報を提供しなければなりません
RSVP itself does not support query-type of operations. However, the RSVP diagnosis messages extension [RFC2745] provides a means to query resource availability.
RSVP自体は操作のクエリタイプをサポートしていません。しかし、RSVP診断メッセージの拡張[RFC2745]はリソースの可用性を照会するための手段を提供します。
5.1.2. NSIS MUST Be Designed Modularly
5.1.2. NSISは、モジュール方式設計する必要があります
RSVP was designed to be modular by way of TLV objects, however it is regarded being lack of sufficient extensibility in various kind of signalling applications.
RSVPは、しかしながら、それはシグナリングアプリケーションの様々な種類に十分な拡張性の欠如であるとみなされる、TLVオブジェクトを介してモジュール化するように設計されました。
5.1.3. NSIS MUST Decouple Protocol and Information
5.1.3. NSISは、プロトコルと情報をデカップリングしなければなりません。
RSVP is decoupled from the IntServ QoS specifications. Still, the concept of sessions in RSVP are somewhat coupled to the information it carries.
RSVPは、IntServのQoS仕様から分離されます。それでも、RSVPでのセッションの概念はややそれが運ぶ情報に結合されています。
5.1.4. NSIS MUST Support Independence of Signaling and Network Control Paradigm
5.1.4. NSISはシグナリングの独立性とネットワーク制御パラダイムをサポートしている必要があります
The IntServ information carried by RSVP does not tie the QoS provisioning mechanisms.
RSVPによって運ばのIntServ情報はメカニズムをプロビジョニングQoSを結ぶありません。
5.1.5. NSIS SHOULD Be Able To Carry Opaque Objects
5.1.5. NSISは不透明なオブジェクトを運ぶことができるはずです
RSVP supports this.
RSVPはこれをサポートしています。
5.2. Signaling Flows
5.2. シグナリングフロー
5.2.1. The Placement of NSIS Initiator, Forwarder, and Responder Anywhere in the Network MUST Be Allowed
5.2.1. ネットワーク内のどこにでもNSISイニシエータ、フォワーダー、およびレスポンダの配置は許可されている必要があり
Standard RSVP works only end-to-end, although the RSVP proxy [BEGD02] and the Localized RSVP [MSK+04] have relaxed this assumption. RSVP relies on receiver-initiation way to perform QoS reservations.
RSVPプロキシ[BEGD02]とローカライズされたRSVP [MSK + 04]この仮定を緩和しているものの、標準RSVPは、唯一のエンドツーエンドで動作します。 RSVPは、QoS予約を実行するために受信機の開始方法に依存しています。
5.2.2. NSIS MUST support Path-Coupled and MAY Support Path-Decoupled Signaling
5.2.2. NSISはパス-結合をサポートしなければならないとパスデカップリングシグナリングをサポートすることが可能
Standard RSVP is path-coupled, but the Subnet Bandwidth Manager (SBM) work makes RSVP somewhat path-decoupled.
標準RSVPパス結合であるが、サブネット帯域幅マネージャー（SBM）作業は、RSVP幾分パスデカップリングを行います。
5.2.3. Concealment of Topology and Technology Information SHOULD Be Possible
5.2.3. トポロジおよび技術情報の隠蔽が可能なはずです
RSVP itself does not provide such capability.
RSVP自体は、このような機能を提供していません。
5.2.4. Transparent Signaling through Networks SHOULD Be Possible
5.2.4. ネットワークを通じた透明なシグナリングが可能なはずです
RSVP messages are intercepted and evaluated in each RSVP router, and thus they may not cross certain RSVP-routers unnoticed. Still, the message processing rules allow unknown RSVP messages to be forwarded unharmed.
RSVPメッセージは傍受され、各RSVPルータで評価し、そして従ってそれらは特定のRSVP-ルータを気付か交差しないことがありれます。それでも、メッセージ処理規則は、未知のRSVPメッセージが無傷で転送することができます。
5.3. Messaging
5.3. メッセージング
5.3.1. Explicit Erasure of State MUST Be Possible
5.3.1. 国家の明示的な消去が可能でなければなりません
Supported by the PathTear and ResvTear messages.
PathTearとたResvTearメッセージによってサポートされています。
5.3.2. Automatic Release of State After Failure MUST Be Possible
5.3.2. 失敗した後の状態の自動リリースが可能でなければなりません
On error reservation states are torn down with PathTear messages.
エラーの予約状態はPathTearメッセージで取り壊されています。
5.3.3. NSIS SHOULD Allow for Sending Notifications Upstream
5.3.3. NSISは、通知の上流の送信を可能にすべきです
There are two notifications in RSVP, confirm of a reservation set-up and tear down of reservation states as a result of errors.
RSVPでの2つの通知、予約セットアップの確認やエラーの結果として、予約状態のティアダウンがあります。
5.3.4. Establishment and Refusal To Set Up State MUST Be Notified
5.3.4. 設立と状態を設定するには拒否が通知しなければなりません
PathErr and ResvErr messages provide refusal to set up state in RSVP.
PathErrとResvErrメッセージはRSVPの状態を設定するための拒否を提供しています。
5.3.5. NSIS MUST Allow for Local Information Exchange
5.3.5. NSISは、地域の情報交換のために許可する必要があります
RSVP NULL service type [RFC2997] provides such a feature.
RSVP NULLサービスタイプ[RFC2997]は、そのような機能を提供します。
5.4. Control Information
5.4. 制御情報
5.4.1. Mutability Information on Parameters SHOULD Be Possible
5.4.1. パラメータの可変性の情報は可能なはず
Rspec and Adspec are mutable; Tspec is (generally) end-to-end not mutable.
RSpecのとADSPECは変更可能です。 TSPECは、（一般に）エンド・ツー・エンドではない変更可能です。
5.4.2. It SHOULD Be Possible To Add and Remove Local Domain Information
5.4.2. ローカルドメインの情報を追加し、削除することが可能なはずです
RSVP aggregation [RFC3175] and NULL service type [RFC2997] can provide such a feature.
RSVP集約[RFC3175]とNULLサービスタイプ[RFC2997]は、そのような機能を提供することができます。
5.4.3. State MUST Be Addressed Independent of Flow Identification
5.4.3. 状態は、フロー識別の独立に対処しなければなりません
RSVP states are tied to the flows, thus this requirement is not met.
RSVPの状態は、このように、この要件が満たされていない、フローに関連付けられています。
5.4.4. Modification of Already Established State SHOULD Be Seamless
5.4.4. 既に確立された状態の変更は、シームレスでなければなりません
Modifications of a reservation is possible with RSVP.
予約の変更はRSVPで可能です。
5.4.5. Grouping of Signaling for Several Micro-Flows MAY Be Provided
5.4.5. いくつかのマイクロフローのシグナリングのグループは、提供することができます
Aggregated RSVP and RFC2961 allow this.
集約RSVPとRFC2961はこれを許可します。
5.5. Performance
5.5. 演奏
5.5.1. Scalability
5.5.1. スケーラビリティ
RSVP scales linearly to the number of reservation states.
RSVPは、予約状態の数に比例します。
5.5.2. NSIS SHOULD Allow for Low Latency in Setup
5.5.2. NSISは、セットアップで低遅延を可能にすべきです
Setting up an RSVP reservation takes one round-trip time and the processing times are each RSVP router.
RSVP予約を設定すると、1往復時間がかかり、処理時間は、各RSVPルータです。
5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the Signaling Protocol
5.5.3. NSISはシグナリングプロトコルのための低帯域幅の消費のために許可する必要があります
The initial reservations messages can not be compressed, but the refresh interval can be adjusted to consume less bandwidth, at the expense of possible inefficient resource usage.
最初の予約メッセージを圧縮することができませんが、リフレッシュ間隔は、可能な非効率的なリソース使用率を犠牲にし、少ない帯域幅を消費するように調整することができます。
5.5.4. NSIS SHOULD Allow To Constrain Load on Devices
5.5.4. NSISは、デバイス上の負荷を制限するために許可する必要があります
See discussions on RSVP performance (section 4).
RSVP性能（セクション4）上の議論を参照してください。
5.5.5. NSIS SHOULD Target the Highest Possible Network Utilization
5.5.5. NSISは、可能な限り最高のネットワーク使用率をターゲットとすべき
This depends on the IntServ service types, Controlled Load can provide better overall utilization than Guaranteed Service.
これはイントサーブサービスの種類に依存して、制御された負荷が保証されたサービスよりも優れた全体的な利用を提供することができます。
5.6. Flexibility
5.6. 柔軟性
5.6.1. Flow Aggregation
5.6.1. フロー集約
Aggregated RSVP and RFC2961 allow this.
集約RSVPとRFC2961はこれを許可します。
5.6.2. Flexibility in the Placement of the NSIS Initiator/Responder
5.6.2. NSISイニシエータ/レスポンダの配置の柔軟性
RSVP allows receiver as initiator of reservations.
RSVPは、予約の開始剤として受信を可能にします。
5.6.3. Flexibility in the Initiation of State Change
5.6.3. 状態変更の開始の柔軟性
RSVP receivers can initiate the state change during its refreshment.
RSVP受信機は、そのリフレッシュ時の状態変化を開始することができます。
5.6.4. SHOULD Support Network-Initiated State Change
5.6.4. ネットワーク開始ステートの変更をサポートする必要があります
As RSVP supports hop-by-hop refreshment, this is made possible.
RSVPは、ホップバイホップリフレッシュをサポートしていますように、これは可能となります。
5.6.5. Uni / Bi-Directional State Setup
5.6.5. ユニ/双方向ステートの設定
RSVP is only uni-directional.
RSVPは単方向です。
5.7. Security
5.7. セキュリティ
5.7.1. Authentication of Signaling Requests
5.7.1. シグナリング要求の認証
Authentication is available in RSVP.
認証は、RSVPで利用可能です。
5.7.2. Request Authorization
5.7.2. リクエスト認証
Authorization with a PDP is possible in RSVP.
PDPと認可は、RSVPで可能です。
5.7.3. Integrity Protection
5.7.3. 完全性保護
The INTEGRITY Object is available in RSVP.
INTEGRITYオブジェクトは、RSVPで利用可能です。
5.7.4. Replay Protection
5.7.4. リプレイ保護
The INTEGRITY Object to replay protect the content of the signaling messages between two RSVP nodes.
INTEGRITYオブジェクトは、二つのRSVPノード間のシグナリングメッセージのコンテンツを保護再生します。
5.7.5. Hop-By-Hop Security
5.7.5. ホップバイホップのセキュリティ
The RSVP security model works only hop-by-hop.
RSVPのセキュリティモデルはホップごとに動作します。
5.7.6. Identity Confidentiality and Network Topology Hiding
5.7.6. アイデンティティの機密性とネットワークトポロジ隠蔽
The INTEGRITY Object can be used for this purpose.
INTEGRITYオブジェクトは、この目的のために使用することができます。
5.7.7. Denial-Of-Service Attacks
5.7.7. サービス拒否攻撃
Challenging with RSVP.
RSVPに挑戦。
5.7.8. Confidentiality of Signaling Messages
5.7.8. シグナリングメッセージの機密性
Not supported by RSVP.
RSVPによってサポートされていません。
5.7.9. Ownership of State
5.7.9. 国家の所有権
Challenging with RSVP.
RSVPに挑戦。
5.8. Mobility
5.8. 可動性
5.8.1. Allow Efficient Service Re-Establishment After Handover
5.8.1. ハンドオーバ後に効率的なサービスの再確立を許可します
Works for upstream but may not be achieved for the downstream if mobility is not noticed at the cross-over router.
上流のために動作しますが、移動度は、クロスオーバールータに気づいていない場合、下流のために達成することはできません。
5.9. Interworking with Other Protocols and Techniques
5.9. その他のプロトコルおよび技術とのインターワーキング
5.9.1. MUST Interwork with IP Tunneling
5.9.1. IPトンネルと相互作用しなければなりません
RFC 2746 discusses these issues.
RFC 2746は、これらの問題について説明します。
5.9.2. MUST NOT Constrain either to IPv4 or IPv6
5.9.2. IPv4またはIPv6のいずれかに拘束してはなりません
RSVP supports both IP versions.
RSVPは両方のIPバージョンをサポートしています。
5.9.3. MUST Be Independent from Charging Model
5.9.3. 充電モデルから独立していなければなりません
RSVP does not discuss this.
RSVPはこれを議論していません。
5.9.4. SHOULD Provide Hooks for AAA Protocols
5.9.4. AAAプロトコルのためのフックを提供する必要があります
COPS and RSVP work together.
COPSと一緒にRSVPの仕事。
5.9.5. SHOULD Work with Seamless Handoff Protocols
5.9.5. シームレスハンドオフプロトコルで動作するはずです
Not supported by RSVP. Still, [RFC2205] suggests that route changes should be indicated to the local RSVP daemon, which can then initiate state refresh.
RSVPによってサポートされていません。依然として、[RFC2205]は、ルート変更は、状態の更新を開始することができるローカルRSVPデーモンに指示されるべきであることを示唆しています。
5.9.6. MUST Work with Traditional Routing
5.9.6. 従来のルーティングで働かなければなりません
RSVP expects traditional routing.
RSVPは、従来のルーティングを期待しています。
5.10. Operational
5.10. オペレーショナル
5.10.1. Ability to Assign Transport Quality to Signaling Messages
5.10.1. シグナリングメッセージへの輸送品質を割り当てる機能
This is a network design issue, but is possible with DiffServ.
これは、ネットワークの設計上の問題ですが、DiffServので可能です。
5.10.2. Graceful Fail Over
5.10.2. 優雅なフェイルオーバー
RSVP supports this.
RSVPはこれをサポートしています。
5.10.3. Graceful Handling of NSIS Entity Problems
5.10.3. NSIS実体問題の優雅な取り扱い
RSVP itself does not supports this.
RSVP自身はこれをサポートしません。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]ブルナー、M.、 "シグナリングプロトコルのための要件"、RFC 3726、2004年4月。
[3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service (QoS) Concept and Architecture, Release 5, December 2002.
[3GPP-TS23207] 3GPP TS 23.207 V5.6.0、エンドツーエンドサービス品質（QoS）の概念とアーキテクチャは、5、2002年12月リリース。
[BEBH96] Braden, R., Estrin, D., Berson, S., Herzog, and D. Zappala, "The Design of the RSVP Protocol", ISI Final Technical Report, July 1996.
[BEBH96]ブレーデン、R.、Estrin、D.、Berson氏、S.、ヘルツォーク、およびD. Zappala、 "RSVPプロトコルの設計"、ISI最終技術報告書、1996年7月。
[BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP Proxy", Work in Progress, March 2002.
[BEGD02] Y. Bernet、N. Elfassy、S.ガイ、およびD.ダットは、進歩、2002年3月に、仕事を "プロキシをRSVP"。
[BFM+96] A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma, and H. Zhang, "The Tenet Real-Time Protocol Suite: Design, Implementation, and Experiences", IEEE/ACM Transactions on Networking, Volume 4, Issue 1, February 1996, pp. 1-10.
[BFM + 96] A. Banerjea、D.フェラーリ、B.麻雀、M.モラン、D.バーマ、およびH.チャン、 "テネットリアルタイムプロトコルスイート：設計、実装、および経験"、IEEE / ACMネットワーキング、4巻、1号、1996年2月、頁1-10上の取引。
[BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-Based Aggregation Protocol for Inter-domain Reservations", Journal of Communications and Networks, Vol. 2, No. 2, June 2000, pp. 157-167.
[BGRP] P.パン、E、Hahne、およびH. Schulzrinneと、「BGRP：ドメイン間の予約のためのツリーベースの集約プロトコル」、コミュニケーションとネットワーク誌、Vol。 2、第2号、2000年6月、頁157-167。
[Bless02] R. Bless, "Dynamic Aggregation of Reservations for Internet Services", Proceedings of the Tenth International Conference on Telecommunication Systems - Modeling and Analysis (ICTSM 10), Vol. 1, pp. 26-38, October 3-6 2002, Monterey, California, available at http://www.tm.uka.de/doc/2003/ictsm-daris-journal-crc-web.pdf.
モデリングと解析（ICTSM 10）、巻 - [Bless02] R.は、「インターネットサービスのご予約の動的集約」、通信システムの第十国際会議の議事録を祝福します。 http://www.tm.uka.de/doc/2003/ictsm-daris-journal-crc-web.pdfで入手可能な1頁26-38、10月3-6 2002年、モントレー、カリフォルニア州、。
[Bless04] R. Bless, "Towards Scalable Management of QoS-based End-to- End Services" (PDF), Proceedings of NOMS 2004 (IEEE/IFIP 2004 Network Operations and Management Symposium), April 2004, Seoul, Korea.
[Bless04] R.は、ブレス "のスケーラブルな管理に向けてQoSベースのエンド・ツー・エンドのサービス"（PDF）、NOMSの議事2004（IEEE / IFIP 2004ネットワーク運用と管理シンポジウム）、2004年4月、ソウル、韓国。
[FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Work in Progress, January 2004.
[FAST-REROUTE] P.パン、G.ツバメ、およびA.アトラス、進歩、2004年1月に、仕事を "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。
[FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J. Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple Protocol for Resource Reservation in IP Networks", IEEE RTAS, 1999.
【FNM + 99] G. Feher、K. Nemethの、M. Maliosz、I. Cselenyi、J. Bergkvist、D. Ahlard、T. Engborg、 "IPネットワークにおけるリソース予約のためのブーメランA単純なプロトコル"、IEEE RTAS、1999 。
[FNS02] G. Feher, K. Nemeth, and I. Cselenyi, "Performance evaluation framework for IP resource reservation signalling". Performance Evaluation 48 (2002), pp. 131-156.
[FNS02] G. Feher、K. Nemethの、及びI. Cselenyi、 "IPリソース予約シグナリングのための性能評価フレームワーク"。性能評価48（2002）、頁131から156まで。
[FJ02] P. Fransson and A. Jonsson, "The need for an alternative to IPv4-options", in RVK (RadioVetenskap och Kommunikation), Stockholm, Sweden, pp. 162-166, June 2002.
[FJ02] Fransson及びP. A.ジョンソン、「IPv4オプションの代替の必要性」、RVK（無線科学コミュニケーションズ）、ストックホルム、スウェーデン、PP。 162〜166、2002年6月。
[Fu02] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP Regarding Multicast". Technical Report No. IFI-TB-2002-001, ISSN 1611-1044, Institute for Informatics, University of Goettingen, Oct 2002.
【Fu02】X.フー、C. Kappler、及びH. Tschofenig、 "マルチキャストに関してRSVPの分析"。テクニカルレポート番号IFI-TB-2002-001、ISSN 1611-1044、情報、ゲッティンゲン大学の研究所、2002年10月。
[H.245] ITU-T Recommendation H.245, Control Protocol for Multimedia Communication, July 2000.
[H.245] ITU-T勧告H.245、マルチメディア通信、2000年7月のための制御プロトコル。
[H.323] ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems, Nov. 2000.
[H.323] ITU-T勧告H.323、パケットベースのマルチメディア通信システム、2000年11月。
[JR03] Jukka Manner, Kimmo Raatikainen, "Localized QoS Management for Multimedia Applications in Wireless Access Networks". IASTED International Conference on Internet and Multimedia Systems and Applications (IMSA 2003), August, 2003, pp. 193-200.
[JR03]ユッカマナー、キンモRaatikainen、「無線アクセスネットワークにおけるマルチメディアアプリケーションのローカライズされたQoS管理」。インターネットとマルチメディアシステムおよびアプリケーション上のIASTED国際会議（2003年IMSA）、2003年8月、頁193-200。
[Kars01] M. Karsten, "Experimental Extensions to RSVP -- Remote Client and One-Pass Signalling". IWQoS 2001, Karlsruhe, Germany, June 2001.
[Kars01] M.カルステン、「RSVPする実験的な機能拡張 - リモートクライアントとワンパスシグナリング」。 2001 IWQoS、カールスルーエ、ドイツ、2001年6月。
[KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz, "Implementation and Evaluation of the KOM RSVP Engine", IEEE Infocom 2001.
[KSS01] M.カルステン、イェンス・シュミット、ラルフ・スタインメッツ、 "実装とKOM RSVPエンジンの評価"、2001 IEEEインフォコム。
[LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A. Campbell,"INSIGNIA: An IP-Based Quality of Service Framework for Mobile Ad Hoc Networks". Journal of Parallel and Distributed Computing (Academic Press), Special issue on Wireless and Mobile Computing and Communications, Vol. 60, Number 4, April, 2000, pp. 374-406.
[LGZC00] S.リー、A. Gahng・ヒソプ、X.チャン、A.キャンベル、「INSIGNIA：アドホックネットワークのためのサービスフレームワークのIPベースの品質」。並列分散コンピューティング誌（アカデミック・プレス）、ワイヤレスおよびモバイルコンピューティングとコミュニケーション、巻特集。 60、ナンバー4、2000年4月、頁374から406まで。
[MA01] B. Moon, and H. Aghvami, "RSVP Extensions for Real-Time Services in Wireless Mobile Networks". IEEE Communications Magazine, December 2001, pp. 52-59.
[MA01] B.月、およびH. Aghvami、「ワイヤレスモバイルネットワークにおけるリアルタイムサービスのためのRSVP拡張」。 IEEEコミュニケーションズマガジン、2001年12月、頁52-59。
[MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An Architectural Comparison of ST-II and RSVP", Infocom 1994.
【MESZ94] D. Mitzel、D. Estrin、S. Shenker、およびL.チャン、 "ST-IIおよびRSVPのアーキテクチャの比較"、インフォコム1994。
[MHS02] Y Miao, W. Hwang, and C. Shieh, "A transparent deployment method of RSVP-aware applications on UNIX". Computer Networks, 40 (2002), pp. 45-56.
[MHS02] Yミャオ族、W.黄とC. Shieh、 "UNIX上のRSVP対応アプリケーションの透明展開方法"。コンピュータネットワーク、40（2002）、頁45-56。
[MSK+04] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K. Raatikainen, "Localized RSVP", Work in Progress, September 2004.
[MSK + 04] J.マナー、T. Suihko、M.古城、M. Liljeberg、K. Raatikainen、 "ローカライズRSVP"、進歩、2004年9月での作業。
[OVERLAY] G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter, "GMPLS UNI: RSVP Support for the Overlay Model", Work in Progress, February 2004.
[OVERLAY] G.ツバメ、J.ドレイク、H.石松、およびY. Rekhter、 "GMPLS UNI：オーバーレイモデルのRSVPのサポート"、進歩、2004年2月に作業。
[PS97] P. Pan and H. Schulzrinne, "Staged refresh timers for RSVP", Global Internet, Phoenix, Arizona, November 1997.
[PS97] P.パンとH. Schulzrinneとは、 "RSVPのリフレッシュタイマーを段階的"、グローバル・インターネット、フェニックス、アリゾナ州、1997年11月。
[PS98] P. Pan, and H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism for the Internet". Proceedings of NOSSDAV, Cambridge, UK, July 1998.
[PS98] P.パン、およびH. Schulzrinneと、 "YESSIR：インターネットのための簡単な予約メカニズム"。 NOSSDAV、ケンブリッジ、英国、1998年7月の議事録。
[PS00] P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel extension for IP option packet processing", Technical Memorandum 10009669-02TM, Bell Labs, Lucent Technologies, Murray Hill, NJ, June 2000.
[PS00] P.パン、およびH. Schulzrinneと、 "PF_IPOPTION：IPオプションパケット処理のためのカーネル拡張"、技術的な覚書10009669-02TM、ベル研究所、ルーセント・テクノロジーズ、マレーヒル、ニュージャージー州、2000年6月。
[RFC1819] Delgrossi, L. and L. Berger, "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.
[RFC1819] Delgrossi、L.およびL.バーガー、 "インターネットストリームプロトコルバージョン2（ST2）プロトコル仕様 - バージョンST2 +"、RFC 1819、1995年8月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]バーガー、L.とT.オマリー、 "IPSECデータフローのためのRSVP拡張機能"、RFC 2207、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2379] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24, RFC 2379, August 1998.
[RFC2379]バーガー、L.、 "ATMの実装のガイドラインを超えるRSVP"、BCP 24、RFC 2379、1998年8月。
[RFC2380] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
[RFC2380]バーガー、L.、 "ATMの実装要件を超えるRSVP"、RFC 2380、1998年8月。
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC2745] Terzis、A.、ブレーデン、B.、ヴィンセント、S.、およびL.チャン、 "RSVP診断メッセージ"、RFC 2745、2000年1月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[RFC2749]ヘルツォーク、S.、ボイル、J.、コーエン、R.、ダラム、D.、ラジャン、R.、およびA. Sastryは、RFC 2749、2000年1月 "RSVPの使用をCOPS"。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[RFC2814] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks", RFC 2814, May 2000.
[RFC2814] Yavatkar、R.、ホフマン、D.、Bernet、Y.、ベイカー、F.、およびM.シュペーア、「SBM（サブネット帯域幅マネージャー）：IEEE 802形式のネットワーク上でRSVPベースのアドミッション制御のためのプロトコル」、RFC 2814、2000年5月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、2000年11月。
[RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[RFC2997] Bernet、Y.、スミス、A.、およびB.デイビー、 "ヌルサービスタイプの仕様"、RFC 2997、2000年11月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE 。Felstaine、 "Diffservのネットワーク経由の統合サービス操作のための枠組み"、RFC 2998、2000年11月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001
[RFC3181]ヘルツォーク、S.、 "合図先取り優先権方針要素"、RFC 3181、2001年10月
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182] Yadavが、S.、Yavatkar、R.、Pabbati、R.、フォード、P.、ムーア、T.、ヘルツォーク、S.、およびR.ヘス、 "RSVPのID表現"、RFC 3182、2001年10月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520]ハマー、L-N。、ゲージ、B.、コジンスキー、B.、およびH. Shieh、 "セッション認可ポリシーの要素"、RFC 3520、2003年4月。
[SGV02] R. Sofia, R. Guerin, and P. Veiga, "An Investigation of Inter-Domain Control Aggregation Procedures", International Conference on Networking Protocols, ICNP 2002, Paris, France, November 2002.
[SGV02] R.ソフィア、R.ゲラン、およびP.ア・ベイガ、「ドメイン間のコントロール集約手続の調査」、ネットワークプロトコル、ICNP 2002、パリ、フランス、2002年11月の国際会議。
[SGV03] R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared-segment Inter-domain Control Aggregation Protocol. High Performance Switching and Routing, HPSR 2003, Turin, Italy, June 2003.
[SGV03] R.ソフィア、R.ゲラン、およびP.ア・ベイガ。 SICAP、共有セグメント間のドメインコントロール集約プロトコル。高性能スイッチングおよびルーティング、HPSR 2003、トリノ、イタリア、2003年6月。
[SGV03b] R. Sofia, R. Guerin, and P. Veiga. A Study of Over-reservation for Inter-Domain Control Aggregation Protocols. Technical report (short version under submission), University of Pennsylvania, May 2003, available at http://einstein.seas.upenn.edu/mnlab/ publications.html.
[SGV03b] R.ソフィア、R.ゲラン、およびP.ア・ベイガ。過予約ドメイン間のコントロール集約プロトコルのための研究。 http://einstein.seas.upenn.edu/mnlab/ publications.htmlで入手可能な技術報告書（提出の下でショートバージョン）、ペンシルベニア州、2003年5月の大学、。
[TBA01] A. Talukdar, B. Badrinath, and A. Acharya, "MRSVP: A Resource Reservation Protocol for an Integrated Services Network with Mobile Hosts", Wireless Networks, vol. 7, no. 1, pp. 5-19, 2001.
【TBA01] A. Talukdar、B.バドリーナート、及びA. Acharyaさん、「MRSVP：モバイルホストとの統合サービスネットワークのためのリソース予約プロトコル」、無線ネットワーク、巻。 7、ありません。 1頁5-19、2001。
[Thom02] M. Thomas, "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.
[Thom02] M.トーマス、 "モバイルIPとRSVPの相互作用の解析"、進歩、2002年10月の作業。
[Tsch03] H. Tschofenig, "RSVP Security Properties", Work in Progress, February 2004.
[Tsch03] H. Tschofenig、 "RSVPセキュリティのプロパティ"、進歩、2004年2月に作業。
[ZDSZ93] L. Zhang, S. Deering, D. Estrin, and D. Zappala, "RSVP: A New Resource Reservation Protocol", IEEE Network, Volume 7, Pages 8-18, September 1993.
[ZDSZ93] L.チャン、S.デアリング、D. Estrin、およびD. Zappala、 "RSVP：新しいリソース予約プロトコル"、IEEEネットワーク、7巻、ページ8-18、1993年9月。
[URL1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
[のURL 1]のhttp：//vvv.atimktutkfi/list-arkaiv/diffsserw/thrdh3khtml
[URL2] OPENSIG http://comet.columbia.edu/opensig/
[URL2] OPENSIG http://comet.columbia.edu/opensig/
[URL3] SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/ siglite.html
[URL3] SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/ siglite.html
Authors' Addresses
著者のアドレス
Jukka Manner Department of Computer Science University of Helsinki P.O. Box 68 (Gustav Hallstrominkatu 2b) FIN-00014 HELSINKI Finland
コンピュータサイエンス、ヘルシンキ大学、私書箱のユッカマナー教室ボックス68（グスタフHallstrominkatu部2b）FIN-00014ヘルシンキ、フィンランド
Phone: +358-9-191-51298 Fax: +358-9-191-51120 EMail: jmanner@cs.helsinki.fi
電話：+ 358-9-191-51298ファックス：+ 358-9-191-51120 Eメール：jmanner@cs.helsinki.fi
Xiaoming Fu Institute for Informatics Georg-August-University of Goettingen Lotzestrasse 16-18 37083 Goettingen Germany
16-18 37083ゲッティンゲンドイツゲッティンゲンLotzestrasseの情報ゲオルクアウグスト大学のための暁明フー研究所
Phone: +49-551-39-14411 Fax: +49-551-39-14403 EMail: fu@cs.uni-goettingen.de
電話：+ 49-551-39-14411ファックス：+ 49-551-39-14403 Eメール：fu@cs.uni-goettingen.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。