RFC2205 日本語訳
2205 Resource ReSerVation Protocol (RSVP) -- Version 1 FunctionalSpecification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S.Jamin. September 1997. (Format: TXT=223974 bytes) (Updated by RFC2750, RFC3936, RFC4495) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Braden, Ed.
Request for Comments: 2205 ISI
Category: Standards Track L. Zhang
UCLA
S. Berson
ISI
S. Herzog
IBM Research
S. Jamin
Univ. of Michigan
September 1997
ワーキンググループのR.ブレーデン、エドをネットワークでつないでください。コメントのために以下を要求してください。 2205年のISIカテゴリ: 規格は1997年9月にミシガンのL.チャンUCLA S.Berson ISI S.ハーツォグIBM研究S.ジャマン大学を追跡します。
Resource ReSerVation Protocol (RSVP) --
資源予約プロトコル(RSVP)--
Version 1 Functional Specification
バージョン1の機能的な仕様
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
このメモはRSVPのバージョン1、統合サービスインターネットに設計された資源予約セットアッププロトコルについて説明します。 RSVPはマルチキャストの資源予約か利益が比例するユニキャストデータフローと丈夫さの特性の受信機で開始しているセットアップを提供します。
Braden, Ed., et. al. Standards Track [Page 1] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ................................................... 4
1.1 Data Flows ................................................. 7
1.2 Reservation Model .......................................... 8
1.3 Reservation Styles .........................................11
1.4 Examples of Styles .........................................14
2. RSVP Protocol Mechanisms .......................................19
2.1 RSVP Messages ..............................................19
2.2 Merging Flowspecs ..........................................21
2.3 Soft State .................................................22
2.4 Teardown ...................................................24
2.5 Errors .....................................................25
2.6 Confirmation ...............................................27
2.7 Policy Control .............................................27
2.8 Security ...................................................28
2.9 Non-RSVP Clouds ............................................29
2.10 Host Model ................................................30
3. RSVP Functional Specification ..................................32
3.1 RSVP Message Formats .......................................32
3.2 Port Usage .................................................47
3.3 Sending RSVP Messages ......................................48
3.4 Avoiding RSVP Message Loops ................................50
3.5 Blockade State .............................................54
3.6 Local Repair ...............................................56
3.7 Time Parameters ............................................57
3.8 Traffic Policing and Non-Integrated Service Hops ...........58
3.9 Multihomed Hosts ...........................................59
3.10 Future Compatibility ......................................61
3.11 RSVP Interfaces ...........................................63
4. Acknowledgments ................................................76
APPENDIX A. Object Definitions ....................................77
APPENDIX B. Error Codes and Values ................................92
APPENDIX C. UDP Encapsulation .....................................98
APPENDIX D. Glossary .............................................102
REFERENCES .......................................................111
SECURITY CONSIDERATIONS ..........................................111
AUTHORS' ADDRESSES ...............................................112
1. 序論… 4 1.1のデータが流れます… 7 1.2予約モデル… 8 1.3 予約様式…11 様式に関する1.4の例…14 2. RSVPはメカニズムについて議定書の中で述べます…19 2.1 RSVPメッセージ…19 2.2 Flowspecsを合併します…21 2.3 柔らかい状態…22 2.4分解…24 2.5の誤り…25 2.6確認…27 2.7 方針コントロール…27 2.8セキュリティ…28 2.9 非RSVPは曇ります…29 2.10 モデルをホスティングしてください…30 3. RSVPの機能的な仕様…32 3.1 RSVPメッセージ・フォーマット…32 3.2 用法を移植してください…47 3.3 メッセージをRSVPに送ります…48 3.4 RSVPメッセージを避けるのは輪にされます…50 3.5 状態を封鎖してください…54 3.6 地方の修理…56 3.7 時間パラメタ…57 3.8 トラフィックの取り締まっていて非統合しているサービスは跳びます…58 3.9はホストをMultihomedしました…59 3.10 将来の互換性…61 3.11 RSVPは連結します…63 4. 承認…76 付録A.オブジェクト定義…77 付録B.エラーコードと値…92 付録C.UDPカプセル化…98付録D.用語集…102の参照箇所…111 セキュリティ問題…111人の作者のアドレス…112
Braden, Ed., et. al. Standards Track [Page 2] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[2ページ]。
What's Changed
変化したもの
This revision contains the following very minor changes from the ID14 version.
この改正はID14バージョンからの以下のまさしくそのマイナーチェンジを含んでいます。
o For clarity, each message type is now defined separately in
Section 3.1.
o 明快において、それぞれのメッセージタイプは現在、別々にセクション3.1で定義されます。
o We added more precise and complete rules for accepting Path
messages for unicast and multicast destinations (Section
3.1.3).
o 私たちはユニキャストへのPathメッセージとマルチキャストの目的地(セクション3.1.3)を受け入れるための、より正確で完全な規則を加えました。
o We added more precise and complete rules for processing and
forwarding PathTear messages (Section 3.1.5).
o 私たちは処理と推進PathTearメッセージ(セクション3.1.5)のために、より正確で完全な規則を加えました。
o A note was added that a SCOPE object will be ignored if it
appears in a ResvTear message (Section 3.1.6).
o SCOPEがResvTearメッセージ(セクション3.1.6)に現れるなら無視されるのを反対させる注意は加えられました。
o A note was added that a SENDER_TSPEC or ADSPEC object will be
ignored if it appears in a PathTear message (Section 3.1.5).
o SENDER_TSPECかADSPECがPathTearメッセージ(セクション3.1.5)に現れるなら無視されるのを反対させる注意は加えられました。
o The obsolete error code Ambiguous Filter Spec (09) was
removed, and a new (and more consistent) name was given to
error code 08 (Appendix B).
o 時代遅れのエラーコードAmbiguous Filter Spec(09)を移しました、そして、エラーコード08(付録B)に新しくて(より一貫する)の名前を与えました。
o In the generic interface to traffic control, the Adspec was
added as a parameter to the AddFlow and ModFlow calls
(3.11.2). This is needed to accommodate a node that updates
the slack term (S) of Guaranteed service.
o AddFlowとModFlowへのパラメタが呼ぶようにトラフィックコントロールへのジェネリックインタフェースでは、Adspecが加えられた、(3.11、.2、) これが、低調なGuaranteedサービスの諸条件(S)をアップデートするノードに対応するのに必要です。
o An error subtype was added for an Adspec error (Appendix B).
o 誤り「副-タイプ」はAdspec誤り(付録B)によって加えられました。
o Additional explanation was added for handling a CONFIRM
object (Section 3.1.4).
o 追加説明は、CONFIRMオブジェクト(セクション3.1.4)を扱うために加えられました。
o The rules for forwarding objects with unknown class type were
clarified.
o 未知のクラスタイプでオブジェクトを進めるための規則ははっきりさせられました。
o Additional discussion was added to the Introduction and to
Section 3.11.2 about the relationship of RSVP to the link
layer. (Section 3.10).
o 追加議論はIntroductionと、そして、リンクレイヤへのRSVPの関係に関するセクション3.11.2に加えられました。 (セクション3.10。)
o Section 2.7 on Policy and Security was split into two
sections, and some additional discussion of security was
included.
o PolicyとSecurityの上のセクション2.7は2つのセクションに分割されました、そして、セキュリティの何らかの追加議論が含められました。
o There were some minor editorial improvements.
o いくつかの小さい方の編集の改良がありました。
Braden, Ed., et. al. Standards Track [Page 3] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[3ページ]。
1. Introduction
1. 序論
This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet [RSVP93, RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path.
このドキュメントはRSVP、統合サービスインターネット[RSVP93、RFC1633]に設計された資源予約セットアッププロトコルを定義します。 RSVPプロトコルは、特定用途データ・ストリームのためにネットワークから特定のサービスの品質を要求するのにホストによって使用されるか、または流れます。 要求されたサービスを提供するために状態をまた、RSVPはルータによって使用されて、サービスの質(QoS)要求を流れの経路に沿ったすべてのノードに提供して、設置して、維持します。 一般に、RSVP要求はデータ経路に沿った各ノードで予約されるリソースをもたらすでしょう。
RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1.
RSVPはシンプレクス流れのためのリソースを要求します、すなわち、それが一方向だけにリソースを要求します。 したがって、RSVPは受信機と論理的に異なるとして送付者を扱います、同じアプリケーション・プロセスが同時に、送付者と受信機の両方として機能するかもしれませんが。 プロトコル・スタックでトランスポート・プロトコルの場所を占領して、RSVPはIPv4かIPv6の上で作動します。 しかしながら、RSVPはアプリケーションデータを輸送しませんが、ICMP、IGMP、またはルーティング・プロトコルのようにむしろインターネット制御プロトコルです。 ルーティングと管理プロトコルの実装のように、RSVPの実装は目立つように経路を進めるデータで仕上げるのではなく、バックグラウンドで図を通常1に仕上げるでしょう。
RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing.
RSVPはそれ自体でルーティング・プロトコルではありません。 RSVPは、現在の、そして、将来のユニキャストとマルチキャストルーティング・プロトコルで作動するように設計されています。 RSVPプロセスは、ルートを入手するためにローカルのルーティングデータベースに相談します。 マルチキャスト場合では、例えば、ホストは、マルチキャストグループに加わるメッセージをIGMPに送って、次に、そのグループの配送経路に沿ってリソースを予約するメッセージをRSVPに送ります。 ルーティング・プロトコルは、パケットがどこで進められるかを決定します。 RSVPはルーティングに応じて進められるそれらのパケットのQoSに関係があるだけです。
In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [RSVP93]. A QoS request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers.
効率的に大きいグループ、ダイナミックなグループ会員資格、および異種の受信機要件に対応するために、RSVPは受信機を特定のQoS[RSVP93]を要求するのに責任があるようにします。 QoSは、受信ホストからアプリケーションが地方のRSVPプロセスに合格されるよう要求します。 要求がその時、データ送信端末への逆のデータ経路に沿ったすべてのノード(ルータとホスト)まで運ばれますが、受信機のデータ経路がマルチキャスト分配木に合流するところでRSVPプロトコルはルータと同じくらい遠くにだけ運びます。 その結果、一般に、RSVPの予約オーバーヘッドはそうです。受信機の数で直線的であるというよりむしろ、対数です。
Braden, Ed., et. al. Standards Track [Page 4] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[4ページ]。
HOST ROUTER
ホストルータ
_____________________________ ____________________________ | _______ | | | | | | _______ | | _______ | | |Appli- | | | |RSVP | | | | | | cation| | RSVP <---------------------------> RSVP <----------> | | <--> | | | _______ | | | | | | |process| _____ | ||Routing| |process| _____ | | |_._____| | -->Polcy|| || <--> -->Polcy|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| | |data | | |_____|| ||__.____| | | |_____|| |===|===========|==|==========| |===|==========|==|==========| | | --------| | _____ | | | --------| | _____ | | | | | ---->Admis|| | | | | ---->Admis|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | | | | | |_____|| | | | | ||_____|| | |Class-| | Packet | | | |Class-| | Packet | | | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> | |______| |________| |data | |______| |________| |data | | | | |_____________________________| |____________________________|
_____________________________ ____________________________ | _______ | | | | | | _______ | | _______ | | |Appli| | | |RSVP| | | | | | 陽イオン| | RSVP<。--------------------------->RSVP<。---------->|、| <--、>|、|、| _______ | | | | | | |プロセス| _____ | ||ルート設定| |プロセス| _____ | | |_._____| | -->Polcy|| || <-->-->Polcy|| | | |__.__._| |Cntrl|| ||プロセス| |__.__._| |Cntrl|| | |データ| | |_____|| ||__.____| | | |_____|| |===|===========|==|==========| |===|==========|==|==========| | | --------| | _____ | | | --------| | _____ | | | | | ---->Admis|| | | | | ---->Admis|| | _V__V____V____ |Cntrl|| | _V__V_ ______ |Cntrl|| | | | | | |_____|| | | | | ||_____|| | |クラス| | パケット| | | |クラス| | パケット| | | | ifier|==>Schedulr|================>ifier|==>Schedulr|===========>||______| |________| |データ| |______| |________| |データ| | | | |_____________________________| |____________________________|
Figure 1: RSVP in Hosts and Routers
図1: ホストとルータにおけるRSVP
Quality of service is implemented for a particular data flow by mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group.
サービスの質は特定のデータフローのためにまとめて「トラフィックコントロール」と呼ばれるメカニズムによって実装されます。 これらのメカニズムは、特定のパケットがいつ進められるかを決定するために(3) (1) パケットクラシファイアか、(2) 入場コントロールと、「パケットスケジューラ」かある他のリンク層に依存するメカニズムを含んでいます。 「パケットクラシファイア」は各パケットのために、QoSのクラス(そして、恐らくルート)を決定します。 それぞれの外向的なインタフェースに関しては、「パケットスケジューラ」か他のリンク層に依存するメカニズムが約束のQoSを実現します。 トラフィックコントロール道具QoSはIntegrated Services作業部会によって定義されたモデルにサービスを提供します。
During reservation setup, an RSVP QoS request is passed to 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
予約セットアップの間、RSVP QoS要求は2つのローカルの決定モジュール、「入場コントロール」、および「方針コントロール」に合格されます。 入場コントロールは、ノードには要求されたQoSを供給できるくらいの利用可能資源があるかどうか決定します。 方針コントロール
Braden, Ed., et. al. Standards Track [Page 5] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[5ページ]。
determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request.
ユーザに予約をする管理許可があるか否かに関係なく、決定します。 両方のチェックが成功するなら、パラメタはパケットクラシファイアと必要なQoSを入手するリンクレイヤインタフェース(例えば、パケットスケジューラの)のセットです。 どちらのチェックも失敗するなら、RSVPプログラムは要求を溯源したアプリケーション・プロセスにエラー通知を返します。
RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development.
RSVPプロトコルメカニズムはマルチキャストかユニキャスト配送経路のメッシュの向こう側に分散予約状態を創設して、維持するのに一般的な施設を提供します。 RSVP自身は不明瞭なデータとしてQoSと方針管理パラメータを移して、操作します、解釈のための適切なトラフィックコントロールと方針コントロールモジュールにそれらを通過して。 QoSパラメタの構造とコンテンツはIntegrated Services作業部会によって開発された仕様に記録されます。 [RFC2210]を見てください。 方針パラメタの構造とコンテンツは開発中です。
Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted.
大きいマルチキャストグループの会員資格と結果として起こるマルチキャスト木のトポロジーが時間を交換しそうであるので、RSVPデザインは、RSVPのための州とトラフィックコントロール状態がルータとホストで増加して造られて、破壊されることになっていると仮定します。 このために、RSVPは「柔らかい」状態を設置します。 すなわち、RSVPは周期的に発信します。予約された経路に沿った状態が(s)であると主張するメッセージをリフレッシュしてください。 が不在のとき、メッセージをリフレッシュしてください、外に自動的に回を述べて、削除されます。
In summary, RSVP has the following attributes:
概要では、RSVPは以下の属性を持っています:
o RSVP makes resource reservations for both unicast and many-to-
many multicast applications, adapting dynamically to changing
group membership as well as to changing routes.
o RSVPは-多くのマルチキャストアプリケーションに、ダイナミックに変化に順応するのがルートを変えることに関してまた、会員資格を分類するというユニキャストと多くの両方の資源予約をします。
o RSVP is simplex, i.e., it makes reservations for unidirectional
data flows.
o RSVPがシンプレクスである、すなわち、それは単方向のデータフローの予約をします。
o RSVP is receiver-oriented, i.e., the receiver of a data flow
initiates and maintains the resource reservation used for that
flow.
o RSVPが受信機指向であり、すなわち、データフローの受信機は、その流れに使用される資源予約を、開始して、維持します。
o RSVP maintains "soft" state in routers and hosts, providing
graceful support for dynamic membership changes and automatic
adaptation to routing changes.
o RSVPはルータとホストで「柔らかい」状態を維持します、ダイナミックな会員資格変化とルーティング変化への自動適合の優雅なサポートを提供して。
o RSVP is not a routing protocol but depends upon present and
future routing protocols.
o RSVPはルーティング・プロトコルではありませんが、現在の、そして、将来のルーティング・プロトコルによります。
o RSVP transports and maintains traffic control and policy control
parameters that are opaque to RSVP.
o RSVPはトラフィックコントロールとRSVPに不明瞭な方針管理パラメータを、輸送して、維持します。
Braden, Ed., et. al. Standards Track [Page 6] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[6ページ]。
o RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications.
o RSVPは、さまざまなアプリケーションに合うように、数個の予約モデルか「スタイル」(以下では、定義される)を提供します。
o RSVP provides transparent operation through routers that do not
support it.
o RSVPはそれをサポートしないルータを通してわかりやすい操作を提供します。
o RSVP supports both IPv4 and IPv6.
o RSVPはIPv4とIPv6の両方をサポートします。
Further discussion on the objectives and general justification for RSVP design are presented in [RSVP93] and [RFC 1633].
目的のさらなる議論とRSVPデザインのための一般的な正当化は[RSVP93]と[RFC1633]に提示されます。
The remainder of this section describes the RSVP reservation services. Section 2 presents an overview of the RSVP protocol mechanisms. Section 3 contains the functional specification of RSVP, while Section 4 presents explicit message processing rules. Appendix A defines the variable-length typed data objects used in the RSVP protocol. Appendix B defines error codes and values. Appendix C defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support.
このセクションの残りはRSVP予約サービスについて説明します。 セクション2はRSVPプロトコルメカニズムの概要を提示します。セクション3はRSVPの機能的な仕様を含みます、セクション4は明白なメッセージ処理規則を提示しますが。 付録AはRSVPプロトコルに使用される可変長のタイプされたデータ・オブジェクトを定義します。 付録Bはエラーコードと値を定義します。 付録Cはオペレーティングシステムが不十分な生のネットワーク入出力サポートを提供するホストへのRSVPメッセージのUDPカプセル化を定義します。
1.1 Data Flows
1.1 データ流れ
RSVP defines a "session" to be a data flow with a particular
destination and transport-layer protocol. RSVP treats each
session independently, and this document often omits the implied
qualification "for the same session".
RSVPは、特定の目的地とトランスポート層プロトコルがあるデータフローになるように「セッション」を定義します。 RSVPは各セッションのときに独自に扱います、そして、このドキュメントは「同じセッション」のためにしばしば暗示している資格を省略します。
An RSVP session is defined by the triple: (DestAddress, ProtocolId
[, DstPort]). Here DestAddress, the IP destination address of the
data packets, may be a unicast or multicast address. ProtocolId
is the IP protocol ID. The optional DstPort parameter is a
"generalized destination port", i.e., some further demultiplexing
point in the transport or application protocol layer. DstPort
could be defined by a UDP/TCP destination port field, by an
equivalent field in another transport protocol, or by some
application-specific information.
RSVPセッションは三重によって定義されます: (DestAddress、ProtocolId[DstPort]。) ここで、DestAddress(データ・パケットの受信者IPアドレス)はユニキャストかマルチキャストアドレスであるかもしれません。 ProtocolIdはIPプロトコルIDです。 任意のDstPortパラメタは「一般化された仕向港」(輸送かアプリケーションプロトコル層のすなわち何らかのより遠い逆多重化ポイント)です。 UDP/TCP仕向港分野でDstPortを定義できました、別のトランスポート・プロトコル、または何らかのアプリケーション特有の情報による同等な分野のそばで。
Although the RSVP protocol is designed to be easily extensible for
greater generality, the basic protocol documented here supports
only UDP/TCP ports as generalized ports. Note that it is not
strictly necessary to include DstPort in the session definition
when DestAddress is multicast, since different sessions can always
have different multicast addresses. However, DstPort is necessary
to allow more than one unicast session addressed to the same
receiver host.
RSVPプロトコルは、より重要な一般性において容易に広げることができるように設計されていますが、ここに記録された基本プロトコルは一般化されたポートとしてUDP/TCPポートだけを支えます。 DestAddressがマルチキャストであるときにはセッション定義にDstPortを含むのは厳密に必要でないことに注意してください、異なったセッションがいつも異なったマルチキャストアドレスを持つことができるので。 しかしながら、DstPortが、同じ受信ホストに扱われた1つ以上のユニキャストセッションを許容するのに必要です。
Braden, Ed., et. al. Standards Track [Page 7] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[7ページ]。
Figure 2 illustrates the flow of data packets in a single RSVP
session, assuming multicast data distribution. The arrows
indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, and the cloud represents the distribution mesh created by
multicast routing. Multicast distribution forwards a copy of each
data packet from a sender Si to every receiver Rj; a unicast
distribution session has a single receiver R. Each sender Si may
be running in a unique Internet host, or a single host may contain
multiple senders distinguished by "generalized source ports".
マルチキャストデータが分配であると仮定して、図2はただ一つのRSVPセッションにおける、データ・パケットの流れを例証します。 矢は受信機のR1、R2、および送付者のS1とS2からR3まで流れるデータを示します、そして、雲はマルチキャストルーティングで作成された分配メッシュを表します。 マルチキャスト分配は送付者Siからあらゆる受信機Rjまでそれぞれのデータ・パケットのコピーを進めます。 ユニキャスト分配セッションには、Siがユニークなインターネット・ホストで車で送っているかもしれない独身の受信機R.Each送付者がいるか、または独身のホストは「一般化されたソースポート」によって区別された複数の送付者を含むかもしれません。
Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( by Internet ) ===> R3
(_____________________)
送付者受信機_____________________ ( ) ===>R1 S1===>(マルチキャスト)( )===>R2(分配)S2===>( )(インターネットのそばの)===>R3(_____________________)
Figure 2: Multicast Distribution Session
図2: マルチキャスト分配セッション
For unicast transmission, there will be a single destination host
but there may be multiple senders; RSVP can set up reservations
for multipoint-to-single-point transmission.
ユニキャスト送信を支持して、独身のあて先ホストがいるでしょうが、複数の送付者がいるかもしれません。 RSVPは多点から単一のポイントへのトランスミッションの予約をセットアップできます。
1.2 Reservation Model
1.2 予約モデル
An elementary RSVP reservation request consists of a "flowspec"
together with a "filter spec"; this pair is called a "flow
descriptor". The flowspec specifies a desired QoS. The filter
spec, together with a session specification, defines the set of
data packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set parameters in the node's
packet scheduler or other link layer mechanism, while the filter
spec is used to set parameters in the packet classifier. Data
packets that are addressed to a particular session but do not
match any of the filter specs for that session are handled as
best-effort traffic.
基本のRSVP予約の要請は「フィルタ仕様」と共に"flowspec"から成ります。 この組は「流れ記述子」と呼ばれます。 flowspecは必要なQoSを指定します。 フィルタ仕様は、flowspecによって定義されたQoSを受け取るためにセッション仕様と共に「流れ」というデータ・パケットのセットを定義します。 flowspecはノードのパケットスケジューラか他のリンクレイヤメカニズムにパラメタをはめ込むのに使用されます、フィルタ仕様がパケットクラシファイアにパラメタをはめ込むのに使用されますが。 特定のセッションまで扱われますが、そのセッションのためにフィルタ仕様のいずれにも合っていないデータ・パケットがベストエフォート型トラフィックとして扱われます。
The flowspec in a reservation request will generally include a
service class and two sets of numeric parameters: (1) an "Rspec"
(R for `reserve') that defines the desired QoS, and (2) a "Tspec"
(T for `traffic') that describes the data flow. The formats and
contents of Tspecs and Rspecs are determined by the integrated
service models [RFC 2210] and are generally opaque to RSVP.
一般に、予約の要請のflowspecはサービスのクラスと2セットの数値パラメタを含むでしょう: (1) 必要なQoS、および(2) データについて説明する"Tspec"('トラフィック'のためのT)流動を定義する"Rspec"('蓄え'のためのR)。 TspecsとRspecsの形式とコンテンツは、統合サービスモデル[RFC2210]によって決定されて、一般に、RSVPに不透明です。
Braden, Ed., et. al. Standards Track [Page 8] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[8ページ]。
The exact format of a filter spec depends upon whether IPv4 or
IPv6 is in use; see Appendix A. In the most general approach
[RSVP93], filter specs may select arbitrary subsets of the packets
in a given session. Such subsets might be defined in terms of
senders (i.e., sender IP address and generalized source port), in
terms of a higher-level protocol, or generally in terms of any
fields in any protocol headers in the packet. For example, filter
specs might be used to select different subflows of a
hierarchically-encoded video stream by selecting on fields in an
application-layer header. In the interest of simplicity (and to
minimize layer violation), the basic filter spec format defined in
the present RSVP specification has a very restricted form: sender
IP address and optionally the UDP/TCP port number SrcPort.
フィルタ仕様の正確な形式をIPv4かIPv6が使用中であるかどうか依存します。 Appendix A.を見てください。Inの最も一般的なアプローチ[RSVP93]、フィルタ仕様は与えられたセッションのときにパケットの任意の部分集合を選択してもよいです。 そのような部分集合は送付者(すなわち、送付者IPアドレスと一般化されたソースポート)、上位レベル・プロトコル、または一般にパケットのどんなプロトコルヘッダーのどんな分野でも定義されるかもしれません。 例えば、フィルタ仕様は、応用層ヘッダーのフィールドで選択することによって階層的でコード化されたビデオストリームの異なった「副-流れ」を選択するのに使用されるかもしれません。 簡単さのために(層の違反を最小にするために)、現在のRSVP仕様に基づき定義された基本的なフィルタ仕様書式は非常に制限されたフォームを持っています: そして、送付者IPアドレス、任意に、UDP/TCPは数のSrcPortを移植します。
Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields.
This raises three potential problems.
UDP/TCPポートナンバーがパケット分類に使用されるので、それぞれのルータはこれらの分野を調べることができなければなりません。 これは3つの潜在的な問題を提起します。
1. It is necessary to avoid IP fragmentation of a data flow for
which a resource reservation is desired.
1. 資源予約が望まれているデータフローのIP断片化を避けるのが必要です。
Document [RFC 2210] specifies a procedure for applications
using RSVP facilities to compute the minimum MTU over a
multicast tree and return the result to the senders.
ドキュメント[RFC2210]は、マルチキャスト木の上で最小のMTUを計算して、結果を送付者に返すのにRSVP施設を使用することでアプリケーションのための手順を指定します。
2. IPv6 inserts a variable number of variable-length Internet-
layer headers before the transport header, increasing the
difficulty and cost of packet classification for QoS.
2. IPv6は可変数の可変長のインターネット層のヘッダーを輸送ヘッダーの前に挿入します、QoSのためにパケット分類の困難と費用を増強して。
Efficient classification of IPv6 data packets could be
obtained using the Flow Label field of the IPv6 header. The
details will be provided in the future.
IPv6ヘッダーのFlow Label分野を使用することでIPv6データ・パケットの効率的な分類を得ることができるでしょう。 詳細は将来、明らかにされるでしょう。
3. IP-level Security, under either IPv4 or IPv6, may encrypt the
entire transport header, hiding the port numbers of data
packets from intermediate routers.
3. IP-レベルSecurityはIPv4かIPv6のどちらかの下で全体の輸送ヘッダーを暗号化するかもしれません、中間的ルータからデータ・パケットのポートナンバーを隠して。
A small extension to RSVP for IP Security under IPv4 and IPv6
is described separately in [RFC 2207].
小さい拡大は別々に[RFC2207]にIPv4とIPv6の下のIP SecurityのためのRSVPに説明されます。
RSVP messages carrying reservation requests originate at receivers
and are passed upstream towards the sender(s). Note: in this
document, we define the directional terms "upstream" vs.
"downstream", "previous hop" vs. "next hop", and "incoming
interface" vs "outgoing interface" with respect to the direction
of data flow.
予約の要請を運ぶRSVPメッセージが、送付者に向かって受信機で起因して、上流へ渡されます。 以下に注意してください。 本書では、私たちはデータフローの方向に関して「川下」、「次のホップ」に対する「前のホップ」、および「外向的なインタフェース」に対する「入って来るインタフェース」に対して「上流」という方向を示す用語を定義します。
Braden, Ed., et. al. Standards Track [Page 9] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[9ページ]。
At each intermediate node, a reservation request triggers two
general actions, as follows:
それぞれの中間的ノードでは、予約の要請は以下の通り2つの一般的な動作の引き金となります:
1. Make a reservation on a link
1. リンクの上に予約をしてください。
The RSVP process passes the request to admission control and
policy control. If either test fails, the reservation is
rejected and the RSVP process returns an error message to the
appropriate receiver(s). If both succeed, the node sets the
packet classifier to select the data packets defined by the
filter spec, and it interacts with the appropriate link layer
to obtain the desired QoS defined by the flowspec.
RSVPプロセスは入場コントロールと方針コントロールに要求に合格します。 テストが失敗するなら、予約は拒絶されます、そして、RSVPプロセスは適切な受信機にエラーメッセージを返します。 両方が成功するなら、ノードは、パケットクラシファイアにフィルタ仕様によって定義されたデータ・パケットを選択するように設定します、そして、それはflowspecによって定義された必要なQoSを入手するために適切なリンクレイヤと対話します。
The detailed rules for satisfying an RSVP QoS request depend
upon the particular link layer technology in use on each
interface. Specifications are under development in the ISSLL
Working Group for mapping reservation requests into popular
link layer technologies. For a simple leased line, the
desired QoS will be obtained from the packet scheduler in the
link layer driver, for example. If the link-layer technology
implements its own QoS management capability, then RSVP must
negotiate with the link layer to obtain the requested QoS.
Note that the action to control QoS occurs at the place where
the data enters the link-layer medium, i.e., at the upstream
end of the logical or physical link, although an RSVP
reservation request originates from receiver(s) downstream.
RSVP QoS要求を満たすための細則は各インタフェースで使用中の特定のリンクレイヤ技術によります。 ポピュラーなリンクレイヤ技術に予約の要請を写像するのにおいて、仕様はISSLL作業部会で開発中です。 簡単な専用線において、例えば、リンクレイヤドライバーでパケットスケジューラから必要なQoSを入手するでしょう。 リンクレイヤ技術が、それ自身のQoSが管理能力であると実装するなら、RSVPは要求されたQoSを入手するリンクレイヤと交渉しなければなりません。 QoSを制御する動作がすなわち、データがリンクレイヤ媒体を入れる場所、論理的であるか物理的なリンクの上流の端に起こることに注意してください、RSVP予約の要請は川下に受信機から発しますが。
2. Forward the request upstream
2. 要求上流を進めてください。
A reservation request is propagated upstream towards the
appropriate senders. The set of sender hosts to which a
given reservation request is propagated is called the "scope"
of that request.
予約の要請は上流へ適切な送付者に向かって伝播されます。 与えられた予約の要請が伝播される送付者ホストのセットはその要求の「範囲」と呼ばれます。
The reservation request that a node forwards upstream may
differ from the request that it received from downstream, for
two reasons. The traffic control mechanism may modify the
flowspec hop-by-hop. More importantly, reservations from
different downstream branches of the multicast tree(s) from
the same sender (or set of senders) must be " merged" as
reservations travel upstream.
ノードが上流へ転送する予約の要請は川下から受信したという要求と異なるかもしれません、2つの理由で。 トラフィックコントロールメカニズムはflowspecホップごとに変更するかもしれません。 より重要に、予約が上流へ移動するとき、同じ送付者(または、送付者のセット)からのマルチキャスト木の異なった川下の枝からの予約は「合併されなければなりません」。
When a receiver originates a reservation request, it can also
request a confirmation message to indicate that its request was
(probably) installed in the network. A successful reservation
request propagates upstream along the multicast tree until it
reaches a point where an existing reservation is equal or greater
また、受信機が予約の要請を溯源するとき、それは、要求が(たぶん)そうであったのを示す確認メッセージがネットワークにインストールされたよう要求できます。 既存の予約が等しいか、または、より大きいポイントに達するまで、うまくいっている予約の要請はマルチキャスト木に沿って上流へ伝播されます。
Braden, Ed., et. al. Standards Track [Page 10] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[10ページ]。
than that being requested. At that point, the arriving request is
merged with the reservation in place and need not be forwarded
further; the node may then send a reservation confirmation message
back to the receiver. Note that the receipt of a confirmation is
only a high-probability indication, not a guarantee, that the
requested service is in place all the way to the sender(s), as
explained in Section 2.6.
要求されたその存在より。 その時、到着要求を予約が適所にあった状態で合併して、さらに転送する必要はありません。 次に、ノードは予約確認メッセージを受信機に送り返すかもしれません。確認の領収書が要求されたサービスが適所に送付者までのいっぱいにあるという保証ではなく、高確率指示にすぎないことに注意してください、セクション2.6で説明されるように。
The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path either
accepts or rejects the request. This scheme provides no easy way
for a receiver to find out the resulting end-to-end service.
Therefore, RSVP supports an enhancement to one-pass service known
as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP
control packets are sent downstream, following the data paths, to
gather information that may be used to predict the end-to-end QoS.
The results ("advertisements") are delivered by RSVP to the
receiver hosts and perhaps to the receiver applications. The
advertisements may then be used by the receiver to construct, or
to dynamically adjust, an appropriate reservation request.
基本的なRSVP予約モデルは「1個のパス」です: 受信機が予約の要請上流を送って、経路の各ノードは、要求を受け入れるか、または拒絶します。 この計画は、終わりから終わりに対する結果として起こるサービスを見つけるために受信機のためのどんな簡単な方法も提供しません。 したがって、RSVPは「広告がある1つのパス」(OPWA)[OPWA95]として知られている1パスのサービスに増進を支持します。 OPWAと共に、RSVPコントロールパケットを川下に送ります、終わりから終わりへのQoSを予測するのに使用されるかもしれない情報を集めるためにデータ経路に続いて。 結果(「広告」)はRSVPによって受信ホストと、そして、恐らく受信側アプリケーションに送られます。 そして、広告は組み立てるか、またはダイナミックに調整する受信機、適切な予約の要請によって使用されるかもしれません。
1.3 Reservation Styles
1.3 予約様式
A reservation request includes a set of options that are
collectively called the reservation "style".
予約の要請はまとめて予約「スタイル」と呼ばれる1セットのオプションを含んでいます。
One reservation option concerns the treatment of reservations for
different senders within the same session: establish a "distinct"
reservation for each upstream sender, or else make a single
reservation that is "shared" among all packets of selected
senders.
1つの予約オプションが同じセッション中に異なった送付者の予約の処理に関係があります: それぞれの上流の送付者の「異なった」予約を確立するか、または選択された送付者のすべてのパケットの中で「共有される」ただ一つの予約をしてください。
Another reservation option controls the selection of senders; it
may be an "explicit" list of all selected senders, or a "wildcard"
that implicitly selects all the senders to the session. In an
explicit sender-selection reservation, each filter spec must match
exactly one sender, while in a wildcard sender-selection no filter
spec is needed.
別の予約オプションは送付者の品揃えを制御します。 それは、すべての選択された送付者の「明白な」リスト、またはセッションまでそれとなくすべての送付者を選ぶ「ワイルドカード」であるかもしれません。 明白な送付者選択の予約では、それぞれのフィルタ仕様はちょうど1人の送付者に合わなければなりません、ワイルドカード送付者選択では、フィルタ仕様が全く必要ではありませんが。
Braden, Ed., et. al. Standards Track [Page 11] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[11ページ]。
Sender || Reservations:
Selection || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|
送付者|| 予約: 選択|| 異なる| 共有されます。_________||__________________|____________________ || | | 明白|| 固定フィルタ| 共有されて明白です。| || (ff) スタイル| (SE) 様式| __________||__________________|____________________| || | | ワイルドカード|| (定義されなかったなにも) | ワイルドカードフィルタ| || | (WF) 様式| __________||__________________|____________________|
Figure 3: Reservation Attributes and Styles
図3: 予約属性と様式
The following styles are currently defined (see Figure 3):
以下のスタイルは現在、定義されます(図3を見てください):
o Wildcard-Filter (WF) Style
o ワイルドカードフィルタ(WF)様式
The WF style implies the options: "shared" reservation and
"wildcard" sender selection. Thus, a WF-style reservation
creates a single reservation shared by flows from all
upstream senders. This reservation may be thought of as a
shared "pipe", whose "size" is the largest of the resource
requests from all receivers, independent of the number of
senders using it. A WF-style reservation is propagated
upstream towards all sender hosts, and it automatically
extends to new senders as they appear.
WFスタイルはオプションを含意します: 「共有された」予約と「ワイルドカード」送付者選択。 したがって、WF-スタイルの予約はすべての上流の送付者からの流れによって共有されたただ一つの予約を作成します。 この予約はすべての受信機からの資源要求で「サイズ」が最も大きい共有された「パイプ」として考えられるかもしれません、それを使用している送付者の数の如何にかかわらず。 WF-スタイルの予約は上流へすべての送付者ホストに向かって伝播されます、そして、彼らが現れるとき、それは自動的に新しい送付者に達します。
Symbolically, we can represent a WF-style reservation request
by:
象徴的に、私たちは以下でWF-スタイル予約の要請を表すことができます。
WF( * {Q})
WF(*Q)
where the asterisk represents wildcard sender selection and Q
represents the flowspec.
アスタリスクがワイルドカードを表すところでは、送付者選択とQはflowspecを表します。
o Fixed-Filter (FF) Style
o 固定フィルタ(ff)様式
The FF style implies the options: "distinct" reservations and
"explicit" sender selection. Thus, an elementary FF-style
reservation request creates a distinct reservation for data
packets from a particular sender, not sharing them with other
senders' packets for the same session.
FFスタイルはオプションを含意します: 「異なった」予約と「明白な」送付者選択。 したがって、基本のFF-スタイル予約の要請は特定の送付者からデータ・パケットの異なった予約を作成します、同じセッションのために他の送付者のパケットとそれらを共有しないで。
Braden, Ed., et. al. Standards Track [Page 12] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[12ページ]。
Symbolically, we can represent an elementary FF reservation
request by:
象徴的に、私たちは以下で基本のFF予約の要請を表すことができます。
FF( S{Q})
ff(S Q)
where S is the selected sender and Q is the corresponding
flowspec; the pair forms a flow descriptor. RSVP allows
multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors:
Sが選択された送付者であり、Qが対応するflowspecであるところ。 組は流れ記述子を形成します。 RSVPは、流れ記述子のリストを使用して、複数の基本のFF-スタイルの予約が同時に要求されるのを許容します:
FF( S1{Q1}, S2{Q2}, ...)
ff(S1Q1、S2Q2)
The total reservation on a link for a given session is the
`sum' of Q1, Q2, ... for all requested senders.
リンクの与えられたセッションの総予約はQ1の'合計'です、Q2、… すべてが送付者を要求したので。
o Shared Explicit (SE) Style
o 共有された明白な(SE)様式
The SE style implies the options: "shared" reservation and
"explicit" sender selection. Thus, an SE-style reservation
creates a single reservation shared by selected upstream
senders. Unlike the WF style, the SE style allows a receiver
to explicitly specify the set of senders to be included.
SEスタイルはオプションを含意します: 「共有された」予約と「明白な」送付者選択。 したがって、SE-スタイルの予約は選択された上流の送付者によって共有されたただ一つの予約を作成します。 WFスタイルと異なって、受信機は、含まれるようにSEスタイルで明らかに送付者のセットを指定できます。
We can represent an SE reservation request containing a
flowspec Q and a list of senders S1, S2, ... by:
私たちは以下でflowspec Qを入れてあるSE予約の要請と送付者S1、S2のリストを表すことができます。
SE( (S1,S2,...){Q} )
SE((S1、S2)Q)
Shared reservations, created by WF and SE styles, are appropriate
for those multicast applications in which multiple data sources
are unlikely to transmit simultaneously. Packetized audio is an
example of an application suitable for shared reservations; since
a limited number of people talk at once, each receiver might issue
a WF or SE reservation request for twice the bandwidth required
for one sender (to allow some over-speaking). On the other hand,
the FF style, which creates distinct reservations for the flows
from different senders, is appropriate for video signals.
複数のデータ送信端末が同時に伝わりそうにないそれらのマルチキャストアプリケーションに、WFとSEスタイルによって作成された共有された予約は適切です。 Packetizedオーディオは共有された予約に適したアプリケーションに関する例です。 限られた数の人々がすぐに話すので、各受信機がWFを発行するかもしれませんか、または帯域幅の2倍のためのSE予約の要請が1人の送付者(いくつかの話し過ぎるのを許す)に必要です。 他方では、ビデオ信号に、FFスタイル(異なった送付者からの流れの異なった予約を作成する)は適切です。
The RSVP rules disallow merging of shared reservations with
distinct reservations, since these modes are fundamentally
incompatible. They also disallow merging explicit sender
selection with wildcard sender selection, since this might produce
an unexpected service for a receiver that specified explicit
selection. As a result of these prohibitions, WF, SE, and FF
styles are all mutually incompatible.
RSVPは、これらのモードが基本的に両立しないので共有された予約を異なった予約に合併するのを禁じるように裁決します。 また、彼らは、明白な送付者選択をワイルドカード送付者選択に合併するのを禁じます、これが明白な選択を指定した受信機のための予期していなかったサービスを起こすかもしれないので。 これらの禁止の結果、WF、SE、およびFFスタイルはすべて互いに両立しないです。
Braden, Ed., et. al. Standards Track [Page 13] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[13ページ]。
It would seem possible to simulate the effect of a WF reservation
using the SE style. When an application asked for WF, the RSVP
process on the receiver host could use local state to create an
equivalent SE reservation that explicitly listed all senders.
However, an SE reservation forces the packet classifier in each
node to explicitly select each sender in the list, while a WF
allows the packet classifier to simply "wild card" the sender
address and port. When there is a large list of senders, a WF
style reservation can therefore result in considerably less
overhead than an equivalent SE style reservation. For this
reason, both SE and WF are included in the protocol.
SEスタイルを使用するWFの予約の効果をシミュレートするのは可能に思えるでしょう。 アプリケーションがWFを求めたとき、受信ホストのRSVPの過程は、明らかにすべての送付者を記載した同等なSEの予約を作成するのに地方の状態を使用するかもしれません。 しかしながら、SEの予約によって、各ノードのパケットクラシファイアは明らかにやむを得ずリストの各送付者を選びます、WFが単に「ワイルドカード」への送付者アドレスとポートをパケットクラシファイアに許容しますが。 したがって、送付者の大きいリストがあるとき、WFスタイルの予約は同等なSEスタイルの予約よりかなり少ないオーバーヘッドをもたらすことができます。 この理由で、SEとWFの両方がプロトコルに含まれています。
Other reservation options and styles may be defined in the future.
他の予約オプションとスタイルは将来、定義されるかもしれません。
1.4 Examples of Styles
1.4 様式に関する例
This section presents examples of each of the reservation styles
and shows the effects of merging.
このセクションはそれぞれの予約スタイルとショーに関する例に合併するという効果を提示します。
Figure 4 illustrates a router with two incoming interfaces,
labeled (a) and (b), through which flows will arrive, and two
outgoing interfaces, labeled (c) and (d), through which data will
be forwarded. This topology will be assumed in the examples that
follow. There are three upstream senders; packets from sender S1
(S2 and S3) arrive through previous hop (a) ((b), respectively).
There are also three downstream receivers; packets bound for R1
(R2 and R3) are routed via outgoing interface (c) ((d),
respectively). We furthermore assume that outgoing interface (d)
is connected to a broadcast LAN, i.e., that replication occurs in
the network; R2 and R3 are reached via different next hop routers
(not shown).
図4は流れが到着する(a)と(b)とラベルされた2つの入って来るインタフェースとデータが転送される(c)と(d)とラベルされた2つの外向的なインタフェースをルータに入れます。 このトポロジーは従う例で想定されるでしょう。 3人の上流の送付者がいます。 送付者S1(S2とS3)からのパケットが前のホップ(a)((b)を通してそれぞれ到着する、) また、3台の川下の受信機があります。 R1(R2とR3)に向かっているパケットが外向的なインタフェース(c)((d)を通してそれぞれ発送される、) その上、私たちは、外向的なインタフェース(d)が放送LANに関連づけられると思います、すなわち、その模写はネットワークで起こります。 次の異なったホップルータ(目立たない)でR2とR3に達しています。
We must also specify the multicast routes within the node of
Figure 4. Assume first that data packets from each Si shown in
Figure 4 are routed to both outgoing interfaces. Under this
assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
Fixed-Filter, and Shared-Explicit reservations, respectively.
また、私たちは図4のノードの中でマルチキャストルートを指定しなければなりません。 最初に、図4で見せられた各Siからのデータ・パケットが両方の外向的なインタフェースに発送されると仮定してください。 この仮定で、図5、6、および7はそれぞれWildcard-フィルタ、Fixed-フィルタ、およびShared明白な予約を例証します。
Braden, Ed., et. al. Standards Track [Page 14] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[14ページ]。
________________
(a)| | (c)
( S1 ) ---------->| |----------> ( R1 )
| Router | |
(b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |------|
|________________| |---> ( R3 )
|
________________ (a)| | (c) (S1) ---------->| |---------->(R1)| ルータ| | (b)| | (d) |--->(R2)(S2、S3)------->| |------| |________________| |--->(R3)|
Figure 4: Router Configuration
図4: ルータ構成
For simplicity, these examples show flowspecs as one-dimensional
multiples of some base resource quantity B. The "Receives" column
shows the RSVP reservation requests received over outgoing
interfaces (c) and (d), and the "Reserves" column shows the
resulting reservation state for each interface. The "Sends"
column shows the reservation requests that are sent upstream to
previous hops (a) and (b). In the "Reserves" column, each box
represents one reserved "pipe" on the outgoing link, with the
corresponding flow descriptor.
簡単さのために、これらの例は、いくつかの倍数が「受信」コラムが結果として起こる予約状態を各インタフェースに見せるのを外向的なインタフェース(c)と(d)、および「蓄え」コラムの上受け取られたRSVP予約の要請に示すリソース量B.を基礎づけるのを一次元としてのflowspecsに示します。 「送付」コラムは上流へ前のホップ(a)と(b)に送られる予約の要請を示しています。 「蓄え」コラムでは、各箱は対応する流れ記述子との出発しているリンクの上に1予約された「パイプ」を表します。
Figure 5, showing the WF style, illustrates two distinct
situations in which merging is required. (1) Each of the two next
hops on interface (d) results in a separate RSVP reservation
request, as shown; these two requests must be merged into the
effective flowspec, 3B, that is used to make the reservation on
interface (d). (2) The reservations on the interfaces (c) and (d)
must be merged in order to forward the reservation requests
upstream; as a result, the larger flowspec 4B is forwarded
upstream to each previous hop.
WFスタイルを示して、図5は合併が必要である2つの異なった状況を例証します。 (1) インタフェース(d)のそれぞれの次の2つのホップが示されるように別々のRSVP予約の要請をもたらします。 有効なflowspec、インタフェース(d)の予約をするのに使用される3Bにこれらの2つの要求を合併しなければなりません。 (2) 予約の要請上流を進めるためにインタフェース(c)と(d)の予約を合併しなければなりません。 その結果、上流へ前の各ホップにより大きいflowspec 4Bを送ります。
Braden, Ed., et. al. Standards Track [Page 15] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[15ページ]。
|
Sends | Reserves Receives
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| <- WF( *{2B} )
|、発信| 蓄えは受信されます。| | _______ WF(*4B)<(a)| (c) | * 4B| (c) <。 WF(*4B)| |_______| | -----------------------|---------------------------------------- | _______ WF(*4B)<(b)| (d) | * 3B| (d) <。 WF(*3B)| |_______| <。 WF(*2B)
Figure 5: Wildcard-Filter (WF) Reservation Example
図5: ワイルドカードフィルタ(WF)予約の例
Figure 6 shows Fixed-Filter (FF) style reservations. For each
outgoing interface, there is a separate reservation for each
source that has been requested, but this reservation will be
shared among all the receivers that made the request. The flow
descriptors for senders S2 and S3, received through outgoing
interfaces (c) and (d), are packed (not merged) into the request
forwarded to previous hop (b). On the other hand, the three
different flow descriptors specifying sender S1 are merged into
the single request FF( S1{4B} ) that is sent to previous hop (a).
図6はFixed-フィルタ(FF)スタイルの予約を示しています。 それぞれの外向的なインタフェースには、要求されているそれぞれのソースの別々の予約がありますが、この予約は要求をしたすべての受信機の中で共有されるでしょう。 外向的なインタフェース(c)と(d)を通して受け取られた送付者のS2とS3への流れ記述子は前のホップ(b)に転送された要求に梱包されます(合併されていません)。 他方では、送付者S1を指定する3つの異なった流れ記述子が前のホップ(a)に送られる独身の要求FF(S1 4B)に合併されています。
|
Sends | Reserves Receives
|
| ________
FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} )
| | S3{B} |
| |________|
|、発信| 蓄えは受信されます。| | ________ ff(S1 4B)<(a)| (c) | S1 4B| (c) <。 ff(S1 4B、S2 5B)| |________| | | S2 5B| | |________| ---------------------|--------------------------------------------- | ________ <。 (b) | (d) | S1 3B| (d) <。 ff(S1 3B、S3B)ff(S2 5B、S3B)| |________| <。 ff(S1B)| | S3B| | |________|
Figure 6: Fixed-Filter (FF) Reservation Example
図6: 固定フィルタ(ff)予約の例
Braden, Ed., et. al. Standards Track [Page 16] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[16ページ]。
Figure 7 shows an example of Shared-Explicit (SE) style
reservations. When SE-style reservations are merged, the
resulting filter spec is the union of the original filter specs,
and the resulting flowspec is the largest flowspec.
図7はShared明白な(SE)スタイルの予約に関する例を示しています。 SE-スタイルの予約が合併されているとき、結果として起こるフィルタ仕様はオリジナルのフィルタ仕様の組合です、そして、結果として起こるflowspecは最も大きいflowspecです。
|
Sends | Reserves Receives
|
| ________
SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} |
| |________|
---------------------|---------------------------------------------
| __________
<- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} )
| |__________|
|、発信| 蓄えは受信されます。| | ________ SE(S1 3B)<(a)| (c) |(S1、S2) | (c) <。 SE((S1、S2)B)| | B| | |________| ---------------------|--------------------------------------------- | __________ <。 (b) | (d) |(S1、S2、S3)| (d) <。 SE(S1、S3)3B) SE((S2、S3)3B)| | 3B| <。 SE(S2 2B)| |__________|
Figure 7: Shared-Explicit (SE) Reservation Example
図7: 共有されて明白な(SE)予約の例
The three examples just shown assume that data packets from S1,
S2, and S3 are routed to both outgoing interfaces. The top part
of Figure 8 shows another routing assumption: data packets from S2
and S3 are not forwarded to interface (c), e.g., because the
network topology provides a shorter path for these senders towards
R1, not traversing this node. The bottom part of Figure 8 shows
WF style reservations under this assumption. Since there is no
route from (b) to (c), the reservation forwarded out interface (b)
considers only the reservation on interface (d).
ただ示された3つの例が、S1、S2、およびS3からのデータ・パケットが両方の外向的なインタフェースに発送されると仮定します。 図8の最高部分は別のルーティング仮定を示しています: S2とS3からのデータ・パケットは(c)を連結するように進められません、例えば、ネットワーク形態がR1に向かったこれらの送付者により短い経路を提供するので、このノードを横断しないで。 図8の下部の部分はスタイルの予約をWFにこの仮定で示しています。 以来、(b)から(c)(進められた出かけているインタフェース(b)がインタフェース(d)の予約だけであると考える予約)までルートが全くありません。
Braden, Ed., et. al. Standards Track [Page 17] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[17ページ]。
_______________
(a)| | (c)
( S1 ) ---------->| >-----------> |----------> ( R1 )
| > |
| > |
(b)| > | (d)
( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
|_______________|
_______________ (a)| | (c) (S1) ---------->| >、-、-、-、-、-、-、-、-、-、-->|---------->(R1)| >|| >| (b)| >| (d)(S2、S3)------->| >、-、-、-、-、-、-、-->-->|---------->(R2、R3)|_______________|
Router Configuration
ルータ構成
|
Sends | Reserves Receives
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| <- WF( * {2B} )
|、発信| 蓄えは受信されます。| | _______ WF(*4B)<(a)| (c) | * 4B| (c) <。 WF(*4B)| |_______| | -----------------------|---------------------------------------- | _______ WF(*3B)<(b)| (d) | * 3B| (d) <。 WF(*3B)| |_______| <。 WF(*2B)
Figure 8: WF Reservation Example -- Partial Routing
エイト環: WF予約の例--部分的なルート設定
Braden, Ed., et. al. Standards Track [Page 18] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[18ページ]。
2. RSVP Protocol Mechanisms
2. RSVPプロトコルメカニズム
2.1 RSVP Messages
2.1 RSVPメッセージ
Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops
前の次の入って来る外向的なホップスインタフェースインタフェースホップス
_____ _____________________ _____
| | data --> | | data --> | |
| A |-----------| a c |--------------| C |
|_____| Path --> | | Path --> |_____|
<-- Resv | | <-- Resv _____
_____ | ROUTER | | | |
| | | | | |--| D |
| B |--| data-->| | data --> | |_____|
|_____| |--------| b d |-----------|
| Path-->| | Path --> | _____
_____ | <--Resv|_____________________| <-- Resv | | |
| | | |--| D' |
| B' |--| | |_____|
|_____| | |
_____ _____________________ _____ | | データ-->。| | データ-->。| | | A|-----------| c|--------------| C| |_____| 経路-->。| | 経路-->。|_____| <-- Resv| | <-- Resv_____ _____ | ルータ| | | | | | | | | |--| D| | B|--| データ-->|、| データ-->。| |_____| |_____| |--------| b d|-----------| | 経路-->|、| 経路-->。| _____ _____ | <--Resv|_____________________| <-- Resv| | | | | | |--| 'D'| | 'B'|--| | |_____| |_____| | |
Figure 9: Router Using RSVP
図9: RSVPを使用するルータ
Figure 9 illustrates RSVP's model of a router node. Each data
flow arrives from a "previous hop" through a corresponding
"incoming interface" and departs through one or more "outgoing
interface"(s). The same interface may act in both the incoming
and outgoing roles for different data flows in the same session.
Multiple previous hops and/or next hops may be reached through a
given physical interface; for example, the figure implies that D
and D' are connected to (d) with a broadcast LAN.
図9はRSVPのルータノードのモデルを例証します。 各データフローは、「前のホップ」から対応する「入って来るインタフェース」まで到着して、1「外向的なインタフェース」(s)を通って出発します。 同じインタフェースは同じセッションのときに異なったデータフローのために両方の送受信の役割で行動するかもしれません。 前の複数のホップ、そして/または、次のホップに与えられた物理インターフェースを通して達するかもしれません。 '例えば、図は、DとD'が放送LANで(d)に接続されると暗示します。
There are two fundamental RSVP message types: Resv and Path.
2つの基本的なRSVPメッセージタイプがあります: Resvと経路。
Each receiver host sends RSVP reservation request (Resv) messages
upstream towards the senders. These messages must follow exactly
the reverse of the path(s) the data packets will use, upstream to
all the sender hosts included in the sender selection. They
create and maintain "reservation state" in each node along the
path(s). Resv messages must finally be delivered to the sender
hosts themselves, so that the hosts can set up appropriate traffic
control parameters for the first hop. The processing of Resv
messages was discussed previously in Section 1.2.
各受信ホストは送付者に向かったRSVP予約の要請(Resv)メッセージ上流を送ります。 これらのメッセージはちょうどデータ・パケットが使用する経路の逆に続かなければなりません、送付者選択にすべての送付者ホストを含んでいるのに、上流です。 彼らは、経路に沿った各ノードで「予約状態」を作成して、維持します。 最終的に自分たちでResvメッセージを送付者ホストに送らなければなりません、ホストが最初のホップのための適切なトラフィックコントロールパラメタをセットアップできるように。 以前に、セクション1.2でResvメッセージの処理について議論しました。
Braden, Ed., et. al. Standards Track [Page 19] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[19ページ]。
Each RSVP sender host transmits RSVP "Path" messages downstream
along the uni-/multicast routes provided by the routing
protocol(s), following the paths of the data. These Path messages
store "path state" in each node along the way. This path state
includes at least the unicast IP address of the previous hop node,
which is used to route the Resv messages hop-by-hop in the reverse
direction. (In the future, some routing protocols may supply
reverse path forwarding information directly, replacing the
reverse-routing function of path state).
それぞれのRSVP送付者ホストはルーティング・プロトコルによって提供されたuni/マルチキャストルートに沿ってRSVP「経路」メッセージを川下に送ります、データの経路に続いて。 これらのPathメッセージは道に沿って各ノードに「経路州」を格納します。 この経路州は少なくとも前のホップノードのユニキャストIPアドレスを含めます。(ノードは、反対の方向へのホップごとのResvメッセージを発送するのに使用されます)。 (経路州の逆経路選択機能を取り替えて、将来、いくつかのルーティング・プロトコルが直接逆の経路推進情報を提供するかもしれません。)
A Path message contains the following information in addition to
the previous hop address:
Pathメッセージは前のホップアドレスに加えた以下の情報を含んでいます:
o Sender Template
o 送付者テンプレート
A Path message is required to carry a Sender Template, which
describes the format of data packets that the sender will
originate. This template is in the form of a filter spec
that could be used to select this sender's packets from
others in the same session on the same link.
Pathメッセージが、Sender Templateを運ぶのに必要です。(Sender Templateは送付者が溯源するデータ・パケットの形式について説明します)。 このテンプレートは同じリンクの同じセッションのときに他のものからこの送付者のパケットを選択するのに使用できたフィルタ仕様の形にあります。
Sender Templates have exactly the same expressive power and
format as filter specs that appear in Resv messages.
Therefore a Sender Template may specify only the sender IP
address and optionally the UDP/TCP sender port, and it
assumes the protocol Id specified for the session.
送付者Templatesには、Resvメッセージに現れるフィルタ仕様としてまさに同じ表現力と形式があります。 したがって、Sender Templateは送付者IPだけのために任意にアドレスを指定するかもしれません。そして、UDP/TCP送付者が移植する、それは、プロトコルがセッションとして指定されたIdであると仮定します。
o Sender Tspec
o 送付者Tspec
A Path message is required to carry a Sender Tspec, which
defines the traffic characteristics of the data flow that the
sender will generate. This Tspec is used by traffic control
to prevent over-reservation, and perhaps unnecessary
Admission Control failures.
Pathメッセージが、Sender Tspecを運ぶのに必要です。(Sender Tspecは送付者が発生させるデータフローの交通の特性を定義します)。 このTspecは、過剰の予約、および恐らく不要なAdmission Controlの故障を防ぐのにトラフィックコントロールで使用されます。
o Adspec
o Adspec
A Path message may carry a package of OPWA advertising
information, known as an "Adspec". An Adspec received in a
Path message is passed to the local traffic control, which
returns an updated Adspec; the updated version is then
forwarded in Path messages sent downstream.
Pathメッセージは"Adspec"として知られているOPWA広告情報のパッケージを運ぶかもしれません。 Pathメッセージに受け取られたAdspecはローカルのトラフィックコントロールに渡されます。(それは、アップデートされたAdspecを返します)。 そして、川下に送られたPathメッセージでアップデートされたバージョンを進めます。
Braden, Ed., et. al. Standards Track [Page 20] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[20ページ]。
Path messages are sent with the same source and destination
addresses as the data, so that they will be routed correctly
through non-RSVP clouds (see Section 2.9). On the other hand,
Resv messages are sent hop-by-hop; each RSVP-speaking node
forwards a Resv message to the unicast address of a previous RSVP
hop.
同じソースと送付先アドレスと共にデータとして経路メッセージを送ります、それらが非RSVP雲を通して正しく発送される(セクション2.9を見る)ように。 他方では、ホップごとにResvメッセージを送ります。 それぞれのRSVP-話しノードは前のRSVPホップのユニキャストアドレスにResvメッセージを転送します。
2.2 Merging Flowspecs
2.2 Flowspecsを合併すること。
A Resv message forwarded to a previous hop carries a flowspec that
is the "largest" of the flowspecs requested by the next hops to
which the data flow will be sent (however, see Section 3.5 for a
different merging rule used in certain cases). We say the
flowspecs have been "merged". The examples shown in Section 1.4
illustrated another case of merging, when there are multiple
reservation requests from different next hops for the same session
and with the same filter spec, but RSVP should install only one
reservation on that interface. Here again, the installed
reservation should have an effective flowspec that is the
"largest" of the flowspecs requested by the different next hops.
前のホップに転送されたResvメッセージはデータフローが送られる次のホップによって要求されたflowspecsで中で「もの最も大きい」であるflowspecを運びます(しかしながら、ある場合には、異なった合併している規則のためのセクション3.5が使用されるのを見てください)。 私たちは、flowspecsが「合併された」と言います。 セクション1.4に示された例は同じセッションと同じフィルタ仕様がある次の異なったホップからの複数の予約の要請がありますが、RSVPがそのインタフェースの1つの予約だけをインストールするはずであるとき合併する別のケースを例証しました。 ここに、一方、インストールされた予約は次の異なったホップによって要求されたflowspecsで中で「もの最も大きい」である有効なflowspecを持つべきです。
Since flowspecs are opaque to RSVP, the actual rules for comparing
flowspecs must be defined and implemented outside RSVP proper.
The comparison rules are defined in the appropriate integrated
service specification document. An RSVP implementation will need
to call service-specific routines to perform flowspec merging.
flowspecsがRSVPに不透明であるので、RSVP本土の外でflowspecsを比較するための実際の規則を定義されて、実行しなければなりません。 比較規則は適切な統合サービス仕様ドキュメントで定義されます。 RSVP実現は、flowspec合併を実行するためにサービス特有のルーチンと呼ぶ必要があるでしょう。
Note that flowspecs are generally multi-dimensional vectors; they
may contain both Tspec and Rspec components, each of which may
itself be multi-dimensional. Therefore, it may not be possible to
strictly order two flowspecs. For example, if one request calls
for a higher bandwidth and another calls for a tighter delay
bound, one is not "larger" than the other. In such a case,
instead of taking the larger, the service-specific merging
routines must be able to return a third flowspec that is at least
as large as each; mathematically, this is the "least upper bound"
(LUB). In some cases, a flowspec at least as small is needed;
this is the "greatest lower bound" (GLB) GLB (Greatest Lower
Bound).
flowspecsが一般に多次元のベクトルであることに注意してください。 どれについてそれぞれTspecとRspecの部品の両方を含むかもしれないか、それ自体、多次元であるかもしれなくなってください。 したがって、厳密に2flowspecsを注文するのは可能でないかもしれません。 例えば、1つの要求が、より高い帯域幅を求めて、別のものが、よりきつい遅れバウンドを求めるなら、1つは「もう片方ほど大きくはありません」。 このような場合には、より大きいのを取ることの代わりに、サービス特有の合併しているルーチンはそれぞれと少なくとも同じくらい大きい3番目のflowspecを返すことができなければなりません。 これは数学的に、「上限」(LUB)です。 いくつかの場合、少なくとも小さいとしてのflowspecが必要です。 これは「最も大きい下界」(GLB)GLB(最もすばらしいLower Bound)です。
The following steps are used to calculate the effective flowspec
(Re, Te) to be installed on an interface [RFC 2210]. Here Te is
the effective Tspec and Re is the effective Rspec.
以下のステップは、インタフェース[RFC2210]にインストールされるために、有効なflowspec(re、Te)について計算するのに使用されます。 ここで、Teは有効なTspecです、そして、Reは有効なRspecです。
Braden, Ed., et. al. Standards Track [Page 21] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[21ページ]。
1. An effective flowspec is determined for the outgoing
interface. Depending upon the link-layer technology, this
may require merging flowspecs from different next hops; this
means computing the effective flowspec as the LUB of the
flowspecs. Note that what flowspecs to merge is determined
by the link layer medium (see Section 3.11.2), while how to
merge them is determined by the service model in use [RFC
2210].
1. 有効なflowspecは外向的なインタフェースに決定します。 リンクレイヤ技術によって、これは、次の異なったホップからflowspecsを合併するのを必要とするかもしれません。 これは、flowspecsのLUBとして有効なflowspecを計算することを意味します。 どんなflowspecsを合併したらよいかがリンクレイヤ媒体によって決定されることに注意してください(セクション3.11.2を見てください)、どうそれらを合併するかはサービスモデルによって使用中[RFC2210]に決定されますが。
The result is a flowspec that is opaque to RSVP but actually
consists of the pair (Re, Resv_Te), where is Re is the
effective Rspec and Resv_Te is the effective Tspec.
どこによるReが有効なRspecであるということであるか、そして、結果はRSVPに不透明ですが、実際に組から成るflowspec(re、Resv_Te)です、そして、Resv_Teは有効なTspecです。
2. A service-specific calculation of Path_Te, the sum of all
Tspecs that were supplied in Path messages from different
previous hops (e.g., some or all of A, B, and B' in Figure
9), is performed.
2. 'Path_Teのサービス特有の計算(Pathメッセージで前の異なったホップ(図9のA、B、およびB'の例えば、いくつかかすべて)から供給されたすべてのTspecsの合計)は実行されます。
3. (Re, Resv_Te) and Path_Te are passed to traffic control.
Traffic control will compute the effective flowspec as the
"minimum" of Path_Te and Resv_Te, in a service-dependent
manner.
3. (re、Resv_Te) そして、Path_Teはトラフィックコントロールに渡されます。 トラフィックコントロールはPath_TeとResv_Teの「最小限」としてサービス依存する方法で有効なflowspecを計算するでしょう。
Section 3.11.6 defines a generic set of service-specific calls to
compare flowspecs, to compute the LUB and GLB of flowspecs, and to
compare and sum Tspecs.
セクション3.11 .6 flowspecsを比較して、flowspecsのLUBとGLBを計算して、比較するというサービス特有の要求と合計Tspecsの一般的なセットを定義します。
2.3 Soft State
2.3 軟性国家
RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and
periodically refreshed by Path and Resv messages. The state is
deleted if no matching refresh messages arrive before the
expiration of a "cleanup timeout" interval. State may also be
deleted by an explicit "teardown" message, described in the next
section. At the expiration of each "refresh timeout" period and
after a state change, RSVP scans its state to build and forward
Path and Resv refresh messages to succeeding hops.
RSVPはルータとホストで予約状態を経営することへの「軟性国家」アプローチを取ります。 RSVP軟性国家は、作成されていて、定期的にPathとResvメッセージによってリフレッシュされます。 状態はマッチでないのがリフレッシュするなら削除されて、メッセージが「クリーンアップタイムアウト」間隔の満了の前に到着するということです。 また、状態は次のセクションで説明された明白な「分解」メッセージによって削除されるかもしれません。 それぞれの満了のときに、州の変化の後に「タイムアウトをリフレッシュしてください」のRSVPスキャンの期間、造る状態、前進のPath、およびResvは続くホップにメッセージをリフレッシュします。
Path and Resv messages are idempotent. When a route changes, the
next Path message will initialize the path state on the new route,
and future Resv messages will establish reservation state there;
the state on the now-unused segment of the route will time out.
Thus, whether a message is "new" or a "refresh" is determined
separately at each node, depending upon the existence of state at
that node.
経路とResvメッセージはベキ等元です。 ルートが変化するとき、次のPathメッセージは新しいルートの上の経路州を初期化するでしょう、そして、将来のResvメッセージはそこで予約状態を設置するでしょう。 ルートの現在未使用のセグメントの状態はタイムアウトがそうするでしょう。 したがって、メッセージが「新しいか」、そして、「リフレッシュ」が別々に各ノードで断固としています、そのノードで状態の存在によって。
Braden, Ed., et. al. Standards Track [Page 22] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[22ページ]。
RSVP sends its messages as IP datagrams with no reliability
enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to handle the occasional loss of an RSVP
message. If the effective cleanup timeout is set to K times the
refresh timeout period, then RSVP can tolerate K-1 successive RSVP
packet losses without falsely deleting state. The network traffic
control mechanism should be statically configured to grant some
minimal bandwidth for RSVP messages to protect them from
congestion losses.
RSVPはIPデータグラムとして信頼性の増進なしでメッセージを送ります。 周期的なトランスミッション、ホストでメッセージをリフレッシュしてください。そうすれば、ルータがRSVPメッセージの時々の損失を扱うと予想されます。 有効なクリーンアップタイムアウトがK回に設定される、タイムアウト時間をリフレッシュしてください、と当時のRSVPは間違って状態を削除しながら、K-1の連続したRSVPパケット損失を黙認できます。 ネットワークトラフィック制御機構は、混雑の損失からそれらを保護するRSVPメッセージのためにいくらかの最小量の帯域幅を与えるために静的に構成されるべきです。
The state maintained by RSVP is dynamic; to change the set of
senders Si or to change any QoS request, a host simply starts
sending revised Path and/or Resv messages. The result will be an
appropriate adjustment in the RSVP state in all nodes along the
path; unused state will time out if it is not explicitly torn
down.
RSVPによって維持された状態はダイナミックです。 送付者Siのセットを変えるか、またはどんなQoS要求も変えるために、ホストは単に改訂されたPath、そして/または、Resvにメッセージを送り始めます。 結果は経路に沿ったすべてのノードのRSVP状態で適当な調整になるでしょう。 それが明らかに取りこわされないなら、未使用の州はタイムアウトを望んでいます。
In steady state, state is refreshed hop-by-hop to allow merging.
When the received state differs from the stored state, the stored
state is updated. If this update results in modification of state
to be forwarded in refresh messages, these refresh messages must
be generated and forwarded immediately, so that state changes can
be propagated end-to-end without delay. However, propagation of a
change stops when and if it reaches a point where merging causes
no resulting state change. This minimizes RSVP control traffic
due to changes and is essential for scaling to large multicast
groups.
定常状態では、ホップごとに状態は、合併するのを許容するためにリフレッシュされます。 容認された状態が格納された状態と異なっているとき、格納された状態をアップデートします。 このアップデートが進めて、メッセージが中でリフレッシュするということになるように状態の変更に結果として生じるなら、これらは発生しなければならなくて、すぐに転送されたメッセージをリフレッシュします、州の変化が即刻終わりから伝播された終わりになるように。 しかしながら、変化の伝播はいつを止めるか、そして、達するなら、ポイントは合併するところで結果として起こる州の変化を全く引き起こしません。 これは、変化のためRSVPコントロール交通を最小にして、大きいマルチキャストグループに比例するのに、不可欠です。
State that is received through a particular interface I* should
never be forwarded out the same interface. Conversely, state that
is forwarded out interface I* must be computed using only state
that arrived on interfaces different from I*. A trivial example
of this rule is illustrated in Figure 10, which shows a transit
router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and
(c) serve as both outgoing and incoming interfaces for this
session. Both receivers are making wildcard-style reservations,
in which the Resv messages are forwarded to all previous hops for
senders in the group, with the exception of the next hop from
which they came. The result is independent reservations in the
two directions.
特定のインタフェースI*を通して受け取られる状態に同じ出かけているインタフェースを決して送るべきではありません。 逆に、I*と異なったインタフェースで到着した状態だけを使用することで出かけているインタフェースI*が送られる状態を計算しなければなりません。この規則の些細な例は図10で例証されます。(それは、各インタフェース(そして、次か前の1インタフェースあたり1つのホップを仮定する)に、ある送付者とある受信機でトランジットルータを示しています)。 インタフェース(a)と(c)はこのセッションのために両方の送受信のインタフェースとして機能します。 両方の受信機はワイルドカードスタイルを予約にしています、彼らが来た次のホップを除いて。(そこでは、Resvメッセージがグループの送付者のために前のすべてのホップに転送されます)。 結果は2つの方向への独立している予約です。
There is an additional rule governing the forwarding of Resv
messages: state from Resv messages received from outgoing
interface Io should be forwarded to incoming interface Ii only if
Path messages from Ii are forwarded to Io.
Resvメッセージの推進を治める付則があります: IiからのPathメッセージをイーオーに転送する場合にだけ、外向的なインタフェースイーオーから受け取られたResvメッセージからの状態を入って来るインタフェースIiに送るべきです。
Braden, Ed., et. al. Standards Track [Page 23] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[23ページ]。
________________
a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|
________________ a| | c(R1、S1)<。----->| ルータ| <、-、-、-、-->(R2、S2)|________________|
Send | Receive
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive | Send
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
発信してください。| 受信してください。| WF(*3B)<--(a)| (c) <-- WF(*3B)| 受信してください。| 発信してください。| WF(*4B)-->(a)| (c) -->WF(*4B)| (a)における蓄え| (c)における蓄え__________ | __________ | * 4B| | | * 3B| |__________| | |__________| |
Figure 10: Independent Reservations
図10: 独立している予約
2.4 Teardown
2.4 分解
RSVP "teardown" messages remove path or reservation state
immediately. Although it is not necessary to explicitly tear down
an old reservation, we recommend that all end hosts send a
teardown request as soon as an application finishes.
RSVP「分解」メッセージはすぐに、経路か予約状態を取り除きます。 明らかに古い予約を取りこわすのは必要ではありませんが、私たちは、アプリケーションが完成するとすぐに、すべての終わりのホストが分解要求を送ることを勧めます。
There are two types of RSVP teardown message, PathTear and
ResvTear. A PathTear message travels towards all receivers
downstream from its point of initiation and deletes path state, as
well as all dependent reservation state, along the way. An
ResvTear message deletes reservation state and travels towards all
senders upstream from its point of initiation. A PathTear
(ResvTear) message may be conceptualized as a reversed-sense Path
message (Resv message, respectively).
2つのタイプに関するRSVP分解メッセージ、PathTear、およびResvTearがあります。 PathTearメッセージは、川下を開始のポイントからすべての受信機に向かって旅行して、経路州を削除します、すべての依存する予約状態と同様に、道に沿って。 ResvTearメッセージは、開始のポイントから予約状態を削除して、すべての送付者上流に向かって移動します。 PathTear(ResvTear)メッセージは逆にされた感覚Pathメッセージ(それぞれResvメッセージ)として概念化されるかもしれません。
A teardown request may be initiated either by an application in an
end system (sender or receiver), or by a router as the result of
state timeout or service preemption. Once initiated, a teardown
request must be forwarded hop-by-hop without delay. A teardown
message deletes the specified state in the node where it is
received. As always, this state change will be propagated
immediately to the next node, but only if there will be a net
change after merging. As a result, a ResvTear message will prune
the reservation state back (only) as far as possible.
分解要求はエンドシステム(送付者か受信機)におけるアプリケーション、または州のタイムアウトかサービス先取りの結果としてのルータによって開始されるかもしれません。 いったん開始すると、ホップごとに即刻分解要求を転送しなければなりません。 分解メッセージはそれが受け取られているノードで指定された状態を削除します。 いつものように、純変化が合併した後にある場合にだけ、この州の変化はすぐ次のノードに伝播されるでしょう。 その結果、ResvTearメッセージは逆(単に)で予約状態をできるだけ剪定するでしょう。
Braden, Ed., et. al. Standards Track [Page 24] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[24ページ]。
Like all other RSVP messages, teardown requests are not delivered
reliably. The loss of a teardown request message will not cause a
protocol failure because the unused state will eventually time out
even though it is not explicitly deleted. If a teardown message
is lost, the router that failed to receive that message will time
out its state and initiate a new teardown message beyond the loss
point. Assuming that RSVP message loss probability is small, the
longest time to delete state will seldom exceed one refresh
timeout period.
他のすべてのRSVPメッセージのように、分解要求は確かに提供されません。 分解要求メッセージの損失は、結局、それがタイムアウトですが、未使用の状態が明らかに削除されていなく引き起こすので、プロトコル失敗を引き起こさないでしょう。 分解メッセージが無くなるなら、そのメッセージを受け取らなかったルータは、損失ポイントを超えてタイムアウトに状態を望んでいて、新しい分解メッセージを開始します。 RSVPメッセージ呼損率がわずかであると仮定して、状態を削除するのがめったに1つを超えない最も長い時代にタイムアウト時間をリフレッシュしてください。
It should be possible to tear down any subset of the established
state. For path state, the granularity for teardown is a single
sender. For reservation state, the granularity is an individual
filter spec. For example, refer to Figure 7. Receiver R1 could
send a ResvTear message for sender S2 only (or for any subset of
the filter spec list), leaving S1 in place.
設立された状態のどんな部分集合も取りこわすのは可能であるべきです。 経路州において、分解のための粒状は独身の送付者です。 予約状態において、粒状は個々のフィルタ仕様です。 例えば、図7を参照してください。 受信機R1は送付者S2だけのためにResvTearメッセージを送ることができました、適所にS1を残して。
A ResvTear message specifies the style and filters; any flowspec
is ignored. Whatever flowspec is in place will be removed if all
its filter specs are torn down.
ResvTearメッセージはスタイルとフィルタを指定します。 どんなflowspecも無視されます。 すべてのフィルタ仕様を取りこわすと、適所にあるどんなflowspecも取り外すでしょう。
2.5 Errors
2.5 誤り
There are two RSVP error messages, ResvErr and PathErr. PathErr
messages are very simple; they are simply sent upstream to the
sender that created the error, and they do not change path state
in the nodes though which they pass. There are only a few
possible causes of path errors.
2つのRSVPエラーメッセージ、ResvErr、およびPathErrがあります。 PathErrメッセージは非常に簡単です。 単に上流へ誤りを作成した送付者にそれらを送ります、そして、彼らはもっとも経路がノードに述べるそれらが通過するどんな変化もしません。 経路誤りのほんのいくつかの考えられる原因があります。
However, there are a number of ways for a syntactically valid
reservation request to fail at some node along the path. A node
may also decide to preempt an established reservation. The
handling of ResvErr messages is somewhat complex (Section 3.5).
Since a request that fails may be the result of merging a number
of requests, a reservation error must be reported to all of the
responsible receivers. In addition, merging heterogeneous
requests creates a potential difficulty known as the "killer
reservation" problem, in which one request could deny service to
another. There are actually two killer-reservation problems.
しかしながら、経路に沿ってシンタクス上有効な予約の要請が何らかのノードで失敗する多くの方法があります。 また、ノードは、確立した予約を先取りすると決めるかもしれません。 ResvErrメッセージの取り扱いはいくらか複雑です(セクション3.5)。 失敗する要求が多くの要求を合併するという結果であるかもしれないので、原因となる受信機のすべてに予約誤りを報告しなければなりません。 さらに、異種の要求を合併すると、「殺人者の予約」問題として知られている潜在的困難は作成されます。そこでは、要求が別のものに対するサービスを否定する場合がありました。 実際に、2つの殺人者予約問題があります。
1. The first killer reservation problem (KR-I) arises when there
is already a reservation Q0 in place. If another receiver
now makes a larger reservation Q1 > Q0, the result of merging
Q0 and Q1 may be rejected by admission control in some
upstream node. This must not deny service to Q0.
1. 予約Q0が適所に既にあるとき、最初の殺人者予約問題(KR-I)は起こります。 別の受信機が今Q1>Q0の、より大きい予約をするなら、Q0とQ1を合併するという結果は何らかの上流のノードにおける入場コントロールで拒絶されるかもしれません。 これはQ0に対するサービスを否定してはいけません。
Braden, Ed., et. al. Standards Track [Page 25] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[25ページ]。
The solution to this problem is simple: when admission
control fails for a reservation request, any existing
reservation is left in place.
この問題の解決は簡単です: 入場コントロールが予約の要請のために失敗すると、どんな既存の予約も適所から外されます。
2. The second killer reservation problem (KR-II) is the
converse: the receiver making a reservation Q1 is persistent
even though Admission Control is failing for Q1 in some node.
This must not prevent a different receiver from now
establishing a smaller reservation Q0 that would succeed if
not merged with Q1.
2. 2番目の殺人者予約問題(KR-II)は逆です: Admission ControlはQ1のために何らかのノードで失敗していますが、Q1の予約をする受信機はしつこいです。 これは、異なった受信機が現在そうでなければ成功するQ0がQ1と合併したというより小さい条件を確立するのを防いではいけません。
To solve this problem, a ResvErr message establishes
additional state, called "blockade state", in each node
through which it passes. Blockade state in a node modifies
the merging procedure to omit the offending flowspec (Q1 in
the example) from the merge, allowing a smaller request to be
forwarded and established. The Q1 reservation state is said
to be "blockaded". Detailed rules are presented in Section
3.5.
この問題を解決するために、ResvErrメッセージは「封鎖州」と呼ばれる追加状態をそれが通る各ノードに設置します。 ノードの封鎖州はマージから怒っているflowspec(例のQ1)を省略するように合併している手順を変更します、進められて、設立されるというより小さい要求を許して。 Q1予約状態は「封鎖される」と言われています。 細則はセクション3.5に提示されます。
A reservation request that fails Admission Control creates
blockade state but is left in place in nodes downstream of the
failure point. It has been suggested that these reservations
downstream from the failure represent "wasted" reservations and
should be timed out if not actively deleted. However, the
downstream reservations are left in place, for the following
reasons:
Admission Controlに失敗する予約の要請は、失敗ポイントのノード川下で封鎖州を創設しますが、適所から外されます。 活発に削除されないなら、失敗からのこれらの予約川下が「無駄な」予約を表して、調節されるべきであると示唆されました。 しかしながら、川下の予約は適所から以下の理由に外されます:
o There are two possible reasons for a receiver persisting in a
failed reservation: (1) it is polling for resource
availability along the entire path, or (2) it wants to obtain
the desired QoS along as much of the path as possible.
Certainly in the second case, and perhaps in the first case,
the receiver will want to hold onto the reservations it has
made downstream from the failure.
o 失敗した予約に固執する受信機の2つの可能な理由があります: (1) (2) それは全体の経路に沿ったリソースの有用性のための世論調査であるかそれができるだけ多くの経路に沿って必要なQoSを入手したがっています。 確かに、2番目の場合、および恐らく最初の場合では、受信機はそれが川下で失敗からした予約を頼りにしたくなるでしょう。
o If these downstream reservations were not retained, the
responsiveness of RSVP to certain transient failures would be
impaired. For example, suppose a route "flaps" to an
alternate route that is congested, so an existing reservation
suddenly fails, then quickly recovers to the original route.
The blockade state in each downstream router must not remove
the state or prevent its immediate refresh.
o これらの川下の予約が保有されないなら、ある一時障害へのRSVPの反応性は損なわれるでしょうに。 例えば、既存の予約が突然失敗して、次に、すぐに元のルートに回復するようにルートが混雑している代替経路まで「ばたつく」と仮定してください。 それは即座です。それぞれの川下のルータにおける封鎖州が状態を取り除いてはいけない、防止、リフレッシュしてください。
o If we did not refresh the downstream reservations, they might
time out, to be restored every Tb seconds (where Tb is the
blockade state timeout interval). Such intermittent behavior
might be very distressing for users.
o 回復してください。私たちが川下の予約をリフレッシュしないで、それらが力のタイムアウトである、あらゆるTbが後援します(Tbが封鎖州のタイムアウト間隔であるところ)。 ユーザには、そのような間欠振舞いは非常に痛ましいかもしれません。
Braden, Ed., et. al. Standards Track [Page 26] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[26ページ]。
2.6 Confirmation
2.6 確認
To request a confirmation for its reservation request, a receiver
Rj includes in the Resv message a confirmation-request object
containing Rj's IP address. At each merge point, only the largest
flowspec and any accompanying confirmation-request object is
forwarded upstream. If the reservation request from Rj is equal
to or smaller than the reservation in place on a node, its Resv is
not forwarded further, and if the Resv included a confirmation-
request object, a ResvConf message is sent back to Rj. If the
confirmation request is forwarded, it is forwarded immediately,
and no more than once for each request.
予約の要請、受信機のための確認を要求するために、RjはResvメッセージにRjのIPアドレスを含む確認要求物を含んでいます。 それぞれのマージポイント、最も大きいflowspec、およびどんな付随の確認要求物だけにも、進められた上流があります。 ノードでは、適所では、Rjからの予約の要請が予約より等しいか、または小さいなら、Resvはさらに送られません、そして、Resvが確認要求物を含んでいたなら、RjはResvConfメッセージに送り返されます。 確認要求を転送するなら、すぐに、進められて、各要求のための一度ほど多くはありません。
This confirmation mechanism has the following consequences:
この確認メカニズムには、以下の結果があります:
o A new reservation request with a flowspec larger than any in
place for a session will normally result in either a ResvErr
or a ResvConf message back to the receiver from each sender.
In this case, the ResvConf message will be an end-to-end
confirmation.
o 通常、flowspecがセッションのために適所にある何より大きい新しい予約の要請は各送付者からの受信機へのResvErrかResvConfメッセージのどちらかをもたらすでしょう。 この場合、ResvConfメッセージは終わりから終わりへの確認になるでしょう。
o The receipt of a ResvConf gives no guarantees. Assume the
first two reservation requests from receivers R1 and R2
arrive at the node where they are merged. R2, whose
reservation was the second to arrive at that node, may
receive a ResvConf from that node while R1's request has not
yet propagated all the way to a matching sender and may still
fail. Thus, R2 may receive a ResvConf although there is no
end-to-end reservation in place; furthermore, R2 may receive
a ResvConf followed by a ResvErr.
o ResvConfの領収書は保証を全く与えません。 受信機のR1とR2からの最初の2つの予約の要請がそれらが合併されているノードに到着すると仮定してください。 R2(予約はそのノードに到着する2番目であった)はR1の要求がまだ合っている送付者までのいっぱいに伝播されていない間、そのノードからResvConfを受けて、まだ失敗しているかもしれません。 したがって、終わりから終わりへの予約が全く適所にありませんが、R2はResvConfを受けるかもしれません。 その上、R2はResvErrによって続かれたResvConfを受けるかもしれません。
2.7 Policy Control
2.7 方針コントロール
RSVP-mediated QoS requests allow particular user(s) to obtain
preferential access to network resources. To prevent abuse, some
form of back pressure will generally be required on users who make
reservations. For example, such back pressure may be accomplished
by administrative access policies, or it may depend upon some form
of user feedback such as real or virtual billing for the "cost" of
a reservation. In any case, reliable user identification and
selective admission will generally be needed when a reservation is
requested.
RSVPによって調停されたQoS要求で、特定のユーザはネットワーク資源への優先のアクセスを得ることができます。 一般に、乱用を防ぐために、何らかのフォームの逆圧が予約をするユーザの上で必要でしょう。 例えば、そのような逆圧が管理アクセス方針で達成されるかもしれませんか、またはそれは何らかのフォームの予約の「費用」のための本当の、または、仮想の支払いなどのユーザフィードバックによるかもしれません。 どのような場合でも、予約が要求されているとき、一般に、信頼できるユーザ登録名と選択している入場が必要でしょう。
The term "policy control" is used for the mechanisms required to
support access policies and back pressure for RSVP reservations.
When a new reservation is requested, each node must answer two
questions: "Are enough resources available to meet this request?"
「方針コントロール」という用語はRSVPの予約へのアクセス方針と逆圧を支持しなければならなかったメカニズムに使用されます。 新しい予約が要求されているとき、各ノードは2つの質問に答えなければなりません: 「会うために利用可能な十分なリソースがこの要求ですか?」
Braden, Ed., et. al. Standards Track [Page 27] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[27ページ]。
and "Is this user allowed to make this reservation?" These two
decisions are termed the "admission control" decision and the
"policy control" decision, respectively, and both must be
favorable in order for RSVP to make a reservation. Different
administrative domains in the Internet may have different
reservation policies.
そして、「このユーザはこの予約をすることができますか?」 これらの2つの決定がそれぞれ「入場コントロール」決定と「方針コントロール」決定と呼ばれます、そして、RSVPが予約をするように、両方が好ましくなければなりません。 インターネットの異なった管理ドメインには、異なった予約方針があるかもしれません。
The input to policy control is referred to as "policy data", which
RSVP carries in POLICY_DATA objects. Policy data may include
credentials identifying users or user classes, account numbers,
limits, quotas, etc. Like flowspecs, policy data is opaque to
RSVP, which simply passes it to policy control when required.
Similarly, merging of policy data must be done by the policy
control mechanism rather than by RSVP itself. Note that the merge
points for policy data are likely to be at the boundaries of
administrative domains. It may therefore be necessary to carry
accumulated and unmerged policy data upstream through multiple
nodes before reaching one of these merge points.
方針コントロールへの入力は「方針データ」と呼ばれます。(RSVPはPOLICY_DATA物でそれを運びます)。 方針データはユーザやユーザ・クラス、口座番号、限界、割当てなどを特定する信任状を含むかもしれません。 flowspecsのように、方針データはRSVPに不明瞭です。(単に、必要であると、RSVPは方針コントロールにそれを通過します)。 同様に、RSVP自身でというよりむしろ方針制御機構は方針データの合併をしなければなりません。 方針データのためのマージポイントが管理ドメインの境界にありそうに注意してください。 したがって、これらのマージポイントの1つに達する前に運ぶのが複数のノードを通して上流へ方針データを蓄積して、非合併したのが必要であるかもしれません。
Carrying user-provided policy data in Resv messages presents a
potential scaling problem. When a multicast group has a large
number of receivers, it will be impossible or undesirable to carry
all receivers' policy data upstream. The policy data will have to
be administratively merged at places near the receivers, to avoid
excessive policy data. Further discussion of these issues and an
example of a policy control scheme will be found in [PolArch96].
Specifications for the format of policy data objects and RSVP
processing rules for them are under development.
Resvメッセージのユーザによって提供された方針データを運ぶと、潜在的スケーリング問題は提示されます。 マルチキャストグループに多くの受信機があるとき、すべての受信機の方針データ上流を運ぶのは、不可能であるか、または望ましくなくなるでしょう。 方針データは、過度の方針データを避けるために受信機の近くの場所で行政上合併されなければならないでしょう。 これらの問題のさらなる議論と方針コントロール計画に関する例は[PolArch96]で見つけられるでしょう。 方針データ・オブジェクトの形式のための仕様とそれらのためのRSVP処理規則は開発中です。
2.8 Security
2.8 セキュリティ
RSVP raises the following security issues.
RSVPは以下の安全保障問題を提起します。
o Message integrity and node authentication
o メッセージの保全とノード認証
Corrupted or spoofed reservation requests could lead to theft
of service by unauthorized parties or to denial of service
caused by locking up network resources. RSVP protects
against such attacks with a hop-by-hop authentication
mechanism using an encrypted hash function. The mechanism is
supported by INTEGRITY objects that may appear in any RSVP
message. These objects use a keyed cryptographic digest
technique, which assumes that RSVP neighbors share a secret.
Although this mechanism is part of the base RSVP
specification, it is described in a companion document
[Baker96].
崩壊したかだまされた予約の要請はネットワーク資源に鍵をかけることによって引き起こされたサービスの否定に対する権限のないパーティー、または、サービスの窃盗につながるかもしれません。 RSVPはホップごとの認証機構がコード化されたハッシュ関数を使用しているそのような攻撃から守ります。 メカニズムはどんなRSVPメッセージにも現れるかもしれないINTEGRITY物によってサポートされます。 これらの物は合わせられた暗号のダイジェストのテクニックを使用します。(それは、RSVP隣人が秘密を共有すると仮定します)。 このメカニズムはベースRSVP仕様の一部ですが、それは仲間ドキュメント[Baker96]で説明されます。
Braden, Ed., et. al. Standards Track [Page 28] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[28ページ]。
Widespread use of the RSVP integrity mechanism will require
the availability of the long-sought key management and
distribution infrastructure for routers. Until that
infrastructure becomes available, manual key management will
be required to secure RSVP message integrity.
RSVP保全メカニズムの普及使用はルータのために長く探されたかぎ管理と分配インフラストラクチャの有用性を必要とするでしょう。 そのインフラストラクチャが利用可能になるまで、手動のかぎ管理はRSVPメッセージの保全を保証しなければならないでしょう。
o User authentication
o ユーザー認証
Policy control will depend upon positive authentication of
the user responsible for each reservation request. Policy
data may therefore include cryptographically protected user
certificates. Specification of such certificates is a future
issue.
方針コントロールは各予約の要請に責任があるユーザの積極的な認証によるでしょう。 したがって、方針データは暗号で保護されたユーザー証明書を含むかもしれません。 そのような証明書の仕様は将来の問題です。
Even without globally-verifiable user certificates, it may be
possible to provide practical user authentication in many
cases by establishing a chain of trust, using the hop-by-hop
INTEGRITY mechanism described earlier.
グローバルに証明可能なユーザー証明書がなくても、多くの場合、信用のチェーンを設立するのによる実用的なユーザー認証を提供するのは可能であるかもしれません、ホップごとの、より早く説明されたINTEGRITYメカニズムを使用して。
o Secure data streams
o 安全なデータ・ストリーム
The first two security issues concerned RSVP's operation. A
third security issue concerns resource reservations for
secure data streams. In particular, the use of IPSEC (IP
Security) in the data stream poses a problem for RSVP: if
the transport and higher level headers are encrypted, RSVP's
generalized port numbers cannot be used to define a session
or a sender.
最初の2つの安全保障問題がRSVPの操作に関係がありました。 3番目の安全保障問題は安全なデータ・ストリームの資源予約に関係があります。特に、データ・ストリームにおけるIPSEC(IP Security)の使用はRSVPのために問題を設定します: 輸送と、より高い平らなヘッダーがコード化されているなら、セッションか送付者を定義するのにRSVPの一般化されたポートナンバーを使用できません。
To solve this problem, an RSVP extension has been defined in
which the security association identifier (IPSEC SPI) plays a
role roughly equivalent to the generalized ports [RFC 2207].
この問題を解決するために、セキュリティ協会識別子(IPSEC SPI)がおよそ一般化されたポート[RFC2207]に同等な役割を果たすRSVP拡張子は定義されました。
2.9 Non-RSVP Clouds
2.9 非RSVP雲
It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform
resource reservation. However, if such a cloud has sufficient
capacity, it may still provide useful realtime service.
同時に全体のインターネット中でRSVP(または、どんな新しいプロトコルも)を配備するのは不可能です。 その上、RSVPはいたる所で決して配備されないかもしれません。 したがって、2つのRSVPできるルータが非RSVPルータの任意の「雲」によって接合さえされるとき、RSVPは正しいプロトコル操作を提供しなければなりません。 もちろん、RSVPを支持しない中間的雲は資源予約を実行できません。 しかしながら、そのような雲に十分な容量があるなら、それはまだ役に立つリアルタイムでサービスを提供しているかもしれません。
RSVP is designed to operate correctly through such a non-RSVP
cloud. Both RSVP and non-RSVP routers forward Path messages
towards the destination address using their local uni-/multicast
routing table. Therefore, the routing of Path messages will be
RSVPは、そのような非RSVP雲を通して正しく作動するように設計されています。 RSVPと非RSVPルータの両方が、それらの地方のuni/マルチキャスト経路指定テーブルを使用することで送付先アドレスに向かったメッセージをPathに転送します。 したがって、Pathメッセージのルーティングはそうでしょう。
Braden, Ed., et. al. Standards Track [Page 29] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[29ページ]。
unaffected by non-RSVP routers in the path. When a Path message
traverses a non-RSVP cloud, it carries to the next RSVP-capable
node the IP address of the last RSVP-capable router before
entering the cloud. An Resv message is then forwarded directly to
the next RSVP-capable router on the path(s) back towards the
source.
経路の非RSVPルータで、影響を受けないです。 Pathメッセージが非RSVP雲を横断するとき、雲に入る前に、それは最後のRSVPできるルータのIPアドレスを次のRSVPできるノードまで運びます。 経路でResvメッセージはソースに向かって直接次のRSVPできるルータに送られたその時であって戻ります。
Even though RSVP operates correctly through a non-RSVP cloud, the
non-RSVP-capable nodes will in general perturb the QoS provided to
a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the
local traffic control mechanism when there are non-RSVP-capable
hops in the path to a given sender. Traffic control combines this
flag bit with its own sources of information, and forwards the
composed information on integrated service capability along the
path to receivers using Adspecs [RFC 2210].
RSVPは非RSVP雲を通して正しく作動しますが、一般に、できる非RSVPノードは受信機に提供されたQoSを混乱させるでしょう。したがって、できる非RSVPホップが与えられた送付者への経路にあるとき、RSVPは'NonRSVP'フラグビットをローカルのトラフィックコントロールメカニズムに渡します。 トラフィックコントロールは、このフラグビットをそれ自身の情報筋に結合して、Adspecs[RFC2210]を使用することで経路に沿った統合サービス能力の落ち着いた情報を受信機に転送します。
Some topologies of RSVP routers and non-RSVP routers can cause
Resv messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP
process must be prepared to handle either situation. If the
destination address does not match any local interface and the
message is not a Path or PathTear, the message must be forwarded
without further processing by this node. To handle the wrong
interface case, a "Logical Interface Handle" (LIH) is used. The
previous hop information included in a Path message includes not
only the IP address of the previous node but also an LIH defining
the logical outgoing interface; both values are stored in the path
state. A Resv message arriving at the addressed node carries both
the IP address and the LIH of the correct outgoing interface, i.e,
the interface that should receive the requested reservation,
regardless of which interface it arrives on.
RSVPルータと非RSVPルータのいくらかのtopologiesが間違ったRSVPできるノードに到着するか、または正しいノードの間違ったインタフェースに到着するメッセージをResvに引き起こす場合があります。 どちらの状況も扱うようにRSVPの過程を準備しなければなりません。 メッセージが送付先アドレスが少しの局所界面にも合わないで、またPathでなくて、またPathTearでもないなら、このノードはさらなる処理なしでメッセージを転送しなければなりません。 間違ったインタフェースケースを扱うために、「論理的なインタフェースハンドル」(LIH)は使用されています。 Pathメッセージに前のホップ情報を含んでいると、前のノードのIPアドレスだけではなく、論理的な外向的なインタフェースを定義するLIHも包含します。 両方の値は経路州に格納されます。 記述されたノードに到着するResvメッセージはIPアドレスと正しい外向的なインタフェースのLIHの両方を運びます、i.e、要求された予約を受けるべきであるインタフェース、どのインタフェースで到着するかにかかわらず。
The LIH may also be useful when RSVP reservations are made over a
complex link layer, to map between IP layer and link layer flow
entities.
また、IP層とリンクレイヤの間で流れ実体を写像するために複雑なリンクレイヤであることをRSVPの予約を変更されるとき、LIHも役に立つかもしれません。
2.10 Host Model
2.10 ホストモデル
Before a session can be created, the session identification
(DestAddress, ProtocolId [, DstPort]) must be assigned and
communicated to all the senders and receivers by some out-of-band
mechanism. When an RSVP session is being set up, the following
events happen at the end systems.
セッションの前に、メカニズムは、作成されています、セッション識別(DestAddress、ProtocolId[DstPort])を割り当てなければならないということであることができ、バンドの外でいくつかですべての送付者と受信機に交信していました。 RSVPセッションがセットアップされているとき、以下の出来事はエンドシステムで起こります。
Braden, Ed., et. al. Standards Track [Page 30] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[30ページ]。
H1 A receiver joins the multicast group specified by
DestAddress, using IGMP.
H1A受信機はIGMPを使用して、DestAddressによって指定されたマルチキャストグループに加わります。
H2 A potential sender starts sending RSVP Path messages to the
DestAddress.
潜在的送付者がDestAddressへのメッセージをRSVP Pathに送り始めるH2。
H3 A receiver application receives a Path message.
H3A受信側アプリケーションはPathメッセージを受け取ります。
H4 A receiver starts sending appropriate Resv messages,
specifying the desired flow descriptors.
必要な流れ記述子を指定して、受信機が発信させ始めるH4はResvメッセージを当てます。
H5 A sender application receives a Resv message.
H5A送付者アプリケーションはResvメッセージを受け取ります。
H6 A sender starts sending data packets.
送付者がデータ・パケットを送り始めるH6。
There are several synchronization considerations.
いくつかの同期問題があります。
o H1 and H2 may happen in either order.
o H1とH2はオーダーで起こるかもしれません。
o Suppose that a new sender starts sending data (H6) but there
are no multicast routes because no receivers have joined the
group (H1). Then the data will be dropped at some router
node (which node depends upon the routing protocol) until
receivers(s) appear.
o 新しい送付者がデータ(H6)を送り始めると思いますが、どんな受信機もグループ(H1)に加わっていないので、マルチキャストルートが全くありません。 そして、受信機が現れるまで、データは何らかのルータノード(そのノードはルーティング・プロトコルによる)で落とされるでしょう。
o Suppose that a new sender starts sending Path messages (H2)
and data (H6) simultaneously, and there are receivers but no
Resv messages have reached the sender yet (e.g., because its
Path messages have not yet propagated to the receiver(s)).
Then the initial data may arrive at receivers without the
desired QoS. The sender could mitigate this problem by
awaiting arrival of the first Resv message (H5); however,
receivers that are farther away may not have reservations in
place yet.
o 新しい送付者が同時に、Pathメッセージ(H2)とデータ(H6)を送り始めて、受信機がありますが、どんなResvメッセージもまだ送付者に届いていないと仮定してください。(例えば、Pathメッセージがまだ受信機(s))に伝播されていないので。 そして、初期のデータは必要なQoSなしで受信機に到着するかもしれません。 送付者は最初のResvメッセージ(H5)の到着を待つことによって、この問題を緩和できるでしょう。 しかしながら、遠くでは、より遠い受信機は適所にまだ予約を持っていないかもしれません。
o If a receiver starts sending Resv messages (H4) before
receiving any Path messages (H3), RSVP will return error
messages to the receiver.
o どんなPathメッセージ(H3)も受け取る前に受信機がメッセージ(H4)をResvに送り始めると、RSVPはエラーメッセージを受信機に返すでしょう。
The receiver may simply choose to ignore such error messages,
or it may avoid them by waiting for Path messages before
sending Resv messages.
受信機が、そのようなエラーメッセージを無視するのを単に選ぶかもしれませんか、またはそれは、メッセージをResvに送る前にPathメッセージを待つことによって、それらを避けるかもしれません。
A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent.
However, Section 3.11.1 discusses the general requirements and
outlines a generic interface.
RSVPのための特定の適用業務プログラム・インタフェース(API)はこのプロトコル仕様に基づき定義されません、それがホストシステムに依存しているとき。 しかしながら、セクション3.11.1は、一般的な要件について議論して、一般的なインタフェースについて概説します。
Braden, Ed., et. al. Standards Track [Page 31] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[31ページ]。
3. RSVP Functional Specification
3. RSVPの機能的な仕様
3.1 RSVP Message Formats
3.1 RSVPメッセージ・フォーマット
An RSVP message consists of a common header, followed by a body
consisting of a variable number of variable-length, typed
"objects". The following subsections define the formats of the
common header, the standard object header, and each of the RSVP
message types.
RSVPメッセージは可変数の可変長の、そして、タイプされた「物」から成るボディーがあとに続いた一般的なヘッダーから成ります。 以下の小区分は一般的なヘッダー(標準の物のヘッダー、およびRSVPメッセージタイプ各人)の書式を定義します。
For each RSVP message type, there is a set of rules for the
permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation
should create messages with the objects in the order shown here,
but accept the objects in any permissible order.
それぞれのRSVPメッセージタイプのために、オブジェクト・タイプの許されている選択のための1セットの規則があります。 これらの規則は、角括弧が任意のサブ系列を囲んでいて増大するBN記法(BNF)を使用することで指定されます。 BNFはメッセージの物の注文を含意します。 しかしながら、多くの(すべてでない)場合では、物のオーダーはどんな論理的な違いも作りません。 実現はここのオーダーで物でメッセージを作成するべきですが、あらゆる許されているオーダーで物を受け入れてください。
3.1.1 Common Header
3.1.1 一般的なヘッダー
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers| 旗| エムエスジータイプ| RSVPチェックサム| +-------------+-------------+-------------+-------------+ | _TTLを送ってください。| (予約される)です。 | RSVPの長さ| +-------------+-------------+-------------+-------------+
The fields in the common header are as follows:
一般的なヘッダーの分野は以下の通りです:
Vers: 4 bits
Vers: 4ビット
Protocol version number. This is version 1.
バージョン番号について議定書の中で述べてください。 これはバージョン1です。
Flags: 4 bits
旗: 4ビット
0x01-0x08: Reserved
0×01 0×08: 予約されます。
No flag bits are defined yet.
フラグビットは全くまだ定義されていません。
Msg Type: 8 bits
エムエスジーは以下をタイプします。 8ビット
1 = Path
1つの=経路
2 = Resv
2 =Resv
Braden, Ed., et. al. Standards Track [Page 32] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[32ページ]。
3 = PathErr
3 =PathErr
4 = ResvErr
4 =ResvErr
5 = PathTear
5 =PathTear
6 = ResvTear
6 =ResvTear
7 = ResvConf
7 =ResvConf
RSVP Checksum: 16 bits
RSVPチェックサム: 16ビット
The one's complement of the one's complement sum of the
message, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value
means that no checksum was transmitted.
チェックサムを計算する目的のためにチェックサム野原をゼロに取り替えているメッセージの1の補数合計の1の補数。 オールゼロ値は、チェックサムが全く伝えられなかったことを意味します。
Send_TTL: 8 bits
_TTLを送ってください: 8ビット
The IP TTL value with which the message was sent. See
Section 3.8.
メッセージが送られたIP TTL値。 セクション3.8を見てください。
RSVP Length: 16 bits
RSVPの長さ: 16ビット
The total length of this RSVP message in bytes, including
the common header and the variable-length objects that
follow.
一般的なヘッダーと従う可変長の物を含むバイトで表現されるこのRSVPメッセージの全長。
3.1.2 Object Formats
3.1.2 物の形式
Every object consists of one or more 32-bit words with a one-
word header, with the following format:
あらゆる物が1個の単語ヘッダー、以下の形式で1つ以上の32ビットの単語から成ります:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | 長さ(バイト)| クラスヌム| C-タイプ| +-------------+-------------+-------------+-------------+ | | //(物のコンテンツ)//| | +-------------+-------------+-------------+-------------+
Braden, Ed., et. al. Standards Track [Page 33] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[33ページ]。
An object header has the following fields:
物のヘッダーには、以下の分野があります:
Length
長さ
A 16-bit field containing the total object length in
bytes. Must always be a multiple of 4, and at least 4.
バイトで表現される総物の長さを含む16ビットの分野。 aが4、および少なくとも4の倍数であったならいつもそうしなければなりません。
Class-Num
クラスヌム
Identifies the object class; values of this field are
defined in Appendix A. Each object class has a name,
which is always capitalized in this document. An RSVP
implementation must recognize the following classes:
物のクラスは特定します。 この分野の値はAppendix A.で定義されます。Each物のクラスには、名前があります。(それは、いつも本書では大文字で書かれます)。 RSVP実現は以下のクラスを認識しなければなりません:
NULL
ヌル
A NULL object has a Class-Num of zero, and its C-Type
is ignored. Its length must be at least 4, but can
be any multiple of 4. A NULL object may appear
anywhere in a sequence of objects, and its contents
will be ignored by the receiver.
NULL物には、ゼロのClass-ヌムがあります、そして、C-タイプは無視されます。 長さは、少なくとも4でなければなりませんが、4のどんな倍数であるかもしれません。 NULL物は物の系列でどこでも現れるかもしれません、そして、コンテンツは受信機によって無視されるでしょう。
SESSION
セッション
Contains the IP destination address (DestAddress),
the IP protocol id, and some form of generalized
destination port, to define a specific session for
the other objects that follow. Required in every
RSVP message.
従う他の物のための特定のセッションを定義するために受信者IPアドレス(DestAddress)、IPプロトコルイド、および何らかの形式の一般化された仕向港を含んでいます。 あらゆるRSVPメッセージでは、必要です。
RSVP_HOP
RSVP_ホップ
Carries the IP address of the RSVP-capable node that
sent this message and a logical outgoing interface
handle (LIH; see Section 3.3). This document refers
to a RSVP_HOP object as a PHOP ("previous hop")
object for downstream messages or as a NHOP (" next
hop") object for upstream messages.
このメッセージを送ったRSVPできるノードと論理的な出発しているインタフェースハンドル(LIH; セクション3.3を見る)のIPアドレスを運びます。 このドキュメントは川下のメッセージのためのPHOP(「前のホップ」)物か上流のメッセージのためのNHOP(「次のホップ」)物とRSVP_HOP物を呼びます。
TIME_VALUES
時間_値
Contains the value for the refresh period R used by
the creator of the message; see Section 3.7.
Required in every Path and Resv message.
値を含んでいる、以上、メッセージの創造者によって使用されたRをリフレッシュしてください。 セクション3.7を見てください。 あらゆるPathとResvメッセージでは、必要です。
Braden, Ed., et. al. Standards Track [Page 34] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[34ページ]。
STYLE
スタイル
Defines the reservation style plus style-specific
information that is not in FLOWSPEC or FILTER_SPEC
objects. Required in every Resv message.
FLOWSPECかFILTER_SPEC物にない予約スタイルとスタイル特有の情報を定義します。 あらゆるResvメッセージでは、必要です。
FLOWSPEC
FLOWSPEC
Defines a desired QoS, in a Resv message.
Resvメッセージで必要なQoSを定義します。
FILTER_SPEC
フィルタ_仕様
Defines a subset of session data packets that should
receive the desired QoS (specified by a FLOWSPEC
object), in a Resv message.
Resvメッセージで必要なQoS(FLOWSPEC物で、指定される)を受けるはずであるセッションデータ・パケットの部分集合を定義します。
SENDER_TEMPLATE
送付者_テンプレート
Contains a sender IP address and perhaps some
additional demultiplexing information to identify a
sender. Required in a Path message.
送付者を特定する送付者IPアドレスと恐らく何らかの追加逆多重化情報を含んでいます。 Pathメッセージでは、必要です。
SENDER_TSPEC
送付者_TSPEC
Defines the traffic characteristics of a sender's
data flow. Required in a Path message.
送付者のデータフローの交通の特性を定義します。 Pathメッセージでは、必要です。
ADSPEC
ADSPEC
Carries OPWA data, in a Path message.
PathメッセージのOPWAデータを運びます。
ERROR_SPEC
誤り_仕様
Specifies an error in a PathErr, ResvErr, or a
confirmation in a ResvConf message.
ResvConfメッセージにおけるPathErr、ResvErr、または確認における誤りを指定します。
POLICY_DATA
方針_データ
Carries information that will allow a local policy
module to decide whether an associated reservation is
administratively permitted. May appear in Path,
Resv, PathErr, or ResvErr message.
ローカルの方針モジュールが、関連予約が行政上受入れられるかどうか決めることができる情報を運びます。 Path、Resv、PathErr、またはResvErrメッセージに現れるかもしれません。
The use of POLICY_DATA objects is not fully specified
at this time; a future document will fill this gap.
POLICY_DATA物の使用はこのとき、完全に指定されるというわけではありません。 将来のドキュメントはこの不足をいっぱいにするでしょう。
Braden, Ed., et. al. Standards Track [Page 35] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[35ページ]。
INTEGRITY
保全
Carries cryptographic data to authenticate the
originating node and to verify the contents of this
RSVP message. The use of the INTEGRITY object is
described in [Baker96].
由来しているノードを認証して、このRSVPメッセージのコンテンツについて確かめるために暗号のデータを運びます。 INTEGRITY物の使用は[Baker96]で説明されます。
SCOPE
範囲
Carries an explicit list of sender hosts towards
which the information in the message is to be
forwarded. May appear in a Resv, ResvErr, or
ResvTear message. See Section 3.4.
送られるメッセージの情報がことである送付者ホストの明白なリストを運びます。 Resv、ResvErr、またはResvTearメッセージに現れるかもしれません。 セクション3.4を見てください。
RESV_CONFIRM
RESV_は確認します。
Carries the IP address of a receiver that requested a
confirmation. May appear in a Resv or ResvConf
message.
確認を要求した受信機のIPアドレスを運びます。 ResvかResvConfメッセージに現れるかもしれません。
C-Type
C-タイプ
Object type, unique within Class-Num. Values are defined
in Appendix A.
Class-ヌムの中でユニークなオブジェクト・タイプ。 値はAppendix Aで定義されます。
The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields may be used together as a 16-bit number
to define a unique type for each object.
最大の物のコンテンツの長さは65528バイトです。 ClassヌムとC-タイプ分野は、各物のためのユニークなタイプを定義するのに16ビットの数として一緒に使用されるかもしれません。
The high-order two bits of the Class-Num is used to determine
what action a node should take if it does not recognize the
Class-Num of an object; see Section 3.10.
物のClass-ヌムを認識しないなら、Class-ヌムの高位2ビットはノードがどんな行動を取るはずであるかを決定するのに使用されます。 セクション3.10を見てください。
3.1.3 Path Messages
3.1.3 経路メッセージ
Each sender host periodically sends a Path message for each
data flow it originates. It contains a SENDER_TEMPLATE object
defining the format of the data packets and a SENDER_TSPEC
object specifying the traffic characteristics of the flow.
Optionally, it may contain may be an ADSPEC object carrying
advertising (OPWA) data for the flow.
それぞれの送付者ホストは定期的にそれが溯源する各データフローへのPathメッセージを送ります。 それはデータ・パケットの書式を定義するSENDER_TEMPLATE物と流れの交通の特性を指定するSENDER_TSPEC物を含んでいます。 任意に、それは広告(OPWA)を運んだADSPEC物が流れのためのデータであったかもしれないなら含むかもしれません。
A Path message travels from a sender to receiver(s) along the
same path(s) used by the data packets. The IP source address
of a Path message must be an address of the sender it
describes, while the destination address must be the
DestAddress for the session. These addresses assure that the
message will be correctly routed through a non-RSVP cloud.
Pathメッセージはデータ・パケットによって使用される同じ経路に沿って送付者から受信機まで移動します。 PathメッセージのIPソースアドレスはそれが説明する送信者のアドレスであるに違いありません、送付先アドレスがセッションのためのDestAddressでなければなりませんが。 これらのアドレスは、メッセージが非RSVP雲を通して正しく発送されることを保証します。
Braden, Ed., et. al. Standards Track [Page 36] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[36ページ]。
The format of a Path message is as follows:
Pathメッセージの形式は以下の通りです:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<経路メッセージ>:、:= <の一般的なヘッダー>。[<保全>]
<SESSION> <RSVP_HOP>
<セッション><RSVP_ホップ>。
<TIME_VALUES>
<時間_は>を評価します。
[ <POLICY_DATA> ... ]
[<方針_データ>]
[ <sender descriptor> ]
[<送付者記述子>]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
<送付者記述子>:、:= _<送付者_テンプレート><送付者TSPEC>。
[ <ADSPEC> ]
[<ADSPEC>]
If the INTEGRITY object is present, it must immediately follow
the common header. There are no other requirements on
transmission order, although the above order is recommended.
Any number of POLICY_DATA objects may appear.
INTEGRITY物が存在しているなら、それはすぐに、一般的なヘッダーに続かなければなりません。 上記のオーダーはお勧めですが、トランスミッション命令に関する他の要件が全くありません。 いろいろなPOLICY_DATA物が現れるかもしれません。
The PHOP (i.e., RSVP_HOP) object of each Path message contains
the previous hop address, i.e., the IP address of the interface
through which the Path message was most recently sent. It also
carries a logical interface handle (LIH).
それぞれのPathメッセージのPHOP(すなわち、RSVP_HOP)物は前のホップアドレス(すなわち、Pathメッセージがごく最近送られたインタフェースのIPアドレス)を含んでいます。 また、それは論理的なインタフェースハンドル(LIH)を運びます。
Each RSVP-capable node along the path(s) captures a Path
message and processes it to create path state for the sender
defined by the SENDER_TEMPLATE and SESSION objects. Any
POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
the path state. If an error is encountered while processing a
Path message, a PathErr message is sent to the originating
sender of the Path message. Path messages must satisfy the
rules on SrcPort and DstPort in Section 3.2.
経路に沿ったそれぞれのRSVPできるノードは、SENDER_TEMPLATEとSESSION物によって定義された送付者のために経路州を創設するためにPathメッセージを得て、それを処理します。 また、どんなPOLICY_DATA、SENDER_TSPEC、およびADSPEC物も経路州に保存されます。 Pathメッセージを処理している間、誤りに遭遇するなら、Pathメッセージの由来している送付者にPathErrメッセージを送ります。 経路メッセージはセクション3.2でSrcPortとDstPortの上の規則を満たさなければなりません。
Periodically, the RSVP process at a node scans the path state
to create new Path messages to forward towards the receiver(s).
Each message contains a sender descriptor defining one sender,
and carries the original sender's IP address as its IP source
address. Path messages eventually reach the applications on
all receivers; however, they are not looped back to a receiver
running in the same application process as the sender.
定期的に、ノードのRSVPの過程は、受信機に向かって転送する新しいPathメッセージを作成するために経路州をスキャンします。 各メッセージは、1人の送付者を定義する送付者記述子を含んでいて、IPソースアドレスとして元の送り主のIPアドレスを運びます。 経路メッセージは結局、すべての受信機におけるアプリケーションに達します。 しかしながら、それらは送付者と同じアプリケーション・プロセスへ駆け込む受信機に輪にして戻されません。
The RSVP process forwards Path messages and replicates them as
required by multicast sessions, using routing information it
obtains from the appropriate uni-/multicast routing process.
The route depends upon the session DestAddress, and for some
RSVPの過程は、メッセージをPathに転送して、必要に応じてマルチキャストセッションでそれらを模写します、それが適切なuni/マルチキャストルーティングの過程から得るルーティング情報を使用して。 ルートはセッションDestAddress、およびいくつかのためによります。
Braden, Ed., et. al. Standards Track [Page 37] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[37ページ]。
routing protocols also upon the source (sender's IP) address.
The routing information generally includes the list of zero or
more outgoing interfaces to which the Path message is to be
forwarded. Because each outgoing interface has a different IP
address, the Path messages sent out different interfaces
contain different PHOP addresses. In addition, ADSPEC objects
carried in Path messages will also generally differ for
different outgoing interfaces.
ソース(送付者のIP)アドレスに関してもプロトコルを発送します。 一般に、ルーティング情報はゼロか送られるPathメッセージがことであるより外向的なインタフェースのリストを含んでいます。 異なったIPアドレス、出されたPathメッセージがそれぞれの外向的なインタフェースで異なるようになるので、インタフェースは異なったPHOPアドレスを含んでいます。 一般に、さらに、また、Pathメッセージで運ばれたADSPEC物は異なった外向的なインタフェースに異なるでしょう。
Path state for a given session and sender may not necessarily
have a unique PHOP or unique incoming interface. There are two
cases, corresponding to multicast and unicast sessions.
与えられたセッションと送付者のための経路州には、ユニークなPHOPかユニークな入って来るインタフェースが必ずあるかもしれないというわけではありません。 マルチキャストとユニキャストセッションに対応している、2つのケースがあります。
o Multicast Sessions
o マルチキャストセッション
Multicast routing allows a stable distribution tree in
which Path messages from the same sender arrive from more
than one PHOP, and RSVP must be prepared to maintain all
such path state. The RSVP rules for handling this
situation are contained in Section 3.9. RSVP must not
forward (according to the rules of Section 3.9) Path
messages that arrive on an incoming interface different
from that provided by routing.
マルチキャストルーティングは同じ送付者からのPathメッセージが1PHOPから到着する安定分布木を許容します、そして、そのようなすべての経路州を維持するようにRSVPを準備しなければなりません。 この状況を扱うためのRSVP規則はセクション3.9に含まれています。 RSVPはルーティングで提供されたそれと異なった入って来るインタフェースで到着する経路メッセージを転送してはいけません(セクション3.9の規則に従って)。
o Unicast Sessions
o ユニキャストセッション
For a short period following a unicast route change
upstream, a node may receive Path messages from multiple
PHOPs for a given (session, sender) pair. The node cannot
reliably determine which is the right PHOP, although the
node will receive data from only one of the PHOPs at a
time. One implementation choice for RSVP is to ignore
PHOP in matching unicast past state, and allow the PHOP to
flip among the candidates. Another implementation choice
is to maintain path state for each PHOP and to send Resv
messages upstream towards all such PHOPs. In either case,
the situation is a transient; the unused path state will
time out or be torn down (because upstream path state
timed out).
しばらくの間ユニキャストルート変化上流に続いて、ノードは(セッション、送付者)与えられた組のために複数のPHOPsからPathメッセージを受け取るかもしれません。 ノードは、どれが右のPHOPであるかを確かに決定できません、ノードが一度に、PHOPsについて1だけからデータを受け取るでしょうが。 RSVPのための1つの実現選択は、ユニキャストの合っている過去の状態でPHOPを無視して、PHOPが候補の中で宙返りするのを許容することです。 別の実現選択は、各PHOPのために経路州を維持して、そのようなすべてのPHOPsに向かってResvメッセージ上流を送ることです。 どちらかの場合では、状況はa一時的です。 未使用の経路は、タイムアウトを望んでいるか、または取りこわされるように述べます(上流の経路州が外で調節されたので)。
3.1.4 Resv Messages
3.1.4 Resvメッセージ
Resv messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flows for
the session. The IP destination address of a Resv message is
the unicast address of a previous-hop node, obtained from the
path state. The IP source address is an address of the node
that sent the message.
Resvメッセージはセッションのためのデータフローの逆の経路に沿って受信機から送付者までのホップごとの予約の要請を運びます。 Resvメッセージの受信者IPアドレスは経路州から得られた前のホップノードのユニキャストアドレスです。 IPソースアドレスはメッセージを送ったノードのアドレスです。
Braden, Ed., et. al. Standards Track [Page 38] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[38ページ]。
The Resv message format is as follows:
Resvメッセージ・フォーマットは以下の通りです:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<Resvメッセージ>:、:= <の一般的なヘッダー>。[<保全>]
<SESSION> <RSVP_HOP>
<セッション><RSVP_ホップ>。
<TIME_VALUES>
<時間_は>を評価します。
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[<RESV_は>を確認します][<範囲>]
[ <POLICY_DATA> ... ]
[<方針_データ>]
<STYLE> <flow descriptor list>
<様式><流れ記述子リスト>。
<flow descriptor list> ::= <empty> |
<流れ記述子リスト>:、:= <の空の>。|
<flow descriptor list> <flow descriptor>
<流れ記述子リスト><流れ記述子>。
If the INTEGRITY object is present, it must immediately follow
the common header. The STYLE object followed by the flow
descriptor list must occur at the end of the message, and
objects within the flow descriptor list must follow the BNF
given below. There are no other requirements on transmission
order, although the above order is recommended.
INTEGRITY物が存在しているなら、それはすぐに、一般的なヘッダーに続かなければなりません。 流れ記述子リストがあとに続いた様式物はメッセージの終わりに現れなければなりません、そして、流れ記述子リストの中の物は以下に与えられたBNFに続かなければなりません。 上記のオーダーはお勧めですが、トランスミッション命令に関する他の要件が全くありません。
The NHOP (i.e., the RSVP_HOP) object contains the IP address of
the interface through which the Resv message was sent and the
LIH for the logical interface on which the reservation is
required.
NHOP(すなわち、RSVP_HOP)物はResvメッセージが送られたインタフェースのIPアドレスと論理的なインタフェースへの予約が必要であるLIHを含んでいます。
The appearance of a RESV_CONFIRM object signals a request for a
reservation confirmation and carries the IP address of the
receiver to which the ResvConf should be sent. Any number of
POLICY_DATA objects may appear.
RESV_CONFIRM物の外観は、予約確認を求める要求を示して、ResvConfが送られるべきである受信機のIPアドレスを運びます。 いろいろなPOLICY_DATA物が現れるかもしれません。
The BNF above defines a flow descriptor list as simply a list
of flow descriptors. The following style-dependent rules
specify in more detail the composition of a valid flow
descriptor list for each of the reservation styles.
上のBNFは記述子が単に流れ記述子のリストに記載する流れを定義します。 以下のスタイル依存する規則はさらに詳細にそれぞれの予約スタイルのための有効な流れ記述子リストの構成を指定します。
o WF Style:
o WF様式:
<flow descriptor list> ::= <WF flow descriptor>
<流れ記述子リスト>:、:= <WF流れ記述子>。
<WF flow descriptor> ::= <FLOWSPEC>
<WF流れ記述子>:、:= <FLOWSPEC>。
Braden, Ed., et. al. Standards Track [Page 39] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[39ページ]。
o FF style:
o FFスタイル:
<flow descriptor list> ::=
<流れ記述子リスト>:、:=
<FLOWSPEC> <FILTER_SPEC> |
<FLOWSPEC><フィルタ_仕様>。|
<flow descriptor list> <FF flow descriptor>
<流れ記述子リスト><FF流れ記述子>。
<FF flow descriptor> ::=
<FF流れ記述子>:、:=
[ <FLOWSPEC> ] <FILTER_SPEC>
[<FLOWSPEC>]<フィルタ_仕様>。
Each elementary FF style request is defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
may be packed into the flow descriptor list of a single
Resv message. A FLOWSPEC object can be omitted if it is
identical to the most recent such object that appeared in
the list; the first FF flow descriptor must contain a
FLOWSPEC.
それぞれの基本のFFスタイル要求は1(FLOWSPEC、FILTER_SPEC)組によって定義されます、そして、そのようなものが要求する倍数はただ一つのResvメッセージの流れ記述子リストに埋めつくされるかもしれません。 それがリストに現れた最新のそのような物と同じであるなら、FLOWSPEC物を省略できます。 最初のFF流れ記述子はFLOWSPECを含まなければなりません。
o SE style:
o SEスタイル:
<flow descriptor list> ::= <SE flow descriptor>
<流れ記述子リスト>:、:= <SE流れ記述子>。
<SE flow descriptor> ::=
<SE流れ記述子>:、:=
<FLOWSPEC> <filter spec list>
<FLOWSPEC><フィルタ仕様リスト>。
<filter spec list> ::= <FILTER_SPEC>
<フィルタ仕様リスト>:、:= <フィルタ_仕様>。
| <filter spec list> <FILTER_SPEC>
| <フィルタ仕様リスト><FILTER_SPEC>。
The reservation scope, i.e., the set of senders towards which a
particular reservation is to be forwarded (after merging), is
determined as follows:
予約範囲(すなわち、送られる(合併した後に)特定の予約がことである送付者のセット)は以下の通り断固としています:
o Explicit sender selection
o 明白な送付者選択
The reservation is forwarded to all senders whose
SENDER_TEMPLATE objects recorded in the path state match a
FILTER_SPEC object in the reservation. This match must
follow the rules of Section 3.2.
経路州に記録されたSENDER_TEMPLATE物が予約でFILTER_SPEC物に合っているすべての送付者に予約を送ります。 このマッチはセクション3.2の規則に従わなければなりません。
Braden, Ed., et. al. Standards Track [Page 40] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[40ページ]。
o Wildcard sender selection
o ワイルドカード送付者選択
A request with wildcard sender selection will match all
senders that route to the given outgoing interface.
ワイルドカード送付者選択による要求は外向的なインタフェースを付与に発送するすべての送付者に合うでしょう。
Whenever a Resv message with wildcard sender selection is
forwarded to more than one previous hop, a SCOPE object
must be included in the message (see Section 3.4 below);
in this case, the scope for forwarding the reservation is
constrained to just the sender IP addresses explicitly
listed in the SCOPE object.
ワイルドカード送付者選択があるResvメッセージを前の1つ以上のホップに転送するときはいつも、メッセージにSCOPE物を含まなければなりません(以下のセクション3.4を見てください)。 この場合、予約を進めるための範囲はまさしくSCOPE物に明らかに記載された送付者IPアドレスに抑制されます。
A Resv message that is forwarded by a node is generally
the result of merging a set of incoming Resv messages
(that are not blockaded; see Section 3.5). If one of
these merged messages contains a RESV_CONFIRM object and
has a FLOWSPEC larger than the FLOWSPECs of the other
merged reservation requests, then this RESV_CONFIRM object
is forwarded in the outgoing Resv message. A RESV_CONFIRM
object in one of the other merged requests (whose
flowspecs are equal to, smaller than, or incomparable to,
the merged flowspec, and which is not blockaded) will
trigger the generation of an ResvConf message containing
the RESV_CONFIRM. A RESV_CONFIRM object in a request that
is blockaded will be neither forwarded nor returned; it
will be dropped in the current node.
一般に、ノードによって転送されるResvメッセージは1セットの入って来るResvメッセージを合併するという結果(それは封鎖されません; セクション3.5を見る)です。 これらの合併しているメッセージの1つでRESV_CONFIRM物を含んでいて、FLOWSPECが他の合併している予約の要請のFLOWSPECsより大きくなるなら、送信するResvメッセージでこのRESV_CONFIRM物を進めます。 もう片方の1つにおけるRESV_CONFIRM物は要求を合併しました。(flowspecsがだれのものと等しいか、小ささ、比較にならないほどです、合併はflowspecされて、封鎖されないもの) 意志はRESV_CONFIRMを含むResvConfメッセージの世代の引き金となります。 封鎖される要求におけるRESV_CONFIRM物は、進められないで、また返されないでしょう。 それは現在のノードで落とされるでしょう。
3.1.5 Path Teardown Messages
3.1.5 経路分解メッセージ
Receipt of a PathTear (path teardown) message deletes matching
path state. Matching state must have match the SESSION,
SENDER_TEMPLATE, and PHOP objects. In addition, a PathTear
message for a multicast session can only match path state for
the incoming interface on which the PathTear arrived. If there
is no matching path state, a PathTear message should be
discarded and not forwarded.
PathTear(経路分解)メッセージの領収書は合っている経路州を削除します。 州にはなければならないマッチングがSESSION、SENDER_TEMPLATE、およびPHOP物に合っています。 さらに、マルチキャストセッションへのPathTearメッセージはPathTearが到着した入って来るインタフェースへの経路州に合うことができるだけです。 合っている経路州が全くなければ、PathTearメッセージを捨てて、転送するべきではありません。
PathTear messages are initiated explicitly by senders or by
path state timeout in any node, and they travel downstream
towards all receivers. A unicast PathTear must not be
forwarded if there is path state for the same (session, sender)
pair but a different PHOP. Forwarding of multicast PathTear
messages is governed by the rules of Section 3.9.
PathTearメッセージは送付者かどんなノードでも経路州のタイムアウトによって明らかに開始されます、そして、彼らはすべての受信機に向かって川下を旅行します。 同じ(セッション、送付者)組にもかかわらず、異なったPHOPのための経路州があれば、ユニキャストPathTearを進めてはいけません。 マルチキャストPathTearメッセージの推進はセクション3.9の規則で治められます。
Braden, Ed., et. al. Standards Track [Page 41] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[41ページ]。
A PathTear message must be routed exactly like the
corresponding Path message. Therefore, its IP destination
address must be the session DestAddress, and its IP source
address must be the sender address from the path state being
torn down.
ちょうど対応するPathメッセージのようにPathTearメッセージを発送しなければなりません。 したがって、受信者IPアドレスはセッションDestAddressであるに違いありません、そして、IPソースアドレスは取りこわされる経路州からの送付者アドレスであるに違いありません。
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<PathTearメッセージ>:、:= <の一般的なヘッダー>。[<保全>]
<SESSION> <RSVP_HOP>
<セッション><RSVP_ホップ>。
[ <sender descriptor> ]
[<送付者記述子>]
<sender descriptor> ::= (see earlier definition)
<送付者記述子>:、:= (以前の定義を見ます)
A PathTear message may include a SENDER_TSPEC or ADSPEC object
in its sender descriptor, but these must be ignored. The order
requirements are as given earlier for a Path message, but the
above order is recommended.
PathTearメッセージは送付者記述子にSENDER_TSPECかADSPEC物を含むかもしれませんが、これらを無視しなければなりません。 Pathメッセージのために、より早く与えられるとしてオーダー要件がありますが、上記のオーダーはお勧めです。
Deletion of path state as the result of a PathTear message or a
timeout must also adjust related reservation state as required
to maintain consistency in the local node. The adjustment
depends upon the reservation style. For example, suppose a
PathTear deletes the path state for a sender S. If the style
specifies explicit sender selection (FF or SE), any reservation
with a filter spec matching S should be deleted; if the style
has wildcard sender selection (WF), the reservation should be
deleted if S is the last sender to the session. These
reservation changes should not trigger an immediate Resv
refresh message, since the PathTear message has already made
the required changes upstream. They should not trigger a
ResvErr message, since the result could be to generate a shower
of such messages.
また、PathTearメッセージかタイムアウトの結果が適応しなければならないので、経路州の削除はローカルのノードの一貫性を維持するために必要に応じて予約状態を関係づけました。 調整は予約スタイルに依存します。 例えば、PathTearが送付者S.Ifのために経路州を削除するなら、スタイルは明白な送付者選択(FFかSE)を指定して、フィルタ仕様がSに合っているどんな予約も削除されるべきです。 スタイルにワイルドカード送付者選択(WF)があるなら、予約はセッションまでSが最後の送付者であるなら削除されるべきです。 変化が即座のResvの引き金となるはずがないというこれらの条件はメッセージをリフレッシュします、必要な変更がPathTearメッセージで既に上流になったので。 それらは、結果がそのようなメッセージのシャワーを発生させることであることができたので、ResvErrメッセージの引き金となるべきではありません。
3.1.6 Resv Teardown Messages
3.1.6 Resv分解メッセージ
Receipt of a ResvTear (reservation teardown) message deletes
matching reservation state. Matching reservation state must
match the SESSION, STYLE, and FILTER_SPEC objects as well as
the LIH in the RSVP_HOP object. If there is no matching
reservation state, a ResvTear message should be discarded. A
ResvTear message may tear down any subset of the filter specs
in FF-style or SE-style reservation state.
ResvTear(予約分解)メッセージの領収書は合っている予約状態を削除します。 合っている予約州はSESSION、様式、およびRSVP_HOP物のLIHと同様にFILTER_SPEC物に合わなければなりません。 合っている予約状態が全くなければ、ResvTearメッセージは捨てられるべきです。 ResvTearメッセージはFF-スタイルかSE-スタイル予約状態でフィルタ仕様のどんな部分集合も取りこわすかもしれません。
ResvTear messages are initiated explicitly by receivers or by
any node in which reservation state has timed out, and they
travel upstream towards all matching senders.
ResvTearメッセージは受信機の近く、または、予約状態が外で時間があるどんなノードでも明らかに開始されます、そして、それらは上流へすべての合っている送付者に向かって旅行します。
Braden, Ed., et. al. Standards Track [Page 42] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[42ページ]。
A ResvTear message must be routed like the corresponding Resv
message, and its IP destination address will be the unicast
address of a previous hop.
対応するResvメッセージのようにResvTearメッセージを発送しなければなりません、そして、受信者IPアドレスは前のホップのユニキャストアドレスになるでしょう。
<ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<ResvTearメッセージ>:、:= <の一般的なヘッダー>。[<保全>]
<SESSION> <RSVP_HOP>
<セッション><RSVP_ホップ>。
[ <SCOPE> ] <STYLE>
[<範囲>] <スタイル>。
<flow descriptor list>
<流れ記述子リスト>。
<flow descriptor list> ::= (see earlier definition)
<流れ記述子リスト>:、:= (以前の定義を見ます)
FLOWSPEC objects in the flow descriptor list of a ResvTear
message will be ignored and may be omitted. The order
requirements for INTEGRITY object, sender descriptor, STYLE
object, and flow descriptor list are as given earlier for a
Resv message, but the above order is recommended. A ResvTear
message may include a SCOPE object, but it must be ignored.
ResvTearメッセージの流れ記述子リストのFLOWSPEC物は、無視されて、省略されるかもしれません。 Resvメッセージのために、より早く与えられるとしてINTEGRITY物、送付者記述子、様式物、および流れ記述子リストのためのオーダー要件がありますが、上記のオーダーはお勧めです。 ResvTearメッセージはSCOPE物を含むかもしれませんが、それを無視しなければなりません。
A ResvTear message will cease to be forwarded at the node where
merging would have suppressed forwarding of the corresponding
Resv message. Depending upon the resulting state change in a
node, receipt of a ResvTear message may cause a ResvTear
message to be forwarded, a modified Resv message to be
forwarded, or no message to be forwarded. These three cases
can be illustrated in the case of the FF-style reservations
shown in Figure 6.
ResvTearメッセージは、合併が対応するResvメッセージの推進を抑圧したノードで進められるのをやめるでしょう。 ノードにおける結果として起こる州の変化によって、進められるべき変更されたResvメッセージを引き起こしますが、ResvTearメッセージの領収書は進められるべきResvTearメッセージ、どんな進められるべきメッセージも引き起こさないかもしれません。 図6に示されたFF-スタイルの予約の場合でこれらの3つのケースを例証できます。
o If receiver R2 sends a ResvTear message for its
reservation S3{B}, the corresponding reservation is
removed from interface (d) and a ResvTear for S3{B} is
forwarded out (b).
o 受信機R2が予約S3BへのResvTearメッセージを送るなら、インタフェース(d)から対応する予約を移します、そして、S3BのためのResvTearに出かけている(b)を送ります。
o If receiver R1 sends a ResvTear for its reservation
S1{4B}, the corresponding reservation is removed from
interface (c) and a modified Resv message FF( S1{3B} ) is
immediately forwarded out (a).
o 受信機R1が予約S1 4BのためにResvTearを送るなら、インタフェース(c)とすぐにFF(S1 3B)に出かけている(a)を送るという変更されたResvメッセージから対応する予約を取り除きます。
o If receiver R3 sends a ResvTear message for S1{B}, there
is no change in the effective reservation S1{3B} on (d)
and no message is forwarded.
o 受信機R3がS1BへのResvTearメッセージを送るなら、(d)の有効な予約S1 3Bにおける変化が全くありません、そして、メッセージを全く転送しません。
Braden, Ed., et. al. Standards Track [Page 43] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[43ページ]。
3.1.7 Path Error Messages
3.1.7 経路エラーメッセージ
PathErr (path error) messages report errors in processing Path
messages. They are travel upstream towards senders and are
routed hop-by-hop using the path state. At each hop, the IP
destination address is the unicast address of a previous hop.
PathErr messages do not modify the state of any node through
which they pass; they are only reported to the sender
application.
PathErr(経路誤り)メッセージは処理Pathメッセージにおける誤りを報告します。 それらは、経路州を使用することで上流へ送付者に向かった旅行であり、ホップごとに発送されます。 各ホップでは、受信者IPアドレスは前のホップのユニキャストアドレスです。 PathErrメッセージはそれらが通るどんなノードの事情も変更しません。 それらは送付者アプリケーションに報告されるだけです。
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<PathErrメッセージ>:、:= <の一般的なヘッダー>。[<保全>]
<SESSION> <ERROR_SPEC>
<セッション><誤り_仕様>。
[ <POLICY_DATA> ...]
[<方針_データ>]
[ <sender descriptor> ]
[<送付者記述子>]
<sender descriptor> ::= (see earlier definition)
<送付者記述子>:、:= (以前の定義を見ます)
The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). One or more POLICY_DATA objects may be included
message to provide relevant information. The sender descriptor
is copied from the message in error. The object order
requirements are as given earlier for a Path message, but the
above order is recommended.
ERROR_SPEC物は、誤りを指定して、誤り(誤りNode Address)を検出したノードのIPアドレスを含んでいます。 あるPOLICY_DATA物が関連情報を提供する含まれているメッセージであるかもしれません。 送付者記述子はメッセージから間違ってコピーされます。 Pathメッセージのために、より早く与えられるとして物のオーダー要件がありますが、上記のオーダーはお勧めです。
3.1.8 Resv Error Messages
3.1.8 Resvエラーメッセージ
ResvErr (reservation error) messages report errors in
processing Resv messages, or they may report the spontaneous
disruption of a reservation, e.g., by administrative
preemption.
ResvErr(予約誤り)メッセージが処理Resvメッセージにおける誤りを報告するか、または彼らは予約の自然発生的な分裂を報告するかもしれません、例えば、管理先取りで。
ResvErr messages travel downstream towards the appropriate
receivers, routed hop-by-hop using the reservation state. At
each hop, the IP destination address is the unicast address of
a next-hop node.
ResvErrメッセージは適切な受信機、ホップごとの発送された使用に向かって予約状態を川下に旅行します。 各ホップでは、受信者IPアドレスは次のホップノードのユニキャストアドレスです。
Braden, Ed., et. al. Standards Track [Page 44] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[44ページ]。
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<ResvErrメッセージ>:、:= <の一般的なヘッダー>。[<保全>]
<SESSION> <RSVP_HOP>
<セッション><RSVP_ホップ>。
<ERROR_SPEC> [ <SCOPE> ]
<誤り_仕様>。[<範囲>]
[ <POLICY_DATA> ...]
[<方針_データ>]
<STYLE> [ <error flow descriptor> ]
<スタイル>。[<誤り流れ記述子>]
The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). One or more POLICY_DATA objects may be included in
an error message to provide relevant information (e.g.,, when a
policy control error is being reported). The RSVP_HOP object
contains the previous hop address, and the STYLE object is
copied from the Resv message in error. The use of the SCOPE
object in a ResvErr message is defined below in Section 3.4.
The object order requirements are as given for Resv messages,
but the above order is recommended.
ERROR_SPEC物は、誤りを指定して、誤り(誤りNode Address)を検出したノードのIPアドレスを含んでいます。 あるPOLICY_DATA物が、関連情報を提供するためにエラーメッセージに含まれるかもしれません(方針コントロール誤りが例えば報告されているとき)。 RSVP_HOP物は前のホップアドレスを含んでいます、そして、様式物はResvメッセージから間違ってコピーされます。 ResvErrメッセージにおけるSCOPE物の使用は以下でセクション3.4で定義されます。 物のオーダー要件がResvメッセージのために与えるようにありますが、上記のオーダーはお勧めです。
The following style-dependent rules define the composition of a
valid error flow descriptor; the object order requirements are
as given earlier for flow descriptor.
以下のスタイル依存する規則は有効な誤り流れ記述子の構成を定義します。 流れ記述子のために、より早く与えられるとして物のオーダー要件があります。
o WF Style:
o WF様式:
<error flow descriptor> ::= <WF flow descriptor>
<誤り流れ記述子>:、:= <WF流れ記述子>。
o FF style:
o FFスタイル:
<error flow descriptor> ::= <FF flow descriptor>
<誤り流れ記述子>:、:= <FF流れ記述子>。
Each flow descriptor in a FF-style Resv message must be
processed independently, and a separate ResvErr message
must be generated for each one that is in error.
独自にFF-スタイルResvメッセージのそれぞれの流れ記述子を処理しなければなりません、そして、別々のResvErrメッセージは間違ったそれぞれのために発生しなければなりません。
o SE style:
o SEスタイル:
<error flow descriptor> ::= <SE flow descriptor>
<誤り流れ記述子>:、:= <SE流れ記述子>。
An SE-style ResvErr message may list the subset of the
filter specs in the corresponding Resv message to which
the error applies.
SE-スタイルResvErrメッセージは誤りが適用される対応するResvメッセージのフィルタ仕様の部分集合を記載するかもしれません。
Braden, Ed., et. al. Standards Track [Page 45] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[45ページ]。
Note that a ResvErr message contains only one flow descriptor.
Therefore, a Resv message that contains N > 1 flow descriptors
(FF style) may create up to N separate ResvErr messages.
ResvErrメッセージが1つの流れ記述子だけを含むことに注意してください。 したがって、N>1流れ記述子(FFスタイル)を含むResvメッセージは最大N別々のResvErrメッセージを作成するかもしれません。
Generally speaking, a ResvErr message should be forwarded
towards all receivers that may have caused the error being
reported. More specifically:
概して、報告される誤りを引き起こしたかもしれないすべての受信機に向かってResvErrメッセージを転送するべきです。 より明確に:
o The node that detects an error in a reservation request
sends a ResvErr message to the next hop node from which
the erroneous reservation came.
o 予約の要請が誤った予約が来た次のホップノードへのResvErrメッセージを送るそれが誤りを検出するノード。
This ResvErr message must contain the information required
to define the error and to route the error message in
later hops. It therefore includes an ERROR_SPEC object, a
copy of the STYLE object, and the appropriate error flow
descriptor. If the error is an admission control failure
while attempting to increase an existing reservation, then
the existing reservation must be left in place and the
InPlace flag bit must be on in the ERROR_SPEC of the
ResvErr message.
このResvErrメッセージは誤りを定義して、後のホップでエラーメッセージを発送するのに必要である情報を含まなければなりません。 したがって、それはERROR_SPEC物、様式物のコピー、および適切な誤り流れ記述子を含んでいます。 既存の予約を増加させるのを試みている間、誤りが入場コントロール失敗であるなら、既存の予約は適所から外されなければなりません、そして、InPlaceフラグビットはResvErrメッセージのERROR_SPECでオンであるに違いありません。
o Succeeding nodes forward the ResvErr message to next hops
that have local reservation state. For reservations with
wildcard scope, there is an additional limitation on
forwarding ResvErr messages, to avoid loops; see Section
3.4. There is also a rule restricting the forwarding of a
Resv message after an Admission Control failure; see
Section 3.5.
o 続くノードは地方の予約状態を持っている次のホップにResvErrメッセージを転送します。 ワイルドカード範囲による予約のために、輪を避けるためにメッセージをResvErrに転送するときの追加制限があります。 セクション3.4を見てください。 また、Admission Controlの故障の後にResvメッセージの推進を制限する規則があります。 セクション3.5を見てください。
A ResvErr message that is forwarded should carry the
FILTER_SPEC(s) from the corresponding reservation state.
転送されるResvErrメッセージは対応する予約状態からFILTER_SPEC(s)を運ぶべきです。
o When a ResvErr message reaches a receiver, the STYLE
object, flow descriptor list, and ERROR_SPEC object
(including its flags) should be delivered to the receiver
application.
o ResvErrメッセージが受信機に達するとき、様式物、流れ記述子リスト、およびERROR_SPEC物(旗を含んでいる)を受信側アプリケーションに届けるべきです。
3.1.9 Confirmation Messages
3.1.9 確認メッセージ
ResvConf messages are sent to (probabilistically) acknowledge
reservation requests. A ResvConf message is sent as the result
of the appearance of a RESV_CONFIRM object in a Resv message.
(probabilisticallyに)予約の要請を承認するためにResvConfメッセージを送ります。 Resvメッセージにおける、RESV_CONFIRM物の外観の結果としてResvConfメッセージを送ります。
Braden, Ed., et. al. Standards Track [Page 46] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[46ページ]。
A ResvConf message is sent to the unicast address of a receiver
host; the address is obtained from the RESV_CONFIRM object.
However, a ResvConf message is forwarded to the receiver hop-
by-hop, to accommodate the hop-by-hop integrity check
mechanism.
受信ホストのユニキャストアドレスにResvConfメッセージを送ります。 RESV_CONFIRM物からアドレスを得ます。 しかしながら、ホップでResvConfメッセージを受信機ホップに転送して、ホップごとの保全チェックメカニズムに対応します。
<ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
<ResvConfメッセージ>:、:= <の一般的なヘッダー>。[<保全>]
<SESSION> <ERROR_SPEC>
<セッション><誤り_仕様>。
<RESV_CONFIRM>
<RESV_は>を確認します。
<STYLE> <flow descriptor list>
<様式><流れ記述子リスト>。
<flow descriptor list> ::= (see earlier definition)
<流れ記述子リスト>:、:= (以前の定義を見ます)
The object order requirements are the same as those given
earlier for a Resv message, but the above order is recommended.
Resvメッセージに、物のオーダー要件は、より早く与えられたものと同じですが、上記のオーダーはお勧めです。
The RESV_CONFIRM object is a copy of that object in the Resv
message that triggered the confirmation. The ERROR_SPEC is
used only to carry the IP address of the originating node, in
the Error Node Address; the Error Code and Value are zero to
indicate a confirmation. The flow descriptor list specifies
the particular reservations that are being confirmed; it may be
a subset of flow descriptor list of the Resv that requested the
confirmation.
RESV_CONFIRM物は確認の引き金となったResvメッセージのその物のコピーです。 ERROR_SPECは使用されますが、Error Node Addressの由来しているノードのIPアドレスを運びます。 Error CodeとValueは確認を示すゼロです。 流れ記述子リストは確認されている特定の予約を指定します。 それは確認を要求したResvの流れ記述子リストの部分集合であるかもしれません。
3.2 Port Usage
3.2 ポート用法
An RSVP session is normally defined by the triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port
field (i.e., a 16-bit quantity carried at octet offset +2 in the
transport header). DstPort may be omitted (set to zero) if the
ProtocolId specifies a protocol that does not have a destination
port field in the format used by UDP and TCP.
通常、RSVPセッションは三重によって定義されます: (DestAddress、ProtocolId、DstPort。) ここで、DstPortはUDP/TCP仕向港分野(すなわち、16ビットの量は輸送ヘッダーで八重奏オフセット+2で運ばれた)です。 ProtocolIdがUDPとTCPが形式の仕向港分野を使用しないプロトコルを指定するなら、DstPortは省略されるかもしれません(ゼロに設定します)。
RSVP allows any value for ProtocolId. However, end-system
implementations of RSVP may know about certain values for this
field, and in particular the values for UDP and TCP (17 and 6,
respectively). An end system may give an error to an application
that either:
RSVPはProtocolIdのためのどんな値も許容します。 しかしながら、RSVPの終わりシステムの実現はこの分野、および特に値でUDPとTCP(それぞれ17と6)で、ある値に関して知るかもしれません。 エンドシステムは誤りをアプリケーションに与えそんなにのどちらかであるかもしれません:
o specifies a non-zero DstPort for a protocol that does not
have UDP/TCP-like ports, or
o またはUDP/TCPのようなポートを持っていないプロトコルに非ゼロDstPortを指定する。
Braden, Ed., et. al. Standards Track [Page 47] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[47ページ]。
o specifies a zero DstPort for a protocol that does have
UDP/TCP-like ports.
o UDP/TCPのようなポートを持っているプロトコルにDstPortを全く指定しません。
Filter specs and sender templates specify the pair: (SrcAddress,
SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
16-bit quantity carried at octet offset +0 in the transport
header). SrcPort may be omitted (set to zero) in certain cases.
フィルタ仕様と送付者テンプレートは組を指定します: (SrcAddress、SrcPort), SrcPortがUDP/TCPソース港であるところでは、(すなわち、輸送ヘッダーで八重奏オフセット+0で運ばれた16ビットの量)をさばいてください。 ある場合には、SrcPortは省略されるかもしれません(ゼロに設定します)。
The following rules hold for the use of zero DstPort and/or
SrcPort fields in RSVP.
以下の規則はRSVPにおけるDstPort、そして/または、SrcPort分野の全くいずれの使用にも当てはまりません。
1. Destination ports must be consistent.
1. 仕向港は一貫しているに違いありません。
Path state and reservation state for the same DestAddress and
ProtocolId must each have DstPort values that are all zero or
all non-zero. Violation of this condition in a node is a
"Conflicting Dest Ports" error.
同じDestAddressとProtocolIdのための経路州と予約州には、それぞれすべてゼロであるDstPort値かすべての非ゼロがなければなりません。 ノードにおける、この状態の違反は「Destが移植する闘争」誤りです。
2. Destination ports rule.
2. 仕向港は統治されます。
If DstPort in a session definition is zero, all SrcPort
fields used for that session must also be zero. The
assumption here is that the protocol does not have UDP/TCP-
like ports. Violation of this condition in a node is a "Bad
Src Ports" error.
また、セッション定義におけるDstPortがゼロであるなら、そのセッションに使用されるすべてのSrcPort分野がゼロであるに違いありません。 プロトコルにはUDP/TCPがポートのようにないという仮定がここにあります。 ノードにおける、この状態の違反は「悪いSrcポート」誤りです。
3. Source Ports must be consistent.
3. ソースPortsは一貫しているに違いありません。
A sender host must not send path state both with and without
a zero SrcPort. Violation of this condition is a
"Conflicting Sender Port" error.
送付者ホストは両方にSrcPortでないことのあるなしにかかわらず経路州に行かせてはいけません。 この状態の違反は「闘争している送付者ポート」誤りです。
Note that RSVP has no "wildcard" ports, i.e., a zero port cannot
match a non-zero port.
RSVPには「ワイルドカード」ポートが全くないことに注意してください、そして、すなわち、aゼロポートは非ゼロポートに合うことができません。
3.3 Sending RSVP Messages
3.3 送付RSVPメッセージ
RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are
also intended to be used between an end system and the first/last
hop router, although it is also possible to encapsulate RSVP
messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation is needed for systems
that cannot do raw network I/O.
プロトコル番号46と共にRSVPできるルータの間の「生」としてのホップごとのIPデータグラムをRSVPメッセージに送ります。 また、エンドシステムと最後の最初/のホップルータの間で生のIPデータグラムが使用されることを意図します、また、終わりシステム・コミュニケーションのためのUDPデータグラムとしてRSVPメッセージを要約するのも可能ですがC. UDPカプセル化がAppendixで説明されるように生のネットワーク入出力ができないシステムに必要です。
Braden, Ed., et. al. Standards Track [Page 48] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[48ページ]。
Path, PathTear, and ResvConf messages must be sent with the Router
Alert IP option [RFC 2113] in their IP headers. This option may
be used in the fast forwarding path of a high-speed router to
detect datagrams that require special processing.
Router Alert IPオプション[RFC2113]と共に彼らのIPヘッダーで経路、PathTear、およびResvConfメッセージを送らなければなりません。 このオプションは、特別な処理を必要とするデータグラムを検出するのに高速ルータの速い推進経路で使用されるかもしれません。
Upon the arrival of an RSVP message M that changes the state, a
node must forward the state modification immediately. However,
this must not trigger sending a message out the interface through
which M arrived (which could happen if the implementation simply
triggered an immediate refresh of all state for the session).
This rule is necessary to prevent packet storms on broadcast LANs.
状態を変えるRSVPメッセージMの到着のときに、ノードはすぐに、州の変更を進めなければなりません。 しかしながら、これがMが到着したインタフェースから送付aメッセージの引き金となってはいけない、(単に引き起こされて、どれが実現であるなら起こるかもしれないか、即座である、セッションのためにすべての状態をリフレッシュしてください、) この規則が、放送LANでパケット嵐を防ぐのに必要です。
In this version of the spec, each RSVP message must occupy exactly
one IP datagram. If it exceeds the MTU, such a datagram will be
fragmented by IP and reassembled at the recipient node. This has
several consequences:
仕様のこのバージョンでは、それぞれのRSVPメッセージはちょうど1個のIPデータグラムを占領しなければなりません。 MTUを超えていると、そのようなデータグラムは、IPによって断片化されて、受取人ノードで組み立て直されるでしょう。 これには、いくつかの結果があります:
o A single RSVP message may not exceed the maximum IP datagram
size, approximately 64K bytes.
o ただ一つのRSVPメッセージは最大のIPをデータグラムサイズ、およそ64Kバイト超えないかもしれません。
o A congested non-RSVP cloud could lose individual message
fragments, and any lost fragment will lose the entire
message.
o 混雑している非RSVP雲は個々のメッセージ断片をなくす場合がありました、そして、どんな無くなっている断片も全体のメッセージを失うでしょう。
Future versions of the protocol will provide solutions for these
problems if they prove burdensome. The most likely direction will
be to perform "semantic fragmentation", i.e., break the path or
reservation state being transmitted into multiple self-contained
messages, each of an acceptable size.
重荷になると判明すると、プロトコルの将来のバージョンはこれらの問題の解決法を提供するでしょう。 「意味断片化」を最も実行しそうで、指示がことであるすなわち、複数の自己充足的なメッセージ(それぞれ許容できるサイズ)に伝えられる経路か予約状態を壊してください。
RSVP uses its periodic refresh mechanisms to recover from
occasional packet losses. Under network overload, however,
substantial losses of RSVP messages could cause a failure of
resource reservations. To control the queuing delay and dropping
of RSVP packets, routers should be configured to offer them a
preferred class of service. If RSVP packets experience noticeable
losses when crossing a congested non-RSVP cloud, a larger value
can be used for the timeout factor K (see section 3.7).
それは周期的です。RSVPが使用する、時々のパケット損失から回復するためにメカニズムをリフレッシュしてください。 しかしながら、ネットワークオーバーロードの下では、RSVPメッセージのかなりの損失が資源予約の失敗を引き起こす場合がありました。 列を作りを制御するために、延着してください。そうすれば、RSVPパケットを落として、ルータは都合のよいクラスのサービスをそれらに提供するために構成されるべきです。 混雑している非RSVP雲に交差するとき、RSVPパケットがめぼしい損失を経験するなら、タイムアウト要素Kにより大きい値を使用できます(セクション3.7を見てください)。
Some multicast routing protocols provide for "multicast tunnels",
which do IP encapsulation of multicast packets for transmission
through routers that do not have multicast capability. A
multicast tunnel looks like a logical outgoing interface that is
mapped into some physical interface. A multicast routing protocol
that supports tunnels will describe a route using a list of
logical rather than physical interfaces. RSVP can operate across
such multicast tunnels in the following manner:
いくつかのマルチキャストルーティング・プロトコルが「マルチキャストトンネル」に備えます。(それは、マルチキャスト能力を持っていないルータを通したトランスミッションのためにマルチキャストパケットのIPカプセル化をします)。 マルチキャストトンネルはいくらかの物理インターフェースに写像される論理的な外向的なインタフェースに似ています。 トンネルを支えるマルチキャストルーティング・プロトコルは、物理的であるというよりむしろ論理的なインタフェースのリストを使用することでルートを説明するでしょう。 RSVPはそのようなマルチキャストトンネルの向こう側に以下の方法で作動できます:
Braden, Ed., et. al. Standards Track [Page 49] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[49ページ]。
1. When a node N forwards a Path message out a logical outgoing
interface L, it includes in the message some encoding of the
identity of L, called the "logical interface handle" or LIH.
The LIH value is carried in the RSVP_HOP object.
1. ノードNが論理的な外向的なインタフェースLからPathメッセージを転送するとき、それはメッセージに「論理的なインタフェースハンドル」と呼ばれるLかLIHのアイデンティティのいくつかのコード化を含んでいます。 LIH値はRSVP_HOP物で運ばれます。
2. The next hop node N' stores the LIH value in its path state.
2. '次のホップノードN'は経路州にLIH値を格納します。
3. When N' sends a Resv message to N, it includes the LIH value
from the path state (again, in the RSVP_HOP object).
3. 'N'がResvメッセージをNに送るとき、それは経路州からのLIH値を含んでいます(RSVP_HOPでは、もう一度、反対してください)。
4. When the Resv message arrives at N, its LIH value provides
the information necessary to attach the reservation to the
appropriate logical interface. Note that N creates and
interprets the LIH; it is an opaque value to N'.
4. ResvメッセージがNに到着するとき、LIH値は、適切な論理的なインタフェースに予約を付けるために必要情報を提供します。 NがLIHを作成して、解釈することに注意してください。 'それはNへの不透明な値です'。
Note that this only solves the routing problem posed by tunnels.
The tunnel appears to RSVP as a non-RSVP cloud. To establish RSVP
reservations within the tunnel, additional machinery will be
required, to be defined in the future.
これがトンネルによって引き起こされたルーティング問題を解決するだけであることに注意してください。 トンネルは非RSVP雲としてRSVPにおいて現れます。 トンネルの中でRSVPの予約を証明するために、追加機械が将来定義されるのに必要でしょう。
3.4 Avoiding RSVP Message Loops
3.4 RSVPメッセージ輪を避けること。
Forwarding of RSVP messages must avoid looping. In steady state,
Path and Resv messages are forwarded on each hop only once per
refresh period. This avoids looping packets, but there is still
the possibility of an "auto-refresh" loop, clocked by the refresh
period. Such auto-refresh loops keep state active "forever", even
if the end nodes have ceased refreshing it, until the receivers
leave the multicast group and/or the senders stop sending Path
messages. On the other hand, error and teardown messages are
forwarded immediately and are therefore subject to direct looping.
RSVPメッセージの推進は、輪にするのを避けなければなりません。 中でメッセージが各ホップの上で一度だけ転送される状態、Path、およびResvを安定させる、期間をリフレッシュしてください。 これが、パケットを輪にするのを避けますが、可能性がまだある、「自動、リフレッシュ、」 時間を計られた輪、期間をリフレッシュしてください。 そのようなもの、自動、リフレッシュ、輪は「いつまでも」アクティブに状態を維持します、エンドノードが、それをリフレッシュするのをやめたとしても、受信機が、マルチキャストグループ、そして/または、送付者停止がメッセージをPathに送るのを出発するまで。 他方では、誤りと分解メッセージは、すぐに、転送されて、したがって、ループを指示するためになることがあります。
Consider each message type.
各メッセージがタイプであると考えてください。
o Path Messages
o 経路メッセージ
Path messages are forwarded in exactly the same way as IP
data packets. Therefore there should be no loops of Path
messages (except perhaps for transient routing loops, which
we ignore here), even in a topology with cycles.
まさにIPデータ・パケットと同じように経路メッセージを転送します。 したがって、Pathメッセージ(恐らく私たちがここで無視する一時的なルーティング輪を除いた)の輪が全くあるはずがありません、サイクルがあるトポロジーでさえ。
o PathTear Messages
o PathTearメッセージ
PathTear messages use the same routing as Path messages and
therefore cannot loop.
PathTearメッセージは、Pathメッセージと同じルーティングを使用して、したがって、輪にされることができません。
Braden, Ed., et. al. Standards Track [Page 50] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[50ページ]。
o PathErr Messages
o PathErrメッセージ
Since Path messages do not loop, they create path state
defining a loop-free reverse path to each sender. PathErr
messages are always directed to particular senders and
therefore cannot loop.
Pathメッセージが輪にされないので、それらは無輪の逆の経路を各送付者と定義する経路州を創設します。 PathErrメッセージは、いつも特定の送付者に向けられて、したがって、輪にされることができません。
o Resv Messages
o Resvメッセージ
Resv messages directed to particular senders (i.e., with
explicit sender selection) cannot loop. However, Resv
messages with wildcard sender selection (WF style) have a
potential for auto-refresh looping.
特定の送付者(すなわち、明白な送付者選択がある)に向けられたResvメッセージは輪にされることができません。 しかしながら、ワイルドカード送付者選択(WFスタイル)があるResvメッセージには可能性がある、自動、リフレッシュ、ループ。
o ResvTear Messages
o ResvTearメッセージ
Although ResvTear messages are routed the same as Resv
messages, during the second pass around a loop there will be
no state so any ResvTear message will be dropped. Hence
there is no looping problem here.
ResvTearメッセージはResvメッセージとして同じように発送されますが、2番目の間どんなResvTearメッセージも落とされるためにある輪の周りを状態を全く通り過ぎないでください。 したがって、ループ問題が全くここにありません。
o ResvErr Messages
o ResvErrメッセージ
ResvErr messages for WF style reservations may loop for
essentially the same reasons that Resv messages loop.
WFスタイルの予約へのResvErrメッセージは本質的には同じ理由でそのResvメッセージ輪を輪にするかもしれません。
o ResvConf Messages
o ResvConfメッセージ
ResvConf messages are forwarded towards a fixed unicast
receiver address and cannot loop.
ResvConfメッセージは、固定ユニキャスト受信機アドレスに向かって転送されて、輪にされることができません。
If the topology has no loops, then looping of Resv and ResvErr
messages with wildcard sender selection can be avoided by simply
enforcing the rule given earlier: state that is received through a
particular interface must never be forwarded out the same
interface. However, when the topology does have cycles, further
effort is needed to prevent auto-refresh loops of wildcard Resv
messages and fast loops of wildcard ResvErr messages. The
solution to this problem adopted by this protocol specification is
for such messages to carry an explicit sender address list in a
SCOPE object.
トポロジーに輪が全くないなら、単により早く与えられた規則を実施することによって、ワイルドカード送付者選択があるResvとResvErrメッセージのループを避けることができます: 特定のインタフェースを通して受け取られる状態は決して進めて、同じくらいが外に連結するということでないに違いありません。 しかしながら、防ぐ、トポロジーにサイクルがあるときのさらなる努力が必要である自動、リフレッシュ、ワイルドカードResvメッセージの輪とワイルドカードResvErrメッセージの速い輪。 このプロトコル仕様によって採用されたこの問題の解決はSCOPE物で明白な送付者住所録を運ぶそのようなメッセージのためのものです。
Braden, Ed., et. al. Standards Track [Page 51] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[51ページ]。
When a Resv message with WF style is to be forwarded to a
particular previous hop, a new SCOPE object is computed from the
SCOPE objects that were received in matching Resv messages. If
the computed SCOPE object is empty, the message is not forwarded
to the previous hop; otherwise, the message is sent containing the
new SCOPE object. The rules for computing a new SCOPE object for
a Resv message are as follows:
WFスタイルがあるResvメッセージが前の特定のホップに送ることであるときに、合っているResvメッセージに受け取られたSCOPE物から新しいSCOPE物を計算します。 計算されたSCOPE物が空であるなら、メッセージは前のホップに転送されません。 さもなければ、メッセージに新しいSCOPE物を含ませます。 Resvメッセージのために新しいSCOPE物を計算するための規則は以下の通りです:
1. The union is formed of the sets of sender IP addresses listed
in all SCOPE objects in the reservation state for the given
session.
1. 組合は与えられたセッションのために予約状態ですべてのSCOPE物に記載された送付者IPアドレスのセットについて形成されます。
If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included
in the union. For a message that arrived on outgoing
interface OI, the substitute list is the set of senders that
route to OI.
いくらかのNHOPからの予約状態がSCOPE物を含んでいないなら、組合に代わりの送付者リストを作成されて、含まなければなりません。 出発しているインタフェースOIで到着したメッセージに関しては、代わりのリストはそれがOIに発送する送付者のセットです。
2. Any local senders (i.e., any sender applications on this
node) are removed from this set.
2. どんな地元の送付者(このノードにおけるすなわちどんな送付者アプリケーションも)もこのセットから外されます。
3. If the SCOPE object is to be sent to PHOP, remove from the
set any senders that did not come from PHOP.
3. SCOPE目的がPHOPに送ることであるなら、セットから、PHOPから来なかったあらゆる送付者を外してください。
Figure 11 shows an example of wildcard-scoped (WF style) Resv
messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections
among the nodes, creating looping topology that is not shown.
図11はワイルドカードで見られた(WFスタイル)Resvメッセージに関する例を示しています。 SCOPE物の中の住所録は角括弧で見せられます。 示されないループトポロジーを作成して、ノードの中に追加接続があるかもしれないことに注意してください。
Braden, Ed., et. al. Standards Track [Page 52] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[52ページ]。
________________
a | | c
R4, S4<----->| Router |<-----> R2, S2, S3
| |
b | |
R1, S1<----->| |
|________________|
________________ a| | c R4、S4<。----->| ルータ| <、-、-、-、-->R2、S2、S3| | b| | R1、S1<。----->|、| |________________|
Send on (a): | Receive on (c):
|
<-- WF( [S4] ) | <-- WF( [S4, S1])
|
Send on (b): |
|
<-- WF( [S1] ) |
|
Receive on (a): | Send on (c):
|
WF( [S1,S2,S3]) --> | WF( [S2, S3]) -->
|
Receive on (b): |
|
WF( [S2,S3,S4]) --> |
|
(a)を転送してください: | (c)で受信してください: | <-- WF([S4])| <-- WF([S4、S1])| (b)を転送してください: | | <-- WF([S1])| | (a)で受信してください: | (c)を転送してください: | WF([S1、S2、S3])-->。| WF([S2、S3])-->。| (b)で受信してください: | | WF([S2、S3、S4])-->。| |
Figure 11: SCOPE Objects in Wildcard-Scope Reservations
図11: ワイルドカード範囲予約における範囲物
SCOPE objects are not necessary if the multicast routing uses
shared trees or if the reservation style has explicit sender
selection. Furthermore, attaching a SCOPE object to a reservation
should be deferred to a node which has more than one previous hop
for the reservation state.
マルチキャストルーティングが共有された木を使用するか、または予約スタイルに明白な送付者選択があるなら、SCOPE物は必要ではありません。 その上、SCOPE物を予約に取り付けるのは予約状態への前の1つ以上のホップを持っているノードに延期されるべきです。
The following rules are used for SCOPE objects in ResvErr messages
with WF style:
以下の規則はResvErrメッセージのSCOPE物にWFスタイルで使用されます:
1. The node that detected the error initiates an ResvErr message
containing a copy of the SCOPE object associated with the
reservation state or message in error.
1. 誤りを検出したノードは関連している間違った予約状態かメッセージでSCOPE物のコピーを含むResvErrメッセージを開始します。
2. Suppose a wildcard-style ResvErr message arrives at a node
with a SCOPE object containing the sender host address list
L. The node forwards the ResvErr message using the rules of
Section 3.1.8. However,
2. SCOPE物がセクション3.1.8の規則を使用することでノードがResvErrメッセージを転送する送付者ホスト住所録L.を含んでいてワイルドカードスタイルResvErrメッセージがノードに到着すると仮定してください。 しかしながら
Braden, Ed., et. al. Standards Track [Page 53] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[53ページ]。
the ResvErr message forwarded out OI must contain a SCOPE
object derived from L by including only those senders that
route to OI. If this SCOPE object is empty, the ResvErr
message should not be sent out OI.
進められた出ているOIがSCOPE物を含まなければならないというResvErrメッセージがLにそれらの送付者だけを含んでいるのによるそのルートにOIに由来していました。 このSCOPE物が空であるなら、出ているOIをResvErrメッセージに送るべきではありません。
3.5 Blockade State
3.5 封鎖州
The basic rule for creating a Resv refresh message is to merge the
flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from ResvErr messages, to
solve the KR-II problem (see Section 2.5). The blockade state
also enters into the routing of ResvErr messages for Admission
Control failure.
基本的な規則はResvを作成するとメッセージがリフレッシュするのでノードに適所にある予約の要請のflowspecsを合併することです、それらのLUBを計算することによって。 しかしながら、この規則は、KR-II問題を解決するためにResvErrメッセージから生じながら、「封鎖州」の存在によって変更されます(セクション2.5を見てください)。 また、封鎖州はAdmission Controlの故障へのResvErrメッセージのルーティングに入ります。
When a ResvErr message for an Admission Control failure is
received, its flowspec Qe is used to create or refresh an element
of local blockade state. Each element of blockade state consists
of a blockade flowspec Qb taken from the flowspec of the ResvErr
message, and an associated blockade timer Tb. When a blockade
timer expires, the corresponding blockade state is deleted.
Admission Controlの故障へのResvErrメッセージが受信されているとき、flowspec Qeは、地方の封鎖州の要素を作成するか、またはリフレッシュするのに使用されます。 封鎖州の各要素はResvErrメッセージのflowspec、および関連封鎖タイマTbから取られた封鎖flowspec Qbから成ります。 封鎖タイマが期限が切れるとき、対応する封鎖州は削除されます。
The granularity of blockade state depends upon the style of the
ResvErr message that created it. For an explicit style, there may
be a blockade state element (Qb(S),Tb(S)) for each sender S. For
a wildcard style, blockade state is per previous hop P.
封鎖州の粒状はそれを作成したResvErrメッセージのスタイルに依存します。 明白なスタイルのために、封鎖州の要素があるかもしれません。(Qb(S)、それぞれの送付者S.ForのためのTb(S))が前のホップP単位でありますワイルドカードスタイル、封鎖が、述べる。
An element of blockade state with flowspec Qb is said to
"blockade" a reservation with flowspec Qi if Qb is not (strictly)
greater than Qi. For example, suppose that the LUB of two
flowspecs is computed by taking the max of each of their
corresponding components. Then Qb blockades Qi if for some
component j, Qb[j] <= Qi[j].
Qbが杞より(厳密に)大きくないなら、flowspec Qbがある封鎖州の要素はflowspec杞との予約を「封鎖する」と言われます。 例えば、2flowspecsのLUBがそれぞれのそれらの対応するコンポーネントの最大を取ることによって計算されると仮定してください。 そして、何らかのコンポーネントj、Qb[j]<=杞[j]のためにQbは杞を封鎖します。
Suppose that a node receives a ResvErr message from previous hop P
(or, if style is explicit, sender S) as the result of an Admission
Control failure upstream. Then:
ノードがAdmission Control失敗上流の結果として前のホップP(スタイルが明白であり送付者S)からResvErrメッセージを受け取ると仮定してください。 その時:
1. An element of blockade state is created for P (or S) if it
did not exist.
1. 存在しなかったなら、封鎖州の要素はP(または、S)のために作成されます。
2. Qb(P) (or Qb(S)) is set equal to the flowspec Qe from the
ResvErr message.
2. または、Qb(P)、(Qb(S))はResvErrメッセージからのflowspec Qeと等しいセットです。
3. A corresponding blockade timer Tb(P) (or Tb(S)) is started or
restarted for a time Kb*R. Here Kb is a fixed multiplier and
R is the refresh interval for reservation state. Kb should
be configurable.
3. 対応はタイマTb(P)を封鎖します。(または、時間KB*R始動されたか、または再開されたTb(S))。 KBがここの、固定乗数であり、Rがそのような乗数である、予約状態に間隔をリフレッシュしてください。 KBは構成可能であるべきです。
Braden, Ed., et. al. Standards Track [Page 54] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[54ページ]。
4. If there is some local reservation state that is not
blockaded (see below), an immediate reservation refresh for P
(or S) is generated.
4. 地方であることの何かがあれば、封鎖されない(以下を見ます)状態、即座の予約がP(または、S)のためにリフレッシュするという条件は発生します。
5. The ResvErr message is forwarded to next hops in the
following way. If the InPlace bit is off, the ResvErr
message is forwarded to all next hops for which there is
reservation state. If the InPlace bit is on, the ResvErr
message is forwarded only to the next hops whose Qi is
blockaded by Qb.
5. 以下の方法でResvErrメッセージを次のホップに転送します。 InPlaceビットがオフであるなら、予約状態がある次のホップにResvErrメッセージを転送します。 InPlaceビットがオンであるなら、だれの次のホップ杞がQbによって封鎖されるだけであるかにResvErrメッセージを転送します。
Finally, we present the modified rule for merging flowspecs to
create a reservation refresh message.
最終的に、私たちは合併するための予約を作成するflowspecsがメッセージをリフレッシュするという変更された規則を提示します。
o If there are any local reservation requests Qi that are not
blockaded, these are merged by computing their LUB. The
blockaded reservations are ignored; this allows forwarding of
a smaller reservation that has not failed and may perhaps
succeed, after a larger reservation fails.
o 封鎖されないどんなローカルの予約の要請杞もいれば、これらは、それらのLUBを計算することによって、合併されています。 封鎖された予約は無視されます。 より大きい予約が失敗していなくて、恐らく成功するかもしれないより小さい予約失敗した後にこれは、進めるのを許容します。
o Otherwise (all local requests Qi are blockaded), they are
merged by taking the GLB (Greatest Lower Bound) of the Qi's.
o さもなければ(すべてのローカルの要求杞は封鎖される)、それらは、杞のGLB(最もすばらしいLower Bound)を取ることによって、合併されています。
(The use of some definition of "minimum" improves performance
by bracketing the failure level between the largest that
succeeds and the smallest that fails. The choice of GLB in
particular was made because it is simple to define and
implement, and no reason is known for using a different
definition of "minimum" here).
(「最小限」の何らかの定義の使用は成功する最も大きいものと失敗する最も小さいものの間の失敗レベルに腕木を付けるのによる性能を向上させます。 定義して、実行するのが簡単であるので、特にGLBの選択をしました、そして、ここで「最小限」の異なった定義を使用するので、理由を全く知っていません。).
This refresh merging algorithm is applied separately to each flow
(each sender or PHOP) contributing to a shared reservation (WF or
SE style).
これは、別々に共有された条件(WFかSEスタイル)に貢献しながら各流れ(各送付者かPHOP)に適用されたアルゴリズムを合併しながら、リフレッシュします。
Figure 12 shows an example of the the application of blockade
state for a shared reservation (WF style). There are two previous
hops labeled (a) and (b), and two next hops labeled (c) and (d).
The larger reservation 4B arrived from (c) first, but it failed
somewhere upstream via PHOP (a), but not via PHOP (b). The
figures show the final "steady state" after the smaller
reservation 2B subsequently arrived from (d). This steady state
is perturbed roughly every Kb*R seconds, when the blockade state
times out. The next refresh then sends 4B to previous hop (a);
presumably this will fail, sending a ResvErr message that will
re-establish the blockade state, returning to the situation shown
in the figure. At the same time, the ResvErr message will be
forwarded to next hop (c) and to all receivers downstream
responsible for the 4B reservations.
図12は共有された条件(WFスタイル)のために封鎖州のアプリケーションに関する例を示しています。 (a)と(b)とラベルされた、前の2つのホップ、および(c)と(d)とラベルされた次の2つのホップがあります。 より大きい予約4BはPHOP(a)を通して(c) しかし、1番目、それからどこかで失敗されていた状態で上流へ到着しましたが、PHOP(b)を通して到着したというわけではありません。 より小さい予約2Bが次に(d)から到着した後に数字は最終的な「定常状態」を示しています。 この定常状態はKB*毎におよそ混乱させられています。封鎖であることのR秒は外に回を述べます。 次はリフレッシュします。その時、前のホップ(a)への4Bは発信します。 おそらく、これは失敗するでしょう、封鎖州を復職させるResvErrメッセージを送って、図に示された状況に戻って。 同時に、次のホップ(c)と、そして、4Bの予約に原因となるすべての受信機川下にResvErrメッセージを転送するでしょう。
Braden, Ed., et. al. Standards Track [Page 55] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[55ページ]。
Send Blockade | Reserve Receive
State {Qb}|
| ________
(a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c)
| |________|
|
---------------------------|-------------------------------
|
| ________
(b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d)
| |________|
封鎖を送ってください。| 蓄えは州のQbを受けます。| | ________ (a) <。 WF(*2B)4B| | * 4B| WF(*4B)<(c)| |________| | ---------------------------|------------------------------- | | ________ (b) <。 WF(*4B)(なにも)| | * 2B| WF(*2B)<(d)| |________|
Figure 12: Blockading with Shared Style
図12: 共有された様式との封鎖
3.6 Local Repair
3.6 局部的修繕
When a route changes, the next Path or Resv refresh message will
establish path or reservation state (respectively) along the new
route. 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.
ルートが変化するとき、次のPathかResvが新しいルートに沿って意志が経路か予約状態を確立するというメッセージ(それぞれ)をリフレッシュします。 速い適合を提供するために、短いことのオーバーヘッドのないルーティング変化に、期間はリフレッシュしています、とローカルのルーティング・プロトコルモジュールはルート変化のRSVPの過程に特定の目的地に通知できます。 RSVPの過程は、これらの目的地に状態をリフレッシュして、新しいルートを使用することで迅速にaの引き金となるのにこの情報を使用するべきです。
The specific rules are as follows:
特定の規則は以下の通りです:
o When routing detects a change of the set of outgoing
interfaces for destination G, RSVP should update the path
state, wait for a short period W, and then send Path
refreshes for all sessions G/* (i.e., for any session with
destination G, regardless of destination port).
o ルーティングが変化を検出するとき、G、RSVPがそうするべきである目的地への外向的なインタフェースのセットでは、経路州、短期Wの間の待ち、およびその時がPathを送るアップデートはすべてのセッションG/*(すなわち、仕向港にかかわらず目的地Gとのどんなセッションのためのも)のためにリフレッシュします。
The short wait period before sending Path refreshes is to
allow the routing protocol to settle, and the value for W
should be chosen accordingly. Currently W = 2 sec is
suggested; however, this value should be configurable per
interface.
短い待ちの期間が送付Pathがリフレッシュする前にルーティング・プロトコルに決着をつけるのを許容することであり、Wのための値はそれに従って、選ばれるべきです。 現在の、2W=秒は示されます。 しかしながら、この値はインタフェース単位で構成可能であるべきです。
o When a Path message arrives with a Previous Hop address that
differs from the one stored in the path state, RSVP should
send immediate Resv refreshes to that PHOP.
o Pathメッセージが経路州に格納されたものと異なっているPrevious Hopアドレスと共に到着するとき、RSVPは即座のResvを送るはずです。そのPHOPにリフレッシュします。
Braden, Ed., et. al. Standards Track [Page 56] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[56ページ]。
3.7 Time Parameters
3.7 時間パラメタ
There are two time parameters relevant to each element of RSVP
path or reservation state in a node: the refresh period R between
generation of successive refreshes for the state by the neighbor
node, and the local state's lifetime L. Each RSVP Resv or Path
message may contain a TIME_VALUES object specifying the R value
that was used to generate this (refresh) message. This R value is
then used to determine the value for L when the state is received
and stored. The values for R and L may vary from hop to hop.
ノードでRSVP経路か予約状態の各要素に関連している2つの時間パラメタがあります: 間に連続することの世代が隣人ノードで状態にリフレッシュする期間R、および地方の状態の生涯L.Each RSVP Resvをリフレッシュしてください。さもないと、Pathメッセージはこの(リフレッシュします)メッセージを発生させるのに使用されたR値を指定するタイム誌_VALUES物を含むかもしれません。 そして、このR値は、状態が受け取られて、格納されるとき、Lのために値を決定するのに使用されます。 ホップによってRとLのための値は異なるかもしれません。
In more detail:
さらに詳細に:
1. Floyd and Jacobson [FJ94] have shown that periodic messages
generated by independent network nodes can become
synchronized. This can lead to disruption in network
services as the periodic messages contend with other network
traffic for link and forwarding resources. Since RSVP sends
periodic refresh messages, it must avoid message
synchronization and ensure that any synchronization that may
occur is not stable.
1. フロイドとジェーコブソン[FJ94]は、独立しているネットワーク・ノードで発生する周期的なメッセージが連動するようになることができるのを示しました。 周期的なメッセージがリンクと推進リソースのために他のネットワークトラフィックを競争するとき、これはネットワーク・サービスにおける分裂に通じることができます。 メッセージ同期を避けなければなりません、そして、RSVPが周期的に発信するので、メッセージをリフレッシュしてください、そして、起こるどんな同期も安定していないのを確実にしてください。
For this reason, the refresh timer should be randomly set to
a value in the range [0.5R, 1.5R].
タイマをリフレッシュしてください。この理由で手当たりしだいに範囲[0.5R、1.5R]の値へのであるべきです設定されて。
2. To avoid premature loss of state, L must satisfy L >= (K +
0.5)*1.5*R, where K is a small integer. Then in the worst
case, K-1 successive messages may be lost without state being
deleted. To compute a lifetime L for a collection of state
with different R values R0, R1, ..., replace R by max(Ri).
2. 状態の時期尚早な損失を避けるために、LはL>=(K+0.5)*1.5*Rを満たさなければなりません。そこでは、Kがわずかな整数です。 そして、最悪の場合には、K-1の連続したメッセージは削除される状態なしで失われるかもしれません。 計算するために、異なったRとの状態の収集のための寿命LはR0、R1を評価します…, Rを最大(Ri)に取り替えてください。
Currently K = 3 is suggested as the default. However, it may
be necessary to set a larger K value for hops with high loss
rate. K may be set either by manual configuration per
interface, or by some adaptive technique that has not yet
been specified.
現在の、K=3はデフォルトとして示されます。 しかしながら、高い損失率で、より大きいK値をホップに設定するのが必要であるかもしれません。 Kは1インタフェースあたりの手動の構成、またはまだ指定されていない何らかの適応型のテクニックで設定されるかもしれません。
3. Each Path or Resv message carries a TIME_VALUES object
containing the refresh time R used to generate refreshes.
The recipient node uses this R to determine the lifetime L of
the stored state created or refreshed by the message.
3. それぞれのPathかResvメッセージがタイム誌_VALUES物の含有を運ぶ、発生するのにおいて中古のRがリフレッシュする時をリフレッシュしてください。 受取人ノードは、メッセージによって創設されるか、またはリフレッシュされた格納された状態の生涯Lを決定するのにこのRを使用します。
4. The refresh time R is chosen locally by each node. If the
node does not implement local repair of reservations
disrupted by route changes, a smaller R speeds up adaptation
to routing changes, while increasing the RSVP overhead. With
local repair, a router can be more relaxed about R since the
periodic refresh becomes only a backstop robustness
4. Rが各ノードによって局所的に選ばれている時間をリフレッシュしてください。 ノードがルート変化で中断する予約の局部的修繕を実行しないなら、より小さいRはRSVPオーバーヘッドを上げている間、ルーティング変化への適合を早くします。 局部的修繕で、ルータはさらに弛緩して、周期的がリフレッシュするのでRがバックネット丈夫さだけになるということであるかもしれません。
Braden, Ed., et. al. Standards Track [Page 57] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[57ページ]。
mechanism. A node may therefore adjust the effective R
dynamically to control the amount of overhead due to refresh
messages.
メカニズム。 したがって、ノードは、メッセージをリフレッシュすることにおける支払い満期のオーバーヘッドの量を制御するようにダイナミックに有効なRを調整するかもしれません。
The current suggested default for R is 30 seconds. However,
the default value Rdef should be configurable per interface.
電流は、Rのためのデフォルトが30秒であると示唆しました。 しかしながら、デフォルト値Rdefはインタフェース単位で構成可能であるべきです。
5. When R is changed dynamically, there is a limit on how fast
it may increase. Specifically, the ratio of two successive
values R2/R1 must not exceed 1 + Slew.Max.
5. ダイナミックにRを変えるとき、どれくらい速く増加するかもしれないかに関して限界があります。 明確にR2/R1が1+Slew.Maxに超えてはいけない2つの連続した値の比率。
Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent
per refresh cycle.
現在、Slew.Maxは0.30です。 Kに、Rが1リフレッシュ・サイクルあたり30パーセントを増加させている間、=3、1パケットは州のタイムアウトなしで失われるかもしれません。
6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial
state establishment).
6. 丈夫さを改良するために、ノードが一時送るかもしれないaは州の変化の後のRよりしばしばリフレッシュします(初期状態設立を含んでいて)。
7. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may
lead to different values. The possibility of dynamically
adapting K and/or Slew.Max in response to measured loss rates
is for future study.
7. 実現に使用されるRdef、K、およびSlew.Maxの値はインタフェース単位で容易に修正できるべきです、経験が異価につながるとき。 今後の研究にはダイナミックに測定損失率に対応してK、そして/または、Slew.Maxを適合させる可能性があります。
3.8 Traffic Policing and Non-Integrated Service Hops
3.8 交通の取り締まっていて非統合しているサービスホップス
Some QoS services may require traffic policing at some or all of
(1) the edge of the network, (2) a merging point for data from
multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than the downstream reservation being
requested. RSVP knows where such points occur and must so
indicate to the traffic control mechanism. On the other hand,
RSVP does not interpret the service embodied in the flowspec and
therefore does not know whether policing will actually be applied
in any particular case.
いくつかのQoSサービスが(2) (1) ネットワークの縁、複数の送付者からのデータのための合併しているポイント、そして/または、(3)のいくつかかすべてで上流からの交通の流れが要求されている川下の予約よりすごいかもしれないブランチポイントを取り締まる交通を必要とするかもしれません。 そのようなポイントがどこに起こるかを知っているので、RSVPはメカニズムをトラフィックコントロールに示さなければなりません。 他方では、RSVPは、flowspecに表現されたサービスを解釈しないで、またしたがって、取り締まりが実際に何か特定の場合で適用されるかどうかを知りません。
The RSVP process passes to traffic control a separate policing
flag for each of these three situations.
RSVPの過程はそれぞれのこれらの3つの状況のために別々の取り締まり旗をトラフィックコントロールに渡します。
o E_Police_Flag -- Entry Policing
o 警察の_が旗を揚げさせるE_--エントリーの取り締まり
This flag is set in the first-hop RSVP node that implements
traffic control (and is therefore capable of policing).
この旗はトラフィックコントロール(そして、したがって、取り締まることができる)を実行する最初に、ホップRSVPノードに設定されます。
For example, sender hosts must implement RSVP but currently
many of them do not implement traffic control. In this case,
the E_Police_Flag should be off in the sender host, and it
例えば、送付者ホストはRSVPを実行しなければなりませんが、現在の彼らの多くがトラフィックコントロールを実行しません。 この場合、E_警察_Flagは送付者ホスト、およびそれでオフであるべきです。
Braden, Ed., et. al. Standards Track [Page 58] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[58ページ]。
should only be set on when the first node capable of traffic
control is reached. This is controlled by the E_Police flag
in SESSION objects.
トラフィックコントロールができる最初のノードに達している時セットだけであるべきです。 これはSESSION物でE_警察の旗で制御されます。
o M_Police_Flag -- Merge Policing
o M_警察の_は弛みます--取り締まりを合併してください。
This flag should be set on for a reservation using a shared
style (WF or SE) when flows from more than one sender are
being merged.
この旗は1人以上の送付者からの流れが合併されているとき共有されたスタイル(WFかSE)を使用する予約に、オンなセットであるべきです。
o B_Police_Flag -- Branch Policing
o 警察の_が旗を揚げさせるB_--支店の取り締まり
This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION.
インストールされるflowspecが、より小さい時この旗がセットであるべきである、比較にならないほどです、適所にあるa FLOWSPECはいかなる他のも連結します、同じFILTER_SPECとSESSIONのために。
RSVP must also test for the presence of non-RSVP hops in the path
and pass this information to traffic control. From this flag bit
that the RSVP process supplies and from its own local knowledge,
traffic control can detect the presence of a hop in the path that
is not capable of QoS control, and it passes this information to
the receivers in Adspecs [RFC 2210].
RSVPはまた、経路での非RSVPホップの存在がないかどうかテストして、この情報をトラフィックコントロールに通過しなければなりません。 RSVPの過程が提供するこのフラグビットとそれ自身の局所的知識から、トラフィックコントロールはQoSコントロールができない経路でのホップの存在を検出できます、そして、それはAdspecs[RFC2210]の受信機にこの情報を移ります。
With normal IP forwarding, RSVP can detect a non-RSVP hop by
comparing the IP TTL with which a Path message is sent to the TTL
with which it is received; for this purpose, the transmission TTL
is placed in the common header. However, the TTL is not always a
reliable indicator of non-RSVP hops, and other means must
sometimes be used. For example, if the routing protocol uses IP
encapsulating tunnels, then the routing protocol must inform RSVP
when non-RSVP hops are included. If no automatic mechanism will
work, manual configuration will be required.
通常のIP推進で、RSVPはPathメッセージがそれが受け取られているTTLに送られるIP TTLを比較することによって、非RSVPホップを検出できます。 このために、トランスミッションTTLは一般的なヘッダーに置かれます。 しかしながら、TTLはいつも非RSVPホップの高信頼のインディケータであるというわけではありません、そして、時々他の手段を使用しなければなりません。 例えば、ルーティング・プロトコルがトンネルを要約しながらIPを使用するなら、ルーティング・プロトコルは、非RSVPホップがいつ含まれているかをRSVPに知らせなければなりません。 機械的なメカニズムが全く動作しないと、手動の構成が必要でしょう。
3.9 Multihomed Hosts
3.9 Multihomedホスト
Accommodating multihomed hosts requires some special rules in
RSVP. We use the term `multihomed host' to cover both hosts (end
systems) with more than one network interface and routers that are
supporting local application programs.
「マルチ-家へ帰」っているホストを収容するのはRSVPのいくつかの特別な規則を必要とします。 私たちは1つ以上のネットワーク・インターフェースをもっているホスト(エンドシステム)と局所塗布プログラムをサポートしているルータの両方をカバーするために'ホストを「マルチ-家へ帰」った'という用語を使用します。
An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or
for receiving data packets, to override the system-specified
default interface. The RSVP process must be aware of the default,
and if an application sets a specific interface, it must also pass
that information to RSVP.
「マルチ-家へ帰」っているホストの上で実行されるアプリケーションは、何か与えられた流れが送付システムで指定されたデフォルトインタフェースをくつがえすためにデータ・パケットを受けるのにどのインタフェースを使用するかを明らかに指定するかもしれません。 RSVPの過程はデフォルトを意識しているに違いありません、そして、また、アプリケーションが特定のインタフェースを設定するなら、それはその情報をRSVPに通過しなければなりません。
Braden, Ed., et. al. Standards Track [Page 59] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[59ページ]。
o Sending Data
o 送付データ
A sender application uses an API call (SENDER in Section
3.11.1) to declare to RSVP the characteristics of the data
flow it will originate. This call may optionally include the
local IP address of the sender. If it is set by the
application, this parameter must be the interface address for
sending the data packets; otherwise, the system default
interface is implied.
送付者アプリケーションはそれが溯源するデータフローの特性をRSVPに宣言するというAPI要求(セクション3.11.1におけるSENDER)を使用します。 この呼び出しは任意にローカルアイピー送信者のアドレスを含むかもしれません。 それがアプリケーションで設定されるなら、このパラメタはデータ・パケットを送るためのインターフェース・アドレスでなければなりません。 さもなければ、システム・デフォルトインタフェースは含意されます。
The RSVP process on the host then sends Path messages for
this application out the specified interface (only).
そして、ホストのRSVPの過程はこのアプリケーションへのメッセージを指定されたインタフェース(単に)からPathに送ります。
o Making Reservations
o 予約をします。
A receiver application uses an API call (RESERVE in Section
3.11.1) to request a reservation from RSVP. This call may
optionally include the local IP address of the receiver,
i.e., the interface address for receiving data packets. In
the case of multicast sessions, this is the interface on
which the group has been joined. If the parameter is
omitted, the system default interface is used.
受信側アプリケーションはRSVPから予約を要求するというAPI要求(セクション3.11.1におけるRESERVE)を使用します。 この呼び出しは任意に受信機のローカルアイピーアドレス、データ・パケットを受けるためのすなわち、インターフェース・アドレスを含むかもしれません。 マルチキャストセッションの場合では、これはグループが加わられたインタフェースです。 パラメタが省略されるなら、システム・デフォルトインタフェースは使用されています。
In general, the RSVP process should send Resv messages for an
application out the specified interface. However, when the
application is executing on a router and the session is
multicast, a more complex situation arises. Suppose in this
case that a receiver application joins the group on an
interface Iapp that differs from Isp, the shortest-path
interface to the sender. Then there are two possible ways
for multicast routing to deliver data packets to the
application. The RSVP process must determine which case
holds by examining the path state, to decide which incoming
interface to use for sending Resv messages.
一般に、RSVPの過程はアプリケーションへのメッセージを指定されたインタフェースからResvに送るべきです。 しかしながら、アプリケーションがルータでの実行であり、セッションがマルチキャストであるときに、より複雑な状況は起こります。 この場合、受信側アプリケーションがIsp(送付者への最短パスインタフェース)と異なっているインタフェースIappに関するグループに加わると仮定してください。 そして、2つの可能な方法で、送るマルチキャストルーティングのために、アプリケーションへのデータ・パケットがあります。 RSVPの過程は、送付Resvメッセージにどの入って来るインタフェースを使用したらよいかを決めるために経路州を調べることによってどのケースが持ちこたえるかを決定しなければなりません。
1. The multicast routing protocol may create a separate
branch of the multicast distribution `tree' to deliver
to Iapp. In this case, there will be path state for
both interfaces Isp and Iapp. The path state on Iapp
should only match a reservation from the local
application; it must be marked "Local_only" by the RSVP
process. If "Local_only" path state for Iapp exists,
the Resv message should be sent out Iapp.
1. マルチキャストルーティング・プロトコルは、Iappに配送するためにマルチキャスト分配'木'の別々のブランチを創設するかもしれません。 この場合、両方のインタフェースのIspとIappへの経路州があるでしょう。 Iappの上の経路州は局所塗布から予約に合っているだけであるべきです。 「地方の_専用」であるとRSVP工程でそれをマークしなければなりません。 Iappのための「地方の_専用」経路州が存在しているなら、出ているIappをResvメッセージに送るべきです。
Note that it is possible for the path state blocks for
Isp and Iapp to have the same next hop, if there is an
intervening non-RSVP cloud.
経路に、IspとIappが同じように次にする州のブロックが跳ぶのが、可能であることに注意してください、介入している非RSVP雲があれば。
Braden, Ed., et. al. Standards Track [Page 60] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[60ページ]。
2. The multicast routing protocol may forward data within
the router from Isp to Iapp. In this case, Iapp will
appear in the list of outgoing interfaces of the path
state for Isp, and the Resv message should be sent out
Isp.
2. マルチキャストルーティング・プロトコルはルータの中でIspからIappまでデータを転送するかもしれません。 この場合、Iappは経路州の外向的なインタフェースのリストにIspに関して現れるでしょう、そして、出ているIspをResvメッセージに送るべきです。
3. When Path and PathTear messages are forwarded, path
state marked "Local_Only" must be ignored.
3. PathとPathTearメッセージを転送するとき、「地方の_専用」であるとマークされた経路州を無視しなければなりません。
3.10 Future Compatibility
3.10 将来の互換性
We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new object
classes will be defined. It will be desirable to employ such new
objects within the Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are as
follows (`b' represents a bit).
私たちは、将来の新しい物のC-タイプのそれが既存の物のクラスのために定義されると予想するかもしれません、そして、恐らく、新しい物のクラスは定義されるでしょう。 それらを認識しないより古い実現を使用するインターネットの中でそのような新しい物を使うのは望ましいでしょう。 残念ながら、これは妥当な複雑さに従った限られた度だけ可能です。 規則は以下の通りです('b'はしばらくを表します)。
1. Unknown Class
1. 未知のクラス
There are three possible ways that an RSVP implementation can
treat an object with unknown class. This choice is
determined by the two high-order bits of the Class-Num octet,
as follows.
3つの可能な方法があります。RSVP実現は未知のクラスと共に物を扱うことができます。 以下のClass-ヌムの八重奏の2高位のビットに従って、この選択は決定しています。
o Class-Num = 0bbbbbbb
o クラスヌムは0bbbbbbbと等しいです。
The entire message should be rejected and an "Unknown
Object Class" error returned.
全体のメッセージは拒絶されるべきでした、そして、「未知の物のクラス」誤りは戻りました。
o Class-Num = 10bbbbbb
o クラスヌムは10bbbbbbと等しいです。
The node should ignore the object, neither forwarding it
nor sending an error message.
どちらもそれを進めないで、エラーメッセージを送って、ノードは物を無視するはずです。
o Class-Num = 11bbbbbb
o クラスヌムは11bbbbbbと等しいです。
The node should ignore the object but forward it,
unexamined and unmodified, in all messages resulting
from this message.
ノードは、このメッセージから生じながら、物を無視しますが、すべてのメッセージで非審査されて変更されていないそれを進めるはずです。
The following more detailed rules hold for unknown-class
objects with a Class-Num of the form 11bbbbbb:
以下の、より詳細な規則は未知のクラス物のためにフォーム11bbbbbbのClass-ヌムと共に成立します:
1. Such unknown-class objects received in PathTear,
ResvTear, PathErr, or ResvErr messages should be
forwarded immediately in the same messages.
1. すぐ同じメッセージでPathTear、ResvTear、PathErr、またはResvErrメッセージに受け取られたそのような未知のクラス物を進めるべきです。
Braden, Ed., et. al. Standards Track [Page 61] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[61ページ]。
2. Such unknown-class objects received in Path or Resv
messages should be saved with the corresponding state
and forwarded in any refresh message resulting from that
state.
2. メッセージが対応する状態と共に保存されて、いずれでも転送されるべきであるPathかResvに受け取られたそのような未知のクラス物はその状態から生じるメッセージをリフレッシュします。
3. When a Resv refresh is generated by merging multiple
reservation requests, the refresh message should include
the union of unknown-class objects from the component
requests. Only one copy of each unique unknown-class
object should be included in this union.
3. メッセージをリフレッシュしてください。a Resvがいつリフレッシュするかが複数の予約の要請を合併することによって発生する、コンポーネント要求からの未知のクラス物の組合を含むべきです。 それぞれのユニークな未知のクラス物のコピー1部だけがこの組合に含まれるべきです。
4. The original order of such unknown-class objects need
not be retained; however, the message that is forwarded
must obey the general order requirements for its message
type.
4. そのような未知のクラス物に関する最初の注文は保有される必要はありません。 しかしながら、転送されるメッセージはメッセージタイプのための一般的なオーダー要件に従わなければなりません。
Although objects with unknown class cannot be merged, these
rules will forward such objects until they reach a node that
knows how to merge them. Forwarding objects with unknown
class enables incremental deployment of new objects; however,
the scaling limitations of doing so must be carefully
examined before a new object class is deployed with both high
bits on.
未知のクラスがある物を合併できませんが、それらを合併する方法を知っているノードに達するまで、これらの規則はそのような物を進めるでしょう。 未知のクラスがある物を進めると、新しい物の増加の展開は可能にされます。 しかしながら、ともに高いビットがオンな状態で新しい物のクラスが配備される前に慎重にそうするスケーリング制限を調べなければなりません。
2. Unknown C-Type for Known Class
2. 知られているクラスのための未知のC-タイプ
One might expect the known Class-Num to provide information
that could allow intelligent handling of such an object.
However, in practice such class-dependent handling is
complex, and in many cases it is not useful.
人は、知られているClass-ヌムがそのような物の知的な取り扱いを許すことができた情報を提供すると予想するかもしれません。 しかしながら、実際には、そのようなクラス依存する取り扱いは複雑です、そして、多くの場合、それは役に立ちません。
Generally, the appearance of an object with unknown C-Type
should result in rejection of the entire message and
generation of an error message (ResvErr or PathErr as
appropriate). The error message will include the Class-Num
and C-Type that failed (see Appendix B); the end system that
originated the failed message may be able to use this
information to retry the request using a different C-Type
object, repeating this process until it runs out of
alternatives or succeeds.
一般に、未知のC-タイプがある物の外観はエラーメッセージの全体のメッセージと世代(適切な同じくらいResvErrか同じくらいPathErr)の拒絶をもたらすべきです。 エラーメッセージは失敗したClass-ヌムとC-タイプを含むでしょう(Appendix Bを見てください)。 失敗したメッセージを溯源したエンドシステムは異なったC-タイプ物を使用することで要求を再試行するのにこの情報を使用できるかもしれません、代替手段を使い果たすか、または成功するまでこの過程を繰り返して。
Objects of certain classes (FLOWSPEC, ADSPEC, and
POLICY_DATA) are opaque to RSVP, which simply hands them to
traffic control or policy modules. Depending upon its
internal rules, either of the latter modules may reject a C-
Type and inform the RSVP process; RSVP should then reject the
message and send an error, as described in the previous
paragraph.
あるクラス(FLOWSPEC、ADSPEC、およびPOLICY_DATA)の物はRSVPに不明瞭です。(単に、RSVPはトラフィックコントロールか方針モジュールにそれらを手渡します)。 社内規定によって、後者のモジュールのどちらかが、Cタイプを拒絶して、RSVPの過程を知らせるかもしれません。 RSVPは前のパラグラフで説明されるように次に、メッセージを拒絶して、誤りを送るはずです。
Braden, Ed., et. al. Standards Track [Page 62] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[62ページ]。
3.11 RSVP Interfaces
3.11 RSVPインタフェース
RSVP on a router has interfaces to routing and to traffic control.
RSVP on a host has an interface to applications (i.e, an API) and
also an interface to traffic control (if it exists on the host).
ルータのRSVPはルーティングと、そして、トラフィックコントロールにインタフェースを持っています。 ホストの上のRSVPはアプリケーション(i.e、API)へのインタフェースとインタフェースもトラフィックコントロールに持っています(ホストの上に存在しているなら)。
3.11.1 Application/RSVP Interface
3.11.1 アプリケーション/RSVPは連結します。
This section describes a generic interface between an
application and an RSVP control process. The details of a real
interface may be operating-system dependent; the following can
only suggest the basic functions to be performed. Some of
these calls cause information to be returned asynchronously.
このセクションはアプリケーションとRSVPコントロールの過程との一般的なインタフェースについて説明します。 本当のインタフェースの詳細はオペレーティングシステムに依存しているかもしれません。 以下は、実行されるために基本機能を示すことができるだけです。 これらの呼び出しのいくつかが情報を非同期に返させます。
o Register Session
o レジスタセッション
Call: SESSION( DestAddress , ProtocolId, DstPort
以下に電話をしてください。 セッション、(DestAddress、ProtocolId、DstPort
[ , SESSION_object ]
[セッション_は反対します]
[ , Upcall_Proc_addr ] ) -> Session-id
[Upcall_Proc_addr) ->セッションイド
This call initiates RSVP processing for a session, defined
by DestAddress together with ProtocolId and possibly a
port number DstPort. If successful, the SESSION call
returns immediately with a local session identifier
Session-id, which may be used in subsequent calls.
この呼び出しはProtocolIdとことによるとポートナンバーDstPortと共にDestAddressによって定義されたセッションのためにRSVP処理を開始します。 うまくいくなら、SESSIONは、すぐローカルのセッション識別子Session-イドでリターンと呼びます。(それは、その後の呼び出しに使用されるかもしれません)。
The Upcall_Proc_addr parameter defines the address of an
upcall procedure to receive asynchronous error or event
notification; see below. The SESSION_object parameter is
included as an escape mechanism to support some more
general definition of the session ("generalized
destination port"), should that be necessary in the
future. Normally SESSION_object will be omitted.
Upcall_Proc_addrパラメタは非同期な誤りかイベント通知を受け取るためにupcall手順のアドレスを定義します。 以下を見てください。 SESSION_物のパラメタはセッション(「仕向港を一般化する」)のそれ以上の一般的な定義を支持するために逃避機制として含まれています、それが将来必要であるなら。 通常、SESSION_物は省略されるでしょう。
o Define Sender
o 送付者を定義してください。
Call: SENDER( Session-id
以下に電話をしてください。 送付者、(セッションイド
[ , Source_Address ] [ , Source_Port ]
[ソース_アドレス][ソース_ポート]
[ , Sender_Template ]
[送付者_テンプレート]
[ , Sender_Tspec ] [ , Adspec ]
[送付者_Tspec][Adspec]
[ , Data_TTL ] [ , Policy_data ] )
[データ_TTL]、[方針_データ])
Braden, Ed., et. al. Standards Track [Page 63] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[63ページ]。
A sender uses this call to define, or to modify the
definition of, the attributes of the data flow. The first
SENDER call for the session registered as `Session-id'
will cause RSVP to begin sending Path messages for this
session; later calls will modify the path information.
送付者は定義するか、または定義を変更するこの呼び出しを使用して、データの属性は流れます。 最初のSENDERは'セッションイド'がRSVPにこのセッションへのメッセージをPathに送らせ始めるので登録されたセッションを求めます。 後の呼び出しは経路情報を変更するでしょう。
The SENDER parameters are interpreted as follows:
SENDERパラメタは以下の通り解釈されます:
- Source_Address
- ソース_アドレス
This is the address of the interface from which the
data will be sent. If it is omitted, a default
interface will be used. This parameter is needed
only on a multihomed sender host.
これはデータが送られるインタフェースのアドレスです。 それが省略されると、デフォルトインタフェースは使用されるでしょう。 このパラメタが「マルチ-家へ帰」っている送付者ホストだけの上で必要です。
- Source_Port
- ソース_ポート
This is the UDP/TCP port from which the data will be
sent.
これはデータが送られるUDP/TCPポートです。
- Sender_Template
- 送付者_テンプレート
This parameter is included as an escape mechanism to
support a more general definition of the sender
("generalized source port"). Normally this parameter
may be omitted.
このパラメタは、送付者(「ソース港を一般化する」)の、より一般的な定義を支持するために逃避機制として含まれています。 通常、このパラメタは省略されるかもしれません。
- Sender_Tspec
- 送付者_Tspec
This parameter describes the traffic flow to be sent;
see [RFC 2210].
このパラメタは送られる交通の流れについて説明します。 [RFC2210]を見てください。
- Adspec
- Adspec
This parameter may be specified to initialize the
computation of QoS properties along the path; see
[RFC 2210].
このパラメタは経路に沿ってQoSの特性の計算を初期化するために指定されるかもしれません。 [RFC2210]を見てください。
- Data_TTL
- データ_TTL
This is the (non-default) IP Time-To-Live parameter
that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a
scope larger than multicast data packets.
これはデータ・パケットの上で提供されている生きる(非デフォルト)IP Timeパラメタです。 それが、Pathメッセージで範囲がマルチキャストデータ・パケットより大きくならないのを保証するのに必要です。
Braden, Ed., et. al. Standards Track [Page 64] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[64ページ]。
- Policy_data
- 方針_データ
This optional parameter passes policy data for the
sender. This data may be supplied by a system
service, with the application treating it as opaque.
この任意のパラメタは送付者のために方針データを通過します。 システムサービスで不透明なものとしてそれを扱うアプリケーションをこのデータに供給するかもしれません。
o Reserve
o 蓄え
Call: RESERVE( session-id, [ receiver_address , ]
以下に電話をしてください。 RESERVE、(セッションイド[受信機_アドレス]
[ CONF_flag, ] [ Policy_data, ]
[CONF_旗][方針_データ]
style, style-dependent-parms )
スタイル、扶養家族がparmsするスタイル)
A receiver uses this call to make or to modify a resource
reservation for the session registered as `session-id'.
The first RESERVE call will initiate the periodic
transmission of Resv messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but
note that changing existing reservations may result in
admission control failures).
受信機がかけるこの電話を使用するか、またはセッションの資源予約を変更するのは'セッションイド'として登録されました。 最初のRESERVE呼び出しはResvメッセージの周期的な伝達を開始するでしょう。 以前の呼び出しのパラメタを変更するために後のRESERVE呼び出しを与えるかもしれません(既存の予約を変えると入場コントロール失敗がもたらされるかもしれないことに注意してください)。
The optional `receiver_address' parameter may be used by a
receiver on a multihomed host (or router); it is the IP
address of one of the node's interfaces. The CONF_flag
should be set on if a reservation confirmation is desired,
off otherwise. The `Policy_data' parameter specifies
policy data for the receiver, while the `style' parameter
indicates the reservation style. The rest of the
parameters depend upon the style; generally these will be
appropriate flowspecs and filter specs.
任意の'受信機_アドレス'パラメタは「マルチ-家へ帰」っているホスト(または、ルータ)の上で受信機によって使用されるかもしれません。 それはノードのインタフェースの1つのIPアドレスです。 CONF_旗では、そうでなければ、予約確認が必要であって、取り止めになるなら、セットされるべきです。 '方針_データ'パラメタは受信機のための方針データを指定しますが、'スタイル'パラメタは予約スタイルを示します。 パラメタの残りをスタイルに依存します。 一般にこれらは、適切なflowspecsとフィルタ眼鏡になるでしょう。
The RESERVE call returns immediately. Following a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any
time.
RESERVEは、すぐに、リターンと呼びます。 RESERVE呼び出しに続いて、非同期なERROR/EVENT upcallはいつでも、起こるかもしれません。
o Release
o リリース
Call: RELEASE( session-id )
以下に電話をしてください。 リリース(セッションイド)
This call removes RSVP state for the session specified by
session-id. The node then sends appropriate teardown
messages and ceases sending refreshes for this session-id.
この呼び出しはセッションイドによって指定されたセッションのためにRSVP状態を取り除きます。 その時が適切な分解メッセージを送って、送るのをやめるノードはこのセッションイドのためにリフレッシュします。
Braden, Ed., et. al. Standards Track [Page 65] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[65ページ]。
o Error/Event Upcalls
o 誤り/イベントUpcalls
The general form of a upcall is as follows:
upcallの一般的なフォームは以下の通りです:
Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
Upcall: <Upcall_Proc>( )->セッションイド、Info_タイプ
information_parameters
情報_パラメタ
Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the SESSION call. This upcall may
occur asynchronously at any time after a SESSION call and
before a RELEASE call, to indicate an error or an event.
ここに、「Upcall_Proc」はアドレスがSESSION呼び出しで供給されたupcall手順を表します。 このupcallは、SESSION呼び出しの後とRELEASE呼び出しの前にいつでも、誤りか出来事を示すために非同期に現れるかもしれません。
Currently there are five upcall types, distinguished by
the Info_type parameter. The selection of information
parameters depends upon the type.
現在、Info_型引数によって区別された5つのupcallタイプがあります。 情報パラメタの品揃えはタイプに頼っています。
1. Info_type = PATH_EVENT
1. インフォメーション_は=経路_出来事をタイプします。
A Path Event upcall results from receipt of the first
Path message for this session, indicating to a
receiver application that there is at least one
active sender, or if the path state changes.
このセッションのときにそこでそれを受信側アプリケーションに示すのが、少なくとも1人の活発な送付者である、または経路州が変化するなら、Path Event upcallは最初のPathメッセージの領収書から生じます。
Upcall: <Upcall_Proc>( ) -> session-id,
Upcall: <Upcall_Proc>( )->セッションイド
Info_type=PATH_EVENT,
インフォメーション_は=経路_出来事をタイプします。
Sender_Tspec, Sender_Template
送付者_Tspec、送付者_テンプレート
[ , Adspec ] [ , Policy_data ]
[Adspec][方針_データ]
This upcall presents the Sender_Tspec, the
Sender_Template, the Adspec, and any policy data from
a Path message.
このupcallはPathメッセージからのSender_Tspec、Sender_Template、Adspec、およびどんな方針データも提示します。
2. Info_type = RESV_EVENT
2. インフォメーション_は=RESV_出来事をタイプします。
A Resv Event upcall is triggered by the receipt of
the first RESV message, or by modification of a
previous reservation state, for this session.
Resv Event upcallは最初のRESVメッセージの領収書、または前の予約状態の変更で引き起こされます、このセッションのために。
Braden, Ed., et. al. Standards Track [Page 66] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[66ページ]。
Upcall: <Upcall_Proc>( ) -> session-id,
Upcall: <Upcall_Proc>( )->セッションイド
Info_type=RESV_EVENT,
インフォメーション_は=RESV_出来事をタイプします。
Style, Flowspec, Filter_Spec_list
様式、Flowspecは_仕様_リストをフィルターにかけます。
[ , Policy_data ]
[方針_データ]
Here `Flowspec' will be the effective QoS that has
been received. Note that an FF-style Resv message
may result in multiple RESV_EVENT upcalls, one for
each flow descriptor.
ここで、'Flowspec'は受け取られた有効なQoSになるでしょう。 FF-スタイルResvメッセージが複数のRESV_EVENT upcalls、それぞれの流れ記述子あたり1つをもたらすかもしれないことに注意してください。
3. Info_type = PATH_ERROR
3. インフォメーション_は=経路_誤りをタイプします。
An Path Error event indicates an error in sender
information that was specified in a SENDER call.
Path Error出来事はSENDER呼び出しで指定された送付者情報における誤りを示します。
Upcall: <Upcall_Proc>( ) -> session-id,
Upcall: <Upcall_Proc>( )->セッションイド
Info_type=PATH_ERROR,
インフォメーション_は=経路_誤りをタイプします。
Error_code , Error_value ,
誤り_コード、誤り_価値
Error_Node , Sender_Template
誤り_ノード、送付者_テンプレート
[ , Policy_data_list ]
[方針_データ_は記載します]
The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps
system-specific) data about the error. The
Error_Node parameter will specify the IP address of
the node that detected the error. The
Policy_data_list parameter, if present, will contain
any POLICY_DATA objects from the failed Path message.
Error_コード・パラメータは誤りを定義するでしょう、そして、Error_値は誤りに関するいくつかの追加している(恐らくシステム特有の)データを提供するかもしれません。 Error_Nodeパラメタは誤りを検出したノードのIPアドレスを指定するでしょう。 存在していると、Policy_データ_リストパラメタは失敗したPathメッセージからのどんなPOLICY_DATA物も含むでしょう。
4. Info_type = RESV_ERR
4. インフォメーション_タイプ=RESV_は間違えます。
An Resv Error event indicates an error in a
reservation message to which this application
contributed.
Resv Error出来事はこのアプリケーションが貢献した予約メッセージにおける誤りを示します。
Upcall: <Upcall_Proc>( ) -> session-id,
Upcall: <Upcall_Proc>( )->セッションイド
Info_type=RESV_ERROR,
インフォメーション_は=RESV_誤りをタイプします。
Braden, Ed., et. al. Standards Track [Page 67] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[67ページ]。
Error_code , Error_value ,
誤り_コード、誤り_価値
Error_Node , Error_flags ,
誤り_ノード、誤り_旗
Flowspec, Filter_spec_list
Flowspec、フィルタ_仕様_リスト
[ , Policy_data_list ]
[方針_データ_は記載します]
The Error_code parameter will define the error and
Error_value may supply some additional (perhaps
system-specific) data. The Error_Node parameter will
specify the IP address of the node that detected the
event being reported.
Error_コード・パラメータは誤りを定義するでしょう、そして、Error_値はいくつかの追加している(恐らくシステム特有の)データを提供するかもしれません。 Error_Nodeパラメタは出来事が報告されるのを検出したノードのIPアドレスを指定するでしょう。
There are two Error_flags:
2個のError_旗があります:
- InPlace
- InPlace
This flag may be on for an Admission Control
failure, to indicate that there was, and is, a
reservation in place at the failure node. This
flag is set at the failure point and forwarded
in ResvErr messages.
この旗は、あったのを示さないAdmission Controlのことにオンであるかもしれなく、あります、失敗ノードに適所にある予約。 この旗を失敗ポイントに設定して、ResvErrメッセージで進めます。
- NotGuilty
- NotGuilty
This flag may be on for an Admission Control
failure, to indicate that the flowspec requested
by this receiver was strictly less than the
flowspec that got the error. This flag is set
at the receiver API.
この旗はAdmission Controlの故障にオンです、それを示すために、この受信機によって要求されたflowspecが誤りを得たflowspecより厳密に少なかったということであるかもしれません。 この旗は受信機APIに設定されます。
Filter_spec_list and Flowspec will contain the
corresponding objects from the error flow descriptor
(see Section 3.1.8). List_count will specify the
number of FILTER_SPECS in Filter_spec_list. The
Policy_data_list parameter will contain any
POLICY_DATA objects from the ResvErr message.
フィルタ_仕様_リストとFlowspecは誤り流れ記述子からの対応するオブジェクトを入れてあるでしょう(セクション3.1.8を見てください)。 リスト_カウントはFilter_仕様_リストのFILTER_SPECSの数を指定するでしょう。 Policy_データ_リストパラメタはResvErrメッセージからのどんなPOLICY_DATA物も含むでしょう。
5. Info_type = RESV_CONFIRM
5. タイプ=RESV_が確認するインフォメーション_
A Confirmation event indicates that a ResvConf
message was received.
Confirmation出来事は、ResvConfメッセージが受け取られたのを示します。
Upcall: <Upcall_Proc>( ) -> session-id,
Upcall: <Upcall_Proc>( )->セッションイド
Info_type=RESV_CONFIRM,
タイプ=RESV_が確認するインフォメーション_
Braden, Ed., et. al. Standards Track [Page 68] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[68ページ]。
Style, List_count,
様式、リスト_は数えられます。
Flowspec, Filter_spec_list
Flowspec、フィルタ_仕様_リスト
[ , Policy_data ]
[方針_データ]
The parameters are interpreted as in the Resv Error
upcall.
パラメタはResv Error upcallで解釈されます。
Although RSVP messages indicating path or resv events may
be received periodically, the API should make the
corresponding asynchronous upcall to the application only
on the first occurrence or when the information to be
reported changes. All error and confirmation events
should be reported to the application.
定期的に経路を示すRSVPメッセージかresv出来事を受け取るかもしれませんが、APIは対応する非同期なupcallを単に最初の発生かそれとも報告されるべき情報がいつ変化するかに関するアプリケーションにするはずです。 すべての誤りと確認出来事はアプリケーションに報告されるべきです。
3.11.2 RSVP/Traffic Control Interface
3.11.2 RSVP/トラフィックコントロールは連結します。
It is difficult to present a generic interface to traffic
control, because the details of establishing a reservation
depend strongly upon the particular link layer technology in
use on an interface.
一般的なインタフェースをトラフィックコントロールに提示するのは難しいです、予約を確立する詳細が強くインタフェースで使用中の特定のリンクレイヤ技術によるので。
Merging of RSVP reservations is required because of multicast
data delivery, which replicates data packets for delivery to
different next-hop nodes. At each such replication point, RSVP
must merge reservation requests from the corresponding next
hops by computing the "maximum" of their flowspecs. At a given
router or host, one or more of the following three replication
locations may be in use.
RSVPの予約の合併がマルチキャストデータ配送のために必要です。(それは、配送のために異なった次のホップノードにデータ・パケットを模写します)。 そのようなそれぞれの模写ポイントでは、RSVPは、それらのflowspecsの「最大」を計算することによって、次の対応するホップからの予約の要請を合併しなければなりません。 与えられたルータかホストでは、以下の3つの模写位置の1つ以上は使用中であるかもしれません。
1. IP layer
1. IP層
IP multicast forwarding performs replication in the IP
layer. In this case, RSVP must merge the reservations
that are in place on the corresponding outgoing interfaces
in order to forward a request upstream.
IPマルチキャスト推進はIP層の中で模写を実行します。 この場合、RSVPは要求上流を進めるために対応する外向的なインタフェースに適所にある予約を合併しなければなりません。
2. "The network"
2. 「ネットワーク」
Replication might take place downstream from the node,
e.g., in a broadcast LAN, in link-layer switches, or in a
mesh of non-RSVP-capable routers (see Section 2.8). In
模写はノード、例えば、放送LAN、リンクレイヤスイッチ、またはできる非RSVPルータのメッシュで川下で行われるかもしれません(セクション2.8を見てください)。 コネ
Braden, Ed., et. al. Standards Track [Page 69] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[69ページ]。
these cases, RSVP must merge the reservations from the
different next hops in order to make the reservation on
the single outgoing interface. It must also merge
reservations requests from all outgoing interfaces in
order to forward a request upstream.
これらのケース、RSVPは単一の外向的なインタフェースの予約をするように次の異なったホップから予約を合併しなければなりません。 また、それは、要求上流を進めるためにすべての外向的なインタフェースからの予約要求を合併しなければなりません。
3. Link-layer driver
3. リンクレイヤドライバー
For a multi-access technology, replication may occur in
the link layer driver or interface card. For example,
this case might arise when there is a separate ATM point-
to-point VC towards each next hop. RSVP may need to apply
traffic control independently to each VC, without merging
requests from different next hops.
マルチアクセス技術のために、模写はリンクレイヤドライバーかインタフェースカードに起こるかもしれません。 それぞれ次にであることに向かったポイントのVCが飛び越す別々のATMポイントがあるとき、例えば、本件は起こるかもしれません。 RSVPは、独自に次の異なったホップからの要求を合併しないで各VCにトラフィックコントロールを適用する必要があるかもしれません。
In general, these complexities do not impact the protocol
processing that is required by RSVP, except to determine
exactly what reservation requests need to be merged. It may be
desirable to organize an RSVP implementation into two parts: a
core that performs link-layer-independent processing, and a
link-layer-dependent adaptation layer. However, we present
here a generic interface that assumes that replication can
occur only at the IP layer or in "the network".
一般に、これらの複雑さはRSVPによって必要とされるプロトコル処理に影響を与えません、どんな予約の要請が、合併される必要であるかをまさに決定するのを除いて。 2つの部品にRSVP実現を組織化するのは望ましいかもしれません: リンク層の独立者処理、およびリンク層の扶養家族適合層を実行するコア。 しかしながら、私たちはここに模写がIP層において、または、だけ「ネットワーク」で起こることができると仮定する一般的なインタフェースを提示します。
o Make a Reservation
o 予約をしてください。
Call: TC_AddFlowspec( Interface, TC_Flowspec,
以下に電話をしてください。 Tc_AddFlowspec、(インタフェース、Tc_Flowspec
TC_Tspec, TC_Adspec, Police_Flags )
Tc_Tspec、Tc_Adspec、警察_旗)
-> RHandle [, Fwd_Flowspec]
->RHandle[Fwd_Flowspec]
The TC_Flowspec parameter defines the desired effective
QoS to admission control; its value is computed as the
maximum over the flowspecs of different next hops (see the
Compare_Flowspecs call below). The TC_Tspec parameter
defines the effective sender Tspec Path_Te (see Section
2.2). The TC_Adspec parameter defines the effective
Adspec. The Police_Flags parameter carries the three
flags E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
Section 3.8.
TC_Flowspecパラメタは必要な有効なQoSを入場コントロールと定義します。 値は最大として次の異なったホップのflowspecsの上で計算されます(Compare_Flowspecsが以下に呼ぶのを見てください)。 TC_Tspecパラメタは有効な送付者Tspec Path_Teを定義します(セクション2.2を見てください)。 TC_Adspecパラメタは有効なAdspecを定義します。 警察_Flagsパラメタは3個の旗_E警察_Flag、_M警察_Flag、および_B警察_Flagを運びます。 セクション3.8を見てください。
If this call is successful, it establishes a new
reservation channel corresponding to RHandle; otherwise,
it returns an error code. The opaque number RHandle is
used by the caller for subsequent references to this
reservation. If the traffic control service updates the
この呼び出しがうまくいくなら、RHandleに対応する新しい予約チャンネルを確立します。 さもなければ、それはエラーコードを返します。 不透明な数のRHandleはこの予約のその後の参照に訪問者によって使用されます。 トラフィックコントロールサービスアップデートです。
Braden, Ed., et. al. Standards Track [Page 70] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[70ページ]。
flowspec, the call will also return the updated object as
Fwd_Flowspec.
flowspec、また、呼び出しはFwd_Flowspecとしてアップデートされた物を返すでしょう。
o Modify Reservation
o 予約を変更してください。
Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
以下に電話をしてください。 Tc_ModFlowspec、(インタフェース、RHandle、Tc_Flowspec
TC_Tspec, TC_Adspec, Police_flags )
Tc_Tspec、Tc_Adspec、警察の_旗)
[ -> Fwd_Flowspec ]
[->Fwd_Flowspec]
This call is used to modify an existing reservation.
TC_Flowspec is passed to Admission Control; if it is
rejected, the current flowspec is left in force. The
corresponding filter specs, if any, are not affected. The
other parameters are defined as in TC_AddFlowspec. If the
service updates the flowspec, the call will also return
the updated object as Fwd_Flowspec.
この呼び出しは、既存の予約を変更するのに使用されます。 TC_FlowspecはAdmission Controlに渡されます。 それが拒絶されるなら、現在のflowspecは有効なままにされます。 もしあれば対応するフィルタ仕様は影響を受けません。 他のパラメタはTC_AddFlowspecのように定義されます。 また、サービスがflowspecをアップデートすると、呼び出しはFwd_Flowspecとしてアップデートされた物を返すでしょう。
o Delete Flowspec
o Flowspecを削除してください。
Call: TC_DelFlowspec( Interface, RHandle )
以下に電話をしてください。 Tc_DelFlowspec(インタフェース、RHandle)
This call will delete an existing reservation, including
the flowspec and all associated filter specs.
この呼び出しはflowspecとすべての関連フィルタ眼鏡を含む既存の予約を削除するでしょう。
o Add Filter Spec
o フィルタ仕様を加えてください。
Call: TC_AddFilter( Interface, RHandle,
以下に電話をしてください。 Tc_AddFilter、(RHandle、連結してください。
Session , FilterSpec ) -> FHandle
セッション、FilterSpec) ->FHandle
This call is used to associate an additional filter spec
with the reservation specified by the given RHandle,
following a successful TC_AddFlowspec call. This call
returns a filter handle FHandle.
この呼び出しは与えられたRHandleによって指定される予約に追加フィルタ仕様を関連づけるのに使用されます、うまくいっているTC_AddFlowspec呼び出しに続いて。 この呼び出しはフィルタハンドルFHandleを返します。
o Delete Filter Spec
o フィルタ仕様を削除してください。
Call: TC_DelFilter( Interface, FHandle )
以下に電話をしてください。 Tc_DelFilter(インタフェース、FHandle)
This call is used to remove a specific filter, specified
by FHandle.
この呼び出しは、FHandleによって指定された特定のフィルタを取り外すのに使用されます。
Braden, Ed., et. al. Standards Track [Page 71] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[71ページ]。
o OPWA Update
o OPWAアップデート
Call: TC_Advertise( Interface, Adspec,
以下に電話をしてください。 Tc_が広告を出す、(Adspec、連結してください。
Non_RSVP_Hop_flag ) -> New_Adspec
非_のRSVP_ホップ_旗) ->の新しい_Adspec
This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface. The
flag bit Non_RSVP_Hop_flag should be set whenever the RSVP
daemon detects that the previous RSVP hop included one or
more non-RSVP-capable routers. TC_Advertise will insert
this information into New_Adspec to indicate that a non-
integrated-service hop was found; see Section 3.8.
OPWAが外向的な広告New_Adspecを指定されたインタフェースに計算するのにこの呼び出しは使用されます。 RSVPデーモンがその前のRSVPホップ含まれているものかできるより多くの非RSVPルータを検出するときはいつも、フラグビットNon_RSVP_Hop_旗は設定されるべきです。 TC_、広告、統合非サービスホップが見つけられたのを示すためにNew_Adspecにこの情報を挿入するでしょう。 セクション3.8を見てください。
o Preemption Upcall
o 先取りUpcall
Upcall: TC_Preempt() -> RHandle, Reason_code
Upcall: Tc_は()->RHandle、理由_コードを先取りします。
In order to grant a new reservation request, the admission
control and/or policy control modules may preempt one or
more existing reservations. This will trigger a
TC_Preempt() upcall to RSVP for each preempted
reservation, passing the RHandle of the reservation and a
sub-code indicating the reason.
新しい予約の要請を与えるために、入場コントロール、そして/または、方針コントロールモジュールは1つ以上の既存の予約を先取りするかもしれません。 これはそれぞれの先取りされた予約のためのRSVPにTC_Preempt() upcallの引き金となるでしょう、理由を示しながら予約のRHandleとサブコードを渡して。
3.11.3 RSVP/Policy Control Interface
3.11.3 RSVP/方針コントロールインタフェース
This interface will be specified in a future document.
このインタフェースは将来のドキュメントで指定されるでしょう。
3.11.4 RSVP/Routing Interface
3.11.4 RSVP/ルート設定は連結します。
An RSVP implementation needs the following support from the
routing mechanisms of the node.
RSVP実現はノードのルーティングメカニズムから以下のサポートを必要とします。
o Route Query
o ルート質問
To forward Path and PathTear messages, an RSVP process
must be able to query the routing process(s) for routes.
前進のPathとPathTearメッセージに、RSVPの過程はルーティングの過程についてルートに質問できなければなりません。
Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Ucast_ルート_は[SrcAddress]DestAddressについて質問します。
Notify_flag ) -> OutInterface
通知、_旗) ->OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress,
Mcast_ルート_は[SrcAddress]DestAddressについて質問します。
Braden, Ed., et. al. Standards Track [Page 72] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[72ページ]。
Notify_flag )
通知、_旗)
-> [ IncInterface, ] OutInterface_list
->[IncInterface]OutInterface_リスト
Depending upon the routing protocol, the query may or may
not depend upon SrcAddress, i.e., upon the sender host IP
address, which is also the IP source address of the
message. Here IncInterface is the interface through which
the packet is expected to arrive; some multicast routing
protocols may not provide it. If the Notify_flag is True,
routing will save state necessary to issue unsolicited
route change notification callbacks (see below) whenever
the specified route changes.
ルーティング・プロトコルによって、質問はSrcAddressによるかもしれません、すなわち、送付者ホストIPアドレスで。(また、それは、メッセージのIPソースアドレスです)。 ここで、IncInterfaceはパケットが到着すると予想されるインタフェースです。 いくつかのマルチキャストルーティング・プロトコルはそれを提供しないかもしれません。 Notify_旗がTrueであるなら、ルーティングは指定されたルートが変化するときはいつも、求められていないルート変更届出書回収(以下を見る)を発行するのに必要な状態を節約するでしょう。
A multicast route query may return an empty
OutInterface_list if there are no receivers downstream of
a particular router. A route query may also return a `No
such route' error, probably as a result of a transient
inconsistency in the routing (since a Path or PathTear
message for the requested route did arrive at this node).
In either case, the local state should be updated as
requested by the message, which cannot be forwarded
further. Updating local state will make path state
available immediately for a new local receiver, or it will
tear down path state immediately.
特定のルータに受信機が全く川下になければ、マルチキャストルート質問は空のOutInterface_リストを返すかもしれません。 また、ルート質問は'そのようなルートでない'誤りを返すかもしれません、たぶんルーティングにおける一時的な矛盾の結果、(要求されたルートへのPathかPathTearメッセージがこのノードに届いたので)。 どちらの場合ではも、メッセージは要求された通り地方の状態をアップデートするべきです。(さらにそれを転送できません)。 地方の状態をアップデートするのに経路州がすぐ新しい地方の受信機に利用可能になるだろうか、またはそれはすぐに、経路州を取りこわすでしょう。
o Route Change Notification
o ルート変更届出書
If requested by a route query with the Notify_flag True,
the routing process may provide an asynchronous callback
to the RSVP process that a specified route has changed.
Notify_旗のTrueとのルート質問で要求されるなら、ルーティングの過程は指定されたルートが変えたRSVPの過程に非同期な回収を提供するかもしれません。
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
Ucast_ルート_は( ) ->[SrcAddress]DestAddressを変えます。
OutInterface
OutInterface
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
Mcast_ルート_は( ) ->[SrcAddress]DestAddressを変えます。
[ IncInterface, ] OutInterface_list
[IncInterface] OutInterface_リスト
o Interface List Discovery
o インタフェースリスト発見
RSVP must be able to learn what real and virtual
interfaces are active, with their IP addresses.
RSVPは、どんな本当の、そして、仮想のインタフェースがそれらのIPアドレスにアクティブであるかを学ぶことができなければなりません。
Braden, Ed., et. al. Standards Track [Page 73] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[73ページ]。
It should be possible to logically disable an interface
for RSVP. When an interface is disabled for RSVP, a Path
message should never be forwarded out that interface, and
if an RSVP message is received on that interface, the
message should be silently discarded (perhaps with local
logging).
RSVPのためにインタフェースを論理的に無能にするのは可能であるべきです。 インタフェースがRSVPのために無能にされるとき、Pathメッセージは決して進めて、それが外に連結するということであるべきではありません、そして、そのインタフェースにRSVPメッセージを受け取るなら、静かにメッセージを捨てるべきです(恐らく地方の伐採で)。
3.11.5 RSVP/Packet I/O Interface
3.11.5 RSVP/パケット入出力は連結します。
An RSVP implementation needs the following support from the
packet I/O and forwarding mechanisms of the node.
RSVP実現はノードのパケット入出力と推進メカニズムから以下のサポートを必要とします。
o Promiscuous Receive Mode for RSVP Messages
o 無差別である、RSVPメッセージのためにモードを受けてください。
Packets received for IP protocol 46 but not addressed to
the node must be diverted to the RSVP program for
processing, without being forwarded. The RSVP messages to
be diverted in this manner will include Path, PathTear,
and ResvConf messages. These message types carry the
Router Alert IP option, which can be used to pick them out
of a high-speed forwarding path. Alternatively, the node
can intercept all protocol 46 packets.
IPプロトコル46のために受け取りますが、ノードに記述しないパケットを処理のためのRSVPプログラムに紛らさなければなりません、進めないで。 紛らされるべきRSVPメッセージはこの様にPath、PathTear、およびResvConfメッセージを含むでしょう。 これらのメッセージタイプはRouter Alert IPオプションを運びます。(高速推進経路から彼らを選ぶのにそれを使用できます)。 あるいはまた、ノードはすべてのプロトコル46パケットを妨害できます。
On a router or multi-homed host, the identity of the
interface (real or virtual) on which a diverted message is
received, as well as the IP source address and IP TTL with
which it arrived, must also be available to the RSVP
process.
または、ルータ、マルチ、家へ帰り、また、ホスト(紛らされたメッセージがIPソースアドレスとそれが到着したIP TTLと同様に受け取られるインタフェース(本当の、または、仮想の)のアイデンティティ)もRSVPの過程に手があいているに違いありません。
o Outgoing Link Specification
o 送信するリンク仕様
RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing real or virtual link,
bypassing the normal routing mechanism. A virtual link
might be a multicast tunnel, for example. Outgoing link
specification is necessary to send different versions of
an outgoing Path message on different interfaces, and to
avoid routing loops in some cases.
RSVPに特定の出発している本当の、または、仮想のリンクに(マルチキャスト)データグラムを送らせることができなければなりません、正常なルーティングメカニズムを迂回させて。 例えば、仮想のリンクはマルチキャストトンネルであるかもしれません。 送信するリンク仕様が、送信するPathメッセージの異なった見解を異なったインタフェースに送って、いくつかの場合、輪を発送するのを避けるのに必要です。
o Source Address and TTL Specification
o ソースアドレスとTTL仕様
RSVP must be able to specify the IP source address and IP
TTL to be used when sending Path messages.
RSVPは、メッセージをPathに送るとき、使用されるためにIPのソースアドレスとIP TTLを指定できなければなりません。
o Router Alert
o ルータ警戒
RSVP must be able to cause Path, PathTear, and ResvConf
message to be sent with the Router Alert IP option.
RSVPはPath、PathTear、およびRouter Alert IPオプションと共に送られるべきResvConfメッセージを引き起こすことができなければなりません。
Braden, Ed., et. al. Standards Track [Page 74] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[74ページ]。
3.11.6 Service-Dependent Manipulations
3.11.6 サービス依存する操作
Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
their contents are defined in service specification documents.
In order to manipulate these objects, RSVP process must have
available to it the following service-dependent routines.
Flowspecs、Tspecs、およびAdspecsはRSVPへの不明瞭な物です。 それらの内容はサービス仕様ドキュメントで定義されます。 これらの物を操作するために、以下のそれに利用可能なサービス扶養家族ルーチンがRSVPの過程になければなりません。
o Compare Flowspecs
o Flowspecsを比較してください。
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
_Flowspecs(Flowspec_1、Flowspec_2)->を比較してください。
result_code
結果_コード
The possible result_codes indicate: flowspecs are equal,
Flowspec_1 is greater, Flowspec_2 is greater, flowspecs
are incomparable but LUB can be computed, or flowspecs are
incompatible.
可能な結果_コードは以下を示します。 flowspecsが等しい、Flowspec_1が、よりすばらしい、Flowspec_2が、よりすばらしい、flowspecsは比較にならないほどです、しかし、LUBを計算できますか、またはflowspecsは非互換です。
Note that comparing two flowspecs implicitly compares the
Tspecs that are contained. Although the RSVP process
cannot itself parse a flowspec to extract the Tspec, it
can use the Compare_Flowspecs call to implicitly calculate
Resv_Te (see Section 2.2).
それとなく2flowspecsを比較すると含まれたTspecsが比較されることに注意してください。 RSVPの過程がそうすることができない、それ自体、それは、a flowspecを分析して、Tspecを抽出してください、それとなくResv_Teについて計算するというCompare_Flowspecs要求を使用できます(セクション2.2を見てください)。
o Compute LUB of Flowspecs
o FlowspecsのLUBを計算してください。
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
_Flowspecs(Flowspec_1、Flowspec_2)->のLUB_
Flowspec_LUB
Flowspec_LUB
o Compute GLB of Flowspecs
o FlowspecsのGLBを計算してください。
GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
_Flowspecs(Flowspec_1、Flowspec_2)->のGLB_
Flowspec_GLB
Flowspec_GLB
o Compare Tspecs
o Tspecsを比較してください。
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code
_Tspecs(Tspec_1、Tspec_2)->結果_コードを比較してください。
Braden, Ed., et. al. Standards Track [Page 75] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[75ページ]。
The possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal.
可能な結果_コードは以下を示します。 Tspecsが等しいか、またはTspecsは不平等です。
o Sum Tspecs
o 合計Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
合計_Tspecs(Tspec_1、Tspec_2)->Tspec_合計
This call is used to compute Path_Te (see Section 2.2).
この呼び出しは、Path_Teを計算するのに使用されます(セクション2.2を見てください)。
4. Acknowledgments
4. 承認
The design of RSVP is based upon research performed in 1992-1993 by a collaboration including Lixia Zhang (UCLA), Deborah Estrin (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC), and Daniel Zappala (USC). Sugih Jamin developed the first prototype implementation of RSVP and successfully demonstrated it in May 1993. Shai Herzog, and later Steve Berson, continued development of RSVP prototypes.
RSVPのデザインはLixiaチャン(UCLA)、デボラEstrin(USC/ISI)、スコットShenker(ゼロックスPARC)、Sugihジャマン(USC/ゼロックスPARC)、およびダニエルZappala(USC)を含んでいて、1992-1993で共同で実行された研究に基づいています。 Sugihジャマンは、RSVPの最初のプロトタイプ実装を開発して、1993年5月に首尾よくそれを示しました。 Shaiハーツォグ、および後のスティーブBersonはRSVPプロトタイプの開発を続けていました。
Since 1993, many members of the Internet research community have contributed to the design and development of RSVP; these include (in alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker, John Wroclawski, Daniel Zappala, and Lixia Zhang. In addition, a number of host and router vendors have made valuable contributions to the RSVP documents, particularly Fred Baker (Cisco), Mark Baugher (Intel), Lou Berger (Fore Systems), Don Hoffman (Sun), Steve Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki (SGI), as well as many others.
1993年以来、インターネット研究団体の多くのメンバーがRSVPのデザインと開発に貢献しています。 これらはスティーブBerson、ボブ・ブレーデン、リー・ブレスラウ、デーブ・クラーク、デボラEstrin、Shaiハーツォグ、クレイグPartridge、スコットShenker、ジョンWroclawski、ダニエルZappala、およびLixiaチャンを含んでいます(アルファベット順に)。 さらに、多くのホストとルータベンダーはRSVPドキュメント、特にフレッド・ベイカー(シスコ)、マークBaugher(インテル)、ルウ・バーガー(前面のSystems)、ドン・ホフマン(Sun)、スティーブJakowski(NetManage)、ジョンKrawczyk(ベイネットワークス)、およびビルNowicki(SGI)への有価約因をしました、多くの他のものと同様に。
Braden, Ed., et. al. Standards Track [Page 76] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[76ページ]。
APPENDIX A. Object Definitions
付録A.オブジェクト定義
C-Types are defined for the two Internet address families IPv4 and IPv6. To accommodate other address families, additional C-Types could easily be defined. These definitions are contained as an Appendix, to ease updating.
C-タイプは2インターネット・アドレスのファミリーのIPv4とIPv6のために定義されます。 他のアドレスファミリーを収容するために、容易に追加C-タイプを定義できました。 これらの定義は、アップデートを緩和するためにAppendixとして含まれています。
All unused fields should be sent as zero and ignored on receipt.
すべての未使用の野原が、ゼロとして送られて、領収書の上で無視されるべきです。
A.1 SESSION Class
A.1セッションのクラス
SESSION Class = 1.
セッションのクラス=1。
o IPv4/UDP SESSION object: Class = 1, C-Type = 1
o IPv4/UDP SESSIONは反対します: クラスは1、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 DestAddress(4バイト)| +-------------+-------------+-------------+-------------+ | プロトコルイド| 旗| DstPort| +-------------+-------------+-------------+-------------+
o IPv6/UDP SESSION object: Class = 1, C-Type = 2
o IPv6/UDP SESSIONは反対します: クラスは1、C-タイプ=2と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | プロトコルイド| 旗| DstPort| +-------------+-------------+-------------+-------------+
DestAddress
DestAddress
The IP unicast or multicast destination address of the
session. This field must be non-zero.
セッションのIPユニキャストかマルチキャスト送付先アドレス。 この分野は非ゼロであるに違いありません。
Protocol Id
プロトコルイド
The IP Protocol Identifier for the data flow. This field
must be non-zero.
データのためのIPプロトコルIdentifierは流れます。 この分野は非ゼロであるに違いありません。
Braden, Ed., et. al. Standards Track [Page 77] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[77ページ]。
Flags
旗
0x01 = E_Police flag
0×01 = E_警察は弛みます。
The E_Police flag is used in Path messages to determine
the effective "edge" of the network, to control traffic
policing. If the sender host is not itself capable of
traffic policing, it will set this bit on in Path
messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the
service) and turn the flag off.
E_警察の旗は、トラフィックの取り締まりを制御するのにネットワークの有効な「縁」を決定するPathメッセージで使用されます。 送付者ホスト自身がトラフィックの取り締まることができないと、それはそれが送るPathメッセージでオンなこのビットを設定するでしょう。 RSVPがトラフィックの取り締まることができる最初のノードは、そう(サービスに適切であるなら)して、旗をオフにするでしょう。
DstPort
DstPort
The UDP/TCP destination port for the session. Zero may be
used to indicate `none'.
セッションのためのUDP/TCP仕向港。 ゼロは、'なにも'を示すのに使用されるかもしれません。
Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport-
layer or application layer.
将来、輸送層か応用層の中で他の逆多重化がコンベンションであるとサポートするために他のSESSION C-タイプを定義できました。
Braden, Ed., et. al. Standards Track [Page 78] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[78ページ]。
A.2 RSVP_HOP Class
A.2 RSVP_ホップのクラス
RSVP_HOP class = 3.
RSVP_HOPのクラス=3。
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1
o IPv4 RSVP_HOPは反対します: クラスは3、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | 次か前のホップが扱うIPv4| +-------------+-------------+-------------+-------------+ | 論理的なインタフェースハンドル| +-------------+-------------+-------------+-------------+
o IPv6 RSVP_HOP object: Class = 3, C-Type = 2
o IPv6 RSVP_HOPは反対します: クラスは3、C-タイプ=2と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + 次か前のホップが+であると扱うIPv6| | + + | | +-------------+-------------+-------------+-------------+ | 論理的なインタフェースハンドル| +-------------+-------------+-------------+-------------+
This object carries the IP address of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle (LIH) is used to distinguish logical
outgoing interfaces, as discussed in Sections 3.3 and 3.9. A node
receiving an LIH in a Path message saves its value and returns it
in the HOP objects of subsequent Resv messages sent to the node
that originated the LIH. The LIH should be identically zero if
there is no logical interface handle.
このオブジェクトは最後のRSVP博識なホップがこのメッセージを転送したインタフェースのIPアドレスを運びます。 Logical Interface Handle(LIH)は、論理的な外向的なインタフェースを区別するのにセクション3.3と3.9で議論するように使用されます。 PathメッセージでLIHを受けるノードは、LIHを溯源したノードに送られたその後のResvメッセージのHOPオブジェクトで値を節約して、それを返します。 LIHによるそこであるなら同様に、ゼロが論理的なインタフェースハンドルでないということであるはずです。
Braden, Ed., et. al. Standards Track [Page 79] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[79ページ]。
A.3 INTEGRITY Class
A.3保全のクラス
INTEGRITY class = 4.
INTEGRITYのクラス=4。
See [Baker96].
[Baker96]を見てください。
A.4 TIME_VALUES Class
A.4時間_はクラスを評価します。
TIME_VALUES class = 5.
タイム誌_VALUESのクラス=5。
o TIME_VALUES Object: Class = 5, C-Type = 1
o 時間_はオブジェクトを評価します: クラスは5、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| Refresh Period R |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | 以上、Rをリフレッシュしてください。| +-------------+-------------+-------------+-------------+
Refresh Period
期間をリフレッシュしてください。
The refresh timeout period R used to generate this message;
in milliseconds.
このメッセージを生成するために費やされたタイムアウト時間Rをリフレッシュしてください。 ミリセカンドで。
Braden, Ed., et. al. Standards Track [Page 80] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[80ページ]。
A.5 ERROR_SPEC Class
A.5誤り_仕様のクラス
ERROR_SPEC class = 6.
ERROR_SPECのクラス=6。
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
o IPv4 ERROR_SPECは反対します: クラスは6、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 Error Node Address(4バイト)| +-------------+-------------+-------------+-------------+ | 旗| エラーコード| 誤り値| +-------------+-------------+-------------+-------------+
o IPv6 ERROR_SPEC object: Class = 6, C-Type = 2
o IPv6 ERROR_SPECは反対します: クラスは6、C-タイプ=2と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Error Node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Error Node Address(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | 旗| エラーコード| 誤り値| +-------------+-------------+-------------+-------------+
Error Node Address
誤りノードアドレス
The IP address of the node in which the error was detected.
誤りが検出されたノードのIPアドレス。
Flags
旗
0x01 = InPlace
0×01 =InPlace
This flag is used only for an ERROR_SPEC object in a
ResvErr message. If it on, this flag indicates that
there was, and still is, a reservation in place at the
failure point.
この旗はResvErrメッセージのERROR_SPECオブジェクトにだけ使用されます。 それであるなら、オンであることで、この旗は、あったのを示して、まだあって、失敗で適所にある予約はポイントです。
0x02 = NotGuilty
0×02 =NotGuilty
This flag is used only for an ERROR_SPEC object in a
ResvErr message, and it is only set in the interface to
この旗はResvErrメッセージのERROR_SPECオブジェクトにだけ使用されます、そして、それはインタフェースに設定されるだけです。
Braden, Ed., et. al. Standards Track [Page 81] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[81ページ]。
the receiver application. If it on, this flag indicates
that the FLOWSPEC that failed was strictly greater than
the FLOWSPEC requested by this receiver.
受信側アプリケーション。 それである、オンです、この旗は失敗したFLOWSPECにこの受信機によって要求されたFLOWSPECより厳密にすばらしかったのを示します。
Error Code
エラーコード
A one-octet error description.
1八重奏のエラー記述。
Error Value
誤り値
A two-octet field containing additional information about the
error. Its contents depend upon the Error Type.
誤りに関する追加情報を含む2八重奏の分野。 内容はError Typeによります。
The values for Error Code and Error Value are defined in Appendix
B.
Error CodeとError Valueのための値はAppendix Bで定義されます。
Braden, Ed., et. al. Standards Track [Page 82] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[82ページ]。
A.6 SCOPE Class
A.6範囲のクラス
SCOPE class = 7.
SCOPEのクラス=7。
This object contains a list of IP addresses, used for routing
messages with wildcard scope without loops. The addresses must be
listed in ascending numerical order.
このオブジェクトはルーティング・メッセージにワイルドカード範囲で輪なしで使用されるIPアドレスのリストを含んでいます。 番号を昇る際にアドレスを記載しなければなりません。
o IPv4 SCOPE List object: Class = 7, C-Type = 1
o IPv4 SCOPE Listは反対します: クラスは7、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 Src Address(4バイト)| +-------------+-------------+-------------+-------------+ // // +-------------+-------------+-------------+-------------+ | IPv4 Src Address(4バイト)| +-------------+-------------+-------------+-------------+
o IPv6 SCOPE list object: Class = 7, C-Type = 2
o IPv6 SCOPEはオブジェクトを記載します: クラスは7、C-タイプ=2と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Src Address(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ // // +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Src Address(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+
Braden, Ed., et. al. Standards Track [Page 83] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[83ページ]。
A.7 STYLE Class
A.7スタイルのクラス
STYLE class = 8.
様式のクラス=8。
o STYLE object: Class = 8, C-Type = 1
o 様式オブジェクト: クラスは8、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| Flags | Option Vector |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | 旗| オプションベクトル| +-------------+-------------+-------------+-------------+
Flags: 8 bits
旗: 8ビット
(None assigned yet)
(まだ割り当てられていなかったなにも)
Option Vector: 24 bits
オプションベクトル: 24ビット
A set of bit fields giving values for the reservation
options. If new options are added in the future,
corresponding fields in the option vector will be assigned
from the least-significant end. If a node does not recognize
a style ID, it may interpret as much of the option vector as
it can, ignoring new fields that may have been defined.
1セットのビットは予約オプションのために付与値をさばきます。 新しいオプションが将来加えられると、オプションベクトルにおける対応する分野は最も最少に重要な終わりから割り当てられるでしょう。 ノードがスタイルIDを認識しないなら、解釈できるようにオプションベクトルの多くを解釈するかもしれません、定義されたかもしれない新しい分野を無視して。
The option vector bits are assigned (from the left) as
follows:
オプションベクトルビットは以下の通り割り当てられます(左から):
19 bits: Reserved
19ビット: 予約されます。
2 bits: Sharing control
2ビット: コントロールを共有します。
00b: Reserved
00b: 予約されます。
01b: Distinct reservations
01b: 異なった予約
10b: Shared reservations
10b: 共有された予約
11b: Reserved
11b: 予約されます。
3 bits: Sender selection control
3ビット: 送付者選択コントロール
000b: Reserved
000b: 予約されます。
001b: Wildcard
001b: ワイルドカード
010b: Explicit
010b: 明白
Braden, Ed., et. al. Standards Track [Page 84] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[84ページ]。
011b - 111b: Reserved
011b--、111b: 予約されます。
The low order bits of the option vector are determined by the
style, as follows:
オプションベクトルの下位のビットは、スタイルで決定していて、以下の通りです:
WF 10001b
FF 01010b
SE 10010b
WF 10001b ff01010b SE 10010b
Braden, Ed., et. al. Standards Track [Page 85] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[85ページ]。
A.8 FLOWSPEC Class
A.8 FLOWSPECのクラス
FLOWSPEC class = 9.
FLOWSPECのクラス=9。
o Reserved (obsolete) flowspec object: Class = 9, C-Type = 1
o 予約された(時代遅れの)flowspecオブジェクト: クラスは9、C-タイプ=1と等しいです。
o Inv-serv Flowspec object: Class = 9, C-Type = 2
o Inv-serv Flowspecは反対します: クラスは9、C-タイプ=2と等しいです。
The contents and encoding rules for this object are specified
in documents prepared by the int-serv working group [RFC
2210].
このオブジェクトのためのコンテンツと符号化規則はint-servワーキンググループ[RFC2210]によって準備されたドキュメントで指定されます。
Braden, Ed., et. al. Standards Track [Page 86] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[86ページ]。
A.9 FILTER_SPEC Class
A.9フィルタ_仕様のクラス
FILTER_SPEC class = 10.
FILTER_SPECのクラス=10。
o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
o IPv4 FILTER_SPECは反対します: クラスは10、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 SrcAddress(4バイト)| +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort| +-------------+-------------+-------------+-------------+
o IPv6 FILTER_SPEC object: Class = 10, C-Type = 2
o IPv6 FILTER_SPECは反対します: クラスは10、C-タイプ=2と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort| +-------------+-------------+-------------+-------------+
o IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3
o IPv6 Flow-ラベルFILTER_SPECは反対します: クラスは10、C-タイプ=3と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | /////// | 流れLabel(24ビット)| +-------------+-------------+-------------+-------------+
SrcAddress
SrcAddress
The IP source address for a sender host. Must be non-zero.
送付者ホストのためのIPソースアドレス。 非ゼロにならなければならなくなってください。
Braden, Ed., et. al. Standards Track [Page 87] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[87ページ]。
SrcPort
SrcPort
The UDP/TCP source port for a sender, or zero to indicate
`none'.
'なにも'を示す送付者、またはゼロのためのUDP/TCPソースポート。
Flow Label
流れラベル
A 24-bit Flow Label, defined in IPv6. This value may be used
by the packet classifier to efficiently identify the packets
belonging to a particular (sender->destination) data flow.
IPv6で定義された24ビットのFlow Label。 この値が効率的に事項に属すパケットを特定するのにパケットクラシファイアによって使用されるかもしれない、(送付者->、目的地、)、データは流れます。
Braden, Ed., et. al. Standards Track [Page 88] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[88ページ]。
A.10 SENDER_TEMPLATE Class
A.10送付者_テンプレートのクラス
SENDER_TEMPLATE class = 11.
SENDER_TEMPLATEのクラス=11。
o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1
o IPv4 SENDER_TEMPLATEは反対します: クラスは11、C-タイプ=1と等しいです。
Definition same as IPv4/UDP FILTER_SPEC object.
IPv4/UDP FILTER_SPECが反対するのと同じ定義。
o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2
o IPv6 SENDER_TEMPLATEは反対します: クラスは11、C-タイプ=2と等しいです。
Definition same as IPv6/UDP FILTER_SPEC object.
IPv6/UDP FILTER_SPECが反対するのと同じ定義。
o IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type =
3
o IPv6 Flow-ラベルSENDER_TEMPLATEは反対します: クラスは11、C-タイプ=3と等しいです。
A.11 SENDER_TSPEC Class
A.11送付者_TSPECのクラス
SENDER_TSPEC class = 12.
SENDER_TSPECのクラス=12。
o Intserv SENDER_TSPEC object: Class = 12, C-Type = 2
o Intserv SENDER_TSPECは反対します: クラスは12、C-タイプ=2と等しいです。
The contents and encoding rules for this object are specified
in documents prepared by the int-serv working group.
このオブジェクトのためのコンテンツと符号化規則はint-servワーキンググループによって準備されたドキュメントで指定されます。
A.12 ADSPEC Class
A.12 ADSPECのクラス
ADSPEC class = 13.
ADSPECのクラス=13。
o Intserv ADSPEC object: Class = 13, C-Type = 2
o Intserv ADSPECは反対します: クラスは13、C-タイプ=2と等しいです。
The contents and format for this object are specified in
documents prepared by the int-serv working group.
このオブジェクトのためのコンテンツと形式はint-servワーキンググループによって準備されたドキュメントで指定されます。
Braden, Ed., et. al. Standards Track [Page 89] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[89ページ]。
A.13 POLICY_DATA Class
A.13方針_データのクラス
POLICY_DATA class = 14.
POLICY_DATAのクラス=14。
o Type 1 POLICY_DATA object: Class = 14, C-Type = 1
o 1個のPOLICY_DATAオブジェクトをタイプしてください: クラスは14、C-タイプ=1と等しいです。
The contents of this object are for further study.
さらなる研究にはこのオブジェクトの内容があります。
Braden, Ed., et. al. Standards Track [Page 90] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[90ページ]。
A.14 Resv_CONFIRM Class
A.14 Resv_はクラスを確認します。
RESV_CONFIRM class = 15.
RESV_CONFIRMのクラス=15。
o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1
o IPv4 RESV_CONFIRMは反対します: クラスは15、C-タイプ=1と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 Receiver Address (4 bytes) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 Receiver Address(4バイト)| +-------------+-------------+-------------+-------------+
o IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2
o IPv6 RESV_CONFIRMは反対します: クラスは15、C-タイプ=2と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Receiver Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Receiver Address(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+
Braden, Ed., et. al. Standards Track [Page 91] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[91ページ]。
APPENDIX B. Error Codes and Values
付録B.エラーコードと値
The following Error Codes may appear in ERROR_SPEC objects and be passed to end systems. Except where noted, these Error Codes may appear only in ResvErr messages.
以下のError Codesは、ERROR_SPECオブジェクトに現れて、システムを終わらせるために渡されるかもしれません。有名であるところを除いて、これらのError CodesはResvErrメッセージだけに現れるかもしれません。
o Error Code = 00: Confirmation
o 誤りコード=00: 確認
This code is reserved for use in the ERROR_SPEC object of a
ResvConf message. The Error Value will also be zero.
このコードはResvConfメッセージのERROR_SPECオブジェクトにおける使用のために予約されます。 また、Error Valueはゼロになるでしょう。
o Error Code = 01: Admission Control failure
o 誤りコード=01: 入場Controlの故障
Reservation request was rejected by Admission Control due to
unavailable resources.
予約の要請は入手できないリソースのためAdmission Controlによって拒絶されました。
For this Error Code, the 16 bits of the Error Value field are:
このError Codeに関しては、Error Value分野の16ビットは以下の通りです。
ssur cccc cccc cccc
ssur cccc cccc cccc
where the bits are:
ビットがあるところ:
ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below).
ss=00: 下位12ビットはグローバルに定義されたサブコードを含んでいます(値は以下に記載しました)。
ss = 10: Low order 12 bits contain a organization-specific sub-
code. RSVP is not expected to be able to interpret this
except as a numeric value.
ss=10: 下位12ビットは組織特有のサブコードを含んでいます。 数値以外に、RSVPがこれを解釈できないと予想されます。
ss = 11: Low order 12 bits contain a service-specific sub-code.
RSVP is not expected to be able to interpret this except as
a numeric value.
ss=11: 下位12ビットはサービス特有のサブコードを含んでいます。 数値以外に、RSVPがこれを解釈できないと予想されます。
Since the traffic control mechanism might substitute a
different service, this encoding may include some
representation of the service in use.
トラフィックコントロールメカニズムが異なったサービスを代入するかもしれないので、このコード化は何らかの使用中にサービスの表現を含むかもしれません。
u = 0: RSVP rejects the message without updating local
state.
u=0: 地方の状態をアップデートしないで、RSVPはメッセージを拒絶します。
u = 1: RSVP may use message to update local state and forward
the message. This means that the message is informational.
u=1: RSVPは地方の状態をアップデートして、メッセージを転送するメッセージを使用するかもしれません。 これは、メッセージが情報であることを意味します。
Braden, Ed., et. al. Standards Track [Page 92] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[92ページ]。
r: Reserved bit, should be zero.
r: 予約されたビットはゼロであるべきです。
cccc cccc cccc: 12 bit code.
cccc cccc cccc: 12はコードに噛み付きました。
The following globally-defined sub-codes may appear in the low-
order 12 bits when ssur = 0000:
ssur=0000であるのに、以下のグローバルに定義されたサブコードは少ないオーダーに12ビット現れるかもしれません:
- Sub-code = 1: Delay bound cannot be met
- サブコード=1: 遅れバウンドを迎えることができません。
- Sub-code = 2: Requested bandwidth unavailable
- サブコード=2: 入手できない要求された帯域幅
- Sub-code = 3: MTU in flowspec larger than interface MTU.
- サブコード=3: インタフェースMTUより大きいflowspecのMTU。
o Error Code = 02: Policy Control failure
o 誤りコード=02: 方針Controlの故障
Reservation or path message has been rejected for administrative
reasons, for example, required credentials not submitted,
insufficient quota or balance, or administrative preemption.
This Error Code may appear in a PathErr or ResvErr message.
予約か経路メッセージが例えば、必要な資格証明書が提出されなかった管理理由、不十分な割当て、バランス、または管理先取りのために拒絶されました。 このError CodeはPathErrかResvErrメッセージに現れるかもしれません。
Contents of the Error Value field are to be determined in the
future.
Error Value分野の内容は将来断固とすることです。
o Error Code = 03: No path information for this Resv message.
o 誤りコード=03: このResvメッセージのための経路情報がありません。
No path state for this session. Resv message cannot be
forwarded.
このセッションのための経路州がありません。 Resvメッセージを転送できません。
o Error Code = 04: No sender information for this Resv message.
o 誤りコード=04: このResvメッセージのための送付者情報がありません。
There is path state for this session, but it does not include
the sender matching some flow descriptor contained in the Resv
message. Resv message cannot be forwarded.
経路州がこのセッションの間ありますが、それはResvメッセージに含まれた何らかの流れ記述子に合っている送付者を含んでいません。 Resvメッセージを転送できません。
o Error Code = 05: Conflicting reservation style
o 誤りコード=05: 闘争している予約スタイル
Reservation style conflicts with style(s) of existing
reservation state. The Error Value field contains the low-order
16 bits of the Option Vector of the existing style with which
the conflict occurred. This Resv message cannot be forwarded.
予約スタイルは既存の予約状態のスタイルと衝突します。 Error Value分野は闘争が起こった既存のスタイルのOption Vectorの下位の16ビットを含んでいます。 このResvメッセージを転送できません。
o Error Code = 06: Unknown reservation style
o 誤りコード=06: 未知の予約スタイル
Reservation style is unknown. This Resv message cannot be
forwarded.
予約スタイルは未知です。 このResvメッセージを転送できません。
Braden, Ed., et. al. Standards Track [Page 93] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[93ページ]。
o Error Code = 07: Conflicting dest ports
o 誤りコード=07: destが移植する闘争
Sessions for same destination address and protocol have appeared
with both zero and non-zero dest port fields. This Error Code
may appear in a PathErr or ResvErr message.
同じ送付先アドレスとプロトコルのためのセッションはゼロと非ゼロdestポート分野の両方と共に現れました。 このError CodeはPathErrかResvErrメッセージに現れるかもしれません。
o Error Code = 08: Conflicting sender ports
o 誤りコード=08: 送付者が移植する闘争
Sender port is both zero and non-zero in Path messages for the
same session. This Error Code may appear only in a PathErr
message.
送付者ポートはゼロと同じセッションへのPathメッセージの非ゼロの両方です。 このError CodeはPathErrメッセージだけに現れるかもしれません。
o Error Code = 09, 10, 11: (reserved)
o 09、10、エラーコード=11: (予約される)です。
o Error Code = 12: Service preempted
o 誤りコード=12: 先取りされたサービス
The service request defined by the STYLE object and the flow
descriptor has been administratively preempted.
様式オブジェクトと流れ記述子によって定義されたサービスのリクエストは行政上先取りされました。
For this Error Code, the 16 bits of the Error Value field are:
このError Codeに関しては、Error Value分野の16ビットは以下の通りです。
ssur cccc cccc cccc
ssur cccc cccc cccc
Here the high-order bits ssur are as defined under Error Code
01. The globally-defined sub-codes that may appear in the low-
order 12 bits when ssur = 0000 are to be defined in the future.
ここに、高位ビットssurがError Code01の下で定義されるようにあります。 ssur=0000が将来定義されることであるときに、安値に現れるかもしれないグローバルに定義されたサブコードは12ビットを配置します。
o Error Code = 13: Unknown object class
o 誤りコード=13: 未知のオブジェクトのクラス
Error Value contains 16-bit value composed of (Class-Num, C-
Type) of unknown object. This error should be sent only if RSVP
is going to reject the message, as determined by the high-order
bits of the Class-Num. This Error Code may appear in a PathErr
or ResvErr message.
誤りValueは値が(クラスヌム、Cタイプ)で構成した16ビットの未知のオブジェクトを含んでいます。 RSVPがメッセージを拒絶する場合にだけ、この誤りを送るべきです、Class-ヌムの高位のビットで決定するように。 このError CodeはPathErrかResvErrメッセージに現れるかもしれません。
o Error Code = 14: Unknown object C-Type
o 誤りコード=14: 未知のオブジェクトC-タイプ
Error Value contains 16-bit value composed of (Class-Num, C-
Type) of object.
誤りValueは値が(クラスヌム、Cタイプ)で構成した16ビットオブジェクトを含んでいます。
o Error Code = 15-19: (reserved)
o エラーコードは15-19と等しいです: (予約される)です。
o Error Code = 20: Reserved for API
o 誤りコード=20: APIのために、予約されます。
Error Value field contains an API error code, for an API error
that was detected asynchronously and must be reported via an
upcall.
Valueがさばく誤りはAPIエラーコードを含んでいます、非同期に検出されて、upcallを通して報告しなければならないAPI誤りのために。
Braden, Ed., et. al. Standards Track [Page 94] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[94ページ]。
o Error Code = 21: Traffic Control Error
o 誤りコード=21: トラフィックコントロール誤り
Traffic Control call failed due to the format or contents of the
parameters to the request. The Resv or Path message that caused
the call cannot be forwarded, and repeating the call would be
futile.
Controlが呼ぶトラフィックは要求へのパラメタの形式かコンテンツのため失敗しました。 呼び出しを引き起こしたResvかPathメッセージは転送できません、そして、呼び出しを繰り返すのは空しいでしょう。
For this Error Code, the 16 bits of the Error Value field are:
このError Codeに関しては、Error Value分野の16ビットは以下の通りです。
ss00 cccc cccc cccc
ss00 cccc cccc cccc
Here the high-order bits ss are as defined under Error Code 01.
ここに、高位のビットssがError Code01の下で定義されるようにあります。
The following globally-defined sub-codes may appear in the low
order 12 bits (cccc cccc cccc) when ss = 00:
ss=00であるのに、以下のグローバルに定義されたサブコードは下位に12ビット(cccc cccc cccc)現れるかもしれません:
- Sub-code = 01: Service conflict
- サブコード=01: サービス闘争
Trying to merge two incompatible service requests.
2つの両立しないサービスのリクエストを合併しようとします。
- Sub-code = 02: Service unsupported
- サブコード=02: サービスサポートされないです。
Traffic control can provide neither the requested service
nor an acceptable replacement.
トラフィックコントロールは要求されたサービスも許容できる交換品も提供できません。
- Sub-code = 03: Bad Flowspec value
- サブコード=03: 悪いFlowspec値
Malformed or unreasonable request.
奇形の、または、無理な要求。
- Sub-code = 04: Bad Tspec value
- サブコード=04: 悪いTspec値
Malformed or unreasonable request.
奇形の、または、無理な要求。
- Sub-code = 05: Bad Adspec value
- サブコード=05: 悪いAdspec値
Malformed or unreasonable request.
奇形の、または、無理な要求。
o Error Code = 22: Traffic Control System error
o 誤りコード=22: トラフィックControl System誤り
A system error was detected and reported by the traffic control
modules. The Error Value will contain a system-specific value
giving more information about the error. RSVP is not expected
to be able to interpret this value.
システム・エラーは、トラフィックコントロールモジュールで検出されて、報告されました。 Error Valueは誤りに関する詳しい情報を与えるシステム特有の値を含むでしょう。 RSVPがこの値を解釈できないと予想されます。
Braden, Ed., et. al. Standards Track [Page 95] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[95ページ]。
o Error Code = 23: RSVP System error
o 誤りコード=23: RSVP System誤り
The Error Value field will provide implementation-dependent
information on the error. RSVP is not expected to be able to
interpret this value.
Error Value分野は誤りの実装依存する情報を提供するでしょう。 RSVPがこの値を解釈できないと予想されます。
In general, every RSVP message is rebuilt at each hop, and the node that creates an RSVP message is responsible for its correct construction. Similarly, each node is required to verify the correct construction of each RSVP message it receives. Should a programming error allow an RSVP to create a malformed message, the error is not generally reported to end systems in an ERROR_SPEC object; instead, the error is simply logged locally, and perhaps reported through network management mechanisms.
一般に、あらゆるRSVPメッセージが各ホップで再建されます、そして、RSVPメッセージを作成するノードは正しい工事に原因となります。 同様に、各ノードが、それが受け取るそれぞれのRSVPメッセージの正しい工事について確かめるのに必要です。 RSVPがプログラミング・エラーで奇形のメッセージを作成できるなら、一般に、誤りがERROR_SPECオブジェクトにシステムを終わらせると報告されません。 代わりに、誤りは、単に局所的に登録されて、恐らくネットワークマネージメントメカニズムを通して報告されます。
The only message formatting errors that are reported to end systems are those that may reflect version mismatches, and which the end system might be able to circumvent, e.g., by falling back to a previous CType for an object; see code 13 and 14 above.
システムを終わらせると報告される唯一のメッセージ形式誤りがエンドシステムがバージョンミスマッチを反映して、回避できるかもしれないものです、例えば、オブジェクトのために前のCTypeへ後ろへ下がることによって。 コード13と14が上であることを見てください。
The choice of message formatting errors that an RSVP may detect and log locally is implementation-specific, but it will typically include the following:
RSVPが局所的に検出して、登録するかもしれないメッセージ形式誤りの選択は実装特有ですが、以下を通常含むでしょう:
o Wrong-length message: RSVP Length field does not match message
length.
o 間違った長さのメッセージ: RSVP Length分野はメッセージ長に合っていません。
o Unknown or unsupported RSVP version.
o 未知の、または、サポートされないRSVPバージョン。
o Bad RSVP checksum
o 悪いRSVPチェックサム
o INTEGRITY failure
o INTEGRITYの故障
o Illegal RSVP message Type
o 不法なRSVPメッセージType
o Illegal object length: not a multiple of 4, or less than 4.
o 不法なオブジェクトの長さ: 4の倍数でない、または4ほど以下でない。
o Next hop/Previous hop address in HOP object is illegal.
o HOPオブジェクトの次のホップ/前のホップアドレスは不法です。
o Bad source port: Source port is non-zero in a filter spec or
sender template for a session with destination port zero.
o 悪いソースポート: ソースポートは仕向港とのセッションのためのフィルタ仕様か送付者テンプレートの非ゼロゼロです。
o Required object class (specify) missing
o 必要なオブジェクトのクラス(指定する)の取り逃がすこと
o Illegal object class (specify) in this message type.
o このメッセージの不法なオブジェクトのクラス(指定する)はタイプされます。
o Violation of required object order
o 必要なオブジェクトオーダーの違反
Braden, Ed., et. al. Standards Track [Page 96] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[96ページ]。
o Flow descriptor count wrong for style or message type
o 流れ記述子はスタイルかメッセージタイプのために数え間違っています。
o Logical Interface Handle invalid
o 論理的なInterface Handle病人
o Unknown object Class-Num.
o 未知のオブジェクトClass-ヌム。
o Destination address of ResvConf message does not match Receiver
Address in the RESV_CONFIRM object it contains.
o ResvConfメッセージの送付先アドレスはそれが含むRESV_CONFIRMオブジェクトでReceiver Addressに合っていません。
Braden, Ed., et. al. Standards Track [Page 97] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[97ページ]。
APPENDIX C. UDP Encapsulation
付録C.UDPカプセル化
An RSVP implementation will generally require the ability to perform "raw" network I/O, i.e., to send and receive IP datagrams using protocol 46. However, some important classes of host systems may not support raw network I/O. To use RSVP, such hosts must encapsulate RSVP messages in UDP.
一般に、RSVP実装はすなわちプロトコル46を使用することでIPデータグラムを送って、受け取るために「生」のネットワーク入出力を実行する能力を必要とするでしょう。 しかしながら、数人の重要なクラスのホストシステムは生のネットワーク入出力をサポートしないかもしれません。 RSVPを使用するために、そのようなホストはUDPのメッセージをRSVPにカプセル化しなければなりません。
The basic UDP encapsulation scheme makes two assumptions:
基本的なUDPカプセル化体系は2を仮定にします:
1. All hosts are capable of sending and receiving multicast packets
if multicast destinations are to be supported.
1. マルチキャストの目的地がサポートされるつもりであるなら、すべてのホストは送受信マルチキャストパケットができます。
2. The first/last-hop routers are RSVP-capable.
2. 最後の第1/ホップルータはRSVPできます。
A method of relaxing the second assumption is given later.
後で2番目の仮定を弛緩するメソッドを与えます。
Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a host that can do raw network I/O. The UDP encapsulation scheme must allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu hosts, and routers.
胡がUDPカプセル化を必要とする「UDP専用」ホストであることをさせてください。そうすれば、Hrは生のネットワーク入出力ができるホストをさせます。 UDPカプセル化体系はHrホスト、胡ホスト、およびルータの任意のトポロジーの中にRSVP interoperationを許容しなければなりません。
Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast addresses learned from the path or reservation state in the node. If the node keeps track of which previous hops and which interfaces need UDP encapsulation, these messages can be sent using UDP encapsulation when necessary. On the other hand, Path and PathTear messages are sent to the destination address for the session, which may be unicast or multicast.
ノードで経路から学習されたユニキャストアドレスか予約状態にResv、ResvErr、ResvTear、およびPathErrメッセージを送ります。 必要であるときに、ノードがどの前のホップの動向をおさえるか、そして、どのインタフェースがUDPカプセル化、これらのメッセージを必要とするかがUDPカプセル化を使用させることができます。 他方では、PathとPathTearメッセージをセッションのための送付先アドレスに送ります。(ユニキャストかセッションはマルチキャストであるかもしれません)。
The tables in Figures 13 and 14 show the basic rules for UDP encapsulation of Path and PathTear messages, for unicast DestAddress and multicast DestAddress, respectively. The other message types, which are sent unicast, should follow the unicast rules in Figure 13. Under the `RSVP Send' columns in these figures, the notation is `mode(destaddr, destport)'; destport is omitted for raw packets. The `Receive' columns show the group that is joined and, where relevant, the UDP Listen port.
図13と14のテーブルはPathとPathTearメッセージのUDPカプセル化、ユニキャストDestAddressとマルチキャストDestAddressのためにそれぞれ基本的なルールを示しています。 他のメッセージタイプ(ユニキャストは送られる)は図13のユニキャスト規則に従うべきです。 これらの数字の'RSVP Send'コラムの下では、記法は'モード(destaddr、destport)'です。 destportは生のパケットのために省略されます。 '受信してください'というコラムは加わられるグループと関連しているところのUDP Listenポートを示しています。
It is useful to define two flavors of UDP encapsulation, one to be sent by Hu and the other to be sent by Hr and R, to avoid double processing by the recipient. In practice, these two flavors are distinguished by differing UDP port numbers Pu and Pu'.
UDPカプセル化の2つの風味を定義するのは役に立ちます、胡ともう片方によって送られる、HrとRで送って、受取人による二重処理を避ける1つ。 '実際には、これらの2つの風味が異なったUDPポートナンバーのPuとPuによって区別されます'。
Braden, Ed., et. al. Standards Track [Page 98] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[98ページ]。
The following symbols are used in the tables.
以下のシンボルはテーブルで使用されます。
o D is the DestAddress for the particular session.
o Dは特定のセッションのためのDestAddressです。
o G* is a well-known group address of the form 224.0.0.14, i.e., a
group that is limited to the local connected network.
o G*がフォームのよく知られるグループアドレスである、224.0、.0、.14、すなわち、ローカルの接続ネットワークに制限されるグループ。
o Pu and Pu' are two well-known UDP ports for UDP encapsulation of
RSVP, with values 1698 and 1699.
o 'PuとPu'は値1698と1699があるRSVPのUDPカプセル化のための2つのよく知られるUDPポートです。
o Ra is the IP address of the router interface `a'.
o Raはルータインタフェース'a'のIPアドレスです。
o Router interface `a' is on the local network connected to Hu and
Hr.
o ルータインタフェース'a'が胡とHrに接続された企業内情報通信網にあります。
o
o
The following notes apply to these figures:
以下の注意はこれらの数字に適用されます:
[Note 1] Hu sends a unicast Path message either to the destination
address D, if D is local, or to the address Ra of the first-hop
router. Ra is presumably known to the host.
[注意1] 胡はユニキャストPathメッセージを送付先アドレスDに送ります、地方である、または最初に、ホップルータのアドレスRaにD。 おそらく、Raはホストにとって知られています。
[Note 2] Here D is the address of the local interface through
which the message arrived.
[注意2] ここで、Dはメッセージが到着した局所界面のアドレスです。
[Note 3] This assumes that the application has joined the group D.
[注意3] これは、アプリケーションがグループDに加わったと仮定します。
Braden, Ed., et. al. Standards Track [Page 99] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[99ページ]。
UNICAST DESTINATION D:
ユニキャストの目的地D:
RSVP RSVP
Node Send Receive
___ _____________ _______________
Hu UDP(D/Ra,Pu) UDP(D,Pu)
[Note 1] and UDP(D,Pu')
[Note 2]
ノードが送るRSVP RSVPは受信します。___ _____________ _______________ 胡'UDP(D/Ra、Pu)UDP(D、Pu)[注意1]とUDP、(D、Pu、'、)[注意2]
Hr Raw(D) Raw()
and if (UDP) and UDP(D, Pu)
then UDP(D,Pu') [Note 2]
(Ignore Pu')
'時間、Raw(D)の生の()、(UDP)とUDP(D、Pu)の当時のUDPである、(D、Pu、'、)、[注意2]'、(Puを無視してください、'、)
R (Interface a):
Raw(D) Raw()
and if (UDP) and UDP(Ra, Pu)
then UDP(D,Pu') (Ignore Pu')
R、(インタフェースa): '生の(D)生の()、(UDP)とUDP(Ra、Pu)の当時のUDPである、(D、Pu、'、)'、(Puを無視してください、'、)
Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages
図13: ユニキャスト経路とResvメッセージのためのUDPカプセル化規則
MULTICAST DESTINATION D:
マルチキャストの目的地D:
RSVP RSVP
Node Send Receive
___ _____________ _________________
Hu UDP(G*,Pu) UDP(D,Pu')
[Note 3]
and UDP(G*,Pu)
ノードが送るRSVP RSVPは受信します。___ _____________ _________________ 胡'UDP(G*、Pu)UDP、(D、Pu、'、)、[注意3]とUDP(G*、Pu)
Hr Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu')
'時間、Raw(D、Tr)の生の()、(UDP)とUDP(G*、Pu)の当時のUDPである、(D、Pu、'、)'、(Puを無視してください、'、)
R (Interface a):
Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu')
R、(インタフェースa): '生(D、Tr)の生の()、(UDP)とUDP(G*、Pu)の当時のUDPである、(D、Pu、'、)'、(Puを無視してください、'、)
Figure 14: UDP Encapsulation Rules for Multicast Path Messages
図14: マルチキャスト経路メッセージのためのUDPカプセル化規則
Braden, Ed., et. al. Standards Track [Page 100] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[100ページ]。
A router may determine if its interface X needs UDP encapsulation by listening for UDP-encapsulated Path messages that were sent to either G* (multicast D) or to the address of interface X (unicast D). There is one failure mode for this scheme: if no host on the connected network acts as an RSVP sender, there will be no Path messages to trigger UDP encapsulation. In this (unlikely) case, it will be necessary to explicitly configure UDP encapsulation on the local network interface of the router.
ルータは、インタフェースXがどちらかのG*(マルチキャストD)、または、インタフェースXのアドレス(ユニキャストD)に送られたUDPによってカプセル化されたPathメッセージの聞こうとすることによってUDPカプセル化を必要とするかどうか決定するかもしれません。 この体系のための1つの故障モードがあります: 接続ネットワークでどんなホストもRSVP送付者として務めないと、UDPカプセル化の引き金となるPathメッセージが全くないでしょう。 この(ありそうもない)の場合では、ルータの企業内情報通信網インタフェースで明らかにUDPカプセル化を構成するのが必要でしょう。
When a UDP-encapsulated packet is received, the IP TTL is not available to the application on most systems. The RSVP process that receives a UDP-encapsulated Path or PathTear message should therefore use the Send_TTL field of the RSVP common header as the effective receive TTL. This may be overridden by manual configuration.
UDPによってカプセル化されたパケットが受け取られているとき、ほとんどのシステムのにおけるアプリケーションについて、IP TTLがありません。したがって、有効がTTLを受けるとき、UDPによってカプセル化されたPathかPathTearメッセージを受け取るRSVPプロセスはRSVPの一般的なヘッダーのSend_TTL分野を使用するはずです。 これは手動の構成によってくつがえされるかもしれません。
We have assumed that the first-hop RSVP-capable router R is on the directly-connected network. There are several possible approaches if this is not the case.
私たちは、最初に、ホップのRSVPできるルータRが直接接続されたネットワークにあると思いました。 いくつかの可能なアプローチがこれがそうでないならあります。
1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
with TTL=Ta
1. 胡がユニキャストとマルチキャストセッションの両方にTTL=とUDP(Ra、Pu)に行かせることができる、バイバイ。
Here Ta must be the TTL to exactly reach R. If Ta is too small,
the Path message will not reach R. If Ta is too large, R and
succeeding routers may forward the UDP packet until its hop
count expires. This will turn on UDP encapsulation between
routers within the Internet, perhaps causing bogus UDP traffic.
The host Hu must be explicitly configured with Ra and Ta.
Taは、まさにR.に達するためにはここの、TTLでなければなりません。If Taが小さ過ぎる、PathメッセージはR.に達しないでしょう。If Taは大き過ぎます、R、ホップカウントが期限が切れるまで、続くルータはUDPパケットを進めるかもしれません。 恐らくにせのUDPトラフィックを引き起こして、これはインターネットの中のルータの間のUDPカプセル化をつけるでしょう。 RaとTaで明らかにホスト胡を構成しなければなりません。
2. A particular host on the LAN connected to Hu could be designated
as an "RSVP relay host". A relay host would listen on (G*,Pu)
and forward any Path messages directly to R, although it would
not be in the data path. The relay host would have to be
configured with Ra and Ta.
2. 「RSVP中継ホスト」として胡に接されたLANの特定のホストを任命できました。 中継ホストは(G*、Pu)に前方にどんなPathメッセージも直接Rまで聴くでしょう、それはデータ経路にないでしょうが。 中継ホストはRaとTaによって構成されなければならないでしょう。
Braden, Ed., et. al. Standards Track [Page 101] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[101ページ]。
APPENDIX D. Glossary
付録D.用語集
o Admission control
o 入場コントロール
A traffic control function that decides whether the packet
scheduler in the node can supply the requested QoS while
continuing to provide the QoS requested by previously-admitted
requests. See also "policy control" and "traffic control".
以前に認められた要求で要求されたQoSを提供し続けている間、ノードのパケットスケジューラが要求されたQoSを供給できるかどうか決めるトラフィック制御機能。 また、「方針コントロール」と「トラフィックコントロール」を見てください。
o Adspec
o Adspec
An Adspec is a data element (object) in a Path message that
carries a package of OPWA advertising information. See "OPWA".
AdspecはOPWA広告情報のパッケージを運ぶPathメッセージのデータ要素(オブジェクト)です。 "OPWA"を見てください。
o Auto-refresh loop
o 自動、リフレッシュ、輪
An auto-refresh loop is an error condition that occurs when a
topological loop of routers continues to refresh existing
reservation state even though all receivers have stopped
requesting these reservations. See section 3.4 for more
information.
自動、リフレッシュ、輪はルータの位相的な輪が、すべての受信機が、これらの予約を要求するのを止めましたが、既存の予約状態をリフレッシュし続けていると起こるエラー条件です。 詳しい情報に関してセクション3.4を見てください。
o Blockade state
o 封鎖州
Blockade state helps to solve a "killer reservation" problem.
See sections 2.5 and 3.5, and "killer reservation".
封鎖州は、「殺人者の予約」問題を解決するのを助けます。 セクション2.5と3.5、および「殺人者の予約」を見てください。
o Branch policing
o 支店の取り締まり
Traffic policing at a multicast branching point on an outgoing
interface that has "less" resources reserved than another
outgoing interface for the same flow. See "traffic policing".
外向的なインタフェースでマルチキャスト分岐ポイントでそれを取り締まるトラフィックで、同じ流れのための別の外向的なインタフェースより「より少ない」リソースを予約します。 「トラフィックの取り締まり」を見てください。
o C-Type
o C-タイプ
The class type of an object; unique within class-name. See
"class-name".
オブジェクトのクラスタイプ。 クラス名の中でユニークです。 「クラス名」を見てください。
o Class-name
o クラス名
The class of an object. See "object".
オブジェクトのクラス。 「反対してください。」と確実にしてください。
o DestAddress
o DestAddress
The IP destination address; part of session identification. See
"session".
受信者IPアドレス。 セッション識別の一部。 「セッション」を見てください。
Braden, Ed., et. al. Standards Track [Page 102] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[102ページ]。
o Distinct style
o 異なったスタイル
A (reservation) style attribute; separate resources are reserved
for each different sender. See also "shared style".
(予約)スタイル属性。 別々のリソースはそれぞれの異なった送付者のために予約されます。 また、「共有されたスタイル」を見てください。
o Downstream
o 川下
Towards the data receiver(s).
データ受信装置に向かって。
o DstPort
o DstPort
The IP (generalized) destination port used as part of a session.
See "generalized destination port".
セッションの一部として使用されるIP(一般化される)仕向港。 「一般化された仕向港」を見てください。
o Entry policing
o エントリーの取り締まり
Traffic policing done at the first RSVP- (and policing-) capable
router on a data path.
データ経路で1RSVP番目の、そして、(取り締まること)のできるルータで行われたトラフィックの取り締まり。
o ERROR_SPEC
o 誤り_仕様
Object that carries the error report in a PathErr or ResvErr
message.
PathErrかResvErrメッセージのエラー・レポートを運ぶオブジェクト。
o Explicit sender selection
o 明白な送付者選択
A (reservation) style attribute; all reserved senders are to be
listed explicitly in the reservation message. See also
"wildcard sender selection".
(予約)スタイル属性。 すべての控え目な送付者が予約メッセージに明らかに記載されていることになっています。 また、「ワイルドカード送付者選択」を見てください。
o FF style
o FFスタイル
Fixed Filter reservation style, which has explicit sender
selection and distinct attributes.
固定Filter予約スタイル。(そのスタイルには、明白な送付者選択と異なった属性があります)。
o FilterSpec
o FilterSpec
Together with the session information, defines the set of data
packets to receive the QoS specified in a flowspec. The
filterspec is used to set parameters in the packet classifier
function. A filterspec may be carried in a FILTER_SPEC or
SENDER_TEMPLATE object.
セッション情報と共に定義する、flowspecで指定されたQoSを受け取るためにデータ・パケットのセットを定義します。 filterspecは、パケットクラシファイア機能にパラメタをはめ込むのに使用されます。 filterspecはFILTER_SPECかSENDER_TEMPLATEオブジェクトで運ばれるかもしれません。
o Flow descriptor
o 流れ記述子
The combination of a flowspec and a filterspec.
flowspecとfilterspecの組み合わせ。
Braden, Ed., et. al. Standards Track [Page 103] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[103ページ]。
o Flowspec
o Flowspec
Defines the QoS to be provided for a flow. The flowspec is used
to set parameters in the packet scheduling function to provide
the requested quality of service. A flowspec is carried in a
FLOWSPEC object. The flowspec format is opaque to RSVP and is
defined by the Integrated Services Working Group.
流れに提供するためにQoSを定義します。 flowspecは、要求されたサービスの質を提供するためにパケットスケジューリング機能にパラメタをはめ込むのに使用されます。 flowspecはFLOWSPECオブジェクトで運ばれます。 flowspec書式は、RSVPに不透明であり、Integrated Services作業部会によって定義されます。
o Generalized destination port
o 一般化された仕向港
The component of a session definition that provides further
transport or application protocol layer demultiplexing beyond
DestAddress. See "session".
さらなる輸送かアプリケーション・プロトコル層の逆多重化をDestAddressに供給するセッション定義のコンポーネント。 「セッション」を見てください。
o Generalized source port
o 一般化されたソースポート
The component of a filter spec that provides further transport
or application protocol layer demultiplexing beyond the sender
address.
さらなる輸送かアプリケーション・プロトコル層の逆多重化を送付者アドレスに提供するフィルタ仕様のコンポーネント。
o GLB
o GLB
Greatest Lower Bound
最も大きい下界
o Incoming interface
o 入って来るインタフェース
The interface on which data packets are expected to arrive, and
on which Resv messages are sent.
データ・パケットが到着すると予想されて、Resvメッセージが送られるインタフェース。
o INTEGRITY
o 保全
Object of an RSVP control message that contains cryptographic
data to authenticate the originating node and to verify the
contents of an RSVP message.
起因するノードを認証して、RSVPメッセージのコンテンツについて確かめる暗号のデータを含むRSVPコントロールメッセージのオブジェクト。
o Killer reservation problem
o 殺人者予約問題
The killer reservation problem describes a case where a receiver
attempting and failing to make a large QoS reservation prevents
smaller QoS reservations from being established. See Sections
2.5 and 3.5 for more information.
殺人者予約問題は試みて、大きいQoSの予約をしない受信機が、より小さいQoSの予約が確立されるのを防ぐケースについて説明します。 詳しい情報に関してセクション2.5と3.5を見てください。
o LIH
o LIH
The LIH (Logical Interface Handle) is used to help deal with
non-RSVP clouds. See Section 2.9 for more information.
LIH(論理的なInterface Handle)は、非RSVP雲に対処するのを助けるのに使用されます。 詳しい情報に関してセクション2.9を見てください。
Braden, Ed., et. al. Standards Track [Page 104] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[104ページ]。
o Local repair
o 局部的修繕
Allows RSVP to rapidly adapt its reservations to changes in
routing. See Section 3.6 for more information.
RSVPが急速にルーティングにおける変化に予約を適合させるのを許容します。 詳しい情報に関してセクション3.6を見てください。
o LPM
o LPM
Local Policy Module. the function that exerts policy control.
地方のPolicy Module方針コントロールを及ぼす機能。
o LUB
o LUB
Least Upper Bound.
上限。
o Merge policing
o 取り締まりを合併してください。
Traffic policing that takes place at data merge point of a
shared reservation.
それを取り締まるトラフィックが共有された予約のデータマージポイントで行われます。
o Merging
o 合併します。
The process of taking the maximum (or more generally the least
upper bound) of the reservations arriving on outgoing
interfaces, and forwarding this maximum on the incoming
interface. See Section 2.2 for more information.
外向的なインタフェースで到着して、入って来るインタフェースでこの最大を進めながら予約の最大(または、より一般に上限)を取るプロセス。 詳しい情報に関してセクション2.2を見てください。
o MTU
o MTU
Maximum Transmission Unit.
マキシマム・トランスミッション・ユニット。
o Next hop
o 次のホップ
The next router in the direction of traffic flow.
交通の流れの向きに次のルータ。
o NHOP
o NHOP
An object that carries the Next Hop information in RSVP control
messages.
RSVPコントロールメッセージのNext Hop情報を運ぶオブジェクト。
o Node
o ノード
A router or host system.
ルータかホストシステム。
o Non-RSVP clouds
o 非RSVP雲
Groups of hosts and routers that do not run RSVP. Dealing with
nodes that do not support RSVP is important for backwards
compatibility. See section 2.9.
RSVPを実行しないホストとルータのグループ。 互換性はRSVPが後方に重要であるサポートではなく、そうするノードを取扱います。 セクション2.9を見てください。
Braden, Ed., et. al. Standards Track [Page 105] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[105ページ]。
o Object
o オブジェクト
An element of an RSVP control message; a type, length, value
triplet.
RSVPコントロールメッセージの要素。 タイプ(長さ)は三つ子を評価します。
o OPWA
o OPWA
Abbreviation for "One Pass With Advertising". Describes a
reservation setup model in which (Path) messages sent downstream
gather information that the receiver(s) can use to predict the
end-to-end service. The information that is gathered is called
an advertisement. See also "Adspec".
「広告がある1つのパス」のための略語。 川下に送られた(経路)メッセージが受信機が終わりから終わりに対するサービスを予測するのに使用できる情報を集める予約セットアップモデルについて説明します。 集められる情報は広告と呼ばれます。 また、"Adspec"を見てください。
o Outgoing interface
o 外向的なインタフェース
Interface through which data packets and Path messages are
forwarded.
どのデータ・パケットとPathメッセージを転送するかを通して連結してください。
o Packet classifier
o パケットクラシファイア
Traffic control function in the primary data packet forwarding
path that selects a service class for each packet, in accordance
with the reservation state set up by RSVP. The packet
classifier may be combined with the routing function. See also
"traffic control".
それを経路に送るプライマリデータ・パケットのトラフィック制御機能は各パケットのためにサービスのクラスを選択します、RSVPによって設立された予約状態に従って。 パケットクラシファイアは経路選択機能に結合されるかもしれません。 また、「トラフィックコントロール」を見てください。
o Packet scheduler
o パケットスケジューラ
Traffic control function in the primary data packet forwarding
path that implements QoS for each flow, using one of the service
models defined by the Integrated Services Working Group. See
also " traffic control".
それを経路に送るプライマリデータ・パケットのトラフィック制御機能は各流れのためにQoSを実装します、Integrated Services作業部会によって定義されたサービスモデルのひとりを使用して。 また、「トラフィックコントロール」を見てください。
o Path state
o 経路州
Information kept in routers and hosts about all RSVP senders.
情報はすべてのRSVP送付者に関してルータとホストに閉じ込めました。
o PathErr
o PathErr
Path Error RSVP control message.
経路Error RSVPはメッセージを制御します。
o PathTear
o PathTear
Path Teardown RSVP control message.
経路Teardown RSVPはメッセージを制御します。
Braden, Ed., et. al. Standards Track [Page 106] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[106ページ]。
o PHOP
o PHOP
An object that carries the Previous Hop information in RSVP
control messages.
RSVPコントロールメッセージのPrevious Hop情報を運ぶオブジェクト。
o Police
o 警察
See traffic policing.
トラフィックが取り締まられているのを見てください。
o Policy control
o 方針コントロール
A function that determines whether a new request for quality of
service has administrative permission to make the requested
reservation. Policy control may also perform accounting (usage
feedback) for a reservation.
サービスの質を求める新しい要求には要求された予約をする管理許可があるかどうか決定する機能。 また、方針コントロールは予約のための会計(用法フィードバック)を実行するかもしれません。
o Policy data
o 方針データ
Data carried in a Path or Resv message and used as input to
policy control to determine authorization and/or usage feedback
for the given flow.
PathかResvメッセージで運ばれて、方針に入力されるように使用されるデータは、与えられた流れのために承認、そして/または、用法フィードバックを決定するために制御されます。
o Previous hop
o 前のホップ
The previous router in the direction of traffic flow. Resv
messages flow towards previous hops.
交通の流れの向きに前のルータ。 Resvメッセージは前のホップに向かって流れます。
o ProtocolId
o ProtocolId
The component of session identification that specifies the IP
protocol number used by the data stream.
データ・ストリームで使用されるIPプロトコル番号を指定するセッション識別のコンポーネント。
o QoS
o QoS
Quality of Service.
サービスの質。
o Reservation state
o 予約状態
Information kept in RSVP-capable nodes about successful RSVP
reservation requests.
情報はうまくいっているRSVP予約の要請に関するRSVPできるノードに閉じ込めました。
o Reservation style
o 予約スタイル
Describes a set of attributes for a reservation, including the
sharing attributes and sender selection attributes. See Section
1.3 for details.
共有属性と送付者選択属性を含む予約のために1セットの属性について説明します。 詳細に関してセクション1.3を見てください。
Braden, Ed., et. al. Standards Track [Page 107] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[107ページ]。
o Resv message
o Resvメッセージ
Reservation request RSVP control message.
予約の要請RSVPはメッセージを制御します。
o ResvConf
o ResvConf
Reservation Confirmation RSVP control message, confirms
successful installation of a reservation at some upstream node.
予約Confirmation RSVPは何らかの上流のノードでメッセージを制御して、予約のうまくいっているインストールを確認します。
o ResvErr
o ResvErr
Reservation Error control message, indicates that a reservation
request has failed or an active reservation has been preempted.
予約Errorは、メッセージを制御して、予約の要請が失敗したか、または活発な予約が先取りされたのを示します。
o ResvTear
o ResvTear
Reservation Teardown RSVP control message, deletes reservation
state.
予約Teardown RSVPはメッセージを制御して、予約状態を削除します。
o Rspec
o Rspec
The component of a flowspec that defines a desired QoS. The
Rspec format is opaque to RSVP and is defined by the Integrated
Services Working Group of the IETF.
必要なQoSを定義するflowspecの部品。 Rspec書式は、RSVPに不透明であり、IETFのIntegrated Services作業部会によって定義されます。
o RSVP_HOP
o RSVP_ホップ
Object of an RSVP control message that carries the PHOP or NHOP
address of the source of the message.
PHOPを運ぶRSVPコントロールメッセージのオブジェクトかメッセージの源のNHOPアドレス。
o Scope
o 範囲
The set of sender hosts to which a given reservation request is
to be propagated.
伝播される与えられた予約の要請がことである送付者ホストのセット。
o SE style
o SEスタイル
Shared Explicit reservation style, which has explicit sender
selection and shared attributes.
共有されたExplicit予約スタイル。(そのスタイルには、明白な送付者選択と共用属性があります)。
o Semantic fragmentation
o 意味断片化
A method of fragmenting a large RSVP message using information
about the structure and contents of the message, so that each
fragment is a logically complete RSVP message.
メッセージの構造とコンテンツの情報を使用することで大きいRSVPメッセージを断片化するメソッドによって、それぞれが断片化するのは、論理的に完全なRSVPメッセージです。
Braden, Ed., et. al. Standards Track [Page 108] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[108ページ]。
o Sender template
o 送付者テンプレート
Parameter in a Path message that defines a sender; carried in a
SENDER_TEMPLATE object. It has the form of a filter spec that
can be used to select this sender's packets from other packets
in the same session on the same link.
送付者を定義するPathメッセージのパラメタ。 SENDER_TEMPLATEオブジェクトでは、運ばれます。 それには、同じリンクの同じセッションのときに他のパケットからこの送付者のパケットを選択するのに使用できるフィルタ仕様のフォームがあります。
o Sender Tspec
o 送付者Tspec
Parameter in a Path message, a Tspec that characterizes the
traffic parameters for the data flow from the corresponding
sender. It is carried in a SENDER_TSPEC object.
Pathメッセージ、対応する送付者からのデータフローのためのトラフィックパラメタを特徴付けるTspecのパラメタ。 それはSENDER_TSPECオブジェクトで運ばれます。
o Session
o セッション
An RSVP session defines one simplex unicast or multicast data
flow for which reservations are required. A session is
identified by the destination address, transport-layer protocol,
and an optional (generalized) destination port.
RSVPセッションは予約が必要である1つのシンプレクスユニキャストかマルチキャストデータフローを定義します。 セッションは送付先アドレス、トランスポート層プロトコル、および任意(一般化される)の仕向港によって特定されます。
o Shared style
o 共有されたスタイル
A (reservation) style attribute: all reserved senders share the
same reserved resources. See also "distinct style".
(予約)スタイル属性: すべての控え目な送付者が同じ予約されたリソースを共有します。 また、「異なったスタイル」を見てください。
o Soft state
o 軟性国家
Control state in hosts and routers that will expire if not
refreshed within a specified amount of time.
そうでなければ期限が切れるホストとルータにおけるコントロール状態は指定された時間以内にリフレッシュしました。
o STYLE
o スタイル
Object of an RSVP message that specifies the desired reservation
style.
必要な予約スタイルを指定するRSVPメッセージのオブジェクト。
o Style
o 様式
See "reservation style"
「予約スタイル」を見てください。
o TIME_VALUES
o 時間_値
Object in an RSVP control message that specifies the time period
timer used for refreshing the state in this message.
このメッセージで状態をリフレッシュするのに使用される期間のタイマを指定するRSVPコントロールメッセージで反対してください。
Braden, Ed., et. al. Standards Track [Page 109] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[109ページ]。
o Traffic control
o トラフィックコントロール
The entire set of machinery in the node that supplies requested
QoS to data streams. Traffic control includes packet
classifier, packet scheduler, and admission control functions.
要求されたQoSをデータに供給するノードの全体の機械は流れます。トラフィックコントロールはパケットクラシファイア、パケットスケジューラ、および入場コントロール機能を含んでいます。
o Traffic policing
o トラフィックの取り締まり
The function, performed by traffic control, of forcing a given
data flow into compliance with the traffic parameters implied by
the reservation. It may involve dropping non-compliant packets
or sending them with lower priority, for example.
トラフィックコントロールで実行された予約で含意されるトラフィックパラメタへの承諾に与えられたデータフローを力づくで押す機能。 それは、例えば、低優先度と共に不従順なパケットを下げるか、またはそれらを送ることを伴うかもしれません。
o TSpec
o TSpec
A traffic parameter set that describes a flow. The format of a
Tspec is opaque to RSVP and is defined by the Integrated Service
Working Group.
流れについて説明する交通パラメタセット。 Tspecの書式は、RSVPに不透明であり、Integrated Service作業部会によって定義されます。
o UDP encapsulation
o UDPカプセル化
A way for hosts that cannot use raw sockets to participate in
RSVP by encapsulating the RSVP protocol (raw) packets in
ordinary UDP packets. See Section APPENDIX C for more
information.
普通のUDPパケットでRSVPプロトコル(生の)パケットをカプセルに入れることによってRSVPに参加するのに生のソケットを使用できないホストのための方法。 詳しい情報に関してセクションAPPENDIX Cを見てください。
o Upstream
o 上流
Towards the traffic source. RSVP Resv messages flow upstream.
交通源に向かって。 RSVP Resvメッセージは逆流します。
o WF style
o WFスタイル
Wildcard Filter reservation style, which has wildcard sender
selection and shared attributes.
ワイルドカードFilter予約スタイル。(そのスタイルには、ワイルドカード送付者選択と共用属性があります)。
o Wildcard sender selection
o ワイルドカード送付者選択
A (reservation) style attribute: traffic from any sender to a
specific session receives the same QoS. See also "explicit
sender selection".
(予約)スタイル属性: どんな送付者から特定のセッションまでの交通も同じQoSを受けます。 また、「明白な送付者選択」を見てください。
Braden, Ed., et. al. Standards Track [Page 110] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[110ページ]。
References
参照
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress.
[Baker96] ベイカー、F.、「RSVPの暗号の認証」が進行中で働いています。
[RFC 1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
PARC, June 1994.
[RFC1633] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、ISI、MIT、およびPARC、1994年6月。
[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
April, 1994.
[FJ94] フロイド、S.、および「周期的なルーティング・メッセージの同期」、ネットワークのIEEE/ACM取引、Vol.2、No.2(1994年4月)対ジェーコブソン
[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC 2207, September 1997.
[RFC2207] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RFC 2113] Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems,
February 1997.
[RFC2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、コクチマスSystems、1997年2月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with Integrated Services",
RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[PolArch96] Herzog, S., "Policy Control for RSVP: Architectural
Overview". Work in Progress.
[PolArch96] ハーツォグ、S.、「方針はRSVPのために以下を制御します」。 「建築概観。」 進行中で、働いてください。
[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation
Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.
[OPWA95] ShenkerとS.とL.ブレスラウ、「予約設立における2冊」、Proc。 ケンブリッジ(MA)1995年8月のACM SIGCOMM95年。
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993.
[RSVP93] チャン、L.、デアリング、S.、Estrin、D.、Shenker、S.、およびD.Zappala、「RSVP:」 IEEEは、1993年9月に「新しい資源予約プロトコル」とネットワークでつなぎます。
Security Considerations
セキュリティ問題
See Section 2.8.
セクション2.8を見てください。
Braden, Ed., et. al. Standards Track [Page 111] RFC 2205 RSVP September 1997
ブレーデン、エドetである、アル。 規格はRSVP1997年9月にRFC2205を追跡します[111ページ]。
Authors' Addresses
作者のアドレス
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデンUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511 EMail: Braden@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Braden@ISI.EDU
Lixia Zhang UCLA Computer Science Department 4531G Boelter Hall Los Angeles, CA 90095-1596 USA
LixiaチャンUCLAコンピュータ理学部4531G Boelter Hallロサンゼルス、カリフォルニア90095-1596米国
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
以下に電話をしてください。 310-825-2695 メールしてください: lixia@cs.ucla.edu
Steve Berson USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
スティーブBerson USC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511 EMail: Berson@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Berson@ISI.EDU
Shai Herzog IBM T. J. Watson Research Center P.O Box 704 Yorktown Heights, NY 10598
ニューヨーク ShaiハーツォグIBM T.J.ワトソン研究所P.O箱704のヨークタウンの高さ、10598
Phone: (914) 784-6059 EMail: Herzog@WATSON.IBM.COM
以下に電話をしてください。 (914) 784-6059 メールしてください: Herzog@WATSON.IBM.COM
Sugih Jamin University of Michigan CSE/EECS 1301 Beal Ave. Ann Arbor, MI 48109-2122
Sugihジャマンミシガン大学CSE/EECS1301ビールAve。 アナーバー、MI48109-2122
Phone: (313) 763-1583
以下に電話をしてください。 (313) 763-1583
EMail: jamin@EECS.UMICH.EDU
メール: jamin@EECS.UMICH.EDU
Braden, Ed., et. al. Standards Track [Page 112]
ブレーデン、エドetである、アル。 標準化過程[112ページ]
一覧
スポンサーリンク
