[要約] 要約：RFC 2996は、RSVP DCLASSオブジェクトのフォーマットに関する情報を提供しています。 目的：RSVPプロトコルの一部として、DCLASSオブジェクトを使用してトラフィックの優先度を指定するための標準化を目指しています。
Network Working Group Y. Bernet
Request for Comments: 2996 Microsoft
Category: Standards Track November 2000
Format of the RSVP DCLASS Object
RSVP DClassオブジェクトの形式
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
概要
Resource Reservation Protocol (RSVP) signaling may be used to request Quality of Service (QoS) services and enhance the manageability of application traffic's QoS in a differentiated service (diff-serv or DS) network. When using RSVP with DS networks it is useful to be able to carry carry Differentiated Services Code Points (DSCPs) in RSVP message objects. One example of this is the use of RSVP to arrange for the marking of packets with a particular DSCP upstream from the DS network's ingress point, at the sender or at a previous network's egress router.
リソース予約プロトコル（RSVP）シグナリングを使用して、サービス品質（QOS）サービスを要求し、差別化されたサービス（DIFF-SERVまたはDS）ネットワークでのアプリケーショントラフィックのQOの管理性を高めることができます。DSネットワークでRSVPを使用する場合、RSVPメッセージオブジェクトでキャリー差別化されたサービスコードポイント（DSCP）を運ぶことができると便利です。この1つの例は、RSVPを使用して、DSネットワークのイングレスポイントから、送信者または以前のネットワークの出力ルーターで上流の特定のDSCPを持つパケットのマーキングを手配することです。
The DCLASS object is used to represent and carry DSCPs within RSVP messages. This document specifies the format of the DCLASS object and briefly discusses its use.
D'Classオブジェクトは、RSVPメッセージ内でDSCPを表現および携帯するために使用されます。このドキュメントは、クラスオブジェクトの形式を指定し、その使用について簡単に説明します。
This section describes the mechanics of using RSVP [RSVP] signaling and the DCLASS object for effecting admission control and applying QoS policy within a Differentiated Service network [DS]. It assumes standard RSVP senders and receivers, and a diff-serv network somewhere in the path between sender and receiver. At least one RSVP aware network element resides in the diff-serv network. This network element may be a policy enforcement point (PEP) [RAP] or may simply act as an admission control agent for the network, admitting or denying resource requests based on the availability of resources. In either case, this network element interacts with RSVP messages arriving from outside the DS network, accepting resource requests from RSVP-aware senders and receivers, and conveying the DS network's admission control and resource allocation decisions to the higher-level RSVP. The network element is typically a router and will be considered to be so for the purpose of this document. This model is described fully in [INTDIFF].
このセクションでは、RSVP [RSVP]シグナル伝達を使用するメカニズムと、分化したサービスネットワーク[DS]内でQOSポリシーを適用するためのDCLASSオブジェクトについて説明します。標準のRSVP送信者とレシーバー、および送信者と受信機の間のパスのどこかに拡散ネットワークを想定しています。少なくとも1つのRSVP認識ネットワーク要素は、Diff-Servネットワークにあります。このネットワーク要素は、ポリシー執行ポイント（PEP）[RAP]であるか、ネットワークの入場管理エージェントとして機能し、リソースの可用性に基づいてリソース要求を認めたり拒否したりする場合があります。どちらの場合でも、このネットワーク要素は、DSネットワークの外部から到着するRSVPメッセージと相互作用し、RSVPを認識した送信者とレシーバーからのリソース要求を受け入れ、DSネットワークのアドミッションコントロールとリソース割り当ての決定を高レベルのRSVPに伝えます。ネットワーク要素は通常、ルーターであり、このドキュメントの目的のためにそうであると見なされます。このモデルは[intdiff]で完全に説明されています。
A principal usage of the DCLASS object is to carry DSCP information between a DS network and upstream nodes that may wish to mark packets with DSCP values. Briefly, the sender composes a standard RSVP PATH message and sends it towards the receiver. At some point the PATH message reaches the DS network. The PATH message traverses one or more network elements that are PEPs and/or admission control agents for the diff-serv network. These elements install appropriate state and forward the PATH message towards the receiver. If admission control is successful downstream of the diff-serv network, then a RESV message will arrive from the direction of the receiver. As this message arrives at the PEPs and/or admission control agents that are RSVP enabled, each of these network elements must make a decision regarding the admissibility of the signaled flow to the diff-serv network.
DCLASSオブジェクトの主要な使用法は、DSCP値でパケットをマークすることを希望するDSネットワークと上流ノードの間にDSCP情報を携帯することです。簡単に言えば、送信者は標準のRSVPパスメッセージを作成し、レシーバーに送信します。ある時点で、パスメッセージがDSネットワークに到達します。PATHメッセージは、DIF-ServネットワークのPEPおよび/または入場制御エージェントである1つ以上のネットワーク要素を横断します。これらの要素は、適切な状態をインストールし、受信機にパスメッセージを転送します。入場制御がDiff-Servネットワークの下流に成功した場合、RESVメッセージは受信機の方向から到着します。このメッセージがRSVPを有効にしているPEPおよび/または入場制御エージェントに到達すると、これらのネットワーク要素はそれぞれ、Diff-Servネットワークへの信号流の許容性に関して決定を下す必要があります。
If the network element determines that the request represented by the PATH and RESV messages is admissible to the diff-serv network, the appropriate diff-serv service level (or behavior aggregate) for the traffic represented in the RSVP request is determined. Next, a decision is made to mark arriving data packets for this traffic locally using MF classification, or to request upstream marking of the packets with the appropriate DSCP(s). This upstream marking could occur anywhere before the DS network's ingress point. Two likely candidates are the originating sender and the egress boundary router of some upstream (DS or non-DS) network. The decision about where the RSVP request's packets should be marked can be made by agreement or through a negotiation protocol; the details are outside the scope of this document.
ネットワーク要素がパスとRESVメッセージで表される要求がDiff-Servネットワークに容認できると判断した場合、RSVP要求に表されるトラフィックの適切なDIFSERVサービスレベル（または動作集計）が決定されます。次に、MF分類を使用してローカルにこのトラフィックに到着するデータパケットをマークするか、適切なDSCPを使用してパケットの上流マーキングを要求することを決定します。この上流のマーキングは、DSネットワークの入り口の前にどこでも発生する可能性があります。おそらく2つの候補者は、上流（DSまたは非DS）ネットワークの発信中の送信者と出口境界ルーターです。RSVPリクエストのパケットをマークする場所に関する決定は、合意または交渉プロトコルを通じて行うことができます。詳細は、このドキュメントの範囲外です。
If the packets for this RSVP request are to be marked upstream, information about the DSCP(s) to use must be conveyed from the RSVP-aware network element to the upstream marking point. This information is conveyed with the DCLASS object. To do this, the network element adds a DCLASS object containing one or more DSCPs corresponding to the behavior aggregate, to the RESV message. The RESV message is then sent upstream towards the RSVP sender.
このRSVPリクエストのパケットが上流にマークされる場合、使用するDSCPに関する情報をRSVPを認識したネットワーク要素からアップストリームマーキングポイントに伝える必要があります。この情報は、DCLASSオブジェクトで伝えられます。これを行うには、ネットワーク要素は、動作集計に対応する1つ以上のDSCPをRESVメッセージに含むDCLASSオブジェクトを追加します。その後、RESVメッセージはRSVP送信者に向かって上流に送信されます。
If the network element determines that the RSVP request is not admissible to the diff-serv network, it sends a RESV error message towards the receiver. No DCLASS is required.
ネットワーク要素がRSVP要求がDIFF-SERVネットワークに認められないと判断した場合、RESVエラーメッセージを受信機に送信します。DCLASSは必要ありません。
The DCLASS object is intended to be a general tool for conveying DSCP information in RSVP messages. This may be useful in a number of situations. We give one further example here as motivation.
DCLASSオブジェクトは、RSVPメッセージでDSCP情報を伝えるための一般的なツールであることを目的としています。これは、多くの状況で役立つ場合があります。ここでは、モチベーションとしてさらに1つの例を挙げます。
In this example, we assume that the decision about the appropriate behavior aggregate for a RSVP-mediated traffic flow is made at the DS network egress router (or a related Policy Decision Point) by observing RSVP PATH and RESV messages and other necessary information. However, the actual packet marking must be done at the ingress of the network. The DCLASS object can be used to carry the needed marking information between egress and ingress routers.
この例では、RSVPを介したトラフィックフローの適切な動作の合計に関する決定が、RSVPパスとRESVメッセージおよびその他の必要な情報を観察することにより、DSネットワーク出口ルーター（または関連するポリシー決定ポイント）で行われると想定しています。ただし、実際のパケットマーキングは、ネットワークの侵入で行う必要があります。DCLASSオブジェクトを使用して、出力ルーターとイングレスルーターの間に必要なマーキング情報を運ぶことができます。
The DCLASS object has the following format:
DCLASSオブジェクトには次の形式があります。
0 | 1 | 2 | 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (>= 8) | C-Num (225) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 1st DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 2nd DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | . . . . | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first word contains the standard RSVP object header (the Class Num for the DCLASS object is 225). The length field indicates the total object length in bytes. The object header is followed by one or more 32-bit words, each containing a DSCP in the six high-order bits of the least significant byte. The length field in the object header indicates the number of DSCPs included in the object. Specifically, the number of DCLASS objects present is equal to (Length - 4) / 4.
最初の単語には、標準のRSVPオブジェクトヘッダーが含まれています（DCLASSオブジェクトのクラスNumは225です）。長さフィールドは、バイト単位のオブジェクトの総長さを示します。オブジェクトヘッダーの後には、それぞれが最も重要なバイトの6つの高次ビットにDSCPを含む1つ以上の32ビット単語が続きます。オブジェクトヘッダーの長さフィールドは、オブジェクトに含まれるDSCPの数を示します。具体的には、存在するDCLASSオブジェクトの数は（長さ-4） / 4に等しくなります。
The network may return multiple DSCPs in the DCLASS object in order to enable the host to discriminate sub-flows within a behavior aggregate. For example, in the case of the AF PHB group [AF], the network may return the DSCPs 001010, 001100, and 001110 corresponding to increasing levels of drop precedence within Class 1 of the AF PHB group. Note that this document makes no statements regarding the significance of the order of the returned DSCPs. Further interpretation of DSCP sets is dependent on the specific service requested by the host and is beyond the scope of this document.
ネットワークは、ホストが動作の集合体内でサブフローを区別できるようにするために、DCLASSオブジェクトの複数のDSCPを返す場合があります。たとえば、AF PHBグループ[AF]の場合、ネットワークは、AF PHBグループのクラス1内での低下の優先順位の増加に対応するDSCPS 001010、001100、および001110を返すことができます。このドキュメントは、返されたDSCPSの順序の重要性に関する声明を発表していないことに注意してください。DSCPセットのさらなる解釈は、ホストが要求する特定のサービスに依存し、このドキュメントの範囲を超えています。
Note that the Class-Num for the DCLASS object is chosen from the space of unknown class objects that should be ignored and forwarded by nodes that do not recognize it. This is to assure maximal backward compatibility.
DCLASSオブジェクトのクラスNumは、認識されないノードによって無視され、転送されるべき不明なクラスオブジェクトの空間から選択されることに注意してください。これは、最大の後方互換性を保証するためです。
From a black-box perspective, admission control and policy functionality amounts to the decision whether to accept or reject a request and the determination of the DSCPs that should be used for the corresponding traffic. The specific details of admission control are beyond the scope of this document. In general the admission control decision is based both on resource availability and on policies regarding the use of resources in the diff-serv network. The admission control decision made by RSVP aware network elements represents both considerations.
ブラックボックスの観点から、入場制御とポリシーの機能は、リクエストを受け入れるか拒否するか、および対応するトラフィックに使用する必要があるDSCPの決定を決定することになります。入場制御の具体的な詳細は、このドキュメントの範囲を超えています。一般に、入場管理の決定は、リソースの可用性と、Diff-Servネットワークでのリソースの使用に関するポリシーの両方に基づいています。RSVP認識ネットワーク要素によって行われた入場管理の決定は、両方の考慮事項を表しています。
In order to decide whether the RSVP request is admissible in terms of resource availability, one or more network elements within or at the boundary of the diff-serv network must understand the impact that admission would have on specific diff-serv resources, as well as the availability of these resources along the relevant data path in the diff-serv network.
RSVP要求がリソースの可用性に関して認められるかどうかを判断するために、Diff-Servネットワーク内または境界内または境界内の1つ以上のネットワーク要素が、特定のdiff-servリソースに与える影響を理解する必要があります。Diff-Servネットワークの関連するデータパスに沿ったこれらのリソースの可用性。
In order to decide whether the RSVP request is admissible in terms of policy, the network element may use identity objects describing users and/or applications that may be included in the request. The router may act as a PEP/PDP and use data from a policy database or directory to aid in this decision.
RSVP要求がポリシーの観点から認められるかどうかを決定するために、ネットワーク要素は、リクエストに含まれる可能性のあるユーザーおよび/またはアプリケーションを説明するIDオブジェクトを使用する場合があります。ルーターは、PEP/PDPとして機能し、この決定を支援するためにポリシーデータベースまたはディレクトリのデータを使用できます。
See Appendix A for a simple mechanism for configurable resource based admission control.
構成可能なリソースベースの入場制御の簡単なメカニズムについては、付録Aを参照してください。
The DCLASS object conveys information that can be used to request enhanced QoS from a DS network, so inappropriate modification of the object could allow traffic flows to obtain a higher or lower level of QoS than appropriate. Particularly, modification of a DCLASS object by a third party inserted between the DS network ingress node and the upstream marker constitutes a possible denial of service attack. This attack is subtle because it is possible to reduce the received QoS to an unacceptably low level without completely cutting off data flow, making the attack harder to detect.
DCLASSオブジェクトは、DSネットワークから強化されたQOSを要求するために使用できる情報を伝達するため、オブジェクトの不適切な変更により、トラフィックフローが適切よりも高いレベルまたは低レベルのQOを取得できます。特に、DSネットワークイングレスノードと上流マーカーの間に挿入された第三者によるDCLASSオブジェクトの変更は、サービス拒否攻撃の可能性を構成します。この攻撃は、データフローを完全に遮断することなく、受信したQOを容認できないほど低いレベルに減らし、攻撃を検出しにくくすることができるため、微妙です。
The possibility of raising the received level of QoS by inappropriate modification of the DCLASS object is less significant because it a subclass of a larger class of attacks that must already be detected by the system. Protection must already be in place to prevent a host raising its received level of QoS by simply guessing "good" DSCP's and marking packets accordingly. If this protection is at the boundary of the DS network, it will detect inappropriate marking of arriving packets caused by modified DCLASS objects as well. If, however, the protection function as well as the marking function has been pushed upstream (perhaps to a trusted third party or intermediate node), correct transmission of the DCLASS object must be ensured to prevent a possible theft of service attack.
DCLASSオブジェクトの不適切な変更により受信レベルのQOSを引き上げる可能性は、システムによってすでに検出されなければならない大規模なクラスの攻撃のサブクラスであるため、それほど重要ではありません。「良い」DSCPを推測し、それに応じてマークパケットを推測することにより、ホストが受信したレベルのQoSを上げるのを防ぐために、保護を既に導入する必要があります。この保護がDSネットワークの境界にある場合、変更されたDCLASSオブジェクトによって引き起こされる到着パケットの不適切なマーキングも検出されます。ただし、保護関数とマーキング関数が上流（おそらく信頼できるサードパーティまたは中間ノードにプッシュされている場合、DCLASSオブジェクトの正しい送信を確保する必要があります。
Simple observation of the DCLASS object in a RSVP message raises several issues which may be seen as security concerns. Correlation of observed DCLASS object values with RSVP requests or MF classification parameters allows the observer to determine that different flows are receiving different levels of QoS, which may be knowledge that should be protected in some environments. Similarly, observation of the DCLASS object can allow the observer to determine that a single flow's QoS has been promoted or demoted, which may signal significant events in the life of that flow's application or user. Finally, observation of the DCLASS object may reveal information about the internal operations of a DS network that could be useful to observers interested in theft-of-services attacks.
RSVPメッセージ内のDCLASSオブジェクトの簡単な観察により、セキュリティの懸念と見なされる可能性のあるいくつかの問題が発生します。観測されたDCLASSオブジェクト値のRSVP要求またはMF分類パラメーターとの相関により、オブザーバーは、さまざまなレベルのQOを受信していることを判断することができます。これは、一部の環境で保護されるべき知識である可能性があります。同様に、DCLASSオブジェクトの観察により、観測者は単一のフローのQOが宣伝または降格されたことを判断することができ、その流れのアプリケーションまたはユーザーの寿命における重要なイベントを示す可能性があります。最後に、DCLASSオブジェクトの観察は、盗難攻撃に関心のあるオブザーバーに役立つDSネットワークの内部操作に関する情報を明らかにする可能性があります。
[INTDIFF] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B. and J. Wroclawski, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[Intdiff] Bernet、Y.、Yavatkar、R.、Ford、P.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B。、J。Wroclawski、 "A FrameworkDiffservネットワークを介した統合サービス操作」、RFC 2998、2000年11月。
[DS] Blake, S., Carlson, M., Davies, D., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DS] Blake、S.、Carlson、M.、Davies、D.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、RFC 2475、1998年12月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[Rap] Yavatkar、R.、Pendarakis、D。and R. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
Thanks to Fred Baker and Carol Iturralde for reviewing this document. Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for input.
この文書をレビューしてくれたフレッド・ベイカーとキャロル・イトゥルラルドに感謝します。Ramesh Pabbati、Tim Moore、Bruce Davie、Kam Leeに入力してくれてありがとう。
Yoram Bernet Microsoft One Microsoft Way, Redmond, WA 98052
Yoram Bernet Microsoft One Microsoft Way、Redmond、WA 98052
Phone: (425) 936-9568 EMail: yoramb@microsoft.com
電話：（425）936-9568メール：Yoramb@microsoft.com
Appendix A - Simple Configurable Resource Based Admission Control
付録A-シンプルな構成可能なリソースベースの入場制御
Routers may use quite sophisticated mechanisms in making the admission control decision, including policy considerations, various intra-domain signaling protocols, results of traffic monitoring and so on. It is recommended that the following basic functionality be provided to enable simple resource based admission control in the absence of more sophisticated mechanisms. This functionality can be used with configurable, standalone routers. It applies to standard RSVP/Intserv requests. This minimal functionality assumes only a single DSCP is included in the DCLASS object, but may readily be extended to support multiple DSCPs.
ルーターは、ポリシーの考慮事項、さまざまなドメイン内シグナル伝達プロトコル、交通監視の結果など、入学管理の決定を行う際に非常に洗練されたメカニズムを使用する場合があります。より洗練されたメカニズムがない場合に、シンプルなリソースベースの入場制御を可能にするために、次の基本機能を提供することをお勧めします。この機能は、構成可能なスタンドアロンルーターで使用できます。標準のRSVP/IntServリクエストに適用されます。この最小限の機能は、DCLASSオブジェクトに1つのDSCPのみが含まれていると想定していますが、複数のDSCPをサポートするために容易に拡張することができます。
It must be possible to configure two tables in the router. These are described below.
ルーターに2つのテーブルを構成することが可能である必要があります。これらを以下に説明します。
One table provides a mapping from the intserv service-type specified in the RSVP request to a DSCP that can be used to obtain a corresponding service in the diff-serv network. This table contains a row for each intserv service type for which a mapping is available. Each row has the following format:
1つのテーブルは、RSVPリクエストで指定されたIntServサービスタイプからDSCPへのマッピングを提供します。DSCPは、DIFF-Servネットワークで対応するサービスを取得するために使用できます。このテーブルには、マッピングが利用可能な各intservサービスタイプの行が含まれています。各行には次の形式があります。
Intserv service type : DSCP
IntServサービスタイプ：DSCP
The table would typically contain at least three rows; one for Guaranteed service, one for Controlled Load service and one for Best-Effort service. (The best-effort service will typically map to DSCP 000000, but may be overridden). It should be possible to add rows for as-yet-undefined service types.
テーブルには通常、少なくとも3列が含まれます。1つは保証されたサービス用、1つは制御されたロードサービス用、もう1つは最良のサービス用です。（ベストエフォルトサービスは通常、DSCP 000000にマッピングされますが、オーバーライドされる場合があります）。まだ未定義のサービスタイプに行を追加することができるはずです。
This table allows the network administrator to statically configure a DSCP that the router will return in the DCLASS object for an admitted RSVP request. In general, more sophisticated and likely more dynamic mechanisms may be used to determine the DSCP to be returned in the DCLASS object. Also, it is likely that a real mapping for some services would use more than one DSCP, with the DSCP depending on the invocation parameters of a specific service request. In this case, these mechanisms may override or replace the static table based mapping described here.
このテーブルにより、ネットワーク管理者は、ルーターがDCLASSオブジェクトに戻るDSCPを静的に構成し、認められたRSVPリクエストを行うことができます。一般に、DCLASSオブジェクトで返されるDSCPを決定するために、より洗練された可能性のあるより動的なメカニズムを使用することができます。また、一部のサービスの実際のマッピングは、特定のサービス要求の呼び出しパラメーターに応じて、DSCPを使用して複数のDSCPを使用する可能性があります。この場合、これらのメカニズムは、ここで説明する静的テーブルベースのマッピングをオーバーライドまたは交換する場合があります。
Standard intserv requests are quantitative in nature. They include token bucket parameters describing the resources required by the traffic for which admission is requested. The second table enables the network administrator to statically configure quantitative parameters to be used by the router when making an admission control decision for quantitative service requests. Each row in this table has the following form:
本質的に標準的なIntServリクエストは定量的です。それらには、入場が要求されるトラフィックに必要なリソースを説明するトークンバケットパラメーターが含まれます。2番目のテーブルにより、ネットワーク管理者は、定量的サービスリクエストのために入学制御決定を行う際に、ルーターが使用する定量的パラメーターを静的に構成できます。このテーブルの各行には、次の形式があります。
DSCP : Token bucket profile
DSCP：トークンバケットプロファイル
The first column specifies those DSCPs for which quantitative admission control is applied. The second column specifies the token bucket parameters which represent the total resources available in the diff-serv network to accommodate traffic in the service class specified by the DSCP.
最初の列は、定量的な入場制御が適用されるDSCPを指定します。2番目の列は、DSCPが指定したサービスクラスのトラフィックに対応するために、Diff-Servネットワークで利用可能な総リソースを表すトークンバケットパラメーターを指定します。
Full Copyright Statement
完全な著作権声明
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エディター機能の資金は現在、インターネット協会によって提供されています。