[要約] 要約： RFC 4094は、既存の品質サービス信号プロトコルの分析を提供しています。このRFCの目的は、異なるプロトコルの比較と評価を通じて、品質サービス信号の実装と展開に関する洞察を提供することです。目的： 1. 既存の品質サービス信号プロトコルの分析を提供する。 2. 異なるプロトコルの比較と評価を通じて、品質サービス信号の実装と展開に関する洞察を提供する。 3. 品質サービス信号のプロトコルの選択に役立つ情報を提供する。
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).
Copyright（c）The Internet Society（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]およびBoomerang [FNM 99]は、RSVP後に設計されたプロトコルの例です。どちらもRSVPよりも単純であることを意図していました。YessirはRTCPの拡張機能ですが、BoomerangはICMPで使用されます。
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.
以前は、多くの作業がリソース制御のための新しいシグナル伝達プロトコルを作成することを目的としています。Istvan Cselenyiは、QoSシグナル伝達の問題を特定するためにIETF47にQossig BoFを持つことを提案しましたが、十分なサポートを得ることができませんでした[URL1]。「多くの点で、RSVPはST-2で改善され、より単純で始まりましたが、複雑さとスケーラビリティを備えたデザインをもたらしました」と主張した人もいましたが、他の人々は「新しい知識と要件」によりRSVPが不十分であると考えました。一部の人は、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".
Michael WelzlはSci 2001で特別セッション「ABRへの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 Panは、軽量のインターネットシグナル伝達を調査するために、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]は、ST-IIから進化し、アプリケーションデータストリームにエンドツーエンドQoSシグナリングサービスを提供しました。ホストはRSVPを使用して、特定のアプリケーションフローのためにネットワークから特定のサービス品質（QoS）を要求します。ルーターはRSVPを使用して、データパスに沿ってすべてのルーターにQoSリクエストを配信します。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モジュールはパケット分類器とパケットスケジューラにパラメーターを設定して、目的のQOを取得します。
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の設計は、多くの基本的な方法でそれ自体を区別しました。特に、ソフト状態管理、2パスシグナリングメッセージ交換、受信機ベースのリソース予約、およびルーティングからの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」メッセージを生成する場合があります。レシーバーの予約は不均一な場合があります。Multipoint-to-Multipointマルチキャストアプリケーションに対応するために、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は、定期的な更新メッセージ（PATHと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ノードの信号操作が少なくなる可能性がありますが、受信機の開始に制限を導入する可能性があります。
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のネットワーク全体の展開から利益を得ることができる重要なインターネットアプリケーションの1つであると考えていたマルチキャスト対応リアルタイムのテレコンフェンシングの需要は、実現したことはありません。代わりに、トラフィックエンジニアリングのRSVP拡張であるRSVP-TE [RFC3209]は、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やGMPLなどの新しいアプリケーションを単純に定義するものもあります。これは、プロトコルの当初の意図とはまったく関係ありません。
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-in-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は、1回のフローベースではなく、アドレスレスごとの、プロトコルごとにIPSECをサポートできます。[RFC2207]は、UDP/TCP様ポートの代わりにIPSECセキュリティパラメーターインデックス（SPI）を使用してRSVPを拡張します。これにより、IPSec SPIと新しいセッションオブジェクトを含む新しいFilter_Specオブジェクトが導入されます。
[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オブジェクトを解釈できないノードは、ポリシーイノラントノード（PIN）と呼ばれます。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]は、RSVP内の承認トークンの助けを借りて、個別のプロトコル（SIPなど）によって提供される認可をどのように再利用できるかを説明しています。したがって、トークンには、承認された情報自体（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オブジェクト。3つの新しい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メッセージは、1つ以上の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メッセージは、1つ以上のmessage_idリスト、message_id src_list、message_id mcast_listオブジェクトを伝えます。それらは、状態を確立するPATHおよび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セッションの数を減らすことができます。プロトコルタイプは、rsvpからe2e（標準）パス、pathtear、およびresvconfメッセージでRSVP-e2e-ignoreに交換され、集約領域に入るとRESVCONFメッセージが戻り、出発時に交換されます。新しい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.
1) セッションオブジェクトには、2つの値が含まれています。集約セッション宛先のIPアドレスと、予約に含まれるE2Eデータで使用する差別化されたサービスコードポイント（DSCP）が含まれます。
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.
3) Aggregate Reservationの集約ルーターを識別し、Sender_Templateオブジェクトと構文的に同一である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]は、パスメッセージが2つのL3エンティティ（RSVP PHOPとNHOPノード）の間でL2ドメインを横断するときに、次のL3ホップを追跡するRSVP LAN_NHOPアドレスオブジェクトを導入します。レイヤー2とレイヤー-3の両方のアドレスは、LAN_NHOPに含まれています。RSVP_HOP_L2オブジェクトは、前のホップのレイヤー2アドレス（L2ADDR）を含めるために使用され、RSVP_HOPオブジェクト（RSVP_HOP_L3アドレス）に含まれるL3アドレス情報を補完します。
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.
デバッグまたはリソース管理に十分な情報を提供するために、RSVP診断メッセージ（DREQおよびDREP）が[RFC2745]で定義され、受信者から特定の送信者へのパスに沿ってRSVP状態情報を収集および報告します。
[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の実装ガイドラインと要件をめぐるRSVPを定義し、ATM（フォーラム）UNI 3.x/4.0とインターワークします。[RFC2380]は、RSVP（コントロール）メッセージとRSVP関連データパケットを同じ仮想回路（VC）で送信する必要はなく、RSVPコントロールメッセージを転送するためにVCが実行されたらRSVP関連QoS VCの明示的なリリースを実行する必要があると述べています。終了します。RSVPコントロールメッセージを転送するためには別のコントロールVCも可能ですが、[RFC2379]は、RSVPトリガーされたVCSをセットアップして最高の効果を使用できるようにすることができる、ベストエフォルトショートカット最初（存在しない場合）を作成することを推奨しています。終点。（ショートカットは、2つのエンドポイントが異なるIPサブネットに配置されるポイントツーポイントVCです。）データフローの場合、サブネット送信者はすべてのQOS VCを確立する必要があり、RSVP対応サブネットレシーバーはできる必要があります。着信QOS VCを受け入れる。RSVPは、VCの構成可能な非アクティブタイマーを「無限」に設定するように要求する必要があります。VCレシーバーでこれを行うには複雑すぎる場合、ATMの実装を介したRSVPは、受信した接続をクリアして不活性タイマーを使用しないように必要です。動的な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メッセージオブジェクトに差別化されたサービスコードポイント（DSCPS）を運ぶ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）アプリケーション。NULLサービス[RFC2997]により、アプリケーションはRSVPシグナルを使用してQoSポリシーエージェントをネットワークに識別できますが、リソース要件を指定する必要はありません。ネットワーク内のQoSポリシーエージェントは、アプリケーションに適したQoSポリシーを適用することで対応します（ネットワーク管理者によって決定されます）。RSVP送信者は、パスメッセージに含まれるADSPECで、新しいサービスタイプ「Null Service Type」を提供します。新しいサービスタイプに対応する新しい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は、新しいハローメッセージ（迅速なノード障害検出用）を定義します。
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は、セッション、sender_template、およびfilter_specオブジェクトの新しいc-types（lsp_tunnel_ipv4およびlsp_tunnel_ipv6）も定義します。ここでは、セッションは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.
1) rsvpパスメッセージに組み込まれたrebricit_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オブジェクトを使用してパスメッセージを作成できます。label_requestオブジェクトを送信するノードは、対応するRESVメッセージ内のラベルオブジェクトを受け入れ、正しく処理する準備ができている必要があります。
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) ラベルオブジェクト。ラベルオブジェクトを含む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.
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オブジェクトは、PATHメッセージと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では、RSVPへの拡張機能を指定して、MPLSネットワークのDiffServをサポートするLSPを確立し、新しいDiffservオブジェクト（パスメッセージに適用）を導入し、事前に構成または信号を使用して「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.
- LSP_TUNNEL_INTERFACE_IDオブジェクト。隣接するLSRが識別子を形成または使用することを許可します。
- 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に関して、送信される通知を含む場合がある新しいNotifyメッセージ（一般的なイベント通知用）を定義します。通知メッセージは、失敗したLSPの復元を担当するノードに障害やその他のイベントの迅速な通知に使用できます。ルーターアラートオプションなしで通知メッセージが送信されます。
A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for general uses of MPLS:
多数の新しいRSVP-TE（sub）オブジェクトは、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);
- upstream_labelオブジェクト（双方向LSPをサポートするため）;
- a Label ERO subobject;
- ラベルERO SubObject;
- 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)
- RestART_CAPオブジェクト（リカバリ機能を識別するためにHelloメッセージで使用）
- 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
- ユーザーからネットワークインターフェイス（UNIS）がユーザーまたはユーザーネットワークとコアネットワークの間にある場合、または
- 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タイプは必要ありません。[オーバーレイ]を参照してください。
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とGMPLはMPLSおよびCCAMPワーキンググループによって拡張され、追加の洗練された機能をサポートしています。これにより、必然的に既存のオブジェクトに新しいCタイプが導入され、新しいオブジェクト（CNUM）の要件が導入されます。新しいメッセージも導入される可能性があります。
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）を提供する機能が開発されます。 - ポイントツーマルチポイントパスの確立。 - エリア間および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（[H.323]）は、RSVPを使用したIntServリソース予約手順を推奨しています。適切なQoSmodeフィールドを設定することにより、エンドポイントがRSVPをサポートするかどうかについての情報は、H.245 [H.245]能力交換フェーズ中に伝えられるべきです。両方のエンドポイントがRSVP対応である場合、H.245論理チャネルを開くときは、OpenLogicalChannelackメッセージによって受信機ポートIDを送信者に伝える必要があります。その後のみ、「パス-RESV -RESVCONF」プロセスが行われます。ResvConfメッセージを待つタイマーは、エンドポイントによって設定されます。このタイマーが有効期限が切れるか、RSVPの予約がH.323呼び出し中の任意の時点で失敗した場合、アクションはベンダー次第です。RESVCONFメッセージが送信または受信されると、エンドポイントは予約タイマーを停止し、H.323コール手順で再開する必要があります。[H.323]では、予約の明示的な放出のみがサポートされています。ストリームにCloselogicalChannelメッセージを送信する前に、送信者はRSVPセッションがそのストリームのために以前に作成された場合は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 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.
第3世代パートナーシッププロジェクト（3GPP）TS 23.207（[3GPP-TS23207]）は、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）エンドツーエンドQoSアーキテクチャ内のポリシー管理を備えたQoSシグナル伝達手順を指定します。RSVPを使用する場合、シグナリングソースおよび/または宛先は、モバイルオリジニング（MO）側とモバイル終端（MT）側に位置するユーザー機器（UES、ユーザーがネットワークサービスにアクセスできるデバイス）です。RSVPシグナル伝達プロセスは、（COPS）PDPコンテキストの確立/変更プロセスによってトリガーまたはトリガーされる可能性があります。さわやかな状態の動作は[3GPP-TS23207]で指定されていません。双方向の予約が必要な場合、RSVPシグナリング交換は、エンドポイント間で2回実行する必要があります。ポリシーデータオブジェクトの承認トークンとフロー識別子は、UEでトークンが利用可能である場合、UEが送信したRSVPメッセージに含める必要があります。RSVPとサービスベースのローカルポリシーの両方を使用する場合、Gateway GPRSサポートノード（GGSN、ネットワークのアクセスポイント）は、ポリシー情報を使用して、PATH/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つの記事では、アプリケーションの認識なしにホストがRSVPメカニズムの恩恵を受けることを可能にするメカニズムを提示します[MHS02]。
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を要求する場合があります。これは、特にCronsledent Nodeが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デーモンの実行とシグナリングの世話をすることで、不必要なオーバーヘッドが導入される可能性があります。1つの記事[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メッセージは、1つの非フラグメント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には、WildCard-Filter（WF）、固定フィルター（FF）、共有標識（SE）など、包括的なフィルタリングスタイルのセットがあり、特定のQoSオブジェクトに結び付けられていません。（RSVPは、IntServ保証サービス/制御負荷（GS/CL）仕様に結び付けられていません。）オブジェクトはモジュラーになるように設計されていますが、XSPEC（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ヘッダーの新しいPTYPE）として定義されます。RSVPパスメッセージはエンドツーエンドで配信する必要があります。トランジットルーターがパスメッセージを傍受するために、新しい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には適切なメッセージ配信メカニズムがありません。ワイヤーでメッセージが失われた場合、ネットワークによる次の再送信サイクルは、後で1つのソフトステートリフレッシュ間隔になります。デフォルトでは、ソフトステートの更新間隔は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の1対1の高速化[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メッセージには1つのセッションの情報のみを含めることができます。RSVPセッションがかなり多数あるネットワークでは、この制約はルーターに大きな処理負担を課します。多くのルーターOSはUNIXに基づいています。[PS00]は、UNIXソケットI/O処理がパケットサイズにそれほど敏感ではないことを示しました。実際、小さなパケットの処理には、大規模なパケットを処理するのとほぼ同じくらいのCPUパケットが必要です。ただし、個々のメッセージを処理しすぎると、Socket 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.
RSVP-TEは、元のRSVPが設計されたものとは異なる環境で動作します。MPLSネットワークでは、ラベルスイッチパス（LSP）をサポートするために使用される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は、ネットワークエッジから動作するルーティングアルゴリズムであり、LSPの「最も多くの」最適なルートを計算するためです。）その結果、RSVP-TEは大量の「トリガーされた」（新規または修正された）メッセージを処理する必要はありません。。ほとんどのメッセージは更新メッセージであり、RFC2961で導入されたメカニズムで処理できます。特に、概要更新拡張[RFC2961]では、各RSVP更新メッセージは4バイトIDとして表すことができます。ルーターは、IDを交換してRSVPセッションを更新できます。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デザインと相乗的）はこれらの1つです。ネットワークデバイスにアクティブネットワークコードをデポジットするなど、遠いアプリケーションがあります。ネットワークセキュリティ要件、および上記の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メッセージの逆ルートを記録する必要があります）。第二に、RSVPは受信機が開始するため、RESVメッセージの処理中にマルチキャスト予約のさまざまなマージ操作を最適化します。マルチキャストを処理するには、予約スタイル、スコープオブジェクト、遮断状態などの他のメカニズムも、基本プロトコルで提示する必要があります。これにより、障害とエラーの原因が追加されるだけでなく、状態マシンも複雑になります[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) 実装固有のオーバーヘッド。RSVPメッセージを送信および受信するには、プロトコル番号46を持つ「RAW」IPデータグラムとして、またはRSVP処理の効率を高めるカプセル化されたUDPデータグラムとしての2つの方法があります。典型的なRSVP実装は、カーネルと対話するユーザー空間デーモンです。したがって、州の管理、メッセージの送信、および受信は、プロトコル処理の効率に影響します。たとえば、[kss01]で説明されている実装の最近のバージョンでは、メッセージ送信/受信システムが「sendto」、「select」、および「recvmsg」を呼び出すメッセージの相対的な実行コストが6-7％でした。、総実行コストの9〜10％、個別に。[KSS01]は、状態（メモリ）管理が総実行コストの最大17〜18％を使用できることも発見しましたが、標準のメモリ管理を置き換えるために適切なアクションが取られた場合、そのコストを6〜7％に減らすことができます。州情報のための専用のメモリ管理を備えています。RSVP/ルーティング、RSVP/ポリシーコントロール、およびRSVP/トラフィックコントロールインターフェイスも、実装に応じて異なるオーバーヘッドをもたらす可能性があります。たとえば、RSVP/ルーティングオーバーヘッドは、総実行コストの約11〜12％であると測定されています[KSS01]。
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では、PATH/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
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ペイロードサイズBR：RESVメッセージの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は92、BPTは44バイト、RIは30秒です）の場合、帯域幅の消費は次のとおりです。
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メッセージ（パスまたはRESV）で安全な方法で伝えることを許可するために、[RFC3182]はのエンコードを指定します。rsvp policy_dataオブジェクトとしてのアイデンティティ。ただし、Ironcladのセキュリティ保護を提供するには、承認と組み合わせた暗号化認証を提供する必要があります。このような機能は通常、認証と主要な交換プロトコルによって提供されます。ユーザー識別子のみを含めることは不十分です。
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は、偽造およびメッセージの変更に対する保護を提供します。ただし、これは非repudiationを提供したり、メッセージの削除から保護したりしません。現在の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アドレスのいずれかを変更する必要がある場合があります。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.
2番目の問題は、モバイルノードの動きに従うことに関連しています。RFC2205は、パスメッセージが予約パスのローカル修理を実行できることを定義しています。通信エンドホスト間のルートが変更されると、パスメッセージが新しいルートの予約の状態を設定し、その後のRESVメッセージがリソースの予約を行います。したがって、RESVメッセージを送信することにより、ホストは単独で予約を更新することができないため、パスメッセージが渡される前にローカル修理を実行できません。また、短い更新期間のオーバーヘッドなしでルーティングの変更に迅速に適応するために、ローカルルーティングプロトコルモジュールは、特定の宛先のルート変更のRSVPプロセスに通知できます。RSVPプロセスは、この情報を使用して、新しいルート（セクション3.6、[RFC2205]）を使用して、これらの宛先の迅速な状態をリフレッシュする必要があります。ただし、すべてのローカルモビリティプロトコルがルーターで直接ルーティングに影響を与えるわけではないため、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への拡張のためのいくつかの設計がありました。1つのソリューションは[MSK 04]に提示されています。このソリューションでは、1つのセクションでRSVPの結合とモビリティ管理メカニズムについて説明し、RSVPへの小さな拡張機能を提案して、とりわけハンドオーバーイベントをより適切に処理します。この拡張機能により、モバイルホストは、ハンドオーバーが発生したときに下流の予約のパスを要求できます。
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.
もう1つの例は、モバイルRSVP（MRSVP）[TBA01]です。これは、標準のRSVPの拡張です。これは、近隣のアクセスポイントがカバレッジエリアに移動するモバイルノード用のリソースを予約し続ける事前予約に基づいています。モバイルノードがリソースを要求すると、隣接するアクセスポイントもチェックされ、モバイルノードの現在の場所の周りでパッシブ予約が行われます。
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.
Tenetと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.
元のTenetアーキテクチャ[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]は基本的に次のように機能します。送信者は、レシーバーのセットへの接続メッセージを発信します。各中間ノードは次のホップサブネットを決定し、これらの次のホップに行くリンクの予約を行います。接続表示を受信すると、受信者は送信者に受け入れメッセージまたはごみメッセージを送信する必要があります。受け入れの場合、受信者は、返されたフロー仕様を更新することにより、リソース要求をさらに減らすことができます。
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-IIは、データ輸送用のSTとすべての制御機能のストリーム制御メッセージプロトコル（SCMP）の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がグループメンバーシップのダイナミクスを処理するためのオーバーヘッドは、RSVP [MESZ94]のオーバーヘッドよりも高くなっています。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（もう1つの送信者セッションインターネット予約）[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診断メッセージと同様）、広告（RSVP ADSPECと同様）、共有予約、部分的な予約、フローマージをサポートします。
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]などの通常の双方向シグナル伝達プロトコルよりも優れた性能と処理コストが低いことが示されています。Yessirの帯域幅消費量は、たとえばRSVPの帯域幅の消費量よりもやや低いです。これは、追加のIPおよびトランスポートヘッダーを必要としないためです。帯域幅の消費は、拡張ヘッダーサイズに制限されています。
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.
Yessirは、RTCPの不可欠な部分であるため、アプリケーションのサポートが必要です。同様に、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).
Boomerang [FNM 99]は、IPネットワーク用の別のリソース予約プロトコルです。プロトコルには、予約のセットアップと分解のためのメッセージタイプと単一の信号ループのみがあり、遠端ノードには要件がありません。代わりに、開始ノード（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.
さらに、Boomerangプロトコルにより、送信者または受信者指向の予約とリソースクエリが可能になります。フローは一般的な5タプルで識別され、QoSはさまざまな手段で指定できます。たとえば、サービスクラスとビットレート。最初の実装では、BoomerangメッセージはICMPエコー/返信メッセージで転送されます。
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.
Boomerangは、ユニキャストセッションにのみ使用できます。マルチキャストのサポートは存在しません。要求されたQOは、さまざまな方法で指定でき、通信セッションの両端は送信されたフローの予約を行うことができます。
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.
Boomerangの著者は、[FNS02]の著者は、プロトコルの処理がISI RSVPデーモン実装の処理よりもかなり低いことを示しています。ただし、これは主に、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.
Boomerangメッセージは非常に短く、比較的少ないリンク帯域幅を消費します。これは、プロトコルの機能が限られているためです。たとえば、セキュリティ固有の情報やポリシーベースの相互作用は提供されていません。送信者志向であるため、帯域幅の消費は主に送信者から受信機への下流方向に影響します。
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.
Boomerangは送信者向けであるため、後方情報を保存する必要はありません。これにより、必要なシグナル伝達が減少します。RSVPで特定された残りの問題は、Boomerangに適用されます。Boomerangにはセキュリティメカニズムは指定されていません。
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.
Boomerangプロトコルには、ホストネットワークホストプロトコルの問題と同様の展開の問題があります。通信ノードとルーターの両方で実装が必要です。Boomerang-Unawareルーターは、ブーメランメッセージを透過的に転送できるはずです。それでも、ファイアウォールは多くの場合、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.
Boomerangは非常に軽量なプロトコルであり、独自のシナリオで効率的であるようです。ただし、限られた機能によると、見かけの低い処理オーバーヘッドと帯域幅の消費が生じます。マルチキャストやセキュリティ機能のサポートは存在しません。これにより、著者はBoomerangを比較したい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]は、モバイルアドホックネットワークでQOをサポートするための非常に簡単なシグナル伝達メカニズムとして提案されています。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.
Insigniaプロトコルはネットワークレイヤーで動作し、リンクステータスセンシングとアクセススキームが低層エンティティによって提供されると想定しています。スキームの有用性はMACレイヤーに依存しますが、これは未定義であるため、記章は任意の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は、ソースが送信するトラフィックの性質について多くの仮定を行います。これにより、入学制御とバッファの割り当てが簡素化される場合があります。システムは基本的に、「リアルタイム」が最大遅延として定義されると想定しており、ユーザーは特定の量のトラフィックに対してリアルタイムサービスを要求できます。
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.
ただし、記章には（完全に）セキュリティフレームワークがなく、参加しているノード間に比較的弱い信頼または信頼が存在しないアドホックネットワークでシグナル付き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.
Border Gateway Reservation Protocol（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]は、境界ルーター（BRSで必要な状態を減らすために、自律系（AS）レベルで共有セグメント集約[SGV02]を実行するドメイン間シグナル伝達ソリューションです。）。SICAPは、異なる予約が共有するパスセグメントに基づいて集約を実行します。したがって、予約は、必ずしも予約の目的地まで伸びるとは限らない骨材にマージされる場合があります。「より短い」集合体を作成する動機は、一方で、将来の要求をより簡単に対応する能力、そして他方で作成された集合体の最小化と、その結果、確立された予約を管理するために必要な状態の削減が最小化されることです。ただし、シンクツリーアプローチ（BGRP [BGRP]で使用）とは対照的に、共有セグメントアプローチでは、中間の凝集場所を導入します。これらは、集合体が「再凝集」を経験する可能性があるASEです。これらの場所では、（出口ルーターとして）集約を実行するルーターは、予約と集合体の間のマッピングを追跡する必要があります。これを行う可能性のある方法の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によって大幅に減少するBRSで維持されている状態です。これは、BGRPのより良いパフォーマンスの代替品を提供するためではなく、コントロールパス集約の研究分野でまだ利用可能なパフォーマンスの改善を定量化するために重要であると考えています。最後に、シグナリング負荷の可能な問題に対処するために、SICAPは過剰保存メカニズム[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）パス（またはその部分）に沿って予約を集約します。データパスが共通のASEのシーケンスを共有する一連の予約は、その共有サブパスに沿って共同予約の集計に統合されます。集合体内のすべてのエンティティは、集計の開始点とエンドポイントを除き、含まれている個々の予約の状態情報を削除し、それにより状態を節約できます。彼らは、包括的な総合に関する必要な情報を保持する必要があります。さらに、これらの中間ASEは、集約された予約に関連するシグナル伝達にもはや関与していません。実際に必要とされるよりも多くの集約リソースが予約されている場合、集約の容量は、新しいまたはリリースされた予約ごとに適応する必要はありません（それにより、メッセージ交換の数を減らします）。
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つのASEの間の集合体は、それらの間の一方向の予約のアクティブな数を説明するしきい値kを超えるとすぐに作成されます。ただし、異なる集約トリガーを適用することは可能です。さらに、Darisでは、集合体を階層的にネストすることができます。したがって、より短い凝集体の存在は、より長い（したがってより効率的な）凝集体の作成を妨げるものではなく、逆も同様です。[Bless02]の最近のBGPルーティング情報の評価により、すべてのエンドツーエンドパスの92％に少なくとも4つのASが含まれていることが示されました。その結果、エッジから4つ以上のASEにまたがる可能性のあるエッジからの集合体であるため、状態を保存し、少なくとも2つのASEでメッセージ処理を信号します。
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内の個々の留保に関連する州情報の事前の削除によって引き起こされます。これは、ASEの間で予約または集合体が再ルーティングされる場合にも困難をもたらす可能性があります。これらの特別なケースの洗練された適応技術を定義する方法を検討する際には、非常に複雑になるように見えるため、注意する必要があります。
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（ドメインマネージャーシグナリングプロトコル）は、場合によっては1回の往復時間の予約セットアップ時間を短縮する特別な拡張により集約をサポートします（たとえば、新しい予約を含める前に集計容量を増やす必要がある場合）。詳細は[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以上のASEで構成されるトポロジを使用したシミュレーションを使用して評価されました。凝集していないシナリオと比較して、保存された状態の数は1〜2桁の範囲にあり、シグナリングメッセージの数に関して同様の結果が得られました。[Bless02]は、分散ドメイン管理エンティティ（帯域幅ブローカーと同様）のコンテキストでDarisを説明していますが、ルーターベースのリソース管理環境にも適用できます。これにより、より高い程度の分布が実現します。これは、非常に相互接続されている大きなASEにとって有益です。
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.
集約の一般的な問題は、開始した集合体から利益を得るのはASEの集約と凝集ではなく、すべての中間ASEが骨材内であることです。したがって、総作成のインセンティブを与えなければなりません。これは、将来的に集約概念のために開発する必要がある新しいコストモデルにつながる可能性があります。
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が提供するセキュリティプロパティの詳細を提供します。さらに、モバイルノードとの間で安全で効率的なシグナル伝達は、既存のプロトコルによって完全に満たされていない重要な課題の1つです。
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シグナリングプロトコルを一般的なメッセンジャーに移動すると、多くの採用が得られます。将来のプロトコルの開発は、既存のプロトンのレッスンから学ぶべきであると予想されます。それにもかかわらず、予想される機能、プロトコルの複雑さ/パフォーマンスの間のトレードオフは依然として考慮されます。たとえば、RSVPは双方向シグナル伝達メカニズムを使用しますが、Yessirは1パスシグナルのみを採用しています。どちらも、特定の慎重に選択されたシグナリングシナリオで、他のパフォーマンスを発揮することが示されます。
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ワーキンググループで行われた作業の一部です。このドキュメントは、当初、Jukka MatherとXiaoming Fuによって書かれました。最初のバージョン以来、Martin KarstenはRSVPの処理オーバーヘッドに関するテキストを提供し、Hannes Tschofenigはプロトコル内のさまざまなセキュリティ問題に関するテキストを提供しています。Henning SchulzrinneとPing Panは、2回目の改訂後、RSVP輸送に関する詳細情報を提供しています。Kireeti KompellaとAdrian Farrelは、RSVP-TEおよびGMPLSに関する議論のレビューと更新を提供しました。
We would like to acknowledge Bob Braden and Vlora Rexhepi for their useful comments.
Bob Bradenと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. NSIはモジュール式に設計する必要があります
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はエンドツーエンドのみに機能しますが、RSVPプロキシ[BEGD02]と局所RSVP [MSK 04]はこの仮定を緩和しています。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はパス結合されていますが、Subnet Bandwidth Manager（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.
これはIntServサービスの種類に依存し、制御された負荷は保証されたサービスよりも優れた全体的な利用を提供できます。
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. Uni / Bi-Directional State Setup
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.
RSVPでは、PDPによる承認が可能です。
5.7.3. Integrity Protection
5.7.3. 整合性保護
The INTEGRITY Object is available in RSVP.
整合性オブジェクトは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.
リプレイする整合性オブジェクトは、2つの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.
整合性オブジェクトは、この目的に使用できます。
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.
警官と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] Brunner、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] Braden、R.、Estrin、D.、Berson、S.、Herzog、および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。Gai、およびD. Dutt、「RSVP Proxy」、2002年3月、進行中の作業。
[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。Ferrari、B。Mah、M。Moran、D。Verma、およびH. Zhang、「TheTenetリアルタイムプロトコルスイート：設計、実装、および経験」、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. Pan、E、Hahne、およびH. Schulzrinne、「Bgrp：ドメイン間予約のためのツリーベースの集約プロトコル」、Journal of Communications and Networks、vol。2、No。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.
[Bless02] R. Bless、「インターネットサービスの予約の動的集約」、電気通信システムに関する第10回国際会議の議事録 - モデリングと分析（ICTSM 10）、Vol。1、pp。26-38、2002年10月3〜6日、カリフォルニア州モントレー、http：//www.tm.uka.de/doc/2003/ictsm-daris-journal-crc-web.pdfで入手可能。
[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. Bless、「QoSベースのエンドツーエンドサービスのスケーラブルな管理に向けて」（PDF）、Proceedings of 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. Pan、G。Wallow、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速再拡張」、2004年1月、進行中の作業。
[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、「BoomerangはIPネットワークでのリソース予約のための簡単なプロトコル」、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）、pp。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] P. Fransson and A. Jonsson、「IPv4-Optionsに代わるものの必要性」、RVK（Radiovetenskap Och Kommunikation）、ストックホルム、スウェーデン、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. Fu、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] Jukka Mather、Kimmo Raatikainen、「ワイヤレスアクセスネットワークのマルチメディアアプリケーション用のローカライズされたQoS管理」。インターネットおよびマルチメディアシステムおよびアプリケーションに関するIasted International Conference（IMSA 2003）、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. Karsten、「RSVPへの実験的拡張 - リモートクライアントとワンパスシグナリング」。IWQOS 2001、Karlsruhe、ドイツ、2001年6月。
[KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz, "Implementation and Evaluation of the KOM RSVP Engine", IEEE Infocom 2001.
[KSS01] M. Karsten、Jens Schmitt、Ralf Steinmetz、「KOM RSVPエンジンの実装と評価」、IEEE Infocom 2001。
[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. Lee、A。Gahng-Seop、X。Zhang、A。Campbell、「記章：モバイルアドホックネットワーク用のIPベースのサービスフレームワーク」。Journal of Parallel and Distributed Computing（Academic Press）、ワイヤレスおよびモバイルコンピューティングとコミュニケーションに関する特別号、Vol。60、番号4、2000年4月、pp。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. Moon、およびH. Aghvami、「ワイヤレスモバイルネットワークでのリアルタイムサービス用のRSVP拡張」。IEEE Communications Magazine、2001年12月、pp。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. Zhang、「St-IIとRSVPの建築比較」、Infocom 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 Miao、W。Hwang、およびC. Shieh、「UNIXでのRSVP対応アプリケーションの透明な展開方法」。Computer Networks、40（2002）、pp。45-56。
[MSK+04] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K. Raatikainen, "Localized RSVP", Work in Progress, September 2004.
[MSK 04] J. Mater、T。Suihko、M。Kojo、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.
[オーバーレイ] G.スワロー、J。ドレイク、H。石島、およびY.レクター、「GMPLS UNI：オーバーレイモデルのRSVPサポート」、2004年2月、Work in Progress。
[PS97] P. Pan and H. Schulzrinne, "Staged refresh timers for RSVP", Global Internet, Phoenix, Arizona, November 1997.
[PS97] P. Panおよび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. Pan、およびH. Schulzrinne、「Yessir：インターネットの単純な予約メカニズム」。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. Pan、およびH. Schulzrinne、「PF_IPOPTION：IPオプションパケット処理のカーネル拡張」、技術覚書100096669-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. Berger、「Internet Stream Protocolバージョン2（ST2）プロトコル仕様 - バージョンST2」、RFC 1819、1995年8月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207] Berger、L。およびT. O'Malley、「IPSECデータフローのRSVP拡張」、RFC 2207、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2379] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24, RFC 2379, August 1998.
[RFC2379] Berger、L。、「ATM実装ガイドラインをめぐるRSVP」、BCP 24、RFC 2379、1998年8月。
[RFC2380] Berger, L., "RSVP over ATM Implementation Requirements", RFC 2380, August 1998.
[RFC2380] Berger、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.、Braden、B.、Vincent、S。、およびL. Zhang、「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. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[RFC2749] Herzog、S.、Boyle、J.、Cohen、R.、Durham、D.、Rajan、R.、およびA. Sastry、「RSVPのCOPS使用」、RFC 2749、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750] Herzog、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.、Hoffman、D.、Bernet、Y.、Baker、F。、およびM. Speer、 "SBM（Subnet Bandwidth Manager）：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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F.、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、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.、Smith、A。、およびB. Davie、「ヌルサービスタイプの仕様」、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.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J。、およびEFelstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「IPv4およびIPv6予約のRSVPの集約」、RFC 3175、2001年9月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001
[RFC3181] Herzog、S。、「シグナル前の先制優先政策要素」、RFC 3181、2001年10月
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182] Yadav、S.、Yavatkar、R.、Pabbati、R.、Ford、P.、Moore、T.、Herzog、S。、およびR. Hess、「RSVPのアイデンティティ表現」、RFC 3182、2001年10月。
[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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（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.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、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] Berger、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] Hamer、L-N。、Gage、B.、Kosinski、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. Sofia、R。Guerin、およびP. Veiga、「ドメイン間対照凝集手順の調査」、2002年11月、フランス、パリ、ICNP 2002、ICNP 2002、ICNP 2002に関する国際会議。
[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. veiga。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。Guerin、およびP. Veiga。ドメイン間コントロール凝集プロトコルの過剰保存の研究。2003年5月、ペンシルバニア大学、テクニカルレポート（提出中の短いバージョン）、http：//einstein.seas.upenn.edu/mnlab/ publications.htmlで入手可能。
[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。Badrinath、およびA. Acharya、「MRSVP：モバイルホストとの統合サービスネットワークのリソース予約プロトコル」、Wireless Networks、Vol。7、いいえ。1、pp。5-19、2001。
[Thom02] M. Thomas, "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.
[Thom02] M. Thomas、「モバイル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. Zhang、S。Deering、D。Estrin、およびD. Zappala、「RSVP：新しいリソース予約プロトコル」、IEEEネットワーク、第7巻、8〜18ページ、1993年9月。
[URL1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
[url1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
[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
ジュッカマナーコンピュータサイエンス大学ヘルシンキP.O.Box 68（Gustav Hallstrominkatu 2b）Fin-00014 Helsinki Finland
Phone: +358-9-191-51298
Fax: +358-9-191-51120
EMail: jmanner@cs.helsinki.fi
Xiaoming Fu Institute for Informatics Georg-August-University of Goettingen Lotzestrasse 16-18 37083 Goettingen Germany
Xiaoming Fu Institute for Informatics Georg-August-University of Goettingen Lotzestrasse 16-18 37083 Goettingenドイツ
Phone: +49-551-39-14411
Fax: +49-551-39-14403
EMail: fu@cs.uni-goettingen.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。