[要約] RFC 2475は、異なるサービスを提供するためのアーキテクチャを定義しており、QoS（Quality of Service）の実装を支援する。このRFCの目的は、ネットワークトラフィックの優先順位付けと制御を可能にし、リソースの効果的な利用を促進することである。
Network Working Group S. Blake
Request for Comments: 2475 Torrent Networking Technologies
Category: Informational D. Black
EMC Corporation
M. Carlson
Sun Microsystems
E. Davies
Nortel UK
Z. Wang
Bell Labs Lucent Technologies
W. Weiss
Lucent Technologies
December 1998
An Architecture for Differentiated Services
差別化されたサービスのアーキテクチャ
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.
このドキュメントでは、インターネットでスケーラブルなサービスの差別化を実装するためのアーキテクチャを定義しています。このアーキテクチャは、DSフィールド[DSFIELD]を使用したIP層パケットマーキングによって伝達されるトラフィック分類状態を集約することにより、スケーラビリティを実現します。パケットは、パスに沿ったノードで特定のホップごとの転送動作を受信するように分類およびマークされます。高度な分類、マーキング、ポリシング、およびシェーピング操作は、ネットワーク境界またはホストでのみ実装する必要があります。ネットワークリソースは、サービスプロビジョニングポリシーによってトラフィックストリームに割り当てられます。このポリシーは、差別化されたサービス対応ネットワークへのエントリ時にトラフィックがどのようにマークおよび条件付けされるか、およびそのネットワーク内でのトラフィックの転送方法を制御します。これらの構成要素の上にさまざまなサービスを実装できます。
Table of Contents
目次
1. Introduction ................................................. 2
1.1 Overview ................................................. 2
1.2 Terminology ............................................... 4
1.3 Requirements .............................................. 8
1.4 Comparisons with Other Approaches ......................... 9
2. Differentiated Services Architectural Model .................. 12
2.1 Differentiated Services Domain ............................ 12
2.1.1 DS Boundary Nodes and Interior Nodes .................. 12
2.1.2 DS Ingress Node and Egress Node ....................... 13
2.2 Differentiated Services Region ............................ 13
2.3 Traffic Classification and Conditioning ................... 14
2.3.1 Classifiers ........................................... 14
2.3.2 Traffic Profiles ...................................... 15
2.3.3 Traffic Conditioners .................................. 15
2.3.3.1 Meters ............................................ 16
2.3.3.2 Markers ........................................... 16
2.3.3.3 Shapers ........................................... 17
2.3.3.4 Droppers .......................................... 17
2.3.4 Location of Traffic Conditioners and MF Classifiers ... 17
2.3.4.1 Within the Source Domain .......................... 17
2.3.4.2 At the Boundary of a DS Domain .................... 18
2.3.4.3 In non-DS-Capable Domains ......................... 18
2.3.4.4 In Interior DS Nodes .............................. 19
2.4 Per-Hop Behaviors ......................................... 19
2.5 Network Resource Allocation ............................... 20
3. Per-Hop Behavior Specification Guidelines .................... 21
4. Interoperability with Non-Differentiated Services-Compliant
Nodes ........................................................ 25
5. Multicast Considerations ..................................... 26
6. Security and Tunneling Considerations ........................ 27
6.1 Theft and Denial of Service ............................... 28
6.2 IPsec and Tunneling Interactions .......................... 30
6.3 Auditing .................................................. 32
7. Acknowledgements ............................................. 32
8. References ................................................... 33
Authors' Addresses ............................................... 34
Full Copyright Statement ......................................... 36
This document defines an architecture for implementing scalable service differentiation in the Internet. A "Service" defines some significant characteristics of packet transmission in one direction across a set of one or more paths within a network. These characteristics may be specified in quantitative or statistical terms of throughput, delay, jitter, and/or loss, or may otherwise be specified in terms of some relative priority of access to network resources. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service.
このドキュメントでは、インターネットでスケーラブルなサービスの差別化を実装するためのアーキテクチャを定義しています。 「サービス」は、ネットワーク内の1つまたは複数のパスのセットにわたる一方向のパケット送信のいくつかの重要な特性を定義します。これらの特性は、スループット、遅延、ジッター、および/または損失の定量的または統計的な用語で指定されるか、ネットワークリソースへのアクセスの相対的な優先順位によって指定されます。異種のアプリケーション要件とユーザーの期待に対応し、インターネットサービスの差別化された価格設定を可能にするために、サービスの差別化が望まれます。
This architecture is composed of a number of functional elements implemented in network nodes, including a small set of per-hop forwarding behaviors, packet classification functions, and traffic conditioning functions including metering, marking, shaping, and policing. This architecture achieves scalability by implementing complex classification and conditioning functions only at network boundary nodes, and by applying per-hop behaviors to aggregates of traffic which have been appropriately marked using the DS field in the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to permit a reasonably granular means of allocating buffer and bandwidth resources at each node among competing traffic streams. Per-application flow or per-customer forwarding state need not be maintained within the core of the network. A distinction is maintained between:
このアーキテクチャは、ネットワークノードに実装された多数の機能要素で構成されます。これには、ホップごとの転送動作、パケット分類機能、およびメータリング、マーキング、シェーピング、ポリシングなどのトラフィック調整機能が含まれます。このアーキテクチャは、ネットワーク境界ノードでのみ複雑な分類と調整機能を実装し、IPv4またはIPv6ヘッダーのDSフィールドを使用して適切にマークされたトラフィックの集約にホップごとの動作を適用することによって、スケーラビリティを実現します[DSFIELD]。ホップごとの動作は、競合するトラフィックストリーム間で各ノードにバッファと帯域幅リソースを割り当てるきめ細かい手段を可能にするように定義されています。アプリケーションごとのフローまたは顧客ごとの転送状態をネットワークのコア内で維持する必要はありません。以下の違いが維持されます。
o the service provided to a traffic aggregate,
o トラフィック集合体に提供されるサービス
o the conditioning functions and per-hop behaviors used to realize services,
o サービスの実現に使用されるコンディショニング機能とホップごとの動作、
o the DS field value (DS codepoint) used to mark packets to select a per-hop behavior, and
o パケットにマークを付けてホップごとの動作を選択するために使用されるDSフィールド値（DSコードポイント）、および
o the particular node implementation mechanisms which realize a per-hop behavior.
o ホップごとの動作を実現する特定のノード実装メカニズム。
Service provisioning and traffic conditioning policies are sufficiently decoupled from the forwarding behaviors within the network interior to permit implementation of a wide variety of service behaviors, with room for future expansion.
サービスプロビジョニングおよびトラフィックコンディショニングポリシーは、ネットワーク内部の転送動作から十分に分離されているため、将来の拡張の余地があるさまざまなサービス動作を実装できます。
This architecture only provides service differentiation in one direction of traffic flow and is therefore asymmetric. Development of a complementary symmetric architecture is a topic of current research but is outside the scope of this document; see for example [EXPLICIT].
このアーキテクチャは、トラフィックフローの一方向のみでサービスの差別化を提供するため、非対称です。補完的な対称アーキテクチャの開発は現在の研究のトピックですが、このドキュメントの範囲外です。たとえば、[EXPLICIT]を参照してください。
Sect. 1.2 is a glossary of terms used within this document. Sec. 1.3 lists requirements addressed by this architecture, and Sec. 1.4 provides a brief comparison to other approaches for service differentiation. Sec. 2 discusses the components of the architecture in detail. Sec. 3 proposes guidelines for per-hop behavior specifications. Sec. 4 discusses interoperability issues with nodes and networks which do not implement differentiated services as defined in this document and in [DSFIELD]. Sec. 5 discusses issues with multicast service delivery. Sec. 6 addresses security and tunnel considerations.
宗派。 1.2は、このドキュメントで使用されている用語集です。 Sec。 1.3は、このアーキテクチャで対応する要件と、Sec。 1.4は、サービスの差別化のための他のアプローチとの簡単な比較を提供します。 Sec。 2では、アーキテクチャのコンポーネントについて詳しく説明します。 Sec。 3は、ホップごとの動作仕様のガイドラインを提案します。 Sec。 4では、このドキュメントと[DSFIELD]で定義されている差別化されたサービスを実装していないノードとネットワークとの相互運用性の問題について説明します。 Sec。 5では、マルチキャストサービス配信の問題について説明します。 Sec。 6は、セキュリティとトンネルの考慮事項を扱います。
This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of this document.
このセクションでは、このドキュメントで使用されている用語の一般的な概念の概要を示します。これらの用語のいくつかは、このドキュメントの後のセクションでより正確に定義されています。
Behavior Aggregate (BA) a DS behavior aggregate.
動作集約（BA）DS動作集約。
BA classifier a classifier that selects packets based only on the contents of the DS field.
BA分類子は、DSフィールドの内容のみに基づいてパケットを選択する分類子です。
Boundary link a link connecting the edge nodes of two domains.
境界リンク2つのドメインのエッジノードを接続するリンク。
Classifier an entity which selects packets based on the content of packet headers according to defined rules.
分類子定義されたルールに従ってパケットヘッダーの内容に基づいてパケットを選択するエンティティ。
DS behavior aggregate a collection of packets with the same DS codepoint crossing a link in a particular direction.
DSの動作は、特定の方向でリンクを通過する同じDSコードポイントを持つパケットのコレクションを集約します。
DS boundary node a DS node that connects one DS domain to a node either in another DS domain or in a domain that is not DS-capable.
DS境界ノードとは、あるDSドメインを別のDSドメインまたはDSに対応していないドメイン内のノードに接続するDSノードです。
DS-capable capable of implementing differentiated services as described in this architecture; usually used in reference to a domain consisting of DS-compliant nodes.
このアーキテクチャで説明されているように、差別化されたサービスを実装できるDS対応。通常、DS準拠のノードで構成されるドメインを参照して使用されます。
DS codepoint a specific value of the DSCP portion of the DS field, used to select a PHB.
DSコードポイントは、PHBの選択に使用されるDSフィールドのDSCP部分の特定の値です。
DS-compliant enabled to support differentiated services functions and behaviors as defined in [DSFIELD], this document, and other differentiated services documents; usually used in reference to a node or device.
[DSFIELD]、このドキュメント、およびその他の差別化されたサービスのドキュメントで定義されている差別化されたサービスの機能と動作をサポートするためにDSに対応。通常、ノードまたはデバイスを参照するために使用されます。
DS domain a DS-capable domain; a contiguous set of nodes which operate with a common set of service provisioning policies and PHB definitions.
DSドメインDS対応ドメイン。一連の共通のサービスプロビジョニングポリシーとPHB定義で動作する一連のノード。
DS egress node a DS boundary node in its role in handling traffic as it leaves a DS domain.
DS出力ノードは、DSドメインを離れるときにトラフィックを処理する役割を持つDS境界ノードです。
DS ingress node a DS boundary node in its role in handling traffic as it enters a DS domain.
DS入力ノードは、DSドメインに入るときにトラフィックを処理する役割を持つDS境界ノードです。
DS interior node a DS node that is not a DS boundary node.
DS内部ノードDS境界ノードではないDSノード。
DS field the IPv4 header TOS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in [DSFIELD]. The bits of the DSCP field encode the DS codepoint, while the remaining bits are currently unused.
[DSFIELD]で与えられた定義に従って解釈された場合、DSはIPv4ヘッダーのTOSオクテットまたはIPv6トラフィッククラスオクテットをフィールドします。 DSCPフィールドのビットはDSコードポイントをエンコードしますが、残りのビットは現在使用されていません。
DS node a DS-compliant node.
DSノードはDS準拠のノードです。
DS region a set of contiguous DS domains which can offer differentiated services over paths across those DS domains.
DSリージョンは、一連の連続したDSドメインのセットです。これらのDSドメインは、それらのDSドメイン間のパスを介して差別化されたサービスを提供できます。
Downstream DS domain the DS domain downstream of traffic flow on a boundary link.
ダウンストリームDSドメイン境界リンク上のトラフィックフローのDSドメインダウンストリーム。
Dropper a device that performs dropping.
ドロッパードロップを実行するデバイス。
Dropping the process of discarding packets based on specified rules; policing.
指定されたルールに基づいてパケットを破棄するプロセスを削除します。ポリシング。
Legacy node a node which implements IPv4 Precedence as defined in [RFC791,RFC1812] but which is otherwise not DS-compliant.
レガシーノードは、[RFC791、RFC1812]で定義されているようにIPv4 Precedenceを実装するが、それ以外の場合はDSに準拠しないノードです。
Marker a device that performs marking.
マーカーマーキングを実行するデバイス。
Marking the process of setting the DS codepoint in a packet based on defined rules; pre-marking, re-marking.
定義されたルールに基づいて、DSコードポイントをパケットに設定するプロセスをマークします。事前マーキング、再マーキング。
Mechanism a specific algorithm or operation (e.g., queueing discipline) that is implemented in a node to realize a set of one or more per-hop behaviors.
1つ以上のホップごとの動作のセットを実現するためにノードに実装されている特定のアルゴリズムまたは操作（キューイング規則など）のメカニズム。
Meter a device that performs metering.
計測を実行するデバイスを計測します。
Metering the process of measuring the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes.
分類子によって選択されたトラフィックストリームの一時的なプロパティ（たとえば、レート）を測定するプロセスを測定します。このプロセスの瞬間的な状態は、マーカー、シェイパー、またはスポイトの動作に影響を与えるために使用することができ、および/または会計および測定の目的で使用することができます。
Microflow a single instance of an application-to-application flow of packets which is identified by source address, source port, destination address, destination port and protocol id.
Microflowは、パケットのアプリケーション間フローの単一インスタンスであり、送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、およびプロトコルIDによって識別されます。
MF Classifier a multi-field (MF) classifier which selects packets based on the content of some arbitrary number of header fields; typically some combination of source address, destination address, DS field, protocol ID, source port and destination port.
MF分類子は、任意の数のヘッダーフィールドの内容に基づいてパケットを選択するマルチフィールド（MF）分類子です。通常、送信元アドレス、宛先アドレス、DSフィールド、プロトコルID、送信元ポート、および宛先ポートのいくつかの組み合わせ。
Per-Hop-Behavior (PHB) the externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate.
Per-Hop-Behavior（PHB）は、DS準拠のノードでDS動作集約に適用される、外部から観察可能な転送動作です。
PHB 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. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group.
キューサービスやキュー管理ポリシーなどのセット内のすべてのPHBに共通の制約が適用されるため、PHBは、意味のある指定と実装のみが同時に可能な1つ以上のPHBのセットをグループ化します。 PHBグループは、関連する転送動作のセットを一緒に指定できるようにするサービスビルディングブロックを提供します（たとえば、4つのドロップ優先度）。単一のPHBは、PHBグループの特殊なケースです。
Policing the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile.
トラフィックプロファイルを適用する対応するメーターの状態に応じて、トラフィックストリーム内のパケットを（ドロッパーによって）廃棄するプロセスをポリシングします。
Pre-mark to set the DS codepoint of a packet prior to entry into a downstream DS domain.
ダウンマークDSドメインに入る前にパケットのDSコードポイントを設定する事前マーク。
Provider DS domain the DS-capable provider of services to a source domain.
プロバイダーDSドメインソースドメインへのサービスのDS対応プロバイダー。
Re-mark to change the DS codepoint of a packet, usually performed by a marker in accordance with a TCA.
再マーキングしてパケットのDSコードポイントを変更します。通常、TCAに従ってマーカーによって実行されます。
Service the overall treatment of a defined subset of a customer's traffic within a DS domain or end-to-end.
DSドメイン内またはエンドツーエンドでの顧客のトラフィックの定義されたサブセットの全体的な処理を処理します。
Service Level Agreement a service contract between a customer and a (SLA) service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another DS domain (upstream domain). A SLA may include traffic conditioning rules which constitute a TCA in whole or in part.
サービスレベルアグリーメントは、顧客と（SLA）サービスプロバイダーの間のサービス契約であり、顧客が受け取る必要のある転送サービスを指定します。顧客は、ユーザー組織（ソースドメイン）または別のDSドメイン（上流ドメイン）の場合があります。 SLAには、全体的または部分的にTCAを構成するトラフィック調整ルールが含まれる場合があります。
Service Provisioning a policy which defines how traffic Policy conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of services.
トラフィックポリシーコンディショナーをDS境界ノードで構成する方法と、トラフィックストリームをDS動作集約にマップして、さまざまなサービスを実現する方法を定義するポリシーをサービスプロビジョニングします。
Shaper a device that performs shaping.
シェーパーシェーピングを実行するデバイス。
Shaping the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile.
トラフィックストリーム内のパケットを遅延させるプロセスを形成し、定義されたトラフィックプロファイルに準拠させる。
Source domain a domain which contains the node(s) originating the traffic receiving a particular service.
ソースドメイン特定のサービスを受信するトラフィックを発信するノードを含むドメイン。
Traffic conditioner an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers. Traffic conditioners are typically deployed in DS boundary nodes only. A traffic conditioner may re-mark a traffic stream or may discard or shape packets to alter the temporal characteristics of the stream and bring it into compliance with a traffic profile.
トラフィックコンディショナーは、トラフィック調整機能を実行するエンティティであり、メーター、マーカー、ドロッパー、およびシェーパーを含む場合があります。トラフィックコンディショナーは通常、DS境界ノードにのみ展開されます。トラフィックコンディショナーは、トラフィックストリームを再マーキングするか、パケットを破棄または形成して、ストリームの時間特性を変更し、トラフィックプロファイルに準拠させることができます。
Traffic conditioning control functions performed to enforce rules specified in a TCA, including metering, marking, shaping, and policing.
メータリング、マーキング、シェーピング、ポリシングなど、TCAで指定されたルールを実施するために実行されるトラフィック調整制御機能。
Traffic Conditioning an agreement specifying classifier rules Agreement (TCA) and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy.
クラシファイアルールアグリーメント（TCA）および対応するトラフィックプロファイルと、クラシファイアによって選択されたトラフィックストリームに適用されるメータリング、マーキング、破棄、シェーピングルールを指定するトラフィックコンディショニング。 TCAには、SLA内で明示的に指定されたすべてのトラフィック調整ルールと、関連するサービス要件やDSドメインのサービスプロビジョニングポリシーから暗黙的なすべてのルールが含まれます。
Traffic profile a description of the temporal properties of a traffic stream such as rate and burst size.
トラフィックプロファイルは、レートやバーストサイズなどのトラフィックストリームの一時的なプロパティの説明です。
Traffic stream an administratively significant set of one or more microflows which traverse a path segment. A traffic stream may consist of the set of active microflows which are selected by a particular classifier.
トラフィックは、パスセグメントを通過する1つ以上のマイクロフローの管理上重要なセットをストリーミングします。トラフィックストリームは、特定の分類子によって選択されるアクティブなマイクロフローのセットで構成されます。
Upstream DS domain the DS domain upstream of traffic flow on a boundary link.
アップストリームDSドメイン境界リンク上のトラフィックフローのDSドメインアップストリーム。
The history of the Internet has been one of continuous growth in the number of hosts, the number and variety of applications, and the capacity of the network infrastructure, and this growth is expected to continue for the foreseeable future. A scalable architecture for service differentiation must be able to accommodate this continued growth.
インターネットの歴史は、ホストの数、アプリケーションの数と種類、およびネットワークインフラストラクチャの容量の継続的な成長の1つであり、この成長は近い将来も続くと予想されます。サービスの差別化のためのスケーラブルなアーキテクチャは、この継続的な成長に対応できなければなりません。
The following requirements were identified and are addressed in this architecture:
次の要件が確認され、このアーキテクチャで対処されています。
o should accommodate a wide variety of services and provisioning policies, extending end-to-end or within a particular (set of) network(s),
o エンドツーエンドまたは特定の（セットの）ネットワーク内で拡張する、さまざまなサービスとプロビジョニングポリシーに対応する必要があります。
o should allow decoupling of the service from the particular application in use,
o 使用中の特定のアプリケーションからサービスを分離できるようにする必要があります。
o should work with existing applications without the need for application programming interface changes or host software modifications (assuming suitable deployment of classifiers, markers, and other traffic conditioning functions),
o アプリケーションプログラミングインターフェイスを変更したり、ホストソフトウェアを変更したりすることなく、既存のアプリケーションで機能する必要があります（分類子、マーカー、およびその他のトラフィック調整機能が適切に配置されている場合）。
o should decouple traffic conditioning and service provisioning functions from forwarding behaviors implemented within the core network nodes,
o トラフィック調整とサービスプロビジョニング機能を、コアネットワークノード内に実装された転送動作から切り離す必要があります。
o should not depend on hop-by-hop application signaling,
o ホップバイホップのアプリケーションシグナリングに依存すべきではありません。
o should require only a small set of forwarding behaviors whose implementation complexity does not dominate the cost of a network device, and which will not introduce bottlenecks for future high-speed system implementations,
o 実装の複雑さがネットワークデバイスのコストを支配せず、将来の高速システム実装にボトルネックを導入しない、少数の転送動作のみを必要とします。
o should avoid per-microflow or per-customer state within core network nodes,
o コアネットワークノード内のマイクロフローごとまたは顧客ごとの状態を回避する必要があります。
o should utilize only aggregated classification state within the network core,
o ネットワークコア内の集約された分類状態のみを使用する必要があります。
o should permit simple packet classification implementations in core network nodes (BA classifier),
o コアネットワークノードで単純なパケット分類の実装を許可する必要があります（BA分類子）、
o should permit reasonable interoperability with non-DS-compliant network nodes,
o DSに準拠していないネットワークノードとの妥当な相互運用性を許可する必要があります。
o should accommodate incremental deployment.
o 増分展開に対応する必要があります。
The differentiated services architecture specified in this document can be contrasted with other existing models of service differentiation. We classify these alternative models into the following categories: relative priority marking, service marking, label switching, Integrated Services/RSVP, and static per-hop classification.
このドキュメントで指定されている差別化サービスアーキテクチャは、他の既存のサービス差別化モデルと対照的です。これらの代替モデルは、相対優先順位マーキング、サービスマーキング、ラベルスイッチング、統合サービス/ RSVP、静的なホップごとの分類に分類されます。
Examples of the relative priority marking model include IPv4 Precedence marking as defined in [RFC791], 802.5 Token Ring priority [TR], and the default interpretation of 802.1p traffic classes [802.1p]. In this model the application, host, or proxy node selects a relative priority or "precedence" for a packet (e.g., delay or discard priority), and the network nodes along the transit path apply the appropriate priority forwarding behavior corresponding to the priority value within the packet's header. Our architecture can be considered as a refinement to this model, since we more clearly specify the role and importance of boundary nodes and traffic conditioners, and since our per-hop behavior model permits more general forwarding behaviors than relative delay or discard priority.
相対優先度マーキングモデルの例には、[RFC791]で定義されているIPv4 Precedenceマーキング、802.5トークンリング優先度[TR]、802.1pトラフィッククラスのデフォルト解釈[802.1p]が含まれます。このモデルでは、アプリケーション、ホスト、またはプロキシノードがパケットの相対的な優先度または「優先度」を選択し（たとえば、遅延または破棄の優先度）、トランジットパスに沿ったネットワークノードが、優先度の値に対応する適切な優先度転送動作を適用します。パケットのヘッダー内。境界ノードとトラフィックコンディショナーの役割と重要性をより明確に指定し、ホップごとの動作モデルでは、相対的な遅延や破棄の優先順位よりも一般的な転送動作を許可するため、このアーキテクチャはこのモデルの改良版と見なすことができます。
An example of a service marking model is IPv4 TOS as defined in [RFC1349]. In this example each packet is marked with a request for a "type of service", which may include "minimize delay", "maximize throughput", "maximize reliability", or "minimize cost". Network nodes may select routing paths or forwarding behaviors which are suitably engineered to satisfy the service request. This model is subtly different from our architecture. Note that we do not describe the use of the DS field as an input to route selection. The TOS markings defined in [RFC1349] are very generic and do not span the range of possible service semantics. Furthermore, the service request is associated with each individual packet, whereas some service semantics may depend on the aggregate forwarding behavior of a sequence of packets. The service marking model does not easily accommodate growth in the number and range of future services (since the codepoint space is small) and involves configuration of the "TOS->forwarding behavior" association in each core network node. Standardizing service markings implies standardizing service offerings, which is outside the scope of the IETF. Note that provisions are made in the allocation of the DS codepoint space to allow for locally significant codepoints which may be used by a provider to support service marking semantics [DSFIELD].
サービスマーキングモデルの例は、[RFC1349]で定義されているIPv4 TOSです。この例では、各パケットは、「遅延の最小化」、「スループットの最大化」、「信頼性の最大化」、または「コストの最小化」を含む「サービスの種類」の要求でマークされています。ネットワークノードは、サービス要求を満たすように適切に設計されたルーティングパスまたは転送動作を選択できます。このモデルは、私たちのアーキテクチャとは微妙に異なります。ルート選択への入力としてのDSフィールドの使用については説明していません。 [RFC1349]で定義されているTOSマーキングは非常に一般的であり、可能なサービスセマンティクスの範囲を超えていません。さらに、サービス要求は個々のパケットに関連付けられますが、一部のサービスセマンティクスは、一連のパケットの集約転送動作に依存する場合があります。サービスマーキングモデルは、（コードポイントスペースが小さいため）将来のサービスの数と範囲の増加に容易に対応できず、各コアネットワークノードでの「TOS->転送動作」の関連付けの構成を伴います。サービスマーキングの標準化は、サービス提供の標準化を意味します。これは、IETFの範囲外です。プロバイダーがサービスマーキングセマンティクスをサポートするために使用できるローカルで重要なコードポイントを許可するために、DSコードポイントスペースの割り当てでプロビジョニングが行われることに注意してください[DSFIELD]。
Examples of the label switching (or virtual circuit) model include Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model path forwarding state and traffic management or QoS state is established for traffic streams on each hop along a network path. Traffic aggregates of varying granularity are associated with a label switched path at an ingress node, and packets/cells within each label switched path are marked with a forwarding label that is used to lookup the next-hop node, the per-hop forwarding behavior, and the replacement label at each hop. This model permits finer granularity resource allocation to traffic streams, since label values are not globally significant but are only significant on a single link; therefore resources can be reserved for the aggregate of packets/ cells received on a link with a particular label, and the label switching semantics govern the next-hop selection, allowing a traffic stream to follow a specially engineered path through the network. This improved granularity comes at the cost of additional management and configuration requirements to establish and maintain the label switched paths. In addition, the amount of forwarding state maintained at each node scales in proportion to the number of edge nodes of the network in the best case (assuming multipoint-to-point label switched paths), and it scales in proportion with the square of the number of edge nodes in the worst case, when edge-edge label switched paths with provisioned resources are employed.
ラベルスイッチング（または仮想回線）モデルの例には、フレームリレー、ATM、MPLS [FRELAY、ATM]があります。このモデルでは、パス転送状態とトラフィック管理またはQoS状態が、ネットワークパス上の各ホップのトラフィックストリームに対して確立されます。さまざまな粒度のトラフィック集約は、入口ノードのラベルスイッチドパスに関連付けられており、各ラベルスイッチドパス内のパケット/セルは、ネクストホップノードの検索に使用される転送ラベルでマークされ、ホップごとの転送動作、各ホップの交換用ラベル。このモデルでは、ラベル値がグローバルに重要ではなく、単一のリンクでのみ重要であるため、トラフィックストリームへのリソースの割り当てをより細かく設定できます。したがって、特定のラベルが付いたリンクで受信されたパケット/セルの集合のためにリソースを予約でき、ラベルスイッチングセマンティクスがネクストホップの選択を管理し、トラフィックストリームがネットワークを介して特別に設計されたパスをたどることができます。この改善された細分性は、ラベルスイッチドパスを確立および維持するための追加の管理および構成要件を犠牲にしています。さらに、各ノードで維持される転送状態の量は、最良の場合（マルチポイントツーポイントラベルスイッチドパスを想定）に、ネットワークのエッジノードの数に比例してスケーリングされ、その値の2乗に比例してスケーリングされます。プロビジョニングされたリソースを使用するエッジエッジラベルスイッチドパスが使用される場合の最悪の場合のエッジノードの数。
The Integrated Services/RSVP model relies upon traditional datagram forwarding in the default case, but allows sources and receivers to exchange signaling messages which establish additional packet classification and forwarding state on each node along the path between them [RFC1633, RSVP]. In the absence of state aggregation, the amount of state on each node scales in proportion to the number of concurrent reservations, which can be potentially large on high-speed links. This model also requires application support for the RSVP signaling protocol. Differentiated services mechanisms can be utilized to aggregate Integrated Services/RSVP state in the core of the network [Bernet].
統合サービス/ RSVPモデルは、デフォルトのケースでは従来のデータグラム転送に依存していますが、送信元と受信者は、それらの間のパスに沿って各ノードで追加のパケット分類と転送状態を確立するシグナリングメッセージを交換できます[RFC1633、RSVP]。状態の集約がない場合、各ノードの状態の量は、同時予約の数に比例して増加します。これは、高速リンクでは潜在的に大きくなる可能性があります。このモデルでは、RSVPシグナリングプロトコルのアプリケーションサポートも必要です。差別化されたサービスメカニズムを利用して、ネットワークのコア[Bernet]の統合サービス/ RSVP状態を集約できます。
A variant of the Integrated Services/RSVP model eliminates the requirement for hop-by-hop signaling by utilizing only "static" classification and forwarding policies which are implemented in each node along a network path. These policies are updated on administrative timescales and not in response to the instantaneous mix of microflows active in the network. The state requirements for this variant are potentially worse than those encountered when RSVP is used, especially in backbone nodes, since the number of static policies that might be applicable at a node over time may be larger than the number of active sender-receiver sessions that might have installed reservation state on a node. Although the support of large numbers of classifier rules and forwarding policies may be computationally feasible, the management burden associated with installing and maintaining these rules on each node within a backbone network which might be traversed by a traffic stream is substantial.
統合サービス/ RSVPモデルのバリアントは、ネットワークパスに沿った各ノードに実装されている「静的」分類および転送ポリシーのみを利用することにより、ホップバイホップシグナリングの要件を排除します。これらのポリシーは、管理タイムスケールで更新され、ネットワークでアクティブなマイクロフローの瞬間的な混合には応答しません。このバリアントの状態要件は、特にバックボーンノードでRSVPを使用した場合に発生するものよりも悪い可能性があります。これは、ノードに長期間適用できる静的ポリシーの数が、アクティブな送受信セッションの数よりも多い可能性があるためです。ノードに予約状態をインストールした可能性があります。多数の分類ルールと転送ポリシーのサポートは計算上実現可能かもしれませんが、トラフィックストリームが通過する可能性のあるバックボーンネットワーク内の各ノードにこれらのルールをインストールして維持することに関連する管理の負担はかなりのものです。
Although we contrast our architecture with these alternative models of service differentiation, it should be noted that links and nodes employing these techniques may be utilized to extend differentiated services behaviors and semantics across a layer-2 switched infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones) interconnecting DS nodes, and in the case of MPLS may be used as an alternative intra-domain implementation technology. The constraints imposed by the use of a specific link-layer technology in particular regions of a DS domain (or in a network providing access to DS domains) may imply the differentiation of traffic on a coarser grain basis. Depending on the mapping of PHBs to different link-layer services and the way in which packets are scheduled over a restricted set of priority classes (or virtual circuits of different category and capacity), all or a subset of the PHBs in use may be supportable (or may be indistinguishable).
アーキテクチャをこれらのサービス差別化の代替モデルと対比していますが、これらの技術を使用するリンクとノードを利用して、差別化されたサービスの動作とセマンティクスをレイヤー2スイッチドインフラストラクチャ（802.1p LAN、フレームリレーなど）に拡張できることに注意してください。 / ATMバックボーン）DSノードを相互接続し、MPLSの場合は、ドメイン内の代替実装技術として使用できます。 DSドメインの特定の領域（またはDSドメインへのアクセスを提供するネットワーク）で特定のリンク層技術を使用することによって課せられる制約は、トラフィックをより細かく区別することを意味する場合があります。 PHBの異なるリンク層サービスへのマッピングと、制限された優先度クラスのセット（または異なるカテゴリと容量の仮想回線）でパケットがスケジュールされる方法に応じて、使用中のPHBのすべてまたはサブセットがサポートされる場合があります。 （または区別できない場合があります）。
The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single DS codepoint. Within the core of the network, packets are forwarded according to the per-hop behavior associated with the DS codepoint. In this section, we discuss the key components within a differentiated services region, traffic classification and conditioning functions, and how differentiated services are achieved through the combination of traffic conditioning and PHB-based forwarding.
差別化されたサービスアーキテクチャは、ネットワークに入るトラフィックが分類され、場合によってはネットワークの境界で条件付けされ、さまざまな動作集約に割り当てられる単純なモデルに基づいています。各動作集約は、単一のDSコードポイントによって識別されます。ネットワークのコア内では、DSコードポイントに関連付けられたホップごとの動作に従ってパケットが転送されます。このセクションでは、差別化サービスリージョン内の主要コンポーネント、トラフィックの分類と調整機能、およびトラフィック調整とPHBベースの転送の組み合わせによって差別化サービスを実現する方法について説明します。
A DS domain is a contiguous set of DS nodes which operate with a common service provisioning policy and set of PHB groups implemented on each node. A DS domain has a well-defined boundary consisting of DS boundary nodes which classify and possibly condition ingress traffic to ensure that packets which transit the domain are appropriately marked to select a PHB from one of the PHB groups supported within the domain. Nodes within the DS domain select the forwarding behavior for packets based on their DS codepoint, mapping that value to one of the supported PHBs using either the recommended codepoint->PHB mapping or a locally customized mapping [DSFIELD]. Inclusion of non-DS-compliant nodes within a DS domain may result in unpredictable performance and may impede the ability to satisfy service level agreements (SLAs).
DSドメインは、共通のサービスプロビジョニングポリシーと各ノードに実装されたPHBグループのセットで動作するDSノードの連続したセットです。 DSドメインには、ドメイン内をサポートするPHBグループの1つからPHBを選択するためにドメインを通過するパケットが適切にマークされるように、入力トラフィックを分類し、場合によっては条件付けするDS境界ノードで構成される明確な境界があります。 DSドメイン内のノードは、DSコードポイントに基づいてパケットの転送動作を選択し、推奨されるコードポイント-> PHBマッピングまたはローカルにカスタマイズされたマッピング[DSFIELD]を使用して、その値をサポートされるPHBの1つにマッピングします。 DSドメイン内に非DS準拠のノードを含めると、予測できないパフォーマンスが発生し、サービスレベルアグリーメント（SLA）を満たす機能が妨げられる場合があります。
A DS domain normally consists of one or more networks under the same administration; for example, an organization's intranet or an ISP. The administration of the domain is responsible for ensuring that adequate resources are provisioned and/or reserved to support the SLAs offered by the domain.
DSドメインは通常、同じ管理下にある1つ以上のネットワークで構成されます。たとえば、組織のイントラネットやISPなどです。ドメインの管理は、ドメインによって提供されるSLAをサポートするために適切なリソースがプロビジョニングおよび/または予約されることを保証する責任があります。
A DS domain consists of DS boundary nodes and DS interior nodes. DS boundary nodes interconnect the DS domain to other DS or non-DS-capable domains, whilst DS interior nodes only connect to other DS interior or boundary nodes within the same DS domain.
DSドメインは、DS境界ノードとDS内部ノードで構成されます。 DS境界ノードはDSドメインを他のDSまたは非DS対応ドメインに相互接続しますが、DS内部ノードは同じDSドメイン内の他のDS内部または境界ノードにのみ接続します。
Both DS boundary nodes and interior nodes must be able to apply the appropriate PHB to packets based on the DS codepoint; otherwise unpredictable behavior may result. In addition, DS boundary nodes may be required to perform traffic conditioning functions as defined by a traffic conditioning agreement (TCA) between their DS domain and the peering domain which they connect to (see Sec. 2.3.3).
DS境界ノードと内部ノードの両方が、DSコードポイントに基づいて適切なPHBをパケットに適用できる必要があります。そうしないと、予測できない動作が発生する可能性があります。さらに、DS境界ノードは、DSドメインと接続先のピアリングドメイン間のトラフィック調整合意（TCA）によって定義されたトラフィック調整機能を実行する必要がある場合があります（セクション2.3.3を参照）。
Interior nodes may be able to perform limited traffic conditioning functions such as DS codepoint re-marking. Interior nodes which implement more complex classification and traffic conditioning functions are analogous to DS boundary nodes (see Sec. 2.3.4.4).
内部ノードは、DSコードポイントの再マーキングなどの限られたトラフィック調整機能を実行できる場合があります。より複雑な分類およびトラフィック調整機能を実装する内部ノードは、DS境界ノードに類似しています（セクション2.3.4.4を参照）。
A host in a network containing a DS domain may act as a DS boundary node for traffic from applications running on that host; we therefore say that the host is within the DS domain. If a host does not act as a boundary node, then the DS node topologically closest to that host acts as the DS boundary node for that host's traffic.
DSドメインを含むネットワーク内のホストは、そのホストで実行されているアプリケーションからのトラフィックのDS境界ノードとして機能する場合があります。したがって、ホストはDSドメイン内にあると言います。ホストが境界ノードとして機能しない場合、そのホストにトポロジ的に最も近いDSノードは、そのホストのトラフィックのDS境界ノードとして機能します。
DS boundary nodes act both as a DS ingress node and as a DS egress node for different directions of traffic. Traffic enters a DS domain at a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any TCA between it and the other domain to which the ingress node is connected. A DS egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains. Note that a DS boundary node may act as a DS interior node for some set of interfaces.
DS境界ノードは、DS入口ノードとしても、トラフィックの異なる方向のDS出口ノードとしても機能します。トラフィックは、DS入力ノードでDSドメインに入り、DS出力ノードでDSドメインを出ます。 DS入力ノードは、DSドメインに入るトラフィックが、それと入力ノードが接続されている他のドメインとの間のTCAに準拠していることを確認する責任があります。 DS出力ノードは、2つのドメイン間のTCAの詳細に応じて、直接接続されたピアリングドメインに転送されたトラフィックに対してトラフィック調整機能を実行できます。 DS境界ノードは、一部のインターフェイスセットのDS内部ノードとして機能する場合があることに注意してください。
A differentiated services region (DS Region) is a set of one or more contiguous DS domains. DS regions are capable of supporting differentiated services along paths which span the domains within the region.
差別化サービスリージョン（DSリージョン）は、1つ以上の連続したDSドメインのセットです。 DSリージョンは、リージョン内のドメインにまたがるパスに沿った差別化されたサービスをサポートできます。
The DS domains in a DS region may support different PHB groups internally and different codepoint->PHB mappings. However, to permit services which span across the domains, the peering DS domains must each establish a peering SLA which defines (either explicitly or implicitly) a TCA which specifies how transit traffic from one DS domain to another is conditioned at the boundary between the two DS domains.
DSリージョンのDSドメインは、内部で異なるPHBグループと、異なるコードポイント-> PHBマッピングをサポートする場合があります。ただし、ドメイン全体にまたがるサービスを許可するには、ピアリングDSドメインがそれぞれ、1つのDSドメインから別のDSドメインへの通過トラフィックが2つのドメイン間の境界でどのように条件付けられるかを指定するTCAを（明示的または暗黙的に）定義するピアリングSLAを確立する必要がありますDSドメイン。
It is possible that several DS domains within a DS region may adopt a common service provisioning policy and may support a common set of PHB groups and codepoint mappings, thus eliminating the need for traffic conditioning between those DS domains.
DSリージョン内のいくつかのDSドメインが共通のサービスプロビジョニングポリシーを採用し、PHBグループとコードポイントマッピングの共通セットをサポートする可能性があるため、これらのDSドメイン間のトラフィック調整の必要性がなくなります。
Differentiated services are extended across a DS domain boundary by establishing a SLA between an upstream network and a downstream DS domain. The SLA may specify packet classification and re-marking rules and may also specify traffic profiles and actions to traffic streams which are in- or out-of-profile (see Sec. 2.3.2). The TCA between the domains is derived (explicitly or implicitly) from this SLA.
差別化されたサービスは、アップストリームネットワークとダウンストリームDSドメインの間にSLAを確立することにより、DSドメインの境界を越えて拡張されます。 SLAは、パケット分類と再マーキングルールを指定し、トラフィックプロファイルと、プロファイル内またはプロファイル外のトラフィックストリームに対するアクションを指定することもできます（セクション2.3.2を参照）。ドメイン間のTCAは、このSLAから（明示的または暗黙的に）導出されます。
The packet classification policy identifies the subset of traffic which may receive a differentiated service by being conditioned and/ or mapped to one or more behavior aggregates (by DS codepoint re-marking) within the DS domain.
パケット分類ポリシーは、DSドメイン内の1つ以上の動作集約に（DSコードポイントの再マーキングによって）条件付けおよび/またはマッピングすることにより、差別化されたサービスを受信する可能性があるトラフィックのサブセットを識別します。
Traffic conditioning performs metering, shaping, policing and/or re-marking to ensure that the traffic entering the DS domain conforms to the rules specified in the TCA, in accordance with the domain's service provisioning policy. The extent of traffic conditioning required is dependent on the specifics of the service offering, and may range from simple codepoint re-marking to complex policing and shaping operations. The details of traffic conditioning policies which are negotiated between networks is outside the scope of this document.
トラフィック調整では、メータリング、シェーピング、ポリシング、再マーキングを実行して、DSドメインに入るトラフィックが、ドメインのサービスプロビジョニングポリシーに従って、TCAで指定されたルールに準拠していることを確認します。必要なトラフィック調整の範囲は、提供するサービスの仕様によって異なり、単純なコードポイントの再マーキングから複雑なポリシングおよびシェーピング操作までさまざまです。ネットワーク間でネゴシエートされるトラフィック調整ポリシーの詳細は、このドキュメントの範囲外です。
Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header. We define two types of classifiers. The BA (Behavior Aggregate) Classifier classifies packets based on the DS codepoint only. The MF (Multi-Field) classifier selects packets based on the value of a combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and other information such as incoming interface.
パケット分類子は、パケットヘッダーの一部のコンテンツに基づいて、トラフィックストリーム内のパケットを選択します。 2つのタイプの分類子を定義します。 BA（Behavior Aggregate）分類子は、DSコードポイントのみに基づいてパケットを分類します。 MF（マルチフィールド）クラシファイアは、送信元アドレス、宛先アドレス、DSフィールド、プロトコルID、送信元ポートと宛先ポート番号、およびその他の情報など、1つ以上のヘッダーフィールドの組み合わせの値に基づいてパケットを選択します。着信インターフェース。
Classifiers are used to "steer" packets matching some specified rule to an element of a traffic conditioner for further processing. Classifiers must be configured by some management procedure in accordance with the appropriate TCA.
分類子は、特定のルールに一致するパケットを「ステアリング」して、トラフィックコンディショナーの要素にさらに処理するために使用されます。分類子は、適切なTCAに従って、いくつかの管理手順で構成する必要があります。
The classifier should authenticate the information which it uses to classify the packet (see Sec. 6).
分類子は、パケットの分類に使用する情報を認証する必要があります（セクション6を参照）。
Note that in the event of upstream packet fragmentation, MF classifiers which examine the contents of transport-layer header fields may incorrectly classify packet fragments subsequent to the first. A possible solution to this problem is to maintain fragmentation state; however, this is not a general solution due to the possibility of upstream fragment re-ordering or divergent routing paths. The policy to apply to packet fragments is outside the scope of this document.
アップストリームパケットの断片化が発生した場合、トランスポート層ヘッダーフィールドの内容を検査するMF分類子が、最初のパケットフラグメント以降のパケットフラグメントを誤って分類する場合があることに注意してください。この問題の可能な解決策は、フラグメンテーション状態を維持することです。ただし、これは、上流フラグメントの再順序付けまたはルーティングパスの発散の可能性があるため、一般的な解決策ではありません。パケットフラグメントに適用するポリシーは、このドキュメントの範囲外です。
A traffic profile specifies the temporal properties of a traffic stream selected by a classifier. It provides rules for determining whether a particular packet is in-profile or out-of-profile. For example, a profile based on a token bucket may look like:
トラフィックプロファイルは、分類子によって選択されたトラフィックストリームの一時的なプロパティを指定します。特定のパケットが適合か不適合かを判別するためのルールを提供します。たとえば、トークンバケットに基づくプロファイルは次のようになります。
codepoint=X, use token-bucket r, b
codepoint = X、トークンバケットr、bを使用
The above profile indicates that all packets marked with DS codepoint X should be measured against a token bucket meter with rate r and burst size b. In this example out-of-profile packets are those packets in the traffic stream which arrive when insufficient tokens are available in the bucket. The concept of in- and out-of-profile can be extended to more than two levels, e.g., multiple levels of conformance with a profile may be defined and enforced.
上記のプロファイルは、DSコードポイントXでマークされたすべてのパケットを、レートrおよびバーストサイズbのトークンバケットメーターに対して測定する必要があることを示しています。この例では、プロファイル外のパケットは、バケットでトークンが不十分な場合に到着するトラフィックストリーム内のパケットです。プロファイル内およびプロファイル外の概念は、3つ以上のレベルに拡張できます。たとえば、プロファイルへの複数レベルの準拠を定義して適用できます。
Different conditioning actions may be applied to the in-profile packets and out-of-profile packets, or different accounting actions may be triggered. In-profile packets may be allowed to enter the DS domain without further conditioning; or, alternatively, their DS codepoint may be changed. The latter happens when the DS codepoint is set to a non-Default value for the first time [DSFIELD], or when the packets enter a DS domain that uses a different PHB group or codepoint->PHB mapping policy for this traffic stream. Out-of-profile packets may be queued until they are in-profile (shaped), discarded (policed), marked with a new codepoint (re-marked), or forwarded unchanged while triggering some accounting procedure. Out-of-profile packets may be mapped to one or more behavior aggregates that are "inferior" in some dimension of forwarding performance to the BA into which in-profile packets are mapped.
プロファイル内パケットとプロファイル外パケットに異なる調整アクションが適用されるか、異なるアカウンティングアクションがトリガーされます。プロファイル内のパケットは、それ以上の条件付けなしでDSドメインに入ることが許可される場合があります。または、それらのDSコードポイントが変更される場合があります。後者は、DSコードポイントが初めてデフォルト以外の値に設定されたとき[DSFIELD]、またはパケットがこのトラフィックストリームに対して別のPHBグループまたはコードポイント-> PHBマッピングポリシーを使用するDSドメインに入るときに発生します。プロファイル外のパケットは、プロファイル内（シェーピング）、破棄（ポリシング）、新しいコードポイントでマーク（再マーク）、またはアカウンティングプロシージャのトリガー中に変更せずに転送されるまで、キューに入れることができます。プロファイル外パケットは、プロファイル内パケットがマップされるBAへの転送パフォーマンスのいくつかの次元で「劣る」1つ以上の動作集約にマップされる場合があります。
Note that a traffic profile is an optional component of a TCA and its use is dependent on the specifics of the service offering and the domain's service provisioning policy.
トラフィックプロファイルはTCAのオプションのコンポーネントであり、その使用はサービスの詳細とドメインのサービスプロビジョニングポリシーに依存することに注意してください。
A traffic conditioner may contain the following elements: meter, marker, shaper, and dropper. A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner. A meter is used (where appropriate) to measure the traffic stream against a traffic profile. The state of the meter with respect to a particular packet (e.g., whether it is in- or out-of-profile) may be used to affect a marking, dropping, or shaping action.
トラフィックコンディショナーには、メーター、マーカー、シェイパー、ドロッパーの要素を含めることができます。トラフィックストリームは分類器によって選択され、分類器はパケットをトラフィック調整器の論理インスタンスに誘導します。メーターを使用して（適切な場合）、トラフィックプロファイルに対するトラフィックストリームを測定します。特定のパケットに関するメーターの状態（たとえば、プロファイル内かプロファイル外か）を使用して、マーキング、ドロップ、またはシェーピングアクションに影響を与えることができます。
When packets exit the traffic conditioner of a DS boundary node the DS codepoint of each packet must be set to an appropriate value.
パケットがDS境界ノードのトラフィックコンディショナーを出るとき、各パケットのDSコードポイントを適切な値に設定する必要があります。
Fig. 1 shows the block diagram of a classifier and traffic conditioner. Note that a traffic conditioner may not necessarily contain all four elements. For example, in the case where no traffic profile is in effect, packets may only pass through a classifier and a marker.
図1に、分類器とトラフィックコンディショナーのブロック図を示します。トラフィックコンディショナーには、4つすべての要素が含まれているとは限りません。たとえば、有効なトラフィックプロファイルがない場合、パケットは分類子とマーカーのみを通過できます。
+-------+
| |-------------------+
+----->| Meter | |
| | |--+ |
| +-------+ | |
| V V
+------------+ +--------+ +---------+
| | | | | Shaper/ |
packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
| | | | | |
+------------+ +--------+ +---------+
Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner
図1：パケット分類子とトラフィックコンディショナーの論理ビュー
Traffic meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile specified in a TCA. A meter passes state information to other conditioning functions to trigger a particular action for each packet which is either in- or out-of-profile (to some extent).
トラフィックメーターは、TCAで指定されたトラフィックプロファイルに対して、分類子によって選択されたパケットストリームの一時的なプロパティを測定します。メーターは、状態情報を他の調整機能に渡し、（ある程度）適合または不適合である各パケットの特定のアクションをトリガーします。
Packet markers set the DS field of a packet to a particular codepoint, adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets which are steered to it to a single codepoint, or may be configured to mark a packet to one of a set of codepoints used to select a PHB in a PHB group, according to the state of a meter. When the marker changes the codepoint in a packet it is said to have "re-marked" the packet.
パケットマーカーは、パケットのDSフィールドを特定のコードポイントに設定し、マークされたパケットを特定のDS動作集約に追加します。マーカーは、単一のコードポイントに向けられたすべてのパケットにマークを付けるように構成することも、PHBグループ内のPHBを選択するために使用されるコードポイントのセットの1つにパケットをマークするように構成することもできます。メーター。マーカーがパケットのコードポイントを変更すると、そのパケットは「再マーク」されたといいます。
Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets.
シェーパーは、トラフィックストリームをトラフィックプロファイルに準拠させるために、トラフィックストリーム内の一部またはすべてのパケットを遅延させます。シェーパーには通常、有限サイズのバッファーがあり、遅延したパケットを保持するのに十分なバッファースペースがない場合、パケットは破棄される可能性があります。
Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is know as "policing" the stream. Note that a dropper can be implemented as a special case of a shaper by setting the shaper buffer size to zero (or a few) packets.
ドロッパーは、トラフィックストリームをトラフィックプロファイルに準拠させるために、トラフィックストリーム内の一部またはすべてのパケットを破棄します。このプロセスは、ストリームの「ポリシング」と呼ばれます。ドロッパーは、シェーパーバッファーサイズをゼロ（またはいくつか）のパケットに設定することにより、シェーパーの特殊なケースとして実装できます。
Traffic conditioners are usually located within DS ingress and egress boundary nodes, but may also be located in nodes within the interior of a DS domain, or within a non-DS-capable domain.
トラフィックコンディショナーは通常、DSの入力と出力の境界ノード内に配置されますが、DSドメインの内部のノードまたはDS非対応ドメイン内のノードに配置される場合もあります。
We define the source domain as the domain containing the node(s) which originate the traffic receiving a particular service. Traffic sources and intermediate nodes within a source domain may perform traffic classification and conditioning functions. The traffic originating from the source domain across a boundary may be marked by the traffic sources directly or by intermediate nodes before leaving the source domain. This is referred to as initial marking or "pre-marking".
ソースドメインは、特定のサービスを受信するトラフィックを発信するノードを含むドメインとして定義します。トラフィックソースおよびソースドメイン内の中間ノードは、トラフィックの分類および調整機能を実行できます。境界を越えてソースドメインから発信されるトラフィックは、ソースドメインを離れる前に、トラフィックソースによって直接、または中間ノードによってマークされます。これは、初期マーキングまたは「プレマーキング」と呼ばれます。
Consider the example of a company that has the policy that its CEO's packets should have higher priority. The CEO's host may mark the DS field of all outgoing packets with a DS codepoint that indicates "higher priority". Alternatively, the first-hop router directly connected to the CEO's host may classify the traffic and mark the CEO's packets with the correct DS codepoint. Such high priority traffic may also be conditioned near the source so that there is a limit on the amount of high priority traffic forwarded from a particular source.
CEOのパケットの優先度を高くする必要があるというポリシーを持つ会社の例を考えてみます。 CEOのホストは、すべての発信パケットのDSフィールドに、「優先度が高い」ことを示すDSコードポイントを付けることができます。または、CEOのホストに直接接続されているファーストホップルーターがトラフィックを分類し、CEOのパケットを正しいDSコードポイントでマークすることもできます。そのような高優先度のトラフィックは、特定のソースから転送される高優先度のトラフィックの量に制限があるように、ソースの近くで条件付けされる場合もあります。
There are some advantages to marking packets close to the traffic source. First, a traffic source can more easily take an application's preferences into account when deciding which packets should receive better forwarding treatment. Also, classification of packets is much simpler before the traffic has been aggregated with packets from other sources, since the number of classification rules which need to be applied within a single node is reduced.
トラフィックソースの近くにパケットをマーキングすることにはいくつかの利点があります。まず、トラフィックソースは、より適切な転送処理を受信する必要があるパケットを決定するときに、アプリケーションの設定をより簡単に考慮することができます。また、単一ノード内で適用する必要のある分類規則の数が減るため、他のソースからのパケットでトラフィックが集約される前に、パケットの分類がはるかに簡単になります。
Since packet marking may be distributed across multiple nodes, the source DS domain is responsible for ensuring that the aggregated traffic towards its provider DS domain conforms to the appropriate TCA. Additional allocation mechanisms such as bandwidth brokers or RSVP may be used to dynamically allocate resources for a particular DS behavior aggregate within the provider's network [2BIT, Bernet]. The boundary node of the source domain should also monitor conformance to the TCA, and may police, shape, or re-mark packets as necessary.
パケットマーキングは複数のノードに分散される可能性があるため、ソースDSドメインは、そのプロバイダーDSドメインへの集約トラフィックが適切なTCAに準拠していることを確認する責任があります。帯域幅ブローカーやRSVPなどの追加の割り当てメカニズムを使用して、プロバイダーのネットワーク内の特定のDS動作集約にリソースを動的に割り当てることができます[2BIT、Bernet]。ソースドメインの境界ノードもTCAへの準拠を監視する必要があり、必要に応じてパケットのポリシング、シェーピング、または再マーキングを行う場合があります。
Traffic streams may be classified, marked, and otherwise conditioned on either end of a boundary link (the DS egress node of the upstream domain or the DS ingress node of the downstream domain). The SLA between the domains should specify which domain has responsibility for mapping traffic streams to DS behavior aggregates and conditioning those aggregates in conformance with the appropriate TCA. However, a DS ingress node must assume that the incoming traffic may not conform to the TCA and must be prepared to enforce the TCA in accordance with local policy.
トラフィックストリームは、境界リンクの両端（上流ドメインのDS出力ノードまたは下流ドメインのDS入力ノード）で分類、マーク、およびその他の条件付けを行うことができます。ドメイン間のSLAは、トラフィックストリームをDS動作集約にマッピングし、適切なTCAに準拠してそれらの集約を調整する責任があるドメインを指定する必要があります。ただし、DS入力ノードは、着信トラフィックがTCAに準拠していない可能性があると想定し、ローカルポリシーに従ってTCAを適用する準備をする必要があります。
When packets are pre-marked and conditioned in the upstream domain, potentially fewer classification and traffic conditioning rules need to be supported in the downstream DS domain. In this circumstance the downstream DS domain may only need to re-mark or police the incoming behavior aggregates to enforce the TCA. However, more sophisticated services which are path- or source-dependent may require MF classification in the downstream DS domain's ingress nodes.
パケットに上流のドメインで事前のマーク付けと条件付けを行うと、下流のDSドメインでサポートする必要のある分類とトラフィックの条件付けルールが少なくなる可能性があります。この状況では、ダウンストリームDSドメインは、TCAを実施するために着信動作集約を再マークまたはポリシングするだけでよい場合があります。ただし、パスまたはソースに依存するより高度なサービスでは、ダウンストリームDSドメインの入力ノードでMF分類が必要になる場合があります。
If a DS ingress node is connected to an upstream non-DS-capable domain, the DS ingress node must be able to perform all necessary traffic conditioning functions on the incoming traffic.
DS入力ノードが上流の非DS対応ドメインに接続されている場合、DS入力ノードは、着信トラフィックに対して必要なすべてのトラフィック調整機能を実行できる必要があります。
Traffic sources or intermediate nodes in a non-DS-capable domain may employ traffic conditioners to pre-mark traffic before it reaches the ingress of a downstream DS domain. In this way the local policies for classification and marking may be concealed.
DSに対応していないドメインのトラフィックソースまたは中間ノードは、トラフィックがダウンストリームDSドメインの入口に到達する前に、トラフィックコンディショナーを使用してトラフィックに事前マークを付けることができます。このようにして、分類とマーキングのローカルポリシーを隠すことができます。
Although the basic architecture assumes that complex classification and traffic conditioning functions are located only in a network's ingress and egress boundary nodes, deployment of these functions in the interior of the network is not precluded. For example, more restrictive access policies may be enforced on a transoceanic link, requiring MF classification and traffic conditioning functionality in the upstream node on the link. This approach may have scaling limits, due to the potentially large number of classification and conditioning rules that might need to be maintained.
基本的なアーキテクチャでは、複雑な分類機能とトラフィック調整機能はネットワークの入口と出口の境界ノードにのみ配置されていると想定していますが、これらの機能をネットワークの内部に配置することは可能です。たとえば、大洋横断リンクでは、より制限の厳しいアクセスポリシーが適用され、リンクの上流ノードでMF分類とトラフィック調整機能が必要になる場合があります。維持する必要がある可能性のある多数の分類および条件付けルールが原因で、このアプローチにはスケーリングの制限がある場合があります。
A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. "Forwarding behavior" is a general concept in this context. For example, in the event that only one behavior aggregate occupies a link, the observable forwarding behavior (i.e., loss, delay, jitter) will often depend only on the relative loading of the link (i.e., in the event that the behavior assumes a work-conserving scheduling discipline). Useful behavioral distinctions are mainly observed when multiple behavior aggregates compete for buffer and bandwidth resources on a node. The PHB is the means by which a node allocates resources to behavior aggregates, and it is on top of this basic hop-by-hop resource allocation mechanism that useful differentiated services may be constructed.
ホップごとの動作（PHB）は、特定のDS動作集約に適用された、DSノードの外部から観察可能な転送動作の説明です。 「転送動作」は、この文脈における一般的な概念です。たとえば、1つの動作集約のみがリンクを占有している場合、観察可能な転送動作（つまり、損失、遅延、ジッター）は、リンクの相対的な負荷のみに依存する場合があります（つまり、動作が仕事を節約するスケジューリング規律）。有用な動作の違いは主に、複数の動作集約がノード上のバッファおよび帯域幅リソースを求めて競合するときに観察されます。 PHBは、ノードが動作集合体にリソースを割り当てる手段であり、この基本的なホップバイホップのリソース割り当てメカニズムの上にあり、役立つ差別化サービスを構築できます。
The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of X% of a link (over some reasonable time interval) to a behavior aggregate. This PHB can be fairly easily measured under a variety of competing traffic conditions. A slightly more complex PHB would guarantee a minimal bandwidth allocation of X% of a link, with proportional fair sharing of any excess link capacity. In general, the observable behavior of a PHB may depend on certain constraints on the traffic characteristics of the associated behavior aggregate, or the characteristics of other behavior aggregates.
PHBの最も単純な例は、動作集計へのリンクのX％（ある程度の時間間隔で）の最小帯域幅割り当てを保証するものです。このPHBは、さまざまな競合する交通状況の下でかなり簡単に測定できます。少し複雑なPHBは、リンクのX％の最小帯域幅割り当てを保証し、過剰なリンク容量を均等に均等に共有します。一般に、PHBの観察可能な動作は、関連する動作集約のトラフィック特性または他の動作集約の特性に対する特定の制約に依存する場合があります。
PHBs may be specified in terms of their resource (e.g., buffer, bandwidth) priority relative to other PHBs, or in terms of their relative observable traffic characteristics (e.g., delay, loss). These PHBs may be used as building blocks to allocate resources and should be specified as a group (PHB group) for consistency. PHB groups will usually share a common constraint applying to each PHB within the group, such as a packet scheduling or buffer management policy. The relationship between PHBs in a group may be in terms of absolute or relative priority (e.g., discard priority by means of deterministic or stochastic thresholds), but this is not required (e.g., N equal link shares). A single PHB defined in isolation is a special case of a PHB group.
PHBは、他のPHBに対するリソース（バッファー、帯域幅など）の優先順位、または相対的に観察可能なトラフィック特性（遅延、損失など）の観点から指定できます。これらのPHBは、リソースを割り当てるためのビルディングブロックとして使用でき、整合性のためにグループ（PHBグループ）として指定する必要があります。 PHBグループは通常、パケットスケジューリングやバッファ管理ポリシーなど、グループ内の各PHBに適用される共通の制約を共有します。グループ内のPHB間の関係は、絶対的または相対的な優先度（たとえば、確定的または確率的しきい値による優先度の破棄）の観点からあり得ますが、これは必須ではありません（たとえば、Nの等しいリンク共有）。分離して定義された単一のPHBは、PHBグループの特殊なケースです。
PHBs are implemented in nodes by means of some buffer management and packet scheduling mechanisms. PHBs are defined in terms of behavior characteristics relevant to service provisioning policies, and not in terms of particular implementation mechanisms. In general, a variety of implementation mechanisms may be suitable for implementing a particular PHB group. Furthermore, it is likely that more than one PHB group may be implemented on a node and utilized within a domain. PHB groups should be defined such that the proper resource allocation between groups can be inferred, and integrated mechanisms can be implemented which can simultaneously support two or more groups. A PHB group definition should indicate possible conflicts with previously documented PHB groups which might prevent simultaneous operation.
PHBは、いくつかのバッファ管理およびパケットスケジューリングメカニズムによってノードに実装されます。 PHBは、特定の実装メカニズムではなく、サービスプロビジョニングポリシーに関連する動作特性の観点から定義されます。一般に、特定のPHBグループを実装するには、さまざまな実装メカニズムが適している場合があります。さらに、複数のPHBグループがノードに実装され、ドメイン内で利用される可能性があります。 PHBグループは、グループ間の適切なリソース割り当てを推測できるように定義する必要があり、2つ以上のグループを同時にサポートできる統合メカニズムを実装できます。 PHBグループの定義は、以前に文書化されたPHBグループとの競合を示しているため、同時操作ができない場合があります。
As described in [DSFIELD], a PHB is selected at a node by a mapping of the DS codepoint in a received packet. Standardized PHBs have a recommended codepoint. However, the total space of codepoints is larger than the space available for recommended codepoints for standardized PHBs, and [DSFIELD] leaves provisions for locally configurable mappings. A codepoint->PHB mapping table may contain both 1->1 and N->1 mappings. All codepoints must be mapped to some PHB; in the absence of some local policy, codepoints which are not mapped to a standardized PHB in accordance with that PHB's specification should be mapped to the Default PHB.
[DSFIELD]で説明されているように、PHBは受信パケット内のDSコードポイントのマッピングによってノードで選択されます。標準化されたPHBには、推奨されるコードポイントがあります。ただし、コードポイントの合計スペースは、標準化されたPHBの推奨コードポイントに使用可能なスペースよりも大きく、[DSFIELD]はローカルで構成可能なマッピングのプロビジョニングを残します。コードポイント-> PHBマッピングテーブルには、1-> 1とN-> 1の両方のマッピングを含めることができます。すべてのコードポイントは、いくつかのPHBにマップする必要があります。ローカルポリシーがない場合、そのPHBの仕様に従って標準化されたPHBにマップされていないコードポイントは、デフォルトのPHBにマップする必要があります。
The implementation, configuration, operation and administration of the supported PHB groups in the nodes of a DS Domain should effectively partition the resources of those nodes and the inter-node links between behavior aggregates, in accordance with the domain's service provisioning policy. Traffic conditioners can further control the usage of these resources through enforcement of TCAs and possibly through operational feedback from the nodes and traffic conditioners in the domain. Although a range of services can be deployed in the absence of complex traffic conditioning functions (e.g., using only static marking policies), functions such as policing, shaping, and dynamic re-marking enable the deployment of services providing quantitative performance metrics.
DSドメインのノードでサポートされるPHBグループの実装、構成、操作、および管理は、ドメインのサービスプロビジョニングポリシーに従って、それらのノードのリソースと動作集約間のノード間リンクを効果的に分割する必要があります。トラフィックコンディショナーは、TCAの実施と、場合によってはドメイン内のノードとトラフィックコンディショナーからの操作フィードバックを通じて、これらのリソースの使用をさらに制御できます。複雑なトラフィック調整機能がなくても（静的なマーキングポリシーのみを使用して）さまざまなサービスを展開できますが、ポリシング、シェーピング、動的な再マーキングなどの機能を使用すると、定量的なパフォーマンスメトリックを提供するサービスを展開できます。
The configuration of and interaction between traffic conditioners and interior nodes should be managed by the administrative control of the domain and may require operational control through protocols and a control entity. There is a wide range of possible control models.
トラフィックコンディショナーと内部ノードの構成と相互作用は、ドメインの管理制御によって管理する必要があり、プロトコルと制御エンティティによる運用制御が必要になる場合があります。可能な制御モデルは多岐にわたります。
The precise nature and implementation of the interaction between these components is outside the scope of this architecture. However, scalability requires that the control of the domain does not require micro-management of the network resources. The most scalable control model would operate nodes in open-loop in the operational timeframe, and would only require administrative-timescale management as SLAs are varied. This simple model may be unsuitable in some circumstances, and some automated but slowly varying operational control (minutes rather than seconds) may be desirable to balance the utilization of the network against the recent load profile.
これらのコンポーネント間の相互作用の正確な性質と実装は、このアーキテクチャの範囲外です。ただし、スケーラビリティには、ドメインの制御がネットワークリソースのマイクロ管理を必要としないことが必要です。最もスケーラブルな制御モデルでは、運用時間枠内でノードを開ループで操作し、SLAが変化するため、管理タイムスケール管理のみが必要になります。この単純なモデルは状況によっては不適切な場合があり、ネットワークの使用率と最近の負荷プロファイルのバランスをとるには、自動化されているがゆっくりと変化する操作制御（秒ではなく分）が望ましい場合があります。
Basic requirements for per-hop behavior standardization are given in [DSFIELD]. This section elaborates on that text by describing additional guidelines for PHB (group) specifications. This is intended to help foster implementation consistency. Before a PHB group is proposed for standardization it should satisfy these guidelines, as appropriate, to preserve the integrity of this architecture.
ホップごとの動作標準化の基本要件は、[DSFIELD]で提供されています。このセクションでは、PHB（グループ）仕様の追加ガイドラインを説明することにより、そのテキストについて詳しく説明します。これは、実装の一貫性を促進することを目的としています。 PHBグループが標準化のために提案される前に、このアーキテクチャの整合性を維持するために、必要に応じてこれらのガイドラインを満たす必要があります。
G.1: A PHB standard must specify a recommended DS codepoint selected from the codepoint space reserved for standard mappings [DSFIELD]. Recommended codepoints will be assigned by the IANA. A PHB proposal may recommend a temporary codepoint from the EXP/LU space to facilitate inter-domain experimentation. Determination of a packet's PHB must not require inspection of additional packet header fields beyond the DS field.
G.1：PHB標準は、標準マッピング[DSFIELD]用に予約されたコードポイントスペースから選択された推奨DSコードポイントを指定する必要があります。推奨コードポイントはIANAによって割り当てられます。 PHBプロポーザルは、ドメイン間の実験を容易にするために、EXP / LUスペースからの一時的なコードポイントを推奨する場合があります。パケットのPHBの決定では、DSフィールド以外の追加のパケットヘッダーフィールドを検査する必要はありません。
G.2: The specification of each newly proposed PHB group should include an overview of the behavior and the purpose of the behavior being proposed. The overview should include a problem or problems statement for which the PHB group is targeted. The overview should include the basic concepts behind the PHB group. These concepts should include, but are not restricted to, queueing behavior, discard behavior, and output link selection behavior. Lastly, the overview should specify the method by which the PHB group solves the problem or problems specified in the problem statement.
G.2：新しく提案された各PHBグループの仕様には、行動の概要と提案されている行動の目的を含める必要があります。概要には、PHBグループが対象としている問題が含まれている必要があります。概要には、PHBグループの背後にある基本的な概念を含める必要があります。これらの概念には、キューイング動作、破棄動作、および出力リンク選択動作が含まれますが、これらに限定されません。最後に、概要では、PHBグループが問題文で指定された問題を解決する方法を指定する必要があります。
G.3: A PHB group specification should indicate the number of individual PHBs specified. In the event that multiple PHBs are specified, the interactions between these PHBs and constraints that must be respected globally by all the PHBs within the group should be clearly specified. As an example, the specification must indicate whether the probability of packet reordering within a microflow is increased if different packets in that microflow are marked for different PHBs within the group.
G.3：PHBグループ仕様は、指定された個々のPHBの数を示す必要があります。複数のPHBが指定されている場合、これらのPHBとグループ内のすべてのPHBがグローバルに尊重する必要がある制約との間の相互作用を明確に指定する必要があります。例として、仕様では、マイクロフロー内の異なるパケットがグループ内の異なるPHBに対してマークされている場合に、マイクロフロー内のパケットの並べ替えの確率が高くなるかどうかを示す必要があります。
G.4: When proper functioning of a PHB group is dependent on constraints such as a provisioning restriction, then the PHB definition should describe the behavior when these constraints are violated. Further, if actions such as packet discard or re-marking are required when these constraints are violated, then these actions should be specifically stipulated.
G.4：PHBグループの適切な機能がプロビジョニング制限などの制約に依存している場合、PHB定義は、これらの制約に違反したときの動作を記述する必要があります。さらに、これらの制約に違反したときにパケットの破棄や再マーキングなどのアクションが必要な場合は、これらのアクションを具体的に規定する必要があります。
G.5: A PHB group may be specified for local use within a domain in order to provide some domain-specific functionality or domain-specific services. In this event, the PHB specification is useful for providing vendors with a consistent definition of the PHB group. However, any PHB group which is defined for local use should not be considered for standardization, but may be published as an Informational RFC. In contrast, a PHB group which is intended for general use will follow a stricter standardization process. Therefore all PHB proposals should specifically state whether they are to be considered for general or local use.
G.5：ドメイン固有の機能またはドメイン固有のサービスを提供するために、PHBグループをドメイン内でローカルに使用するように指定できます。この場合、PHB仕様は、ベンダーにPHBグループの一貫した定義を提供するのに役立ちます。ただし、ローカルで使用するために定義されているPHBグループは、標準化の対象とは見なされませんが、情報RFCとして公開される場合があります。対照的に、一般的な使用を目的としたPHBグループは、より厳密な標準化プロセスに従います。したがって、すべてのPHBの提案には、一般的な使用とローカルでの使用のどちらを検討するかを具体的に記載する必要があります。
It is recognized that PHB groups can be designed with the intent of providing host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge services. Use of the term "end-to-end" in a PHB definition should be interpreted to mean "host-to-host" for consistency.
PHBグループは、ホストからホスト、WANエッジからWANエッジ、またはドメインエッジからドメインエッジへのサービスを提供する目的で設計できることが認識されています。 PHB定義での「エンドツーエンド」という用語の使用は、一貫性のために「ホストツーホスト」を意味すると解釈されるべきです。
Other PHB groups may be defined and deployed locally within domains, for experimental or operational purposes. There is no requirement that these PHB groups must be publicly documented, but they should utilize DS codepoints from one of the EXP/LU pools as defined in [DSFIELD].
その他のPHBグループは、実験的または運用上の目的で、ドメイン内でローカルに定義および展開できます。これらのPHBグループを公に文書化する必要はありませんが、[DSFIELD]で定義されているように、EXP / LUプールの1つからのDSコードポイントを利用する必要があります。
G.6: It may be possible or appropriate for a packet marked for a PHB within a PHB group to be re-marked to select another PHB within the group; either within a domain or across a domain boundary. Typically there are three reasons for such PHB modification:
G.6：PHBグループ内のPHB用にマークされたパケットを再度マークして、グループ内の別のPHBを選択することが可能または適切な場合があります。ドメイン内またはドメイン境界を越えて。通常、このようなPHB変更には3つの理由があります。
a. The codepoints associated with the PHB group are collectively intended to carry state about the network, b. Conditions exist which require PHB promotion or demotion of a packet (this assumes that PHBs within the group can be ranked in some order), c. The boundary between two domains is not covered by a SLA. In this case the codepoint/PHB to select when crossing the boundary link will be determined by the local policy of the upstream domain.
a. PHBグループに関連付けられたコードポイントは、ネットワークに関する状態をまとめて運ぶことを目的としています。パケットのPHB昇格または降格を必要とする条件が存在します（これは、グループ内のPHBが何らかの順序でランク付けできることを前提としています）。 2つのドメイン間の境界はSLAの対象ではありません。この場合、境界リンクを通過するときに選択するコードポイント/ PHBは、上流ドメインのローカルポリシーによって決定されます。
A PHB specification should clearly state the circumstances under which packets marked for a PHB within a PHB group may, or should be modified (e.g., promoted or demoted) to another PHB within the group. If it is undesirable for a packet's PHB to be modified, the specification should clearly state the consequent risks when the PHB is modified. A possible risk to changing a packet's PHB, either within or outside a PHB group, is a higher probability of packet re-ordering within a microflow. PHBs within a group may carry some host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge semantics which may be difficult to duplicate if packets are re-marked to select another PHB from the group (or otherwise).
PHB仕様では、PHBグループ内のPHB用にマークされたパケットが、グループ内の別のPHBに変更（たとえば、昇格または降格）される可能性がある状況を明確に示す必要があります。パケットのPHBが変更されることが望ましくない場合、仕様では、PHBが変更された場合の結果として生じるリスクを明確に示す必要があります。 PHBグループの内外でパケットのPHBを変更するリスクとして考えられるのは、マイクロフロー内でのパケットの並べ替えの可能性が高くなることです。グループ内のPHBは、ホストからホスト、WANエッジからWANエッジ、またはドメインエッジからドメインエッジのセマンティクスを伝送する場合があり、パケットが再度マークされてから別のPHBを選択すると、複製が困難になる場合があります。グループ（またはそれ以外）。
For certain PHB groups, it may be appropriate to reflect a state change in the node by re-marking packets to specify another PHB from within the group. If a PHB group is designed to reflect the state of a network, the PHB definition must adequately describe the relationship between the PHBs and the states they reflect. Further, if these PHBs limit the forwarding actions a node can perform in some way, these constraints may be specified as actions the node should, or must perform.
特定のPHBグループでは、パケットを再マーキングしてグループ内から別のPHBを指定することにより、ノードの状態変化を反映することが適切な場合があります。 PHBグループがネットワークの状態を反映するように設計されている場合、PHB定義は、PHBとそれらが反映する状態の間の関係を適切に記述する必要があります。さらに、これらのPHBがノードが何らかの方法で実行できる転送アクションを制限する場合、これらの制約はノードが実行する必要がある、または実行する必要があるアクションとして指定できます。
G.7: A PHB group specification should include a section defining the implications of tunneling on the utility of the PHB group. This section should specify the implications for the utility of the PHB group of a newly created outer header when the original DS field of the inner header is encapsulated in a tunnel. This section should also discuss what possible changes should be applied to the inner header at the egress of the tunnel, when both the codepoints from the inner header and the outer header are accessible (see Sec. 6.2).
G.7：PHBグループ仕様には、PHBグループのユーティリティに対するトンネリングの影響を定義するセクションを含める必要があります。このセクションでは、内部ヘッダーの元のDSフィールドがトンネルにカプセル化されている場合に、新しく作成された外部ヘッダーのPHBグループのユーティリティに対する影響を指定する必要があります。このセクションでは、内部ヘッダーと外部ヘッダーの両方のコードポイントにアクセスできる場合に、トンネルの出口で内部ヘッダーにどのような変更を適用する必要があるかについても説明します（セクション6.2を参照）。
G.8: The process of specifying PHB groups is likely to be incremental in nature. When new PHB groups are proposed, their known interactions with previously specified PHB groups should be documented. When a new PHB group is created, it can be entirely new in scope or it can be an extension to an existing PHB group. If the PHB group is entirely independent of some or all of the existing PHB specifications, a section should be included in the PHB specification which details how the new PHB group can co-exist with those PHB groups already standardized. For example, this section might indicate the possibility of packet re-ordering within a microflow for packets marked by codepoints associated with two separate PHB groups. If concurrent operation of two (or more) different PHB groups in the same node is impossible or detrimental this should be stated. If the concurrent operation of two (or more) different PHB groups requires some specific behaviors by the node when packets marked for PHBs from these different PHB groups are being processed by the node at the same time, these behaviors should be stated.
G.8：PHBグループを指定するプロセスは、本質的にインクリメンタルになる可能性があります。新しいPHBグループを提案する場合、以前に指定したPHBグループとの既知の相互作用を文書化する必要があります。新しいPHBグループが作成されると、そのスコープは完全に新しいものになるか、既存のPHBグループの拡張になります。 PHBグループが既存のPHB仕様の一部またはすべてから完全に独立している場合、新しいPHBグループがすでに標準化されているPHBグループとどのように共存できるかを詳述するセクションをPHB仕様に含める必要があります。たとえば、このセクションは、2つの個別のPHBグループに関連付けられたコードポイントによってマークされたパケットのマイクロフロー内でのパケットの並べ替えの可能性を示している場合があります。同じノード内の2つ（またはそれ以上）の異なるPHBグループの同時操作が不可能または有害な場合は、これを明記する必要があります。 2つ以上の異なるPHBグループの同時操作で、これらの異なるPHBグループからのPHB用にマークされたパケットがノードによって同時に処理されているときに、ノードによる特定の動作が必要な場合は、これらの動作を明記する必要があります。
Care should be taken to avoid circularity in the definitions of PHB groups.
PHBグループの定義が循環しないように注意する必要があります。
If the proposed PHB group is an extension to an existing PHB group, a section should be included in the PHB group specification which details how this extension interoperates with the behavior being extended. Further, if the extension alters or more narrowly defines the existing behavior in some way, this should also be clearly indicated.
提案されたPHBグループが既存のPHBグループの拡張である場合、この拡張が拡張される動作とどのように相互運用するかを詳述するセクションをPHBグループ仕様に含める必要があります。さらに、拡張機能が既存の動作を何らかの方法で変更またはより狭く定義する場合、これも明確に示されます。
G.9: Each PHB specification should include a section specifying minimal conformance requirements for implementations of the PHB group. This conformance section is intended to provide a means for specifying the details of a behavior while allowing for implementation variation to the extent permitted by the PHB specification. This conformance section can take the form of rules, tables, pseudo-code, or tests.
G.9：各PHB仕様には、PHBグループの実装に関する最小限の適合要件を指定するセクションを含める必要があります。この適合セクションは、PHB仕様で許可されている範囲で実装のバリエーションを許可しながら、動作の詳細を指定する手段を提供することを目的としています。この適合セクションは、ルール、テーブル、疑似コード、またはテストの形式を取ることができます。
G.10: A PHB specification should include a section detailing the security implications of the behavior. This section should include a discussion of the re-marking of the inner header's codepoint at the egress of a tunnel and its effect on the desired forwarding behavior.
G.10：PHB仕様には、動作のセキュリティへの影響を詳しく説明するセクションを含める必要があります。このセクションには、トンネルの出口での内部ヘッダーのコードポイントの再マーキングと、目的の転送動作への影響についての説明を含める必要があります。
Further, this section should also discuss how the proposed PHB group could be used in denial-of-service attacks, reduction of service contract attacks, and service contract violation attacks. Lastly, this section should discuss possible means for detecting such attacks as they are relevant to the proposed behavior.
さらに、このセクションでは、提案されたPHBグループがサービス拒否攻撃、サービスコントラクト攻撃の削減、およびサービスコントラクト違反攻撃でどのように使用されるかについても説明する必要があります。最後に、このセクションでは、提案された動作に関連する攻撃を検出するための可能な手段について説明します。
G.11: A PHB specification should include a section detailing configuration and management issues which may affect the operation of the PHB and which may impact candidate services that might utilize the PHB.
G.11：PHB仕様には、PHBの運用に影響を与える可能性があり、PHBを利用する可能性のある候補サービスに影響を与える可能性のある構成および管理の問題を詳述するセクションを含める必要があります。
G.12: It is strongly recommended that an appendix be provided with each PHB specification that considers the implications of the proposed behavior on current and potential services. These services could include but are not restricted to be user-specific, device-specific, domain-specific or end-to-end services. It is also strongly recommended that the appendix include a section describing how the services are verified by users, devices, and/or domains.
G.12：提案されている動作が現在のサービスと潜在的なサービスに与える影響を考慮した付録を各PHB仕様とともに提供することを強くお勧めします。これらのサービスには、ユーザー固有、デバイス固有、ドメイン固有、またはエンドツーエンドサービスが含まれますが、これらに限定されません。また、付録には、サービスがユーザー、デバイス、ドメインによって検証される方法を説明するセクションを含めることを強くお勧めします。
G.13: It is recommended that an appendix be provided with each PHB specification that is targeted for local use within a domain, providing guidance for PHB selection for packets which are forwarded into a peer domain which does not support the PHB group.
G.13：ドメイン内でのローカル使用を対象とした各PHB仕様に付録を提供し、PHBグループをサポートしないピアドメインに転送されるパケットのPHB選択に関するガイダンスを提供することをお勧めします。
G.14: It is recommended that an appendix be provided with each PHB specification which considers the impact of the proposed PHB group on existing higher-layer protocols. Under some circumstances PHBs may allow for possible changes to higher-layer protocols which may increase or decrease the utility of the proposed PHB group.
G.14：提案されたPHBグループが既存の上位層プロトコルに与える影響を考慮した付録を各PHB仕様とともに提供することをお勧めします。状況によっては、PHBは上位層プロトコルへの可能な変更を可能にし、提案されたPHBグループの有用性を増加または減少させる可能性があります。
G.15: It is recommended that an appendix be provided with each PHB specification which recommends mappings to link-layer QoS mechanisms to support the intended behavior of the PHB across a shared-medium or switched link-layer. The determination of the most appropriate mapping between a PHB and a link-layer QoS mechanism is dependent on many factors and is outside the scope of this document; however, the specification should attempt to offer some guidance.
G.15：リンク層のQoSメカニズムへのマッピングを推奨し、共有メディアまたはスイッチドリンク層全体でPHBの意図された動作をサポートする付録を各PHB仕様で提供することをお勧めします。 PHBとリンク層QoSメカニズムの間の最も適切なマッピングの決定は、多くの要因に依存しており、このドキュメントの範囲外です。ただし、仕様ではいくつかのガイダンスを提供する必要があります。
We define a non-differentiated services-compliant node (non-DS-compliant node) as any node which does not interpret the DS field as specified in [DSFIELD] and/or does not implement some or all of the standardized PHBs (or those in use within a particular DS domain). This may be due to the capabilities or configuration of the node. We define a legacy node as a special case of a non-DS-compliant node which implements IPv4 Precedence classification and forwarding as defined in [RFC791, RFC1812], but which is otherwise not DS-compliant. The precedence values in the IPv4 TOS octet are compatible by intention with the Class Selector Codepoints defined in [DSFIELD], and the precedence forwarding behaviors defined in [RFC791, RFC1812] comply with the Class Selector PHB Requirements also defined in [DSFIELD]. A key distinction between a legacy node and a DS-compliant node is that the legacy node may or may not interpret bits 3-6 of the TOS octet as defined in [RFC1349] (the "DTRC" bits); in practice it will not interpret these bit as specified in [DSFIELD]. We assume that the use of the TOS markings defined in [RFC1349] is deprecated. Nodes which are non-DS-compliant and which are not legacy nodes may exhibit unpredictable forwarding behaviors for packets with non-zero DS codepoints.
非差別化サービス準拠ノード（非DS準拠ノード）は、[DSFIELD]で指定されたDSフィールドを解釈せず、かつ/または標準化されたPHB（またはそれらの一部）を実装しないノードとして定義します。特定のDSドメイン内で使用中）。これは、ノードの機能または構成が原因である可能性があります。 [RFC791、RFC1812]で定義されているようにIPv4優先順位の分類と転送を実装しているが、それ以外の場合はDSに準拠していない、DSに準拠していないノードの特殊なケースとしてレガシーノードを定義します。 IPv4 TOSオクテットの優先値は、[DSFIELD]で定義されたクラスセレクタコードポイントと意図的に互換性があり、[RFC791、RFC1812]で定義された優先転送動作は、[DSFIELD]でも定義されたクラスセレクタPHB要件に準拠しています。レガシーノードとDS準拠ノードの主な違いは、レガシーノードが[RFC1349]で定義されているTOSオクテットのビット3〜6（「DTRC」ビット）を解釈する場合と解釈しない場合があります。実際には、これらのビットは[DSFIELD]で指定されているように解釈されません。 [RFC1349]で定義されているTOSマーキングの使用は非推奨であると想定しています。 DSに準拠しておらず、レガシーノードではないノードは、DSコードポイントがゼロ以外のパケットに対して、予測できない転送動作を示す可能性があります。
Differentiated services depend on the resource allocation mechanisms provided by per-hop behavior implementations in nodes. The quality or statistical assurance level of a service may break down in the event that traffic transits a non-DS-compliant node, or a non-DS-capable domain.
差別化されたサービスは、ノードのホップごとの動作の実装によって提供されるリソース割り当てメカニズムに依存します。サービスの品質または統計的保証レベルは、トラフィックがDSに準拠していないノードまたはDSに対応していないドメインを通過する場合に故障する可能性があります。
We will examine two separate cases. The first case concerns the use of non-DS-compliant nodes within a DS domain. Note that PHB forwarding is primarily useful for allocating scarce node and link resources in a controlled manner. On high-speed, lightly loaded links, the worst-case packet delay, jitter, and loss may be negligible, and the use of a non-DS-compliant node on the upstream end of such a link may not result in service degradation. In more realistic circumstances, the lack of PHB forwarding in a node may make it impossible to offer low-delay, low-loss, or provisioned bandwidth services across paths which traverse the node. However, use of a legacy node may be an acceptable alternative, assuming that the DS domain restricts itself to using only the Class Selector Codepoints defined in [DSFIELD], and assuming that the particular precedence implementation in the legacy node provides forwarding behaviors which are compatible with the services offered along paths which traverse that node. Note that it is important to restrict the codepoints in use to the Class Selector Codepoints, since the legacy node may or may not interpret bits 3-5 in accordance with [RFC1349], thereby resulting in unpredictable forwarding results.
2つの個別のケースを検討します。最初のケースは、DSドメイン内での非DS準拠ノードの使用に関するものです。 PHB転送は、制御された方法で希少なノードとリンクのリソースを割り当てる場合に主に役立ちます。高速で負荷が軽いリンクでは、最悪の場合のパケット遅延、ジッター、および損失は無視できる場合があり、そのようなリンクのアップストリームエンドでDSに準拠していないノードを使用しても、サービスが低下することはありません。より現実的な状況では、ノードにPHB転送がないため、ノードを通過するパス全体に低遅延、低損失、またはプロビジョニングされた帯域幅サービスを提供できない場合があります。ただし、レガシーノードの使用は、DSドメインが[DSFIELD]で定義されたクラスセレクターコードポイントのみを使用するように制限し、レガシーノードの特定の優先順位の実装が互換性のある転送動作を提供すると想定して、許容できる代替手段となる場合がありますそのノードを通過するパスに沿って提供されるサービス。レガシーノードは[RFC1349]に従ってビット3〜5を解釈する場合としない場合があるため、使用中のコードポイントをクラスセレクターコードポイントに制限することが重要であり、予測できない転送結果が生じることに注意してください。
The second case concerns the behavior of services which traverse non-DS-capable domains. We assume for the sake of argument that a non-DS-capable domain does not deploy traffic conditioning functions on domain boundary nodes; therefore, even in the event that the domain consists of legacy or DS-compliant interior nodes, the lack of traffic enforcement at the boundaries will limit the ability to consistently deliver some types of services across the domain. A DS domain and a non-DS-capable domain may negotiate an agreement which governs how egress traffic from the DS-domain should be marked before entry into the non-DS-capable domain. This agreement might be monitored for compliance by traffic sampling instead of by rigorous traffic conditioning. Alternatively, where there is knowledge that the non-DS-capable domain consists of legacy nodes, the upstream DS domain may opportunistically re-mark differentiated services traffic to one or more of the Class Selector Codepoints. Where there is no knowledge of the traffic management capabilities of the downstream domain, and no agreement in place, a DS domain egress node may choose to re-mark DS codepoints to zero, under the assumption that the non-DS-capable domain will treat the traffic uniformly with best-effort service.
2番目のケースは、DSに対応していないドメインを通過するサービスの動作に関するものです。議論のために、非DS対応ドメインはトラフィック調整機能をドメイン境界ノードに展開しないと仮定します。したがって、ドメインがレガシーまたはDS準拠の内部ノードで構成されている場合でも、境界にトラフィックを適用しないと、ドメイン全体である種のサービスを一貫して提供する機能が制限されます。 DSドメインと非DS対応ドメインは、非DS対応ドメインに入る前に、DSドメインからの下りトラフィックをどのようにマークする必要があるかを管理する合意を交渉する場合があります。この合意は、厳密なトラフィック調整ではなく、トラフィックサンプリングによってコンプライアンスを監視される場合があります。または、DSに対応していないドメインがレガシーノードで構成されていることがわかっている場合、上流のDSドメインは、1つ以上のクラスセレクターコードポイントへの差別化されたサービストラフィックを日和見的に再マーキングできます。ダウンストリームドメインのトラフィック管理機能についての知識がなく、適切な合意がない場合、DSドメインの出口ノードは、DSに対応していないドメインが処理するという前提の下で、DSコードポイントをゼロに再マークすることを選択できます。ベストエフォートサービスでトラフィックを均一にします。
In the event that a non-DS-capable domain peers with a DS domain, traffic flowing from the non-DS-capable domain should be conditioned at the DS ingress node of the DS domain according to the appropriate SLA or policy.
DS非対応ドメインがDSドメインとピアリングする場合、非DS対応ドメインから流れるトラフィックは、適切なSLAまたはポリシーに従って、DSドメインのDS入力ノードで調整される必要があります。
Use of differentiated services by multicast traffic introduces a number of issues for service provisioning. First, multicast packets which enter a DS domain at an ingress node may simultaneously take multiple paths through some segments of the domain due to multicast packet replication. In this way they consume more network resources than unicast packets. Where multicast group membership is dynamic, it is difficult to predict in advance the amount of network resources that may be consumed by multicast traffic originating from an upstream network for a particular group. A consequence of this uncertainty is that it may be difficult to provide quantitative service guarantees to multicast senders. Further, it may be necessary to reserve codepoints and PHBs for exclusive use by unicast traffic, to provide resource isolation from multicast traffic.
マルチキャストトラフィックによる差別化サービスの使用には、サービスプロビジョニングに関する多くの問題があります。まず、入口ノードでDSドメインに入るマルチキャストパケットは、マルチキャストパケットの複製により、ドメインの一部のセグメントを介して同時に複数のパスを通過する場合があります。このようにして、ユニキャストパケットよりも多くのネットワークリソースを消費します。マルチキャストグループメンバーシップが動的である場合、特定のグループのアップストリームネットワークから発信されるマルチキャストトラフィックによって消費される可能性があるネットワークリソースの量を事前に予測することは困難です。この不確実性の結果として、マルチキャスト送信者に定量的なサービス保証を提供することが難しい場合があります。さらに、マルチキャストトラフィックからリソースを分離するために、ユニキャストトラフィック専用のコードポイントとPHBを予約する必要がある場合があります。
The second issue is the selection of the DS codepoint for a multicast packet arriving at a DS ingress node. Because that packet may exit the DS domain at multiple DS egress nodes which peer with multiple downstream domains, the DS codepoint used should not result in the request for a service from a downstream DS domain which is in violation of a peering SLA. When establishing classifier and traffic conditioner state at an DS ingress node for an aggregate of traffic receiving a differentiated service which spans across the egress boundary of the domain, the identity of the adjacent downstream transit domain and the specifics of the corresponding peering SLA can be factored into the configuration decision (subject to routing policy and the stability of the routing infrastructure). In this way peering SLAs with downstream DS domains can be partially enforced at the ingress of the upstream domain, reducing the classification and traffic conditioning burden at the egress node of the upstream domain. This is not so easily performed in the case of multicast traffic, due to the possibility of dynamic group membership. The result is that the service guarantees for unicast traffic may be impacted. One means of addressing this problem is to establish a separate peering SLA for multicast traffic, and to either utilize a particular set of codepoints for multicast packets, or to implement the necessary classification and traffic conditioning mechanisms in the DS egress nodes to provide preferential isolation for unicast traffic in conformance with the peering SLA with the downstream domain.
2番目の問題は、DS入力ノードに到着するマルチキャストパケットのDSコードポイントの選択です。そのパケットは、複数のダウンストリームドメインとピアリングする複数のDS出力ノードでDSドメインを出る可能性があるため、使用されるDSコードポイントは、ピアリングSLAに違反するダウンストリームDSドメインからのサービスのリクエストを引き起こすべきではありません。ドメインの出口境界にまたがる差別化サービスを受信するトラフィックの集約に対して、DS入力ノードで分類子とトラフィックコンディショナーの状態を確立する場合、隣接するダウンストリームトランジットドメインのIDと、対応するピアリングSLAの詳細を考慮することができます。構成の決定（ルーティングポリシーとルーティングインフラストラクチャの安定性に依存）このようにして、ダウンストリームDSドメインとのピアリングSLAをアップストリームドメインの入口で部分的に実施でき、アップストリームドメインの出口ノードでの分類とトラフィック調整の負担を軽減します。マルチキャストトラフィックの場合、動的グループメンバーシップの可能性があるため、これはそれほど簡単には実行されません。その結果、ユニキャストトラフィックのサービス保証が影響を受ける可能性があります。この問題に対処する1つの方法は、マルチキャストトラフィックに個別のピアリングSLAを確立し、マルチキャストパケットに特定のコードポイントセットを利用するか、DS出力ノードに必要な分類とトラフィック調整メカニズムを実装して、ダウンストリームドメインとのピアリングSLAに準拠したユニキャストトラフィック。
This section addresses 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 (Sec. 6.1). In addition, the operation of differentiated services in the presence of IPsec and its interaction with IPsec are also discussed (Sec. 6.2), as well as auditing requirements (Sec. 6.3). This section considers issues introduced by the use of both IPsec and non-IPsec tunnels.
このセクションでは、差別化されたサービスの導入によって引き起こされるセキュリティの問題、主にサービス拒否攻撃の可能性、および不正なトラフィックによるサービスの盗用の可能性（セクション6.1）を扱います。さらに、IPsecが存在する場合の差別化されたサービスの操作とIPsecとの相互作用についても説明し（セクション6.2）、監査要件（セクション6.3）についても説明します。このセクションでは、IPsecトンネルと非IPsecトンネルの両方を使用することによって発生する問題について検討します。
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 resource management 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 field, and hence an adversary may be able to obtain better service by modifying the DS field to codepoints indicating behaviors used for enhanced services or by injecting packets with the DS field set to such codepoints. Taken to its limits, this 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 such theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS boundary nodes along with security and integrity of the network infrastructure within a DS domain.
差別化サービスの主な目的は、共通のネットワークインフラストラクチャ上のトラフィックストリームにさまざまなレベルのサービスを提供できるようにすることです。さまざまなリソース管理手法を使用してこれを実現できますが、最終的には、一部のパケットが他のパケットとは異なる（たとえば、より良い）サービスを受け取ることになります。異なる（たとえば、より良いまたはより悪い）サービスをもたらす特定の動作へのネットワークトラフィックのマッピングは、主にDSフィールドによって示されます。したがって、攻撃者はDSフィールドを使用する動作を示すコードポイントに変更することにより、より良いサービスを取得できる可能性があります拡張サービスの場合、またはDSフィールドがそのようなコードポイントに設定されたパケットを挿入する場合。限界に達すると、このサービスの盗難は、変更または挿入されたトラフィックが、それおよび他のトラフィックストリームを転送するために利用可能なリソースを使い果たすと、サービス拒否攻撃になります。このようなサービスの盗難やサービス拒否攻撃に対する防御は、DS境界ノードでのトラフィック調整と、DSドメイン内のネットワークインフラストラクチャのセキュリティと整合性の組み合わせで構成されます。
As described in Sec. 2, DS ingress nodes must condition all traffic entering a DS domain to ensure that it has acceptable DS codepoints. This means that the codepoints must conform to the applicable TCA(s) and the domain's service provisioning policy. Hence, the ingress nodes are the primary line of defense against theft- and denial-of-service attacks based on modified DS codepoints (e.g., codepoints to which the traffic is not entitled), as success of any such attack constitutes a violation of the applicable TCA(s) and/or service provisioning policy. An important instance of an ingress node is that any traffic-originating node in a DS domain is the ingress node for that traffic, and must ensure that all originated traffic carries acceptable DS codepoints.
Sec。 2、DS入力ノードは、DSドメインに入るすべてのトラフィックを調整して、受け入れ可能なDSコードポイントがあることを確認する必要があります。つまり、コードポイントは、該当するTCAおよびドメインのサービスプロビジョニングポリシーに準拠する必要があります。したがって、このような攻撃が成功すると違反するため、入力ノードは、変更されたDSコードポイント（トラフィックに資格のないコードポイントなど）に基づく盗難およびサービス拒否攻撃に対する主要な防御線です。該当するTCAおよび/またはサービスプロビジョニングポリシー。入力ノードの重要なインスタンスは、DSドメイン内のトラフィック発信ノードがそのトラフィックの入力ノードであり、すべての発信トラフィックが受け入れ可能なDSコードポイントを確実に運ぶようにする必要があることです。
Both a domain's service provisioning policy and TCAs may require the ingress nodes to change the DS codepoint on some entering packets (e.g., an ingress router may set the DS codepoint of a customer's traffic in accordance with the appropriate SLA). Ingress nodes must condition all other inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to the Default PHB codepoint [DSFIELD]. Traffic authentication may be required to validate the use of some DS codepoints (e.g., those corresponding to enhanced services), and such authentication may be performed by technical means (e.g., IPsec) and/or non-technical means (e.g., the inbound link is known to be connected to exactly one customer site).
ドメインのサービスプロビジョニングポリシーとTCAの両方で、入力ノードがいくつかの入力パケットのDSコードポイントを変更する必要がある場合があります（たとえば、入力ルーターが適切なSLAに従って顧客のトラフィックのDSコードポイントを設定する場合があります）。入力ノードは、DSコードポイントが受け入れ可能であることを確認するために、他のすべての受信トラフィックを調整する必要があります。受け入れられないコードポイントがあることが判明したパケットは、破棄するか、転送する前にDSコードポイントを受け入れ可能な値に変更する必要があります。たとえば、拡張サービス契約が存在しないドメインからトラフィックを受信する入口ノードは、DSコードポイントをデフォルトのPHBコードポイント[DSFIELD]にリセットする場合があります。一部のDSコードポイント（拡張サービスに対応するものなど）の使用を検証するためにトラフィック認証が必要な場合があり、そのような認証は技術的手段（IPsecなど）や非技術的手段（インバウンドリンクなど）で実行できます。正確に1つのカスタマーサイトに接続されていることがわかっています）。
An inter-domain agreement may reduce or eliminate the need for ingress node traffic conditioning by making the upstream domain partly or completely responsible for ensuring that traffic has DS codepoints acceptable to the downstream domain. In this case, the ingress node may still perform redundant traffic conditioning checks to reduce the dependence on the upstream domain (e.g., such checks can prevent theft-of-service attacks from propagating across the domain boundary). If such a check fails because the upstream domain is not fulfilling its responsibilities, that failure is an auditable event; the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that caused the failure. In practice, the limited gains from such checks need to be weighed against their potential performance impact in determining what, if any, checks to perform under these circumstances.
ドメイン間の合意により、アップストリームドメインが部分的または完全に責任を持って、ダウンストリームドメインがDSコードポイントを受け入れられるようにすることで、入口ノードのトラフィック調整の必要性を軽減または排除できます。この場合でも、上流ノードへの依存を減らすために、入口ノードは冗長なトラフィック調整チェックを実行できます（たとえば、このようなチェックにより、サービスの盗難攻撃がドメイン境界を越えて伝播するのを防ぐことができます）。アップストリームドメインがその責任を果たさないためにこのようなチェックが失敗した場合、その失敗は監査可能なイベントです。生成された監査ログエントリには、パケットを受信した日時、送信元と宛先のIPアドレス、および障害の原因となったDSコードポイントが含まれているはずです。実際には、このようなチェックから得られる限定的な利益を、これらの状況下で実行するチェックがある場合は、それを決定する際のパフォーマンスへの潜在的な影響と比較検討する必要があります。
Interior nodes in a DS domain may rely on the DS field to associate differentiated services traffic with the behaviors used to implement enhanced services. Any node doing so depends on the correct operation of the DS domain to prevent the arrival of traffic with unacceptable DS codepoints. Robustness concerns dictate that the arrival of packets with unacceptable DS codepoints must not cause the failure (e.g., crash) of network nodes. Interior nodes are not responsible for enforcing the service provisioning policy (or individual SLAs) and hence are not required to check DS codepoints before using them. Interior nodes may perform some traffic conditioning checks on DS codepoints (e.g., check for DS codepoints that are never used for traffic on a specific link) to improve security and robustness (e.g., resistance to theft-of-service attacks based on DS codepoint modifications). Any detected failure of such a check is an auditable event and the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that caused the failure. In practice, the limited gains from such checks need to be weighed against their potential performance impact in determining what, if any, checks to perform at interior nodes.
DSドメインの内部ノードは、DSフィールドに依存して、差別化されたサービストラフィックを拡張サービスの実装に使用される動作に関連付けることができます。これを行うノードは、DSドメインの正しい動作に依存して、許容できないDSコードポイントを持つトラフィックの到着を防ぎます。堅牢性の懸念により、許容できないDSコードポイントを持つパケットの到着がネットワークノードの障害（クラッシュなど）を引き起こしてはならないことが規定されています。内部ノードは、サービスプロビジョニングポリシー（または個々のSLA）を適用する責任がないため、DSコードポイントを使用する前にチェックする必要はありません。内部ノードは、DSコードポイントでいくつかのトラフィック調整チェック（特定のリンクのトラフィックに使用されないDSコードポイントのチェックなど）を実行して、セキュリティと堅牢性（DSコードポイントの変更に基づくサービス盗難攻撃への耐性など）を向上させることができます。 ）。このようなチェックで検出された障害は監査可能なイベントであり、生成された監査ログエントリには、パケットを受信した日付/時刻、送信元と宛先のIPアドレス、および障害の原因となったDSコードポイントが含まれます。実際には、そのようなチェックからの限られた利益は、内部ノードで実行するチェックがある場合は、それを決定する際の潜在的なパフォーマンスへの影響と比較検討する必要があります。
Any link that cannot be adequately secured against modification of DS codepoints or traffic injection by adversaries should be treated as a boundary link (and hence any arriving traffic on that link is treated as if it were entering the domain at an ingress node). Local security policy provides the definition of "adequately secured," and such a definition may include a determination that the risks and consequences of DS codepoint modification and/or traffic injection do not justify any additional security measures for a link. Link security can be enhanced via physical access controls and/or software means such as tunnels that ensure packet integrity.
DSコードポイントの変更または攻撃者によるトラフィックインジェクションに対して適切に保護できないリンクは、境界リンクとして扱われる必要があります（したがって、そのリンクに到着するトラフィックは、それが入力ノードでドメインに入るように扱われます）。ローカルセキュリティポリシーは「適切に保護された」の定義を提供します。そのような定義には、DSコードポイントの変更やトラフィックインジェクションのリスクと結果がリンクの追加のセキュリティ対策を正当化しないという決定が含まれる場合があります。リンクのセキュリティは、物理的なアクセス制御や、パケットの完全性を保証するトンネルなどのソフトウェア手段によって強化できます。
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. In some environments, the ability to modify the DS field without affecting IPsec integrity checks may constitute a covert channel; if it is necessary to eliminate such a channel or reduce its bandwidth, the DS domains should be configured so that the required processing (e.g., set all DS fields on sensitive traffic to a single value) can be performed at DS egress nodes where traffic exits higher security domains.
[ESP、AH]で定義されているIPsecプロトコルは、暗号化計算のいずれにもIPヘッダーのDSフィールドを含めません（トンネルモードの場合、含まれないのは外部IPヘッダーのDSフィールドです）。したがって、ネットワークノードによるDSフィールドの変更は、IPsecの整合性チェックが失敗することはないため、IPsecのエンドツーエンドのセキュリティには影響しません。その結果、IPsecは、敵対者の変更がIPsecのエンドツーエンドのセキュリティに影響を与えないため、敵対者のDSフィールドの変更（つまり、中間者攻撃）に対する防御を提供しません。一部の環境では、IPsec整合性チェックに影響を与えずにDSフィールドを変更する機能が、隠れチャネルを構成する場合があります。そのようなチャネルを排除するか、帯域幅を減らす必要がある場合は、DSドメインを構成して、トラフィックが存在するDS出力ノードで必要な処理（たとえば、機密トラフィックのすべてのDSフィールドを単一の値に設定する）を実行できるようにするより高いセキュリティドメイン。
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 stripping the outer header and forwarding the packet (if required) using the inner header. If the inner IP header has not been processed by a DS ingress node for the tunnel egress node's DS domain, the tunnel egress node is the DS ingress node for traffic exiting the tunnel, and hence must carry out the corresponding traffic conditioning responsibilities (see Sec. 6.1). If the IPsec 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. This allows a tunnel egress node in the same DS domain as the tunnel ingress node, to safely treat a packet passing such an integrity check as if it had arrived from another node within the same DS domain, omitting the DS ingress node traffic conditioning that would otherwise be required. An important consequence is that otherwise insecure links internal to a DS domain can be secured by a sufficiently strong IPsec tunnel.
IPsecのトンネルモードは、カプセル化されたIPヘッダーのDSフィールドにセキュリティを提供します。トンネルモードのIPsecパケットには、2つのIPヘッダーが含まれています。トンネル入力ノードによって提供される外部ヘッダーと、パケットの元のソースによって提供されるカプセル化された内部ヘッダーです。 IPsecトンネルが差別化されたサービスネットワークで（全体的または部分的に）ホストされている場合、中間ネットワークノードは外部ヘッダーのDSフィールドで動作します。トンネル出口ノードでのIPsec処理には、外部ヘッダーの除去と内部ヘッダーを使用したパケット（必要な場合）の転送が含まれます。内部IPヘッダーがトンネル出力ノードのDSドメインのDS入力ノードによって処理されていない場合、トンネル出力ノードは、トンネルを出るトラフィックのDS入力ノードであり、したがって、対応するトラフィック調整の責任を実行する必要があります（セクションを参照）。 。6.1）。 IPsec処理に、カプセル化されたパケットの十分な強度の暗号化整合性チェックが含まれている場合（十分性はローカルセキュリティポリシーによって決定されます）、トンネル出力ノードは、内部ヘッダーのDSフィールドがトンネル入口ノード。これにより、トンネル入口ノードと同じDSドメイン内のトンネル出口ノードは、完全性チェックに合格したパケットを、同じDSドメイン内の別のノードから到着したかのように安全に処理し、DS入口ノードのトラフィック調整を省略して、それ以外の場合は必要です。重要な結果は、DSドメイン内部の安全でないリンクは、十分に強力なIPsecトンネルによって保護できることです。
This analysis and its implications apply to any tunneling 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 tunneling 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 DS ingress node from outside the domain.
この分析とその影響は、整合性チェックを実行するすべてのトンネリングプロトコルに適用されますが、内部ヘッダーのDSフィールドの保証レベルは、トンネリングプロトコルによって実行される整合性チェックの強度に依存します。現在のDSドメイン外のノードを通過する可能性がある（または他の方法で脆弱な）トンネルが十分に保証されていない場合、カプセル化されたパケットは、ドメイン外からDS入力ノードに到着したかのように処理する必要があります。
The IPsec protocol currently requires that the inner header's DS field not be changed by IPsec decapsulation processing at a tunnel egress node. This ensures that an adversary's modifications to the DS field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint, as any such modifications will be discarded at the tunnel endpoint. This document makes no change to that IPsec requirement.
現在、IPsecプロトコルでは、トンネルの出口ノードでのIPsecカプセル化解除処理によって内部ヘッダーのDSフィールドを変更しないようにする必要があります。これにより、DSフィールドに対する攻撃者の変更を使用して、IPsecトンネルエンドポイント全体での盗難またはサービス拒否攻撃を開始できなくなります。そのような変更はトンネルエンドポイントで破棄されるためです。このドキュメントは、そのIPsec要件に変更を加えません。
If the IPsec specifications are modified in the future to permit a tunnel egress node to modify the DS field in an inner IP header based on the DS field value in the outer header (e.g., copying part or all of the outer DS field to the inner DS field), then additional considerations would apply. For a tunnel contained entirely within a single DS domain and for which the links are adequately secured against modifications of the outer DS field, the only limits on inner DS field modifications would be those imposed by the domain's service provisioning policy. Otherwise, the tunnel egress node performing such modifications would be acting as a DS ingress node for traffic exiting the tunnel and must carry out the traffic conditioning responsibilities of an ingress node, including defense against theft-and denial-of-service attacks (See Sec. 6.1). If the tunnel enters the DS domain at a node different from the tunnel egress node, the tunnel egress node may depend on the upstream DS ingress node having ensured that the outer DS field values are acceptable. Even in this case, there are some checks that can only be performed by the tunnel egress node (e.g., a consistency check between the inner and outer DS codepoints for an encrypted tunnel). Any detected failure of such a check is an auditable event and the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that was unacceptable.
将来、トンネル出口ノードが外部ヘッダーのDSフィールド値に基づいて内部IPヘッダーのDSフィールドを変更できるようにIPsec仕様が変更される場合（たとえば、外部DSフィールドの一部またはすべてを内部にコピーする） DSフィールド）、追加の考慮事項が適用されます。完全に単一のDSドメイン内に含まれ、リンクが外部DSフィールドの変更に対して適切に保護されているトンネルの場合、内部DSフィールドの変更に対する唯一の制限は、ドメインのサービスプロビジョニングポリシーによって課される制限です。それ以外の場合、このような変更を実行するトンネル出口ノードは、トンネルを出るトラフィックのDS入力ノードとして機能し、盗難やサービス拒否攻撃に対する防御を含む、入口ノードのトラフィック調整の責任を実行する必要があります（セクションを参照）。 。6.1）。トンネルが、トンネル出口ノードとは異なるノードでDSドメインに入る場合、トンネル出口ノードは、上流DS入力ノードが外部DSフィールド値が受け入れ可能であることを確認していることに依存する場合があります。この場合でも、トンネル出口ノードでのみ実行できるいくつかのチェックがあります（暗号化されたトンネルの内部DSコードポイントと外部DSコードポイント間の整合性チェックなど）。このようなチェックで検出された障害は監査可能なイベントであり、生成された監査ログエントリには、パケットが受信された日付/時刻、送信元と宛先のIPアドレス、および受け入れられなかったDSコードポイントが含まれます。
An IPsec tunnel can be viewed in at least two different ways from an architectural perspective. If the tunnel is viewed as a logical single hop "virtual wire", the actions of intermediate nodes in forwarding the tunneled traffic should not be visible beyond the ends of the tunnel and hence the DS field should not be modified as part of decapsulation processing. In contrast, if the tunnel is viewed as a multi-hop participant in forwarding traffic, then modification of the DS field as part of tunnel decapsulation processing may be desirable. A specific example of the latter situation occurs when a tunnel terminates at an interior node of a DS domain at which the domain administrator does not wish to deploy traffic conditioning logic (e.g., to simplify traffic management). This could be supported by using the DS codepoint in the outer IP header (which was subject to traffic conditioning at the DS ingress node) to reset the DS codepoint in the inner IP header, effectively moving DS ingress traffic conditioning responsibilities from the IPsec tunnel egress node to the appropriate upstream DS ingress node (which must already perform that function for unencapsulated traffic).
IPsecトンネルは、アーキテクチャの観点から、少なくとも2つの異なる方法で表示できます。トンネルが論理的なシングルホップの「仮想ワイヤー」として表示される場合、トンネル化されたトラフィックを転送する際の中間ノードのアクションはトンネルの両端を越えて見えないはずであり、したがってカプセル化処理の一部としてDSフィールドを変更しないでください。対照的に、トンネルがトラフィック転送のマルチホップ参加者と見なされる場合、トンネルのカプセル化解除処理の一部としてDSフィールドを変更することが望ましい場合があります。後者の状況の具体例は、トンネルがDSドメインの内部ノードで終了し、ドメイン管理者がトラフィック調整ロジックを展開したくない場合（トラフィック管理を簡略化するためなど）に発生します。これは、外部IPヘッダーのDSコードポイントを使用して（DS入力ノードでのトラフィック調整の対象）、内部IPヘッダーのDSコードポイントをリセットし、DS入力トラフィック調整の責任をIPsecトンネル出力から効果的に移動することでサポートできます。ノードを適切なアップストリームDS入力ノード（カプセル化されていないトラフィックに対してその機能をすでに実行している必要があります）。
Not all systems that support differentiated services will implement auditing. However, if differentiated services support is incorporated into a system that supports auditing, then the differentiated services implementation should also support auditing. If such support is present the implementation must allow a system administrator to enable or disable auditing for differentiated services as a whole, and may allow such auditing to be enabled or disabled in part.
差別化されたサービスをサポートするすべてのシステムが監査を実装するわけではありません。ただし、監査をサポートするシステムに差別化サービスのサポートが組み込まれている場合、差別化サービスの実装も監査をサポートする必要があります。そのようなサポートが存在する場合、実装では、システム管理者が差別化されたサービス全体の監査を有効または無効にできるようにする必要があり、そのような監査を部分的に有効または無効にできる場合があります。
For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this document and for each of these events a minimum set of information that should be included in an audit log is defined. Additional information (e.g., packets related to the one that triggered the auditable event) may also be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also may result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
ほとんどの場合、監査の粒度はローカルな問題です。ただし、このドキュメントではいくつかの監査可能なイベントが特定されており、これらのイベントごとに、監査ログに含める必要がある情報の最小セットが定義されています。これらの各イベントの監査ログには、追加情報（監査可能なイベントをトリガーしたパケットに関連するパケットなど）も含まれる場合があり、この仕様で明示的に呼び出されていない追加のイベントも監査ログエントリになることがあります。監査可能なイベントの検出に応答して、意図された送信者にメッセージを送信する必要はありません。これは、そのようなアクションによってサービス拒否を引き起こす可能性があるためです。
This document has benefitted from earlier drafts by Steven Blake, David Clark, Ed Ellesson, Paul Ferguson, Juha Heinanen, Van Jacobson, Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John Wroclawski, and Lixia Zhang.
このドキュメントは、Steven Blake、David Clark、Ed Ellesson、Paul Ferguson、Juha Heinanen、Van Jacobson、Kalevi Kilkki、Kathleen Nichols、Walter Weiss、John Wroclawski、およびLixia Zhangによる以前のドラフトから恩恵を受けています。
The authors would like to acknowledge the following individuals for their helpful comments and suggestions: Kathleen Nichols, Brian Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, Borje Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Hamid Ould-Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O'Neill, James Fu, and Bob Braden.
著者は、役立つコメントと提案について、次の個人に感謝します。 、スコット・ブリム、カーティス・ビラミザール、ハミド・オールド・ブラヒ、アンドリュー・スミス、ジョン・レンウィック、ワーナー・アルメスバーガー、アラン・オニール、ジェームズ・フー、ボブ・ブレーデン。
[802.1p] ISO/IEC Final CD 15802-3 Information technology - Tele-communications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15).
[802.1p] ISO / IEC Final CD 15802-3情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-共通仕様-パート3：メディアアクセスコントロール（MAC）ブリッジ（IEEEとして利用可能な現在のドラフト） P802.1D / D15）。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S.、R。アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[ATM] ATM Traffic Management Specification Version 4.0 <af-tm-0056.000>, ATM Forum, April 1996.
[ATM] ATMトラフィック管理仕様バージョン4.0 <af-tm-0056.000>、ATMフォーラム、1996年4月。
[Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. Nichols, and M. Speer, "A Framework for Use of RSVP with Diff-serv Networks", Work in Progress.
[Bernet] Y. Bernet、R。Yavatkar、P。Ford、F。Baker、L。Zhang、K。Nichols、およびM. Speer、「Diff-servネットワークでRSVPを使用するためのフレームワーク」、作業中。
[DSFIELD] 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.
[DSFIELD] Nichols、K.、Blake、S.、Baker、F.、D。Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年12月。
[EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", IEEE/ACM Trans. on Networking, vol. 6, no. 4, August 1998, pp. 362-373.
[EXPLICIT] D.クラークとW.ファング、「ベストエフォートパケット配信サービスの明示的割り当て」、IEEE / ACMトランス。ネットワーキング、巻。 6、いいえ。 1998年8月4日、362-373ページ。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IP Encapsulating Security Payload（ESP）」、RFC 2406、1998年11月。
[FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
[リレー] ANSI T1S1、「フレームリレーのDSSIコアの側面」、1990年3月。
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、編集者、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349] Almquist、P。、「インターネットプロトコルスイートのサービスタイプ」、RFC 1349、1992年7月。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, July 1994.
[RFC1633] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年7月。
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、編集者、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、B.、Zhang、L.、Berson S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.
[2BIT] K. Nichols、V。Jacobson、およびL. Zhang、「インターネット用の2ビットの差別化サービスアーキテクチャ」、ftp：//ftp.ee.lbl.gov/papers/dsarch.pdf、1997年11月。
[TR] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token Ring Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.5- 1995), 1995.
[TR] ISO / IEC 8802-5情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-共通仕様-パート5：トークンリングアクセス方法および物理層仕様（ANSI / IEEE Std 802.5- 1995） 、1995年。
Authors' Addresses
著者のアドレス
Steven Blake Torrent Networking Technologies 3000 Aerial Center, Suite 140 Morrisville, NC 27560
Steven Blake Torrent Networking Technologies 3000 Aerial Center、Suite 140 Morrisville、NC 27560
Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.com
David L. Black EMC Corporation 35 Parkwood Drive Hopkinton, MA 01748
David L.Black EMC Corporation 35 Parkwood Drive Hopkinton、MA 01748
Phone: +1-508-435-1000 x76140
EMail: black_david@emc.com
Mark A. Carlson Sun Microsystems, Inc. 2990 Center Green Court South Boulder, CO 80301
Mark A. Carlson Sun Microsystems、Inc. 2990 Center Green Court South Boulder、CO 80301
Phone: +1-303-448-0048 x115
EMail: mark.carlson@sun.com
Elwyn Davies Nortel UK London Road Harlow, Essex CM17 9NA, UK
Elwyn Davies Nortel UK London Road Harlow、Essex CM17 9NA、UK
Phone: +44-1279-405498 EMail: elwynd@nortel.co.uk Zheng Wang Bell Labs Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733
電話：+ 44-1279-405498メール：elwynd@nortel.co.uk Zheng Wang Bell Labs Lucent Technologies 101 Crawfords Corner Road Holmdel、NJ 07733
EMail: zhwang@bell-labs.com
Walter Weiss Lucent Technologies 300 Baker Avenue, Suite 100 Concord, MA 01742-2168
Walter Weiss Lucent Technologies 300 Baker Avenue、Suite 100 Concord、MA 01742-2168
EMail: wweiss@lucent.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。