RFC4094 日本語訳
4094 Analysis of Existing Quality-of-Service Signaling Protocols. J.Manner, X. Fu. May 2005. (Format: TXT=103146 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Manner Request for Comments: 4094 X. Fu Category: Informational May 2005
コメントを求めるワーキンググループJ.方法要求をネットワークでつないでください: 4094年のX.フーカテゴリ: 情報の2005年5月
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)インターネット協会(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ネットワークのためにプロトコルに合図しながら、Service(QoS)のいくらかの既存のQualityを見直します。 ここの目標は、それらから学んで、ありがちな誤解を避けることです。 さらに、私たちは、この領域のどんな新しいプロトコルの設計と実装の間も、間違いを避ける必要があります。
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
1. 序論…3 2. RSVPとRSVP拡張子…4 2.1. 基本的なデザイン…4 2.1.1. シグナリングはモデル化されます…4 2.1.2. 柔らかい状態…5 2.1.3. ツー・パスシグナリング交換処理…5 2.1.4. 受信機ベースの資源予約…5 2.1.5. ルート設定から合図するQoSの分離…5 2.2. RSVP拡張子…6 2.2.1. 簡単なトンネリング…6 2.2.2. IPsecは連結します…6 2.2.3. 方針インタフェース…6 2.2.4. 減少をリフレッシュしてください…7 2.2.5. RSVPの上のRSVP…8 2.2.6. 802様式のIEEE LANインタフェース…8 2.2.7. 気圧インタフェース…9 2.2.8. DiffServは連結します…9 2.2.9. ヌルサービスタイプ…9 2.2.10. MPLS交通工学…10 2.2.11. GMPLSとRSVP-Te…11
Manner & Fu Informational [Page 1] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[1ページ]のRFC4094Analysis
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
2.2.12. UNIでのGMPLS操作と電子NNI参照は示されます…12 2.2.13. MPLSとGMPLSの将来の拡張子…12 2.2.14. ITU-T H.323は連結します…13 2.2.15. 3GPPは連結します…13 2.3. 新しい展開シナリオのための拡大…14 2.4. 結論…15 3. RSVPはメカニズム問題を輸送します…16 3.1. メッセージングの信頼性…16 3.2. メッセージパッキング…17 3.3. MTU問題…17 3.4. RSVP-Te対RTアプリケーションのためにプロトコルに合図します…18 3.5. より良い代替手段は何でしょうか? .......................18 4. RSVPはパフォーマンス問題について議定書の中で述べます…19 4.1. オーバーヘッドを処理します…19 4.2. 帯域幅消費…20 5. RSVPセキュリティと移動性…21 5.1. セキュリティ…21 5.2. 移動性サポート…22 6. 他のQoSシグナリング提案…23 6.1. そして、主義、第-、II、…23 6.2. YESSIR…24 6.2.1. 予約の機能性…24 6.2.2. 結論…25 6.3. やぶへびになってください…25 6.3.1. 予約の機能性…25 6.3.2. 結論…26 6.4. 記章…26 7. 相互ドメインシグナリング…27 7.1. BGRP…27 7.2. SICAP…27 7.3. ダリー語…28 8. セキュリティ問題…30 9. 概要…30 10. 貢献者…31 11. 承認…31 12. 付録A: NSIS要件へのRSVPの比較…32 13. 標準の参照…38 14. 有益な参照…38
Manner & Fu Informational [Page 2] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[2ページ]のRFC4094Analysis
1. Introduction
1. 序論
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、(YEt、予約) 別のSender Sessionインターネット[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.
以前、多くの仕事が資源管理のために新しいシグナリングプロトコルを作成するのに狙いました。 イシュトバーン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".
マイケルWelzlは、SCI2001で特別なセッション「インターネットへのABR」を組織化して、インターネット(e2e、edge2edge)への明白なレートフィードバック関連のメカニズムを紹介するよう意図したIETF#51における「インターネットへのABR」BOFに要求するためにいくつかの入力を集めました。 これは「なくなった共同体関心」で失敗しました。
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]は長年インターネットシグナリングにかかわっています。 ピングPanは、軽量のインターネットシグナリングを調査するためにSIGLITE[URL3]BOFメーリングリストを開始しました。 最終的に、NSIS BOFはうまくいきました、そして、NSIS WGは形成されました。
Manner & Fu Informational [Page 3] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[3ページ]のRFC4094Analysis
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の中の仕事への関連性に基づいて選ばれています。 目的はあらゆる既存のプロトコルを見直すというわけではないことです。
2. RSVP and RSVP Extensions
2. RSVPとRSVP拡張子
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(Resource予約プロトコル)[ZDSZ93][RFC2205][BEBH96]は、アプリケーションデータ・ストリームのための終わりから終わりに対するQoSシグナリングサービスを提供するためにST-IIから発展しました。ホストは、特定用途のためのネットワークからの特定のサービスの質(QoS)が流れるよう要求するのにRSVPを使用します。 ルータは、データ経路に沿ったすべてのルータへの要求をQoSに提供するのにRSVPを使用します。 RSVPも要求されたQoSアプリケーション流動のために州を維持して、リフレッシュできます。
By original design, RSVP fits well into the framework of the Integrated Services (IntServ) [RFC2210] [BEBH96] with certain modularity and scalability.
当初の設計で、RSVPはあるモジュール方式とスケーラビリティがあるIntegrated Services(IntServ)[RFC2210][BEBH96]のフレームワークによく収まります。
RSVP carries QoS signaling messages through the network, visiting each node along the data path. To make a resource reservation at a node, the RSVP module communicates with two local decision modules, admission control and policy control. Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control provides authorization for the QoS request. If either check fails, the RSVP module returns an error notification to the application process that originated the request. If both checks succeed, the RSVP module sets parameters in a packet classifier and packet scheduler to obtain the desired QoS.
データ経路に沿った各ノードを訪問して、RSVPはネットワークを通してQoSシグナリングメッセージを伝えます。 ノードで資源予約をするように、RSVPモジュールは2つのローカルの決定モジュール、入場コントロール、および方針コントロールとコミュニケートします。 入場コントロールは、ノードには要求されたQoSを供給できるくらいの利用可能資源があるかどうか決定します。 方針コントロールはQoS要求に承認を提供します。 どちらのチェックも失敗するなら、RSVPモジュールは要求を溯源したアプリケーション・プロセスにエラー通知を返します。 両方のチェックが成功するなら、RSVPモジュールは、必要なQoSを入手するためにパケットクラシファイアとパケットスケジューラにパラメタをはめ込みます。
2.1. Basic Design
2.1. 基本的なデザイン
The design of RSVP distinguished itself by a number of fundamental ways; particularly, soft state management, two-pass signaling message exchanges, receiver-based resource reservation, and separation of QoS signaling from routing.
RSVPのデザインは多くの基本的な方法でそれ自体を区別しました。 特にルーティングから合図するQoSの軟性国家管理、ツー・パスシグナリング交換処理、受信機ベースの資源予約、および分離。
2.1.1. Signaling Model
2.1.1. シグナリングモデル
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
RSVPシグナリングモデルはマルチキャストの特別な取り扱いに基づいています。 マルチキャスト流動の送付者は「経路」メッセージでトラフィックの特性の受信機に定期的に広告を出します。 広告を受け取り次第、受信機は流路に沿って送付者からリソースを予約する"Resv"メッセージを生成するかもしれません。 受信機の予約は異種であるかもしれません。 多点から多点へのマルチキャストアプリケーションを収容するなら、RSVPは、「スタイル」と呼ばれる予約属性のベクトルをサポートするように設計されました。 スタイルは説明します。
Manner & Fu Informational [Page 4] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[4ページ]のRFC4094Analysis
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.
マルチキャストグループのすべての送付者がただ一つの予約を共有します、そして、どの受信機が適用されていますか? 「範囲」オブジェクトはさらに、送付者の明白なリストを提供します。
2.1.2. Soft State
2.1.2. 軟性国家
Because the number of receivers in a multicast flow is likely to change, and the flow of delivery paths might change during the life of an application flow, RSVP takes a soft-state approach in its design, creating and removing the protocol states (Path and Resv states) in routers and hosts incrementally over time. RSVP sends periodic refresh messages (Path and Resv) to maintain its states and to recover from occasional lost messages. In the absence of refresh messages, the RSVP states automatically time out and are deleted. States may also be deleted explicitly by PathTear, PathErr with Path_State_Removed flag, or ResvTear Message.
マルチキャスト流動における、受信機の数が変化しそうであって、配送経路の流れがアプリケーション流動の寿命の間、変化するかもしれないので、RSVPはデザインにおける軟性国家アプローチを取ります、時間がたつにつれてルータとホストでプロトコル州(経路とResv州)を増加して創設して、取り除いて。 RSVPは周期的に発信します。州を維持して、時々の無くなっているメッセージから回復するメッセージ(経路とResv)をリフレッシュしてください。 が不在のとき、メッセージをリフレッシュしてください、RSVPは自動的にタイムアウトを述べて、削除されます。 また、州はPathTear、Removedが旗を揚げさせるPath_州_とPathErr、またはResvTear Messageによって明らかに削除されるかもしれません。
2.1.3. Two-Pass Signaling Message Exchanges
2.1.3. ツー・パスシグナリング交換処理
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要求は合併されるかもしれません、多くの受信機があるときよく比例するプロトコルをもたらして。
2.1.4. Receiver-Based Resource Reservation
2.1.4. 受信機ベースの資源予約
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ノードのための、より少ないシグナリング操作をもたらすことができましたが、受信機開始に制限を紹介するかもしれません。
2.1.5. Separation of QoS Signaling from Routing
2.1.5. ルート設定から合図するQoSの分離
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はデータ経路に沿った予約セットアップだけに責任があります。
Manner & Fu Informational [Page 5] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[5ページ]のRFC4094Analysis
A number of messages and objects have been defined for the protocol. A detailed description is given in [RFC2205].
多くのメッセージとオブジェクトがプロトコルのために定義されました。 [RFC2205]で詳述を与えます。
2.2. RSVP Extensions
2.2. RSVP拡張子
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-TE[RFC3209](交通工学のためのRSVP拡張子)は多くのネットワーク内の提供者によって広く配布されて、MPLSがアプリケーションであるとサポートしました。
There are a large number of protocol extensions based on RSVP. Some provide additional features, such as security and scalability, to the original protocol. Some introduce additional interfaces to other services, such as DiffServ. And some simply define new applications, such as MPLS and GMPLS, that are completely irrelevant from protocol's original intent.
RSVPに基づく多くのプロトコル拡大があります。 或るものはセキュリティやスケーラビリティなどの付加的な機能をオリジナルのプロトコルに提供します。 或るものはDiffServなどの他のサービスに追加インタフェースを紹介します。 そして、或るものは単にMPLSやGMPLSなどのプロトコルの当初の意図によって完全に無関係の新しいアプリケーションを定義します。
In this section, we list only IETF-based RFCs and a limited set of other organizations' specifications. Informational RFCs (e.g., RFC2998 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not covered here.
このセクションで、私たちはIETFベースのRFCsと限られたセットの他の組織の仕様だけをリストアップします。 情報のRFCs(例えば、RFC2998[RFC2998])と処理中の作業I-Ds(例えば、プロキシ)はここにカバーされていません。
2.2.1. Simple Tunneling
2.2.1. 簡単なトンネリング
[RFC2746] describes an IP tunneling enhancement mechanism that allows RSVP to make reservations across all IP-in-IP tunnels, basically by recursively applying RSVP over the tunnel portion of the path.
[RFC2746]はRSVPが経路のトンネルの部分の上にRSVPを再帰的に付けることによってIPにおけるIPが基本的にトンネルを堀るすべての向こう側に予約をすることができるIPトンネリングエンハンスメカニズムについて説明します。
2.2.2. IPsec Interface
2.2.2. IPsecインタフェース
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は流れ基礎あたりのaの代わりに1プロトコルあたりのアドレスベースのIPsecをサポートすることができます。 [RFC2207]は、UDP/TCPのようなポートに代わってIPsec Security Parameter Index(SPI)を使用することによって、RSVPを広げています。 これは新しいFILTER_SPECオブジェクトと新しいSESSIONオブジェクトを導入します。(それは、IPsec SPIを含みます)。
2.2.3. Policy Interface
2.2.3. 方針インタフェース
[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
[RFC2750]はPOLICY_DATAオブジェクトの形式と方針イベントのRSVPの取り扱いを指定します。 それは政策決定ポイント(PDPs)と対話する方針意識しているノード(PEPs)だけによって解釈されるオブジェクトを導入します。 POLICY_DATAオブジェクトを解釈できないノードは方針無知なノード(暗証番号)と呼ばれます。 The
Manner & Fu Informational [Page 6] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[6ページ]のRFC4094Analysis
content of the POLICY_DATA object itself is protected only between PEPs and therefore provides end-to-middle or middle-to-middle security.
POLICY_DATAオブジェクト自体の内容は、PEPsだけの間に保護されて、したがって、中央から終わりから中央か中央へのセキュリティを提供します。
[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]は先取り優先権方針要素(PREEMPTION_PRI)をRSVP POLICY_DATA Objectによる使用に指定します。 [RFC3520]はRSVPの中で承認トークンの助けでどう別々のプロトコル(SIPなどの)によって提供された承認を再利用できるかを説明します。 したがって、トークンは認可された情報(例えば、QoSパラメタ)自体かそれらの値の参照のどちらかを含むかもしれません。 トークンは保護がないかもしれません(強くがっかりしています)。左右対称の、または、非対称の暗号に基づいて、保護されています。 そのうえ、ドキュメントはPOLICY_DATAオブジェクトとしてコード化されたセッション承認情報をホストに提供する方法を説明します。
2.2.4. Refresh Reduction
2.2.4. 減少をリフレッシュしてください。
[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:
処理オーバヘッド要件を減らすメカニズムは、メッセージをリフレッシュして、潜在が被ったRSVPメッセージが無くなる州の同期を排除して、全体の送信なしで状態をリフレッシュします。[RFC2961]が説明する、メッセージをリフレッシュしてください。 それは以下のオブジェクトを定義します: _MESSAGE_ID、MESSAGE_ID ACK、_MESSAGE_IDナック、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) バンドルメッセージはボディーの成っているものか、より標準の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メッセージが_1MESSAGEの_ID ACKを運ぶか、またはMESSAGE_ID_ナックは反対します。 メッセージの損失を検出して、1ホップあたり1個のベースで信頼できるRSVPがメッセージ配送であるとサポートするために隣接しているRSVPノードの間にACKメッセージを送ります。
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メッセージは1MESSAGE_ID LIST、MESSAGE_ID SRC_LIST、およびMESSAGE_ID MCAST_LISTオブジェクトを運びます。 彼らは州を設立するPathとResvメッセージに対応します。 Srefreshメッセージは、標準のPathかResvメッセージを送らないでRSVP州をリフレッシュするのに使用されます。
Manner & Fu Informational [Page 7] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[7ページ]のRFC4094Analysis
2.2.5. RSVP over RSVP
2.2.5. RSVPの上の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セッションの数は減少できます。 プロトコルタイプは、集合領域に入るとき、2EのE(標準の)経路、PathTear、およびResvConfメッセージでRSVPから2RSVP EのE-IGNOREまで交換されて、いなくなるとき、交換されます。 新しいPathErrコード(AGGREGATE_が必要としたNEW_)に加えて、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) SESSION(2つの値を含む)は反対します: 集合セッションの目的地のIP Address、およびそれが予約が含む2EのEデータで使用するDifferentiated Services Code Point(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) FILTER_SPEC(集合予約のために集合ルータを特定して、シンタクス上SENDER_TEMPLATEオブジェクトと同じである)は反対します。
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シグナリングの見解と集合領域のデータ・パケットの取り扱いによって、これらのケースは2ユーロのE RSVPの予約に集めるものに同等です。 唯一の違いは何らかの追加知識が2EのE RSVPシグナリングは行われないで、したがって、引き金として使用できないので集合予約をセットアップするのに必要であるということです。
2.2.6. IEEE 802-Style LAN Interface
2.2.6. 802様式のIEEE LANインタフェース
[RFC2814] introduces an RSVP LAN_NHOP address object that keeps track of the next L3 hop as the PATH message traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP nodes). Both layer-2 and layer-3 addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is used to include the Layer-2 address (L2ADDR) of the previous hop, complementing the L3 address information included in the RSVP_HOP object (RSVP_HOP_L3 address).
[RFC2814]はPATHメッセージが2つのL3実体(RSVP PHOPとNHOPノード)の間のL2ドメインを横断するとき次のL3ホップの動向をおさえるRSVP LAN_NHOPアドレスオブジェクトを導入します。 層-2と層-3つのアドレスの両方がラン_NHOPに含まれています。 RSVP_HOP_L2オブジェクトは前のホップのLayer-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は経路に沿って受信機から特定の送付者まで情報を述べます。
Manner & Fu Informational [Page 8] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[8ページ]のRFC4094Analysis
2.2.7. ATM Interface
2.2.7. 気圧インタフェース
[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実施要綱とATM(フォーラム)と共にUNI 3.x/4.0を織り込むという要件の上でRSVPを定義します。 [RFC2380]はRSVP(コントロール)メッセージとRSVP関連データパケットを同じ仮想の回路(VCs)に送ってはいけなくて、推進RSVPコントロールメッセージのためのVCがいったん終わるとRSVPの関連QoS VCsの明白なリリースを実行しなければならないと述べます。 また、推進RSVPコントロールメッセージに、別々のコントロールVCも可能ですが、[RFC2379]は、最初に(1つが存在していないなら)ベストエフォート型ショートカットを作成するとベストエフォート型エンドポイントが使用されることを勧めます。(作成はRSVPによって引き起こされたVCsをセットアップできます)。 (ショートカットは2つのエンドポイントが異なったIPサブネットで位置している二地点間VCです。) データフローに関しては、サブネット送付者はすべてのQoS VCsを設立しなければなりません、そして、RSVPによって可能にされたサブネット受信機は入って来るQoS VCsを受け入れることができなければなりません。 RSVPは、VCsの構成可能な不活発タイマが「無限」に設定されるよう要求しなければなりません。 VC受信機にこれをするのが複雑過ぎるなら、ATM実装の上のRSVPは、どんな容認された接続もきれいにするのに不活発タイマを使用してはいけません。 ダイナミックなQoSに関しては、優雅にVCの交換をするべきです。
2.2.8. DiffServ Interface
2.2.8. DiffServインタフェース
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メッセージオブジェクトでDifferentiated Services Code Points(DSCPs)を運ぶためにDCLASS Objectを導入します。 ネットワーク要素が、RSVP要求がDiffServネットワークに容認できることを決定すると、振舞い集合に対応する1DSCPsが断固として、RESVメッセージ上流に加えられたDCLASS ObjectによってRSVP送付者に向かって運ばれるでしょう。
2.2.9. Null Service Type
2.2.9. ヌルサービスタイプ
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 Service[RFC2997]は、アプリケーションがネットワークQoS方針エージェントに自分たちを特定するのをRSVPシグナリングを使用することで許容しますが、彼らがリソース要件を指定するのを必要としません。 ネットワークのQoS方針エージェントは、アプリケーションに、適切なQoS方針を適用することによって、応じます(ネットワーク管理者によって決定されるように)。 送付者が新しいサービスを提供するRSVPは、'ヌルService Type'とタイプします、PATHメッセージで含まれているADSPECで。 新しいサービスタイプにおいて、対応する新しいTSPECはSENDER_TSPECに加えられます。 さらに、PATHメッセージ政策目的がユーザとアプリケーションとサブ流動を特定している状態で、RSVP送付者は通信員交通の流れを通常入れるでしょう。(ネットワーク・ノードが管理するのに流動は使用されるでしょう)。
Manner & Fu Informational [Page 9] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[9ページ]のRFC4094Analysis
2.2.10. MPLS Traffic Engineering
2.2.10. MPLS交通工学
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を使用することで規制ベースの明らかに発送されたLSPsをMPLSネットワークに設立するとコア拡大をRSVPに指定します。 RSVP-TEはルータ(ホストと同様に)を切り換えるラベルによる使用のためにLSP-トンネルを確立して、維持して、そのようなLSP-トンネルへのネットワーク資源を予約することを意図します。
RFC3209 defines a new Hello message (for rapid node failure detection).
RFC3209は新しいHelloメッセージ(急速なノード障害検出のための)を定義します。
RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects. Here, a session is the association of LSPs that support the LSP-tunnel. The traffic on an LSP can be classified as the set of packets that are assigned the same MPLS label value at the originating node of an LSP-tunnel.
また、RFC3209はSESSION、SENDER_TEMPLATE、およびFILTER_SPECオブジェクトのための新しいC-タイプ(LSP_TUNNEL_IPv4とLSP_TUNNEL_IPv6)を定義します。 ここで、セッションはLSP-トンネルを支えるLSPsの協会です。 LSP-トンネルの起因するノードにおける同じMPLSラベル価値が割り当てられるパケットのセットとしてLSPの上のトラフィックを分類できます。
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) EXPLICIT_ROUTEオブジェクト(ERO)。(明らかに発送された経路を構成するホップの連結をカプセル化して、そのオブジェクトはRSVP Pathメッセージに組み入れられます)。 このオブジェクトを使用して、従来のIPルーティングの如何にかかわらずラベルで切り換えられたRSVP-MPLS流れによって取られた経路は予定できます。
2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can
create a Path message with a LABEL_REQUEST object. A node that
sends a LABEL_REQUEST object MUST be ready to accept and correctly
process a LABEL object in the corresponding Resv messages.
2) LABEL_REQUESTは反対します。 LSPトンネルを証明するために、送付者はLABEL_REQUESTオブジェクトでPathメッセージを作成できます。 LABEL_REQUESTオブジェクトを送るノードは、受け入れて、対応するResvメッセージで正しくLABELオブジェクトを処理する準備ができているに違いありません。
3) LABEL object. Each node that receives a Resv message containing a
LABEL object uses that label for outgoing traffic associated with
this LSP tunnel.
3) LABELは反対します。 LABELオブジェクトを含むResvメッセージを受け取る各ノードはこのLSPトンネルに関連している外向的なトラフィックにそのラベルを使用します。
4) SESSION_ATTRIBUTE object, which can be added to Path messages to
aid in session identification and diagnostics. Additional control
information, such as setup and holding priorities, resource
affinities, and local-protection, are also included in this
object.
4) SESSION_ATTRIBUTE(セッション識別と病気の特徴で支援するPathメッセージに追加できる)は反対します。 また、セットアップや把持プライオリティのようなリソースの親近感、およびローカルの保護がこのオブジェクトに含まれているという追加制御情報。
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メッセージの両方に現れるかもしれません。 それは、詳細な経路情報を集めるのに使用されて、輪の検出と病気の特徴の役に立ちます。
Manner & Fu Informational [Page 10] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[10ページ]のRFC4094Analysis
Section 5 of [RFC3270] further specifies the extensions to RSVP to establish LSPs supporting DiffServ in MPLS networks, introducing a new DIFFSERV Object (applicable in the Path messages), and using pre-configured or signaled "EXP<-->PHB mapping" (e.g., [RFC3270]).
[RFC3270]のセクション5がネットワーク、(Pathメッセージで適切)で新しいDIFFSERV Objectを導入して、および使用があらかじめ設定したか、または示したMPLSでDiffServをサポートするLSPsを証明するためにさらにRSVPに拡大を指定する、「EXP<--」 (例えば、[RFC3270])を写像する>PHB。
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]を通してそのExplicit RouteとRecord Route Objectsで無数のリンクを示す方法を提供します。 これは以下の拡大を指定します:
- An Unnumbered Interface ID Subobject, which is a subobject of the
Explicit Route Object (ERO) used to specify unnumbered links.
- Unnumbered Interface ID Subobjectであり、どれがExplicit Route Object(ERO)の「副-オブジェクト」であるかは以前はよく無数のリンクを指定していました。
- 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 Object、隣接しているLSRが無数のForwarding Adjacencyに識別子を形成するか、または使用するのを許容するために。
- A new subobject of the Record Route Object, used to record that the
LSP path traversed an unnumbered link.
- LSP経路が無数のリンクを横断したという記録に使用されるRecord Route Objectの新しい「副-オブジェクト」。
2.2.11. GMPLS and RSVP-TE
2.2.11. GMPLSとRSVP-Te
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.
それは新しいNotifyメッセージ(一般的なイベント通知のための)を定義します、上流と川下のそれぞれの記載されたLSPに関して。(メッセージは送られる通知を含むかもしれません)。 回復に原因となるノードへの失敗の速められた通知に中古で他のイベントが失敗したLSPsであったかもしれないならメッセージに通知してください。 ルータ警戒オプションなしでNotifyメッセージを送ります。
A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for general uses of MPLS:
多くの新しいRSVP-TE(潜水艦)オブジェクトがMPLSの一般的な用途のためにGMPLS RSVP-TEで定義されます:
- a Generalized Label Request Object;
- 一般化されたラベル要求オブジェクト。
- a Generalized Label Object;
- 一般化されたラベルオブジェクト。
- a Suggested Label Object;
- 提案されたラベルオブジェクト。
- a Label Set Object (to restrict label choice);
- Label Set Object(ラベル選択を制限する)。
- an Upstream_Label object (to support bidirectional LSPs);
- Upstream_Labelオブジェクト(双方向のLSPsをサポートする)。
- a Label ERO subobject;
- Label ERO subobject。
Manner & Fu Informational [Page 11] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[11ページ]のRFC4094Analysis
- IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in
out-of-band signaling or in bundled links);
- _HOPは_ID RSVPであるなら反対します。(IPv4&IPv6; バンドの外のシグナリングか添付されるところでインタフェースを特定するのはリンクされます)。
- IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in
out-of-band signaling or in bundled links);
- _SPECは_ID ERRORであるなら反対します。(IPv4&IPv6; バンドの外のシグナリングか添付されるところでインタフェースを特定するのはリンクされます)。
- an Acceptable Label Set object (to support negotiation of label
values in particular for bidirectional LSPs)
- Acceptable Label Setオブジェクト(特に双方向のLSPsのためのラベル値の交渉をサポートする)
- 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)
- Notify Requestオブジェクト(送られるLSPの故障の通知がことである示すPathかResvメッセージに挿入されるかもしれません)
- a Restart_Cap Object (used on Hello messages to identify recovery
capabilities)
- 再開_上限オブジェクト(回復能力を特定するHelloメッセージで中古)です。
- an Admin Status Object (to notify each node along the path of the
status of the LSP, and to control that state).
- Admin Status Object(LSPの状態の経路に沿った各ノードに通知して、その状態を制御する)。
2.2.12. GMPLS Operation at UNI and E-NNI Reference Points
2.2.12. UNIでのGMPLS操作と電子NNI基準点
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
- またはNetwork Interfaces(UNIs)へのユーザが彼らであるならユーザかユーザネットワークとコアネットワークの間に横たわる。
- External Network to Network Interfaces (E-NNIs) if they lie between
peer networks, network domains, or subnetworks.
- 同輩ネットワーク、ネットワークドメイン、またはサブネットワークの間には、Network Interfaces(電子NNIs)への外部のNetworkが彼らであるならいます。
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-タイプも必要ではありません。 見てください[かぶせました]。
2.2.13. MPLS and GMPLS Future Extensions
2.2.13. MPLSとGMPLSの将来の拡張子
At the time of writing, MPLS and GMPLS are being extended by the MPLS and CCAMP Working Groups to support additional sophisticated functions. This will inevitably lead to the introduction of new C-Types for existing objects, and to the requirement for new objects (CNums). It is possible that new messages will also be introduced.
これを書いている時点で、MPLSとGMPLSは、追加洗練された機能をサポートするためにMPLSとCCAMP Working Groupsによって広げられています。 これは新しいオブジェクト(CNums)のために必然的に既存のオブジェクトと、要件への新しいC-タイプの導入に通じるでしょう。 また、新しいメッセージが紹介されるのは、可能です。
Manner & Fu Informational [Page 12] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[12ページ]のRFC4094Analysis
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) --バックアップLSPsにおける付加的なトラフィックのサポート--保護と負荷分割法のためのさまざまの経路設立。 - ポイントツーマルチポイント経路の設立。 - --明白な経路制御--帯域幅予約による相互領域と相互AS経路設立(経路の多様性)は、Automatic Switched Optical Networkの要件のためにITU-Tによって定義されるように(ASON)がシグナリングであるとサポートします、呼び出しと接続分離を含んでいて。 - LSPの間のCrankbackはセットアップします。
2.2.14. ITU-T H.323 Interface
2.2.14. ITU-T H.323インタフェース
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資源予約手順を推薦します。 終点がRSVPをサポートするかどうかの情報はH.245[H.245]能力交換段階の間、伝えられるべきです、適切なqOSMode分野を設定することによって。 H.245論理チャネルを開くとき、両方の終点がRSVPできるなら、受信機ポートIDはopenLogicalChannelAckメッセージによって送付者に伝えられるべきです。 「経路--Resv--ResvConf」プロセスはその後にだけ行われることができます。 ResvConfメッセージを待つタイマは終点によって設定されるでしょう。 このタイマが期限が切れるか、またはRSVPの予約がH.323呼び出しの間、任意な点で失敗するなら、動作はベンダー次第です。 いったんResvConfメッセージを送るか、または受け取ると、終点は、予約タイマを止めて、H.323呼び出し手順で再開するべきです。 予約の明白なリリースだけが[H.323]でサポートされます。 ストリームへのcloseLogicalChannelメッセージを送る前に、RSVPセッションがそのストリームのために作成されていた状態で前であるなら、送付者はPathTearメッセージを送るべきです。 closeLogicalChannelを受けた後に、受信機は同様にResvTearを送るはずです。 FFスタイルだけがポイントツーマルチポイント呼び出しのためにさえサポートされます。
2.2.15. 3GPP Interface
2.2.15. 3GPPインタフェース
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
第3Generation Partnership Project(3GPP)TS23.207([3GPP-TS23207])はUniversalのモバイルTelecommunications System(UMTS)終わりから終わりへのQoSアーキテクチャの中で方針コントロールでQoSシグナリング手順を指定します。 RSVPを使用する、シグナリングソース、そして/または、目的地がモバイルで場所を見つけるUser Equipments(UEs、ネットワーク・サービスへのアクセスをユーザに許すデバイス)であるときに
Manner & Fu Informational [Page 13] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[13ページ]のRFC4094Analysis
Originating (MO) side and the Mobile Terminating (MT) side. An RSVP signaling process can either trigger or be triggered by the (COPS) PDP Context establishment/modification process. The operation of refreshing states is not specified in [3GPP-TS23207]. If a bidirectional reservation is needed, the RSVP signaling exchange must be performed twice between the end-points. The authorization token and flow identifier(s) in a policy data object should be included in the RSVP messages sent by the UE, if the token is available in the UE. When both RSVP and Service-based Local Policy are used, the Gateway GPRS Support Node (GGSN, the access point of the network) should use the policy information to decide whether to accept and forward Path/Resv messages.
側を溯源して(MO)、モバイルTerminating(MT)は面があります。 RSVPシグナリングプロセスが、よりこぎれいな状態で引き起こすことができますか、または(COPS)PDP Context設立/変更プロセスによって引き起こされてください。 壮快な州の操作は[3GPP-TS23207]で指定されません。 双方向の予約が必要であるなら、エンドポイントの間で二度RSVPシグナリング交換を実行しなければなりません。 方針データ・オブジェクトの承認トークンと流れ識別子はUEによって送られたRSVPメッセージに含まれるべきです、トークンがUEで利用可能であるなら。 RSVPとServiceベースのLocal Policyの両方が使用されているとき、ゲートウェイGPRS Support Node(GGSN、ネットワークのアクセスポイント)は、受け入れて、メッセージをPath/Resvに転送するかどうか決めるのに方針情報を使用するはずです。
2.3. Extensions for New Deployment Scenarios
2.3. 新しい展開シナリオのための拡大
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オプションのように、いくつかのルータ[FJ02]によってIPの注意深いオプションを通して実装されたRSVPメッセージは下げられるかもしれません。 アプリケーションは、RSVPライブラリに建てられる必要がありますが、1つの記事がどんなホストもアプリケーションの認識[MHS02]なしでRSVPメカニズムの利益を得ることができるメカニズムを提示します。
A somewhat similar deployment benefit can be gained from the Localized RSVP (LRSVP) [JR03] [MSK+04]. The documents present the concept of local RSVP-based reservation that alone can be used to trigger reservation within an access network. In those cases, an end-host may request QoS from its own access network without the
Localized RSVP(LRSVP)[JR03]からいくらか同様の展開利益を獲得できます[MSK+04]。 ドキュメントはアクセスネットワークの中で予約の引き金となるのにそれしか使用できないという地方のRSVPベースの条件の概念を提示します。 それらの場合では、終わりホストは、それ自身のものからのQoSがネットワークにアクセスするよう要求するかもしれません。
Manner & Fu Informational [Page 14] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[14ページ]のRFC4094Analysis
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に気づかないときに、これは特に役立っているでしょう。 プロキシノードは、終わりのホストによって送られたメッセージに応じて、上流の、そして、川下の両方の予約を可能にします。 その上、体系は、プロキシの引き金となることによって引き渡しに続く予約修理が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メッセージは単一の非断片化しているIPデータグラムに完全に収まらなければなりません。 バンドルメッセージ[RFC2961]は独身のPDUの中の複数のRSVPメッセージに集められることができますが、それらはまだ、1個のIPデータグラム(すなわち、およそ64K)しか占領していません。 MTUを超えているなら、データグラムは、IPによって断片化されて、受取人ノードで組み立て直されます。
2.4. Conclusion
2.4. 結論
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-フィルタ(WF)を含むスタイルをフィルターにかけるのをFixed-フィルタ(FF)で、Shared明白に(SE)して、あるQoSオブジェクトに結ばれません。 (RSVPはIntServ Guaranteed Service/制御されたLoad(GS/CL)仕様に結ばれません。) オブジェクトがモジュールであるために設計されましたが、Xspecs(TSPECなど)はQoS多少特有であり、さらに一般化されるべきです。 合図されたデータとシグナリングプロトコルの間には、どんな明確なレイヤリング/分離もありません。
RSVP uses a soft state mechanism to maintain states and allows each node to define its own refresh timer. The protocol is also independent of underlying routing protocols. Still, in mobile networks the movement of the mobile nodes may not properly trigger a reservation refresh for the new path, and therefore a mobile node may be left without a reservation up to the length of the refresh timer.
それ自身のものを定義する各ノードが述べて、許容すると主張するRSVP用途a軟性国家メカニズムはタイマをリフレッシュします。 また、プロトコルも基本的なルーティング・プロトコルから独立しています。 静まってください、モバイルノードの動きが適切に予約が予約のない左が上であったかもしれないなら新しい経路、およびしたがって、モバイルノードのために長さにリフレッシュするaの引き金とならないかもしれないモバイルネットワークでタイマをリフレッシュしてください。
Manner & Fu Informational [Page 15] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[15ページ]のRFC4094Analysis
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が元々設計されたよりはるかに広い展開を考慮する何十もの拡張子が現れています--例えば、Subnet Bandwidthマネージャ、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.
移送機構、性能、セキュリティ、および移動性問題は以下のセクションで詳細です。
3. RSVP Transport Mechanism Issues
3. RSVP移送機構問題
3.1. Messaging Reliability
3.1. メッセージングの信頼性
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 Pathメッセージに提供しなければなりません。 トランジットルータがPathメッセージを傍受するように、新しいIP Router Alertオプション[RFC2113]は紹介されました。 このデザインは、実装するのが簡単であって実行するために効率的です。 [PS00]での実験から示される小さい方のカーネル変化IPと共に、オプション処理はFree BSD箱の上にオーバーヘッドをほとんど導入しません。
However, RSVP does not have a good message delivery mechanism. If a message is lost on the wire, the next re-transmit cycle by the network would be one soft-state refresh interval later. By default, a soft-state refresh interval is 30 seconds.
しかしながら、RSVPには、良いメッセージ排紙機構がありません。 メッセージが失われているなら、ワイヤ、次は柔らかい州がリフレッシュするのが後での間隔であったならネットワークでサイクルを再送します。 デフォルトで、軟性国家はリフレッシュします。間隔は30秒です。
Manner & Fu Informational [Page 16] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[16ページ]のRFC4094Analysis
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]に打ち勝つために、上演されたaはタイマメカニズムをリフレッシュします。(それは、[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.
しかしながら、メカニズムの実装の間、多くの取り組みが1セッションあたりのタイマメインテナンス、メッセージの再送(例えば、メッセージ炸裂を避ける)、およびメッセージ配列であることに費やされなければなりませんでした。 さらに、私たちは、プロトコル処理と輸送機能を切り離そうとするために取り組みを作らなければなりません。 例えば、プロトコル拡張子が自然なRSVPセッションタイムアウト(1〜1つが速く別ルートで送るRSVP-TE[FAST-REROUTE]などの)を必要とするなら、私たちは必要でした。興味を失うために、舞台はタイマをリフレッシュします。
3.2. Message Packing
3.2. メッセージパッキング
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セッションを持っているネットワークでは、この規制は重い処理負担をルータに課します。 多くのルータOSesはUNIXに基づいています。 [PS00]は、UNIXソケット入出力処理がそれほどパケットサイズに敏感でないことを示しました。 事実上、小型小包を処理すると、大きいものを処理するのとほとんど同じくらい多くのCPUオーバーヘッドが取ります。 しかしながら、あまりに多くの個々のメッセージを処理すると、混雑はソケット入出力インタフェースで容易に引き起こされる場合があります。
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セッションの数を改良しました。
3.3. MTU Problem
3.3. MTU問題
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が使用された場所では、1セッションあたりのRSVPデータの量がそれほど決して大きくないか、またはリンクMTUは調整可能です。 PPPとFrame RelayはMTUサイズをいつも増強するか、または減少させることができます。 例えば、いくつかのルータでは、Frame Relayインタフェースは、リンクMTUサイズが最大9600バイトであるとサポートすることができます。 現在、RSVP MTU問題はMPLSネットワークの現実的な関心ではありません。
Manner & Fu Informational [Page 17] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[17ページ]のRFC4094Analysis
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に対処しなければならないことに注意してください。
3.4. RSVP-TE vs. Signaling Protocol for RT Applications
3.4. RSVP-Te対RTアプリケーションのためにプロトコルに合図すること。
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ネットワークでは、Labelによって切り換えられたPaths(LSPs)をサポートするのに使用される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 LSPsを通常セットアップします。 例えば、オペレータは、LSP経路最適化の間、1つのセッションから別のものに移すので多くのユーザトラフィックを防ぐか、または遅らせるためにしばしばConstraintベースのShortest Path First(CSPF)計算間隔を規制します。 (CSPFはLSPsのために“most"の最適のルートを計算するためにネットワーク縁を中心に活動するルーティング・アルゴリズムです。) その結果、RSVP- TEは多量の「引き金となられた」(新しいか変更された)メッセージを扱う必要はありません。 メッセージの大部分はメッセージをリフレッシュしてください、メカニズムでどれを扱うことができるかが中でRFC2961を導入したということです。 Summary Refresh拡張子[RFC2961]、RSVPがリフレッシュするそれぞれでは、特に、4バイトのIDとしてメッセージを表すことができます。 ルータは、RSVPセッションをリフレッシュするために単にIDを交換できます。 RFC2961の完全な実施によって、MPLSルータには、どんなRSVPスケーリング問題もありません。 1個の配布しているルータプラットホームでは、それが安定したバックボーンネットワークで5万以上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つの領域です。
3.5. What Would Be a Better Alternative?
3.5. より良い代替手段は何でしょうか?
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をサポートするために十分です。 どんな重要なトランスポート層解決すべき問題もありません。
Manner & Fu Informational [Page 18] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[18ページ]のRFC4094Analysis
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.
- わずかな引き起こされたメッセージボリューム。
4. RSVP Protocol Performance Issues
4. RSVPプロトコルパフォーマンス問題
4.1. Processing Overhead
4.1. 処理オーバヘッド
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
1) プロトコル要素の複雑さ。 最初にRSVP自身がそうである、-、ベースで、流れてください。 したがって、州の数はRSVPセッション番号に比例しています。 経路とResv州は各セッションのためにそれぞれのRSVPルータで維持されなければなりません(Path州も通信員Resvメッセージのために逆のルートを記録しなければなりません)。 Resvメッセージは処理されますが、受信機によって開始されていて、2番目に、RSVPはマルチキャストの予約のための様々な合併している操作を最適化します。 また、マルチキャストを扱うために、基本プロトコルで予約スタイルなどの他のメカニズム(範囲オブジェクト、および封鎖州)は提示されなければなりません。 これは失敗と誤りの源を加えるだけではなく、州のマシン[Fu02]を複雑にもします。 3番目に、同じRSVPシグナリングメッセージは、状態を維持するのに使用されるだけではなく、シグナリングメッセージの損失の回復とルート変化の発見にまた対処するのに使用されます。 したがって、実際のデータ(例えば、QoSパラメタ)仕様を表すプロトコル要素がシグナリング要素から分離されますが、すべてのRSVPメッセージに必要である処理オーバヘッドは切り離されます。
Manner & Fu Informational [Page 19] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[19ページ]のRFC4094Analysis
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.
マージンでない。 最終的に、オーダーの可能な変化とオブジェクトの存在はメッセージ構文解析、社内通信文、および州の表現の複雑さを増強します。
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メッセージを送って、受け取る2つの方法があります: プロトコル番号46がある「生」のIPデータグラムとして、または、カプセル化されたUDPデータグラムとして。データグラムはRSVP処理の効率を増強します。 典型的なRSVP実装はカーネルと対話するユーザスペースデーモンです。 したがって、国家管理、メッセージ送信、およびレセプションはプロトコル処理の効率に影響するでしょう。 例えば、[KSS01]で説明された実装の最近のバージョンでは、メッセージ送信/レセプションシステムコール"sendto"、「選択」、および"recvmsg"のための相対的な実行コストは個別に%、6-7%と、9-10%14-16の総実行費用でした。 また、[KSS01]は、州(メモリ)の経営者側が総実行費用の%を17-18まで使用できるのがわかりましたが、6-7%へのその費用を下げるのは可能です、標準のメモリ管理を州の情報のためのひたむきなメモリ管理に取り替えるために適切な行動を取るなら。 また、RSVP/ルーティング、RSVP/方針コントロール、およびRSVP/トラフィックコントロールインタフェースは実装による異なったオーバーヘッドを引き起こすことができます。 例えば、RSVP/ルーティングオーバーヘッドは、総実行費用[KSS01]のおよそ11-12%になるように測定されました。
4.2. Bandwidth Consumption
4.2. 帯域幅消費
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メッセージで軽い飲食物冗長を減らします。
Manner & Fu Informational [Page 20] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[20ページ]のRFC4094Analysis
Thus, the following formula represents the bandwidth consumption in bytes for an RSVP session lasting n seconds:
したがって、以下の公式はn秒のRSVPセッション持続のためにバイトにおける帯域幅消費を表します:
F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt
+ F(n)=(bP+Br)+ ((n/Ri)*(bP+Br))bPt
bP: IP payload size of Path message
bR: IP payload size of Resv message
bPt: IP payload size of Path Tear message
Ri: refresh interval
bP: PathメッセージbRのIPペイロードサイズ: ResvメッセージbPtのIPペイロードサイズ: Path TearメッセージRiの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秒であるところ)のない簡単なControlled Loadの予約において、帯域幅消費は以下の通りでしょう:
F(n) = (172 + 92) + ((n/30) * (172 + 92)) + 44
+ (172+92)(n/30)F(n)=*(172+92)+44
= 308 + (264n/30) bytes
= 308+(264n/30)バイト
5. RSVP Security and Mobility
5. RSVPセキュリティと移動性
5.1. Security
5.1. セキュリティ
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.
システムの上のプロセスがしっかりと交信プロセス(例えば、ユーザイド)の所有者とアプリケーションを特定して、安全な方法でRSVPメッセージのこの情報(PATHかRESV)を伝えるのを許容するために、[RFC3182]はRSVP POLICY_DATA Objectとしてアイデンティティのコード化を指定します。 しかしながら、甲鉄艦の機密保持を提供するために、承認に結合された暗号の認証を提供しなければなりません。 認証と主要な交換プロトコルはそのような機能性を通常提供します。 唯一ユーザ識別子を含んでいるのは不十分です。
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メッセージは合わせられたメッセージダイジェストを使用することでINTEGRITYオブジェクト([RFC2747])を含むかもしれません。 中間的ルータがシグナリングメッセージの内容を変更して、処理する必要があるので、ホップごとの信頼のチェーンに基づくセキュリティー体系は使用されています。 しかしながら、このドキュメント中で説明されて新しい要件があるRSVPの異なった使用法で、オリジナルの仮定の再評価が必要であるかもしれません。
RFC2747 provides protection against forgery and message modification. However, this does not provide non-repudiation or protect against message deletion. In the current RSVP security scheme, the two-way peer authentication and key management procedures are still missing.
RFC2747は偽造に対する保護とメッセージ変更を提供します。 しかしながら、これは、非拒否を提供もしませんし、メッセージ削除から守りもしません。 現在のRSVPセキュリティ体系では、両用同輩認証とかぎ管理手順はまだなくなっています。
The security issues have been well analyzed in [Tsch03].
安全保障問題は[Tsch03]でよく分析されました。
Manner & Fu Informational [Page 21] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[21ページ]のRFC4094Analysis
5.2. Mobility Support
5.2. 移動性サポート
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.
モバイルノード(ミネソタ)がRSVPを使用すると、2冊は関心を高めます: 流れ識別子と予約はリフレッシュします。 ミネソタが位置を変えるとき、それは、割り当てられたIPアドレスの1つを変える必要があるかもしれません。 ミネソタはアクセスネットワークの外におけるノードでIPアドレスをそれがどれであるかで届くようにするかもしれません、そして、IPアドレスは以前はよく地方の移動性が管理であることをサポートしていました。 移動性管理メカニズムによって、引き渡しはこれらのアドレスのいずれでも変化を強制するかもしれません。 結果、フィルタが交際したので、それ以上流れを特定しないかもしれなくて、aがaでリフレッシュするまで資源予約が効力がないという条件で、新しいセットのフィルタは初期化されます。
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はそのPathメッセージを定義します。予約経路の局部的修繕を実行できます。 交信している終わりのホストの間のルートが変化すると、Pathメッセージは新しいルートの上に予約の州を置くでしょう、そして、その後のResvメッセージは資源予約をするでしょう。 したがって、Resvメッセージにホストを送ることによって、Pathメッセージが終わる前に予約、およびその結果、それがそうすることができない単独のアップデートは局部的修繕を実行できませんか? また、速い適合を提供するために、短いことのオーバーヘッドのないルーティング変化に、期間はリフレッシュしています、とローカルのルーティング・プロトコルモジュールはルート変化のRSVPプロセスに特定の目的地に通知できます。 RSVPプロセスは、これらの目的地に状態をリフレッシュして、新しいルート(セクション3.6、[RFC2205])を使用することで迅速にaの引き金となるのにこの情報を使用するはずです。 しかしながら、すべてのローカルの移動性プロトコルが直接ルータ(モバイルでないIPさえ)におけるルーティングに影響するというわけではありません、そして、その結果、RSVPルータで移動性に気付かないかもしれません。 したがって、引き渡しに続いて、予約がすっきりなる前にそれは比較的長い時かかるかもしれません。
There have been several designs for extensions to RSVP to allow for more seamless mobility. One solution is presented in [MSK+04], in which one section discusses the coupling of RSVP and the mobility management mechanisms and proposes small extensions to RSVP to handle the handover event better, among other things. The extension allows the mobile host to request a Path for the downstream reservation when a handover has happened.
RSVPへの拡張子が、よりシームレスの移動性を考慮するように、いくつかのデザインがありました。 1つのソリューションが[MSK+04]に提示されます。そこでは、セクションは、RSVPのカップリングと移動性管理メカニズムについて論じて、引き渡しイベントをよりよく、そして、特に扱うために小さい拡大をRSVPに提案します。 引き渡しが起こったとき、拡大で、モバイルホストは川下の予約のためにPathを要求できます。
Another example is Mobile RSVP (MRSVP) [TBA01], which is an extension to standard RSVP. It is based on advance reservations, where neighboring access points keep resources reserved for mobile nodes moving to their coverage area. When a mobile node requests resources, the neighboring access points are checked, too, and a passive reservation is done around the mobile nodes' current location.
別の例はモバイルRSVP(MRSVP)[TBA01]です。(そのRSVPは標準のRSVPへの拡大です)。 それは事前の予約に基づいています、隣接しているアクセスポイントが、それらの適用範囲の地域に移行するモバイルノードのためにリソースを予約し続けるところで。 モバイルノードがリソースを要求すると、また、隣接しているアクセスポイントはチェックされます、そして、モバイルノードの現在の位置の周りで受け身の予約をします。
Manner & Fu Informational [Page 22] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[22ページ]のRFC4094Analysis
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]によく記録されました。
6. Other QoS Signaling Proposals
6. 他のQoSシグナリング提案
6.1. Tenet and ST-II
6.1. そして、主義、第-、II
Tenet and ST-II are two original QoS signaling protocols for the Internet.
主義とST-IIはインターネットにプロトコルに合図する2オリジナルのQoSです。
In the original Tenet architecture [BFM+96], the receiver sends a reservation request toward the source. Each network node along the way makes the reservation. Once the request arrives at the source, the source sends another Relax message back toward to the receiver, and has the option to modify the previous reservation at each node.
オリジナルのTenetアーキテクチャ[BFM+96]では、受信機はソースに向かって予約の要請を送ります。 道に沿った各ネットワーク・ノードは予約をします。 要求がいったんソースに到着すると、ソースは、別のRelaxメッセージを受信機に向かって返送して、各ノードに前の予約を変更するオプションを持っています。
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]は基本的に以下の方法で働いています: 送付者は1セットの受信機にConnectメッセージを溯源します。 それぞれの中間的ノードは、次のホップサブネットを決定して、これらの次のホップに行きながら、リンクの上に予約をします。 Connect指示を受けると、受信機はAcceptかRefuseメッセージのどちらかを送付者に返送しなければなりません。 Acceptの場合では、受信機は、さらに返された流れ仕様をアップデートすることによって、資源要求を減らすかもしれません。
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は2つのプロトコルから成ります: データ伝送のためのSTとすべてのコントロールのためのStream Control Messageプロトコル(SCMP)は機能します。 STは簡単であり、ただ一つのPDU形式だけを含んでいます。(低いコミュニケーション遅れを達成して、それは、速くて効率的なデータ推進のために設計されています)。 STパケットの中でSCMPパケットを移します。
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]は充電に関連するいくつかのオブジェクトについて説明します。
Manner & Fu Informational [Page 23] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[23ページ]のRFC4094Analysis
6.2. YESSIR
6.2. YESSIR
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、(YEt、別のSender Sessionインターネット予約) [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)を利用して、それは拡大としてレアル-時間Transport Controlプロトコル(RTCP)に建てられます。 また、YESSIRはあるタイプのアプリケーションのための予約の要請を次のホップに通過できる部分的な予約と呼ばれる概念を紹介します、ローカルのノードに関する十分なリソースがありませんが。 ローカルのノードは、予約を終了するために最適化された再試行に依存できます。
6.2.1. Reservation Functionality
6.2.1. 予約の機能性
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の1パスの予約モデルには、より良い性能と通常の両用シグナリングプロトコルより低い加工費があるのが示されました、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安全策を当てにします。
Manner & Fu Informational [Page 24] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[24ページ]のRFC4094Analysis
6.2.2. Conclusion
6.2.2. 結論
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パケットを進めます。
6.3. Boomerang
6.3. ブーメラン
Boomerang [FNM+99] is a another resource reservation protocol for IP networks. The protocol has only one message type and a single signaling loop for reservation setup and teardown, and it has no requirements on the far end node. Instead, it concentrates the intelligence in the Initiating Node (IN).
ブーメラン[FNM+99]は別の資源予約がIPネットワークのために議定書の中で述べるaです。 プロトコルには、予約セットアップと分解のための1つのメッセージタイプとただ一つのシグナリング輪しかありません、そして、それには、遠端ノードに関する要件が全くありません。 代わりに、それはInitiating Node(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-tupleと流れを同一視しています、そして、あの手この手でQoSを指定できます。 例えば、クラスとビット伝送速度にサービスを提供してください。 初期の実装では、BoomerangメッセージはICMP ECHO/REPLYメッセージで輸送されます。
6.3.1. Reservation Functionality
6.3.1. 予約の機能性
Boomerang can only be used for unicast sessions; no support for multicast exists. The requested QoS can be specified with various methods, and both ends of a communication session can make a reservation for their transmitted flow.
ユニキャストセッションにブーメランを使用できるだけです。 マルチキャストのサポートは全く存在していません。 様々なメソッドで要求されたQoSを指定できます、そして、コミュニケーションセッションの両端はそれらの伝えられた流れの予約をすることができます。
The authors of Boomerang show in [FNS02] that the processing of the protocol is considerably lower than that of the ISI RSVP daemon implementation. However, this is mainly due to the limited functionality provided by the protocol compared to that provided by RSVP.
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.
ブーメランメッセージは、かなり短く、比較的低い量のリンク帯域幅を消費します。 これはプロトコルの限られた機能性のためです。 例えば、どんなセキュリティ特殊情報も方針ベースの相互作用も供給しません。 適応する送付者であり、帯域幅消費は川下の方向にほとんど送付者から受信機まで影響します。
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に指定されません。
Manner & Fu Informational [Page 25] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[25ページ]のRFC4094Analysis
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に転送できるべきです。 それでも、プロトコルを役に立たなくして、ファイアウォールはしばしばICMPパケットを下げます。
6.3.2. Conclusions
6.3.2. 結論
Boomerang seems to be a very lightweight protocol and efficient in its own scenarios. However, the apparent low processing overhead and bandwidth consumption results from the limited functionality. No support for multicast or any security features are present, which allows for a different functionality than RSVP, which the authors like to compare Boomerang to.
ブーメランはそれ自身のシナリオで非常に軽量のプロトコルで効率的であるように思えます。 しかしながら、見かけの低い処理オーバヘッドと帯域幅消費は限られた機能性から生じます。 マルチキャストのサポートがないどんなセキュリティ機能もRSVPより存在しています(異なった機能性を考慮します)。(作者はRSVPと比較するのがBoomerangが好きです)。
6.4. INSIGNIA
6.4. 記章
INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism for supporting QoS in mobile ad-hoc networks. It avoids the need for separate signaling by carrying the QoS signaling data along with the normal data in IP packets using IP packet header options. This approach, known as "in-band signaling", is proposed as more suitable in the rapidly changing environment of mobile networks since the signaled QoS information is not tied to a particular path. It also allows the flows to be rapidly established and, thus, is suitable for short-lived and dynamic flows.
INSIGNIA[LGZC00]はモバイル臨時のネットワークでQoSをサポートするための非常に簡単なシグナル伝達機構として提案されます。 それは、IPパケットでIPパケットのヘッダーオプションを使用することで正常なデータに伴うQoSシグナリングデータを運ぶことによって、別々のシグナリングの必要性を避けます。 合図されたQoS情報が特定の経路に結ばれないので、「バンドにおけるシグナリング」として知られているこのアプローチはモバイルネットワークの急速に変化している環境で、より適当であるとして提案されます。 それは、また、流れが急速に確立されるのを許容して、その結果、短命でダイナミックな流れに適しています。
INSIGNIA aims to minimize signaling by reducing the number of parameters that are provided to the network. It assumes that real- time flows may tolerate some loss, but are very delay sensitive so that the only QoS information needed is the required minimum and maximum bandwidth.
INSIGNIAは、ネットワークに提供されるパラメタの数を減少させることによってシグナリングを最小にすることを目指します。 それは、本当の時間流れがいくらかの損失を黙認するかもしれませんが、遅れ非常に敏感であるので情報が必要とした唯一のQoSが必要な最小の、そして、最大の帯域幅であると仮定します。
The INSIGNIA protocol operates at the network layer and assumes that link status sensing and access schemes are provided by lower-layer entities. The usefulness of the scheme depends on the MAC layers, but this is undefined, so INSIGNIA can run over any MAC layer. The protocol requires that each router maintains per-flow state.
INSIGNIAプロトコルは、ネットワーク層で作動して、リンク状態の感じとアクセス体系が下層実体によって提供されると仮定します。 体系の有用性をMAC層に依存しますが、これが未定義であるので、INSIGNIAはどんなMAC層もひくことができます。 プロトコルは、各ルータが1流れあたりの状態を維持するのを必要とします。
The INSIGNIA system implicitly supports mobility. A near-minimal amount of information is exchanged with the network. To achieve this, INSIGNIA makes many assumptions about the nature of traffic that a source will send. This may also simplify admission control and buffer allocation. The system basically assumes that "real-time" will be defined as a maximum delay, and the user can simply request real-time service for a particular quantity of traffic.
INSIGNIAシステムはそれとなく移動性をサポートします。 ネットワークと共に情報の近い最少量を交換します。 これを達成するために、INSIGNIAはソースが送るトラフィックの本質に関する多くの仮定をします。 また、これは入場コントロールとバッファ配分を簡素化するかもしれません。 システムは、「リアルタイムで」が最大の遅れと定義されると基本的に仮定します、そして、ユーザは単に特定の量のトラフィックのためのリアルタイムのサービスを要求できます。
Manner & Fu Informational [Page 26] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[26ページ]のRFC4094Analysis
After handover, data that was transmitted to the old base station can be forwarded to the new base station, so no data loss should occur. However, there is no way to differentiate between re-routed and new traffic, so priority cannot be given to handover traffic, for example.
引き渡しの後に古い基地局に送られたデータは新しい基地局に転送できるので、データの損失は全く発生するべきではありません。 しかしながら、引き渡しトラフィックが優先できないように別ルートで送られて新しいトラフィックを区別する例えば方法が全くありません。
INSIGNIA, however, (completely) lacks a security framework and does not investigate how to secure signaled QoS data in an ad-hoc network, where relatively weak trust or even no trust exists between the participating nodes. Therefore, authorization and charging especially might be a challenge. The security protection of in-band signaling is costly since the data delivery itself experiences increased latency if security processing is done hop-by-hop. Because the QoS signaling information is encoded into the flow label and end-to-end addressing is used, it is very difficult to provide security other than IPsec in tunnel mode.
INSIGNIAはしかしながら、セキュリティフレームワークを(完全に)欠いて、比較的弱い信頼が存在していますが、どんな信頼さえも参加ノードの間に存在しない臨時のネットワークで合図されたQoSがデータであると機密保護する方法を調査しません。 したがって、承認と特に充電は挑戦であるかもしれません。 セキュリティ処理がホップごとに完了しているならデータ配送自体が増強された潜在になるので、バンドにおけるシグナリングの機密保持は高価です。 QoSシグナリング情報が流れラベルにコード化されて、終わりから終わりへのアドレシングが使用されているので、トンネルモードによるIPsec以外のセキュリティを提供するのは非常に難しいです。
7. Inter-Domain Signaling
7. 相互ドメインシグナリング
This section gives a short overview of protocols designed for inter- domain signaling.
このセクションは相互ドメインシグナリングのために設計されたプロトコルの短い概要を与えます。
7.1. BGRP
7.1. BGRP
Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling protocol for inter-domain aggregated resource reservation for unicast traffic. BGRP builds a sink tree for each of the stub domains. Each sink tree aggregates bandwidth reservations from all data sources in the network. BGRP maintains these aggregated reservations using soft state and relies on Differentiated Services for data forwarding.
境界ゲートウェイ予約プロトコル(BGRP)[BGRP]はユニキャストトラフィックの相互ドメインの集められた資源予約のためのシグナリングプロトコルです。 BGRPはそれぞれのスタッブドメインに流し台木を建てます。 それぞれの流し台木はネットワークにおけるすべてのデータ送信端末から帯域幅の予約に集められます。 BGRPはこれらが軟性国家を使用することで予約に集められたと主張して、データ推進のためにDifferentiated Servicesを当てにします。
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スケールはストレージと帯域幅を述べます。 バックボーンルータが流し台木の情報を保守するだけであるので、各ルータにおける予約の総数はインターネットドメインの数で直線的に比例します。
7.2. SICAP
7.2. SICAP
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
SICAP(共用セグメントInter-ドメインControl Aggregationは議定書を作ります)[SGV03]はBoundary Routers(BRs)で必要である状態を減少させるために、Autonomous System(AS)レベルに共有されたセグメント集合[SGV02]を実行する相互ドメインシグナリングソリューションです。 SICAPは異なった予約が共有する経路セグメントに基づく集合を実行します。 したがって、予約は必ず予約の目的地にいっぱいに達するというわけではない集合に合併されるかもしれません。 「より短い」集合を作成することに関する動機はそれです、集合の片手、今後の要求で、より容易に収容する彼らの能力、および他方では最小化に関して
Manner & Fu Informational [Page 27] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[27ページ]のRFC4094Analysis
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.
その結果、作成されて、管理しなければならなかった状態の減少は予約を確立しました。 しかしながら、流し台木のアプローチ(BGRP[BGRP]によって使用される)と対照して、共用セグメントアプローチは中間的反-集合位置を導入します。 これらは集合が「再集合」になるかもしれないASesです。 これらの位置では、集合(AS出口ルータ)を実行するルータが予約と集合の間のマッピングの動向をおさえなければなりません。 これをする1つの可能な方法は各アグリゲータにそれぞれの予約識別子と対応するリソースを保存し続けることです。 しかしながら、このソリューションは高い州の刑罰を被ります。 SICAPは、明らかに個々の予約を集合に写像するより目的地ドメインのレベルで集合と予約の間のマッピングのむしろ動向をおさえることによって、この州の刑罰を避けます。 言い換えれば、SICAPは集合単位で集合がアクセスを供給する目的地ASによって広告に掲載された目的地接頭語のリストを維持します。
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.
なべ他はコントロール状態、メッセージ処理、および帯域幅効率に関してそのBGRPにスケールをよく示しています、集合なしでRSVPと比べると。 しかしながら、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はデザインがBGRPの可能なサポートを考慮に入れた過剰の予約メカニズム[SGV03b]を使用します。
7.3. DARIS
7.3. ダリー語
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-
インターネットのサービス(ダリー語)[Bless02][Bless04]のための予約のダイナミックなAggregationは資源予約の相互ドメイン集合体系を定義します。 基本的に、それはAutonomous System(AS)経路(または、それの部品)に沿って予約に集められます。 データ経路がASesの共通配列を共有する予約一式がそれに沿った集合が共有した共同予約と統合される、サブ
Manner & Fu Informational [Page 28] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[28ページ]のRFC4094Analysis
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).
経路。 集合始めとエンドポイント以外の集合の中のすべての実体が含まれている個々の予約の州の情報を取り除くことができます、その結果、州を保存します。 彼らは、ただ取り囲むのに関する必要事項を集合であるとして保持する必要があります。 そのうえ、これらの中間的ASesはもう集められた予約に関連するシグナリングにかかわりません。 より多くの集合リソースが実際に必要とされたより予約されているなら、あらゆる新しいかリリースされた条件(その結果、交換処理について数を減らす)のときに集合の容量は適合させられる必要はありません。
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.
それらの間の単方向の予約のアクティブな数について説明する敷居kが超えられているとすぐに、2ASesの間の集合は作成されます。 しかしながら、異なった集合引き金を適用するのは可能です。 その上、ダリー語は、集合が階層的で入れ子にされるのを許容します。 したがって、より短い集合の存在は、より長くて(その結果、より効率的)の集合の作成を防ぎません、逆もまた同様に。 [Bless02]での最近のBGPルーティング情報の評価は、終わりからすべての経路対端の92%が少なくとも4ASesを含むのを示しました。 その結果、ASを斜めに進ませる縁のASからの集合は4ASesにかかることができます、その結果、少なくとも2ASesで州とシグナリングがメッセージ処理であると保存します。
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.
しかしながら、新しい集合に予約を含むことができないという小さい見込みがあります、それがほかの場所で既に集められたので。 このいわゆる「集合闘争」は取り囲む集合の中間的ASesの中で個々の予約に関連した州の情報の先の取り外しで引き起こされます。 また、予約か集合がASesの間で別ルートで送られるなら、これは困難をもたらすかもしれません。 これらの特別なケースのための精巧な適合のテクニックを定義する方法を考えるとき、慎重であるに違いありません、非常に複雑になるように思えるので。
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(ドメインマネージャSignalingプロトコル)はいくつかの場合、往復の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
ダリー語概念は、本当のBGP経路指定テーブル情報から得られて、5500ASesを包括したトポロジーでシミュレーションを使用することによって、評価されました。 非集められたシナリオとの比較には、救われた州の数が1〜2桁の範囲にありました、そして、シグナリングメッセージの数に関して同様の結果を得ました。 [Bless02]は分配されたDomain Management実体(帯域幅ブローカーと同様の)の文脈のダリー語について説明しますが、aでルータベースでそれを適用できます。
Manner & Fu Informational [Page 29] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[29ページ]のRFC4094Analysis
resource management environment, too. This will achieve a higher degree of distribution, which is beneficial for large ASes, which are highly interconnected.
また、リソース経営環境。 これは、より高度の分配を達成するでしょう。(大きいASesに、それは、有益です)。(ASesは非常にインタコネクトされます)。
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.
集合の一般答弁は集合の中で彼らの開始している集合、しかし、すべての中間的ASesから利益を得るのが、集合と反-集合ASesでないということです。 したがって、集合創造のための何らかの誘因を与えなければなりません。 これは将来集合概念のために開発されなければならない目新しい費用モデルに通じるかもしれません。
8. Security Considerations
8. セキュリティ問題
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.
このドキュメントは新技術かプロトコルを提示しません。 したがって、どんな明白な安全保障問題もありません。 それでも、個々のプロトコルは異なったレベルの安全保障問題を含んでいます、そして、ものは関連セクションと参照で強調されます。
9. Summary
9. 概要
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パスのシグナリングだけを使います。 シグナリングシナリオが詳細で慎重に選ばれて、他が外で働くように両方を示すことができます。
Manner & Fu Informational [Page 30] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[30ページ]のRFC4094Analysis
10. Contributors
10. 貢献者
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作業部会で行われた仕事の一部です。 ドキュメントは初めは、ユッカMannerとXiaomingフーによって書かれました。 最初のバージョン以来、マーチン・カルステンはRSVPの処理オーバヘッドに関するテキストを提供しています、そして、ハンネスTschofenigは様々な安全保障問題に関するテキストをプロトコルに提供しました。 ヘニングSchulzrinneとPing Panは2番目の改正の後にRSVP輸送に関する詳しい情報を提供しました。 Kireeti Kompellaとエードリアン・ファレルはRSVP-TEとGMPLSについての議論にレビューとアップデートを提供しました。
11. Acknowledgements
11. 承認
We would like to acknowledge Bob Braden and Vlora Rexhepi for their useful comments.
彼らの役に立つコメントのためにボブ・ブレーデンとヴロレRexhepiを承認したいと思います。
Manner & Fu Informational [Page 31] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[31ページ]のRFC4094Analysis
12. Appendix A: Comparison of RSVP to the NSIS Requirements
12. 付録A: NSIS要件へのRSVPの比較
This section provides a comparison of RSVP to the requirements identified as part of the work in NSIS [RFC3726]. The numbering follows the division in the requirements document.
このセクションは仕事の一部としてNSIS[RFC3726]で特定された要件にRSVPの比較を提供します。 付番は要件ドキュメントでの分割に続きます。
5.1. Architecture and Design Goals
5.1. 構造とデザイン目標
5.1.1. NSIS SHOULD Provide Availability Information on Request
5.1.1. NSISは要求に応じて有用性情報を提供するはずです。
RSVP itself does not support query-type of operations. However,
the RSVP diagnosis messages extension [RFC2745] provides a means
to query resource availability.
RSVP自身は操作の質問タイプを支持しません。 しかしながら、RSVP診断メッセージ拡張子[RFC2745]はリソースの有用性について質問する手段を提供します。
5.1.2. NSIS MUST Be Designed Modularly
5.1.2. NSISは設計されたModularlyであるに違いありません。
RSVP was designed to be modular by way of TLV objects, however
it is regarded being lack of sufficient extensibility in various
kind of signalling applications.
RSVPはTLV物を通してモジュールであるために設計されて、しかしながら、それは、様々のアプリケーションをちょっと示す十分な伸展性の不足であるので見なされます。
5.1.3. NSIS MUST Decouple Protocol and Information
5.1.3. NSISはプロトコルと情報の衝撃を吸収しなければなりません。
RSVP is decoupled from the IntServ QoS specifications. Still,
the concept of sessions in RSVP are somewhat coupled to the
information it carries.
RSVPはIntServ QoS仕様から衝撃を吸収されます。 それでも、RSVPのセッションの概念はそれが運ぶ情報といくらか結合されています。
5.1.4. NSIS MUST Support Independence of Signaling and Network
Control Paradigm
5.1.4. NSISはシグナリングとネットワーク制御パラダイムからの独立を支持しなければなりません。
The IntServ information carried by RSVP does not tie the QoS
provisioning mechanisms.
RSVPによって運ばれたIntServ情報はメカニズムに食糧を供給するQoSを結びません。
5.1.5. NSIS SHOULD Be Able To Carry Opaque Objects
5.1.5. NSISは不明瞭な物を運ぶはずであることができます。
RSVP supports this.
RSVPはこれを支持します。
5.2. Signaling Flows
5.2. シグナリングは流れます。
5.2.1. The Placement of NSIS Initiator, Forwarder, and Responder
Anywhere in the Network MUST Be Allowed
5.2.1. ネットワークでどこでもNSIS創始者、混載業者、および応答者のプレースメントを許容しなければなりません。
Standard RSVP works only end-to-end, although the RSVP proxy
[BEGD02] and the Localized RSVP [MSK+04] have relaxed this
assumption. RSVP relies on receiver-initiation way to perform
QoS reservations.
RSVPプロキシ[BEGD02]とLocalized RSVP[MSK+04]はこの仮定を弛緩しましたが、標準のRSVPは唯一の終わりから終わりに働いています。 RSVPはQoSの予約を実行する受信機開始方法を当てにします。
Manner & Fu Informational [Page 32] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[32ページ]のRFC4094Analysis
5.2.2. NSIS MUST support Path-Coupled and MAY Support Path-
Decoupled Signaling
5.2.2. NSIS MUSTサポートPathによって結合されるのと5月のSupport PathはSignalingの衝撃を吸収しました。
Standard RSVP is path-coupled, but the Subnet Bandwidth
Manager (SBM) work makes RSVP somewhat path-decoupled.
標準のRSVPは経路によって結合されていますが、Subnet Bandwidthマネージャ(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.
2つの通知がRSVPにあって、誤りの結果、予約州をダウンするように予約セットアップと裂け目を確認してください。
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]はそのような特徴を提供します。
Manner & Fu Informational [Page 33] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[33ページ]のRFC4094Analysis
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.
間隔をリフレッシュしてください。しかし、初期の予約メッセージを圧縮できない、 より少ない帯域幅を消費するように調整できます、可能な効率の悪いリソース用法を犠牲にして。
Manner & Fu Informational [Page 34] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[34ページ]のRFC4094Analysis
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サービスタイプに頼っていて、Controlled LoadはGuaranteed Serviceより良い総合的な利用を提供できます。
5.6. Flexibility
5.6. 柔軟性
5.6.1. Flow Aggregation
5.6.1. 流れ集合
Aggregated RSVP and RFC2961 allow this.
集められたRSVPとRFC2961はこれを許容します。
5.6.2. Flexibility in the Placement of the NSIS
Initiator/Responder
5.6.2. NSIS創始者/応答者のプレースメントにおける柔軟性
RSVP allows receiver as initiator of reservations.
RSVPは予約の創始者として受信機を許容します。
5.6.3. Flexibility in the Initiation of State Change
5.6.3. 州の変化の開始における柔軟性
RSVP receivers can initiate the state change during its
refreshment.
RSVP受信機は軽い飲食物の間、州の変化を起こすことができます。
5.6.4. SHOULD Support Network-Initiated State Change
5.6.4. サポートのネットワークによって開始された状態は変化するべきですか?
As RSVP supports hop-by-hop refreshment, this is made possible.
RSVPがホップごとの軽い飲食物を支えるとき、これを可能にします。
5.6.5. Uni / Bi-Directional State Setup
5.6.5. Uni/双方向の州のセットアップ
RSVP is only uni-directional.
RSVPはuni方向上であるだけです。
5.7. Security
5.7. セキュリティ
5.7.1. Authentication of Signaling Requests
5.7.1. シグナリング要求の認証
Authentication is available in RSVP.
認証はRSVPで利用可能です。
5.7.2. Request Authorization
5.7.2. 認可を要求してください。
Authorization with a PDP is possible in RSVP.
PDPとの認可はRSVPで可能です。
5.7.3. Integrity Protection
5.7.3. 保全保護
The INTEGRITY Object is available in RSVP.
INTEGRITY ObjectはRSVPで利用可能です。
Manner & Fu Informational [Page 35] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[35ページ]のRFC4094Analysis
5.7.4. Replay Protection
5.7.4. 反復操作による保護
The INTEGRITY Object to replay protect the content of the
signaling messages between two RSVP nodes.
再演するINTEGRITY Objectは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.
このためにINTEGRITY Objectを使用できます。
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.
RFC2746はこれらの問題について議論します。
5.9.2. MUST NOT Constrain either to IPv4 or IPv6
5.9.2. IPv4かIPv6へのConstrainであってはいけない
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はこれについて議論しません。
Manner & Fu Informational [Page 36] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[36ページ]のRFC4094Analysis
5.9.4. SHOULD Provide Hooks for AAA Protocols
5.9.4. AAAプロトコルにフックを提供するべきです。
COPS and RSVP work together.
COPSとRSVPは一緒に働いています。
5.9.5. SHOULD Work with Seamless Handoff Protocols
5.9.5. シームレスの移管プロトコルで働くべきです。
Not supported by RSVP. Still, [RFC2205] suggests that route
changes should be indicated to the local RSVP daemon, which can
then initiate state refresh.
RSVPによって支持されません。 それでも、[RFC2205]は、ルート変化が地方のRSVPデーモンに示されるべきであると示唆して、次に、どれが状態を開始できるかはリフレッシュします。
5.9.6. MUST Work with Traditional Routing
5.9.6. 伝統的であるとの仕事が掘られて、そうしなければなりません。
RSVP expects traditional routing.
RSVPは伝統的なルーティングを予想します。
5.10. Operational
5.10. 操作上
5.10.1. Ability to Assign Transport Quality to Signaling Messages
5.10.1. 輸送品質をシグナリングメッセージに割り当てる能力
This is a network design issue, but is possible with DiffServ.
これは、ネットワークデザイン問題ですが、DiffServで可能です。
5.10.2. Graceful Fail Over
5.10.2. 優雅なフェイルオーバー
RSVP supports this.
RSVPはこれを支持します。
5.10.3. Graceful Handling of NSIS Entity Problems
5.10.3. NSIS実体問題の優雅な取り扱い
RSVP itself does not supports this.
RSVP自身はどんなサポートにもこれをしません。
Manner & Fu Informational [Page 37] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[37ページ]のRFC4094Analysis
13. Normative References
13. 引用規格
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC3726] ブルンナー、M.、「シグナリングプロトコルのための要件」、RFC3726、2004年4月。
14. Informative References
14. 有益な参照
[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 t23.207V5.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.
ブレーデンとR.とEstrinとD.とBersonとS.、ハーツォグとD.Zappala、「RSVPプロトコルのデザイン」[BEBH96]ISIの最終的な技術報告書(1996年7月)。
[BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP
Proxy", Work in Progress, March 2002.
「RSVPプロキシ」という[BEGD02]Y.Bernet、N.Elfassy、S.ガイ、およびD.ダッタは進歩、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.バネルジー、D.フェラーリ、B.Mah、M.モラン、D.Verma、およびH.チャン、「主義のリアルタイムのプロトコル群:」 Networkingの上のIEEE/ACM Transactions、Volume4、1996年のIssue2月1日「デザイン、Implementation、およびExperiences」、ページ 1-10.
[BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-
Based Aggregation Protocol for Inter-domain
Reservations", Journal of Communications and Networks,
Vol. 2, No. 2, June 2000, pp. 157-167.
[BGRP]P.なべ、E、Hahne、およびH.Schulzrinne、「BGRP:」 「TreeはInter-ドメイン予約のためのAggregationプロトコルを基礎づけ」てCommunicationsのJournalと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、「インターネットのサービスのための予約のダイナミックな集合」、Telecommunication Systemsの上のTenthの国際コンファレンスのProceedings--モデルとAnalysis(ICTSM10)、Vol.1、ページ 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. (PDF)、NOMS2004(IEEE/IFIP2004ネットワークオペレーションと管理シンポジウム)、2004年4月、ソウル、韓国の議事を「QoSベースの終わりから終わりに対するサービスのスケーラブルな管理」に祝福してください。
[FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", Work in
Progress, January 2004.
[速く、コースを変更します] P.なべ、G.ツバメ、およびA.Atlasは「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、処理中の作業、2004年1月。
Manner & Fu Informational [Page 38] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[38ページ]のRFC4094Analysis
[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.フェーヘル、K.Nemeth、M.Maliosz、I.Cselenyi、J.Bergkvist、D.Ahlard、T.Engborg、「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.フェーヘル、K.Nemeth、およびI.Cselenyi、「IP資源予約合図のための業績評価枠組み。」 パフォーマンスEvaluation48(2002)、ページ 131-156.
[FJ02] P. Fransson and A. Jonsson, "The need for an
alternative to IPv4-options", in RVK (RadioVetenskap
och Kommunikation), Stockholm, Sweden, pp. 162-166,
June 2002.
[FJ02] P.FranssonとA.イェンソン、RVK(RadioVetenskap och Kommunikation)、ストックホルム(スウェーデン)のページの「IPv4-オプションへの代替手段の必要性」 162-166と、2002年6月。
[Fu02] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on
RSVP Regarding Multicast". Technical Report No. IFI-
TB-2002-001, ISSN 1611-1044, Institute for
Informatics, University of Goettingen, Oct 2002.
[Fu02] X.フー、C.Kappler、およびH.Tschofenig、「マルチキャストに関するRSVPの分析。」 技術報告書No. IFI Tb2002-001、ISSN1611-1044、情報学の研究所、Goettingen、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]ユッカManner(キモRaatikainen)は「ワイヤレス・アクセスネットワークでマルチメディア応用のためのQoS管理を局所化しました」。 インターネット、Multimedia Systems、およびApplications(IMSA2003)の上のIASTEDの国際コンファレンス、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.カルステン、「リモートクライアントの、そして、1パスのRSVPへの実験的な拡大、合図、」 IWQoS2001、カールスルーエ(ドイツ)2001年6月。
[KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz,
"Implementation and Evaluation of the KOM RSVP
Engine", IEEE Infocom 2001.
[KSS01] M.カルステンと、ジェン・シュミットと、ラルフ・シュタインメッツと、「KOM RSVPエンジンの実現と評価」、IEEE Infocom2001
[LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A.
Campbell,"INSIGNIA: An IP-Based Quality of Service
Framework for Mobile Ad Hoc Networks". Journal of
Parallel and Distributed Computing (Academic Press),
Special issue on Wireless and Mobile Computing and
Communications, Vol. 60, Number 4, April, 2000, pp.
374-406.
[LGZC00]S.リー、A.Gahng-Seop、X.チャン、A.キャンベル、「記章:」 「モバイル臨時のネットワークのためのIPベースのサービスの質枠組み。」 ParallelのジャーナルとDistributed Computing(アカデミックプレス社)、SpecialはWirelessとモバイルComputingとCommunications、Vol.60、Number4、2000年4月にページを発行します。 374-406.
Manner & Fu Informational [Page 39] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[39ページ]のRFC4094Analysis
[MA01] B. Moon, and H. Aghvami, "RSVP Extensions for Real-
Time Services in Wireless Mobile Networks". IEEE
Communications Magazine, December 2001, pp. 52-59.
[MA01]B.月、およびH.Aghvami、「無線のモバイルネットワークにおける本当の時間指定サービスのためのRSVP拡張子。」 IEEE Communications Magazine、2001年12月、ページ 52-59.
[MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An
Architectural Comparison of ST-II and RSVP", Infocom
1994.
[MESZ94] D.Mitzel、D.Estrin、S.Shenker、およびL.チャン、「建築比較、第-、II、RSVP、」、Infocom1994
[MHS02] Y Miao, W. Hwang, and C. Shieh, "A transparent
deployment method of RSVP-aware applications on UNIX".
Computer Networks, 40 (2002), pp. 45-56.
[MHS02] Yミャオ、W.ファン、およびC.Shieh、「UNIXにおけるRSVP意識しているアプリケーションの見え透いた展開方法。」 コンピュータNetworks、40(2002)、ページ 45-56.
[MSK+04] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
Raatikainen, "Localized RSVP", Work in Progress,
September 2004.
[MSK+04] J.方法、T.Suihko、M.Kojo、M.Liljeberg、「局所化されたRSVP」というK.Raatikainenは進歩、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.Ishimatsu、およびY.Rekhter、「GMPLS UNI:」 「オーバレイモデルのRSVPサポート」、処理中の作業、2004年2月。
[PS97] P. Pan and H. Schulzrinne, "Staged refresh timers for
RSVP", Global Internet, Phoenix, Arizona, November
1997.
[PS97] P.PanとH.Schulzrinne、「上演されて、RSVPのためにタイマをリフレッシュしてください」、Globalインターネット、フェニックス(アリゾナ)1997年11月。
[PS98] P. Pan, and H. Schulzrinne, "YESSIR: A Simple
Reservation Mechanism for the Internet". Proceedings
of NOSSDAV, Cambridge, UK, July 1998.
[PS98]P.なべ、およびH.Schulzrinne、「YESSIR:」 「インターネットへの簡単な予約メカニズム。」 1998年7月のNOSSDAV、ケンブリッジイギリスの議事。
[PS00] P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel
extension for IP option packet processing", Technical
Memorandum 10009669-02TM, Bell Labs, Lucent
Technologies, Murray Hill, NJ, June 2000.
[PS00]P.なべ、およびH.Schulzrinne、「pf_IPOPTION:」 「IPオプションパケット処理のためのカーネル拡大」、Technical Memorandum10009669-02TM、ベル研究所、ルーセントテクノロジーズ、マリー・ヒル(ニュージャージー)2000年6月。
[RFC1819] Delgrossi, L. and L. Berger, "Internet Stream Protocol
Version 2 (ST2) Protocol Specification - Version
ST2+", RFC 1819, August 1995.
[RFC1819] Delgrossi、L.、およびL.バーガー、「インターネット流れのプロトコルバージョン2(ST2)は仕様を議定書の中で述べます--バージョンST2+」、RFC1819、1995年8月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC2207] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
Manner & Fu Informational [Page 40] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[40ページ]のRFC4094Analysis
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RFC2379] Berger, L., "RSVP over ATM Implementation Guidelines",
BCP 24, RFC 2379, August 1998.
[RFC2379]バーガー、L.、「気圧実施要綱の上のRSVP」、BCP24、RFC2379、1998年8月。
[RFC2380] Berger, L., "RSVP over ATM Implementation
Requirements", RFC 2380, August 1998.
[RFC2380]バーガー、L.、「気圧実現要件の上のRSVP」、RFC2380、1998年8月。
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang,
"RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC2745] TerzisとA.とブレーデンとB.とヴィンセント、S.とL.チャン、「RSVP診断メッセージ」、RFC2745、2000年1月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
2000年1月の[RFC2746]TerzisとA.とKrawczykとJ.とWroclawski、J.とL.チャン、「IP Tunnelsの上のRSVP操作」RFC2746。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
January 2000.
[RFC2749]ハーツォグとS.とボイルとJ.とコーエンとR.とダラムとD.とRajan、R.とA.Sastry、「RSVPのためのCOPS用法」RFC2749(2000年1月)。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC
2750, January 2000.
[RFC2750] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
[RFC2814] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and
M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol
for RSVP-based Admission Control over IEEE 802-style
networks", RFC 2814, May 2000.
[RFC2814] Yavatkar、R.、ホフマン、D.、Bernet、Y.、ベイカー、F.、およびM.シュペーア、「SBM(サブネット帯域幅マネージャ):」 「IEEEの802スタイルのネットワークの上のRSVPベースのAdmission Controlのためのプロトコル」、RFC2814、2000年5月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F., and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC2961] バーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(2001年4月)。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[RFC2996] Bernet、Y.、「RSVP DCLASS物の形式」、RFC2996、2000年11月。
[RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of
the Null Service Type", RFC 2997, November 2000.
2000年11月の[RFC2997]BernetとY.とスミス、A.とB.デイビー、「ヌルサービスタイプの仕様」RFC2997。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang,
L., Speer, M., Braden, R., Davie, B., Wroclawski, J.,
and E. Felstaine, "A Framework for Integrated Services
Operation over Diffserv Networks", RFC 2998, November
2000.
[RFC2998] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE.Felstaine、「Diffservネットワークの上の統合サービス操作のための枠組み」、RFC2998(2000年11月)。
Manner & Fu Informational [Page 41] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[41ページ]のRFC4094Analysis
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC3175] ベイカー、F.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001
[RFC3181] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC3181、2001年10月
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., and R. Hess, "Identity Representation
for RSVP", RFC 3182, October 2001.
[RFC3182]YadavとS.とYavatkarとR.とPabbatiとR.とフォードとP.とムーアとT.とハーツォグ、S.とR.ヘス、「RSVPのアイデンティティ表現」RFC3182(2001年10月)。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[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.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture
and framework", RFC 3303, August 2002.
そして、[RFC3303]Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリトル、A.、A.Rayhanと、「Middlebox通信アーキテクチャと枠組み」、RFC3303(2002年8月)
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、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)」、RFC3477、2003年1月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
"Session Authorization Policy Element", RFC 3520,
April 2003.
[RFC3520]ヘーマーとL-N.とゲージとB.とコジンスキー、B.とH.Shieh、「セッション認可方針要素」、RFC3520、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] ネットワーク・プロトコル(ICNP2002、パリ(フランス)2002年11月)に関するR.ソフィア、R.ゲラン、およびP.ベイガ、「相互ドメインコントロール集合手順の調査」国際会議。
[SGV03] R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared-
segment Inter-domain Control Aggregation Protocol.
High Performance Switching and Routing, HPSR 2003,
Turin, Italy, June 2003.
[SGV03] R.ソフィア、R.ゲラン、およびP.ベイガ。 SICAP、SharedセグメントInter-ドメインControl Aggregationプロトコル。 高性能の切り換えとルート設定、HPSR2003、トリノ(イタリア)2003年6月。
Manner & Fu Informational [Page 42] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[42ページ]のRFC4094Analysis
[SGV03b] R. Sofia, R. Guerin, and P. Veiga. A Study of Over-
reservation for Inter-Domain Control Aggregation
Protocols. Technical report (short version under
submission), University of Pennsylvania, May 2003,
available at http://einstein.seas.upenn.edu/mnlab/
publications.html.
[SGV03b] R.ソフィア、R.ゲラン、およびP.ベイガ。 Inter-ドメインControl AggregationプロトコルのOverの予約のStudy。 技術報告書(服従している縮約版)、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.徴税支区の徴税官、B.バドリーナート、およびA.Acharya、「MRSVP:」 「モバイルHostsとIntegrated Services NetworkのためのResource予約プロトコル」、Wireless Networks、vol.7、No.1、ページ 5-19, 2001.
[Thom02] M. Thomas, "Analysis of Mobile IP and RSVP
Interactions", Work in Progress, October 2002.
[Thom02]M.トーマス、「モバイルIPとRSVP相互作用の分析」は進歩、2002年10月に働いています。
[Tsch03] H. Tschofenig, "RSVP Security Properties", Work in
Progress, February 2004.
「RSVPセキュリティの特性」という[Tsch03]H.Tschofenigは進歩、2004年2月に働いています。
[ZDSZ93] L. Zhang, S. Deering, D. Estrin, and D. Zappala,
"RSVP: A New Resource Reservation Protocol", IEEE
Network, Volume 7, Pages 8-18, September 1993.
[ZDSZ93] L.チャン、S.デアリング、D.Estrin、およびD.Zappala、「RSVP:」 「新しい資源予約プロトコル」、IEEEネットワーク、第7巻、8-18ページ、1993年9月。
[URL1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
[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
Manner & Fu Informational [Page 43] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[43ページ]のRFC4094Analysis
Authors' Addresses
作者のアドレス
Jukka Manner Department of Computer Science University of Helsinki P.O. Box 68 (Gustav Hallstrominkatu 2b) FIN-00014 HELSINKI Finland
ヘルシンキ私書箱68(グスタフHallstrominkatu 2b)フィン-00014ヘルシンキフィンランドのユッカ方法コンピュータサイエンス学部大学
Phone: +358-9-191-51298 Fax: +358-9-191-51120 EMail: jmanner@cs.helsinki.fi
以下に電話をしてください。 +358-9-191-51298 Fax: +358-9-191-51120 メールしてください: jmanner@cs.helsinki.fi
Xiaoming Fu Institute for Informatics Georg-August-University of Goettingen Lotzestrasse 16-18 37083 Goettingen Germany
Goettingen Lotzestrasse16-18 37083Goettingenドイツの情報学ゲオルク8月の大学のフー学会をXiaomingします。
Phone: +49-551-39-14411 Fax: +49-551-39-14403 EMail: fu@cs.uni-goettingen.de
以下に電話をしてください。 +49-551-39-14411 Fax: +49-551-39-14403 メールしてください: fu@cs.uni-goettingen.de
Manner & Fu Informational [Page 44] RFC 4094 Analysis of QoS Signaling May 2005
2005年5月に合図するQoSの方法とフー情報[44ページ]のRFC4094Analysis
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Manner & Fu Informational [Page 45]
方法とフーInformationalです。[45ページ]
一覧
スポンサーリンク
