Network Working Group J. Heinanen
Request for Comments: 2597 Telia Finland
Category: Standards Track F. Baker
Cisco Systems
W. Weiss
Lucent Technologies
J. Wroclawski
MIT LCS
June 1999
Assured Forwarding PHB Group
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class.
この文書は、保証転送（AF）と呼ばれる一般的な使用差別化サービス（DS）[ブレイク]ペイ・パー・ホップ行動（PHB）グループを定義します。 AF PHBグループは、4つの独立して転送されたAFクラスにおけるIPパケットの配信を提供します。各AFクラス内で、IPパケットは廃棄優先順位の3つの異なるレベルのいずれかを割り当てることができます。彼らは同じAFのクラスに属している場合DSノードは同じマイクロフローのIPパケットの順序を変更しません。
There is a demand to provide assured forwarding of IP packets over the Internet. In a typical application, a company uses the Internet to interconnect its geographically distributed sites and wants an assurance that IP packets within this intranet are forwarded with high probability as long as the aggregate traffic from each site does not exceed the subscribed information rate (profile). It is desirable that a site may exceed the subscribed profile with the understanding that the excess traffic is not delivered with as high probability as the traffic that is within the profile. It is also important that the network does not reorder packets that belong to the same microflow, as defined in [Nichols], no matter if they are in or out of the profile.
インターネット上でのIPパケットの確実な転送を提供するために、需要があります。典型的なアプリケーションでは、同社は、地理的に分散したサイトを相互接続するためにインターネットを使用して、このイントラネット内のIPパケットが加入情報速度を超えていない各サイトからの集約トラフィック限り高い確率で転送されていることを保証（プロファイル）を望んでいます。サイトが過剰なトラフィックがプロファイル内にあるトラフィックのように高い確率で配信されていないことを理解した上で加入したプロファイルを超える可能性があることが望ましいです。 [ニコルズ]で定義されている、彼らは中またはプロファイルの外にある場合に、ネットワークは、関係なく、同じマイクロフローに属するパケットの順序を変更しないことも重要です。
Assured Forwarding (AF) PHB group is a means for a provider DS domain to offer different levels of forwarding assurances for IP packets received from a customer DS domain. Four AF classes are defined, where each AF class is in each DS node allocated a certain amount of forwarding resources (buffer space and bandwidth). IP packets that wish to use the services provided by the AF PHB group are assigned by the customer or the provider DS domain into one or more of these AF classes according to the services that the customer has subscribed to. Further background about this capability and some ways to use it may be found in [Clark].
保証転送（AF）PHBグループは、顧客のDSドメインから受信したIPパケットの転送アシュアランスの様々なレベルを提供するプロバイダDSドメインの手段です。各AFクラスは、転送リソース（バッファ空間および帯域幅）の一定量を割り当てられた各DSノードである四つのAFクラスは、定義されています。 AFのPHBグループが提供するサービスを利用したいIPパケットは、顧客が加入しているサービスに応じて、これらのAFクラスの一つ以上に顧客またはプロバイダDSドメインによって割り当てられます。この能力とそれを使用するいくつかの方法についての更なる背景には、[クラーク]で見つけられるかもしれません。
Within each AF class IP packets are marked (again by the customer or the provider DS domain) with one of three possible drop precedence values. In case of congestion, the drop precedence of a packet determines the relative importance of the packet within the AF class. A congested DS node tries to protect packets with a lower drop precedence value from being lost by preferably discarding packets with a higher drop precedence value.
各AFクラスのIPパケット内の3つの可能なドロップ優先順位の値のいずれかで（再び顧客またはプロバイダDSドメインによって）マークされています。輻輳の場合に、パケットのドロップ優先順位はAFクラス内のパケットの相対的重要度を決定します。輻輳DSノードは、好ましくは、より高い廃棄優先順位値を持つパケットを廃棄することによって失われるから低いドロップ優先順位値を持つパケットを保護しようとします。
In a DS node, the level of forwarding assurance of an IP packet thus depends on (1) how much forwarding resources has been allocated to the AF class that the packet belongs to, (2) what is the current load of the AF class, and, in case of congestion within the class, (3) what is the drop precedence of the packet.
DSノードにおいて、IPパケットの保証を転送するのレベルは、したがって、（2）AFクラスの電流負荷は何である、（1）どのくらいの転送リソースは、パケットが属するAFクラスに割り当てられているに依存しますそして、クラス内の輻輳の場合に、（3）パケットのドロップ優先ものです。
For example, if traffic conditioning actions at the ingress of the provider DS domain make sure that an AF class in the DS nodes is only moderately loaded by packets with the lowest drop precedence value and is not overloaded by packets with the two lowest drop precedence values, then the AF class can offer a high level of forwarding assurance for packets that are within the subscribed profile (i.e., marked with the lowest drop precedence value) and offer up to two lower levels of forwarding assurance for the excess traffic.
たとえば、プロバイダDSドメインの入口でトラフィック調整アクションは、DSノードにおけるAFクラスのみ適度に最低の廃棄優先順位値を持つパケットによってロードされ、2つの最低ドロップprecedence値をパケットによって過負荷になっていないことを確認している場合、その後、AFクラスが加入プロファイル内にあるパケットの転送保証の高いレベルを提供することができ（すなわち、最も低いドロップ優先順位値でマークされた）および過剰なトラフィックの転送保証二低いレベルまで提供しています。
This document describes the AF PHB group. An otherwise DS-compliant node is not required to implement this PHB group in order to be considered DS-compliant, but when a DS-compliant node is said to implement an AF PHB group, it must conform to the specification in this document.
この文書では、AF PHBグループを説明します。そうでなければDS準拠ノードはDS準拠と見なされるために、このPHBグループを実装するが、DS対応ノードがAFのPHBグループを実装するために言われている場合、それはこの文書に記載されている仕様に準拠しなければならない必要はありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bradner].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【ブラドナー]に記載されているように解釈されます。
Assured Forwarding (AF) PHB group provides forwarding of IP packets in N independent AF classes. Within each AF class, an IP packet is assigned one of M different levels of drop precedence. An IP packet that belongs to an AF class i and has drop precedence j is marked with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4) with three levels of drop precedence in each class (M=3) are defined for general use. More AF classes or levels of drop precedence MAY be defined for local use.
保証転送（AF）PHBグループNの独立したAFクラス内のIPパケットの転送を提供します。各AFクラス内で、IPパケットは廃棄優先順位のM個の異なるレベルのいずれかが割り当てられます。 AFクラスiに属する優先順位jはAFコードポイントAFij、でマークされているドロップ有するIPパケット1 <= iが= N 1 <= jの<= M.現在、4つのクラス（N = 4）とを<各クラス内の廃棄優先順位3つのレベル（M = 3）は、一般的な使用のために定義されています。その他のAFクラスまたは廃棄優先順位のレベルは、ローカルな使用のために定義されるかもしれません。
A DS node SHOULD implement all four general use AF classes. Packets in one AF class MUST be forwarded independently from packets in another AF class, i.e., a DS node MUST NOT aggregate two or more AF classes together.
DSノードは、すべての4つの一般的な使用のAFクラスを実装する必要があります。 1つのAFクラスのパケット、すなわち、DSノードが2つの以上のAFクラスを集約してはいけません、他のAFクラスのパケットから独立して転送されなければなりません。
A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) to each implemented AF class. Each class SHOULD be serviced in a manner to achieve the configured service rate (bandwidth) over both small and large time scales.
DSノードは、各実施AFクラスに転送リソース（バッファ空間および帯域幅）の設定可能な最小量を割り当てなければなりません。各クラスは、小規模および大規模の両方の時間スケール上に設定されたサービス速度（帯域幅）を達成するようにサービスされるべきです。
An AF class MAY also be configurable to receive more forwarding resources than the minimum when excess resources are available either from other AF classes or from other PHB groups. This memo does not specify how the excess resources should be allocated, but implementations MUST specify what algorithms are actually supported and how they can be parameterized.
AFクラスはまた、過剰なリソースは、他のAFクラスから、または他のPHBグループのいずれかから入手可能である最小より転送リソースを受信するために構成可能です。このメモは、過剰なリソースが割り当てられる方法を指定しませんが、実装は、実際にサポートされており、それらがどのようにパラメータ化することができるかのアルゴリズムを指定しなければなりません。
Within an AF class, a DS node MUST NOT forward an IP packet with smaller probability if it contains a drop precedence value p than if it contains a drop precedence value q when p < q. Note that this requirement can be fulfilled without needing to dequeue and discard already-queued packets.
それは廃棄優先順位値qが含まれている場合よりも、廃棄優先順位値Pが含まれている場合、AFクラス内、DSノードは小さい確率でIPパケットを転送しない必要がある場合、P <Q。この要件は既にキューに入れられたパケットをデキューし、破棄することなく、満たすことができることに注意してください。
Within each AF class, a DS node MUST accept all three drop precedence codepoints and they MUST yield at least two different levels of loss probability. In some networks, particularly in enterprise networks, where transient congestion is a rare and brief occurrence, it may be reasonable for a DS node to implement only two different levels of loss probability per AF class. While this may suffice for some networks, three different levels of loss probability SHOULD be supported in DS domains where congestion is a common occurrence.
各AFクラス内、DSノードは、すべての3つのドロップ優先コードポイントを受け入れなければなりません、そして、彼らは、損失確率の少なくとも2つの異なるレベルを得なければなりません。 DSノードはAFクラスごとの損失確率の唯一の2つの異なるレベルを実装するためのいくつかのネットワークでは、特に過渡輻輳が稀で短時間発生である企業ネットワークにおいて、それは合理的であってもよいです。これはいくつかのネットワークには十分かもしれないが、損失確率の3つの異なるレベルは、輻輳が共通発生であるDSドメインでサポートされるべきです。
If a DS node only implements two different levels of loss probability for an AF class x, the codepoint AFx1 MUST yield the lower loss probability and the codepoints AFx2 and AFx3 MUST yield the higher loss probability.
DSノードのみAFクラスxの損失確率の2つの異なるレベルを実装する場合、コードポイントAFx1は、低損失の確率を得なければなりません、そして、コードポイントはAFx2とAFx3はより高い損失確率を得なければなりません。
A DS node MUST NOT reorder AF packets of the same microflow when they belong to the same AF class regardless of their drop precedence. There are no quantifiable timing requirements (delay or delay variation) associated with the forwarding of AF packets.
彼らは関係なく、廃棄優先順位の同じAFのクラスに属している場合、DSノードは同じマイクロフローのAFパケットの順序を変更してはなりません。 AFパケットの転送に関連する定量化タイミング要件（遅延または遅延変動）がありません。
The relationship between AF classes and other PHBs is described in Section 7 of this memo.
AFクラスと他のPHBとの間の関係は、このメモのセクション7に記載されています。
The AF PHB group MAY be used to implement both end-to-end and domain edge-to-domain edge services.
AFのPHBグループは、両方のエンド・ツー・エンドのドメインエッジツーエッジドメインサービスを実装するために使用され得ます。
A DS domain MAY at the edge of a domain control the amount of AF traffic that enters or exits the domain at various levels of drop precedence. Such traffic conditioning actions MAY include traffic shaping, discarding of packets, increasing or decreasing the drop precedence of packets, and reassigning of packets to other AF classes. However, the traffic conditioning actions MUST NOT cause reordering of packets of the same microflow.
DSドメインは、ドメインのエッジに入るか、ドロップ優先度の様々なレベルでの領域を出るAFトラフィックの量を制御することができます。そのようなトラフィック調整アクションは、トラフィックシェーピング、パケットの廃棄、パケットのドロップ優先度を増加または減少、および他のAFクラスへのパケットの再割り当てを含むかもしれません。しかし、トラフィック調整アクションは、同じマイクロフローのパケットの並べ替えを引き起こしてはなりません。
This section defines the queueing and discard behavior of the AF PHB group. Other aspects of the PHB group's behavior are defined in Section 2.
このセクションでは、AF PHBグループのキューイングおよび廃棄動作を定義します。 PHBグループの行動の他の態様は、第2節で定義されています。
An AF implementation MUST attempt to minimize long-term congestion within each class, while allowing short-term congestion resulting from bursts. This requires an active queue management algorithm. An example of such an algorithm is Random Early Drop (RED) [Floyd]. This memo does not specify the use of a particular algorithm, but does require that several properties hold.
バーストから生じる短期輻輳を可能にしながら、AFの実装では、各クラス内の長期の輻輳を最小限にしようとしなければなりません。これは、アクティブキュー管理アルゴリズムを必要とします。そのようなアルゴリズムの例は、ランダム早期ドロップ（RED）[フロイド]です。このメモは、特定のアルゴリズムの使用を指定しませんが、いくつかのプロパティを保持することを必要としません。
An AF implementation MUST detect and respond to long-term congestion within each class by dropping packets, while handling short-term congestion (packet bursts) by queueing packets. This implies the presence of a smoothing or filtering function that monitors the instantaneous congestion level and computes a smoothed congestion level. The dropping algorithm uses this smoothed congestion level to determine when packets should be discarded.
AFの実装では、パケットをキューイングすることにより、短期輻輳（パケットバーストを）処理中に、パケットをドロップすることによって検出し、各クラス内の長期輻輳に応答しなければなりません。これは、瞬間的な輻輳レベルを監視し、平滑輻輳レベルを算出する平滑化またはフィルタリング機能が存在することを意味しています。滴下アルゴリズムは、パケットが破棄されるべきかを決定するために、この平滑化輻輳レベルを使用しています。
The dropping algorithm MUST be insensitive to the short-term traffic characteristics of the microflows using an AF class. That is, flows with different short-term burst shapes but identical longer-term packet rates should have packets discarded with essentially equal probability. One way to achieve this is to use randomness within the dropping function.
滴下アルゴリズムは、AFクラスを使用して、マイクロフローの短期間のトラフィック特性に鈍感でなければなりません。すなわち、本質的に等しい確率で廃棄されたパケットを有していなければならない異なる短期バースト形状が同一で長期パケットレートで流れます。これを達成する1つの方法は、滴下関数内でランダム性を使用することです。
The dropping algorithm MUST treat all packets within a single class and precedence level identically. This implies that for any given smoothed congestion level, the discard rate of a particular microflow's packets within a single precedence level will be proportional to that flow's percentage of the total amount of traffic passing through that precedence level.
滴下アルゴリズムは、同一の単一のクラスと優先順位レベル内のすべてのパケットを扱わなければなりません。これは、任意の所与の平滑輻輳レベルのために、単一の優先レベル内の特定のマイクロフローのパケットの廃棄率は、その優先レベルを通過するトラフィックの総量のフローの比率に比例することを意味します。
The congestion indication feedback to the end nodes, and thus the level of packet discard at each drop precedence in relation to congestion, MUST be gradual rather than abrupt, to allow the overall system to reach a stable operating point. One way to do this (RED) uses two (configurable) smoothed congestion level thresholds. When the smoothed congestion level is below the first threshold, no packets of the relevant precedence are discarded. When the smoothed congestion level is between the first and the second threshold, packets are discarded with linearly increasing probability, ranging from zero to a configurable value reached just prior to the second threshold. When the smoothed congestion level is above the second threshold, packets of the relevant precedence are discarded with 100% probability.
エンドノードに輻輳表示フィードバック、および輻輳に対する各廃棄優先順位のパケット廃棄のかくしてレベルは、システム全体が安定した動作点に到達できるように、むしろ急激より緩やかでなければなりません。これを行う1つの方法（RED）は、二つの（設定）平滑化輻輳レベルのしきい値を使用しています。平滑化された輻輳レベルが第1閾値未満である場合、関連する優先順位のないパケットは廃棄されていません。平滑化された輻輳レベルは、第1および第2の閾値の間にある場合、パケットはゼロから直前第二の閾値に達した設定値に至るまで、直線的に増加確率で廃棄されます。平滑化された輻輳レベルが第2の閾値以上である場合、関連する優先順位のパケットは、100％の確率で廃棄されます。
To allow the AF PHB to be used in many different operating environments, the dropping algorithm control parameters MUST be independently configurable for each packet drop precedence and for each AF class.
AF PHBは、多くの異なる動作環境で使用できるように、滴下アルゴリズム制御パラメータは、各パケットの廃棄優先順位と各AFクラスに対する独立設定可能でなければなりません。
Within the limits above, this specification allows for a range of packet discard behaviors. Inconsistent discard behaviors lead to inconsistent end-to-end service semantics and limit the range of possible uses of the AF PHB in a multi-vendor environment. As experience is gained, future versions of this document may more tightly define specific aspects of the desirable behavior.
上記限度内、本明細書ではパケット廃棄行動の範囲を可能にします。一貫性のない廃棄行動が一貫性のないエンドツーエンドのサービスのセマンティクスにつながり、マルチベンダー環境でのAF PHBの可能な用途の範囲を制限します。経験が得られるように、このドキュメントの将来のバージョンでは、より緊密に望ましい行動の特定の側面を定義することもできます。
When AF packets are tunneled, the PHB of the tunneling packet MUST NOT reduce the forwarding assurance of the tunneled AF packet nor cause reordering of AF packets belonging to the same microflow.
AFパケットがトンネリングされている場合、トンネリングパケットのPHBは、トンネリングされたAFパケットの転送保証を減らしたり、同じマイクロフローに属するAFパケットの並べ替えを引き起こしてはなりません。
Recommended codepoints for the four general use AF classes are given below. These codepoints do not overlap with any other general use PHB groups.
4つの一般的な使用のAFクラスの推奨コードポイントは以下の通りです。これらのコードポイントは、他の一般的な使用のPHBグループと重なりません。
The RECOMMENDED values of the AF codepoints are as follows: AF11 = ' 001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = ' 010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = ' 011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. The table below summarizes the recommended AF codepoint values.
次のようにAFコードポイントの推奨値は次のとおりAF11 = '001010'、AF12 = '001100'、AF13 = '001110'、AF21 = '010010'、AF22 = '010100'、AF23 = '010110'、AF31 = ' 011010' 、AF32 = '011100'、AF33 = '011110'、AF41 = '100010'、AF42 = '100100'、およびAF43 = '100110'。下の表は、推奨AFコードポイント値をまとめたもの。
Class 1 Class 2 Class 3 Class 4
+----------+----------+----------+----------+
Low Drop Prec | 001010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 001100 | 010100 | 011100 | 100100 |
High Drop Prec | 001110 | 010110 | 011110 | 100110 |
+----------+----------+----------+----------+
The AF codepoint mappings recommended above do not interfere with the local use spaces nor the Class Selector codepoints recommended in [Nichols]. The PHBs selected by those Class Selector codepoints may thus coexist with the AF PHB group and retain the forwarding behavior and relationships that was defined for them. In particular, the Default PHB codepoint of '000000' may remain to be used for conventional best effort traffic. Similarly, the codepoints '11x000' may remain to be used for network control traffic.
上記の推奨AFコードポイントのマッピングは、ローカルでの使用スペースも[ニコルズ]の推奨クラスセレクタコードポイントに干渉しません。これらのクラスセレクタコードポイントによって選択されたのPHBは、このようにAFのPHBグループと共存し、それらのために定義された転送動作との関係を保持することができます。具体的には、「000000」のデフォルトPHBコードポイントは、従来のベストエフォートトラフィックのために使用されずに残っていることがあります。同様に、コードポイント「11x000」は、ネットワーク制御トラフィックのために使用されないままでもよいです。
The AF PHB group, in conjunction with edge traffic conditioning actions that limit the amount of traffic in each AF class to a (generally different) percentage of the class's allocated resources, can be used to obtain the overall behavior implied by the Class Selector PHBs. In this case it may be appropriate within a DS domain to use some or all of the Class Selector codepoints as aliases of AF codepoints.
AFのPHBグループは、クラスの割り当てられたリソースの（一般的に異なる）百分率を各AFクラスのトラフィックの量を制限するエッジトラフィック調整アクションと一緒に、クラスセレクタのPHBによって暗示全体的な動作を得るために使用することができます。この場合、AFコードポイントのエイリアスとしてクラスセレクタコードポイントの一部またはすべてを使用するためにDSドメイン内に適切かもしれません。
In addition to the Class Selector PHBs, any other PHB groups may co-exist with the AF PHB group within the same DS domain. However, any AF PHB group implementation should document the following:
クラスセレクタのPHBに加えて、他のPHBグループは、同じDSドメイン内のAF PHB基と共存できます。しかし、いずれのAF PHBグループの実装は次のことを文書化する必要があります。
(a) Which, if any, other PHB groups may preempt the forwarding resources specifically allocated to each AF PHB class. This preemption MUST NOT happen in normal network operation, but may be appropriate in certain unusual situations - for example, the '11x000' codepoint may preempt AF forwarding resources, to give precedence to unexpectedly high levels of network control traffic when required.
（a）は、もしあれば、他のPHBグループは、具体的には、各AFのPHBクラスに割り当てられた転送リソースを先取りすることができます。このプリエンプションは、通常のネットワーク動作で発生してはいけませんが、特定の異常な状況では適切であるかもしれない - 例えば、「11x000」コードポイントは、必要なときにネットワーク制御トラヒックの予想外に高いレベルに優先順位を与えるために、AF転送リソースを先取りすることができます。
(b) How "excess" resources are allocated between the AF PHB group and other implemented PHB groups. For example, once the minimum allocations are given to each AF class, any remaining resources could be allocated evenly between the AF classes and the Default PHB. In an alternative example, any remaining resources could be allocated to forwarding excess AF traffic, with resources devoted to the Default PHB only when all AF demand is met.
（b）は、どのように「過剰」のリソースは、AF PHB基及び他の実施PHBグループ間で割り当てられます。最小の割り当てが各AFクラスに与えられた後、例えば、任意の残りのリソースは、AFクラスとデフォルトPHBの間で均等に割り当てることができました。別の例では、残りのリソースは、すべてのAF需要が満たされるだけデフォルトPHBに専念リソースと、過剰AFトラフィックを転送するように割り当てることができました。
This memo does not specify that any particular relationship hold between AF PHB groups and other implemented PHB groups; it requires only that whatever relationship is chosen be documented. Implementations MAY allow either or both of these relationships to be configurable. It is expected that this level of configuration flexibility will prove valuable to many network administrators.
このメモは、任意の特定の関係は、AFのPHBグループおよび他の実施PHBグループ間保持することを指定していません。それはどのような関係が文書化され選択されているのみであることが必要です。実装は、設定できるようにこれらの関係のいずれかまたは両方を可能にすることができます。構成の柔軟性のこのレベルは、多くのネットワーク管理者に貴重なことを証明することが期待されます。
In order to protect itself against denial of service attacks, a provider DS domain SHOULD limit the traffic entering the domain to the subscribed profiles. Also, in order to protect a link to a customer DS domain from denial of service attacks, the provider DS domain SHOULD allow the customer DS domain to specify how the resources of the link are allocated to AF packets. If a service offering requires that traffic marked with an AF codepoint be limited by such attributes as source or destination address, it is the responsibility of the ingress node in a network to verify validity of such attributes.
サービス拒否攻撃から自身を保護するために、プロバイダDSドメインは加入プロファイルにドメインを入力するトラフィックを制限する必要があります。また、サービス拒否攻撃から顧客のDSドメインへのリンクを保護するために、プロバイダDSドメインは、顧客のDSドメインはリンクのリソースがAFパケットに割り当てられている方法を指定できるようにする必要があります。サービスの提供は、AFでマークされたトラフィックは、送信元や送信先アドレスなどの属性によって制限されるコードポイントことを必要とする場合、それはそのような属性の妥当性を検証するために、ネットワークの入口ノードの責任です。
Other security considerations are covered in [Blake] and [Nichols].
その他のセキュリティの考慮事項は、[ブレイク]と[ニコルズ]で覆われています。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
This document allocates twelve codepoints, listed in section 6, in Pool 1 of the code space defined by [Nichols].
この文書では、[ニコルス]によって定義されたコード空間のプール1に、セクション6に記載されている12個のコードポイントを割り当てます。
Appendix: Example Services
付録：例サービス
The AF PHB group could be used to implement, for example, the so-called Olympic service, which consists of three service classes: bronze, silver, and gold. Packets are assigned to these three classes so that packets in the gold class experience lighter load (and thus have greater probability for timely forwarding) than packets assigned to the silver class. Same kind of relationship exists between the silver class and the bronze class. If desired, packets within each class may be further separated by giving them either low, medium, or high drop precedence.
AFのPHBグループを実装するために使用することができ、例えば、3つのサービスクラスで構成され、いわゆるオリンピックサービス、：ブロンズ、シルバー、ゴールドと。ゴールドクラスの経験軽い負荷でのパケットは、銀クラスに割り当てられたパケットよりも（したがって、タイムリーな転送のための大きな可能性を持っている）ように、パケットは、これらの三つのクラスに割り当てられています。関係の同じ種類は、銀クラスとブロンズクラスの間に存在します。所望であれば、各クラス内のパケットは、さらに、それらを低、中、または高廃棄優先順位のいずれかを与えることによって分離することができます。
The bronze, silver, and gold service classes could in the network be mapped to the AF classes 1, 2, and 3. Similarly, low, medium, and high drop precedence may be mapped to AF drop precedence levels 1, 2, or 3.
ブロンズ、銀、金サービスクラスは、ネットワーク内のAFクラス1、2にマッピングすることができ、同様に3、低、中、および高廃棄優先順位はAFドロップ優先レベル1、2、または3にマッピングされてもよいです。
The drop precedence level of a packet could be assigned, for example, by using a leaky bucket traffic policer, which has as its parameters a rate and a size, which is the sum of two burst values: a committed burst size and an excess burst size. A packet is assigned low drop precedence if the number of tokens in the bucket is greater than the excess burst size, medium drop precedence if the number of tokens in the bucket is greater than zero, but at most the excess burst size, and high drop precedence if the bucket is empty. It may also be necessary to set an upper limit to the amount of high drop precedence traffic from a customer DS domain in order to avoid the situation where an avalanche of undeliverable high drop precedence packets from one customer DS domain can deny service to possibly deliverable high drop precedence packets from other domains.
認定バーストサイズと超過バースト：パケットのドロップ優先レベルは、例えば、そのパラメータとして有するリーキーバケットトラフィックポリシング、レート二バースト値の合計サイズを使用することによって、割り当てることができサイズ。パケットは、バケット内のトークン数がゼロよりも大きい場合、バケット内のトークン数が超過バーストサイズ、媒体のドロップ優先順位よりも大きい場合、低ドロップ優先順位を割り当てられているが、ほとんどの超過バーストサイズ、及び高ドロップでバケットが空の場合は優先。また、1つの顧客のDSドメインから配信不能の高い廃棄優先順位パケットの雪崩が高い可能性が成果にサービスを拒否することができ事態を避けるために、顧客のDSドメインからの高い廃棄優先順位トラフィックの量に上限を設定する必要があるかもしれ他のドメインから優先パケットをドロップします。
Another way to assign the drop precedence level of a packet could be to limit the user traffic of an Olympic service class to a given peak rate and distribute it evenly across each level of drop precedence. This would yield a proportional bandwidth service, which equally apportions available capacity during times of congestion under the assumption that customers with high bandwidth microflows have subscribed to higher peak rates than customers with low bandwidth microflows.
パケットのドロップ優先レベルを割り当てるための別の方法は、所与のピークレートにオリンピックサービスクラスのユーザトラフィックを制限し、廃棄優先順位の各レベルに均等に分配することができました。これは、同じように高帯域幅のmicroflowsをお持ちのお客様は、低帯域幅のマイクロフローをお客様より高いピークレートに加入しているという仮定の下で輻輳時に利用可能な容量を配分する比例帯域幅のサービスを、もたらすであろう。
The AF PHB group could also be used to implement a loss and low latency service using an over provisioned AF class, if the maximum arrival rate to that class is known a priori in each DS node. Specification of the required admission control services, however, is beyond the scope of this document. If low loss is not an objective, a low latency service could be implemented without over provisioning by setting a low maximum limit to the buffer space available for an AF class.
AFのPHBグループは、そのクラスに最大到着率は、各DSノードに先験的に知られている場合、オーバープロビジョニングAFクラスを使用して損失と低遅延サービスを実装するために使用することができます。必要なアドミッション制御サービスの仕様は、しかし、このドキュメントの範囲を超えています。低損失が目的ではない場合、低レイテンシ・サービスはAFクラスで使用可能なバッファ空間に低い上限を設定することにより、プロビジョニングかけずに実現することができます。
References
リファレンス
[Blake] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[ブレイク]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[Bradner] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[ブラドナーの]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Clark] Clark, D. and Fang, W., Explicit Allocation of Best Effort Packet Delivery Service. IEEE/ACM Transactions on Networking, Volume 6, Number 4, August 1998, pp. 362-373.
[クラーク]クラーク、D.と牙、W.、ベストエフォートパケットデリバリサービスの明示的な配分。ネットワーク上のIEEE / ACM取引、6巻、ナンバー4、1998年8月、頁362から373まで。
[Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume 1, Number 4, August 1993, pp. 397-413.
[フロイド]フロイド、S.、およびヤコブソン、V.、輻輳回避のためのランダム早期検出ゲートウェイ。ネットワーク上のIEEE / ACM取引、第1巻、ナンバー4、1993年8月、頁397から413まで。
[Nichols] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[ニコルズ]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
Authors' Addresses
著者のアドレス
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vantaa, Finland
ユハわらテリアフィンランドMyyrmäentie2 01600ヴァンター、フィンランド
EMail: jh@telia.fi
メールアドレス：jh@telia.fi
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111
フレッドベイカーシスコシステムズ519ラドドライブサンタバーバラ、カリフォルニア州93111
EMail: fred@cisco.com
メールアドレス：fred@cisco.com
Walter Weiss Lucent Technologies 300 Baker Avenue, Suite 100, Concord, MA 01742-2168
ウォルター・ワイスルーセント・テクノロジーズ300ベーカー・アベニュー、スイート100、コンコード、マサチューセッツ州01742から2168
EMail: wweiss@lucent.com
メールアドレス：wweiss@lucent.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピュータサイエンス545平方技術のためのジョンWroclawski MIT研究所。ケンブリッジ、MA 02139
EMail: jtw@lcs.mit.edu
メールアドレス：jtw@lcs.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。