Network Working Group Y. Bernet
Request for Comments: 2997 Microsoft
Category: Standards Track A. Smith
Allegro Networks
B. Davie
Cisco Systems
November 2000
Specification of the Null Service Type
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
In the typical Resource Reservation Protocol (RSVP)/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service.
典型的なリソース予約プロトコル（RSVP）/のIntServモデルでは、アプリケーションは、特定のIntServサービスタイプを要求し、そのサービスに必要なリソースを定量化します。特定のアプリケーションでは、サービスパラメータの決意は、最高のネットワーク管理者の裁量に任されています。例えば、ERPアプリケーションは、多くの場合、ミッションクリティカルであり、優先順位のサービスのいくつかのフォームを必要とするが、容易に自分のリソース要件を指定することはできません。このようなアプリケーションを提供するために、我々は「ヌルサービス」の概念を導入します。ヌルサービスは、RSVPシグナリングを使用して、アプリケーションがサービスの品質（QoS）ポリシーエージェントをネットワークに自分自身を識別することができます。しかし、それはリソース要件を指定するには、それらを必要としません。 （ネットワーク管理者によって決定される）アプリケーションのための適切なQoSポリシーを適用することにより、ネットワークの応答におけるQoSポリシーエージェント。 RSVPの使用のこのモードは、[intdiff】RSVPシグナリングと差別化サービス（DiffServの）QoSメカニズムを組み合わせてネットワークに特に適用可能です。この環境では、QoSポリシーエージェントは、サービスの特定のDiffServクラスに合図アプリケーションのトラフィックを指示することができます。
Using standard RSVP/Intserv signaling, applications running on hosts issue requests for network resources by communicating the following information to network devices:
標準のRSVP / IntServのシグナリング、ネットワークデバイスに以下の情報を通信することにより、ネットワークリソースのホスト発行要求上で動作するアプリケーションを使用します：
1. A requested service level (Guaranteed or Controlled Load). 2. The quantity of resources required at that service level. 3. Classification information by which the network can recognize specific traffic (filterspec). 4. Policy/identity information indicating the user and/or the application for which resources are required.
1. Aはサービスレベル（保証または制御負荷）を要求しました。 2.リソースの量は、そのサービス・レベルで必要。ネットワークは、特定のトラフィック（FilterSpecに）を認識することが可能な前記分類情報。ユーザおよび/またはリソースが要求されるアプリケーションを示す4ポリシー/識別情報。
In response, standard RSVP aware network nodes choose to admit or deny a resource request. The decision is based on the availability of resources along the relevant path and on policies. Policies define the resources that may be granted to specific users and/or applications. When a resource request is admitted, network nodes install classifiers that are used to recognize the admitted traffic and policers that are used to assure that the traffic remains within the limits of the resources requested.
それに応答して、標準のRSVP対応のネットワーク・ノードは、リソース要求を認めるか拒否するかを選択します。決定は、関連するパスに沿って政策上のリソースの可用性に基づいています。ポリシーは、特定のユーザおよび/またはアプリケーションに付与することができるリソースを定義します。リソース要求が許可される場合、ネットワークノードは認めトラフィック、トラフィックが要求されたリソースの限界内に留まることを保証するために使用されるポリサーを認識するために使用される分類子をインストール。
The Guaranteed and Controlled Load Intserv services are not suitable for certain applications that are unable to (or choose not to)specify the resources they require from the network. Diffserv services are better suited for this type of application. Nodes in a diffserv network are typically provisioned to classify arriving packets to some small number of behavior aggregates (BAs) [diffarch]. Traffic is handled on a per-BA basis. This provisioning tends to be 'top-down' with respect to end-user traffic flows in the sense that there is no signaling between hosts and the network. Instead, the network administrator uses a combination of heuristics, measurement and experience to provision the network devices to handle aggregated traffic, with no deterministic knowledge of the volume of traffic that will arrive at any specific node.
保証および制御された負荷のIntServサービスはにできない（かどうかを選択）されている特定の用途には適していません、彼らはネットワークから必要なリソースを指定します。 Diffservのサービスは、この種の用途に適しています。 DiffServネットワーク内のノードは、典型的には、行動の凝集体（BAS）diffarch]いくつかの小さな数に到着するパケットを分類するようにプロビジョニングされています。トラフィックはあたり-BA基づいて処理されます。このプロビジョニングは、ホストとネットワーク間のシグナリングが存在しないという意味で流れるエンドユーザのトラフィックに対して「トップダウン」となる傾向があります。代わりに、ネットワーク管理者は、任意の特定のノードに到着するトラフィック量のない決定論的知識を、集約トラフィックを処理するために提供するネットワークデバイスをヒューリスティック、測定及び経験の組み合わせを使用します。
In applying diffserv mechanisms to manage application traffic, network administrators are faced with two challenges:
アプリケーショントラフィックを管理するためのDiffServメカニズムを適用するには、ネットワーク管理者は、2つの課題に直面しています：
1. Provisioning - network administrators need to anticipate the volume of traffic likely to arrive at each network node for each diffserv BA. If the volume of traffic arriving is likely to exceed the capacity available for the BA claimed, the network administrator has the choice of increasing the capacity for the BA, reducing the volume of traffic claiming the BA, or compromising service to all traffic arriving for the BA.
1.プロビジョニング - ネットワーク管理者は、それぞれのDiffServ BAのために各ネットワーク・ノードに到達する可能性が高いトラフィック量を予測する必要があります。トラフィックは到着のボリュームがBAを主張するために利用可能な容量を超えそうな場合は、ネットワーク管理者は、のために到着するすべてのトラフィックにサービスを、BAのための容量を増やすBAを主張するトラフィックの量を減らす、あるいは妥協の選択肢を持っていますBA。
2. Classification - diffserv nodes classify traffic to user and/or application, based on the diff-serv codepoint (DSCP) in each packet's IP header or based on other fields in the packet's IP header (source/destination address/port and protocol). The latter method of classification is referred to as MF classification. This method of classification may be unreliable and imposes a management burden.
2.分類 - DiffServのノードは、各パケットのIPヘッダ内のDiffServコードポイント（DSCP）に基づいて、またはパケットのIPヘッダ内の他のフィールド（ソース/宛先アドレス/ポートおよびプロトコル）に基づいて、ユーザおよび/またはアプリケーションにトラフィックを分類します。分類の後者の方法は、MF分類と呼ばれます。分類のこの方法は信頼できないと管理負担を強いることがあります。
By using RSVP signaling, the management of application traffic in diffserv networks can be significantly facilitated. (Note that RSVP/diffserv interoperability has been discussed previously in the context of the Guaranteed and Controlled Load Intserv services.) This document focuses on RSVP/diffserv interoperability in the context of the Null Service.
RSVPシグナリングを使用することにより、DiffServのネットワークにおけるアプリケーショントラフィックの管理が大幅に容易にすることができます。 （そのRSVP / DiffServの相互運用性が保証されており、制御された負荷のIntServサービスの文脈で前に説明されています。）この文書はヌルサービスのコンテキストでRSVP / DiffServの相互運用性に焦点を当てています。
In the proposed mechanism, the RSVP sender offers the new service type, 'Null Service Type' in the ADSPEC that is included with the PATH message. A new Tspec corresponding to the new service type is added to the SENDER_TSPEC. In addition, the RSVP sender will typically include with the PATH message policy objects identifying the user, application and sub application ID [identity, application].
提案されたメカニズムでは、RSVPの送信者は、PATHメッセージに含まれているADSPECに新しいサービス・タイプ、「ヌルサービスタイプ」を提供しています。新しいサービスタイプに対応した新しいのTspecはSENDER_TSPECに追加されます。また、RSVP送信機は、典型的には、PATHメッセージポリシー・オブジェクトは、ユーザ、アプリケーションおよびサブアプリケーションID [アイデンティティ、アプリケーション]を識別して含まれます。
(Note that at this time, the new Tspec is defined only to carry the maximum packet size parameter (M), for the purpose of avoiding fragmentation. No other parameters are defined.)
（断片化を回避するために、）この時点で、新しいTspecは、最大パケットサイズパラメータ（Mを搬送するためにのみ定義されることに注意してください。他のパラメータが定義されていません。）
Network nodes receiving these PATH messages interpret the service type to indicate that the application is requesting no specific service type or quantifiable resources. Instead, network nodes manage the traffic flow based on the requesting user, the requesting application and the type of application sub-flow.
これらのPATHメッセージを受信するネットワークノードは、アプリケーションが何も特定のサービスタイプまたは定量化リソースを要求していないことを示すためにサービスタイプを解釈します。代わりに、ネットワークノードが要求しているユーザ、要求アプリケーションおよびアプリケーションサブフローのタイプに基づいてトラフィックフローを管理します。
This mechanism offers significant advantages over a pure diffserv network. At the very least, it informs each network node which would be affected by the traffic flow (and which is interested in intercepting the signaling) of:
このメカニズムは、純粋のDiffServネットワーク上で重要な利点を提供しています。少なくとも、それは、トラフィックフローの影響を受けることになる（およびシグナリングを傍受に興味がある）の各ネットワークノードに通知します。
1. The demand for resources in terms of number of flows of a particular type traversing the node. 2. The binding between classification information and user, application and sub-application.
1.ノードを横断する特定のタイプのフローの数の点でリソースの需要。前記分類情報とユーザー、アプリケーションとサブアプリケーション間の結合。
This information is particularly useful to policy enforcement points and policy decision points (PEPs and PDPs). The network administrator can configure these elements of the policy management system to apply appropriate policy based on the identity of the user, the application and the specific sub application ID.
この情報には、ポリシーの適用ポイントとポリシー決定ポイント（のPEPとのPDP）に特に便利です。ネットワーク管理者は、ユーザのアイデンティティ、アプリケーションと特定のサブアプリケーションIDに基づいて、適切なポリシーを適用するポリシー管理システムのこれらの要素を構成することができます。
PEPs and PDPs may be configured to return an RSVP RESV message to the sender. The returned RESV message may include a DCLASS object [dclass]. The DCLASS object instructs the sender to mark packets on the corresponding flow with a specific DSCP (or set of DSCPs). This mechanism allows PEP/PDPs to affect the volume of traffic arriving at a node for any given BA. It enables the PEP/PDP to do so based on sophisticated policies.
PEPとPDPは、送信者へのRSVP RESVメッセージを返すように構成されてもよいです。返されたRESVメッセージは、[DCLASS] DCLASSオブジェクトを含むことができます。 DCLASSオブジェクトは、特定のDSCP（またはのDSCPのセット）と対応するフロー上のパケットをマークするために、送信者に指示します。このメカニズムは、PEP / PDPのは、任意のBAのノードに到着するトラフィックの量に影響を与えることができます。これは、洗練されたポリシーに基づいてそうするようにPEP / PDPを可能にします。
In any network in which per-flow signaling is used, it is wise to consider scalability concerns. The Null Service encourages signaling for a broader set of applications than that which would otherwise be signaled for. However, RSVP signaling does not, in general, generate a significant amount of traffic relative to the actual data traffic associated with the session. In addition, the Null Service does not encourage every application to signal. It should be used by applications that are considered mission critical or needing QoS management by network administrators.
フローごとのシグナリングが使用されている任意のネットワークでは、スケーラビリティの問題を考慮することが賢明です。ヌル・サービスは、他の合図されるであろうものより用途の広いセットのためのシグナリングを奨励します。しかし、RSVPシグナリングは、一般的には、セッションに関連付けられた実際のデータトラフィックへのトラフィックの相対的な有意な量を生成しません。また、ヌルサービスが合図するすべてのアプリケーションを奨励していません。これは、ミッションが重要か、ネットワーク管理者によってQoS管理を必要とすると考えられているアプリケーションで使用する必要があります。
Perhaps of more concern is the impact on processing resources at network nodes that process the signaling messages. When considering this issue, it's important to point out that it is not necessary to process the signaling messages at each network node. In fact, the combination of RSVP signaling with diff-serv networks may afford significant benefits even when the RSVP messages are processed only at certain key nodes (such as boundaries between network domains, first-hop routers, PEPs or any subset of these). Individual nodes should be enabled or disabled for RSVP processing at the discretion of the network administrator. See [intdiff] for a discussion of the impact of RSVP signaling on diff-serv networks.
おそらくもっと関心のシグナリングメッセージを処理するネットワークノードにおける処理リソースに影響があります。この問題を考えるとき、各ネットワークノードでシグナリングメッセージを処理する必要がないことを指摘することが重要です。実際には、差分-SERVネットワークとRSVPシグナリングの組み合わせは、RSVPメッセージのみ（例えば、ネットワークドメインとの間の境界として、最初のホップルータのPEP、またはこれらの任意のサブセット）は、特定のキーのノードで処理されていても大きな利益を得てもよいです。個々のノードは、ネットワーク管理者の裁量で有効またはRSVPの処理のために無効にする必要があります。差分-SERVネットワーク上のRSVPシグナリングの影響の議論については[intdiff]参照。
In any case, per-flow state is not necessarily required, even in nodes that apply per-flow processing.
いずれの場合においても、フロー毎の状態は、必ずしも偶数フローごとの処理を適用するノードでは、必要とされません。
Network nodes that adhere to the RSVP spec should transparently pass signaling messages for the Null Service. As such, it is possible to introduce a small number of PEPs that are enabled for Null Service into a legacy network and to realize the benefits described in this document.
RSVPの仕様に準拠したネットワーク・ノードは、透過的にヌルサービスのためのシグナリングメッセージを渡す必要があります。このように、レガシーネットワークにヌルサービスが有効になっていると、この文書で説明した利点を実現するためのPEPの小さな数を導入することが可能です。
This document does not preclude applications from offering both a quantitative Intserv service (Guaranteed or Controlled Load)and the Null Service, at the same time. An example of such an application would be a telephony application that benefits from the Guaranteed Service but is able to adapt to a less strict service. By advertising its support for both, the application enables network policy to decide which service type to provide.
このドキュメントは、同時に、量的イントサーブサービス（保証または制御負荷）とヌルサービスの両方を提供してからアプリケーションを排除するものではありません。このようなアプリケーションの例としては、保証サービスから利益を得るが、あまり厳格なサービスに適応することができます電話アプリケーションだろう。両方のサポートを広告することで、アプリケーションが提供するサービスの種類を決定するネットワークポリシーを有効にします。
The RSVP sender constructs an initial RSVP ADSPEC object specifying the Null Service Type. Since there are no service specific parameters associated with this service type, the associated ADSPEC fragment is empty and contains only the header word. Network nodes may or may not supply valid values for bandwidth and latency general parameters. As such, they may use the unknown values defined in [RFC2216].
RSVPの送信者はヌルサービスタイプを指定して初期のRSVP ADSPECオブジェクトを作成します。このサービスタイプに関連付けられたサービス固有のパラメータが存在しないので、関連ADSPEC断片は空でのみヘッダワードを含んでいます。ネットワーク・ノードは、または帯域幅と遅延の一般的なパラメータの有効な値を指定しない場合があります。そのようなものとして、それらは[RFC2216]で定義された未知の値を使用することができます。
The ADSPEC is added to the RSVP PATH message created at the sender.
ADSPECは、送信側で作成されたRSVP PATHメッセージに追加されます。
An additional Tspec is defined to correspond to the Null Service. If only the Null Service is offered in the ADSPEC, then this is the only Tspec included in the SENDER_TSPEC object. If guaranteed or controlled load services are also offered in the ADSPEC, then the new Tspec is appended following the standard Intserv token-bucket Tspec [RFC2210].
追加のTspecはヌルサービスに対応するように定義されています。唯一のヌルサービスがADSPECで提供されている場合、これが唯一のTspecがSENDER_TSPECオブジェクトに含まれています。保証または制御負荷サービスもADSPECで提供されている場合は、新しいTspecは、標準的なイントサーブトークンバケツTspecは[RFC2210]以下に添付されています。
Receivers may respond to PATH messages by generating an RSVP RESV message including a FLOWSPEC object. The FLOWSPEC object should specify that it is requesting the Null Service. It is possible that, in the future, a specific Rspec may be defined to correspond to the new service type.
受信機は、FLOWSPECオブジェクトを含むRSVP RESVメッセージを生成することにより、PATHメッセージに応答することができます。 FLOWSPECオブジェクトは、それがヌルサービスを要求していることを指定する必要があります。将来的には、特定RSPEC新しいサービスタイプに対応するように定義されてもよい、ということが可能です。
A standard RSVP ADSPEC object is described in [RFC2210]. It includes a message header and a default general parameters fragment. Following the default general parameters fragment are fragments for each supported service type.
標準のRSVP ADSPECオブジェクトは[RFC2210]に記載されています。これは、メッセージヘッダとデフォルト一般パラメータの断片を含みます。デフォルトの一般的なパラメータのフラグメント以下のサポートされている各サービスタイプの断片です。
The Null Service ADSPEC includes the message header and the default general parameters fragment, followed by a single fragment denoting the Null Service. The new fragment introduced for the Null Service is formatted as follows:
ヌルサービスADSPECはヌルサービスを表す単一のフラグメントに続く、メッセージヘッダとデフォルト一般パラメータの断片を含みます。次のようにヌルサービスのために導入された新しいフラグメントがフォーマットされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 (a) |x| Reserved | 0 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a - indicates Null Service (6). x - is the break-bit. b - indicates zero words in addition to the header.
A - ヌルサービス（6）を示しています。 X - ブレークビットです。 B - ヘッダに加えて、ゼロの単語を示しています。
A complete ADSPEC supporting only the Null Service is illustrated below:
のみヌルサービスをサポートする完全なADSPECを以下に示します：
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Reserved | Msg length -1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| Reserved | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (e) | (f) | 1 (g) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | IS hop cnt (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Composed MTU (32-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 6 (q) |x| Reserved | 0 (r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Message Header: (a) - Message header and version number (b) - Message length (10 words not including header)
ワード1：メッセージヘッダー：（A） - メッセージヘッダーとバージョン番号（B） - （10ワードがヘッダを含まない）メッセージ長
Words 2-10: Default general characterization parameters (c) - Per-Service header, service number 1 (Default General Parameters) (x) - Global Break bit (NON_IS_HOP general parameter 2) (d) - Length of General Parameters data block (8 words) (e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general parameter) (f) - Parameter 4 flag byte (g) - Parameter 4 length, 1 word not including header (h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general parameter) (i) - Parameter 6 flag byte (j) - Parameter 6 length, 1 word not including header (k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general parameter) (l) - Parameter 8 flag byte (m) - Parameter 8 length, 1 word not including header (n) - Parameter ID, parameter 10 (PATH_MTU general parameter) (o) - Parameter 10 flag byte (p) - Parameter 10 length, 1 word not including header
単語2-10：デフォルトの一般的な特徴付けパラメータ（C） - サービスごとのヘッダ、サービス番号1（デフォルト一般的なパラメータ）（X） - グローバルブレークビット（NON_IS_HOP一般パラメータ2）（D） - 一般パラメータデータブロックの長さ（ 8ワード）（E） - パラメータID、パラメータ4（NUMBER_OF_IS_HOPS一般的なパラメータ）（F） - パラメータ4フラグバイト（G） - パラメータ4の長さ、ヘッダ（H）を含まない1ワード - パラメータID、パラメーター6（AVAILABLE_PATH_BANDWIDTH一般パラメータ）（I） - パラメータ6フラグバイト（J） - パラメータ6の長さ、ヘッダ（K）を含まない1ワード - パラメータID、パラメータ8（MINIMUM_PATH_LATENCY一般的なパラメータ）（L） - パラメータ8フラグバイト（M） - パラメータ8長さ、ヘッダ（n）を含まない1ワード - パラメータID、パラメータ10（PATH_MTU一般的なパラメータ）（O） - パラメータ10フラグバイト（P） - パラメータ10の長さ、ヘッダを含まない1つのワード
Word 11: Null Service parameters
Wordの11：ヌルサービスパラメータ
(q) - Per-Service header, service number 6 (Null) (x) - Break bit for Null Service (r) - Length (0) of per-service data not including header word.
（Q） - サービスごとのヘッダ、サービス番号6（ヌル）（X） - ヌルサービス（R）のためのブレークビット - （0）サービスごとのデータのヘッダワードを含まない長さ。
Note that the standard rules for parsing ADSPEC service fragments ensure that the ADSPEC will not be rejected by legacy network elements. Specifically, these rules state that a network element encountering a per-service data header which it does not understand should set bit 23 (the break-bit) to indicate that the service is not supported and should use the length field from the header to skip over the rest of the fragment.
ADSPECサービスフラグメントを解析するための標準的なルールは、ADSPECがレガシーネットワーク要素によって拒否されないことを保証することに注意してください。具体的には、これらのルールは、サービスがサポートされておらず、スキップするヘッダから長さフィールドを使用すべきことを指示することを理解していないサービスごとのデータのヘッダに遭遇するネットワーク要素は、ビット23（ブレークビット）に設定すべきであると述べていますフラグメントの残りの部分を超えます。
Also note that it is likely that it will not be possible for hosts or network nodes to generate meaningful values for words 5 and/or 7 (bandwidth estimates and path latency), due to the nature of the service. In this case, the unknown values from [RFC2216] should be used.
また、ホストまたはネットワークノードがサービスの性質に起因する単語5および/または7（帯域幅推定値及びパス待ち時間）のために意味のある値を生成することができなくなる可能性があることに注意してください。この場合には、[RFC2216]から未知の値を使用すべきです。
The following Tspec is defined to correspond to the Null Service:
次のTspecはヌルサービスに対応するように定義されています。
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 6 (a) |0| Reserved | 2 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 128 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Service header (a) - Service number 6 (Null Service) (b) - Length of per-service data, 2 words not including per-service header
ワード1： - サービス番号6（ヌル・サービス）（B） - （A）サービスヘッダごとのサービスデータの長さ、2つのワードが含まれていないサービスごとのヘッダ
Word 2-3: Parameter (c) - Parameter ID, parameter 128 (Null Service TSpec) (d) - Parameter 128 flags (none set) (e) - Parameter 128 length, 1 words not including parameter header
単語2-3：パラメータ（C） - パラメータIDパラメータ128（ヌルサービスTSpecの）（D） - パラメータ128個のフラグ（いずれも設定されていない）（E） - パラメータ128の長さ、パラメータヘッダを含まない1つのワード
Note that the illustration above does not include the standard RSVP SENDER_TSPEC object header, nor does it include the sub-object header (which indicates the message format version number and length), defined in RFC 2205 and RFC 2210, respectively.
図は、上記標準RSVP SENDER_TSPECオブジェクトヘッダが含まれていないことに留意されたい、またそれは、それぞれ、RFC 2205及びRFC 2210で定義された（メッセージフォーマットバージョン番号と長さを示す）サブオブジェクトヘッダーを含むありません。
In the case that only the Null Service is advertised in the ADSPEC, the Tspec above would be appended immediately after the SENDER_TSPEC object header and sub-object header. In the case that additional service types are advertised, requiring the token bucket specific Tspec defined in RFC2210, the Tspec above would be appended following the token bucket Tspec, which would in turn follow the object header and sub-object header.
のみヌルサービスはADSPECでアドバタイズされた場合に、Tspecは、上記SENDER_TSPECオブジェクトヘッダとサブオブジェクトヘッダの直後に付加されることになります。付加的なサービスタイプは、特定のTspecは、RFC2210で定義されたトークンバケットを必要とする、アドバタイズされた場合に、Tspecは、上記順番にオブジェクトヘッダとサブオブジェクトヘッダーをたどるトークンバケットTspecは、以下の添付されるであろう。
The format of an RSVP FLOWSPEC object originating at a receiver requesting the Null Service is shown below. The value of 6 in the per-service header (field (c), below) indicates that Null Service is being requested.
ヌルサービスを要求する受信機で発生RSVP FLOWSPECオブジェクトのフォーマットを以下に示します。サービスごとのヘッダ（以下フィールド（C））で6の値がnullサービスが要求されていることを示しています。
31 24 23 16 15 8 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 3 (b) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (c) |0| Reserved | 2 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 128 (e) | 0 (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0) (b) - Overall length (3 words not including header) (c) - Service header, service number 6 (Null) (d) - Length of data, 2 words not including per-service header (e) - Parameter ID, parameter 128 (Null Service TSpec) (f) - Parameter 128 flags (none set) (g) - Parameter 128 length, 1 words not including parameter header
（A） - メッセージフォーマットのバージョン番号（0）（B） - 全長（ヘッダを含まない3ワード）（C） - サービスヘッダ、サービス番号6（ヌル）（D） - データの長さ当たりを含まない2つのワード-serviceヘッダ（E） - パラメータIDパラメータ128（ヌルサービスTSpecの）（F） - パラメータ128個のフラグ（いずれも設定されていない）（G） - パラメータ128の長さ、パラメータヘッダを含まない1つのワード
DCLASS objects may be included in RESV messages. For details regarding the DCLASS object format, see [dclass].
DCLASSオブジェクトはRESVメッセージに含まれていてもよいです。 DCLASSオブジェクトフォーマットに関する詳細については、[DCLASS]参照。
The message formatting and usage rules described in this note raise no new security issues beyond standard RSVP.
このノートに記述されたメッセージのフォーマットと使用ルールは、標準のRSVPを超えた全く新しいセキュリティ上の問題を提起しません。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element QoS Control Service Specification Template", RFC 2216, September 1997.
[RFC2216] Shenker、S.とJ. Wroclawski、 "ネットワーク要素QoS制御サービス仕様テンプレート"、RFC 2216、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[intdiff] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Nichols, K., Speer, M., Braden, B. and B. Davie, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
【intdiff] Bernet、Y.、Yavatkar、R.、フォード、P.、ベイカー、F.、チャン、L.、ニコルズ、K.、シュペーア、M.、ブレーデン、B.及びB.デイビー、「フレームワークDiffservのネットワークの上に統合サービスオペレーション」、RFC 2998、2000年11月のため。
[diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[diffarch]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., "Identity Representation for RSVP", RFC 2752, January 2000.
[アイデンティティ] Yadavが、S.、Yavatkar、R.、Pabbati、R.、フォード、P.、ムーア、T.、ヘルツォーク、S.、 "RSVPのためのアイデンティティ表現"、RFC 2752、2000年1月。
[application] Bernet, Y., "Application and Sub Application Identity Policy Objects for Use with RSVP", RFC 2872, June 2000.
[アプリケーション] Bernet、Y.、 "RSVPで使用するアプリケーションおよびサブアプリケーションIDポリシーオブジェクト"、RFC 2872、2000年6月。
[dclass] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[DCLASS] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、2000年11月。
We thank Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein, Ramesh Pabbati and Sanjay Kaniyar for their comments on this memo.
私たちは、このメモの彼らのコメントのためのフレッド・ベイカー、ディネッシュダット、Nitsan Elfassy、ジョンSchnizlein、ラメシュPabbatiとサンジェイ・Kaniyarに感謝します。
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
よらｍ べｒねｔ みｃろそｆｔ おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２
Phone: +1 (425) 936-9568 EMail: Yoramb@microsoft.com
電話：+1（425）936-9568 Eメール：Yoramb@microsoft.com
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119, USA
アンドリュー・スミスアレグロ・ネットワーク6399サンイグナチオアベニュー。サンノゼ、CA 95119、USA
FAX: +1 415 345 1827 Email: andrew@allegronetworks.com
FAX：+1 415 345 1827 Eメール：andrew@allegronetworks.com
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824
ブルース・デイビーシスコシステムズ250アポロドライブチェルムズフォード、MA 01824
Phone: +1 (978)-244-8000 EMail: bsd@cisco.com
電話：+1（978）-244-8000 Eメール：bsd@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。