RFC2997 日本語訳
2997 Specification of the Null Service Type. Y. Bernet, A. Smith, B.Davie. November 2000. (Format: TXT=25071 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Bernet Request for Comments: 2997 Microsoft Category: Standards Track A. Smith Allegro Networks B. Davie Cisco Systems November 2000
Bernetがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2997年のマイクロソフトカテゴリ: 規格は2000年11月にA.スミスアレグロネットワークB.デイビーシスコシステムズを追跡します。
Specification of the Null Service Type
ヌルサービスタイプの仕様
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
典型的なResource予約プロトコル(RSVP)/Intservモデルでは、アプリケーションは、特定のIntservサービスタイプを要求して、そのサービスに必要であるリソースを定量化します。 あるアプリケーションにおいて、サービスパラメタの決断をネットワーク管理者に任せるのは最も良いです。 例えば、ERPアプリケーションは、しばしばミッションクリティカルであり、何らかの形式の最優先するサービスを必要としますが、容易にそれらのリソース要件を指定できません。 そのようなアプリケーションに役立つように、私たちは'ヌルService'の概念を紹介します。 RSVPシグナリングを使用して、Null ServiceはアプリケーションにService(QoS)方針エージェントのネットワークQualityに自分たちを特定させます。 しかしながら、リソース要件を指定するのがそれらを必要としません。 ネットワークのQoS方針エージェントは、アプリケーションに、適切なQoS方針を適用することによって、応じます(ネットワーク管理者によって決定されるように)。 RSVP用法のこのモードは特に差別化されたサービス(diffserv)QoSメカニズムを合図するRSVPに結合するネットワーク[intdiff]に適切です。 この環境で、QoS方針エージェントは特定のdiffservのクラスのサービスに合図されたアプリケーションのトラフィックを向けるかもしれません。
Bernet, et al. Standards Track [Page 1] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[1ページ]。
1. Motivation
1. 動機
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. または、要求されたサービスレベル、(保証、Controlled Load) 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意識しているネットワーク・ノードは、資源要求を認めるか、または否定するのを選びます。 決定は関連経路と方針に関するリソースの有用性に基づいています。 方針は特定のユーザ、そして/または、アプリケーションに与えられるかもしれないリソースを定義します。 資源要求が認められるとき、ネットワーク・ノードは認められたトラフィックを認識するのに使用されるクラシファイアとトラフィックがリソースの限界の中に要求されていたままで残っていることを保証するのに使用されるpolicersをインストールします。
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.
GuaranteedとControlled Load Intservサービスは彼らがネットワークから必要とするリソースを指定できない(そうしないのを選んでください)あるアプリケーションに適していません。 Diffservサービスはこのタイプの適用に合うほうがよいです。 diffservネットワークにおけるノードは、到着パケットを何らかの少ない数の振舞い集合(BAs)[diffarch]に分類するために通常食糧を供給されます。 トラフィックは1BAあたり1個のベースで扱われます。 この食糧を供給するのは、ことホストとネットワークの間で合図してはいけないという意味におけるエンドユーザ交通の流れに関する'先端ダウンする'である傾向があります。 代わりに、ネットワーク管理者は発見的教授法、測定の組み合わせを使用します、そして、ネットワークデバイスを支給に経験して、どんな特定のノードにも到着する交通量について決定論的な知識なしで集められたトラフィックを扱ってください。
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のために到着するすべてのトラフィックに対するサービスに感染して。
Bernet, et al. Standards Track [Page 2] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[2ページ]。
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ヘッダーか他の分野に基づいたパケットのIPヘッダー(ソース/目的地アドレス/港とプロトコル)のデフ-serv codepoint(DSCP)に基づいて。 分類の後者のメソッドは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ネットワークにおけるアプリケーショントラフィックの管理をかなり容易にすることができます。 (以前にGuaranteedの、そして、Controlled Load Intservサービスの文脈でRSVP/diffserv相互運用性について議論したことに注意してください。) このドキュメントはNull Serviceの文脈のRSVP/diffserv相互運用性に焦点を合わせます。
2. Operational Overview
2. 操作上の概要
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は、'ヌルService Type'とPATHメッセージで含まれているADSPECにタイプします。 新しいサービスタイプにおいて、対応する新しいTspecはSENDER_TSPECに加えられます。 さらに、PATHメッセージ政策目的がユーザ、アプリケーション、および潜水艦アプリケーションを特定している状態で、RSVP送付者は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. ノードを横断する特定のタイプの流れの数に関するリソースの要求。 2. 分類情報と、ユーザと、アプリケーションとサブアプリケーションの間の結合。
Bernet, et al. Standards Track [Page 3] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[3ページ]。
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.
この情報は特に方針実施ポイントと政策決定ポイント(PEPsとPDPs)の役に立ちます。 ネットワーク管理者は、ユーザ、アプリケーション、および特定の潜水艦アプリケーション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とPDPsは、RSVP RESVメッセージを送付者に返すために構成されるかもしれません。 返されたRESVメッセージはDCLASSオブジェクト[dclass]を含むかもしれません。 DCLASSオブジェクトは、特定のDSCP(または、DSCPsのセット)を対応する流れのパケットに付けるよう送付者に命令します。 このメカニズムで、PEP/PDPsはBAを考えて、いずれのためのノードに到着する交通量に影響できます。 それは、PEP/PDPが高度な方針に基づいてそうするのを可能にします。
3.1 Operational Notes
3.1 操作上の注意
3.1.1 Scalability Issues
3.1.1 スケーラビリティ問題
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.
1流れあたりのシグナリングが使用されたどんなネットワークでも、スケーラビリティ関心を考えるのは賢明です。 Null Serviceは、別の方法で合図されるそれより広いアプリケーションのために合図するよう奨励します。 しかしながら、一般に、RSVPシグナリングはセッションに関連している実際のデータ通信量に比例してかなりの量のトラフィックを生成しません。 さらに、Null Serviceは、あらゆるアプリケーションが合図するよう奨励しません。 それは、ミッションクリティカルであると考えられるアプリケーションで使用されるべきであるか、またはネットワーク管理者で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またはどんな部分集合などのも)だけで処理さえされるとき、デフ-servネットワークへのRSVPシグナリングの組み合わせは重要な利益を都合するかもしれません。 個々のノードは、RSVP処理のためにネットワーク管理者の裁量で可能にされるべきであるか、または利かなくされるべきです。 デフ-servネットワークについてのRSVPシグナリングの影響の議論に関して[intdiff]を見てください。
In any case, per-flow state is not necessarily required, even in nodes that apply per-flow processing.
どのような場合でも、1流れあたりの状態が必ず1流れあたりの処理を当てはまるノードでさえ必要であるというわけではありません。
Bernet, et al. Standards Track [Page 4] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[4ページ]。
2.1.2 Policy Enforcement in Legacy Networks
2.1.2 レガシーネットワークにおける方針実施
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 Serviceへのシグナリングメッセージを通過するはずです。 そういうものとして、Null Serviceのために有効にされるPEPsの少ない数をレガシーネットワークに取り入れて、本書では説明された利益がわかるのは可能です。
2.1.3 Combining Existing Intserv Services with the Null Service
2.1.3 既存のIntservサービスをヌルサービスに結合すること。
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.
または、このドキュメントが量的なIntservサービスを両方に提供するのからのアプリケーションを排除しない、(保証、Controlled Load) そして、同時間のNull Service。 そのようなアプリケーションに関する例は、Guaranteed Serviceの利益を得る電話アプリケーションでしょうが、それほど厳しくないサービスに順応できます。 両方のサポートの広告を出すことによって、アプリケーションは、ネットワーク方針が、どのサービスタイプを提供したらよいかを決めるのを可能にします。
3. Signaling Details
3. シグナリングの詳細
3.1 ADSPEC Generation
3.1ADSPEC世代
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 Service Typeを指定する初期のRSVP ADSPECオブジェクトを組み立てます。 あるので、特定のパラメタがこのサービスタイプ、関連ADSPEC断片に関連づけなかったサービスは、全く空であり、ヘッダー単語だけを含んでいます。 ネットワーク・ノードは帯域幅と潜在一般的指標に有効値を供給するかもしれません。 そういうものとして、彼らは[RFC2216]で定義された未知の値を使用するかもしれません。
The ADSPEC is added to the RSVP PATH message created at the sender.
ADSPECは送付者で作成されたRSVP PATHメッセージに追加されます。
3.2 RSVP SENDER_TSPEC Object
3.2 RSVP送付者_TSPECは反対します。
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 Serviceに相当するように定義されます。 ADSPECでNull Serviceだけを提供するなら、これはSENDER_TSPECオブジェクトに含まれていた唯一のTspecです。 また、ADSPECで保証されたか制御された負荷サービスを提供するなら、標準のIntservトークンバケツTspec[RFC2210]に続いて、新しいTspecを追加します。
3.3 RSVP FLOWSPEC Object
3.3 RSVP FLOWSPECは反対します。
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 Serviceを要求していると指定するはずです。 特定のRspecが未来に新しいサービスタイプに相当するように定義されるのは、可能です。
Bernet, et al. Standards Track [Page 5] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[5ページ]。
4. Detailed Message Formats
4. 詳細なメッセージ・フォーマット
4.1 Standard ADSPEC Format
4.1 標準のADSPEC形式
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]で説明されます。 それはメッセージヘッダーとデフォルト一般的指標断片を含んでいます。 デフォルトに従って、一般的指標断片はサービスタイプであるとサポートされたそれぞれのための断片です。
4.2 ADSPEC for Null Service Type
4.2 ヌルサービスのためのADSPECはタイプします。
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 Service ADSPECはメッセージヘッダーとデフォルト一般的指標断片を含んでいます、続いて、Null Serviceを指示するただ一つの断片を含んでいます。 Null Serviceのために紹介された新しい断片は以下の通りフォーマットされます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 (a) |x| Reserved | 0 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 (a)|x| 予約されます。| 0 (b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a - indicates Null Service (6). x - is the break-bit. b - indicates zero words in addition to the header.
中断ビットはそうです。a--、表示、Null Service(6)x--b--ヘッダーに加えて言葉を全く示しません。
Bernet, et al. Standards Track [Page 6] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[6ページ]。
A complete ADSPEC supporting only the Null Service is illustrated below:
Null Serviceだけをサポートする完全な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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a)| 予約されます。| エムエスジー長さ-1の(b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c)|x| 予約されます。| 8 (d)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 4 (e)| (f) | 1 (g)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | ホップcntは(32ビット未署名)ですか?| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | 6 (h)| (i) | 1 (j)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 経路b/w見積り(32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 8 (k)| (l) | 1 (m)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 最小の経路潜在(32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 10 (n)| (o) | 1 (p)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | 落ち着いたMTU(32ビット未署名の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | 6 (q)|x| 予約されます。| 0 (r)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Message Header: (a) - Message header and version number (b) - Message length (10 words not including header)
Word1: メッセージヘッダー: (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
ワーズ2-10: デフォルト一般的性質パラメタ(c)--1サービスあたりのヘッダー、認識番号1(デフォルトParameters司令官)(x)--グローバルなBreakはパラメタ4(NUMBER_OF_は_ホップス一般的指標です)(f)--パラメタ4フラグバイト(g)--(d)--一般Parametersデータ・ブロック(8つの単語)(e)の長さ--Parameter ID、パラメタ4の長さに噛み付きました(NON_は_HOP一般的指標2です); ヘッダー(h)を含まない1つの単語--ヘッダー(k)を含まない1つの単語--Parameter ID、パラメタ8(MINIMUM_PATH_LATENCY一般的指標)(l)--Parameter ID、パラメタ6(AVAILABLE_PATH_BANDWIDTH一般的指標)(i)--パラメタ6フラグバイト(j)--パラメタ6の長さ、パラメタ8フラグバイト
Bernet, et al. Standards Track [Page 7] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[7ページ]。
(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
パラメタ10(PATH_MTU一般的指標)(o)--パラメタ10フラグバイト(p)--(m)--パラメタ8の長さ、ヘッダー(n)を含まない1つの単語--Parameter ID、パラメタ10の長さ、ヘッダーを含まない1つの単語
Word 11: Null Service parameters
Word11: ヌルServiceパラメタ
(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)--1サービスあたりのヘッダー、認識番号6(ヌル)(x)--Null Service(r)のために噛み付かれるのに壊れてください--ヘッダー単語を含まない1サービスあたりのデータの長さ(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がレガシーネットワーク要素によって拒絶されないのを確実にすることに注意してください。 明確に、これらの規則は、それが理解していない1サービスあたり1個のデータヘッダーに遭遇するネットワーク要素がビット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]からの未知の値は使用されるべきです。
4.3 SENDER_TSPEC Object Format
4.3 送付者_TSPECオブジェクト形式
The following Tspec is defined to correspond to the Null Service:
以下のTspecはNull Serviceに相当するように定義されます:
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 6 (a)|0| 予約されます。| 2 (b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 128 (c)| 0 (d)| 1 (e)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 最大のPacket Size[M](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Service header (a) - Service number 6 (Null Service) (b) - Length of per-service data, 2 words not including per-service header
Word1: サービスヘッダー(a)--認識番号6(ヌルService)(b)--1サービスあたりのデータ、1サービスあたりのヘッダーを含まない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
Word2-3: パラメタ(c)--パラメタ128(ヌルService TSpec)(d)--パラメタ128旗(なにもセットしなかった)の(e)--Parameter ID、パラメタヘッダーを含んでいなくて、1が言い表すパラメタ128の長さ
Bernet, et al. Standards Track [Page 8] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[8ページ]。
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オブジェクトヘッダーを含んでいないことに注意してください、そして、それはRFC2205とRFC2210でそれぞれ定義されたサブオブジェクトヘッダー(メッセージ・フォーマットバージョン番号と長さを示す)を含んでいません。
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 ServiceだけがADSPECの広告に掲載されていて、SENDER_TSPECオブジェクトヘッダーとサブオブジェクトヘッダー直後上のTspecを追加するでしょう。 追加サービスタイプが広告に掲載されていて、トークンバケツTspec(順番に、オブジェクトヘッダーとサブオブジェクトヘッダーに続く)に続いて、特定のTspecが上でRFC2210、Tspecで定義したトークンバケツを必要とするのを追加するでしょう。
4.4 FLOWSPEC Object Format
4.4 FLOWSPECオブジェクト形式
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 Serviceを要求しながら受信機で起因するRSVP FLOWSPECオブジェクトの書式は以下に示されます。 1サービスあたりのヘッダー(下の分野(c))の6の値は、Null Serviceが要求されているのを示します。
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a)| 予約されます。| 3 (b)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 6 (c)|0| 予約されます。| 2 (d)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 128 (e)| 0 (f)| 1 (g)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 最大のPacket Size[M](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(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)--パラメタ128(ヌルService TSpec)(f)--パラメタ128旗(なにもセットしなかった)の(g)--メッセージ・フォーマットバージョン数(0)(b)--全長(ヘッダーを含まない3つの単語)(c)--サービスヘッダー、認識番号6(ヌル)(d)--データ、1サービスあたりのヘッダー(e)を含まない2つの単語の長さ--Parameter ID、パラメタヘッダーを含んでいなくて、1が言い表すパラメタ128の長さ
4.5 DCLASS Object Format
4.5 DCLASSオブジェクト形式
DCLASS objects may be included in RESV messages. For details regarding the DCLASS object format, see [dclass].
DCLASSオブジェクトはRESVメッセージに含まれるかもしれません。 DCLASSオブジェクト形式に関する詳細に関しては、[dclass]を見てください。
5. Security Considerations
5. セキュリティ問題
The message formatting and usage rules described in this note raise no new security issues beyond standard RSVP.
この注意で説明されたメッセージ形式と用法規則は標準のRSVPを超えてどんな新しい安全保障問題も提起しません。
Bernet, et al. Standards Track [Page 9] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[9ページ]。
6. References
6. 参照
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2216] 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月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、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.とフォードとP.とベイカーとF.とチャンとL.とニコルズとK.とシュペーアとM.とブレーデンとB.とB.デイビー、「Diffservネットワークの上の統合サービス操作のためのフレームワーク」、RFC2998、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.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、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のアイデンティティ表現」、RFC2752(2000年1月)。
[application] Bernet, Y., "Application and Sub Application Identity Policy Objects for Use with RSVP", RFC 2872, June 2000.
[アプリケーション] Bernet、「アプリケーションと潜水艦アプリケーションアイデンティティ方針はRSVPとの使用のために反対させる」Y.、RFC2872、6月2000日
[dclass] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[dclass]Bernet、Y.、「RSVP DCLASSオブジェクトの形式」、RFC2996、2000年11月。
7. Acknowledgments
7. 承認
We thank Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein, Ramesh Pabbati and Sanjay Kaniyar for their comments on this memo.
私たちはこのメモの彼らのコメントについてフレッド・ベイカー、Dineshダッタ、Nitsan Elfassy、ジョンSchnizlein、Ramesh Pabbati、およびSanjay Kaniyarに感謝します。
Bernet, et al. Standards Track [Page 10] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[10ページ]。
8. Authors' Addresses
8. 作者のアドレス
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
ヨラムBernetマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 (425) 936-9568 EMail: Yoramb@microsoft.com
以下に電話をしてください。 +1 (425) 936-9568 メールしてください: Yoramb@microsoft.com
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119, USA
アンドリュー・スミスAllegroは6399サンイグナシオAveをネットワークでつなぎます。 サンノゼ、カリフォルニア 95119、米国
FAX: +1 415 345 1827 Email: andrew@allegronetworks.com
Fax: +1 1827年の415 345メール: andrew@allegronetworks.com
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824
ブルースデイビーシスコシステムズ250アポロDriveチェルムズフォード、MA 01824
Phone: +1 (978)-244-8000 EMail: bsd@cisco.com
以下に電話をしてください。 +1 (978)244-8000メール: bsd@cisco.com
Bernet, et al. Standards Track [Page 11] RFC 2997 Specification of Null Service Type November 2000
Bernet、他 規格はタイプ2000年11月にヌルサービスのRFC2997仕様を追跡します[11ページ]。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Bernet, et al. Standards Track [Page 12]
Bernet、他 標準化過程[12ページ]
一覧
スポンサーリンク