Network Working Group Y. Bernet
Request for Comments: 2996 Microsoft
Category: Standards Track November 2000
Format of the RSVP DCLASS Object
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
抽象
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）のサービスを要求し、差別化サービス（差分-SERVまたはDS）ネットワークにおけるアプリケーショントラフィックのQoSの管理性を向上させるために使用することができます。 DSのネットワークとRSVPを使用する場合は、RSVPメッセージのオブジェクトにDiffServコードポイント（DSCPを）を運ぶ運ぶことができるように便利です。この一例は、送信側で、または以前のネットワークの出口ルータで、上流のDSネットワークの入力点から特定のDSCPを持つパケットのマーキングのために配置するRSVPを使用することです。
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.
DCLASSオブジェクトを表し、RSVPメッセージ内のDSCPを運ぶために使用されます。この文書では、DCLASSオブジェクトのフォーマットを指定し、簡単にその使用について説明します。
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].
このセクションでは、[DS]アドミッション制御を行うと差別化サービスネットワーク内のQoSポリシーを適用するためのRSVP [RSVP]シグナリングおよびDCLASSオブジェクトを使用しての力学を記述する。これは、送信側と受信側の間のパスのどこかに、標準のRSVP送信者と受信者、および差分-SERVネットワークを前提としています。少なくとも一つのRSVP意識のネットワーク要素は、差分-SERVネットワーク内に存在します。このネットワーク要素は、ポリシー施行点（PEP）[RAP]であってもよいし、単にリソースの可用性に基づいて、リソース要求を認めるか、拒否、ネットワーク用のアドミッション制御剤として作用することができます。いずれの場合も、このネットワーク要素は、RSVP対応の送信者と受信者からのリソース要求を受け入れ、DSのネットワークの外部から到着RSVPメッセージと対話し、より高いレベルのRSVPにDSネットワークのアドミッション制御およびリソース配分の決定を伝えます。ネットワーク要素は、通常のルータであり、この文書の目的のためにそうであると見なされます。このモデルは、[INTDIFF]に完全に記載されています。
1.1 Use of the DCLASS Object to Carry Upstream Packet Marking Information
DCLASSオブジェクトの1.1を使用するには、上りパケットマーキング情報を伝えるために
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 PATHメッセージを構成し、受信機に向けて送信します。いくつかの時点で、PATHメッセージは、DSのネットワークに到達しました。 PATHメッセージは、差分-SERVネットワークのためのPEP及び/又はアドミッション制御剤である1つのまたは複数のネットワーク要素を横断します。これらの要素は、適切な状態をインストールして、受信機に向けてPATHメッセージを転送します。アドミッション制御はデフ-SERVネットワークの下流に成功した場合、RESVメッセージは、受信機の方向から到着します。このメッセージはRSVPが有効になっているのPEP及び/又はアドミッション制御剤に到達するように、これらのネットワーク要素のそれぞれは、差分-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.
ネットワーク要素はPATHとRESVメッセージによって表される要求は差分-SERVネットワークに許容であると判断した場合に、RSVP要求に表されるトラフィックのための適切な差分-SERVサービスレベル（または行動集合）が決定されます。次に、この決定は、局所的MF分類を使用して、このトラフィックのデータパケットの到着マークするために、又は適切なDSCP（S）とパケットのマーキング上流要求するために構成されています。マーキングこの上流には、DSのネットワークの入力点の前にどこにでも発生する可能性があります。二つの有望な候補は、元の送信者と一部の上流（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（S）に関する情報は、上流のマーキングポイントにRSVPアウェアネットワーク要素から搬送されなければなりません。この情報は、DCLASSオブジェクトと搬送されます。これを行うために、ネットワーク要素は、RESVメッセージに、ビヘイビア集合体に対応する1つの以上のDSCPを含む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要求が差分-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情報を搬送するための一般的なツールであることが意図されています。これは、多くの状況で有用である可能性があります。私たちはモチベーションとして、ここで一つのさらなる例を与えます。
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のPATHと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オブジェクトのクラス民は225である）を含みます。長さフィールドは、バイト単位の総物体長を示します。オブジェクトヘッダは、それぞれ最下位バイト六上位ビットにDSCPを含む一つ以上の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内の廃棄優先順位のレベルを増加させることに対応するのDSCP 001010、001100、および001110を返すことができます。この文書は返されたのDSCPのための重要性に関していかなる声明を行わないことに注意してください。 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の決定を受け入れるか拒否するかどうかの決定になります。アドミッション制御の具体的な詳細は、このドキュメントの範囲を超えています。一般に、アドミッション制御の決定は、リソースの可用性にと差分-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要求は、リソースの可用性の面で許容されるかどうかを決定するためには、差分-SERVネットワークの境界内または1つの以上のネットワーク要素は、同様に、入場料は、特定の差分-SERVリソース上でなければならない影響を理解しなければなりません差分-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要求がポリシーの点で許容であるかどうかを決定するために、ネットワーク要素は、要求に含めることができるユーザおよび/またはアプリケーションを記述アイデンティティオブジェクトを使用してもよいです。ルータは、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オブジェクトは、加工対象物の不適切な変更は、トラフィックが適切なQoSよりも高いまたは低いレベルを得ることが流れる可能性があり、DSネットワークから拡張QoSを要求するために使用できる情報を搬送します。特に、DSネットワークの入口ノードと上流のマーカーの間に挿入され、第三者によってDCLASSオブジェクトの変更は、サービス攻撃の拒否可能となります。完全に検出する攻撃が難しくなって、データの流れを遮断することなく、許容できないほど低いレベルに受信したQoSを低減することが可能であるため、この攻撃は微妙です。
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オブジェクトの単純な観察は、セキュリティ上の問題として見られるかもしれないいくつかの問題を提起します。 RSVP要求またはMF分類パラメータを用いて観察DCLASSオブジェクト値の相関は、観察者が異なるフローは、いくつかの環境で保護されなければならない知識であってもよいのQoSの異なるレベルを、受信されることを決定することを可能にします。同様に、DCLASSオブジェクトの観察は、観察者が単一のフローのQoSを促進又はそのフローのアプリケーションまたはユーザーの生活の中で重要なイベントを知らせることができる、降格されたことを決定することを可能にすることができます。最後に、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.、フォード、P.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.及びJ. Wroclawski、「フレームワークDiffservのネットワークの上に統合サービスオペレーション」、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]ブレイク、S.、カールソン、M.、デイヴィス、D.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（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.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、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.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、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.
この文書を検討するためのフレッド・ベイカーとキャロルIturraldeに感謝します。入力のためのラメシュPabbati、ティム・ムーア、ブルースデイビーとカム・リーに感謝します。
Yoram Bernet Microsoft One Microsoft Way, Redmond, WA 98052
よらｍ べｒねｔ みｃろそｆｔ おね みｃろそｆｔ わｙ、 れｄもんｄ、 わ ９８０５２
Phone: (425) 936-9568 EMail: yoramb@microsoft.com
電話：（425）936-9568 Eメール：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の要求に適用されます。この最小限の機能は、単一のDSCPがDCLASSオブジェクトに含まれている前提としていたが、容易に複数のDSCPをサポートするように拡張されてもよいです。
It must be possible to configure two tables in the router. These are described below.
ルータの2つのテーブルを設定することが可能でなければなりません。これらは、以下に記載されています。
A.1 Service Type to DSCP Mapping
DSCPへのマッピングA.1サービスタイプ
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:
一つのテーブルは、差分-SERVネットワークに対応するサービスを取得するために使用することができるDSCPへRSVP要求に指定のIntServのサービスタイプからのマッピングを提供します。このテーブルは、マッピングが利用可能であるそれぞれのIntServサービスタイプのための列を含んでいます。各行は、次の形式を有します。
Intserv service type : DSCP
イントサーブサービスタイプ：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つ。 （ベストエフォート型のサービスでは、通常、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.
このテーブルには、ネットワーク管理者が静的にルータが認めRSVP要求のDCLASSオブジェクトに戻りますDSCPを設定することができます。一般的に、より洗練された、おそらくより動的なメカニズムはDCLASSオブジェクトに返されるDSCPを決定するために使用することができます。また、一部のサービスのための本当のマッピングは、DSCPは、特定のサービス要求の呼び出しパラメータに応じて、複数のDSCPを使用する可能性が高いです。この場合には、これらのメカニズムは、ここで説明した静的テーブルベースのマッピングを上書きまたは置換することができます。
A.2 Quantitative Resource Availability
A.2定量的リソースの可用性
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:
標準イントサーブ要求は、本質的に定量的です。彼らは、入場料が要求されているトラフィックによって必要なリソースを記述するトークン・バケット・パラメータを含みます。 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によって指定されたサービスクラスのトラフィックに対応するために差分-SERVネットワークで利用可能な総リソースを表すトークン・バケット・パラメータを指定します。
Full Copyright Statement
完全な著作権声明
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機能のための基金は現在、インターネット協会によって提供されます。