RFC2597 日本語訳

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

Heinanenがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2597年の冬胞子堆フィンランドカテゴリ: 標準化過程F.ベイカーシスコシステムズW.ワイスルーセントテクノロジーズJ.Wroclawski MIT LCS1999年6月

                      Assured Forwarding PHB Group

相対的優先転送PHBグループ

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 (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

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.

このドキュメントは一般的使用を定義します。Differentiated Services(DS)[ブレーク]はホップの振舞い単位で呼ばれたAssured Forwarding(AF)を分類します(PHB)。 AF PHBグループは4つの独自に進められたAFのクラスにおける、IPパケットの配送を提供します。 それぞれのAFのクラスの中では、低下先行の3つの異なったレベルの1つをIPパケットに割り当てることができます。 同じAFのクラスのものなら、DSノードは同じmicroflowのIPパケットをどんな追加注文にもしません。

1. Purpose and Overview

1. 目的と概要

   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

IPパケットの相対的優先転送をインターネットの上に提供するという要求があります。 主用途では、各サイトからの集合トラフィックが申し込まれた情報レート(プロフィール)を超えていない限り、会社は、地理的に分配されたサイトとインタコネクトするのにインターネットを使用して、高い確率と共にこのイントラネットの中のIPパケットを進めるという保証が欲しいです。 余分なトラフィックがプロフィールの中にあるトラフィックと同じくらい高い確率で提供されないという条件でサイトが申し込まれたプロフィールを超えているのは、望ましいです。 また、それはそうです。

Heinanen                    Standards Track                     [Page 1]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[1ページ]RFC2597

   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.

重要である、プロフィールかプロフィールを使い果たしたなら、ネットワークは[ニコルズ]で定義されるように同じmicroflowに属す追加注文パケットでないのに問題を全くしません。

   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].

Forwarding(AF)PHBが分類することが保証されているのは、プロバイダー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パケットは3つの可能な低下先行値の1つでマークされます(再び顧客かプロバイダー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パケットの推進保証のレベルは(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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[ブラドナー]で説明されるように本書では解釈されることであるべきですか?

Heinanen                    Standards Track                     [Page 2]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[2ページ]RFC2597

2. The AF PHB Group

2. AF PHBグループ

   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.

確実なForwarding(AF)PHBグループはN独立しているAFのクラスにおける、IPパケットの推進を提供します。 それぞれのAFのクラスの中では、低下先行のM異なったレベルの1つはIPパケットに割り当てられます。 低下先行jはAF codepoint AFijと共にマークされました。(そこでは、1<がi<=Nと等しく、1<がj<=M.と等しいです)。そして、AFのクラスのものIPパケット、i、Currently、各クラス(M=3)における、3つのレベルの低下先行がある4つのクラス(N=4)が一般的使用のために定義されます。 低下先行の、より多くの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.

SHOULDがAFが分類するすべての4一般的使用を実装するDSノード。 パケットからもう1人のAFのクラスで1つの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ノードは構成可能で、最小の量の推進リソース(バッファ領域と帯域幅)をそれぞれの実装しているAFのクラスに割り当てなければなりません。 それぞれが両方の上で小さく、構成されたサービス率(帯域幅)を達成する方法で修理されて大きい時間がスケールであったならSHOULDを分類します。

   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グループから利用可能であるときに、最小限より多くの推進リソースを受け取るのにおいて構成可能であるかもしれません。 このメモは、どのように余分なリソースを割り当てるべきですが、実装が、どんなアルゴリズムが実際にサポートされるかを指定しなければならないか、そして、それらをどうしたらparameterizedされることができるかを指定しません。

   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.

低下先行価値pを含んでいるなら、AFのクラスの中では、DSノードは、よりわずかな確率と共にIPパケットを進めてはいけません。p<qであるときに、低下を含んでいるなら先行が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低下先行codepointsを受け入れなければなりません、そして、彼らは少なくとも2つの異なったレベルの呼損率をもたらさなければなりません。 いくつかのネットワークと、特に企業網では、DSノードが2つの異なったレベルのAFのクラスあたりの呼損率だけを実装するのは、妥当であるかもしれません。そこでは、一時的な混雑はまれで簡潔な発生です。 これが十分であるかもしれない間、いくつかのネットワーク、3つの異なったレベルの呼損率SHOULDには、混雑がよくある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つの異なったレベルの呼損率を実装するだけであるなら、codepoint AFx1は低い呼損率をもたらさなければなりません、そして、codepoints AFx2とAFx3は、より高い呼損率をもたらさなければなりません。

Heinanen                    Standards Track                     [Page 3]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[3ページ]RFC2597

   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.

それらであるときに、同じmicroflowの追加注文AFパケットではなく、ノードがそうしなければならないDSが彼らの低下先行にかかわらず同じAFのクラスのものです。 AFパケットの推進に関連しているどんな定量化可能なタイミング要件(遅れか遅れ変化)もありません。

   The relationship between AF classes and other PHBs is described in
   Section 7 of this memo.

AFのクラスと他のPHBsとの関係はこのメモのセクション7で説明されます。

   The AF PHB group MAY be used to implement both end-to-end and domain
   edge-to-domain edge services.

AF PHBグループは、終わらせる終わりと縁からドメインに対するドメイン縁のサービスの両方を実装するのに使用されるかもしれません。

3. Traffic Conditioning Actions

3. トラフィック調節動作

   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のクラスと増強するか、または減少させて。 しかしながら、トラフィック調節動作は同じmicroflowのパケットに関する再命令を引き起こしてはいけません。

4. Queueing and Discard Behavior

4. 待ち行列、振舞いを捨ててください。

   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実装は、炸裂から生じる短期的な混雑を許容している間、各クラスの中で長期の混雑を最小にするのを試みなければなりません。 これはアクティブな待ち行列管理アルゴリズムを必要とします。 そのようなアルゴリズムに関する例はRandom Early Drop(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のクラスを使用して、低下アルゴリズムはmicroflowsの短期的なトラフィックの特性に神経が鈍いに違いありません。 すなわち、異なった短期的な炸裂形にもかかわらず、同じより長い期間パケットレートに従った流れは本質的には等しい確率でパケットを捨てさせるべきです。 これを達成する1つの方法は低下機能の中で偶発性を使用することです。

Heinanen                    Standards Track                     [Page 4]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[4ページ]RFC2597

   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.

低下アルゴリズムは同様にただ一つのクラスと先行レベルの中ですべてのパケットを扱わなければなりません。 これは、平坦な混雑レベル、破棄が与えられたいずれに関しても、ただ一つの先行レベルの中の特定のmicroflowのパケットのレートがその先行レベルを通り抜けるその流れのトラフィックの総量の割合に比例するようになるのを含意します。

   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.

突然であるというよりむしろエンドノードへの混雑指示フィードバック、およびその結果、混雑と関連したそれぞれの低下先行におけるパケット破棄のレベルは、総合体系が安定した操作ポイントに達するのを許容するためにゆるやかでなければなりません。 この(RED)に(構成可能)で用途twoをする1つの方法が混雑レベル敷居を整えました。 平坦な混雑レベルが最初の敷居の下にあるとき、関連先行のどんなパケットも捨てられません。 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の終わりから終わりへのサービス首尾一貫しない意味論と可能の範囲が使用する限界に導く無節操な破棄。 経験がこのドキュメントの獲得されて、将来のバージョンが、よりしっかり望ましい振舞いの特定の局面を定義するかもしれないということであるので。

5. Tunneling

5. トンネリング

   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パケットの推進保証を抑えて、同じmicroflowに属すAFパケットに関する再命令を引き起こしてはいけません。

Heinanen                    Standards Track                     [Page 5]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[5ページ]RFC2597

6. Recommended Codepoints

6. お勧めのCodepoints

   Recommended codepoints for the four general use AF classes are given
   below. These codepoints do not overlap with any other general use PHB
   groups.

AFが分類する4一般的使用のためのお勧めのcodepointsを以下に与えます。 これらのcodepointsは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 codepointsのRECOMMENDED値は以下の通りです: 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 codepoint値をまとめます。

                        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  |
                      +----------+----------+----------+----------+

クラス1のクラス2のクラス3のクラス4+----------+----------+----------+----------+ 低い低下Prec| 001010 | 010010 | 011010 | 100010 | 中型の低下Prec| 001100 | 010100 | 011100 | 100100 | 高い低下Prec| 001110 | 010110 | 011110 | 100110 | +----------+----------+----------+----------+

7. Interactions with Other PHB Groups

7. 他のPHBグループとの相互作用

   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マッピングは使用が区切って、Class Selector codepointsが[ニコルズ]で推薦したローカルを妨げません。 それらのClass Selector codepointsによって選択されたPHBsはその結果、AF PHBグループと共存して、それらのために定義された推進の振舞いと関係を保有するかもしれません。 特に、'000000'のDefault PHB codepointは、従来のベストエフォート型トラフィックに使用されるために残るかもしれません。 同様に、codepoints'11×000'は、ネットワーク制御トラフィックに使用されるために残るかもしれません。

   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のクラスにおける、トラフィックの量をクラスsの(一般に異なる)の割合の割り当てられたリソースに制限する縁のトラフィック調節動作に関連して、Class Selector PHBsによって含意された総合的な振舞いを得るのにAF PHBグループを使用できます。 この場合、AF codepointsの別名としてClass Selector codepointsのいくつかかすべてを使用するのは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:

Class Selector PHBsに加えて、いかなる他のPHBグループもAF PHBグループと共に同じDSドメインの中に共同存在するかもしれません。 しかしながら、どんな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のクラスに割り当てられた推進リソースを先取りするかもしれません。 この先取りは、通常のネットワーク操作で起こってはいけませんが、ある異例の状況で適切であるかもしれません--例えば、必要であると、'11×000'codepointは、不意に高いレベルのネットワーク制御トラフィックに優先権を与えるためにリソースを転送しながら、AFを先取りするかもしれません。

Heinanen                    Standards Track                     [Page 6]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[6ページ]RFC2597

   (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のクラスとDefault PHBの間にどんな残っているリソースも割り当てるかもしれません。 代替の例では、余分なAFトラフィックを進めるのにどんな残っているリソースも割り当てることができました、すべてのAF需要にこたえるときだけDefault PHBにささげられたリソースで。

   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の間のどんな特定の関係保持も分類されると指定しません。 それは、選ばれているどんな関係も記録されるだけであるのを必要とします。 実装は、これらの関係のどちらかか両方が構成可能であることを許容するかもしれません。 このレベルの構成の柔軟性が多くのネットワーク管理者にとって貴重であると判明すると予想されます。

8. Security Implications

8. セキュリティ含意

   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ドメインSHOULDはドメインに入るトラフィックを申し込まれたプロフィールに制限します。 また、サービス不能攻撃から顧客DSドメインへのリンクを保護するために、プロバイダーDSドメインSHOULDは顧客DSドメインにどうリンクに関するリソースをAFパケットに割り当てるかを指定させます。 サービス提供が、AF codepointと共にマークされたトラフィックがソースや送付先アドレスのような属性によって制限されるのを必要とするなら、そのような属性の正当性について確かめるのは、ネットワークにおけるイングレスノードの責任です。

   Other security considerations are covered in [Blake] and [Nichols].

他のセキュリティ問題は[ブレーク]と[ニコルズ]でカバーされています。

9. Intellectual Property Rights

9. 知的所有権

   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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しくは、要求された権利のオンラインリストに相談してください。

10. IANA Considerations

10. IANA問題

   This document allocates twelve codepoints, listed in section 6, in
   Pool 1 of the code space defined by [Nichols].

このドキュメントは[ニコルズ]によって定義されたコードスペースのPool1にセクション6で記載された12codepointsを割り当てます。

Heinanen                    Standards Track                     [Page 7]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[7ページ]RFC2597

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.

例えば、3つのサービスのクラスから成るそのように呼ばれたオリンピックのサービスを実装するのに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.

パケットの低下先行レベルを割り当てることができました、例えば、パラメタとしてレートとサイズを持っている水漏れするバケツトラフィックpolicerを使用することによって、どれが合計2であるかは値を押し破きました: 遂行された放出量と過剰はサイズを押し破きました。 中型の低下先行は、バケツの中のトークンの数であるならバケツが空であるならバケツの中のトークンの数が過剰がサイズを押し破いたより大きいなら、低い低下先行がパケットに割り当てられて、ゼロ以上と、しかし、高々余分な放出量と高い低下先行です。 また、顧客DSドメインから高い低下先行トラフィックの量に上限を設定するのも、1つの顧客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をもっている顧客が低い帯域幅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グループを使用できた、食糧を供給されたAFのクラスに関して、最大であるなら、そのクラスへの到着率はそれぞれのDSノードで先験的に知られています。 しかしながら、必要に入場コントロールサービスの仕様はこのドキュメントの範囲を超えています。 低い損失が目的でないなら実装する、設定のそばでAFのクラスに利用可能なバッファ領域への低最大の限界に食糧を供給する上で低遅延サービスを実装することができました。

Heinanen                    Standards Track                     [Page 8]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[8ページ]RFC2597

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.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。

   [Bradner] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[ブラドナー] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、明白な配分。 Networkingの上のIEEE/ACM Transactions、Volume6、Number4、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.

[フロイド] Congestion Avoidanceのためのフロイド、S.とジェーコブソン、V.、Random Early Detectionゲートウェイ。 Networkingの上のIEEE/ACM Transactions、Volume1、Number4、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分野)の定義」RFC2474(1998年12月)。

Heinanen                    Standards Track                     [Page 9]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[9ページ]RFC2597

Authors' Addresses

作者のアドレス

   Juha Heinanen
   Telia Finland
   Myyrmaentie 2
   01600 Vantaa, Finland

ユハ・Heinanen冬胞子堆フィンランドMyyrmaentie2 01600バンター(フィンランド)

   EMail: jh@telia.fi

メール: jh@telia.fi

   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, California 93111

フレッドベイカーシスコシステムズ519のLado Driveサンタバーバラ、カリフォルニア 93111

   EMail: fred@cisco.com

メール: fred@cisco.com

   Walter Weiss
   Lucent Technologies
   300 Baker Avenue, Suite 100,
   Concord, MA  01742-2168

ウォルターワイスルーセントテクノロジーズ300ベイカーAvenue、スイート100、コンコード、MA01742-2168

   EMail: wweiss@lucent.com

メール: wweiss@lucent.com

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139

ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139

   EMail: jtw@lcs.mit.edu

メール: jtw@lcs.mit.edu

Heinanen                    Standards Track                    [Page 10]

RFC 2597              Assured Forwarding PHB Group             June 1999

グループ1999年6月にPHBを進めながら保証されたHeinanen標準化過程[10ページ]RFC2597

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 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機能のための基金は現在、インターネット協会によって提供されます。

Heinanen                    Standards Track                    [Page 11]

Heinanen標準化過程[11ページ]