[要約] RFC 2597は、Assured Forwarding PHBグループに関するガイドラインであり、ネットワークトラフィックの優先度と転送保証を定義しています。その目的は、ネットワークの信頼性とパフォーマンスを向上させるために、トラフィックの優先順位付けと制御を提供することです。
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
PHBグループの転送を保証します
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、Assured Forwarding（AF）と呼ばれる一般的な使用差別化サービス（DS）[Blake] [Blake]（PHB）グループを定義します。AF PHBグループは、独立して転送された4つのAFクラスでIPパケットの配信を提供します。各AFクラス内で、IPパケットに3つの異なるレベルのドロップ優先順位のいずれかを割り当てることができます。DSノードは、同じAFクラスに属している場合、同じマイクロフローの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].
Assured Forwarding（AF）PHB Groupは、プロバイダーDSドメインが顧客DSドメインから受け取ったIPパケットのさまざまな転送保証を提供する手段です。4つのAFクラスが定義されており、各AFクラスが各DSノードにあるフォワードリソース（バッファスペースと帯域幅）が割り当てられています。AF PHBグループが提供するサービスを使用したいIPパケットは、顧客またはプロバイダーDSドメインによって割り当てられ、顧客が購読しているサービスに従ってこれらのAFクラスの1つ以上に割り当てられます。この能力とそれを使用するいくつかの方法に関するさらなる背景は、[クラーク]にあるかもしれません。
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パケットは（顧客またはプロバイダーDSドメインによって再び）マークされ、3つのドロップ優先値の値のいずれかが付いています。混雑の場合、パケットの低下の優先順位は、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パケットの転送保証のレベルは、（1）パケットが属するAFクラスに割り当てられている転送リソースの量に依存します。（2）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つの最低ドロップ優先値のパケットによって過負荷にならないことを確認します。、その後、AFクラスは、購読されたプロファイル内にあるパケットの高いレベルの転送保証を提供し（つまり、低下の優先順位値が低い）、過剰なトラフィックに対して最大2つの低レベルの転送保証を提供できます。
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準拠と見なされるためにこのPHBグループを実装するためにDSに準拠したノードを実装する必要はありませんが、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[Bradner]に記載されているように解釈される。
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.
Assured Forwarding（AF）PHB Groupは、N独立したAFクラスでのIPパケットの転送を提供します。各AFクラス内で、IPパケットには、Mが異なるレベルのドロップ優先順位の1つが割り当てられます。AFクラスIに属し、優先順位を落とすIPパケットは、AF CodePoint AFIJでマークされています。1<= i <= nおよび1 <= J <= M.各クラスの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クラスすべてを実装する必要があります。あるAFクラスのパケットは、別のAFクラスのパケットから独立して転送する必要があります。つまり、DSノードは2つ以上の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ノードは、実装された各クラスに構成可能な最小の転送リソース（バッファースペースと帯域幅）を割り当てる必要があります。各クラスは、小規模および大規模な時間スケールの両方で構成されたサービスレート（帯域幅）を達成するために、方法で修理する必要があります。
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.
AFクラス内で、DSノードは、P <Qの場合よりも低い優先順位値qを含む場合よりも、ドロップ優先値pを含む場合、より小さな確率でIPパケットを転送してはなりません。この要件は、既にQUEREDパケットを削除して破棄する必要なく、満たすことができることに注意してください。
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つの異なるレベルの損失確率のみを実装することは合理的かもしれません。一部のネットワークではこれで十分かもしれませんが、輻輳が一般的な発生であるDSドメインでは、3つの異なるレベルの損失確率をサポートする必要があります。
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つの異なるレベルの損失確率のみを実装する場合、CodePoint AFX1は低い損失確率を生成する必要があり、CodePoints 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.
DSノードは、ドロップの優先順位に関係なく、同じAFクラスに属している場合、同じマイクロフローの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の実装は、各クラス内の長期的な輻輳を最小限に抑え、バーストに起因する短期的な渋滞を可能にする必要があります。これには、アクティブなキュー管理アルゴリズムが必要です。このようなアルゴリズムの例は、ランダムな早期ドロップ（赤）[フロイド]です。このメモは、特定のアルゴリズムの使用を指定するものではありませんが、いくつかのプロパティが保持される必要があります。
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つの方法（赤）では、2つの（構成可能な）滑らかな輻輳レベルのしきい値を使用します。滑らかな輻輳レベルが最初のしきい値を下回る場合、関連する優先順位のパケットは破棄されません。平滑化された輻輳レベルが1番目のしきい値と2番目のしきい値の間にある場合、パケットは、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 CodePointマッピングは、[ニコル]で推奨されるローカル使用スペースやクラスセレクターのコードポイントを妨害しません。したがって、これらのクラスセレクターコードポイントによって選択されたPHBは、AF PHBグループと共存し、それらのために定義された転送行動と関係を保持する場合があります。特に、「000000」のデフォルトのPHBコードポイントは、従来のベストエフェクショントラフィックに使用されていない場合があります。同様に、CodePoints「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によって暗示される全体的な動作を取得するために使用できます。この場合、DSドメイン内では、AFコードポイントのエイリアスとしてクラスセレクターのコードポイントの一部またはすべてを使用することが適切かもしれません。
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].
このドキュメントには、[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つのサービスクラスで構成されています。これらの3つのクラスにパケットが割り当てられているため、Goldクラスのパケットは、シルバークラスに割り当てられたパケットよりも軽い負荷を軽減します（したがって、タイムリーな転送の可能性が高くなります）。シルバークラスとブロンズクラスの間にも同じ種類の関係が存在します。必要に応じて、各クラス内のパケットは、低、中程度、または高いドロップの優先順位を与えることにより、さらに分離できます。
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.
パケットのドロップ優先レベルを割り当てる別の方法は、オリンピックサービスクラスのユーザートラフィックを特定のピークレートに制限し、各レベルのドロップ優先順位に均等に分配することです。これにより、帯域幅の高い帯域幅サービスが得られます。これは、帯域幅のマイクロフローが高い顧客が低帯域幅マイクロフローを持つ顧客よりも高いピークレートにサブスクライブしているという仮定の下で、混雑の時期に利用可能な容量を等しく評価します。
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.
[Blake] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[Bradner] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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月、pp。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月、pp。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.
[Nichols] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
Authors' Addresses
著者のアドレス
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vantaa, Finland
Juha Heinanen Telia Finland Myyrmaentie 2 01600 Vanta、フィンランド
EMail: jh@telia.fi
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111
フレッドベイカーシスコシステム519ラドドライブサンタバーバラ、カリフォルニア93111
EMail: fred@cisco.com
Walter Weiss Lucent Technologies 300 Baker Avenue, Suite 100, Concord, MA 01742-2168
Walter Weiss Lucent Technologies 300 Baker Avenue、Suite 100、Concord、MA 01742-2168
EMail: wweiss@lucent.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピューターサイエンスのためのJohn Wroclawski MIT Laboratory 545 Technology Sq。ケンブリッジ、マサチューセッツ州02139
EMail: jtw@lcs.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。