[要約] RFC 2997は、Nullサービスタイプの仕様を定めたものであり、要約すると以下のようになります。1. Nullサービスタイプは、ネットワーク上でのデータ転送を行わず、単にデータの存在を示すためのものです。 2. この仕様は、ネットワーク上でのデータの存在を確認するために使用されることを目的としています。 3. Nullサービスタイプは、ネットワーク上のリソースの状態を監視するために有用であり、ネットワーク管理者にとって便利なツールとなります。
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.
Copyright（c）The Internet Society（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アプリケーションは多くの場合、ミッションクリティカルであり、何らかの形の優先順位付けされたサービスを必要としますが、リソース要件を容易に指定することはできません。このようなアプリケーションを提供するために、「ヌルサービス」の概念を紹介します。nullサービスにより、アプリケーションは、RSVPシグナリングを使用して、ネットワーク品質サービス（QOS）ポリシーエージェントに自分自身を識別できます。ただし、リソース要件を指定する必要はありません。ネットワーク内のQoSポリシーエージェントは、アプリケーションに適したQoSポリシーを適用することで対応します（ネットワーク管理者によって決定されます）。RSVP使用のこのモードは、差別化されたサービス（DIFFSERV）QOSメカニズムとRSVPシグナル伝達[intdiff]を組み合わせたネットワークに特に適用できます。この環境では、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. 要求されたサービスレベル（保証または制御された負荷）。2.そのサービスレベルで必要なリソースの量。3.ネットワークが特定のトラフィックを認識できる分類情報（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.
保証および制御されたロードインターサービスサービスは、ネットワークから必要なリソースを指定できない（または選択しない）特定のアプリケーションには適していません。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ヘッダーのDiff -Serv CodePoint（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サービスのコンテキストで以前に議論されていることに注意してください。）このドキュメントは、nullサービスのコンテキストで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送信者は、パスメッセージに含まれるADSPECの新しいサービスタイプ「Nullサービスタイプ」を提供します。 新しいサービスタイプに対応する新しいTSPECがsender_tspecに追加されます。 さらに、RSVP送信者は通常、ユーザー、アプリケーション、およびサブアプリケーションID [ID、アプリケーション]を識別するPATHメッセージポリシーオブジェクトに含まれます。
(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.
これらのパスメッセージを受信するネットワークノードサービスタイプを解釈して、アプリケーションが特定のサービスタイプまたは定量化可能なリソースを要求していないことを示します。代わりに、ネットワークノードは、リクエストユーザー、要求アプリケーション、アプリケーションサブフローのタイプに基づいてトラフィックフローを管理します。
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. ノードを通過する特定のタイプのフローの数の観点からのリソースの需要。2.分類情報とユーザーの間の拘束力、アプリケーションとサブアプリケーション。
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、アプリケーション、および特定のサブアプリケーション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.
PEPSおよび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.
流量あたりのシグナル伝達が使用されるネットワークでは、スケーラビリティの懸念を考慮することが賢明です。NULLサービスは、そうでなければシグナルとされるものよりも、より広いアプリケーションのセットのシグナリングを奨励しています。ただし、一般に、RSVPシグナル伝達は、セッションに関連付けられている実際のデータトラフィックに比べて、かなりの量のトラフィックを生成しません。さらに、nullサービスは、すべてのアプリケーションが信号を送ることを奨励していません。ミッションクリティカルと見なされるアプリケーションでは、ネットワーク管理者による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.
おそらく、より懸念されるのは、シグナリングメッセージを処理するネットワークノードでのリソースの処理への影響です。この問題を検討する際には、各ネットワークノードで信号メッセージを処理する必要がないことを指摘することが重要です。実際、RSVPメッセージが特定のキーノード（ネットワークドメイン、ファーストホップルーター、PEPS、またはこれらのサブセット間の境界など）でのみ処理されている場合でも、RSVPシグナル伝達とDiff-Servネットワークの組み合わせは大きな利点をもたらす可能性があります。ネットワーク管理者の裁量で、RSVP処理のために個々のノードを有効または無効にする必要があります。diff-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仕様に付着するネットワークノードは、NULLサービスのシグナリングメッセージを透過的に渡す必要があります。そのため、Nullサービスのためにレガシーネットワークへのヌルサービスを有効にし、このドキュメントに記載されている利点を実現する少数の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.
このドキュメントでは、アプリケーションが定量的なInterVサービス（保証または制御された負荷）とNullサービスの両方を同時に提供することを妨げません。このようなアプリケーションの例は、保証されたサービスの恩恵を受けるが、それほど厳格ではないサービスに適応することができるテレフォニーアプリケーションです。両方に対するサポートを宣伝することにより、アプリケーションにより、ネットワークポリシーが提供するサービスタイプを決定することができます。
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送信者は、NULLサービスタイプを指定する初期RSVP ADSPECオブジェクトを構築します。このサービスタイプに関連付けられたサービス固有のパラメーターはないため、関連するADSPECフラグメントは空で、ヘッダーワードのみが含まれています。ネットワークノードは、帯域幅および潜伏期の一般的なパラメーターに有効な値を提供する場合としない場合があります。そのため、[RFC2216]で定義されている未知の値を使用する場合があります。
The ADSPEC is added to the RSVP PATH message created at the sender.
ADSPECは、送信者で作成されたRSVPパスメッセージに追加されます。
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は、nullサービスに対応するように定義されています。nullサービスのみがADSPECで提供されている場合、これはsender_tspecオブジェクトに含まれる唯一のtspecです。ADSPECで保証または制御されたロードサービスも提供されている場合、新しいTSPECは標準のIntServトークンバケット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オブジェクトは、nullサービスを要求していることを指定する必要があります。 将来、特定の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:
nullサービスADSPECには、メッセージヘッダーとデフォルトの一般的なパラメーターフラグメントが含まれ、その後にnullサービスを示す単一のフラグメントが含まれます。NULLサービス用に導入された新しいフラグメントは、次のようにフォーマットされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
NULLサービスのみをサポートする完全な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)
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
Word 11: Null Service parameters
ワード11：NULLサービスパラメーター
(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（null）（x） - ヘッダーワードを含むサービスごとのデータのnullサービス（R）のブレークビット（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は、NULLサービスに対応するように定義されています。
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：サービスヘッダー（a） - サービス番号6（nullサービス）（b） - サービスごとのデータの長さ、サービスごとのヘッダーを含む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
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.
上記の図には、それぞれRFC 2205とRFC 2210で定義されているサブオブジェクトヘッダー（メッセージ形式バージョン番号と長さを示す）も含まれていないことも、それぞれ標準のRSVP Sender_TSPECオブジェクトヘッダーも含まれていないことに注意してください。
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.
nullサービスのみがADSPECで宣伝されている場合、上記のTSPECは、sender_tspecオブジェクトヘッダーとサブオブジェクトヘッダーの直後に追加されます。RFC2210で定義されているトークンバケット固有のTSPECを要求する追加のサービスタイプが宣伝されている場合、上記の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.
NULLサービスを要求する受信機に発信されるRSVP FlowsPecオブジェクトの形式を以下に示します。サービスごとのヘッダー（以下のフィールド（c））の6の値は、ヌルサービスが要求されていることを示しています。
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
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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[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.、Ford、P.、Baker、F.、Zhang、L.、Nichols、K.、Speer、M.、Braden、B。and B. Davie、 "A FrameworkDiffservネットワークを介した統合サービス操作」、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.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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.、Ford、P.、Moore、T.、Herzog、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.
このメモに関するコメントをしてくれたフレッド・ベイカー、ディネシュ・ダット、ニサン・エルファシー、ジョン・シュニズレイン、ラメシュ・パバティ、サンジェイ・カニヤールに感謝します。
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
Yoram Bernet Microsoft One Microsoft Way Redmond、WA 98052
Phone: +1 (425) 936-9568
EMail: Yoramb@microsoft.com
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119, USA
アンドリュースミスアレグロネットワーク6399サンイグナシオアベニュー。サンノゼ、カリフォルニア州95119、米国
FAX: +1 415 345 1827
Email: andrew@allegronetworks.com
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824
ブルースデイビーシスコシステム250アポロドライブチェルムスフォード、マサチューセッツ州01824
Phone: +1 (978)-244-8000
EMail: bsd@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。