RFC2996 日本語訳
2996 Format of the RSVP DCLASS Object. Y. Bernet. November 2000. (Format: TXT=18929 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Bernet Request for Comments: 2996 Microsoft Category: Standards Track November 2000
Bernetがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2996年のマイクロソフトカテゴリ: 標準化過程2000年11月
Format of the RSVP DCLASS Object
RSVP DCLASSオブジェクトの形式
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
要約
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)シグナリングは、差別化されたサービス(デフ-servかDS)ネットワークでService(QoS)サービスのQualityを要求して、アプリケーショントラフィックのQoSの管理可能性を高めるのに使用されるかもしれません。 運ぶことができるのが役に立つDSネットワークがあるRSVPを使用するときには、RSVPメッセージオブジェクトでDifferentiated Services Code Points(DSCPs)を運んでください。 この1つの例は送付者において、または、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メッセージの中でDSCPsを表して、運ぶのに使用されます。 このドキュメントは、DCLASSオブジェクトの形式を指定して、簡潔に使用について議論します。
1. Introduction
1. 序論
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
このセクションはDifferentiated Serviceネットワーク[DS]の中で入場コントロールを実行して、QoS方針を適用するのにRSVP[RSVP]シグナリングとDCLASSオブジェクトを使用する整備士について説明します。 それは標準のRSVP送付者と受信機を仮定します、そして、受信機送付者と少なくとも1つのRSVPの意識しているネットワーク要素の間の経路のどこかのデフ-servネットワークはデフ-servネットワークであります。 このネットワーク要素は、方針実施ポイントであるかもしれない(PEP)[RAP]かネットワークの入場コントロールエージェントとして単に務めるかもしれません、リソースの有用性に基づく資源要求を認めるか、または否定して。 どちらの場合ではも、このネットワーク要素は資源要求を受け入れて、DSネットワークの外から到着するRSVPメッセージと対話します。
Bernet Standards Track [Page 1] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[1ページ]。
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意識している送付者、受信機、DSネットワークの入場コントロールを運んで、および資源配分決定から、より高い平らなRSVPまで。 ネットワーク要素は、通常ルータであり、このドキュメントの目的のためにしたがって、である考えられるでしょう。 このモデルは[INTDIFF]で完全に説明されます。
1.1 Use of the DCLASS Object to Carry Upstream Packet Marking Information
1.1 情報をマークする上流のパケットを運ぶDCLASSオブジェクトの使用
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ネットワークのPEPsである1つ以上のネットワーク要素、そして/または、入場コントロールエージェントを横断します。 これらの要素は、受信機に向かって適切な状態をインストールして、PATHメッセージを転送します。入場コントロールが川下にデフ-servネットワークでうまくいくと、RESVメッセージは受信機の方角から到着するでしょう。このメッセージが有効にされたRSVPであるPEPs、そして/または、入場コントロールエージェントに到着するとき、それぞれのこれらのネットワーク要素はデフ-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ネットワークのイングレスポイントの前にどこでも起こることができました。 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要求のためのパケットが上流であるとマークされるつもりであるなら、RSVPの意識しているネットワーク要素からポイントをマークする上流まで使用へのDSCP(s)の情報を伝えなければなりません。 この情報はDCLASSオブジェクトで伝えられます。 これをするために、ネットワーク要素は振舞い集合に対応する1DSCPsを含むDCLASSオブジェクトを加えます、RESVメッセージに。 そして、上流へRSVP送付者に向かってRESVメッセージを送ります。
If the network element determines that the RSVP request is not admissible to the diff-serv network, it sends a RESV error message
ネットワーク要素が、RSVP要求がデフ-servネットワークに容認できないことを決定するなら、それはRESVエラーメッセージを送ります。
Bernet Standards Track [Page 2] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[2ページ]。
towards the receiver. No DCLASS is required.
受信機に向かって. DCLASSは全く必要ではありません。
1.1 Additional Uses of the DCLASS Object
1.1 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.
この例では、私たちは、DSネットワーク出口ルータ(または、関連するPolicy Decision Point)でRSVP PATH、RESVメッセージ、および他の必要事項を観測することによってRSVPによって調停された交通の流れのための適切な行動集合に関する決定をすると思います。 しかしながら、ネットワークのイングレスで実際のパケットマークをしなければなりません。 出口とイングレスルータの間まで必要なマーク情報を運ぶのにDCLASSオブジェクトを使用できます。
2. Format of the DCLASS Object
2. 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 | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 | 1 | 2 | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ(>=8)| C-ヌム(225)| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| 最初のDSCP| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| 第2DSCP| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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オブジェクトのためのClassヌムは225です)。 長さの分野はバイトで表現される総オブジェクトの長さを示します。 1つ以上の32ビットの単語がオブジェクトヘッダーのあとに続いています、最も重要でないバイトの6高位のビットにそれぞれDSCPを含んでいて。 オブジェクトヘッダーの長さの分野はオブジェクトにDSCPsを含む数を示します。 明確に、オブジェクトが寄贈する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
ネットワークは、ホストが振舞い集合の中でサブ流れを差別するのを可能にするためにDCLASSオブジェクトで複数のDSCPsを返すかもしれません。 例えば、AF PHBグループ[AF]の場合では、ネットワークはAF PHBグループのClass1の中の増加するレベルの低下先行に対応するDSCPs001010、001100、および001110を返すかもしれません。 このドキュメントが返されたDSCPsの注文の意味に関する声明を全く出さないことに注意してください。 DSCPセットのさらなる解釈は特定のサービスに依存しています。
Bernet Standards Track [Page 3] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[3ページ]。
requested by the host and is beyond the scope of this document.
ホストを要求して、このドキュメントの範囲を超えています。
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オブジェクトのためのClass-ヌムが無視されるべきである未知のクラスオブジェクトのスペースから選ばれていて、それを認識しないノードによって進められることに注意してください。 これは、最大限度の後方の互換性を保証するためのものです。
3. Admission Control Functionality
3. 入場コントロールの機能性
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.
ブラックボックス見解から、入場コントロールと方針の機能性は要求を受け入れるか、または拒絶するかという決定と対応するトラフィックに使用されるべきであるDSCPsの決断に達します。 入場コントロールの特定の細部はこのドキュメントの範囲を超えています。 一般に、入場コントロール決定はリソースの有用性と、そして、デフ-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.
構成可能なリソースのための簡単なメカニズムのためのAppendix Aが入場コントロールを基礎づけたのを確実にしてください。
4. Security Considerations
4. セキュリティ問題
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を要求するのに使用できる情報を伝えます、交通の流れが適切であるというよりもオブジェクトの変更でQoSのさらに高いか下側のレベルを得ることができるかもしれないくらい不適当です。 特に、DSネットワークイングレスノードと上流のマーカーの間に挿入された第三者によるDCLASSオブジェクトの変更はサービス攻撃の可能な否定を構成します。 完全にデータフローを断ち切るというわけではなくて容認できないほど低いレベルに容認されたQoSを引き下げるのが可能であるので、この攻撃は微妙です、攻撃を検出するのをより困難にして。
The possibility of raising the received level of QoS by inappropriate
不適当でQoSの容認されたレベルを上げる可能性
Bernet Standards Track [Page 4] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[4ページ]。
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オブジェクトの変更がそれほど重要でない、それ、システムで既に検出しなければならないより大きいクラスの攻撃のサブクラス。 ホストが単に「良い」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ネットワークの社内業務の情報を明らかにするかもしれません。
5. References
5. 参照
[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ネットワークの上の統合サービス操作のためのフレームワーク」、RFC2998、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.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、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の機能的な仕様」、RFC2205、1997年9月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[叩きます] YavatkarとR.とPendarakisとD.とR.ゲラン、「方針のベースの入場コントロールのためのフレームワーク」、RFC2753、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は分類する」RFC2597、1999年6月。
Bernet Standards Track [Page 5] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[5ページ]。
6. Acknowledgments
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、ティム・ムーア、ブルース・デイビー、およびカム・リーをありがとうございます。
7. Author's Address
7. 作者のアドレス
Yoram Bernet Microsoft One Microsoft Way, Redmond, WA 98052
レッドモンド、ワシントン ヨラムBernetマイクロソフト1マイクロソフト道、98052
Phone: (425) 936-9568 EMail: yoramb@microsoft.com
以下に電話をしてください。 (425) 936-9568 メールしてください: yoramb@microsoft.com
Bernet Standards Track [Page 6] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[6ページ]。
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オブジェクトに含まれていますが、複数のDSCPsをサポートするために容易に広げてもよいと仮定します。
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:
1個のテーブルがRSVP要求で指定されたintservサービスタイプからデフ-servネットワークで対応するサービスを得るのに使用できるDSCPまでマッピングを提供します。 このテーブルはマッピングが利用可能であるそれぞれの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つの行を通常含んでいるでしょう。 Guaranteedサービスのためのもの、Controlled Loadサービスのためのもの、およびBest取り組みサービスのためのもの。 (ベストエフォート型サービスは、000000をDSCPに通常写像しますが、くつがえされるかもしれません。) まだ未定義であるとしてのサービスタイプのために行を加えるのは可能であるべきです。
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を構成できます。 一般に、より精巧でありそうなよりダイナミックなメカニズムは、DSCPがDCLASSオブジェクトで返されることを決定するのに使用されるかもしれません。 また、いくつかのサービスのための本当のマッピングは1DSCPを使用しそうでしょう、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
標準のintserv要求は現実に量的です。 彼らは入場が要求されているトラフィックによって必要とされたリソースについて説明するトークンバケツパラメタを含んでいます。 第2テーブルは量的に静的に構成するネットワーク管理者を可能にします。
Bernet Standards Track [Page 7] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[7ページ]。
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:
認めるときルータによって使用されるべきパラメタは量的なサービスのリクエストのための決定を制御します。 このテーブルの各行で、以下は形成されます:
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.
最初のコラムは量的な入場コントロールが適用されているそれらのDSCPsを指定します。 第2コラムはDSCPによって指定されたサービスのクラスでトラフィックを収容するためにデフ-servネットワークで利用可能な総リソースを表すトークンバケツパラメタを指定します。
Bernet Standards Track [Page 8] RFC 2996 Format of the RSVP DCLASS Object November 2000
Bernet規格はオブジェクト2000年11月にRSVP DCLASSのRFC2996形式を追跡します[8ページ]。
Full Copyright Statement
完全な著作権宣言文
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 Standards Track [Page 9]
Bernet標準化過程[9ページ]
一覧
スポンサーリンク