この文書はRFC2474の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group K. Nichols
Request for Comments: 2474 Cisco Systems
Obsoletes: 1455, 1349 S. Blake
Category: Standards Track Torrent Networking Technologies
F. Baker
Cisco Systems
D. Black
EMC Corporation
December 1998
Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers
ＩＰｖ４とＩＰｖ６ヘッダーでの
サービス区分フィールド（ＤＳフィールド）の定義
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
概要
Differentiated services enhancements to the Internet protocol are
intended to enable scalable service discrimination in the Internet
without the need for per-flow state and signaling at every hop. A
variety of services may be built from a small, well-defined set of
building blocks which are deployed in network nodes. The services
may be either end-to-end or intra-domain; they include both those
that can satisfy quantitative performance requirements (e.g., peak
bandwidth) and those based on relative performance (e.g., "class"
differentiation). Services can be constructed by a combination of:
インターネット・プロトコルへの区分サービス拡張は、フロー毎の状態やホッ
プ毎のシグナリングなしで、インターネットレベルでのサービスを可能にす
るように意図されます。構成ブロックの小さい明瞭なセットからいろいろな
サービスが作られ、これはネットワークノードに配置されるかもしれません。
サービスはエンドエンドをつなぐいだり、ドメイン間を接続するかもしれま
せん；それらは量的なパフォーマンス条件（例えば、ピークのバンド幅）や、
相対的なパフォーマンス（例えば「クラス」分け）の両方を含みます。サー
ビスが組合せによって組み立てできます：
- setting bits in an IP header field at network boundaries
(autonomous system boundaries, internal administrative boundaries,
or hosts),
- ネットワーク境界線（自律システム境界線や、内部管理境界線や、ホスト）
でビットをＩＰヘッダーフィールドにセットします、。
- using those bits to determine how packets are forwarded by the
nodes inside the network, and
- どのようにパケットがネットワーク内のノードで転送されるか決定するた
めにそれらのビットを使います、そして。
- conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service.
- それぞれのサービス条件あるいは規則どおりにネットワーク境界線でマー
クしたパケットを調整します。
The requirements or rules of each service must be set through
administrative policy mechanisms which are outside the scope of this
document. A differentiated services-compliant network node includes
a classifier that selects packets based on the value of the DS field,
along with buffer management and packet scheduling mechanisms capable
of delivering the specific packet forwarding treatment indicated by
the DS field value. Setting of the DS field and conditioning of the
temporal behavior of marked packets need only be performed at network
boundaries and may vary in complexity.
それぞれのサービス条件や規則がこの文書の範囲の外にある管理ポリシーメ
カニズムを通して決まるに違いありません。区分サービスに従っているネッ
トワークノードが、ＤＳフィールド値に基づくパケットの分類と、バッファ
管理と、ＤＳフィールド値によって示された特定のパケット転送処理を含み
ます。ＤＳフィールドの設定とマークしたパケットの一時的動作を整えるこ
とはネットワーク境界線でだけ行うことが必要で、複雑さが変化するかもし
れません。
This document defines the IP header field, called the DS (for
differentiated services) field. In IPv4, it defines the layout of
the TOS octet; in IPv6, the Traffic Class octet. In addition, a base
set of packet forwarding treatments, or per-hop behaviors, is
defined.
この文書は、ＤＳ（区分サービスのために）フィールドと呼ぶ、ＩＰヘッダー
フィールドを定義します。ＩＰｖ４ではＴＯＳオクテットに配置し、ＩＰｖ
６ではトラフィッククラスオクテットに配置します。加えて、パケット転送
の扱いやホップ毎の動作の基本セットが定義されます。
For a more complete understanding of differentiated services, see
also the differentiated services architecture [ARCH].
区分サービスのより完全な理解のために、区分サービスアーキテクチャ
[ARCH]を見てください。
Table of Contents
目次
1. Introduction
1. はじめに
2. Terminology Used in This Document
2. この文書で使われる専門用語
3. Differentiated Services Field Definition
3. 区分サービスフィールド定義
4. Historical Codepoint Definitions and PHB Requirements
4. 歴史的コードポイント定義とＰＨＢ必要条件
4.1 A Default PHB
4.1 デフォルトＰＨＢ
4.2 Once and Future IP Precedence Field Use
4.2 過去と未来ののＩＰ優先フィールドの使い方
4.2.1 IP Precedence History and Evolution in Brief
4.2.1 ＩＰの優先の歴史と進展の手短な説明
4.2.2 Subsuming IP Precedence into Class Selector
Codepoints
4.2.2 クラス選択コードポイントにＩＰ優先を包括
4.2.2.1 The Class Selector Codepoints
4.2.2.1 クラス選択コードポイント
4.2.2.2 The Class Selector PHB Requirements
4.2.2.2 クラス選択ＰＨＢ条件
4.2.2.3 Using the Class Selector PHB Requirements
for IP Precedence Compatibility
4.2.2.3 ＩＰ優先互換性のためのクラス選択ＰＨＢ条件
4.2.2.4 Example Mechanisms for Implementing Class
Selector Compliant PHB Groups
4.2.2.4 クラス選択適合ＰＨＢグループを実装するため
のメカニズム例
4.3 Summary
4.3 まとめ
5. Per-Hop Behavior Standardization Guidelines
5. ホップ毎の動作の標準化ガイドライン
6. IANA Considerations
6. ＩＡＮＡの考慮
7. Security Considerations
7. セキュリティの考察
7.1 Theft and Denial of Service
7.1 盗みとサービス否定
7.2 IPsec and Tunnelling Interactions
7.2 ＩＰｓｅｃとトンネルの相互作用
8. Acknowledgements
8. 謝辞
9. References
9. 参考文献
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
Differentiated services are intended to provide a framework and
building blocks to enable deployment of scalable service
discrimination in the Internet. The differentiated services approach
aims to speed deployment by separating the architecture into two
major components, one of which is fairly well-understood and the
other of which is just beginning to be understood. In this, we are
guided by the original design of the Internet where the decision was
made to separate the forwarding and routing components. Packet
forwarding is the relatively simple task that needs to be performed
on a per-packet basis as quickly as possible. Forwarding uses the
packet header to find an entry in a routing table that determines the
packet's output interface. Routing sets the entries in that table
and may need to reflect a range of transit and other policies as well
as to keep track of route failures. Routing tables are maintained as
a background process to the forwarding task. Further, routing is the
more complex task and it has continued to evolve over the past 20
years.
区分サービスがインターネットの大きさで可能なサービスの区別の実装をす
るフレームワークとビルディング・ブロックを供給するように意図されます。
区分サービスの方法は、すばやく配置するために２つの主要なコンポーネン
トに分けられ、１つはかなりよく理解されて、他がちょうど理解され始めて
いる。これは、転送とルーティングのコンポーネントを切り離すインターネッ
トのオリジナルのデザインに従います。パケット転送は可能な限り速くパケッ
トごとに行う必要がある比較的単純な仕事です。転送はパケットの出力イン
タフェースを決定するルーティングテーブルで項目を見つけるためにパケッ
トヘッダーを使います。ルーティングが項目をそのテーブルに設定して、中
継とそのほかのポリシーを反映して経路障害を記録・追跡する必要がありま
す。ルーティングテーブルが転送タスクのバックグラウンドプロセスとして
保守されます。さらに、ルーティングはより複雑な仕事で、過去の２０年に
わたって進展し続けました。
Analogously, the differentiated services architecture contains two
main components. One is the fairly well-understood behavior in the
forwarding path and the other is the more complex and still emerging
background policy and allocation component that configures parameters
used in the forwarding path. The forwarding path behaviors include
the differential treatment an individual packet receives, as
implemented by queue service disciplines and/or queue management
disciplines. These per-hop behaviors are useful and required in
network nodes to deliver differentiated treatment of packets no
matter how we construct end-to-end or intra-domain services. Our
focus is on the general semantics of the behaviors rather than the
specific mechanisms used to implement them since these behaviors will
evolve less rapidly than the mechanisms.
同様に、区分サービスアーキテクチャは２つの主要コンポーネントを含んで
います。１つは転送パスでかなりよく理解された行動で、他は転送パスで使
われたパラメータを設定するいっそう複雑でまだ出現しているバックグラウ
ンドポリシーと配分コンポーネントです。転送パス行動は、個々の受信パケッ
トのキューサービスとキュー管理での異なる扱いを含みます。これらのホッ
プ毎の動作は、そして、我々が端と端をつないでいるか、あるいはドメイン
内のサービスを組み立てる方法はどんな方法であっても、配達するべきネッ
トワークノードでパケットの区別される扱いを必要としました。我々のフォー
カスは、これらの行動がメカニズムより低度に急速に進展するであろう時か
ら、それらを実行するために使われた特定のメカニズムよりどちらかと言う
と、行動の一般的な意味論の上にあります。
Per-hop behaviors and mechanisms to select them on a per-packet basis
can be deployed in network nodes today and it is this aspect of the
differentiated services architecture that is being addressed first.
In addition, the forwarding path may require that some monitoring,
policing, and shaping be done on the network traffic designated for
"special" treatment in order to enforce requirements associated with
the delivery of the special treatment. Mechanisms for this kind of
traffic conditioning are also fairly well-understood. The wide
deployment of such traffic conditioners is also important to enable
the construction of services, though their actual use in constructing
services may evolve over time.
ホップ毎の動作とパケット毎にそれを選択するメカニズムは今日ネットワー
クノードに配置され、これは区分サービス機構の概要で、最初に扱われたも
のです。加えて、転送パスは、ネットワークトラヒックに対して、特別な待
遇の配達と結び付けられた必要条件を実施するために「特別な」待遇のため
に、モニターし、ポリシーを適用し、シェーピングを必要とするかもしれま
せん。この種類のトラフィックを左右するためのメカニズムはなりよく理解
されます。このようなトラフィック調整の広い展開は、それらの、サービス
を組み立てることにおいての実際の用途が長い時間にわたって進展するかも
しれないけれども、同じくサービスの建設を可能にするために、重要です。
The configuration of network elements with respect to which packets
get special treatment and what kinds of rules are to be applied to
the use of resources is much less well-understood. Nevertheless, it
is possible to deploy useful differentiated services in networks by
using simple policies and static configurations. As described in
[ARCH], there are a number of ways to compose per-hop behaviors and
traffic conditioners to create services. In the process, additional
experience is gained that will guide more complex policies and
allocations. The basic behaviors in the forwarding path can remain
the same while this component of the architecture evolves.
Experiences with the construction of such services will continue for
some time, thus we avoid standardizing this construction as it is
premature. Further, much of the details of service construction are
covered by legal agreements between different business entities and
we avoid this as it is very much outside the scope of the IETF.
パケットが特別な待遇を得られるネットワーク要素の形状と、リソースの使
用に適用される規則の種類はあまりよく理解されていません。にもかかわら
ず、単純なポリシーと静的な設定を使うことでネットワークで有用な区分サー
ビスを設定することは可能です。[ARCH]で記述されるように、サービスを作
るためのホップ毎の行動とトラフィック調整を構成する多くの方法がありま
す。この過程で、いっそう複雑なポリシーと割り当てを導くであろう追加の
経験が得られます。転送パスでの基本的な行動は、このアーキテクチャのコ
ンポーネントが進展する間に、同じのままでいることができます。このよう
なサービスの構築の経験がしばらくの間継続するでしょう、時期尚早なので
この構築を標準化するのを避けます。さらに、サービス構築の細部について
は異なっるビジネス参加者間で法律上の協定によってカバーされ、我々はこ
れがIETFの範囲なのでこれを避けます。
This document concentrates on the forwarding path component. In the
packet forwarding path, differentiated services are realized by
mapping the codepoint contained in a field in the IP packet header to
a particular forwarding treatment, or per-hop behavior (PHB), at each
network node along its path. The codepoints may be chosen from a set
of mandatory values defined later in this document, from a set of
recommended values to be defined in future documents, or may have
purely local meaning. PHBs are expected to be implemented by
employing a range of queue service and/or queue management
disciplines on a network node's output interface queue: for example
weighted round-robin (WRR) queue servicing or drop-preference queue
management.
この文書は転送パスコンポーネントに集中します。パケット転送パスで、区
分サービスが、パス上の各ネットワークノードで特定の転送の扱いをするか
ホップ毎の振る舞い（ＰＨＢ）をするための、コードポイントをＩＰパケッ
トのフィールドにマッピングすることで実現できます。コードポイントはこ
の文書の後に定義する必須の値の集合から、または将来の文書で推薦された
値からか、ローカルな意味から選ばれるかもしれません。PHBはネットワー
クノードの出力インタフェースキュー上に広範囲のキューサービスやキュー
管理を使用することで実装されることを期待されます：例えば重み付きラウ
ンドロビン（WRR）キューサービスを提供することや落下優先キュー管理です。
Marking is performed by traffic conditioners at network boundaries,
including the edges of the network (first-hop router or source host)
and administrative boundaries. Traffic conditioners may include the
primitives of marking, metering, policing and shaping (these
mechanisms are described in [ARCH]). Services are realized by the
use of particular packet classification and traffic conditioning
mechanisms at boundaries coupled with the concatenation of per-hop
behaviors along the transit path of the traffic. A goal of the
differentiated services architecture is to specify these building
blocks for future extensibility, both of the number and type of the
building blocks and of the services built from them.
マーク付けは、ネットワーク（最初のホップのルーターあるいはソースホス
ト）と管理上の境界線のエッジを含めて、ネットワーク境界線のトラフィッ
ク調整者によって行われます。トラフィック調整者がにマークを付けて、測
り、ポリシーを行い、シェープするプリミティブを含むかもしれません（メ
カニズムが[ARCH]に記述される）。サービスが特定のパケット分類により実
現し、境界でのトラヒック調整メカニズムが中継パスのトラヒックのホップ
毎の振る舞いの結合で整えられます。区分サービスアーキテクチャのゴール
がこれらの将来の拡張性のためのビルディング・ブロックと、ビルディング・
ブロックの番号とタイプと、これらからサービスを作ることを指定すること
です。
Terminology used in this memo is defined in Sec. 2. The
differentiated services field definition (DS field) is given in Sec.
3. In Sec. 4, we discuss the desire for partial backwards
compatibility with current use of the IPv4 Precedence field. As a
solution, we introduce Class Selector Codepoints and Class Selector
Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior
standardization. Sec. 6 discusses guidelines for allocation of
codepoints. Sec. 7 covers security considerations.
この文書で使う専門用語が２章で定義されます。区分サービスフィールド定
義（ＤＳフィールド）は３章で与えられます。４章で、ＩＰｖ４優先フィー
ルドの現在の使用との部分的なバックワードコンパチビリティの希望を論じ
ます。解決策として、我々はクラス選択コードポイントとクラス選択迎合Ｐ
ＨＢを紹介します。５章がホップ毎の行動標準化のガイドラインを示します。
６章がコードポイントの割り当てのガイドラインを論じます。７章がセキュ
リティの考察をします。
This document is a concise description of the DS field and its uses.
It is intended to be read along with the differentiated services
architecture [ARCH].
この文書はＤＳフィールドとその使用の簡潔な記述です。区分サービスアー
キテクチャ[ARCH]とともに読まれることことが意図されます。
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 [RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は、
[RFC2119]で記述されるように解釈されるはずです。
2. Terminology Used in This Document
2. この文書で使われる専門用語
Behavior Aggregate: a collection of packets with the same codepoint
crossing a link in a particular direction. The terms "aggregate" and
"behavior aggregate" are used interchangeably in this document.
動作対象：リンクを同じ方向に移動する同じコードポイントのパケットの集
合。用語「対象」と「動作対象」がこの文書で交換可能に使われます。
Classifier: an entity which selects packets based on the content of
packet headers according to defined rules.
分類者：定義された規則に従ってパケットヘッダーの内容に基づいてパケッ
トを選ぶエンティティー。
Class Selector Codepoint: any of the eight codepoints in the range '
xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints
are discussed in Sec. 4.2.2.
クラス選択コードポイント：' xxx000'の範囲の８つのコードポイントのどれ
か（'x'は'0'か'1'）。クラス選択コードポイントが４.２.２章で論じられま
す。
Class Selector Compliant PHB: a per-hop behavior satisfying the Class
Selector PHB Requirements specified in Sec. 4.2.2.2.
クラス選択追従ＰＨＢ ：ホップ毎のクラス選択ＰＨＢ必要条件を満たしてい
る行動は４.２.２.２章で指定します。
Codepoint: a specific value of the DSCP portion of the DS field.
Recommended codepoints SHOULD map to specific, standardized PHBs.
Multiple codepoints MAY map to the same PHB.
コードポイント：ＤＳフィールドのＤＳＣＰ部の特定の価値。推薦されたコー
ドポイントが特定の、標準化されたＰＨＢに投影するべきです(SHOULD)。多
数のコードポイントを同じＰＨＢに投影してもよいです(MAY)。
Differentiated Services Boundary: the edge of a DS domain, where
classifiers and traffic conditioners are likely to be deployed. A
differentiated services boundary can be further sub-divided into
ingress and egress nodes, where the ingress/egress nodes are the
downstream/upstream nodes of a boundary link in a given traffic
direction. A differentiated services boundary typically is found at
the ingress to the first-hop differentiated services-compliant router
(or network node) that a host's packets traverse, or at the egress of
the last-hop differentiated services-compliant router or network node
that packets traverse before arriving at a host. This is sometimes
referred to as the boundary at a leaf router. A differentiated
services boundary may be co-located with a host, subject to local
policy. Also DS boundary.
区分サービス境界線：ＤＳドメインのエッジと分類者とトラフィック調整者
が配置される可能性が高い所。区分サービス境界線がさらに入口と出口ノー
ドに小分割でき、入口／出国ノードは所定のトラフィック方向で境界線リン
クの下流／上流のノードです。区分サービス境界線が典型的にホストのパケッ
トが渡り歩く最初のホップの入口の区分サービスに従うルーター（あるいは
ネットワークノード）や、パケットがホストに到着する前に渡り歩く最後の
出口のホップの区分サービスに従うルーターあるいはネットワークノードで
見いだされます。これはしばしばリーフルーターの境界線であると述べられ
ます。区分サービス境界線が、ローカルポリシーの適用を受けて、ホストと
一緒の場所にあるかもしれません。ＤＳ境界線と同じです。
Differentiated Services-Compliant: in compliance with the
requirements specified in this document. Also DS-compliant.
区分サービス追従：この文書で指定された必要条件に従います。ＤＳ追従と
同じです。
Differentiated Services Domain: a contiguous portion of the Internet
over which a consistent set of differentiated services policies are
administered in a coordinated fashion. A differentiated services
domain can represent different administrative domains or autonomous
systems, different trust regions, different network technologies
(e.g., cell/frame), hosts and routers, etc. Also DS domain.
区分サービスドメイン：区分サービスポリシーと管理が一貫しているインター
ネットの連続的な部分。区分サービスドメインが異なった管理のドメインや
自律システムや異なった信頼地域や異なったネットワーク技術（例えば、セ
ル／フレーム）やホストとルーターなどを表すことができます。ＤＳドメイ
ンも同じです。
Differentiated Services Field: the IPv4 header TOS octet or the IPv6
Traffic Class octet when interpreted in conformance with the
definition given in this document. Also DS field.
区分サービスフィールド：この文書で与えられた定義に従っている解釈され
る時のＩＰｖ４ヘッダーやＩＰｖ６トラヒッククラスオクテット。ＤＳフィー
ルドと同じです。
Mechanism: The implementation of one or more per-hop behaviors
according to a particular algorithm.
メカニズム：ホップ毎の１つあるいはさらに多くの実装特有のアルゴリズム
による行動。
Microflow: a single instance of an application-to-application flow of
packets which is identified by source address, destination address,
protocol id, and source port, destination port (where applicable).
マイクロフロー：ソースアドレスと宛先アドレスとプロトコルＩＤとソース
ポートと宛先ポート（適用可能である場合）によって識別されるアプリケー
ションからアプリケーションへのパケットの流れのひとつのインスタンス。
Per-hop Behavior (PHB): a description of the externally observable
forwarding treatment applied at a differentiated services-compliant
node to a behavior aggregate. The description of a PHB SHOULD be
sufficiently detailed to allow the construction of predictable
services, as documented in [ARCH].
ホップ毎の動作（ＰＨＢ）：区分サービスに従っているノードが、動作対象
に適用する、対外的に守る転送処理の記述です。ＰＨＢの記述は[ARCH]で文
書化されるように、予測可能なサービスの構築を許すために十分に詳述され
るべきです(SHOULD)。
Per-hop Behavior Group: a set of one or more PHBs that can only be
meaningfully specified and implemented simultaneously, due to a
common constraint applying to all PHBs in the set such as a queue
servicing or queue management policy. Also PHB Group.
ホップ毎動作グループ：意味が明示されて同時に実装されるＰＨＢの集合で、
キューサービスやキュー管理の様な共通の制約が適用されます。ＰＨＢグルー
プと同じです。
Traffic Conditioning: control functions that can be applied to a
behavior aggregate, application flow, or other operationally useful
subset of traffic, e.g., routing updates. These MAY include
metering, policing, shaping, and packet marking. Traffic
conditioning is used to enforce agreements between domains and to
condition traffic to receive a differentiated service within a domain
by marking packets with the appropriate codepoint in the DS field and
by monitoring and altering the temporal characteristics of the
aggregate where necessary. See [ARCH].
トラフィック条件付け：動作対象に適用できる制御機能、アプリケーション
流れやトラフィックの他の操作の一部、例えば、ルーティング更新。これら
は測定、ポリシング、シェーピングとパケットマーク付けを含むかもしれま
せん。トラフィックを条件付けは、ドメイン間の協定を強制し、ドメインの
受信したマークを付けられた区分サービストラヒックのＤＳフィールドのコー
ドポイントを適切に整え、必要なら対象の一時的な特徴をモニターし警告す
るのに使われます。[ARCH]を見てください。
Traffic Conditioner: an entity that performs traffic conditioning
functions and which MAY contain meters, policers, shapers, and
markers. Traffic conditioners are typically deployed in DS boundary
nodes (i.e., not in interior nodes of a DS domain).
トラフィック調整者：トラフィック調整機能を行うエンティティ、これは計
測、ポリシー適用、シェーピング、マーク付けを含むかもしれません(MAY)。
トラフィック調整者が典型的にＤＳ境界線ノード（すなわちＤＳドメインの
内部のノードではない）で実装されます。
Service: a description of the overall treatment of (a subset of) a
customer's traffic across a particular domain, across a set of
interconnected DS domains, or end-to-end. Service descriptions are
covered by administrative policy and services are constructed by
applying traffic conditioning to create behavior aggregates which
experience a known PHB at each node within the DS domain. Multiple
services can be supported by a single per-hop behavior used in
concert with a range of traffic conditioners.
サービス：特定のドメイン内か、ＤＳドメインをまたぐか、エンドエンド
（の一部）の全体的処理の記述。サービス記述が管理ポリシーでカバーされ、
サービスがＤＳドメインの各ノードの周知のＰＨＢを経験する動作対象を作
るためにトラフィック条件を適用することで作られます。多数のサービスが、
１つのホップ毎の動作を行動を広範囲のトラフィック調整者が協調させて実
行できます。
To summarize, classifiers and traffic conditioners are used to select
which packets are to be added to behavior aggregates. Aggregates
receive differentiated treatment in a DS domain and traffic
conditioners MAY alter the temporal characteristics of the aggregate
to conform to some requirements. A packet's DS field is used to
designate the packet's behavior aggregate and is subsequently used to
determine which forwarding treatment the packet receives. A behavior
aggregate classifier which can select a PHB, for example a
differential output queue servicing discipline, based on the
codepoint in the DS field SHOULD be included in all network nodes in
a DS domain. The classifiers and traffic conditioners at DS
boundaries are configured in accordance with some service
specification, a matter of administrative policy outside the scope of
this document.
要約すると、分類者とトラフィック調整者がどのパケットが動作対象に加え
られるか選択するために使われます。対象がＤＳドメインで区別した処理を
受け、トラフィック調整者がある条件に従うために対象の一時的な特徴を変
えてもよいです(MAY)。パケットのＤＳフィールドはパケットの動作対象を指
定するために使われ、パケットがどの転送扱いを受けか決定するためにその
後使われます。ＤＳフィールドのコードポイントに基づいて、例えば区分出
力キューサービスといったＰＨＢを選択する、動作対象分類者がＤＳドメイ
ンの全てのネットワークノードに含められるべきです(SHOULD)。ＤＳ境界線
での分類者とトラフィック調整者はあるサービス仕様書に従って設定され、
管理ポリシーの問題はこの文書の範囲外です。
Additional differentiated services definitions are given in [ARCH].
追加の区分サービス定義が[ARCH]で与えられます。
3. Differentiated Services Field Definition
3. 区分サービスフィールド定義
A replacement header field, called the DS field, is defined, which is
intended to supersede the existing definitions of the IPv4 TOS octet
[RFC791] and the IPv6 Traffic Class octet [IPv6].
ＤＳフィールドと呼ばれるヘッダフィードの置き換えが定義され、これは
ＩＰｖ４のTOSオクテット［RFC791］とＩＰｖ６トラフィッククラスオクテッ
ト［IPv6］の既存の定義を置き換えるように意図されます。
Six bits of the DS field are used as a codepoint (DSCP) to select the
PHB a packet experiences at each node. A two-bit currently unused
(CU) field is reserved and its definition and interpretation are
outside the scope of this document. The value of the CU bits are
ignored by differentiated services-compliant nodes when determining
the per-hop behavior to apply to a received packet.
６ビットのＤＳフィールドはパケットが各ノードにおいて経験するＰＨＢを
選ぶためのコードポイント（DSCP）として用いられます。２ビットの現在使
われていない（CU）フィールドが予約され、この定義と解釈はこの文書の範
囲の外です。受信パケットのホップ毎の動作を決定する際にＣＵビットの値
が区分サービスに従うノードによって無視されます。
The DS field structure is presented below:
ＤＳフィールド構造を下に提示します：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint
DSCP：区分サービスコードポイント。
CU: currently unused
CU： 現在使われていません。
In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1')
used in this document, the left-most bit signifies bit 0 of the DS
field (as shown above), and the right-most bit signifies bit 5.
ＤＳＣＰ値表記'xxxxxx'（'x'が'0'か'1'）がこの文書で使われ、左の最上位
ビットは（上記の様に）ＤＳフィールドのビット０を意味し、最も右のビット
はビット５を意味します。
Implementors should note that the DSCP field is six bits wide. DS-
compliant nodes MUST select PHBs by matching against the entire 6-bit
DSCP field, e.g., by treating the value of the field as a table index
which is used to select a particular packet handling mechanism which
has been implemented in that device. The value of the CU field MUST
be ignored by PHB selection. The DSCP field is defined as an
unstructured field to facilitate the definition of future per-hop
behaviors.
実装者はＤＳＣＰフィールドの幅６ビットであることを指摘するべきです。
ＤＳに従うノードが全部の６ビットのＤＳＣＰフィールドに対して一致する
ＰＨＢを選ばなくてはなりません(MUST)、例えば、フィールドの値をその装
置に実装されたパケット処理メカニズムを選ぶために使うテーブルインデッ
クスとして扱います。ＣＵフィールドの値はＰＨＢ選択時に無視されなくて
はなりません(MUST)。ＤＳＣＰフィールドがホップ毎の行動の将来形の定義
を容易にするため構造化されないフィールドと定義しました。
With some exceptions noted below, the mapping of codepoints to PHBs
MUST be configurable. A DS-compliant node MUST support the logical
equivalent of a configurable mapping table from codepoints to PHBs.
PHB specifications MUST include a recommended default codepoint,
which MUST be unique for codepoints in the standard space (see Sec.
6). Implementations should support the recommended codepoint-to-PHB
mappings in their default configuration. Operators may choose to use
different codepoints for a PHB, either in addition to or in place of
the recommended default. Note that if operators do so choose, re-
marking of DS fields may be necessary at administrative boundaries
even if the same PHBs are implemented on both sides of the boundary.
いくつかの例外を除き、コードポイントからＰＨＢへのマッピングは構成可
能に違いありません(MUST)。ＤＳに従うノードがコードポイントからＰＨＢ
まで構成可能なマッピングテーブルの論理的同等物をサポートしなくてはな
りません(MUST)。ＰＨＢ仕様が推薦されたデフォルトコードポイントを含ま
なくてはならず(MUST)、これは標準的な空間でユニークなコードポイントで
す(MUST)（６章参照）。実装がデフォルト設定で推薦されたコードポイント
からＰＨＢへのマッピングをサポートするべきです。オペレーターが推薦さ
れたデフォルトのほかや置換えで、異なったコードポイントを使うと決めて
もよいです。もしオペレーターがこれを選択するなら、たとえ同じＰＨＢが
境界線の両側に実装されるとしても、ＤＳフィールドの再マーク付けが管理
境界線で必要かもしれないことに注意を払ってください。
See [ARCH] for further discussion of re-marking.
再マーク付けのそれ以上の論議は[ARCH]を見てください。
The exceptions to general configurability are for codepoints 'xxx000'
and are noted in Secs. 4.2.2 and 4.3.
一般的な構成の例外はコードポイントの'xxx000'で、４．２．２章や４．３章
で注記します。
Packets received with an unrecognized codepoint SHOULD be forwarded
as if they were marked for the Default behavior (see Sec. 4), and
their codepoints should not be changed. Such packets MUST NOT cause
the network node to malfunction.
認識できないコードポイントの受信パケットは、デフォルト行動（４章参照）
のマークが付いたかのように転送されるべきで(SHOULD)、コードポイントは
変更すべきではありません。このようなパケットはネットワークノードを誤
作動させてはなりません(MUST NOT)。
The structure of the DS field shown above is incompatible with the
existing definition of the IPv4 TOS octet in [RFC791]. The
presumption is that DS domains protect themselves by deploying re-
marking boundary nodes, as should networks using the RFC 791
Precedence designations. Correct operational procedure SHOULD follow
[RFC791], which states: "If the actual use of these precedence
designations is of concern to a particular network, it is the
responsibility of that network to control the access to, and use of,
those precedence designations." Validating the value of the DS field
at DS boundaries is sensible in any case since an upstream node can
easily set it to any arbitrary value. DS domains that are not
isolated by suitably configured boundary nodes may deliver
unpredictable service.
上記ＤＳフィールドの構造は[RFC791]のＩＰｖ４のＴＯＳオクテットの既存
の定義と不適合です。ＤＳドメインが境界線ノードで再マーク付けを実装す
ることで自身を守ると仮定し、RFC791優先指定を使うネットワークもそうす
るべきです。正しい使用可能な手続きが[RFC791]に従うべきで(SHOULD)、こ
れは次の通り述べています：「これらの優先指定の実際の使用が個々のネッ
トワークの問題で、もし使用するなら、優先指定のアクセスをコントロール
するのは各ネットワークの責任です」。ＤＳ境界でＤＳフィールド値を有効
にすることは、上流ノードが容易に任意の値を設定できるので、どんな場合
ででも思慮があります。適切に設定された境界線ノードによって区切られて
いないＤＳドメインでは予想できないサービスを配達するかもしれません。
Nodes MAY rewrite the DS field as needed to provide a desired local
or end-to-end service. Specifications of DS field translations at DS
boundaries are the subject of service level agreements between
providers and users, and are outside the scope of this document.
Standardized PHBs allow providers to build their services from a
well-known set of packet forwarding treatments that can be expected
to be present in the equipment of many vendors.
ノードが望ましいローカルなあるいはエンドエンドサービスを供給するため
にＤＳフィールドを再設定する必要があるかもしれません(MAY)。ＤＳ境界に
おいてのＤＳフィールド翻訳の仕様はプロバイダとユーザーの間にサービス
レベル協定の問題であって、この文書の範囲の外です。標準化されたＰＨＢ
は多くのベンダーの装置で存在していることを期待されるパケット転送処理
のよく知られているセットでプロバイダにサービスを作ることを許します。
4. Historical Codepoint Definitions and PHB Requirements
4. 歴史的コードポイント定義とＰＨＢ必要条件
The DS field will have a limited backwards compatibility with current
practice, as described in this section. Backwards compatibility is
addressed in two ways. First, there are per-hop behaviors that are
already in widespread use (e.g., those satisfying the IPv4 Precedence
queueing requirements specified in [RFC1812]), and we wish to permit
their continued use in DS-compliant nodes. In addition, there are
some codepoints that correspond to historical use of the IP
Precedence field and we reserve these codepoints to map to PHBs that
meet the general requirements specified in Sec. 4.2.2.2, though the
specific differentiated services PHBs mapped to by those codepoints
MAY have additional specifications.
ＤＳフィールドは、この章で記述されるように、現在の実装との限定された
バックワードコンパチビリティを持つでしょう。バックワードコンパチビリ
ティが２つの方法で扱われます。最初に、ホップ毎にすでに広範囲にわたる
使用可能な動作があります（例えば、[RFC1812]で指定したＩＰｖ４優先キュー
イング条件を満たすもの）、そして我々はＤＳに従うノードでそれらの継続
的な使用を認めることを望みます。加えて、ＩＰ優先フィールドの歴史的の
使用に対応するあるコードポイントがあります、そして、特定の区分サービ
スが追加の仕様書を持つかもしれない(MAY)が、４.２.２.２章で指定された、
一般的な必要条件を満たすＰＨＢに投影するためにこれらのコードポイント
を予約します。
No attempt is made to maintain backwards compatibility with the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
「DTR」や、[RFC791]で定義されるＩＰｖ４のTOSオクテットのＴＯＳビット
との、バックワードコンパチビリティを維持する試みをしません。
4.1 A Default PHB
4.1 デフォルトＰＨＢ
A "default" PHB MUST be available in a DS-compliant node. This is
the common, best-effort forwarding behavior available in existing
routers as standardized in [RFC1812]. When no other agreements are
in place, it is assumed that packets belong to this aggregate. Such
packets MAY be sent into a network without adhering to any particular
rules and the network will deliver as many of these packets as
possible and as soon as possible, subject to other resource policy
constraints. A reasonable implementation of this PHB would be a
queueing discipline that sends packets of this aggregate whenever the
output link is not required to satisfy another PHB. A reasonable
policy for constructing services would ensure that the aggregate was
not "starved". This could be enforced by a mechanism in each node
that reserves some minimal resources (e.g, buffers, bandwidth) for
Default behavior aggregates. This permits senders that are not
differentiated services-aware to continue to use the network in the
same manner as today. The impact of the introduction of
differentiated services into a domain on the service expectations of
its customers and peers is a complex matter involving policy
decisions by the domain and is outside the scope of this document.
The RECOMMENDED codepoint for the Default PHB is the bit pattern '
000000'; the value '000000' MUST map to a PHB that meets these
specifications. The codepoint chosen for Default behavior is
compatible with existing practice [RFC791]. Where a codepoint is not
mapped to a standardized or local use PHB, it SHOULD be mapped to the
Default PHB.
「デフォルト」ＰＨＢがＤＳに従うノードで利用可能です(MUST)。これは
[RFC1812]で標準化された既存のルーターで利用可能な共通のベストエフォの
転送動作です。他のどのような規則もない時、パケットがこの対象に属する
と想定されます。このようなパケットは特定の規則なしにネットワーク内に
送られるかもしれず、ネットワークはできるだけ早く可能な限りこれらのパ
ケットを多くを配達し、他のリソースポリシーを受けさせるでしょう。この
ＰＨＢの合理的な実装は、出力リンクが他のＰＨＢを満足させるように要求
されない時はいつでも、このパケットを送るキー処理であるでしょう。サー
ビスを組み立てるための合理的なポリシーがパケットが「欠乏」しないこと
を保証するでしょう。これはデフォルト動作対象のためにある最小のリソー
ス（つまりバッファやバンド幅）を確保するそれぞれのノードでメカニズム
によって実施できます。これは区分サービスに気付いていない送り主が今と
同じ方法でネットワークを使い続けるのを許します。顧客とピアのサービス
の期待によるドメインへの区分サービスの導入の影響は、ドメインのポリシー
決定を巻き込む複雑な問題で、この文書の範囲の外です。デフォルトＰＨＢ
の推薦された(RECOMMENDED)コードポイントはビットパターン' 000000'です；
値' 000000'はこれらの仕様書を満たすＰＨＢにマッピングしなくてはなりま
せん(MUST)。デフォルト行動のコードポイントは既存の[RFC791]実装と両立
できます。コードポイントが標準又はローカルＰＨＢにマッピングできない
場合、これはデフォルトＰＨＢにマッピングプされるべきです(SHOULD)。
A packet initially marked for the Default behavior MAY be re-marked
with another codepoint as it passes a boundary into a DS domain so
that it will be forwarded using a different PHB within that domain,
possibly subject to some negotiated agreement between the peering
domains.
最初はデフォルト動作とマークが付いたパケットがＤＳドメインの境界を通
るために他のコードポイントのマークを付けられるかもしれません(MAY)、
このため多分隣り合ったドメイン間で合意された何かによって異なるドメ
インで異なるＰＨＢを使って転送されるでしょう。
4.2 Once and Future IP Precedence Field Use
4.2 過去と未来ののＩＰ優先フィールドの使い方
We wish to maintain some form of backward compatibility with present
uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet.
Routers exist that use the IP Precedence field to select different
per-hop forwarding treatments in a similar way to the use proposed
here for the DSCP field. Thus, a simple prototype differentiated
services architecture can be quickly deployed by appropriately
configuring these routers. Further, IP systems today understand the
location of the IP Precedence field, and thus if these bits are used
in a similar manner as DS-compliant equipment is deployed,
significant failures are not likely during early deployment. In
other words, strict DS-compliance need not be ubiquitous even within
a single service provider's network if bits 0-2 of the DSCP field are
employed in a manner similar to, or subsuming, the deployed uses of
the IP Precedence field.
我々はあるＩＰ優先フィールドの現在の使い方とのバックワードコンパチビ
リティを望みます：ＩＰｖ４のＴＯＳオクテットの０−２ビットです。ＩＰ
優先フィールドを使用して、ＤＳＣＰフィールドの目的同様に、異なるホッ
プ毎の転送の扱いをするルーターが存在します。そこで、単純なプロトタイ
プ区分サービスアーキテクチャは、これらのルーターの構成の設定で適切に
すぐ動作できます。さらに、今日のＩＰシステムが、ＩＰ優先フィールドの
位置と、これらのビットがＤＳに従っている装置の設定と同じ意味で使われ
た場合、意味の違いはすばやい設定に好ましくありません。言い換えれば、
ＤＳＣＰフィールドのビット０−２が同様に使われているか、ＩＰ優先フィー
ルドの使い方を包含しているなら、厳密なＤＳの遵守が１つのプロバイダー
ネットワーク内であっても全面的に存在する必要がありません。
4.2.1 IP Precedence History and Evolution in Brief
4.2.1 ＩＰの優先の歴史と進展の手短な説明
The IP Precedence field is something of a forerunner of the DS field.
IP Precedence, and the IP Precedence Field, were first defined in
[RFC791]. The values that the three-bit IP Precedence Field might
take were assigned to various uses, including network control
traffic, routing traffic, and various levels of privilege. The least
level of privilege was deemed "routine traffic". In [RFC791], the
notion of Precedence was defined broadly as "An independent measure
of the importance of this datagram." Not all values of the IP
Precedence field were assumed to have meaning across boundaries, for
instance "The Network Control precedence designation is intended to
be used within a network only. The actual use and control of that
designation is up to each network." [RFC791]
ＩＰ優先フィールドはＤＳフィールドの原型です。ＩＰ優先とＩＰ優先フィー
ルドは[RFC791]で最初に定義されました。３ビットのＩＰ優先フィールドが
とるかもしれない値は、ネットワーク制御トラフィック、ルーティングトラ
フィックを含めての、種々なレベルの特権の使用に割り当てられました。特
権の最少のレベルは「定常トラフィック」と見なされました。[RFC791]での
優先の考えはおおよそ「このデータグラムの重要性の独立した物差し」と定
義されました。ＩＰ優先フィールドの全ての値が境界を超えて有効とは考え
られてなく、「ネットワーク制御優先はネットワーク内のみで使われること
を意図されます。実際の使い方と指定の制御はネットワーク次第です。」
[RFC791]。
Although early BBN IMPs implemented the Precedence feature, early
commercial routers and UNIX IP forwarding code generally did not. As
networks became more complex and customer requirements grew,
commercial router vendors developed ways to implement various kinds
of queueing services including priority queueing, which were
generally based on policies encoded in filters in the routers, which
examined IP addresses, IP protocol numbers, TCP or UDP ports, and
other header fields. IP Precedence was and is among the options such
filters can examine.
初期のBBN IMPが優先機能を実装したが、初期の商用ルータとＵＮＩＸのＩＰ
転送コードが、一般に優先機能を持ちませんでした。ネットワークがいっそ
う複雑になり、ユーザ要求が成長するにつれ、商用ルーターのベンダーが様々
な種類のキューイングサービスを実装しました、これはルーターのＩＰアド
レスやＩＰプロトコル番号やＴＣＰポートやＵＤＰポートや他のフィールド
によるフィルターでコード化された優先キューを含みます。ＩＰ優先はこの
ようなフィルターが調べるオプションの一部です。
In short, IP Precedence is widely deployed and widely used, if not in
exactly the manner intended in [RFC791]. This was recognized in
[RFC1122], which states that while the use of the IP Precedence field
is valid, the specific assignment of the priorities in [RFC791] were
merely historical.
要するに、ＩＰ優先が、正確には[RFC791]が意図した方法ではないが、広く
実装され、広く使われています。これは[RFC1122]で認識され、ＩＰ優先フィー
ルドの使用は有効だが、[RFC791]の優先の特定の割当てが時代遅れだと述べ
ています。
4.2.2 Subsuming IP Precedence into Class Selector Codepoints
4.2.2 クラス選択コードポイントにＩＰ優先を包括
A specification of the packet forwarding treatments selected by the
IP Precedence field today would have to be quite general; probably
not specific enough to build predictable services from in the
differentiated services framework. To preserve partial backwards
compatibility with known current uses of the IP Precedence field
without sacrificing future flexibility, we have taken the approach of
describing minimum requirements on a set of PHBs that are compatible
with most of the deployed forwarding treatments selected by the IP
Precedence field. In addition, we give a set of codepoints that MUST
map to PHBs meeting these minimum requirements. The PHBs mapped to
by these codepoints MAY have a more detailed list of specifications
in addition to the required ones stated here. Other codepoints MAY
map to these same PHBs. We refer to this set of codepoints as the
Class Selector Codepoints, and the minimum requirements for PHBs that
these codepoints may map to are called the Class Selector PHB
Requirements.
今日のＩＰ優先フィールドで選ばれたパケット転送の扱いの仕様が非常に一
般的で、恐らく区分サービス機構で予測可能なサービスをするのに十分なほ
ど細かく指定しなければならないでしょう。将来の柔軟性を犠牲にせずに、
ＩＰ優先フィールドの周知の現在の使用とのバックワードコンパチビリティ
を維持するために、我々はＩＰ優先フィールドによって選ばれて設定された
転送処理の大部分と両立できるＰＨＢのセットの最小必要条件を記述するア
プローチをとりました。加えて、我々はこれらの最小条件を満たすＰＨＢに
マップする(MUST)コードポイントの集合を与えます。これらのコードポイン
トにマップされたＰＨＢは、ここで述べられた必要な仕様の他に、詳細なリ
ストを持つかもしれません(MAY)。他のコードポイントをこれらのＰＨＢに
マップしてもよいです(MAY)。我々はこのコードポイントの集合をクラス選
択コードポイントと述べ、これらのコードポイントをマップするかもしれな
いＰＨＢの最小条件はクラス選択ＰＨＢ条件と呼ばれます。
4.2.2.1 The Class Selector Codepoints
4.2.2.1 クラス選択コードポイント
A specification of the packet forwarding treatments selected by the
The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU
subfield unspecified, are reserved as a set of Class Selector
Codepoints. PHBs which are mapped to by these codepoints MUST
satisfy the Class Selector PHB requirements in addition to preserving
the Default PHB requirement on codepoint '000000' (Sec. 4.1).
ＤＳフィールド値の'xxx000|xx'かDSCP = 'xxx000'でCUフィールドが指定さ
れていないパケット転送処理の仕様が、クラス選択コードポイントの集合と
して、予約されます。これらのコードポイントにマップされるＰＨＢはクラ
ス選択ＰＨＢ条件を満たさなければならず、加えてコードポイント'000000'
はデフォルトＰＨＢ条件を維持しなければなりません(MUST)。
4.2.2.2 The Class Selector PHB Requirements
4.2.2.2 クラス選択ＰＨＢ条件
We refer to a Class Selector Codepoint with a larger numerical value
than another Class Selector Codepoint as having a higher relative
order while a Class Selector Codepoint with a smaller numerical value
than another Class Selector Codepoint is said to have a lower
relative order. The set of PHBs mapped to by the eight Class
Selector Codepoints MUST yield at least two independently forwarded
classes of traffic, and PHBs selected by a Class Selector Codepoint
SHOULD give packets a probability of timely forwarding that is not
lower than that given to packets marked with a Class Selector
codepoint of lower relative order, under reasonable operating
conditions and traffic loads. A discarded packet is considered to be
an extreme case of untimely forwarding. In addition, PHBs selected
by codepoints '11x000' MUST give packets a preferential forwarding
treatment by comparison to the PHB selected by codepoint '000000' to
preserve the common usage of IP Precedence values '110' and '111' for
routing traffic.
我々は他のクラス選択コードポイントより大きい数値のクラス選択コードポ
イントがより高い順位で、他のクラス選択コードポイントより小さい数値の
クラス選択コードポイントがより低い相対的な順位とのべます。８つのクラ
ス選択コードポイントにマッピングされるＰＨＢの集合が、少なくとも２つ
の独立したトラヒックの転送たクラスをもたらし(MUST)、合理的な運用とト
ラヒック下で、クラス選択コードポイントに選ばれたＰＨＢが低い順位のク
ラス選択コードポイントをマークされたパケットより多分タイムリーに転送
されすべきです(SHOULD)。パケット廃棄がタイムリーでない転送の極端な場
合と考えられます。加えて、ルーチングトラヒックのＩＰ優先値'110'と
'111'の値の一般的使用法を保存するため、コードポイント'11x000'によって
選択されたＰＨＢは、コードポイント'000000'によって選択されたＰＨＢよ
り優先の転送扱いをされなければなりません(MUST)。
Further, PHBs selected by distinct Class Selector Codepoints SHOULD
be independently forwarded; that is, packets marked with different
Class Selector Codepoints MAY be re-ordered. A network node MAY
enforce limits on the amount of the node's resources that can be
utilized by each of these PHBs.
さらに、別のクラス選択コードポイントによって選択されたＰＨＢは独立し
て転送されるべきです(SHOULD)；すなわち、異なったクラス選択コードポイ
ントを指定したパケットの順序は変わるかもしれません(MAY)。ネットワーク
ノードがこれらのＰＨＢのそれぞれの利用できるノードのリソースの量の上
限を実施するかもしれません(MAY)。
PHB groups whose specification satisfy these requirements are
referred to as Class Selector Compliant PHBs.
条件を満たす仕様のＰＨＢグループが、クラス選択適合ＰＨＢと述べられま
す。
The Class Selector PHB Requirements on codepoint '000000' are
compatible with those listed for the Default PHB in Sec. 4.1.
コードポイント'000000'のクラス選択ＰＨＢ条件は４.１章のデフォルトＰＨ
Ｂでリストアップされたのと両立できます。
4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence
Compatibility
4.2.2.3 ＩＰ優先互換性のためのクラス選択ＰＨＢ条件
A DS-compliant network node can be deployed with a set of one or more
Class Selector Compliant PHB groups. This document states that the
set of codepoints 'xxx000' MUST map to such a set of PHBs. As it is
also possible to map multiple codepoints to the same PHB, the vendor
or the network administrator MAY configure the network node to map
codepoints to PHBs irrespective of bits 3-5 of the DSCP field to
yield a network that is compatible with historical IP Precedence use.
Thus, for example, codepoint '011010' would map to the same PHB as
codepoint '011000'.
ＤＳに従っているネットワークノードが１つ以上のクラス選択適合ＰＨＢグ
ループの集合を実装できます。この書類はコードポイント'xxx000'の集合が
このようなＰＨＢの集合にマップしなくてはならないと述べます(MUST)。多
数のコードポイントを同じＰＨＢにマップすることが可能であるから、歴史
的のＩＰ優先と両立できるネットワークをもたらすため、ＤＳＣＰフィール
ドの３-５ビットにかかわらず、ベンダーあるいはネットワーク管理者がネッ
トワークノードがコードポイントをＰＨＢにマッピングするように設定する
かもしれません(MAY)。これで、例えば、コードポイント'011010'がコードポ
イント'011000'と同じＰＨＢにマッピングするでしょう。
4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant
PHB Groups
4.2.2.4 クラス選択適合ＰＨＢグループを実装するためのメカニズム例
Class Selector Compliant PHBs can be realized by a variety of
mechanisms, including strict priority queueing, weighted fair
queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based
Queuing [CBQ]. The distinction between PHBs and mechanisms is
described in more detail in Sec. 5.
クラス選択適合ＰＨＢは、厳密な優先キューイングや、重み付き公平キュー
イング（WFQ）や、WRRやその変形［RPS、HPFQA、DRR］や、クラスベースキュー
イングを含み、様々なメカニズムにより実現できます。ＰＨＢとメカニズム
の間の区別は５章でより詳細に記述されます。
It is important to note that these mechanisms might be available
through other PHBs (standardized or not) that are available in a
particular vendor's equipment. For example, future documents may
standardize a Strict Priority Queueing PHB group for a set of
recommended codepoints. A network administrator might configure
those routers to select the Strict Priority Queueing PHBs with
codepoints 'xxx000' in conformance with the requirements of this
document.
これらのメカニズムが、他の特定のベンダーの装置で利用可能なＰＨＢ（標
準化されてるか、されてない）を通して利用可能でかもしれないことを指摘
することは重要である。例えば、将来の文書が推薦されたコードポイントの
集合のために厳格な優先キューイングＰＨＢグループを標準化するかもしれ
ません。ネットワーク管理者がそれらのルーターをこの文書の条件に従って
いるコードポイント'xxx000'で厳密な優先権キューイングＰＨＢを選ぶよう
に設定するかもしれません。
As a further example, another vendor might employ a CBQ mechanism in
its routers. The CBQ mechanism could be used to implement the Strict
Priority Queueing PHBs as well as a set of Class Selector Compliant
PHBs with a wider range of features than would be available in a set
of PHBs that did no more than meet the minimum Class Selector PHB
requirements.
他の例として、他のベンダーがルーターでＣＢＱメカニズムを使用するかも
しれません。最小クラス選択ＰＨＢ条件を満たさないＰＨＢの集合で利用可
能である広い機能を持ったクラス選択適合ＰＨＢ集合と同様に、ＣＢＱメカ
ニズムは厳密な優先キューイングを実装するために使う事が可能です。
4.3 Summary
4.3 まとめ
This document defines codepoints 'xxx000' as the Class Selector
codepoints, where PHBs selected by these codepoints MUST meet the
Class Selector PHB Requirements described in Sec. 4.2.2.2. This is
done to preserve a useful level of backward compatibility with
current uses of the IP Precedence field in the Internet without
unduly limiting future flexibility. In addition, codepoint '000000'
is used as the Default PHB value for the Internet and, as such, is
not configurable. The remaining seven non-zero Class Selector
codepoints are configurable only to the extent that they map to PHBs
that meet the requirements in Sec. 4.2.2.2.
この文書はコードポイント'xxx000'をクラス選択コードポイントと定義し、
これらのコードポイントによって選択されたＰＨＢは４.２.２.２章で記述さ
れたクラス選択ＰＨＢ条件を満たさなくてはなりません(MUST)。これは将来
の柔軟性を大きく制限することなく、インターネットでＩＰ優先フィールド
の現在の使い方との間のバックワードコンパチビリティを維持するためにさ
れます。加えて、コードポイント'000000'がデフォルトＰＨＢ値としてイン
ターネットで使われ、これは設定可能ではありません。残りの７つの非ゼロ
のクラス選択コードポイントは、それらが４.２.２.２章の条件を満たすＰＨ
Ｂにマップする限りにおいてだけ、設定可能です。
5. Per-Hop Behavior Standardization Guidelines
5. ホップ毎の動作の標準化ガイドライン
The behavioral characteristics of a PHB are to be standardized, and
not the particular algorithms or the mechanisms used to implement
them. A node may have a (possibly large) set of parameters that can
be used to control how packets are scheduled onto an output interface
(e.g., N separate queues with settable priorities, queue lengths,
round-robin weights, drop algorithm, drop preference weights and
thresholds, etc). To illustrate the distinction between a PHB and a
mechanism, we point out that Class Selector Compliant PHBs might be
implemented by several mechanisms, including: strict priority
queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in
isolation or in combination.
ＰＨＢの行動の特徴は標準化されているはずで、特定のアルゴリズムあるい
はメカニズムが実装に使われません。ノードが出力インタフェースでどのよ
うにパケットをスケジューリングするか制御するために使う（多分たくさん
の）パラメータを持つかもしれません（例えば、優先と、キュー長と、ラウ
ンドロビンウエイトと、ドロップアルゴリズムと、ドロッププリファレンス
ウエイトと、閾値などを設定可能なＮ個のキュー）。ＰＨＢとメカニズムの
区別を例示するために、我々はクラス選択適合ＰＨＢがいくつかのメカニズ
ムで実装されるかもしれないことを指摘します、これは下記を含みます：厳
密な優先キューイングや、WFQや、WRRやその変形［HPFQA、RPS、DRR］や、
CBQ[CBQ]や、その一部や組合せ。
PHBs may be specified individually, or as a group (a single PHB is a
special case of a PHB group). A PHB group usually consists of a set
of two or more PHBs that can only be meaningfully specified and
implemented simultaneously, due to a common constraint applying to
each PHB within the group, such as a queue servicing or queue
management policy. A PHB group specification SHOULD describe
conditions under which a packet might be re-marked to select another
PHB within the group. It is RECOMMENDED that PHB implementations do
not introduce any packet re-ordering within a microflow. PHB group
specifications MUST identify any possible packet re-ordering
implications which may occur for each individual PHB, and which may
occur if different packets within a microflow are marked for
different PHBs within the group.
ＰＨＢは個々に、あるいはグループ（一人のＰＨＢがＰＨＢグループの特別
なケースである）として指定されるかもしれません。ＰＨＢグループが通常
２つ以上のＰＨＢから成り立ち、キューサービス提供やキュー管理ポリシー
のようなグループ内の各ＰＨＢに当てはまっている公共の制約のために、Ｐ
ＨＢは意味だけを指定され同時に実行できます。ＰＨＢグループ仕様は、グ
ループ内の他のＰＨＢを選択するためにパケットのマークを変える状態を記
述するべきです(SHOULD)。ＰＨＢ実装がマイクロフロー内のパケットの順序
を変えないことが勧められます(RECOMMENDED)。ＰＨＢグループ仕様はパケッ
トの順序の変更の可能性を認識しなければなりません(MUST)、これは各ＰＨ
Ｂで発生するかもしれないし、マイクロフロー内の異なるパケットに異なる
ＰＨＢのマークを付けて生じるかもしれません。
Only those per-hop behaviors that are not described by an existing
PHB standard, and have been implemented, deployed, and shown to be
useful, SHOULD be standardized. Since current experience with
differentiated services is quite limited, it is premature to
hypothesize the exact specification of these per-hop behaviors.
このような既存のＰＨＢ標準によって記述しなかったホップ毎の動作が、実
装され、配置され、標準化すべき(SHOULD)であることが明らかになりました。
区分サービスの現在の経験が非常に限定されているので、ホップ毎の正確な
動作指定を仮定するのは時期尚早である。
Each standardized PHB MUST have an associated RECOMMENDED codepoint,
allocated out of a space of 32 codepoints (see Sec. 6). This
specification has left room in the codepoint space to allow for
evolution, thus the defined space ('xxx000') is intentionally sparse.
それぞれの標準化されたＰＨＢに対して、３２のコードポイント（６章参照）
から、推薦された(RECOMMENDED)コードポイントを割当てなければなりません
(MUST)。この仕様書は発展を考慮してコードポイント空間の左に空領域を持
ち、そのため定義された空間（'xxx000'）は意図的にまばらです。
Network equipment vendors are free to offer whatever parameters and
capabilities are deemed useful or marketable. When a particular,
standardized PHB is implemented in a node, a vendor MAY use any
algorithm that satisfies the definition of the PHB according to the
standard. The node's capabilities and its particular configuration
determine the different ways that packets can be treated.
ネットワーク装置のベンダーは有用か、売り込みのため、どんなパラメータ
と能力でも申し出ることが自由です。特定の、標準化された PHB がノードに
実装される時、ベンダーが標準に従ってＰＨＢの定義を満足させるどんなア
ルゴリズムでも使ってもよいです(MAY)。ノードの能力とその特定の設定は
パケットが扱われることができる異なった方法を決定します。
Service providers are not required to use the same node mechanisms or
configurations to enable service differentiation within their
networks, and are free to configure the node parameters in whatever
way that is appropriate for their service offerings and traffic
engineering objectives. Over time certain common per-hop behaviors
are likely to evolve (i.e., ones that are particularly useful for
implementing end-to-end services) and these MAY be associated with
particular EXP/LU PHB codepoints in the DS field, allowing use across
domain boundaries (see Sec. 6). These PHBs are candidates for future
standardization.
サービスプロバイダがネットワークの中でサービス分化を可能にするために
同じノードメカニズムあるいは設定を使うように要求されず、それらのサー
ビス提供とトラフィックエンジニアリング目的に適切などんな方法でノード
パラメータを設定しても自由です。時を超えてある特定の共通のホップ毎の
行動が進展する可能性が高く（すなわち、エンドエンドサービスをするのに
特に役立つもの）、これらはＤＳフィールドの特定のEXP/LU ＰＨＢコードポ
イントと結び付けられるかもしれず、ドメイン境界を超えて使用できます
（６章参照）。これらのＰＨＢは未来の標準化の候補です。
It is RECOMMENDED that standardized PHBs be specified in accordance
with the guidelines set out in [ARCH].
標準化されたＰＨＢが[ARCH]で明らかにされたガイドラインのとおりに指定
されることは勧められます(RECOMMENDED)。
6. IANA Considerations
6. ＩＡＮＡの考慮
The DSCP field within the DS field is capable of conveying 64
distinct codepoints. The codepoint space is divided into three pools
for the purpose of codepoint assignment and management: a pool of 32
RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as
defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved
for experimental or Local Use (EXP/LU) as defined in [CONS], and a
pool of 16 codepoints (Pool 3) which are initially available for
experimental or local use, but which should be preferentially
utilized for standardized assignments if Pool 1 is ever exhausted.
The pools are defined in the following table (where 'x' refers to
either '0' or '1'):
ＤＳフィールド中のＤＳＣＰフィールドは６４の別のコードポイントを運ぶ
ことができます。コードポイント空間はコードポイント割当てと管理の目的
のために３つのプールに分けられます：３２の推薦(RECOMMENDED)コードポイ
ント(Pool 1)は、[CONS]で定義されるように標準行動で割り当てられ、１６
のコードポイント(Pool 2)は、[CONS]で定義されるように実験かローカルな
利用に予約され、１６のコードポイント(Pool 3)は、当初は実験やローカル
な利用に使えるが、Pool1が使い尽くされたら、標準割当てに優先的に使用さ
れます。プールは次のテーブルで定義されます('x'は'0'か'1'です)：
Pool Codepoint space Assignment Policy
プール コードポイント空間 割当てポリシー
---- --------------- -----------------
1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)
(*) may be utilized for future Standards Action allocations as
necessary
(*) は必要な未来の標準行動割り当て利用されるかもしれません。
This document assigns eight RECOMMENDED codepoints ('xxx000') which
are drawn from Pool 1 above. These codepoints MUST be mapped, not to
specific PHBs, but to PHBs that meet "at least" the requirements set
forth in Sec. 4.2.2.2 to provide a minimal level of backwards
compatibility with IP Precedence as defined in [RFC791] and as
deployed in some current equipment.
この文書は上記Pool 1から８つの推薦(RECOMMENDED)コードポイント
('xxx000')を割り当てます。これらのコードポイントは、特定のＰＨＢにマッ
プするのではなく、しかし[RFC791]の定義と現在の装置で実装されているの
との最小限のバックワードコンパチビリティを持つため、「少なくとも」
４.２.２.２章の条件に一致するＰＨＢにマップします(MUST)。
7. Security Considerations
7. セキュリティの考察
This section considers security issues raised by the introduction of
differentiated services, primarily the potential for denial-of-
service attacks, and the related potential for theft of service by
unauthorized traffic (Section 7.1). Section 7.2 addresses the
operation of differentiated services in the presence of IPsec
including its interaction with IPsec tunnel mode and other tunnelling
protocols. See [ARCH] for more extensive treatment of the security
concerns raised by the overall differentiated services architecture.
この章は区分サービスの導入によって発生するセキュリティの問題を考えま
す、主にサービス否定攻撃の可能性と無許可トラフィックがサービスを盗む
可能性を考えます（７.１章）。７.２章は、ＩＰｓｅｃトンネルモードと他
のトンネルを堀るプロトコルを含め、ＩＰｓｅｃでの区分サービスのオペレー
ションを扱います。全体的な区分サービスアーキテクチャによって生じるセ
キュリティの考察のより大規模な扱いについては[ARCH]を見てください。
7.1 Theft and Denial of Service
7.1 盗みとサービス否定
The primary goal of differentiated services is to allow different
levels of service to be provided for traffic streams on a common
network infrastructure. A variety of techniques may be used to
achieve this, but the end result will be that some packets receive
different (e.g., better) service than others. The mapping of network
traffic to the specific behaviors that result in different (e.g.,
better or worse) service is indicated primarily by the DS codepoint,
and hence an adversary may be able to obtain better service by
modifying the codepoint to values indicating behaviors used for
enhanced services or by injecting packets with such codepoint values.
Taken to its limits, such theft-of-service becomes a denial-of-
service attack when the modified or injected traffic depletes the
resources available to forward it and other traffic streams.
区分サービスの主要なゴールは共通ネットワーク基礎構造上で異なるレベル
のサービスのトラフィックの流れの提供を許すことです。いろいろなテクニッ
クがこれを成し遂げるために使われるかもしれませんが、最終結果はあるパ
ケットが他と異なる（例えば良い）サービスを受ける事でしょう。ネットワー
クトラヒックを異なるサービス（例えば、良いとか悪いとか）を生じる特定
の動作へマッピングするのは主にＤＳコードポイントによって主に示されま
す、それで敵が値が強化されたサービスに使われる動作を示すコードポイン
トへ修正することで、あるいはこのようなコードポイント値のパケットを乗
せかえることで、良いサービスを得ることが可能でかもしれません。これを
制限すると、サービスを盗むことは、修正や注射されたトラフィックの転送
によりアクセス可能なリソースが使い果たされる時、他のトラフィックスト
リームに対して「サービスの否認」攻撃になります。
The defense against this class of theft- and denial-of-service
attacks consists of the combination of traffic conditioning at DS
domain boundaries with security and integrity of the network
infrastructure within a DS domain. DS domain boundary nodes MUST
ensure that all traffic entering the domain is marked with codepoint
values appropriate to the traffic and the domain, remarking the
traffic with new codepoint values if necessary. These DS boundary
nodes are the primary line of defense against theft- and denial-of-
service attacks based on modified codepoints, as success of any such
attack indicates that the codepoints used by the attacking traffic
were inappropriate. An important instance of a boundary node is that
any traffic-originating node within a DS domain is the initial
boundary node for that traffic. Interior nodes in a DS domain rely
on DS codepoints to associate traffic with the forwarding PHBs, and
are NOT REQUIRED to check codepoint values before using them. As a
result, the interior nodes depend on the correct operation of the DS
domain boundary nodes to prevent the arrival of traffic with
inappropriate codepoints or in excess of provisioned levels that
would disrupt operation of the domain.
サービス盗難とサービス否認攻撃に対する防御は、ＤＳ境界でのトラヒック
を整えるのと、ＤＳドメインのネットワークインフラのセキュリティと完全
性の組合せから成り立ちます。ＤＳドメイン境界ノードは、すべてのドメイ
ンに入るトラヒックに適切なコードポイントを付けて、もし必要なら新しい
コードポイント値をトラフィックに付けることを保証しなくてはなりません
(MUST)。これらのＤＳ境界線ノードは修正されたコードポイントに基づくサー
ビス盗難とサービス否認攻撃に対しする主要な防衛線で、このような攻撃の
成功は攻撃しているトラフィックにの使うコードポイントが不適当であった
ことを示します。境界線ノードの重要な事実はＤＳドメインのトラフィック
の出発点ノードは、そのトラフィックの最初の境界ノードだということです。
ＤＳドメインの内部のノードが、ＤＳコードポイントでトラフィックを転送
ＰＨＢと結び付ける前に、コードポイント値を検査するように要求されませ
ん(NOT REQUIRED)。結果として、内部のノードはＤＳドメイン境界ノードで
不適当なコードポイントの到着を防ぐ正しい操作や、ドメインの運用を混乱
させるでレベルのトラヒックの到着を妨ぐ正しい操作に依存します。
7.2 IPsec and Tunnelling Interactions
7.2 ＩＰｓｅｃとトンネルの相互作用
The IPsec protocol, as defined in [ESP, AH], does not include the IP
header's DS field in any of its cryptographic calculations (in the
case of tunnel mode, it is the outer IP header's DS field that is not
included). Hence modification of the DS field by a network node has
no effect on IPsec's end-to-end security, because it cannot cause any
IPsec integrity check to fail. As a consequence, IPsec does not
provide any defense against an adversary's modification of the DS
field (i.e., a man-in-the-middle attack), as the adversary's
modification will also have no effect on IPsec's end-to-end security.
[ESP, AH]で定義されるようにＩＰｓｅｃプロトコルは、暗号の計算にＩＰヘッ
ダーのＤＳフィールドを含みません（トンネルモードの場合、外側のＩＰヘッ
ダのＤＳフィールドが含まない）。それ故ネットワークノードによるＤＳフィー
ルドの修正はＩＰｓｅｃのエンドエンドセキュリティに対する影響を与えませ
ん、なぜならこれはＩＰｓｅｃ完全性検査を失敗させませんから。結果として、
敵の修正がＩＰｓｅｃエンドエンドセキュリティに影響がないように、
ＩＰｓｅｃは敵がＤＳフィールドを修正する（中間者による攻撃）際に防衛を
供給しません。
IPsec's tunnel mode provides security for the encapsulated IP
header's DS field. A tunnel mode IPsec packet contains two IP
headers: an outer header supplied by the tunnel ingress node and an
encapsulated inner header supplied by the original source of the
packet. When an IPsec tunnel is hosted (in whole or in part) on a
differentiated services network, the intermediate network nodes
operate on the DS field in the outer header. At the tunnel egress
node, IPsec processing includes removing the outer header and
forwarding the packet (if required) using the inner header. The
IPsec protocol REQUIRES that the inner header's DS field not be
changed by this decapsulation processing to ensure that modifications
to the DS field cannot be used to launch theft- or denial-of-service
attacks across an IPsec tunnel endpoint. This document makes no
change to that requirement. If the inner IP header has not been
processed by a DS boundary node for the tunnel egress node's DS
domain, the tunnel egress node is the boundary node for traffic
exiting the tunnel, and hence MUST ensure that the resulting traffic
has appropriate DS codepoints.
ＩＰｓｅｃのトンネルモードはカプセル化されるＩＰヘッダーのＤＳフィー
ルドにセキュリティを提供します。トンネルモードＩＰｓｅｃパケットが２
つのＩＰヘッダーを含みます：トンネル入口ノードの生成した外のヘッダー
とカプセル化されるオリジナルのパケット送信者の生成した奥のヘッダーで
す。ＩＰｓｅｃトンネルが区分サービスネットワークの上で（全部あるいは
部分的に）実施されている時、中間ネットワークノードは外のヘッダーのＤ
Ｓフィールドで動作します。トンネルの出口ノードが外のヘッダを削除して、
ＩＰｓｅｃ処理が（もし必要なら）奥のヘッダーを使ってパケットを転送し
ます。ＤＳフィールドへの修正がＩＰｓｅｃトンネル終端の向こう側でサー
ビス盗難やサービス否認攻撃の始動に使われないことを保証するために、
ＩＰｓｅｃプロトコルは奥のヘッダーのＤＳフィールドがカプセルを解く処
理で変更されないことを要求します。この文書はその条件に対する変更をし
ません。もし奥のＩＰヘッダーがトンネル出口ノードのＤＳドメインのＤＳ
境界線ノードによって処理されなかったなら、トンネル出口ノードはトンネ
ルを出たトラフィックの境界線ノードであり、それ故結果として生じるトラ
フィックが適切なＤＳコードポイントを持つことを保証しなくてはなりませ
ん(MUST)。
When IPsec tunnel egress decapsulation processing includes a
sufficiently strong cryptographic integrity check of the encapsulated
packet (where sufficiency is determined by local security policy),
the tunnel egress node can safely assume that the DS field in the
inner header has the same value as it had at the tunnel ingress node.
An important consequence is that otherwise insecure links within a DS
domain can be secured by a sufficiently strong IPsec tunnel. This
analysis and its implications apply to any tunnelling protocol that
performs integrity checks, but the level of assurance of the inner
header's DS field depends on the strength of the integrity check
performed by the tunnelling protocol. In the absence of sufficient
assurance for a tunnel that may transit nodes outside the current DS
domain (or is otherwise vulnerable), the encapsulated packet MUST be
treated as if it had arrived at a boundary from outside the DS
domain.
ＩＰｓｅｃトンネル出口のカプセルを解く処理に（ローカルなセキュリティ
ポリシーによって決定される）カプセル化パケットの十分に強い暗号の完全
性検査を含む時、トンネル出口ノードは安全に奥のヘッダーのＤＳフィール
ドがトンネル入口ノードであったのと同じ値を持つと想定できます。重要な
結果は、ＤＳドメイン内の不安定なリンクでも十分に強いＩＰｓｅｃトンネ
ルによって安全が保てるということです。この分析と意味は完全性検査を実
行するどんなトンネルを堀るプロトコルにも当てはまります、しかし奥のヘッ
ダーのＤＳフィールドの安全レベルはトンネルを堀るプロトコルによって実
行された完全性チェックの力に依存します。十分な信頼性の欠如で現在の
ＤＳドメイン外のノードを横断する（か攻撃されやすい）トンネルでは、カ
プセル化パケットはＤＳドメインの外から境界に到着したかのように扱われ
なくてはなりません(MUST)。
8. Acknowledgements
8. 謝辞
The authors would like to acknowledge the Differentiated Services
Working Group for discussions which helped shape this document.
著者は区分サービスワークグループに対してこの文書を作るのに手伝った論
議への感謝の意を表したいです。
9. References
9. 参考文献
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October
1998.
[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing
using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1122] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: A
Design Methodology for Fair Queueing Algorithms", IEEE/
ACM Trans. on Networking, April 1998.
Authors' Addresses
著者のアドレス
Kathleen Nichols
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: +1-408-525-4857
EMail: kmn@cisco.com
Steven Blake
Torrent Networking Technologies
3000 Aerial Center, Suite 140
Morrisville, NC 27560
Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.com
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, CA 93111
Phone: +1-408-526-4257
EMail: fred@cisco.com
David L. Black
EMC Corporation
35 Parkwood Drive
Hopkinton, MA 01748
Phone: +1-508-435-1000 x76140
EMail: black_david@emc.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (1998). 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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。