RFC2210 日本語訳
2210 The Use of RSVP with IETF Integrated Services. J. Wroclawski. September 1997. (Format: TXT=77613 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Wroclawski Request for Comments: 2210 MIT LCS Category: Standards Track September 1997
Wroclawskiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2210年のMIT LCSカテゴリ: 標準化過程1997年9月
The Use of RSVP with IETF Integrated Services
IETFの統合サービスとのRSVPの使用
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 note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. The RSVP protocol defines several data objects which carry resource reservation information but are opaque to RSVP itself. The usage and data format of those objects is given here.
この注意はControlled-負荷とGuaranteed QoSコントロールサービスによるRSVP資源予約プロトコルの使用について説明します。 RSVPプロトコルは資源予約情報を運んでいますが、RSVP自身に不透明な数個のデータ・オブジェクトを定義します。 それらのオブジェクトの用法とデータの形式をここに与えます。
1. Introduction
1. 序論
The Internet integrated services framework provides the ability for applications to choose among multiple, controlled levels of delivery service for their data packets. To support this capability, two things are required:
インターネット統合しているサービスフレームワークはアプリケーションが複数の、そして、制御されたレベルのデリバリ・サービスの中で選ばれる能力をそれらのデータ・パケットに提供します。 この能力をサポートするために、2つのものが必要です:
- Individual network elements (subnets and IP routers) along the
path followed by an application's data packets must support
mechanisms to control the quality of service delivered to those
packets.
- アプリケーションのデータ・パケットがあとに続いた経路に沿った個々のネットワーク要素(サブネットとIPルータ)は、それらのパケットに提供されたサービスの質を制御するためにメカニズムをサポートしなければなりません。
- A way to communicate the application's requirements to network
elements along the path and to convey QoS management information
between network elements and the application must be provided.
- 経路に沿ったネットワーク要素にアプリケーションの要件を伝えて、ネットワーク要素とアプリケーションの間にQoS経営情報を伝える方法を提供しなければなりません。
In the integrated services framework the first function is provided by QoS control services such as Controlled-Load [RFC 2211] and Guaranteed [RFC 2212]. The second function may be provided in a number of ways, but is frequently implemented by a resource reservation setup protocol such as RSVP [RFC 2205].
統合サービスフレームワークに、Controlled-負荷[RFC2211]やGuaranteed[RFC2212]などのQoSコントロールサービスで最初の機能を提供します。 2番目の機能を多くの方法で提供するかもしれませんが、RSVP[RFC2205]などの資源予約セットアッププロトコルは頻繁に実装します。
Wroclawski Standards Track [Page 1] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[1ページ]。
Because RSVP is designed to be used with a variety of QoS control services, and because the QoS control services are designed to be used with a variety of setup mechanisms, a logical separation exists between the two specifications. The RSVP specification does not define the internal format of those RSVP protocol fields, or objects, which are related to invoking QoS control services. Rather, RSVP treats these objects as opaque. The objects can carry different information to meet different application and QoS control service requirements.
RSVPがさまざまなQoSコントロールサービスと共に使用されるように設計されていて、QoSコントロールサービスがさまざまなセットアップメカニズムと共に使用されるように設計されているので、論理的な分離は2つの仕様の間に存在しています。 RSVP仕様はそれらのRSVPプロトコル分野、またはオブジェクトの内部の書式を定義しないで、どれがあるかがQoSコントロールが修理する呼び出しに関連しました。 むしろ、RSVPは不透明なこれらの同じくらいオブジェクトを扱います。 オブジェクトは、異なったアプリケーションとQoSコントロールサービス要件を満たすために異なった情報を運ぶことができます。
Similarly, interfaces to the QoS control services are defined in a general format, so that the services can be used with a variety of setup mechanisms.
同様に、QoSコントロールサービスへのインタフェースは一般形式で定義されます、さまざまなセットアップメカニズムと共にサービスを利用できるように。
This RFC provides the information required to use RSVP and the integrated service framework's QoS control services together. It defines the usage and contents of three RSVP protocol objects, the FLOWSPEC, ADSPEC, and SENDER_TSPEC, in an environment supporting the Controlled-Load and/or Guaranteed QoS control services. If new services or capabilities are added to the integrated services framework, this note will be revised as required.
このRFCはRSVPを使用するのに必要である情報と統合サービスフレームワークのQoSコントロールサービスを一緒に提供します。 それは3個のRSVPプロトコルオブジェクト、FLOWSPEC、ADSPEC、およびSENDER_TSPECの用法とコンテンツを定義します、Controlled-負荷、そして/または、Guaranteed QoSコントロールがサービスであるとサポートする環境で。 新種業務か能力が統合サービスフレームワークに加えられると、この注意は必要に応じて改訂されるでしょう。
2. Use of RSVP
2. RSVPの使用
Several types of data must be transported between applications and network elements to correctly invoke QoS control services.
正しくQoSコントロールサービスを呼び出すためにアプリケーションとネットワーク要素の間でいくつかのタイプに関するデータを輸送しなければなりません。
NOTE: In addition to the data used to directly invoke QoS control
services, RSVP carries authentication, accounting, and policy
information needed to manage the use of these services. This note
is concerned only with the RSVP objects needed to actually invoke
QoS control services, and does not discuss accounting or policy
objects.
以下に注意してください。 直接QoSコントロールサービスを呼び出すのに使用されるデータに加えて、RSVPはこれらのサービスの使用を管理するのに必要である認証、会計、および方針情報を運びます。 この注意は、オブジェクトが、実際にQoSコントロールサービスを呼び出す必要だったことをRSVPだけに心配させて、会計か政策目的について議論しません。
This data includes:
このデータは:
- Information generated by each receiver describing the QoS
control service desired, a description of the traffic flow to
which the resource reservation should apply (the Receiver TSpec),
and whatever parameters are required to invoke the service (the
Receiver RSpec). This information is carried from the receivers to
intermediate network elements and the sender(s) by RSVP FLOWSPEC
objects. The information being carried in a FLOWSPEC object may
change at intermediate points in the network due to reservation
merging and other factors.
- QoSコントロールサービスが望んでいたそれぞれの受信機説明で生成された情報、資源予約が適用されるべきである交通の流れ(Receiver TSpec)と、パラメタがことなら何でもであるかに関する記述がサービス(Receiver RSpec)を呼び出すのが必要です。 この情報はRSVP FLOWSPECオブジェクトによって受信機から中間ネットワーク要素と送付者まで運ばれます。 予約合併と他の要素のため、FLOWSPECオブジェクトで運ばれる情報は中間的ポイントでネットワークで変化するかもしれません。
Wroclawski Standards Track [Page 2] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[2ページ]。
- Information generated at each sender describing the data traffic
generated by that sender (the Sender TSpec). This information is
carried from the sender to intermediate network elements and the
receiver(s) by RSVP, but is never modified by intermediate
elements within the network. This information is carried in RSVP
SENDER_TSPEC objects.
- データ通信量を説明する各送付者で生成された情報は、それで送付者が(Sender TSpec)であると生成しました。 この情報は、送付者から中間ネットワーク要素と受信機までRSVPによって運ばれますが、ネットワークの中の中間的要素によって決して変更されません。 この情報はRSVP SENDER_TSPECオブジェクトで運ばれます。
- Information generated or modified within the network and used at
the receivers to make reservation decisions. This information
might include available services, delay and bandwidth estimates,
and operating parameters used by specific QoS control services.
this information is collected from network elements and carried
towards receivers in RSVP ADSPEC objects. Rather than carrying
information from each intermediate node separately to the
receivers, the information in the ADSPEC represents a summary,
computed as the ADSPEC passes each hop. The size of this summary
remains (roughly) constant as the ADSPEC flows through the
network, giving good scaling properties.
- 予約決定をするのに生成されるか、ネットワークの中で変更されて、または受信機で使用される情報。 この情報は特定のQoSコントロールサービスで使用される営業品目、遅れ、帯域幅見積り、および運転パラメータを含むかもしれません。この情報は、ネットワーク要素で集められて、RSVP ADSPECオブジェクトで受信機に向かって運ばれます。 別々にそれぞれの中間的ノードから受信機まで情報を運ぶよりむしろ、ADSPECの情報はADSPECが各ホップを通過するので計算された概要を表します。 良いスケーリング特性を与えて、ADSPECがネットワークを通して流れるのに従って、この概要のサイズは(およそ)一定のままで残っています。
From the point of view of RSVP objects, the breakdown is as follows:
RSVPオブジェクトの観点から、故障は以下の通りです:
- The RSVP SENDER_TSPEC object carries the traffic specification
(sender TSpec) generated by each data source within an RSVP
session. It is transported unchanged through the network, and
delivered to both intermediate nodes and receiving applications.
- RSVP SENDER_TSPECオブジェクトはRSVPセッション以内に各データ送信端末によって生成されたトラフィック仕様(送付者TSpec)を運びます。 それは、ネットワークを通して変わりがない状態で輸送されて、中間的ノードと申し込みを受け付ける両方に提供されます。
- The RSVP ADSPEC object carries information which is generated at
either data sources or intermediate network elements, is flowing
downstream towards receivers, and may be used and updated inside
the network before being delivered to receiving applications.
This information includes both parameters describing the
properties of the data path, including the availability of
specific QoS control services, and parameters required by specific
QoS control services to operate correctly.
- RSVP ADSPECオブジェクトがデータ送信端末か中間ネットワーク要素のどちらかで生成される情報を運んで、申し込みを受け付けるのに提供する前に、ネットワークの中で川下を受信機に向かって流れていて、使用して、アップデートするかもしれません。 この情報はデータ経路の特性について説明する両方のパラメタを含んでいます、特定のQoSコントロールサービス、および正しく作動するのに特定のQoSコントロールサービスで必要であるパラメタの有用性を含んでいて。
- The RSVP FLOWSPEC object carries reservation request
(Receiver_TSpec and RSpec) information generated by data
receivers. The information in the FLOWSPEC flows upstream towards
data sources. It may be used or updated at intermediate network
elements before arriving at the sending application.
- RSVP FLOWSPECオブジェクトはデータ受信装置によって生成された予約の要請(受信機_TSpecとRSpec)情報を運びます。 FLOWSPECの情報はデータ送信端末に向かって逆流します。 送付アプリケーションに到達する前に、中間ネットワーク要素でそれを使用するか、またはアップデートするかもしれません。
NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP objects
is somewhat historical. Using the message format described in
this note it would be possible to place all of the service
control information carried "downstream" by RSVP in the same
object. However, the distinction between data which is not
updated within the network (in the SENDER_TSPEC object) and data
which is updated within the network (in the ADSPEC object) may
以下に注意してください。 SENDER_TSPECとADSPEC RSVPオブジェクトの両方の存在はいくらか歴史的です。 この注意で説明されたメッセージ・フォーマットを使用して、RSVPによって「川下まで」運ばれたサービス制御情報のすべてを同じオブジェクトに置くのは可能でしょう。 しかしながら、ネットワークの中でアップデートされないデータ(SENDER_TSPECオブジェクトの)とネットワークの中でアップデートされるデータ(ADSPECオブジェクトの)の区別はそうするかもしれません。
Wroclawski Standards Track [Page 3] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[3ページ]。
be useful to an implementation in practice, and is therefore
retained.
実際には実装の役に立って、したがって、保有されます。
2.1 Summary of operation
2.1 操作の概要
Operation proceeds as follows:
操作は以下の通り続きます:
An application instance participating in an RSVP session as a data sender registers with RSVP. One piece of information provided by the application instance is the Sender TSpec describing the traffic the application expects to generate. This information is used to construct an RSVP SENDER_TSPEC object, which is included in RSVP PATH messages generated for the application.
RSVPセッションのときにデータ送付者として参加するアプリケーションインスタンスはRSVPとともに記名します。 アプリケーションインスタンスによって提供された1つの情報がアプリケーションが生成すると予想するトラフィックについて説明するSender TSpecです。 この情報は、RSVP SENDER_TSPECオブジェクトを組み立てるのに使用されます。(オブジェクトはアプリケーションのために生成されたRSVP PATHメッセージに含まれています)。
The sending application also constructs an initial RSVP ADSPEC object. This adspec carries information about the QoS control capabilities and requirements of the sending application itself, and forms the starting point for the accumulation of path properties described below. The ADSPEC is added to the RSVP PATH message created at the sender.
また、送付アプリケーションは初期のRSVP ADSPECオブジェクトを組み立てます。 このadspecはQoSコントロール能力の情報と送付アプリケーション自体、および経路の特性の蓄積のための出発点が以下で説明したフォームの要件を運びます。 ADSPECは送付者で作成されたRSVP PATHメッセージに追加されます。
NOTE: For the convenience of application programmers, a host RSVP
implementation may allow the sending application not to provide an
initial adspec, instead supplying its own default. This usage is
most likely when the application sender does not itself
participate in the end-to-end QoS control process (by actively
scheduling CPU usage and similar means) and does not itself care
which QoS control service is selected by the receivers.
以下に注意してください。 アプリケーション・プログラマーの都合のために、送付アプリケーションはホストRSVP実装で初期のadspecを提供できないかもしれません、代わりにそれ自身のデフォルトを供給して。 この用法はアプリケーション送付者がいつそれ自体をするというわけではないかが、終わらせる終わりでのQoSコントロール加工処理していた状態で(活発にCPU用法と同様の手段の計画をするのによる)参加して、それのQoSコントロールサービスが受信機によって選択される注意をそれ自体にするというわけではない最も傾向があります。
Typically the default ADSPEC supplied by the host RSVP in this
case would support all QoS control services known to the host.
However, the exact behavior of this mechanism is implementation
dependent.
通常、この場合ホストRSVPによって供給されているデフォルトADSPECは、すべてのQoSがホストにとって知られているコントロールサービスであるとサポートするでしょう。 しかしながら、このメカニズムの正確な振舞いは実装に依存しています。
The ADSPEC is modified by subsequent network elements as the RSVP PATH message moves from sender to receiver(s). At each network element, the ADSPEC is passed from RSVP to the traffic control module. The traffic control module updates the ADSPEC, which may contain data for several QoS control services, by identifying the services mentioned in the ADSPEC and calling each such service to update its portion of the ADSPEC. If the traffic control module discovers a QoS control service mentioned in the ADSPEC but not implemented by the network element, a flag is set to report this to the receiver. The updated ADSPEC is then returned to RSVP for delivery to the next hop along the path.
RSVP PATHメッセージが送付者から受信機まで移行するとき、ADSPECはその後のネットワーク要素によって変更されます。 それぞれのネットワーク要素では、ADSPECはRSVPからトラフィックコントロールモジュールまで渡されます。 トラフィックコントロールモジュールはADSPECをアップデートします、ADSPECで言及されたサービスを特定して、ADSPECの一部をアップデートするためにそのような各サービスを呼ぶことによって。(ADSPECはいくつかのQoSコントロールサービスのためのデータを含むかもしれません)。 トラフィックコントロールモジュールがADSPECで言及されましたが、ネットワーク要素によって実装されなかったQoSコントロールサービスを発見するなら、これを受信機に報告するように旗を設定します。次に、経路に沿った次のホップへの配送のためにアップデートされたADSPECをRSVPに返します。
Wroclawski Standards Track [Page 4] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[4ページ]。
Upon arrival of the PATH message at an application receiver, the data in the SENDER_TSPEC and ADSPEC objects is passed across the RSVP API to the application. The application (perhaps with the help of a library of common resource-reservation functions) interprets the arriving data, and uses it to guide the selection of resource reservation parameters. Examples of this include use of the arriving "PATH_MTU" composed characterization parameter [RFC 2215] to determine the maximum packet size parameter in the reservation request and use of the arriving Guaranteed service "C" and "D" parameters [RFC 2212] to calculate a mathematical bound on delivered packet delay when using the Guaranteed service.
アプリケーション受信機のPATHメッセージの到着のときに、SENDER_TSPECとADSPECオブジェクトのデータはRSVP APIの向こう側にアプリケーションに通過されます。 アプリケーション(恐らく一般的な資源予約機能のライブラリの助けがある)は、資源予約パラメタの品揃えを誘導するのに到着データを解釈して、それを使用します。 この例は、保証されたサービスを利用するとき、サービス「C」と「D」パラメタ[RFC2212]が数学のバウンドを当てにするために保証された到着の予約の要請と使用における最大のパケットサイズ・パラメータがパケット遅れを提供したことを決定するために到着「経路_MTU」落ち着いた特殊化パラメタ[RFC2215]の使用を含んでいます。
An application receiver wishing to make a resource reservation supplies its local RSVP with the necessary reservation parameters. Among these are the QoS control service desired (Guaranteed or Controlled-Load), the traffic specifier (TSpec) describing the level of traffic for which resources should be reserved, and, if needed by the selected QoS control service, an RSpec describing the level of service desired. These parameters are composed into an RSVP FLOWSPEC object and transmitted upstream by RSVP.
資源予約をするアプリケーション受信機願望は必要な予約パラメタを地方のRSVPに供給します。 このうち、望まれていたサービスのレベルについて説明するトラフィック特許説明書の作成書(TSpec)がリソースが予約されるべきであるトラフィックのレベルについて説明して、望まれていた(保証するか、またはControlledロードします)QoSコントロールサービス、および選択されたQoSコントロールサービスで必要であるときにRSpecがあります。 これらのパラメタは、RSVP FLOWSPECオブジェクトに構成されて、RSVPによって上流へ伝えられます。
At each RSVP-aware point in the network, the SENDER_TSPECs arriving in PATH messages and the FLOWSPECs arriving in RESV messages are used to request an appropriate resource reservation from the desired QoS control service. State merging, message forwarding, and error handling proceed according to the rules of the RSVP protocol.
ネットワークにおけるそれぞれのRSVP意識しているポイントでは、PATHメッセージに到着するSENDER_TSPECsとRESVメッセージに到着するFLOWSPECsは、必要なQoSコントロールサービスから適切な資源予約を要求するのに使用されます。 RSVPプロトコルの規則に従って、州の合併、メッセージ推進、およびエラー処理は続きます。
Finally, the merged FLOWSPEC object arriving at each of an RSVP session's data senders is delivered to the application to inform each sender of the merged reservation request and properties of the data path.
最終的に、RSVPセッションのデータ送付者各人に届く合併しているFLOWSPECオブジェクトは、データ経路の合併している予約の要請と特性について各送付者に知らせるためにアプリケーションに提供されます。
2.2. RSVP support for multiple QoS control services
2.2. RSVPは、複数のQoSのためにコントロールがサービスであるとサポートします。
The design described in this note supports RSVP sessions in which the receivers choose a QoS control service at runtime.
この注意で説明されたデザインはランタイムのときに受信機が選ばれるRSVPセッションにQoSコントロールサービスをサポートします。
To make this possible, a receiver must have all the information needed to choose a particular service before it makes the choice. This means that the RSVP SENDER_TSPEC and ADSPEC objects must provide the receivers with information for all services which might be chosen.
これを可能にするように、受信機には、選択をする前に特定のサービスを選ぶのに必要であるすべての情報がなければなりません。 これは、RSVP SENDER_TSPECとADSPECオブジェクトが選ばれるかもしれないすべてのサービスのための情報を受信機に提供しなければならないことを意味します。
The Sender TSpec used by the two currently defined QoS control services is identical. This simplifies the RSVP SENDER_TSPEC object, which need carry only a single TSpec data structure in this shared format. This common SENDER_TSPEC can be used with either Guaranteed or Controlled-Load service.
2つの現在定義されたQoSコントロールサービスで使用されるSender TSpecは同じです。 これはRSVP SENDER_TSPECオブジェクトを簡素化します。(それは、この共有された形式でただ一つのTSpecデータ構造だけを運ばなければなりません)。 GuaranteedかControlled-負荷サービスのどちらかと共にこの一般的なSENDER_TSPECを使用できます。
Wroclawski Standards Track [Page 5] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[5ページ]。
The RSVP ADSPEC carries information needed by receivers to choose a service and determine the reservation parameters. This includes:
RSVP ADSPECはサービスを選んで、予約パラメタを決定するために受信機によって必要とされた情報を運びます。 これは:
- Whether or not there is a non-RSVP hop along the path. If there
is a non-RSVP hop, the application's traffic will receive
reservationless best-effort service at at least one point on the
path.
- 非RSVPがあるか否かに関係なく、経路に沿って跳んでください。 非RSVPホップがあると、アプリケーションのトラフィックは経路の少なくとも1ポイントでreservationlessのベストエフォート型サービスを受けるでしょう。
- Whether or not a specific QoS control service is implemented at
every hop along the path. For example, a receiver might learn that
at least one integrated-services aware hop along the path supports
the Controlled-Load service but not the Guaranteed service.
- 特定のQoSがサービスを管理しているかどうかが経路に沿ったあらゆるホップで実施されます。 例えば、受信機は、経路に沿った少なくとも1つの統合サービスの意識しているホップがGuaranteedサービスではなく、Controlled-負荷サービスをサポートすることを学ぶかもしれません。
- Default or global values for the general characterization
parameters described in [RFC 2215]. These values describe
properties of the path itself, irrespective of the selected QoS
control service. A value reported in this section of the ADSPEC
applies to all services unless a different, service-specific value
is also present in the ADSPEC.
- [RFC2215]で説明された一般的性質パラメタのためのデフォルトかグローバルな値。 これらの値は選択されたQoSコントロールサービスの如何にかかわらず経路自体の特性について説明します。 また、異なって、サービス特有の値もADSPECに存在していない場合、ADSPECのこのセクションで報告された値はすべてのサービスに適用されます。
- A service-specific value for one or more general
characterization parameters, if the service-specific value differs
from the default value.
- 1つ以上の一般的性質パラメタのためのサービス特有の値サービス特有の値がデフォルト値と異なっているなら。
- Values of the per-service characterization parameters defined by
each supported service.
- それぞれによって定義された1サービスあたりの特殊化パラメタの値はサービスをサポートしました。
Data in the ADSPEC is divided into blocks or fragments, each of which is associated with a specific service. This allows the adspec to carry information about multiple services, allows new services to be deployed in the future without immediately updating existing code, and allows an application which will never use a particular service to omit the ADSPEC data for that service. The structure of the ADSPEC is described in detail in Section 3.3.
ADSPECのデータはブロックか断片に分割されます。それはそれぞれ特定のサービスに関連しています。 これは、adspecが複数のサービスの情報を運ぶのを許容して、新種業務が将来すぐに既存のコードをアップデートしないで配布されるのを許容して、特定のサービスを決して利用しないアプリケーションがそのサービスのためのADSPECデータを省略するのを許容します。 ADSPECの構造はセクション3.3で詳細に説明されます。
A sender may indicate that a specific QoS control service should *not* be used by the receivers within an RSVP session. This is done by omitting all mention of that service from the ADSPEC, as described in Section 3.3. Upon arrival at a receiver, the complete absence of an ADSPEC fragment for a specific service indicates to receivers that the service should not be used.
送付者は、*ではなく、*がRSVPセッション以内に受信機によって使用されるなら特定のQoSがサービスを制御するのを示すかもしれません。 セクション3.3で説明されるようにADSPECからそのサービスのすべての言及を省略することによって、これをします。 受信機への到着のときに、特定のサービスのためのADSPEC断片の完全欠損は、サービスが利用されるべきでないのを受信機に示します。
NOTE: In RSVP Version 1, all receivers within a session are
required to choose the same QoS control service. This restriction
is imposed by the difficulty of merging reservations requesting
different QoS control services, and the current lack of a general
service replacement mechanism. The restriction may be eliminated
in the future.
以下に注意してください。 RSVPバージョン1では、セッション以内のすべての受信機が、同じQoSコントロールサービスを選ぶのに必要です。 この制限は異なったQoSコントロールサービスを要求する予約を合併するという困難、および一般的なサービス交換メカニズムの現在の不足によって課されます。 制限は将来、排除されるかもしれません。
Wroclawski Standards Track [Page 6] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[6ページ]。
Considering this restriction, it may be useful to coordinate the
receivers' selection of a QoS control service by having the
sender(s) offer only one choice, using the ADSPEC mechanism
mentioned above. All receivers must then select the same service.
Alternatively, the coordination might be accomplished by using a
higher-level session announcement and setup mechanism to inform
the receivers of the QoS control service in use, by manual
configuration of the receivers, or by an agreement protocol
running among the session receivers themselves.
この制限を考える場合、送付者に1つの選択だけを提供させることによって受信機のQoSコントロールサービスの選択を調整するのは役に立つかもしれません、前記のようにADSPECメカニズムを使用して。 そして、すべての受信機が同じサービスを選択しなければなりません。 あるいはまた、コーディネートはQoSコントロールサービスの受信機を使用中に知らせるのによりハイレベルのセッション発表とセットアップメカニズムを使用するか、受信機の手動の構成、またはセッション受信機自体の中で稼働する協定プロトコルによって実行されるかもしれません。
As with the ADSPEC, the FLOWSPEC and SENDER_TSPEC object formats
described in Section 3 are capable of carrying TSpecs and RSpecs
for more than one QoS control service in separate data fragments.
Currently, use of a FLOWSPEC or SENDER_TSPEC containing fragments
for more than one QoS control service is not supported. In the
future, this capability may be used to implement a more flexible
service request and replacement scheme, allowing applications to
obtain useful end-to-end QoS control when not all intermediate
nodes support the same set of QoS services. RSVP-application APIs
should be designed to support passing SENDER_TSPEC, FLOWSPEC, and
ADSPEC objects of variable size and containing information about
multiple QoS control services between RSVP and its clients.
ADSPECのように、_TSPECオブジェクト形式がセクション3で説明したFLOWSPECとSENDERは別々のデータの断片における1つ以上のQoSコントロールサービスのためにTSpecsとRSpecsを運ぶことができます。 現在、1つ以上のQoSコントロールサービスのための断片を含むFLOWSPECかSENDER_TSPECの使用はサポートされません。 将来、この能力は、よりフレキシブルなサービスのリクエストと交換体系を実装するのに使用されるかもしれません、すべての中間的ノードが同じセットのQoSサービスを支えるというわけではないとき、アプリケーションが終わりからエンドへのQoS役に立つコントロールを得るのを許容して。 RSVP-アプリケーションAPIは、SENDER_TSPECを渡す、FLOWSPEC、およびADSPECに可変サイズのオブジェクトを支えるように設計されていて、RSVPとそのクライアントの間に複数のQoSコントロールサービスの情報を含んでいるはずです。
2.3. Use of ADSPEC Information
2.3. ADSPEC情報の使用
This section gives some details about setting reservation parameters and the use of information conveyed by the RSVP ADSPEC object.
このセクションは予約パラメタを設定することに関するいくつかの詳細とRSVP ADSPECオブジェクトによって伝えられた情報の使用を与えます。
2.3.1. Determining the availability of a QoS control service
2.3.1. QoSコントロールサービスの有用性を決定します。
The RSVP ADSPEC carries flag bits telling the application receivers whether or not a completely reservation-capable path exists between each sender and the receiver. These bits are called "break bits", because they indicate breaks in the QoS control along a network path. Break bits are carried within the header which begins each per- service data fragment of an RSVP ADSPEC.
RSVP ADSPECは予約完全にできる経路が各送付者と受信機の間に存在するかどうかアプリケーション受信機に言うフラグビットを運びます。これらのビットは「中断ビット」と呼ばれます、彼らがネットワーク経路に沿ったQoSコントロールにおける中断を示すので。 中断ビットがそれぞれを始めるヘッダーの中に運ばれる、-、RSVP ADSPECのデータ断片を調整してください。
Service number 1 is used within the ADSPEC to identify a fragment carrying information about global parameter values that apply to all services (see [RFC 2215] for more details). The break bit in service 1's per-service header is used to tell the receiver(s) whether all of the network elements along the path from sender to receiver support RSVP and integrated services. If a receiver finds this bit set, at least one network element along the data transmission path between the ADSPEC's sender and the receiver can not provide QoS control services at all. This bit corresponds to the global NON_IS_HOP characterization parameter defined in [RFC 2215].
認識番号1は、すべてのサービスに適用されるグローバルなパラメタ値に関して情報を運ぶ断片を特定するのにADSPECの中で使用されます(その他の詳細に関して[RFC2215]を見てください)。 サービスの1つのサービスのヘッダーの中断ビットは、送付者から受信機までの経路に沿ったネットワーク要素のすべてがRSVPと統合サービスをサポートするかどうか受信機に言うのに使用されます。 受信機が、このビットがセットしたのがわかるなら、ADSPECの送付者と受信機の間のデータ伝送経路に沿った少なくとも1つのネットワーク要素は全くコントロールサービスをQoSに供給できません。 このビットはグローバルに対応しています。NON_は[RFC2215]で定義された_HOP特殊化パラメタです。
Wroclawski Standards Track [Page 7] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[7ページ]。
NOTE: If this bit is set, the values of all other parameters in
the ADSPEC are unreliable. The bit being set indicates that at
least one node along the sender-receiver path did not fully
process the ADSPEC.
以下に注意してください。 このビットが設定されるなら、ADSPECの他のすべてのパラメタの値は頼り無いです。 設定されるビットは、送付者受信機経路に沿った少なくとも1つのノードが完全にADSPECを処理したというわけではないのを示します。
Service-specific break bits tell the receiver(s) whether all of the network elements along the path from sender to receiver support a particular QoS control service. The break bit for each service is carried within the ADSPEC's per-service header for that service. If a bit is set at the receiver, at least one network element along the data transmission path supports RSVP but does not support the QoS control service corresponding to the per-service header. These bits correspond to the service-specific NON_IS_HOP characterization parameters defined in [RFC 2215].
サービス特有の中断ビットは、送付者から受信機までの経路に沿ったネットワーク要素のすべてが、特定のQoSがコントロールサービスであるとサポートするかどうか受信機に言います。 各サービスのための中断ビットはそのサービスのためにADSPECの1サービスあたりのヘッダーの中に運ばれます。 しばらくが受信機で決められるなら、データ伝送経路に沿った少なくとも1つのネットワーク要素は、RSVPをサポートしますが、QoSコントロールが1サービスあたりのヘッダーにおいて、対応するサービスであるとサポートしません。 これらのビットはサービス特有に対応しています。NON_は[RFC2215]で定義された_HOP特殊化パラメタです。
Section 3 gives more information about break bits.
セクション3は中断ビットに関する詳しい情報を与えます。
2.3.2. Determining Path MTU
2.3.2. 経路MTUを決定します。
Both Guaranteed and Controlled-Load QoS control services place an upper bound on packet size, and require that the application limit the maximum size of packets subject to resource reservation. For both services, the desired maximum packet size is a parameter of the reservation request, and the service will reject (with an admission control error) reservation requests specifying a packet size larger than that supported by the service.
GuaranteedとControlled-負荷QoSコントロールサービスの両方が、パケットサイズに上限を置いて、アプリケーションが資源予約を条件としてパケットの最大サイズを制限するのを必要とします。 両方のサービスのために、必要な最大のパケットサイズは予約の要請のパラメタです、そして、サービスはサービスでサポートされたそれより大きいパケットサイズを指定する予約の要請を拒絶するでしょう(入場コントロール誤りで)。
Since RSVP reservation requests are made by receivers, this implies that the *receivers* in an RSVP session, as well as the senders, need to know the MTU supported by the QoS control services along a data path. Further, in some unusual cases the MTU supported by a QoS control service may differ from that supported by the same router when providing best effort service.
RSVP予約の要請が受信機によって作られるので、これは、RSVPセッションにおける*受信機*、および送付者が、MTUが、データ経路に沿ってQoSでコントロールがサービスであるとサポートしたのを知る必要であるのを含意します。 さらに、いくつかの珍しい場合では、QoSコントロールサービスでサポートされたMTUはベストエフォート型サービスを提供するとき同じルータによってサポートされたそれと異なるかもしれません。
A scalable form of MTU negotiation is used to address these problems. MTU negotiation in an RSVP system works as follows:
スケーラブルな形式のMTU交渉は、これらのその問題を訴えるのに使用されます。RSVPシステムにおけるMTU交渉は以下の通り働いています:
- Each sending application joining an RSVP session fills in the M
(maximum packet size) parameter in its generated Sender_TSpec
(carried from senders to receivers in a SENDER_TSPEC object) with
the maximum packet size it wishes to send covered by resource
reservation.
- RSVPセッションに参加するそれぞれの送付アプリケーションが資源予約でカバーされて、それが送りたがっている最大のパケットサイズで発生しているSender_TSpec(SENDER_TSPECオブジェクトで送付者から受信機まで運ばれる)のM(最大のパケットサイズ)パラメタに記入します。
- Each RSVP PATH message from a sending application also carries
an ADSPEC object containing at least one PATH_MTU characterization
parameter. When it arrives at the receiver, this parameter gives
the minimum MTU at any point along the path from sender to
receiver. Generally, only the "global" PATH_MTU parameter
- また、送付アプリケーションからのそれぞれのRSVP PATHメッセージは少なくとも1つのPATH_MTU特殊化パラメタを含むADSPECオブジェクトを運びます。 受信機に到着するとき、このパラメタは経路に沿った任意な点で受信機送付者から「グローバルな」PATH_MTUパラメタだけまで最小のMTUに与えます。
Wroclawski Standards Track [Page 8] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[8ページ]。
(service 1, parameter 9) will be present, in which case its value
is a legal MTU for all reservation requests. If a service specific
PATH_MTU parameter is present, its value will be smaller than that
of the global parameter, and should be used for reservation
requests for that service.
(サービス1、パラメタ9)が存在する、その場合、値はすべての予約の要請のための法的なMTUです。 特定のPATH_MTUパラメタがサービスであるなら存在していて、値は、グローバルなパラメタでそれより小さく、そのサービスのための予約の要請に使用されるべきです。
- Each receiver takes the minimum of all the PATH_MTU values (for
the desired QoS control service) arriving in ADSPEC messages from
different senders and uses that value as the MTU in its
reservation requests. This value is used to fill in the M
parameter of the TSpec created at the receiver. In the case of a
FF style reservation, a receiver may also choose to use the MTU
derived from each sender's ADSPEC in the FLOWSPEC generated for
that sender, if the receiver is concerned about obtaining the
maximum MTU on each data path. To accomodate changes in the data
path, the receiver may continue to watch the arriving ADSPECS, and
modify the reservation if a newly arriving ADSPEC indicates a
smaller MTU than is currently in use.
- 各受信機は、異なった送付者からのADSPECメッセージに到着しながらすべてのPATH_MTU値(必要なQoSコントロールサービスのための)の最小限を取って、MTUとして予約の要請でその値を使用します。 この値は、TSpecのパラメタが受信機で作成したMに記入するのに使用されます。また、FFスタイルの予約の場合では、受信機は、その送付者のために生成されたFLOWSPECで各送付者のADSPECから得られたMTUを使用するのを選ぶかもしれません、受信機が各データ経路で最大のMTUを入手することに関して心配しているなら。 データ経路のaccomodate変化に、新たに到着しているADSPECが現在使用中であるより小さいMTUを示すなら、受信機は、ずっと到着しているADSPECSを見て、予約を変更するかもしれません。
- As reservation requests (RESV messages) move from receivers to
senders, reservation parameters are merged at intermediate nodes.
As part of this merging, the smaller of two M parameters arriving
at a merge point will be forwarded in the upstream RESV message.
- 予約の要請(RESVメッセージ)が受信機から送付者まで移行するとき、予約パラメタは中間的ノードで合併されています。 この合併の一部として、2Mが、上流のRESVメッセージでマージポイントに到着するのを送るパラメタは、より小さいです。
- As reservation requests arrive at intermediate RSVPs, the
minimum of the receivers' requested TSpec and the sum of the
sender TSpecs is taken, and a reservation for the resulting TSpec
is made. The reservation will use the smaller of the actual path
MTU value computed by the receivers and the largest maximum packet
size declared by any of the sender(s). (The TSpec sum() function
result's M parameter is the max of the summed TSpec M parameters).
- 予約の要請が中間的RSVPsに到着するので、受信機の最小限は、送付者TSpecsのTSpecと合計が取られるよう要求しました、そして、結果として起こるTSpecの予約をします。 予約は受信機によって計算された実際の経路MTU価値で、より小さくて送付者のどれかによって宣言された中で最も大きい最大のパケットサイズを使用するでしょう。 (TSpec合計()関数結果MのパラメタはまとめられたTSpec Mパラメタの最大です。)
- When the completely merged RESV message arrives at each sender,
the MTU value (M parameter) in the merged FLOWSPEC object will
have been set to the smallest acceptable MTU of the data paths
from that sender to any session receiver. This MTU should be used
by the sending application to size its packets. Any packets larger
than this MTU may be delivered as best-effort rather than being
covered by the session's resource reservation.
- 完全に合併しているRESVメッセージが各送付者に到着するとき、合併しているFLOWSPECオブジェクトのMTU値(Mパラメタ)はその送付者からどんなセッション受信機までのデータ経路の最も小さい許容できるMTUにも設定されてしまうでしょう。このMTUは送付アプリケーションで使用されるべきです。サイズへのそのパケット。 このMTUよりセッションの資源予約でカバーされているより大きいどんなパケットもベストエフォート型としてむしろ提供されるかもしれません。
Note that senders do *not* adjust the value of their
Sender_TSpec's M field to match the actual packet size selected in
this step. The value of M represents the largest packet the sender
could send, not the largest packet the sender is currently
sending.
送付者がこのステップで選択された実際のパケットサイズを合わせるために彼らのSender_TSpec Mの分野の値を*でないのが調整する*にすることに注意してください。 Mの値は送付者が現在送る中で最も大きいパケットではなく、送付者が送ることができた中で最も大きいパケットを表します。
Wroclawski Standards Track [Page 9] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[9ページ]。
Note that the scheme above will allow each sender in a session to use the largest MTU appropriate for that sender, in cases where different data paths or receivers have different acceptable MTU's.
異なったデータ経路か受信機が異なったMTUの許容できるものを持っている場合でセッションにおける各送付者が上の体系でその送付者にとって、適切な最も大きいMTUを使用できることに注意してください。
3. RSVP Object Formats
3. RSVPオブジェクト形式
This section specifies the detailed contents and wire format of RSVP SENDER_TSPEC, ADSPEC, and FLOWSPEC objects for use with the Guaranteed and Controlled-Load QoS control services. The object formats specified here are based on the general message construction rules given in Appendix 1.
このセクションはGuaranteedとControlled-負荷QoSコントロールサービスでRSVP SENDER_TSPEC、ADSPEC、およびFLOWSPECオブジェクトの詳細なコンテンツとワイヤ形式を使用に指定します。 ここで指定されたオブジェクト形式はAppendix1で与えられた一般的なメッセージ構成規則に基づいています。
3.1. RSVP SENDER_TSPEC Object
3.1. RSVP送付者_TSPECオブジェクト
The RSVP SENDER_TSPEC object carries information about a data source's generated traffic. The required RSVP SENDER_TSPEC object contains a global Token_Bucket_TSpec parameter (service_number 1, parameter 127, as defined in [RFC 2215]). This TSpec carries traffic information usable by either the Guaranteed or Controlled-Load QoS control services.
RSVP SENDER_TSPECオブジェクトはデータ送信端末の発生しているトラフィックの情報を運びます。 必要なRSVP SENDER_TSPECオブジェクトはグローバルな_Token_Bucket TSpecを含んでいます。パラメタ(サービス_No.1、中で定義されるとしてのパラメタ127[RFC2215])。 このTSpecはコントロールが調整するGuaranteedかControlled-負荷QoSのどちらかが使用可能な道路交通情報を運びます。
Wroclawski Standards Track [Page 10] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[10ページ]。
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a)| 予約されます。| 7 (b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c)|0| 予約されます。| 6 (d)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e)| 0 (f)| 5 (g)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | トークンBucket Rate[r](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | トークンBucket Size[b](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | ピークData Rate[p](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 最小のPoliced Unit[m](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 最大のPacket Size[M](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 1 (default/global information)
(d) - Length of service 1 data, 6 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including header
(a)--メッセージ・フォーマットバージョン数(0)(b)--全長(ヘッダーを含まない7つの単語)(c)--サービスヘッダー、勤続年数1データ、ヘッダー(e)を含まない6つの単語--Parameter ID、パラメタ127(トークン_Bucket_TSpec)(f)--パラメタ127が(g)に旗を揚げさせるという(なにもセットしませんでした)1(デフォルト/グローバルな情報)(d)の認識番号パラメタ127の長さ、ヘッダーを含まない5つの単語
In this TSpec, the parameters [r] and [b] are set to reflect the sender's view of its generated traffic. The peak rate parameter [p] may be set to the sender's peak traffic generation rate (if known and controlled), the physical interface line rate (if known), or positive infinity (if no better value is available). Positive infinity is represented as an IEEE single-precision floating-point number with an exponent of all ones (255) and a sign and mantissa of all zeros. The format of IEEE floating-point numbers is further summarized in [RFC 1832].
このTSpecでは、パラメタ[r]と[b]が発生しているトラフィックに関する送付者の意見を反映するように設定されます。 ピークレートパラメタ[p]はトラフィック世代が評定する送付者のピークに設定されるかもしれません(知られて、制御されるなら)、物理的なインタフェースライン料率(知られているなら)の、または、陽の無限(どんなより良い値も利用可能でないなら)。 陽の無限はIEEEの単精度の浮動小数点の番号としてすべてのゼロのすべてのもの(255)の解説者、サイン、および仮数で表されます。 IEEEの浮動小数点の番号の書式は[RFC1832]にさらにまとめられます。
The minimum policed unit parameter [m] should generally be set equal to the size of the smallest packet generated by the application. This packet size includes the application data and all protocol headers at or above the IP level (IP, TCP, UDP, RTP, etc.). The size given does not include any link-level headers, because these headers will change as the packet crosses different portions of the internetwork.
一般に、最小の取り締まられたユニットパラメタ[m]はアプリケーションで生成される中で最も小さいパケットのサイズと等しいセットであるべきです。 このパケットサイズはレベルにおいて、または、IPレベル(IP、TCP、UDP、RTPなど)を超えてアプリケーションデータとすべてのプロトコルヘッダーを含んでいます。 与えられたサイズはどんなリンク・レベルヘッダーも含んでいません、パケットがインターネットワークの異なった部分を越えるのに応じてこれらのヘッダーが変化するので。
Wroclawski Standards Track [Page 11] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[11ページ]。
The [m] parameter is used by nodes within the network to compute the maximum bandwidth overhead needed to carry a flow's packets over the particular link-level technology, based on the ratio of [m] to the link-level header size. This allows the correct amount of bandwidth to be allocated to the flow at each point in the net. Note that smaller values of this parameter lead to increased overhead estimates, and thus increased likelyhood of a reservation request being rejected by the node. In some cases, an application transmitting a low percentage of very small packets may therefore choose to set the value of [m] larger than the actual minimum transmitted packet size. This will increase the likelyhood of the reservation succeeding, at the expense of policing packets of size less than [m] as if they were of size [m].
[m]パラメタはネットワークの中のノードによって使用されて、特定のリンク・レベル技術の上まで流れのパケットを運ぶのに必要である最大の帯域幅オーバーヘッドを計算します、[m]対リンク・レベルヘッダーサイズの比率に基づいて。 これは、正しい量の帯域幅がネットで各ポイントでの流れに割り当てられるのを許容します。 このパラメタの、より小さい値が増強された頭上の見積り、およびノードによって拒絶される予約の要請のこのようにして増強された「ありそう-時代」につながることに注意してください。 いくつかの場合、したがって、低百分率の非常に小さいパケットを伝えるアプリケーションは、実際の最小限がパケットサイズを伝えたより大きい[m]の値を設定するのを選ぶかもしれません。 これは予約成功の「ありそう-時代」を増強するでしょう、まるでそれらがサイズ[m]のものであるかのように[m]ほどサイズのパケットを取り締まらないことを犠牲にして。
Note that the an [m] value of zero is illegal. A value of zero would indicate that no data or IP headers are present, and would give an infinite amount of link-level overhead.
それに注意してください、ゼロの[m]値は不法です。 ゼロの値は、データかどんなIPヘッダーも出席していないのを示して、無限の量のリンク・レベルオーバーヘッドを与えるでしょう。
The maximum packet size parameter [M] should be set to the size of the largest packet the application might wish to generate, as described in Section 2.3.2. This value must, by definition, be equal to or larger than the value of [m].
最大のパケットサイズ・パラメータ[M]はアプリケーションが生成したがっているかもしれない中で最も大きいパケットのサイズに設定されるべきです、セクション2.3.2で説明されるように。 [m]では、この値は、定義上等しいか、または値より大きくなければなりません。
3.2. RSVP FLOWSPEC Object
3.2. RSVP FLOWSPECオブジェクト
The RSVP FLOWSPEC object carries information necessary to make reservation requests from the receiver(s) into the network. This includes an indication of which QoS control service is being requested, and the parameters needed for that service.
RSVP FLOWSPECオブジェクトは受信機からの予約の要請を(s)にするのに必要な情報をネットワークまで運びます。 これはQoSコントロールサービスが要求されている指示、およびそのサービスに必要であるパラメタを含んでいます。
The QoS control service requested is indicated by the service_number in the FLOWSPEC's per-service header.
サービスが要求したQoSコントロールはFLOWSPECの1サービスあたりのヘッダーでサービス_数によって示されます。
3.2.1 FLOWSPEC object when requesting Controlled-Load service
3.2.1 Controlled-負荷サービスを要求するとき、FLOWSPECは反対します。
The format of an RSVP FLOWSPEC object originating at a receiver requesting Controlled-Load service is shown below. Each of the TSpec fields is represented using the preferred concrete representation specified in the 'Invocation Information' section of [RFC 2211]. The value of 5 in the per-service header (field (c), below) indicates that Controlled-Load service is being requested.
Controlled-負荷サービスを要求しながら受信機で起因するRSVP FLOWSPECオブジェクトの書式は以下に示されます。 それぞれのTSpec分野は、[RFC2211]の'実施の情報'セクションで指定された都合のよい具体的な表現を使用することで表されます。 1サービスあたりのヘッダー(下の分野(c))の5の値は、Controlled-負荷サービスが要求されているのを示します。
Wroclawski Standards Track [Page 12] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[12ページ]。
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 5 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a)| 予約されます。| 7 (b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (c)|0| 予約されます。| 6 (d)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e)| 0 (f)| 5 (g)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | トークンBucket Rate[r](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | トークンBucket Size[b](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | ピークData Rate[p](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 最小のPoliced Unit[m](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 最大のPacket Size[M](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 5 (Controlled-Load)
(d) - Length of controlled-load data, 6 words not including
per-service header
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including per-service
header
(a)--メッセージ・フォーマットバージョン数(0)(b)--全長(ヘッダーを含まない7つの単語)(c)--サービスヘッダー、認識番号5の(制御負荷)の(d)--制御負荷データ、1サービスあたりのヘッダー(e)を含まない6つの単語の長さ--Parameter ID、パラメタ127(トークンBucket TSpec)(f)--パラメタ127旗(なにもセットしなかった)の(g)--パラメタ127の長さ、1サービスあたりのヘッダーを含まない5つの単語
In this object, the TSpec parameters [r], [b], and [p] are set to reflect the traffic parameters of the receiver's desired reservation (the Reservation TSpec). The meaning of these fields is discussed fully in [RFC 2211]. Note that it is unlikely to make sense for the [p] term to be smaller than the [r] term.
このオブジェクトでは、TSpecパラメタ[r]、[b]、および[p]が受信機の必要な条件(予約TSpec)のトラフィックパラメタを反映するように設定されます。 [RFC2211]でこれらの分野の意味について完全に議論します。 [p]用語のときに[r]用語より小さくなるように理解できそうにないことに注意してください。
The maximum packet size parameter [M] should be set to the value of the smallest path MTU, which the receiver learns from information in arriving RSVP ADSPEC objects. Alternatively, if the receiving application has built-in knowledge of the maximum packet size in use within the RSVP session, and this value is smaller than the smallest path MTU, [M] may be set to this value. Note that requesting a value of [M] larger than the service modules along the data path can support will cause the reservation to fail. See section 2.3.2 for further discussion of the MTU value.
最大のパケットサイズ・パラメータ[M]は最も小さい経路MTUの値に設定されるべきです。(受信機は到着しているRSVP ADSPECオブジェクトの情報からMTUを学びます)。 あるいはまた、受信アプリケーションにはRSVPセッション中に使用中の最大のパケットサイズに関する内蔵の知識があって、この値が最も小さい経路MTUより小さいなら、[M]はこの値に設定されるかもしれません。 失敗するようデータ経路に沿ったモジュールがサポートすることができるサービスが予約を引き起こすより大きい[M]の値に要求して、それに注意してください。 MTU価値のさらなる議論に関してセクション2.3.2を見てください。
Wroclawski Standards Track [Page 13] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[13ページ]。
The value of [m] can be chosen in several ways. Recall that when a resource reservation is installed at each intermediate node, the value used for [m] is the smaller of the receiver's request and the values in each sender's SENDER_TSPEC.
いくつかの方法で[m]の値を選ぶことができます。 資源予約がそれぞれの中間的ノードにインストールされるとき、各送付者のSENDER_TSPECでは、受信機の要求と値で[m]に使用される値が、より小さいと思い出してください。
If the application has a fixed, known minimum packet size, than that value should be used for [m]. This is the most desirable case.
アプリケーションがそれより修理されて、知られている最小のパケットサイズにそうしたなら、値は[m]に使用されるべきです。 これは最も望ましいそうです。
For a shared reservation style, the receiver may choose between two options, or pick some intermediate point between them.
共有された予約スタイルのために、受信機は、2つのオプションを選ぶか、またはそれらの間の何らかの中間的ポイントを選ぶかもしれません。
- if the receiver chooses a large value for [m], then the
reservation will allocate less overhead for link-level headers.
However, if a new sender with a smaller SENDER_TSPEC [m] joins the
session later, an already-installed reservation may fail at that
time.
- 受信機が[m]のための大きい値を選ぶと、予約はリンク・レベルヘッダーのために、より少ないオーバーヘッドを割り当てるでしょう。 しかしながら、より小さいSENDER_TSPEC[m]をもっている新しい送付者が後でセッションに参加するなら、既にインストールされた予約はその時、失敗するかもしれません。
- if the receiver chooses a value of [m] equal to the smallest
value which might be used by any sender, then the reservation will
be forced to allocate more overhead for link-level headers.
However it will not fail later if a new sender with a smaller
SENDER_TSPEC [m] joins the session.
- 受信機がどんな送付者によっても使用されるかもしれない中で最も小さい値に[m] 同輩の値を選ぶと、予約はリンク・レベルヘッダーのためにやむを得ずより多くのオーバーヘッドを割り当てるでしょう。 しかしながら、より小さいSENDER_TSPEC[m]をもっている新しい送付者がセッションに参加すると、それは後で失敗しないでしょう。
For a FF reservation style, if no application-specific value is known the receiver should simply use the value of [m] arriving in each sender's SENDER_TSPEC for its reservation request to that sender.
FF予約スタイルのために、どんなアプリケーション特有の値も知られていないなら、受信機は、その送付者への予約の要請のために各送付者のSENDER_TSPECに到着しながら、単に[m]の値を使用するはずです。
3.2.2. FLOWSPEC Object when Requesting Guaranteed Service
3.2.2. FLOWSPEC Object、Requesting Guaranteed Serviceです。
The format of an RSVP FLOWSPEC object originating at a receiver requesting Guaranteed service is shown below. The flowspec object used to request guaranteed service carries a TSpec and RSpec specifying the traffic parameters of the flow desired by the receiver.
Guaranteedサービスを要求しながら受信機で起因するRSVP FLOWSPECオブジェクトの書式は以下に示されます。 flowspecオブジェクトは、以前はよく保証されたサービスが受信機によって望まれていた流れのトラフィックパラメタを指定するTSpecとRSpecを運ぶよう要求していました。
Each of the TSpec and RSpec fields is represented using the preferred concrete representation specified in the 'Invocation Information' section of [RFC 2212]. The value of 2 for the service header identifier (field (c) in the picture below) indicates that Guaranteed service is being requested.
それぞれのTSpecとRSpec分野は、[RFC2212]の'実施の情報'セクションで指定された都合のよい具体的な表現を使用することで表されます。 サービスヘッダー識別子(以下の画像における分野(c))のための2の値は、Guaranteedサービスが要求されているのを示します。
Wroclawski Standards Track [Page 14] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[14ページ]。
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Unused | 10 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 2 (c) |0| reserved | 9 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 130 (h) | 0 (i) | 2 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Rate [R] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Slack Term [S] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a)| 未使用| 10 (b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c)|0| 予約されます。| 9 (d)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e)| 0 (f)| 5 (g)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | トークンBucket Rate[r](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | トークンBucket Size[b](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | ピークData Rate[p](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 最小のPoliced Unit[m](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 最大のPacket Size[M](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 130 (h)| 0 (i)| 2 (j)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | レート[R](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | ゆるみTerm[S](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (9 words not including header)
(c) - Service header, service number 2 (Guaranteed)
(d) - Length of per-service data, 9 words not including per-service
header
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including parameter header
(h) - Parameter ID, parameter 130 (Guaranteed Service RSpec)
(i) - Parameter 130 flags (none set)
(j) - Parameter 130 length, 2 words not including parameter header
(a)--メッセージ・フォーマットバージョン数(0)(b)--全長(ヘッダーを含まない9つの単語)(c)--認識番号2(保証されます)(d)--1サービスあたりのデータ、1サービスあたりのヘッダー(e)を含まない9つの単語の長さ--ヘッダー、Parameter IDを修理してください; パラメタ127(トークンBucket TSpec)(f)--パラメタ127旗パラメタ130(保証されたService RSpec)(i)--パラメタ130旗(なにもセットしなかった)の(j)--(g)--パラメタ127の長さ、パラメタヘッダー(h)を含まない5つの単語--Parameter ID、パラメタ130の長さ(なにもセットしませんでした)、パラメタヘッダーを含まない2つの単語
In this object, the TSpec parameters [r], [b], and [p] are set to reflect the traffic parameters of the receiver's desired reservation (the Reservation TSpec). The meaning of these fields is discussed fully in [RFC 2212]. Note that it is unlikely to make sense for the [p] term to be smaller than the [r] term.
このオブジェクトでは、TSpecパラメタ[r]、[b]、および[p]が受信機の必要な条件(予約TSpec)のトラフィックパラメタを反映するように設定されます。 [RFC2212]でこれらの分野の意味について完全に議論します。 [p]用語のときに[r]用語より小さくなるように理解できそうにないことに注意してください。
The RSpec terms [R] and [S] are selected to obtain the desired bandwidth and delay guarantees. This selection is described in [RFC 2212].
RSpec用語[R]と[S]が必要な帯域幅と遅れ保証を得るのが選択されます。 この選択は[RFC2212]で説明されます。
Wroclawski Standards Track [Page 15] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[15ページ]。
The [m] and [M] parameters are set identically to those for the Controlled-Load service FLOWSPEC, described in the previous section.
[m]と[M]パラメタは前項で説明されたControlled-負荷サービスFLOWSPECのために同様にそれらに設定されます。
3.3. RSVP ADSPEC Object
3.3. RSVP ADSPECオブジェクト
An RSVP ADSPEC object is constructed from data fragments contributed by each service which might be used by the application. The ADSPEC begins with an overall message header, followed by a fragment for the default general parameters, followed by fragments for every QoS control service which may be selected by application receivers. The size of the ADSPEC varies depending on the number and size of per- service data fragments present and the presence of non-default general parameters (described in Section 3.3.5).
RSVP ADSPECオブジェクトはアプリケーションで利用されるかもしれない各サービスで寄付されたデータの断片から組み立てられます。 ADSPECはデフォルトのために一般的指標であって、続いている断片ごとにアプリケーション受信機によって選択されるかもしれないあらゆるQoSコントロールサービスのために支えた総合的なメッセージヘッダーと共に始まります。 ADSPECのサイズが数に依存して、サイズを変える、-、断片が提示するデータと非デフォルト一般的指標(セクション3.3.5では、説明される)の存在を修理してください。
The complete absence of a data fragment for a particular service means that the application sender does not know or care about that service, and is a signal to intermediate nodes not to add or update information about that service to the ADSPEC. It is also a signal to application receivers that they should not select that service when making reservations.
特定のサービスのためのデータ断片の完全欠損は、ADSPECに対するそのサービスの情報を加えないか、またはアップデートしないようにアプリケーション送付者がそのサービスを知りもしませんし、心配もしないで、中間的ノードへの信号であることを意味します。 また、それはアプリケーション受信機への予約をするとき、彼らがそのサービスを選択するべきでないという信号です。
Each fragment present is identified by a per-service data header. Each header contains a field identifying the service, a break bit, and a length field.
それぞれの断片プレゼントは1サービスあたり1個のデータヘッダーによって特定されます。 各ヘッダーはサービスを特定する分野、中断ビット、および長さの分野を含んでいます。
The length field allows the ADSPEC information for a service to be skipped over by a network elements which does not recognize or implement the service. When an element does this, it sets the break bit, indicating that the service's ADSPEC data was not updated at at least one hop. Note that a service's break bit can be set without otherwise supporting the service in any way. In all cases, a network element encountering a per-service data header it does not understand simply sets bit 23 to report that the service is not supported, then skips over the rest of the fragment.
長さの分野は、サービスがネットワーク要素によって飛ばされるためにADSPEC情報を許容します(サービスを認識もしませんし、実装もしません)。 要素がこれをすると、中断ビットを設定します、少なくともワンバウンドでサービスのADSPECデータをアップデートしなかったのを示して。 そうでなければ、何らかの方法でサービスをサポートしないでサービスの中断ビットを設定できることに注意してください。 すべての場合では、それが単に理解していない1サービスあたり1個のデータヘッダーに遭遇するネットワーク要素は、ビット23にサービスがサポートされないと報告するように設定して、次に、断片の残りを飛ばします。
Data fragments must always appear in an ADSPEC in service_number order. In particular, the default general parameters fragment (service_number 1) always comes first.
データの断片はADSPECの使用中の_数のオーダーにいつも現れなければなりません。 特に、デフォルト一般的指標断片(サービス_No.1)はいつも一番になります。
Within a data fragment, the service-specific data must alway come first, followed by any non-default general parameters which may be present, ordered by parameter_number. The size and structure of the service-specific data is fixed by the service definition, and does not require run-time parsing. The remainder of the fragment, which carries non-default general parameters, varies in size and structure depending on which, if any, of these parameters are present. This part of the fragment must be parsed by examining the per-parameter headers.
断片、サービス特有のデータがそうしなければならないデータの中では、alwayはどんな存在するかもしれない非デフォルト一般的指標でも、一番になって、続きました、パラメタ_数によって命令されて。 サービス特有のデータのサイズと構造は、サービス定義で修理されていて、ランタイム構文解析を必要としません。 これらのパラメタのどれかはそうです。断片の残り(非デフォルト一般的指標を運ぶ)がサイズと構造依存において異なる、どれ、存在しているか。 1パラメタあたりのヘッダーを調べることによって、断片のこの部分を分析しなければなりません。
Wroclawski Standards Track [Page 16] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[16ページ]。
Since the overall size of each data fragment is variable, it is always necessary to examine the length field to find the end of the fragment, rather than assuming a fixed-size structure.
それぞれのデータ断片の総合的なサイズが可変であるので、固定サイズ構成を仮定するよりむしろ断片の端を見つけるために長さの分野を調べるのがいつも必要です。
3.3.1. RSVP ADSPEC format
3.3.1. RSVP ADSPEC形式
The basic ADSPEC format is shown below. The message header and the default general parameters fragment are always present. The fragments for Guaranteed or Controlled-Load service may be omitted if the service is not to be used by the RSVP session. Additional data fragments will be added if new services are defined.
基本的なADSPEC書式は以下に示されます。 メッセージヘッダーとデフォルト一般的指標断片はいつも出席しています。 Guaranteedのための断片かControlled-負荷サービスがサービスがRSVPセッションで使用されないことであるなら省略されるかもしれません。 新種業務が定義されると、追加データの断片は加えられるでしょう。
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (a) | reserved | Msg length - 1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Default General Parameters fragment (Service 1) (c) |
| (Always Present) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Guaranteed Service Fragment (Service 2) (d) |
| (Present if application might use Guaranteed Service) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Controlled-Load Service Fragment (Service 5) (e) |
| (Present if application might use Controlled-Load Service) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (a)| 予約されます。| エムエスジーの長さ--1(b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | デフォルト一般Parameters断片(サービス1)(c)| | (いつも現在)です。 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 保証されたサービス断片(サービス2)(d)| | (プレゼントはアプリケーションであるならGuaranteed Serviceを使用するかもしれません) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 制御負荷サービス断片(サービス5)(e)| | (プレゼントはアプリケーションであるならControlled-負荷Serviceを使用するかもしれません) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall message length not including header word
(c, d, e) - Data fragments
(a)--メッセージ・フォーマットバージョン数(0)(b)--ヘッダー単語(c、d、e)を含まない総合的なメッセージ長--データの断片
3.3.2. Default General Characterization Parameters ADSPEC data fragment
3.3.2. 一般Characterization Parameters ADSPECデータが断片化するデフォルト
All RSVP ADSPECs carry the general characterization parameters defined in [RFC 2215]. Values for global or default general parameters (values which apply to the all services or the path itself) are carried in the per-service data fragment for service number 1, as shown in the picture above. This fragment is always present, and always first in the message.
すべてのRSVP ADSPECsが[RFC2215]で定義された一般的性質パラメタを運びます。 または、グローバルであるかデフォルト一般的なパラメタのための値、(申し込む値、すべてが修理する、経路自体) 1サービスあたりのデータ断片では、認識番号1のために、上の画像で示されるように、運ばれます。 この断片は、いつもプレゼントと、いつもメッセージの1番目です。
Wroclawski Standards Track [Page 17] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[17ページ]。
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 1 (c) |x| reserved | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 4 (e) | (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | IS hop cnt (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Composed MTU (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 1 (c)|x| 予約されます。| 8 (d)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 4 (e)| (f) | 1 (g)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | ホップcnt(32ビットの符号のない整数)です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 6 (h)| (i) | 1 (j)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | 経路b/w見積り(32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 8 (k)| (l) | 1 (m)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 最小の経路潜在(32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 10 (n)| (o) | 1 (p)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 落ち着いたMTU(32ビットの符号のない整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(c) - Per-Service header, service number 1 (Default General
Parameters)
(d) - Global Break bit ([RFC 2215], Parameter 2) (marked x) and
length of General Parameters data block.
(e) - Parameter ID, parameter 4 (Number-of-IS-hops param from
[RFC 2215])
(f) - Parameter 4 flag byte
(g) - Parameter 4 length, 1 word not including header
(h) - Parameter ID, parameter 6 (Path-BW param from [RFC 2215])
(i) - Parameter 6 flag byte
(j) - Parameter 6 length, 1 word not including header
(k) - Parameter ID, parameter 8 (minimum path latency from [RFC
2215])
(l) - Parameter 8 flag byte
(m) - Parameter 8 length, 1 word not including header
(n) - Parameter ID, parameter 10 (composed path MTU from [RFC 2215])
(o) - Parameter 10 flag byte
(p) - Parameter 10 length, 1 word not including header
(c)--1サービスあたりのヘッダー、認識番号1(デフォルトParameters司令官)(d)--グローバルなBreakは[RFC2215](Parameter2) (著しいx)と長さの一般Parametersデータ・ブロック)に噛み付きました。 (e) - パラメタID、パラメタ4、(数、ホップである、ヘッダー(h)を含まない1つの単語--Parameter ID、パラメタ6(RFC2215からの経路-BW param)(i)--パラメタ6フラグバイト(j)--パラメタ6の長さ、ヘッダー(k)を含まない1つの単語--RFC2215からのparam) (f)--パラメタ4フラグバイト(g)--パラメタ4の長さ、Parameter ID; パラメタ8(RFC2215からの最小の経路潜在)(l)--パラメタ10(RFC2215から経路MTUを構成します)(o)--パラメタ10フラグバイト(p)--パラメタ8フラグバイト(m)--パラメタ8の長さ、ヘッダー(n)を含まない1つの単語--Parameter ID、パラメタ10の長さ、ヘッダーを含まない1つの単語
Rules for composing general parameters appear in [RFC 2215].
一般的指標を構成するための規則は[RFC2215]に現れます。
In the above fragment, the global break bit (bit 23 of word 1, marked with (x) in the picture) is used to indicate the existence of a network element not supporting QoS control services somewhere in the data path. This bit is cleared when the ADSPEC is created, and set to one if a network element which does not support RSVP or integrated
上の断片では、グローバルな中断ビット(画像における(x)でマークされて、23のWord1に噛み付く)は、データ経路のどこかでQoSコントロールがサービスであるとサポートしないネットワーク要素の存在を示すのに使用されます。 このビットは、ADSPECが作成されるとき、きれいにされて、RSVPをサポートしないネットワーク要素であるなら1つに設定されるか、または統合されます。
Wroclawski Standards Track [Page 18] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[18ページ]。
services is encountered. An ADSPEC arriving at a receiver with this bit set indicates that all other parameters in the ADSPEC may be invalid, since not all network elements along the path support updating of the ADSPEC.
サービスは遭遇します。 このビットがセットして受信機に到着するADSPECは、ADSPECの他のすべてのパラメタが無効であるかもしれないことを示します、経路に沿ったすべてのネットワーク要素がADSPECのアップデートをサポートするというわけではないので。
The general parameters are updated at every network node which supports RSVP:
RSVPを支えるあらゆるネットワーク・ノードで一般的指標をアップデートします:
- When a PATH message ADSPEC encounters a network element
implementing integrated services, the portion of the ADSPEC
associated with service number 1 is passed to the module
implementing general parameters. This module updates the global
general parameters.
- PATHメッセージであるときに、ADSPECは統合サービスを実装するネットワーク要素に遭遇します、一般的指標を実装するモジュールへのNo.1が通過されるサービスに関連しているADSPECの一部。 このモジュールはグローバルな一般的指標をアップデートします。
- When a PATH message ADSPEC encounters a network element that
does *not* support RSVP or implement integrated services, the
break bit in the general parameters service header must be set. In
practice, this bit will usually be set by another network element
which supports RSVP, but has been made aware of the gap in
integrated services coverage.
- ADSPECがどんな**サポートRSVPもしないネットワーク要素か道具に遭遇するというPATHメッセージがサービスを統合したとき、一般的指標サービスヘッダーの中断ビットを設定しなければなりません。 実際には、このビットをRSVPをサポートする別のネットワーク要素で通常設定しますが、統合サービス適用範囲でギャップを意識するようにしました。
- In either case, the ADSPEC is passed back to RSVP for delivery
to the next hop along the path.
- どちらの場合ではも、ADSPECは経路に沿った次のホップへの配送のためにRSVPに戻されます。
3.3.3. Guaranteed Service ADSPEC data fragment
3.3.3. 保証されたService ADSPECデータ断片
The Guaranteed service uses the RSVP ADSPEC to carry data needed to compute the C and D terms passed from the network to the application. The minimum size of a non-empty guaranteed service data fragment is 8 32-bit words. The ADSPEC fragment for Guaranteed service has the following format:
GuaranteedサービスはCを計算するのに必要であるデータを運ぶのにRSVP ADSPECを使用します、そして、D用語はネットワークからアプリケーションまで経過しました。 非空の保証されたサービスデータ断片の最小規模は8つの32ビットの単語です。 GuaranteedサービスのためのADSPEC断片には、以下の形式があります:
Wroclawski Standards Track [Page 19] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[19ページ]。
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |x| reserved | N-1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 133 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 134 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 135 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 136 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Service-specific general parameter headers/values, if present |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 2 (a) |x| reserved | N-1 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 133 (c) | 0 (d) | 1 (e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | End-to-end composed value for C [Ctot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 134 (f) | (g) | 1 (h) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | End-to-end composed value for D [Dtot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 135 (i) | (j) | 1 (k) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Since-last-reshaping point composed C [Csum] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 136 (l) | (m) | 1 (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Service-specific general parameter headers/values, if present | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . N | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 2 (Guaranteed)
(b) - Break bit and Length of per-service data in 32-bit
words not including header word.
(c) - Parameter ID, parameter 133 (Composed Ctot)
(d) - Parameter 133 flag byte
(e) - Parameter 133 length, 1 word not including header
(f) - Parameter ID, parameter 134 (Composed Dtot)
(g) - Parameter 134 flag byte
(h) - Parameter 134 length, 1 word not including header
(i) - Parameter ID, parameter 135 (Composed Csum).
(j) - Parameter 135 flag byte
(k) - Parameter 135 length, 1 word not including header
(l) - Parameter ID, parameter 136 (Composed Dsum).
(m) - Parameter 136 flag byte
(n) - Parameter 136 length, 1 word not including header
(a) - Per-Service header, service number 2 (Guaranteed) (b) - Break bit and Length of per-service data in 32-bit words not including header word. (c) - Parameter ID, parameter 133 (Composed Ctot) (d) - Parameter 133 flag byte (e) - Parameter 133 length, 1 word not including header (f) - Parameter ID, parameter 134 (Composed Dtot) (g) - Parameter 134 flag byte (h) - Parameter 134 length, 1 word not including header (i) - Parameter ID, parameter 135 (Composed Csum). (j) - Parameter 135 flag byte (k) - Parameter 135 length, 1 word not including header (l) - Parameter ID, parameter 136 (Composed Dsum). (m) - Parameter 136 flag byte (n) - Parameter 136 length, 1 word not including header
When a node which actually implements guaranteed service creates the guaranteed service adspec fragment, the parameter values are set to the local values for each parameter. When an application or network
When a node which actually implements guaranteed service creates the guaranteed service adspec fragment, the parameter values are set to the local values for each parameter. When an application or network
Wroclawski Standards Track [Page 20] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 20] RFC 2210 RSVP with INTSERV September 1997
element which does not itself implement guaranteed service creates a guaranteed service adspec fragment, it should set the values of each parameter to zero, and set the break bit to indicate that the service is not actually implemented at the node.
element which does not itself implement guaranteed service creates a guaranteed service adspec fragment, it should set the values of each parameter to zero, and set the break bit to indicate that the service is not actually implemented at the node.
An application or host RSVP which is creating a guaranteed service adspec fragment but does not itself implement the guaranteed service may create a truncated "empty" guaranteed adspec fragment consisting of only a header word:
An application or host RSVP which is creating a guaranteed service adspec fragment but does not itself implement the guaranteed service may create a truncated "empty" guaranteed adspec fragment consisting of only a header word:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |1| (b) | 0 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 2 (a) |1| (b) | 0 (c) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 2 (Guaranteed)
(b) - Break bit (set, service not implemented)
(c) - Length of per-service data in 32-bit words not
including header word.
(a) - Per-Service header, service number 2 (Guaranteed) (b) - Break bit (set, service not implemented) (c) - Length of per-service data in 32-bit words not including header word.
This might occur if the sending application or host does not do resource reservation iself, but still wants the network to do so. Note that in this case the break bit will always be set, since the creator of the adspec fragment does not itself implement guaranteed service.
This might occur if the sending application or host does not do resource reservation iself, but still wants the network to do so. Note that in this case the break bit will always be set, since the creator of the adspec fragment does not itself implement guaranteed service.
When a PATH message ADSPEC containing a per-service header for Guaranteed service encounters a network element implementing Guaranteed service, the guaranteed service data fragment is updated:
When a PATH message ADSPEC containing a per-service header for Guaranteed service encounters a network element implementing Guaranteed service, the guaranteed service data fragment is updated:
- If the data block in the ADSPEC is an empty (header-only) block
the header-only fragment must first be expanded into the complete
data fragment described above, with initial values of Ctot, Dtot,
Csum, and Dsum set to zero. An empty fragment can be recognized
quickly by checking for a size field of zero. The value of the
break bit in the header is preserved when the additional
Guaranteed service data is added. The overall message length and
the guaranteed-service data fragment size (field (b) in the
pictures above) are changed to reflect the increased message
length.
- If the data block in the ADSPEC is an empty (header-only) block the header-only fragment must first be expanded into the complete data fragment described above, with initial values of Ctot, Dtot, Csum, and Dsum set to zero. An empty fragment can be recognized quickly by checking for a size field of zero. The value of the break bit in the header is preserved when the additional Guaranteed service data is added. The overall message length and the guaranteed-service data fragment size (field (b) in the pictures above) are changed to reflect the increased message length.
The values of Ctot, Csum, Dtot, and Dsum in the ADSPEC data
fragment are then composed with the local values exported by the
network element according to the composition functions defined in
[RFC 2212].
The values of Ctot, Csum, Dtot, and Dsum in the ADSPEC data fragment are then composed with the local values exported by the network element according to the composition functions defined in [RFC 2212].
Wroclawski Standards Track [Page 21] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 21] RFC 2210 RSVP with INTSERV September 1997
- When a PATH message ADSPEC with a Guaranteed service header
encounters a network element that supports RSVP but does *not*
implement Guaranteed service, the network element sets the break
bit in the Guaranteed service header.
- When a PATH message ADSPEC with a Guaranteed service header encounters a network element that supports RSVP but does *not* implement Guaranteed service, the network element sets the break bit in the Guaranteed service header.
- The new values are placed in the correct fields of the ADSPEC,
and the ADSPEC is passed back to RSVP for delivery to the next hop
along the path.
- The new values are placed in the correct fields of the ADSPEC, and the ADSPEC is passed back to RSVP for delivery to the next hop along the path.
When a PATH message ADSPEC containing a Guaranteed service data fragment encounters a network element that supports RSVP but does *not* implement Guaranteed service, the network element sets the break bit in the Guaranteed service header.
When a PATH message ADSPEC containing a Guaranteed service data fragment encounters a network element that supports RSVP but does *not* implement Guaranteed service, the network element sets the break bit in the Guaranteed service header.
When a PATH message ADSPEC *without* a Guaranteed service header encounters a network element implementing Guaranteed service, the Guaranteed service module of the network element leaves the ADSPEC unchanged. The absence of a Guaranteed service per-service header in the ADSPEC indicates that the application does not care about Guaranteed service.
When a PATH message ADSPEC *without* a Guaranteed service header encounters a network element implementing Guaranteed service, the Guaranteed service module of the network element leaves the ADSPEC unchanged. The absence of a Guaranteed service per-service header in the ADSPEC indicates that the application does not care about Guaranteed service.
3.3.4. Controlled-Load Service ADSPEC data fragment
3.3.4. Controlled-Load Service ADSPEC data fragment
Unlike the Guaranteed service, the Controlled-Load service does not require extra ADSPEC data to function correctly. The only ADSPEC data specific to the Controlled-Load service is the Controlled-Load break bit. Therefore the usual Controlled-Load service data block contains no extra information. The minimum size of the controlled-load service data fragment is 1 32-bit word.
Unlike the Guaranteed service, the Controlled-Load service does not require extra ADSPEC data to function correctly. The only ADSPEC data specific to the Controlled-Load service is the Controlled-Load break bit. Therefore the usual Controlled-Load service data block contains no extra information. The minimum size of the controlled-load service data fragment is 1 32-bit word.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | N-1 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Service-specific general parameter headers/values, if present |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 5 (Controlled-Load)
(b) - Break bit
(c) - Length of per-service data in 32 bit words not including
header word.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 5 (a) |x| (b) | N-1 (c) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Service-specific general parameter headers/values, if present | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . N | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Per-Service header, service number 5 (Controlled-Load) (b) - Break bit (c) - Length of per-service data in 32 bit words not including header word.
Wroclawski Standards Track [Page 22] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 22] RFC 2210 RSVP with INTSERV September 1997
The Controlled-Load portion of the ADSPEC is processed according to the following rules:
The Controlled-Load portion of the ADSPEC is processed according to the following rules:
- When a PATH message ADSPEC with a Controlled-Load service header
encounters a network element implementing Controlled-Load service,
the network element makes no changes to the service header.
- When a PATH message ADSPEC with a Controlled-Load service header encounters a network element implementing Controlled-Load service, the network element makes no changes to the service header.
- When a PATH message ADSPEC with a Controlled-Load service header
encounters a network element that supports RSVP but does *not*
implement Controlled-Load service, the network element sets the
break bit in the Controlled-Load service header.
- When a PATH message ADSPEC with a Controlled-Load service header encounters a network element that supports RSVP but does *not* implement Controlled-Load service, the network element sets the break bit in the Controlled-Load service header.
- In either case, the ADSPEC is passed back to RSVP for delivery
to the next hop along the path.
- In either case, the ADSPEC is passed back to RSVP for delivery to the next hop along the path.
3.3.5. Overriding Global ADSPEC Data with Service-Specific Information
3.3.5. Overriding Global ADSPEC Data with Service-Specific Information
In some cases, the default values for the general parameters are not correct for a particular service. For example, an implementation of Guaranteed service may accept only packets with a smaller maximum size than the link MTU, or the percentage of outgoing link bandwidth made available to the Controlled-Load service at a network element may be administratively limited to less than the overall bandwidth.
In some cases, the default values for the general parameters are not correct for a particular service. For example, an implementation of Guaranteed service may accept only packets with a smaller maximum size than the link MTU, or the percentage of outgoing link bandwidth made available to the Controlled-Load service at a network element may be administratively limited to less than the overall bandwidth.
In these cases, a service-specific value, as well as the default value, is reported to the receiver receiving the ADSPEC. Service- specific information which overrides general information is carried by a parameter with the same name as the general parameter, placed within the data fragment of the QoS control service to which it applies. These service-specific values are referred to as override or service-specific general parameters.
In these cases, a service-specific value, as well as the default value, is reported to the receiver receiving the ADSPEC. Service- specific information which overrides general information is carried by a parameter with the same name as the general parameter, placed within the data fragment of the QoS control service to which it applies. These service-specific values are referred to as override or service-specific general parameters.
For example, the following Controlled-Load ADSPEC fragment carries information overriding the global path bandwidth estimate with a different value:
For example, the following Controlled-Load ADSPEC fragment carries information overriding the global path bandwidth estimate with a different value:
Wroclawski Standards Track [Page 23] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 23] RFC 2210 RSVP with INTSERV September 1997
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | 2 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (d) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Path b/w estimate for C-L service (32b IEEE FP number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 5 (a) |x| (b) | 2 (c) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 6 (d) | 0 (d) | 1 (e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Path b/w estimate for C-L service (32b IEEE FP number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 5 (Controlled-Load)
(b) - Break bit
(c) - Length of per-service data, two words not including header
(c) - Parameter ID, parameter 6
(AVAILABLE_PATH_BANDWIDTH general parameter from [RFC 2215])
(d) - Parameter 6 flags (none set)
(e) - Parameter 6 length, one word not including header
(a) - Per-Service header, service number 5 (Controlled-Load) (b) - Break bit (c) - Length of per-service data, two words not including header (c) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general parameter from [RFC 2215]) (d) - Parameter 6 flags (none set) (e) - Parameter 6 length, one word not including header
The presence of override parameters in a data fragment can be quickly detected by examining the fragment's length field, which will be larger than the "standard" length for the fragment. Specific override parameters can be easily identified by examining the parameter headers, because they have parameter_number's from the general parameter portion of the number space (1-127), but are found in service-specific data blocks (those with service_numbers between 2 and 254 in the per_service header field).
The presence of override parameters in a data fragment can be quickly detected by examining the fragment's length field, which will be larger than the "standard" length for the fragment. Specific override parameters can be easily identified by examining the parameter headers, because they have parameter_number's from the general parameter portion of the number space (1-127), but are found in service-specific data blocks (those with service_numbers between 2 and 254 in the per_service header field).
The presence of override parameters in a data fragment is optional. A parameter header/value pair is added only when a particular application or QoS control service wishes to override the global value of a general parameter with a service-specific value.
The presence of override parameters in a data fragment is optional. A parameter header/value pair is added only when a particular application or QoS control service wishes to override the global value of a general parameter with a service-specific value.
As with IP options, it is only the use of these override parameters that is optional. All implementations must be prepared to receive and process override parameters.
As with IP options, it is only the use of these override parameters that is optional. All implementations must be prepared to receive and process override parameters.
The basic principle for handling override parameters is to use the override value (local or adspec) if it exists, and to use the default value otherwise. If a local node exports an override value for a general parameter, but there is no override value in the arriving adspec, the local node adds it. The following pseudo-code fragment gives more detail:
The basic principle for handling override parameters is to use the override value (local or adspec) if it exists, and to use the default value otherwise. If a local node exports an override value for a general parameter, but there is no override value in the arriving adspec, the local node adds it. The following pseudo-code fragment gives more detail:
Wroclawski Standards Track [Page 24] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 24] RFC 2210 RSVP with INTSERV September 1997
/* Adspec parameter processing rules *
/* Adspec parameter processing rules *
<get arriving ADSPEC from RSVP>
<get arriving ADSPEC from RSVP>
for ( <each service number N with a fragment in the ADSPEC> ) {
if ( <the local node does not support the service> ) {
<set the break bit in the service header>
} else {
for ( <each parameter in the data fragment for service N> ) {
if ( < the local service N supplies a value for the parameter> ) {
<compose the arriving and values and update the adspec>
} else {
/* Must be a general parameter, or service N would have
* supplied a value..
*/
<compose the arriving value with the local default value
and update the adspec>
}
}
for ( <any parameters supplied by the local service N
implementation but not found in the adspec> ) {
/*
* Must be an override value for a general parameter,
* or the adspec would have contained a value..
*/
<compose the local override value with the arriving default
value (from the service 1 data fragment) and add the parameter
to the adspec's service N fragment in parameter_number order>
}
}
}
for ( <each service number N with a fragment in the ADSPEC> ) { if ( <the local node does not support the service> ) { <set the break bit in the service header> } else { for ( <each parameter in the data fragment for service N> ) { if ( < the local service N supplies a value for the parameter> ) { <compose the arriving and values and update the adspec> } else { /* Must be a general parameter, or service N would have * supplied a value.. */ <compose the arriving value with the local default value and update the adspec> } } for ( <any parameters supplied by the local service N implementation but not found in the adspec> ) { /* * Must be an override value for a general parameter, * or the adspec would have contained a value.. */ <compose the local override value with the arriving default value (from the service 1 data fragment) and add the parameter to the adspec's service N fragment in parameter_number order> } } }
<pass updated ADSPEC back to RSVP>
<pass updated ADSPEC back to RSVP>
In practice, the two 'for' loops can be combined. Since override parameters within a service's fragment are transmitted in numerical order, it is possible to determine whether a parameter is present without scanning the entire fragment. Also, because the data fragments are ordered by service_number, the default values for general parameters will always be read before they might be needed to update local override values in the second for loop.
In practice, the two 'for' loops can be combined. Since override parameters within a service's fragment are transmitted in numerical order, it is possible to determine whether a parameter is present without scanning the entire fragment. Also, because the data fragments are ordered by service_number, the default values for general parameters will always be read before they might be needed to update local override values in the second for loop.
3.3.6. Example
3.3.6. Example
The picture below shows the complete adspec for an application which can use either controlled-load or guaranteed service. In the example,
The picture below shows the complete adspec for an application which can use either controlled-load or guaranteed service. In the example,
Wroclawski Standards Track [Page 25] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 25] RFC 2210 RSVP with INTSERV September 1997
data fragments are present for general parameters, guaranteed, and controlled-load services. All fragments are of standard size, and there are no override parameters present.
data fragments are present for general parameters, guaranteed, and controlled-load services. All fragments are of standard size, and there are no override parameters present.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Unused | 19 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| reserved (d)| 8 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | zero extension of .. IS hop cnt (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (o) | (p) | 1 (q) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | zero extension of .. composed MTU (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 2 (r) |x| reserved (s)| 8 (t) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 133 (u) | (v) | 1 (w) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14 | 134 (x) | (y) | 1 (z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 135 (aa | (bb | 1 (cc) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18 | 136 (dd) | (ee) | 1 (ff) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 5 (gg |x 0 (hh) | 0 (ii) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Unused | 19 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |x| reserved (d)| 8 (e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 4 (f) | (g) | 1 (h) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | zero extension of .. IS hop cnt (16-bit unsigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | 6 (i) | (j) | 1 (k) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Path b/w estimate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 8 (l) | (m) | 1 (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Minimum path latency (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 10 (o) | (p) | 1 (q) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | zero extension of .. composed MTU (16-bit unsigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | 2 (r) |x| reserved (s)| 8 (t) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | 133 (u) | (v) | 1 (w) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | End-to-end composed value for C [Ctot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | 134 (x) | (y) | 1 (z) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 | End-to-end composed value for D [Dtot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | 135 (aa | (bb | 1 (cc) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 | Since-last-reshaping point composed C [Csum] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | 136 (dd) | (ee) | 1 (ff) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19 | Since-last-reshaping point composed D [Dsum] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | 5 (gg |x 0 (hh) | 0 (ii) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wroclawski Standards Track [Page 26] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 26] RFC 2210 RSVP with INTSERV September 1997
Word 1: Message Header:
(a) - Message header and version number
(b) - Message length - 19 words not including header
Word 1: Message Header: (a) - Message header and version number (b) - Message length - 19 words not including header
Words 2-7: Default general characterization parameters
(c) - Per-Service header, service number 1
(Default General Parameters)
(d) - Global Break bit (NON_IS_HOP general parameter 2) (marked x)
(e) - Length of General Parameters data block (8 words)
(f) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS
general parameter)
(g) - Parameter 4 flag byte
(h) - Parameter 4 length, 1 word not including header
(i) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH
general parameter)
(j) - Parameter 6 flag byte
(k) - Parameter 6 length, 1 word not including header
(l) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY
general parameter)
(m) - Parameter 8 flag byte
(n) - Parameter 8 length, 1 word not including header
(o) - Parameter ID, parameter 10 (PATH_MTU general parameter)
(p) - Parameter 10 flag byte
(q) - Parameter 10 length, 1 word not including header
Words 2-7: Default general characterization parameters (c) - Per-Service header, service number 1 (Default General Parameters) (d) - Global Break bit (NON_IS_HOP general parameter 2) (marked x) (e) - Length of General Parameters data block (8 words) (f) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general parameter) (g) - Parameter 4 flag byte (h) - Parameter 4 length, 1 word not including header (i) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general parameter) (j) - Parameter 6 flag byte (k) - Parameter 6 length, 1 word not including header (l) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general parameter) (m) - Parameter 8 flag byte (n) - Parameter 8 length, 1 word not including header (o) - Parameter ID, parameter 10 (PATH_MTU general parameter) (p) - Parameter 10 flag byte (q) - Parameter 10 length, 1 word not including header
Words 11-19: Guaranteed service parameters
(r) - Per-Service header, service number 2 (Guaranteed)
(s) - Break bit
(t) - Length of per-service data, 8 words not including header
(u) - Parameter ID, parameter 133 (Composed Ctot)
(v) - Composed Ctot flag byte
(w) - Composed Ctot length, 1 word not including header
(x) - Parameter ID, parameter 134 (Composed Dtot)
(y) - Composed Dtot flag byte
(z) - Composed Dtot length, 1 word not including header
(aa)- Parameter ID, parameter 135 (Composed Csum).
(bb)- Composed Csum flag byte
(cc)- Composed Csum length, 1 word not including header
(dd)- Parameter ID, parameter 136 (Composed Dsum).
(ee)- Composed Dsum flag byte
(ff)- Composed Dsum length, 1 word not including header
Words 11-19: Guaranteed service parameters (r) - Per-Service header, service number 2 (Guaranteed) (s) - Break bit (t) - Length of per-service data, 8 words not including header (u) - Parameter ID, parameter 133 (Composed Ctot) (v) - Composed Ctot flag byte (w) - Composed Ctot length, 1 word not including header (x) - Parameter ID, parameter 134 (Composed Dtot) (y) - Composed Dtot flag byte (z) - Composed Dtot length, 1 word not including header (aa)- Parameter ID, parameter 135 (Composed Csum). (bb)- Composed Csum flag byte (cc)- Composed Csum length, 1 word not including header (dd)- Parameter ID, parameter 136 (Composed Dsum). (ee)- Composed Dsum flag byte (ff)- Composed Dsum length, 1 word not including header
Word 20: Controlled-Load parameters
(gg - Per-Service header, service number 5 (Controlled-Load)
(hh)- Break bit
(ii)- Length of controlled-load data, 0 words not including header
Word 20: Controlled-Load parameters (gg - Per-Service header, service number 5 (Controlled-Load) (hh)- Break bit (ii)- Length of controlled-load data, 0 words not including header
Wroclawski Standards Track [Page 27] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 27] RFC 2210 RSVP with INTSERV September 1997
4. Security Considerations
4. Security Considerations
The message formatting and usage rules described in this note raise no security issues. The overall use of these rules to implement multiple qualities of service using RSVP and integrated services scheduling modules introduces a new security requirement; the need to control and authenticate access to enhanced qualities of service. This requirement is discussed further in [RFC 2205], [RFC 2212], and [RFC 2211]. [RFCRSVPMD5] describes the mechanism used to protect the integrity of RSVP messages carrying the information described here.
The message formatting and usage rules described in this note raise no security issues. The overall use of these rules to implement multiple qualities of service using RSVP and integrated services scheduling modules introduces a new security requirement; the need to control and authenticate access to enhanced qualities of service. This requirement is discussed further in [RFC 2205], [RFC 2212], and [RFC 2211]. [RFCRSVPMD5] describes the mechanism used to protect the integrity of RSVP messages carrying the information described here.
Wroclawski Standards Track [Page 28] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 28] RFC 2210 RSVP with INTSERV September 1997
Appendix 1: Message construction rules
Appendix 1: Message construction rules
This section gives the rule used to generate the object formats of Section 3. It is a general wire format for encoding integrated services data objects within setup and management protocol messages. The format has a three-level structure:
This section gives the rule used to generate the object formats of Section 3. It is a general wire format for encoding integrated services data objects within setup and management protocol messages. The format has a three-level structure:
- An overall message header carries a version number and message
length. Providing this header in a standard format allows the
same code library to handle data objects carried by multiple setup
protocols.
- An overall message header carries a version number and message length. Providing this header in a standard format allows the same code library to handle data objects carried by multiple setup protocols.
- Per-service fragments carry information about a specific QoS
control service, such as guaranteed [RFC 2212] or controlled load
[RFC 2211]. Each per-service fragment carries one or more
parameters. The set of parameters present in a fragment is
determined by the needs of the protocol in use. Examples are given
in Section 2.
- Per-service fragments carry information about a specific QoS control service, such as guaranteed [RFC 2212] or controlled load [RFC 2211]. Each per-service fragment carries one or more parameters. The set of parameters present in a fragment is determined by the needs of the protocol in use. Examples are given in Section 2.
- Parameters are the actual data used to control or monitor a
service. A parameter may be a single quantity such as an integer,
or a composite data structure such as a TSpec. The parameters
specific to a service are defined by the service specification.
The available general parameters, with definitions shared by many
services, are defined by [RFC 2215].
- Parameters are the actual data used to control or monitor a service. A parameter may be a single quantity such as an integer, or a composite data structure such as a TSpec. The parameters specific to a service are defined by the service specification. The available general parameters, with definitions shared by many services, are defined by [RFC 2215].
Wroclawski Standards Track [Page 29] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 29] RFC 2210 RSVP with INTSERV September 1997
A1.1. Message Header
A1.1. Message Header
The 32-bit message header specifies the message format version number and total length of the message. The overall message must be aligned to a 32-bit boundary within the transport protocol's data packet. The message length is measured in 32-bit words *not including the word containing the header*. This is to lower the probability of an accidentally cleared word resulting in an infinite loop in the message parser.
The 32-bit message header specifies the message format version number and total length of the message. The overall message must be aligned to a 32-bit boundary within the transport protocol's data packet. The message length is measured in 32-bit words *not including the word containing the header*. This is to lower the probability of an accidentally cleared word resulting in an infinite loop in the message parser.
The Message Header is represented by a 32-bit bitfield laid out as shown below and then encoded as an XDR unsigned integer. Encoding as an XDR unsigned integer is equivalent to converting the bitfield from the machine's native format to big-endian network byte order.
The Message Header is represented by a 32-bit bitfield laid out as shown below and then encoded as an XDR unsigned integer. Encoding as an XDR unsigned integer is equivalent to converting the bitfield from the machine's native format to big-endian network byte order.
Message Header
Message Header
MSB LSB
31 28 27 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Unused | OVERALL LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSB LSB 31 28 27 16 15 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Unused | OVERALL LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V - Message format version; currently 0 OVERALL LENGTH - Message length in 32-bit words not including header
V - Message format version; currently 0 OVERALL LENGTH - Message length in 32-bit words not including header
Wroclawski Standards Track [Page 30] RFC 2210 RSVP with INTSERV September 1997
Wroclawski Standards Track [Page 30] RFC 2210 RSVP with INTSERV September 1997
A1.2. Per-Service Data Header
A1.2. Per-Service Data Header
The message header is followed by one or more service-specific data blocks, each containing the data associated with a specific QoS control service. Each service-specific data block begins with an identifying header. This 32-bit header contains the service number, a one-bit flag (the "break bit", because it indicates a break in the QoS control path) and a length field. The length field specifies the number of 32-bit words used to hold data specific to this service as a count of 32-bit words *not including the word containing the header*.
The message header is followed by one or more service-specific data blocks, each containing the data associated with a specific QoS control service. Each service-specific data block begins with an identifying header. This 32-bit header contains the service number, a one-bit flag (the "break bit", because it indicates a break in the QoS control path) and a length field. The length field specifies the number of 32-bit words used to hold data specific to this service as a count of 32-bit words *not including the word containing the header*.
The break bit, if set, indicates that the service specified by the header was unsupported or unrecognized at some point in the message's path through the network. This bit corresponds to the general parameter NON_IS_HOP defined in [RFC 2215]. It is cleared when a message is first generated, and set whenever the message passes through an element that does not recognize the service_number in the per-service header.
The break bit, if set, indicates that the service specified by the header was unsupported or unrecognized at some point in the message's path through the network. This bit corresponds to the general parameter NON_IS_HOP defined in [RFC 2215]. It is cleared when a message is first generated, and set whenever the message passes through an element that does not recognize the service_number in the per-service header.
The Per-Service Data Header is represented by a 32-bit bitfield laid out as shown below and then encoded as an XDR unsigned integer.
The Per-Service Data Header is represented by a 32-bit bitfield laid out as shown below and then encoded as an XDR unsigned integer.
Per-Service Data Header
1サービスあたりのデータヘッダー
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SVC_NUMBER |B| Reserved | SVC_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSB LSB31 24 23 16 15 0+++++++++++++++++++++++++++++++++| SVC_数|B| 予約されます。| SVC_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SVC_NUMBER - Service ID number (defined in service specification).
B - Break bit - service unsupported/break in path.
SVC_LENGTH - Service-specific data length in 32-bit words,
not including header.
SVC_NUMBER--ID番号(使用中の仕様を定義する)を修理してください。 B--噛み付かれるのに壊れてください--経路でサポートされない/中断を修理してください。 SVC_LENGTH--ヘッダーを含まない32ビットの単語によるサービス特有のデータの長さ。
Wroclawski Standards Track [Page 31] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[31ページ]。
A1.3. Parameter Header
A1.3。 パラメタヘッダー
The per-service header is followed by one or more service parameter blocks, each identified by a Parameter Header. This header contains the parameter identifier (parameter number), the length of the data carrying the parameter's value, and a flag field. The data field(s) of the parameter follow. The parameter number, as well as the meaning and format of the data words following the header, are given by the specification which defines the parameter.
それぞれが、Parameter Headerで1つ以上のサービスパラメタブロック以上が1サービスあたりのヘッダーを支えるのを特定しました。 このヘッダーはパラメタ識別子(パラメタ番号)、パラメタの値を運ぶデータの長さ、および旗の分野を含んでいます。 パラメタのデータ・フィールドは続きます。 パラメタを定義する仕様でヘッダーに続くデータ・ワードのパラメタ番号、意味、および書式を与えます。
The Parameter Header is represented by a 32-bit bitfield laid out as shown below and then encoded as an XDR unsigned integer.
符号のない整数を以下に示して、次に、XDRとしてコード化するとき、Parameter Headerは広げられた32ビットのbitfieldによって表されます。
Parameter Header
パラメタヘッダー
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PARAM_NUM |I FLAGS | PARAM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSB LSB31 24 23 16 15 0+++++++++++++++++++++++++++++++++| PARAM_ヌム|私は弛みます。| PARAM_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PARAM_NUM - Parameter number (defined in service specification)
FLAGS - Per-parameter flags
PARAM_LENGTH - Length of per-parameter data in 32-bit words, not
including the header word.
PARAM_NUM--パラメタ数(使用中の仕様を定義する)のFLAGS--パラメタはPARAM_LENGTHに旗を揚げさせます--ヘッダー単語を含まない32ビットの単語による1パラメタあたりのデータの長さ。
The following flags are currently defined in the FLAGS field:
以下の旗は現在、FLAGS分野で定義されます:
I (bit 23) - INVALID
私(ビット23)--病人
This flag indicates that the parameter value was
not correctly processed at one or more network
elements along a data path. It is intended for use
in a possible future service composition scheme.
この旗は、パラメタ値がデータ経路に沿って1つ以上のネットワーク要素で正しく処理されなかったのを示します。 それは可能な将来のサービス構成体系における使用のために意図します。
Other bits in the FLAGS field of the parameter header are currently reserved, and should be set to zero.
パラメタヘッダーのFLAGS分野の他のビットは、現在予約されて、ゼロに設定されるべきです。
Wroclawski Standards Track [Page 32] RFC 2210 RSVP with INTSERV September 1997
Wroclawski規格は1997年9月にINTSERVと共にRFC2210RSVPを追跡します[32ページ]。
A1.4. Parameter Data
A1.4。 パラメタデータ
Following the Parameter Header is the actual data representing the parameter value. Parameter values are encoded into one or more 32-bit words using the XDR external data representation described in [RFC 1832], and the resulting words are placed in the message.
Parameter Headerに続くのは、パラメタ値を表す実際のデータです。 パラメタ値は[RFC1832]で説明されたXDR外部データ表現を使用することで1つ以上の32ビットの単語にコード化されます、そして、結果として起こる単語はメッセージに置かれます。
The document defining a parameter should provide an XDR description of the parameter's data fields. If it does not, a description should be provided in this note.
パラメタを定義するドキュメントはパラメタのデータ・フィールドのXDR記述を提供するはずです。 そうしないなら、この注意に記述を提供するべきです。
References
参照
[RFC 2205] Braden, B., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、B.、エド、etアル、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、9月1997日
[RFC 2216] Shenker, S., and J. Wroclawski. "Network Element QoS Control Service Specification Template", RFC 2216, September 1997.
[RFC2216] Shenker、S.、およびJ.Wroclawski。 「ネットワーク要素QoS制御サービス仕様テンプレート」、RFC2216、1997年9月。
[RFC 2212] Shenker, S., Partridge, C., and R Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] 1997年9月のShenkerとS.とヤマウズラ、C.とRゲラン、「保証されたサービスの質の仕様」RFC2212。
[RFC 2211] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷サービスの質の仕様」、RFC2211、1997年9月。
[RFC 2215] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC2215] Shenker、S.、およびJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[RFCRSVPMD5] Baker, F., "RSVP Cryptographic Authentication", Work in Progress.
[RFCRSVPMD5] ベイカー、F.、「RSVPの暗号の認証」が進行中で働いています。
[RFC 1832] Srinivansan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
Srinivansan、[RFC1832]R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。
Author's Address
作者のアドレス
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139
Phone: 617-253-7885 Fax: 617-253-2673 (FAX) EMail: jtw@lcs.mit.edu
以下に電話をしてください。 617-253-7885 Fax: 617-253-2673(ファックスする)に、メールしてください: jtw@lcs.mit.edu
Wroclawski Standards Track [Page 33]
Wroclawski標準化過程[33ページ]
一覧
スポンサーリンク
