Network Working Group K. Chan
Request for Comments: 5127 J. Babiarz
Category: Informational Nortel
F. Baker
Cisco Systems
February 2008
Aggregation of Diffserv Service Classes
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end-to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments.
大容量ネットワークのコアでは、サービスの差別化は、まだネットワークのアプリケーションの利用をサポートするために必要とすることができます。同様のトラフィック特性と性能要件を持つアプリケーションは、アプリケーションのエンド・ツー・エンドの動作要件に基づいたDiffservサービスクラスにマッピングされます。しかし、いくつかのネットワークセグメントは、単一の転送処理は、2つの以上のサービスクラスのトラフィック特性及び性能要件を満たすことができるように構成されてもよいです。これらの場合には、単一の転送処理中に二つ以上のDiffservサービスクラスを集約することが望ましい場合があります。この文書では、治療を転送するにはDiffservサービスクラスの集約のためのガイドラインを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Service Class Aggregation . . . . . . . . . . . . 5
4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6
4.1. Mapping Service Classes into Four Treatment Aggregates . . 7
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9
4.1.2. Real-Time Treatment Aggregate . . . . . . . . . . . . 10
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12
5. Treatment Aggregates and Inter-Provider Relationships . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 15
A.1. Network Control Treatment Aggregate with E-LSP . . . . . . 17
A.2. Real-Time Treatment Aggregate with E-LSP . . . . . . . . . 17
A.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 17
A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 17
A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 18
In the core of a high capacity network, it is common for the network to be engineered in such a way that a major link, switch, or router can fail, and the result will be a routed network that still meets ambient Service Level Agreements (SLAs). The implications are that there is sufficient capacity on any given link such that all SLAs sold can be simultaneously supported at their respective maximum rates, and that this remains true after re-routing (either IP re-routing or Multiprotocol Label Switching (MPLS) protection-mode switching) has occurred.
ネットワークは、主要なリンク、スイッチ、またはルータに障害が発生することができ、その結果は（まだ周囲サービスレベル契約を満たしてルーティングされたネットワークになるように設計されるため、高容量のネットワークのコアでは、それが一般的ですSLA）。意味が販売されるすべてのSLAが同時にそのそれぞれの最大レートでサポートすることができ、これは再ルーティング（いずれかのIPの再ルーティングまたはマルチプロトコルラベルスイッチング（MPLS）保護した後、真のままであるように任意のリンク上の十分な容量があることがあります-mode切り替え）が発生しました。
Over-provisioning is generally considered to meet the requirements of all traffic without further quality of service (QoS) treatment, and in the general case, that is true in high-capacity backbones. However, as the process of network convergence continues, and with the increasing speed of the access networks, certain services may still have issues. Delay, jitter, and occasional loss are perfectly acceptable for elastic applications. However, sub-second surges that occur in the best-designed of networks [12] affect real-time applications. Moreover, denial of service (DoS) loads, worms, and network disruptions such as that of 11 September 2001 affect routing [13]. Our objective is to prevent disruption to routing (which in turn affects all services) and to protect real-time jitter-sensitive services, while minimizing loss and delay of sensitive elastic traffic.
オーバープロビジョニング、一般的に更なるサービス品質（QoS）の処理をせずに、すべてのトラフィックの要件を満たすと考えられ、一般的なケースでは、それは大容量バックボーンに本当です。ネットワークコンバージェンスのプロセスは、アクセス網の増加速度を続行しかし、特定のサービスが、まだ問題がある場合があります。遅延、ジッタ、および臨時の損失は弾性用途のために完全に受け入れています。しかし、ネットワークの最もよく設計された中で発生したサブ秒のサージは、[12]リアルタイム・アプリケーションに影響を与えます。また、このような2001年9月11日のそのようなサービス拒否（DoS）負荷、ワーム、およびネットワークの中断の拒否は、ルーティングに影響[13]。我々の目的は、敏感な弾性トラフィックの損失や遅延を最小限に抑えながら、（順番にすべてのサービスに影響を与える）のルーティングに混乱を防ぐために、リアルタイムのジッタに敏感なサービスを保護することです。
RFC 4594 [3] defines a set of basic Diffserv classes from the points of view of the application requiring specific end-to-end behaviors from the network. The service classes are differentiated based on the application payload's tolerance to packet loss, delay, and delay variation (jitter). Different degrees of these criteria form the foundation for supporting the needs of real-time and elastic traffic. RFC 4594 [3] also provides recommendations for the treatment method of these service classes. But, at some network segments of the end-to-end path, the number of levels of network treatment differentiation may be less than the number of service classes that the network segment needs to support. In such a situation, that network segment may use the same treatment to support more than one service class. In this document, we provide guidelines on how multiple service classes may be aggregated into a forwarding treatment aggregate. This entails having the IP traffic belonging to service classes, expressed using the DSCP (Differentiated Services Code Point), as described by RFC 4594 [3]. Note that in a given domain, we may recommend that the supported service classes be aggregated into forwarding treatment aggregates; however, this does not mean all service classes need to be supported, and hence not all forwarding treatment aggregates need to be supported. A domain may support a fewer or greater number of forwarding treatment aggregates than recommended by this document. Which service classes and which forwarding treatment aggregates are supported by a domain is up to the domain administration and may be influenced by business reasons or other reasons (e.g., operational considerations).
RFC 4594 [3]は、ネットワークから特定のエンド・ツー・エンドの行動を必要とするアプリケーションの視点から基本のDiffservクラスのセットを定義します。サービスクラスは、パケットロス、遅延、および遅延変動（ジッタ）へのアプリケーションペイロードの許容度に基づいて区別されています。これらの基準の異なる程度は、リアルタイムと弾性トラフィックのニーズをサポートするための基盤を形成します。 RFC 4594 [3]また、これらのサービスクラスの治療法のための推奨事項を提供します。しかし、エンドツーエンドパスのいくつかのネットワークセグメントで、ネットワーク処理の分化のレベルの数は、ネットワークセグメントをサポートする必要があるサービスクラスの数より少なくてもよいです。このような状況では、そのネットワークセグメントは、複数のサービス・クラスをサポートするために同じ処理を使用してもよいです。この文書では、我々は、転送処理の集約に集約することができる方法を、複数のサービスクラスのガイドラインを提供しています。これはサービスクラスに属するIPトラフィックを有する伴う、RFC 4594によって記載されているように[3]、DSCP（DiffServコードポイント）を使用して発現させました。特定のドメインに、私たちがサポートするサービスクラスが転送処理凝集体に集約することを勧告することができることに注意してください。しかし、これはすべてのサービスクラスがサポートされる必要があり、したがってすべての転送処理凝集体がサポートする必要がないという意味ではありません。この文書が推奨するよりドメインが転送処理凝集体のより少ないまたはより多い数をサポートすることができます。どのサービスクラスおよびそのドメインによってサポートされている治療凝集体を転送すると、ドメイン管理までで、ビジネス上の理由やその他の理由（例えば、運用の考慮）によって影響を受ける可能性があります。
In this document, we've provided:
この文書では、我々は提供してきました：
o definitions for terminology we use in this document,
Oの用語の定義は、私たちは、このドキュメントで使用し、
o requirements for performing this aggregation,
この集約を実行するための要件O、
o an example of performing the aggregation when four treatment aggregates are used, and
O 4つの処置凝集体が使用されるアグリゲーションを行う例、及び
o an example (in the appendix) of performing this aggregation over MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP).
E-LSP、EXP推論PHBスケジューリングクラス（PSC）ラベルスイッチパス（LSP）を使用して、MPLS上にこの凝集を行う（付録の）例O。
The treatment aggregate recommendations are designed to aggregate the service classes [3] in such a manner as to protect real-time traffic and routing, on the assumption that real-time sessions are protected from each other by admission at the edge. The recommendation given is one possible way of performing the aggregation; there may be other ways of aggregation, for example, into fewer treatment aggregates or more treatment aggregates.
治療凝集勧告は、リアルタイムセッションがエッジで入院によって互いに保護されていると仮定して、リアルタイムトラフィックとルーティングを保護するように[3]サービスクラスを集約するように設計されています。与えられた勧告はアグリゲーションを行う1つの可能な方法です。凝集の、例えば、より少ない治療凝集以上の治療凝集体に他の方法が存在してもよいです。
In the appendix, an example of aggregation over MPLS networks using E-LSP to realize the treatment aggregates is provided. Note that the MPLS E-LSP is just an example; this document does not exclude the use of other methods. This example only considers aggregation of IP traffic into E-LSP. The use of E-LSP by non-IP traffic is not discussed.
付録では、処理凝集体を実現するE-LSPを使用してMPLSネットワークを介した凝集の例が提供されます。 MPLS E-LSPは単なる例であることに注意してください。このドキュメントは、他の方法の使用を排除するものではありません。この例は、E-LSPにIPトラフィックの集約を検討します。非IPトラフィックによるE-LSPの使用が議論されていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
This document assumes the reader is familiar with the terms used in differentiated services. This document provides the definitions for new terms introduced by this document and references information defined in RFCs for existing terms not commonly used in differentiated services.
この文書では、読者が差別化されたサービスで使用される用語に精通している前提としています。この文書では、一般的に差別化されたサービスで使用されていない既存の用語のためのRFCで定義されたこの文書や参照情報によって導入された新しい用語の定義を提供します。
For new terms introduced by this document, we provide the definition here:
このドキュメントで導入された新しい用語については、ここでは定義を提供します。
o Treatment Aggregate. This term is defined as the aggregate of Diffserv service classes [3]. A treatment aggregate is concerned only with the forwarding treatment of the aggregated traffic, which may be marked with multiple DSCPs. A treatment aggregate differs from Behavior Aggregate [2] and Traffic Aggregate [14], each of which indicate the aggregated traffic having a single Diffserv codepoint and utilizing a single Per Hop Behavior (PHB).
治療集計O。この用語は、Diffservのサービス・クラスの集合体として定義される[3]。治療集合体は、複数のDSCPでマークされてもよい集約トラフィックの転送処理との関係です。処理凝集体[2]およびトラフィック集合[14]、集約トラフィックが単一のDiffservコードポイントを有し、単一ホップごとのふるまい（PHB）を利用示し各々が行動集合と異なります。
For terms from existing RFCs, we provide the reference to the appropriate section of the relevant RFC that contain the definition:
既存のRFCの用語については、我々は定義が含まれ、関連するRFCの適切なセクションへの参照を提供します。
o Real-Time and Elastic Applications and their traffic. Section 3.1 of RFC 1633 [4].
Oリアルタイムおよび弾性アプリケーションとそのトラフィック。 RFC 1633のセクション3.1 [4]。
o Diffserv Service Class. Section 1.3 of RFC 4594 [3].
DiffservのサービスクラスO。 RFC 4594のセクション1.3 [3]。
o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.2 of RFC 3270 [6].
O MPLS E-LSP、EXP推論PHBスケジューリングクラス（PSC）ラベルスイッチパス（LSP）。 RFC 3270のセクション1.2 [6]。
o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.3 of RFC 3270 [6].
O MPLS L-LSP、ラベルのみ推論PHBスケジューリングクラス（PSC）ラベルスイッチパス（LSP）。 RFC 3270のセクション1.3 [6]。
In Diffserv domains where less fine-grained traffic treatment differentiation is provided, aggregation of the different service classes [3] may be required.
以下きめ細かいトラフィック処理の分化が設けられているのDiffservドメイン、異なるサービスクラスの集合で[3]必要とされ得ます。
These aggregations have the following requirements:
これらの集計は、次の要件があります。
1. The end-to-end network performance characteristic required by the application MUST be supported. This performance characteristic is represented by the use of Diffserv service classes [3].
1.アプリケーションによって必要とされるエンドツーエンドのネットワーク性能特性をサポートしなければなりません。この性能特性は、Diffservのサービスクラス[3]を使用することによって表されます。
2. The treatment aggregate MUST meet the strictest requirements of its member service classes.
2.治療の集合体がそのメンバーのサービスクラスの最も厳しい要件を満たす必要があります。
3. The treatment aggregate SHOULD only contain member service classes with similar traffic characteristic and performance requirements.
3.治療の集計だけで同じようなトラフィックの特性と性能要件と会員サービスクラスを含むべきです。
4. The notion of the individual end-to-end service classes MUST NOT be destroyed when aggregation is performed. Each domain along the end-to-end path may perform aggregation differently, based on the original end-to-end service classes. We recommend an easy way to accomplish this by not altering the DSCP used to indicate the end-to-end service class. But some administrative domains may require the use of their own marking; when this is needed, the original end-to-end service class indication must be restored upon exiting such administrative domains. One possible way of achieving this is with the use of tunnels to encapsulate the end-to-end traffic.
集約が行われた場合4.個々のエンドツーエンドのサービスクラスの概念を破壊してはなりません。エンドツーエンドパスに沿った各ドメインは、元のエンドツーエンドのサービスクラスに基づいて、異なる集計を行ってもよいです。私たちは、エンドツーエンドのサービスクラスを示すために使用されるDSCPを変更しないことによって、これを達成する簡単な方法をお勧めします。しかし、いくつかの管理ドメインは、マーキング、独自の使用が必要な場合があります。これが必要な場合、元のエンドツーエンドのサービスクラス指示は、管理ドメインを出る時に復元しなければなりません。これを達成する1つの可能な方法は、エンドツーエンドのトラフィックをカプセル化するためのトンネルを使用しています。
5. Each treatment aggregate has limited resources; hence, traffic conditioning and/or admission control SHOULD be performed for each service class aggregated into the treatment aggregate. Additional admission control and policing may be used on the sum of all traffic aggregated into the treatment aggregate.
5.各処理の集約は、限られた資源を持っています。したがって、トラフィックコンディショニングおよび/またはアドミッション制御は、治療集合に集約各サービスクラスに対して実行されるべきです。追加の許可制御およびポリシングは、治療集合に集約するすべてのトラフィックの合計に使用することができます。
In addition to the above requirements, we have the following suggestions:
上記の要件に加えて、我々は、以下の提案があります。
1. The treatment aggregate and assigned resources may consider historical traffic patterns and the variability of these patterns. For example, a point-point service (e.g., pseudowire) may have a very predictable pattern, while a multipoint service (e.g., VPLS, Virtual Private LAN Service) may have a much less predictable pattern.
1.治療の集約と割り当てられたリソースは、過去のトラフィックパターンと、これらのパターンの変動を考慮することができます。マルチポイントサービスは、（例えば、VPLS、仮想プライベートLANサービス）ははるかに少ない予測可能なパターンを持っているかもしれないが例えば、ポイント・ポイントサービス（例えば、スードワイヤ）は、非常に予測可能なパターンを有していてもよいです。
2. In addition to Diffserv, other controls are available to influence the traffic level offered to a particular traffic aggregate. These include adjustment of routing metrics, and usage of MPLS-based traffic engineering techniques.
Diffservのに加えて2は、他のコントロールは、特定のトラフィック集約に提供されたトラフィックのレベルに影響を与えるために利用可能です。これらは、ルーティングメトリックの調整、MPLSベースのトラフィック・エンジニアリング技術の使用を含みます。
This document only describes the aggregation of IP traffic based on the use of Diffserv service classes [3].
この文書では、[3]のDiffservサービスクラスの使用に基づいてIPトラフィックの集約を説明しています。
The service class and DSCP selection in RFC 4594 [3] has been defined to allow, in many instances, mapping of two or possibly more service classes into a single forwarding treatment aggregate. Notice that there is a relationship/trade-off between link speed, queue depth, delay, and jitter. The degree of aggregation and hence the number of treatment aggregates will depend on the aggregation's impacts on loss, delay, and jitter. This depends on whether the speed of the links and scheduler behavior, being used to implement the aggregation, can minimize the effects of mixing traffic with different packet sizes and transmit rates on queue depth. A general rule-of-thumb is that higher link speeds allow for more aggregation/ smaller number of treatment aggregates, assuming link utilization is within the engineered level.
[3]多くの場合、許可するように定義されているRFC 4594のサービスクラスとDSCP選択、単一の転送処理凝集体に二つまたはおそらくそれ以上のサービスクラスのマッピング。リンク速度、キューの深さ、遅延、ジッタとの関係/トレードオフがあることに注意してください。凝集の程度、従って処理凝集体の数が減少、遅延、およびジッタに対する凝集の影響に依存するであろう。これは、リンクスケジューラの動作の速度は、凝集を実装するために使用され、異なるパケットサイズでトラフィックを混合の影響を最小限にし、キューの深さの金利を送信することができるかどうかに依存します。一般的な経験則は、より高いリンク速度は、リンクの使用率が操作されたレベルの範囲内であると仮定すると、処理凝集体のより凝集/より小さい数を可能にすることです。
This section provides an example of mapping all the service classes defined in RFC 4594 [3] into four treatment aggregates. The use of four treatment aggregates assumes that the resources allocated to each treatment aggregate are sufficient to honor the required behavior of each service class [3]. We use the performance requirement (tolerance to loss, delay, and jitter) from the application/end-user as a guide on how to map the service classes into treatment aggregates. We have also used section 3.1 of RFC 1633 [4] to provide us with guidance on the definition of Real-Time and Elastic applications. An overview of the mapping between service classes and the four treatment aggregates is provided by Figure 1, with the mapping being based on performance requirements. In Figure 1, the right side columns of "Service Class" and "Tolerance to Loss/ Delay/Jitter" are from Figure 2 of RFC 4594 [3].
このセクションでは、4つの処理凝集体への[3] RFC 4594で定義されたすべてのサービスクラスのマッピングの例を提供します。 4つの処置凝集体の使用は、各治療集合に割り当てられたリソースは、各サービス・クラス[3]の必要な行動を尊重するのに十分であることを前提としています。我々は、処理凝集体にサービスクラスをマップする方法についてのガイドとしてアプリケーション/エンドユーザからの性能要件（損失、遅延、およびジッタに対する耐性）を使用します。また、RFC 1633のセクション3.1 [4]リアルタイム・エラスティックアプリケーションの定義に関するガイダンスをご提供するために使用されてきました。サービスクラスと4つの処置凝集体との間のマッピングの概要をマッピングは性能要件に基づいていると、図1によって提供されます。図1において、右側の「サービスクラス」の列と「損失/遅延/ジッタに対する耐性は、」RFC 4594の図2からのものである[3]。
It is recommended that certain service classes be mapped into specific treatment aggregates. But this does not mean that all the service classes recommended for that treatment aggregate need to be supported. Hence, for a given domain, a treatment aggregate may contain only a subset of the service classes recommended in this document, i.e., the service classes supported by that domain. A domain's treatment of non-supported service classes should be based on the domain's local policy. This local policy may be influenced by its agreement with its customers. Such treatment may use the Elastic Treatment Aggregate, dropping the packets, or some other arrangements.
特定のサービスクラスは、特定の治療凝集体にマップされることをお勧めします。しかし、これはその治療の集計のために推奨されるすべてのサービスクラスをサポートする必要があることを意味するものではありません。したがって、所与のドメインのために、治療集合はこの文書で推奨サービスクラスのサブセットのみを含んでいてもよい、すなわち、サービスクラスは、そのドメインでサポートされています。非サポートサービスクラスのドメインの治療には、ドメインのローカルポリシーに基づいている必要があります。このローカルポリシーは、その顧客との契約によって影響を受ける可能性があります。このような治療は、パケット、またはいくつかの他の構成を落とす、弾性処理集計を使用することができます。
Our example of four treatment aggregates is based on the basic differences in performance requirement from the application/end-user perspective. A domain may choose to support more or fewer treatment aggregates than the four recommended. For example, a domain may support only three treatment aggregates and map any network control traffic into the Assured Elastic treatment aggregate. This is a choice the administrative domain has. Hence, this example of four treatment aggregates does not represent a minimum required set of treatment aggregates one must implement; nor does it represent the maximum set of treatment aggregates one can implement.
4つの治療凝集体の私達の例は、アプリケーション/エンドユーザーの視点からの性能要件における基本的な違いに基づいています。ドメインは、推奨4以上または少ない治療凝集体をサポートすることもできます。例えば、ドメインは、3つの処理凝集体をサポートしてもよいし、確実な弾性処理集計に任意のネットワーク制御トラフィックをマップします。これは、管理ドメインが持っている選択肢です。したがって、4つの治療凝集のこの例は、1つが実装しなければならない処理凝集体の必要最小限の集合を表していません。またそれは1つが実装することができ、治療凝集体の最大セットを表すん。
---------------------------------------------------------------------
|Treatment | Tolerance to ||Service Class | Tolerance to |
|Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter|
|==========+======+======+======++===============+======+======+======|
| Network | Low | Low | Yes || Network | Low | Low | Yes |
| Control | | | || Control | | | |
|==========+======+======+======++===============+======+======+======|
| Real- | Very | Very | Very || Telephony | VLow | VLow | VLow |
| Time | Low | Low | Low ||---------------+------+------+------|
| | | | || Signaling | Low | Low | Yes |
| | | | ||---------------+------+------+------|
| | | | || Multimedia |Low - | Very | Low |
| | | | || Conferencing |Medium| Low | |
| | | | ||---------------+------+------+------|
| | | | || Real-time | Low | Very | Low |
| | | | || Interactive | | Low | |
| | | | ||---------------+------+------+------|
| | | | || Broadcast | Very |Medium| Low |
| | | | || Video | Low | | |
|==========+======+======+======++===============+======+======+======|
| Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes |
| Elastic | |Medium| || Streaming |Medium| | |
| | | | ||---------------+------+------+------|
| | | | || Low-Latency | Low |Low - | Yes |
| | | | || Data | |Medium| |
| | | | ||---------------+------+------+------|
| | | | || OAM | Low |Medium| Yes |
| | | | ||---------------+------+------+------|
| | | | ||High-Throughput| Low |Medium| Yes |
| | | | || Data | |- High| |
|==========+======+======+======++===============+======+======+======|
| Elastic | Not Specified || Standard | Not Specified |
| | | | ||---------------+------+------+------|
| | | | || Low-Priority | High | High | Yes |
| | | | || Data | | | |
---------------------------------------------------------------------
Figure 1: Treatment Aggregate and Service Class Performance
Requirements
As we are recommending to preserve the notion of the individual end-to-end service classes, we also recommend that the original DSCP field marking not be changed when treatment aggregates are used. Instead, classifiers that select packets based on the contents of the DSCP field should be used to direct packets from the member Diffserv service classes into the queue that handles each of the treatment aggregates, without remarking the DSCP field of the packets. This is summarized in Figure 2, which shows the behavior each treatment aggregate should have, and the DSCP field marking of the packets that should be classified into each of the treatment aggregates.
私たちは、個々のエンド・ツー・エンドのサービスクラスの概念を維持するために推奨されているように、我々はまた、治療用骨材が使用されている場合、元のDSCPフィールドは変更されないマーキングすることをお勧めします。代わりに、DSCPフィールドの内容に基づいてパケットを選択する分類は、パケットのDSCPフィールドをリマークせず、治療の凝集体のそれぞれを処理キューにメンバーのDiffservサービスクラスからのパケットを指示するために使用されるべきです。これは、各処置集合が持つべき挙動を示す図2に要約され、およびDSCPフィールドが処理凝集体の各々に分類されるべきパケットのマーキング。
------------------------------------------------------------
|Treatment |Treatment || DSCP |
|Aggregate |Aggregate || |
| |Behavior || |
|==========+==========++=====================================|
| Network | CS || CS6 |
| Control |(RFC 2474)|| |
|==========+==========++=====================================|
| Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
| Time |(RFC 3246)|| |
|==========+==========++=====================================|
| Assured | AF || CS2, AF31, AF21, AF11 |
| Elastic |(RFC 2597)||-------------------------------------|
| | || AF32, AF22, AF12 |
| | ||-------------------------------------|
| | || AF33, AF23, AF13 |
|==========+==========++=====================================|
| Elastic | Default || Default, (CS0) |
| |(RFC 2474)||-------------------------------------|
| | || CS1 |
------------------------------------------------------------
Figure 2: Treatment Aggregate Behavior
図2：治療集計行動
Notes for Figure 2: For Assured Elastic and Elastic Treatment Aggregates, please see sections 4.1.3 and 4.1.4, respectively, for details on additional priority within the treatment aggregate.
図2のための注意事項：確実な伸縮性と伸縮性治療集計のためには、治療の集約内の追加の優先順位の詳細については、それぞれのセクション4.1.3と4.1.4を参照してください。
The Network Control Treatment Aggregate aggregates all service classes that are functionally necessary for the survival of a network during a DoS attack or other high-traffic load interval. The theory is that whatever else is true, the network must protect itself. This includes the traffic that RFC 4594 [3] characterizes as being included in the Network Control service class.
ネットワーク制御治療集計は、DoS攻撃や他の高トラフィック負荷期間中に機能的にネットワークの生存のために必要なすべてのサービスクラスを集約します。理論が真である任意の他、ネットワーク自体を保護しなければならないということです。これは、RFC 4594 [3]ネットワーク制御サービスクラスに含まれるものとして特徴付けるトラフィックを含みます。
Traffic in the Network Control Treatment Aggregate should be carried in a common queue or class with a PHB as described in RFC 2474 [2], section 4.2.2.2 for Class Selector (CS). This treatment aggregate should have a lower probability of packet loss and bear a relatively deep target mean queue depth (min-threshold if RED (Random Early Detection) is being used).
RFC 2474に記載されているようにネットワーク制御処理集約内のトラフィックは、PHBと共通キューまたはクラスに実施すべきである[2]、クラスセレクタ（CS）のためのセクション4.2.2.2。この処理の集約は、パケット損失の低い確率を持っており、比較的深いターゲット平均キュー深度を負わなければならない（最小しきい値RED（ランダム早期検出）が使用されている場合）。
Please notice this Network Control Treatment Aggregate is meant to be used for the customer's network control traffic. The provider may choose to treat its own network control traffic differently, perhaps in its own service class that is not aggregated with the customer's network control traffic.
このネットワークコントロール治療集計がお客様のネットワーク制御トラフィックのために使用されることを意図して注意してください。プロバイダは、おそらくお客様のネットワーク制御トラフィックと集約されていない独自のサービスクラスでは、異なった独自のネットワーク制御トラフィックを処理することもできます。
The Real-Time Treatment Aggregate aggregates all real-time (inelastic) service classes. The theory is that real-time traffic is admitted under some model and controlled by an SLA managed at the edge of the network prior to aggregation. As such, there is a predictable and enforceable upper bound on the traffic that can enter such a queue, and to provide predictable variation in delay it must be protected from bursts of elastic traffic. The predictability of traffic level may be based upon admission control for a well-known community of interest (e.g., a point-point service) and/or based upon historical measurements.
リアルタイム治療集計は、すべてのリアルタイム（非弾性）サービスクラスを集約します。理論は、リアルタイムのトラフィックは、一部のモデルで入院し、集約する前に、ネットワークのエッジで管理SLAによって制御されていることです。そのように、そこで予測可能で、そのようなキューを入力することができ、そしてそれは弾性トラフィックのバーストから保護されなければならない遅延で予測可能なバリエーションを提供するために、トラフィックの上限強制力。トラフィックレベルの予測可能性（例えば、ポイントツーポイントサービス）関心の既知のコミュニティのためのアドミッション制御に基づいて、および/または過去の測定値に基づいてもよいです。
This treatment aggregate may include the following service classes from the Diffserv service classes [3], in addition to other locally defined classes: Telephony, Signaling, Multimedia Conferencing, Real-time Interactive, and Broadcast Video.
テレフォニー、シグナリング、マルチメディア会議、リアルタイムの対話、および放送ビデオ：この処理の集約は、他のローカルに定義されたクラスに加えて、[3]のDiffservサービスクラスから次のサービスクラスを含んでいてもよいです。
Traffic in each service class that is going to be aggregated into the treatment aggregate should be conditioned prior to aggregation. It is recommended that per-service-class admission control procedures be used, followed by per-service-class policing so that any individual service class does not generate more than what it is allowed. Furthermore, additional admission control and policing may be used on the sum of all traffic aggregated into this treatment aggregate.
治療の集計に集約されようとしている各サービスクラスのトラフィックは凝集前に調整する必要があります。個々のサービスクラスは、それが許可されているものよりも多くを発生させないように、サービスごとのクラスのポリシングに続く、サービスごとのクラスアドミッション制御手順を使用することをお勧めします。さらに、追加の許可制御およびポリシングは、この治療集合に集約するすべてのトラフィックの合計に使用することができます。
Traffic in the Real-Time Treatment Aggregate should be carried in a common queue or class with a PHB (Per Hop Behavior) as described in RFC 3246 [9] and RFC 3247 [10].
RFC 3246に記載されているようにリアルタイム処理集約トラフィックはPHB（PERホップ挙動）と共通キューまたはクラスに実施すべきである[9]およびRFC 3247 [10]。
The Assured Elastic Treatment Aggregate aggregates all elastic traffic that uses the Assured Forwarding model as described in RFC 2597 [8]. The premise of such a service is that an SLA that is negotiated includes a "committed rate" and the ability to exceed that rate (and perhaps a second "excess rate") in exchange for a higher probability of loss using Active Queue Management (AQM) [7] or Explicit Congestion Notification (ECN) marking [11] for the portion of traffic deemed to be in excess.
アシュアード弾性治療集合体はRFC 2597に記載されるように保証転送モデルを使用する全ての弾性トラフィックを集約する[8]。そのようなサービスの前提は、交渉されるSLAは、アクティブキュー管理を使用して、損失の高い確率（AQM引き換えに「認定速度」とその割合（そしておそらく第二の「過剰率」）を超えた能力を含むことです）[7]または明示的輻輳通知（ECN）マーキング[11]トラフィックの部分に対して過剰にあるとみなさ。
This treatment aggregate may include the following service classes from the Diffserv service classes [3], in addition to other locally defined classes: Multimedia Streaming, Low Latency Data, OAM, and High-Throughput Data.
マルチメディアストリーミング、低レイテンシデータ、OAM、およびハイスループットデータ：この処理凝集体は、他のローカルに定義されたクラスに加えて、[3]のDiffservサービスクラスから次のサービスクラスを含むことができます。
The DSCP values belonging to the Assured Forwarding (AF) PHB group and class selector of the original service classes remain an important consideration and should be preserved during aggregation. This treatment aggregate should maintain the AF PHB group marking of the original packet. For example, AF3x marked packets should remain AF3x marked within this treatment aggregate. In addition, the class selector DSCP value should not be changed. Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2597 [8]. In effect, appropriate target rate thresholds have been applied at the edge, dividing traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 (excess). The service should be engineered so that AFn1 and CS2 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since the traffic is elastic and responds dynamically to packet loss, Active Queue Management [7] should be used primarily to reduce the forwarding rate to the minimum assured rate at congestion points. The probability of loss of AFn1 and CS2 traffic must not exceed the probability of loss of AFn2 traffic, which in turn must not exceed the probability of loss of AFn3 traffic.
オリジナルのサービス・クラスの保証転送（AF）PHB基及びクラスセレクタに属するDSCP値が重要な考慮事項のままであり、凝集中に保存されるべきです。この処理凝集体は、元のパケットのマーキングのAF PHB群を維持すべきです。例えば、AF3xは、パケットがAF3xは、この治療集約内にマーク残るべきマーク。また、クラスセレクタDSCP値が変更されるべきではありません。 RFC 2597に記載されているように、これらのDSCPを担持するトラフィックは、PHBと共通キューまたはクラスで行われる[8]。実際には、適切な目標速度閾値はAFn1（nは任意の値に対して、コミット）、AFn2、及びAFn3（過剰）にトラフィックを分割し、エッジに適用されています。 AFn1とCS2マークされたパケットフローは、配達の高い保証を提供するために、ネットワーク内の十分な帯域幅を持つようにサービスを設計する必要があります。トラフィックは、弾性であり、パケット損失に動的に応答するので、アクティブキュー管理[7]は、輻輳点最低保証レートに転送速度を減少させるために主に使用されるべきです。 AFn1とCS2トラフィックの損失の可能性は、順番にAFn3トラフィックの損失の可能性を超えてはならないAFn2トラフィックの損失の可能性を、超えてはなりません。
If RED [7] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each of AFn1+CS2, AFn2, and AFn3, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this treatment aggregate, the following inequalities SHOULD hold in queue configurations:
RED [7] AQMアルゴリズムとして使用される場合、最小閾値はAFn1 + CS2、AFn2、及びAFn3の各々のための目標のキューの深さを指定し、および最大しきい値は、キュー深度を指定するようなDSCPとそのすべてのトラフィック上記落下やECNがマークされています。したがって、この治療の集計で、以下の不等式がキュー構成に保持する必要があります：
o min-threshold AFn3 < max-threshold AFn3
最小しきい値AFn3 <最大しきい値AFn3 O
o max-threshold AFn3 <= min-threshold AFn2
O MAX-閾値AFn3 <=最小閾値AFn2
o min-threshold AFn2 < max-threshold AFn2
最小しきい値AFn2 <最大しきい値AFn2 O
o max-threshold AFn2 <= min-threshold AFn1+CS2
O最大しきい値AFn2 <=最小しきい値AFn1 + CS2
o min-threshold AFn1+CS2 < max-threshold AFn1+CS2
O最小しきい値AFn1 + CS2 <最大しきい値AFn1 + CS2
o max-threshold AFn1+CS2 <= memory assigned to the queue
キューに割り当てられたO最大しきい値AFn1 + CS2 <=メモリ
Note: This configuration tends to drop AFn3 traffic before AFn2, and AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result.
注：この設定はAFn1とCS2の前AFn2、およびAFn2前AFn3トラフィックをドロップする傾向があります。他の多くのAQMアルゴリズムが存在し、使用されています。彼らは同様の結果を達成するために設定する必要があります。
The Elastic Treatment Aggregate aggregates all remaining elastic traffic. The premise of such a service is that there is no intrinsic SLA differentiation of traffic, but that AQM [7] or ECN flagging [11] is appropriate for such traffic.
弾性治療集計は、残りのすべての弾性トラフィックを集約します。そのようなサービスの前提は、トラフィックのない固有のSLA分化がないことであるが、AQM [7]またはECNは、[11]フラグを立てるようなトラフィックのために適切であること。
This treatment aggregate may include the following service classes from the Diffserv service classes [3], in addition to other locally defined classes: Standard and Low-Priority Data.
標準および低優先度データ：この処理凝集体は、他のローカルに定義されたクラスに加えて、[3]のDiffservサービスクラスから次のサービスクラスを含むことができます。
Treatment aggregates should be well specified, each indicating the service classes it will handle. But in cases where unspecified or unknown service classes are encountered, they may be dropped or be treated using the Elastic Treatment Aggregate. The choice of how to treat unspecified service classes should be well defined, based on some agreements.
治療凝集体は、各ウェルは、それが処理するサービスクラスを示す、指定する必要があります。しかし、不特定または未知のサービスクラスが発生した場合には、彼らが落下してもよいし、弾性治療集計を用いて治療すること。不特定のサービスクラスを扱う方法の選択は、十分にいくつかの協定に基づいて、定義されるべきです。
Traffic in the Elastic Treatment Aggregate should be carried in a common queue or class with a PHB as described in RFC 2474 [2], section 4.1, "A Default PHB". The AQM thresholds for Elastic traffic MAY be separately set, so that Low Priority Data traffic is dropped before Standard traffic, but this is not a requirement.
RFC 2474に記載されるように弾性治療集合におけるトラフィックは、PHBと共通キューまたはクラスに実施すべきである[2]、セクション4.1、「デフォルトPHB」。低優先度のデータトラフィックは、標準トラフィック前に削除されるように、弾性トラフィックのAQMしきい値は、個別に設定すればよいが、これは必須ではありません。
When treatment aggregates are used at provider boundaries, we recommend that the inter-provider relationship be based on Diffserv service classes [3]. This allows the admission control into each treatment aggregate of a provider domain to be based on the admission control of traffic into the supported service classes, as indicated by the discussion in section 4 of this document.
治療の凝集体は、プロバイダの境界で使用されているとき、私たちは[3]間のプロバイダの関係はDiffservのサービスクラスに基づいてすることをお勧めします。これは、このドキュメントのセクション4で議論によって示されるように、プロバイダドメインの各治療集合にアドミッション制御は、サポートされるサービスクラスにトラフィックのアドミッション制御に基づくことを可能にします。
If the inter-provider relationship needs to be based on treatment aggregates specified by this document, then the exact treatment aggregate content and representation must be agreed to by the peering providers.
インタープロバイダの関係は、この文書で指定された治療集計に基づいてする必要がある場合には、正確な治療集計内容と表現がピアリングプロバイダによって合意されなければなりません。
Some additional work on inter-provider relationships is provided by inter-provider QoS [15], where details on supporting real-time services between service providers are discussed. Some related work in ITU-T provided by Appendix VI of Y.1541 [16] may also help with inter-provider relationships, especially with international providers.
インタープロバイダの関係に関するいくつかの追加の作業は、サービスプロバイダ間のリアルタイムサービスをサポートする方法の詳細が説明されている間、プロバイダのQoS [15]によって提供されています。 Y. 1541の付録VI [16]が提供するITU-Tにおけるいくつかの関連研究はまた、特に国際的プロバイダーで、インタープロバイダの関係で役立つかもしれません。
This document discusses the policy of using Differentiated Services and its service classes. If implemented as described, it should require that the network do nothing that the network has not already allowed. If that is the case, no new security issues should arise from the use of such a policy.
この文書では、差別化サービスとそのサービスクラスを使用しての方針を説明します。説明するように実装されている場合、それは、ネットワークは、ネットワークが既に許可されていない何もしないことを要求すべきです。その場合は、新しいセキュリティ問題は、このような政策の使用から生じてはなりません。
As this document is based on RFC 4594 [3], the Security Consideration discussion of no new security issues indicated by RFC 4594 [3] also applies to treatment aggregates of this document.
この文書は、RFC 4594に基づいている[3]、RFC 4594で示されていない新たなセキュリティ上の問題のセキュリティの考慮事項の議論は、[3]また、本文書の処理集合体に適用されます。
This document has benefited from discussions with numerous people, especially Shane Amante, Brian Carpenter, and Dave McDysan. It has also benefited from detailed reviews by David Black, Marvin Krym, Bruce Davie, Fil Dickinson, and Julie Ann Connary.
この文書は、多くの人々、特にシェーンAmante、ブライアン・カーペンター、とDave McDysanとの議論の恩恵を受けています。また、デビッド・ブラック、マーヴィンKrym、ブルースデイビー、フィル・ディキンソン、とジュリーアンConnaryにより詳細なレビューの恩恵を受けています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] 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.
[2]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[3] Babiarz、J.、チャン、K.、およびF.ベイカー、 "DiffServのサービスクラスの設定時の注意事項"、RFC 4594、2006年8月。
[4] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[4]ブレーデン、B.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[5]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[6]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[7] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[7]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[8] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[8] Heinanen、J.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[9]デイビー、B.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[10] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[10] Charny、A.、ベネット、J.、ベンソン、K.、Boudec、J.、チウ、A.、コートニー、W.、Davari、S.、Firoiu、V.、Kalmanek、C.、およびK 。ラマクリシュナン、「EFのPHBの新しい定義のための補足情報（優先転送ホップ単位動作）」、RFC 3247、2002年3月。
[11] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[11] "IPに明示的輻輳通知の添加（ECN）" ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[12] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point Packet Delay in an Operational Network", INFOCOMM 2004, March 2004, <http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[12]チェ、B.、月、S.、張、Z.、Papagiannaki、K.、およびC. Diot、 "オペレーショナル・ネットワークにおけるポイントツーポイントパケット遅延の分析"、インフォコム2004年、2004年3月、 <http://www.ieee-infocom.org/2004/Papers/37_4.PDF>。
[13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", March 2002, <http://www.renesys.com/tech/presentations/pdf/ renesys-030502-NRC-911.pdf>.
[13] Ogielski、A.とJ. Cowie、 "9月11日にインターネットルーティング動作"、2002年3月、<http://www.renesys.com/tech/presentations/pdf/ renesys-030502-NRC-911。 PDF>。
[14] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[14]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、RFC 3086、2001年4月。
[15] MIT Communications Futures Program, "Inter-provider Quality of Service", November 2006, < http://cfp.mit.edu/resources/papers/Interprovider QoS MIT_CFP_WP_9_14_06.pdf>.
[15] MITコミュニケーションズ先物プログラム、 "サービスのインタープロバイダ品質"、2006年11月、<http://cfp.mit.edu/resources/papers/InterproviderのQoS MIT_CFP_WP_9_14_06.pdf>。
[16] International Telecommunications Union, "Network Performance Objectives for IP-Based Services", Recommendation Y.1541, February 2006.
[16]国際電気通信連合、「IPベースのサービスのためのネットワークパフォーマンスの目標」、勧告Y. 1541、2006年2月。
Appendix A. Using MPLS for Treatment Aggregates
付録A.治療の集約のためのMPLSを使用します
RFC 2983 on Diffserv and Tunnels [5] and RFC 3270 on MPLS Support of Diffserv [6] provide a very good background on this topic. This document provides an example of using the E-LSP, EXP Inferred PHB Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS Support of Diffserv [6] for realizing the Treatment Aggregates.
DiffservののMPLSサポートについてのDiffservとトンネル上のRFC 2983 [5]およびRFC 3270 [6]この話題に非常に優れたバックグラウンドを提供しています。この文書は、治療凝集体を実現するための[6]のDiffservのMPLSサポートによって定義されたE-LSP、EXP推論PHBスケジュールクラス（PSC）ラベルスイッチパス（LSP）を使用する例を提供します。
When treatment aggregates are represented in MPLS using EXP Inferred PSC LSP, we recommend the following usage of the MPLS EXP field for treatment aggregates.
治療凝集体はEXP推論PSC LSPを使用してMPLSで表現されているとき、私たちは治療の凝集体のためのMPLS EXPフィールドの次使用をお勧めします。
-------------------------------------------
|Treatment || MPLS || DSCP | DSCP |
|Aggregate || EXP || name | value |
|==========++======++=========|=============|
| Network || 110 || CS6 | 110000 |
| Control || || | |
|==========++======++=========|=============|
| Real- || 100 || EF | 101110 |
| Time || ||---------|-------------|
| || || CS5 | 101000 |
| || ||---------|-------------|
| || ||AF41,AF42|100010,100100|
| || || AF43 | 100110 |
| || ||---------|-------------|
| || || CS4 | 100000 |
| || ||---------|-------------|
| || || CS3 | 011000 |
|==========++======++=========|=============|
| Assured || 010* || CS2 | 010000 |
| Elastic || || AF31 | 011010 |
| || || AF21 | 010010 |
| || || AF11 | 001010 |
| ||------||---------|-------------|
| || 011* || AF32 | 011100 |
| || || AF22 | 010100 |
| || || AF12 | 001100 |
| || || AF33 | 011110 |
| || || AF23 | 010110 |
| || || AF13 | 001110 |
|==========++======++=========|=============|
| Elastic || 000* || Default | 000000 |
| || || (CS0) | |
| ||------||---------|-------------|
| || 001* || CS1 | 001000 |
-------------------------------------------
Figure 3: Treatment Aggregate and MPLS EXP Field Usage
図3：治療骨材とMPLS EXPフィールドの使用
* Note: For Assured Elastic (and Elastic) Treatment Aggregate, the usage of 010 or 011 (000 or 001) as EXP field value depends on the drop probability. Packets in the LSP with EXP field of 011 (001) have a higher probability of being dropped than packets with an EXP field of 010 (000).
*注：アシュアード弾性（及び弾性）の治療集計、010または011（000又は001）の使用EXPフィールド値が廃棄確率に依存します。 011（001）のEXPフィールドを持つLSPでパケットは010（000）のEXPフィールドを有するパケットよりも廃棄さのより高い確率を有します。
The above table indicates the recommended usage of EXP fields for treatment aggregates. Because many deployments of MPLS are on a per-domain basis, each domain has total control of its EXP usage and each domain may use a different EXP field allocation for the domain's supported treatment aggregates.
上記の表は、治療凝集のためのEXPフィールドの推奨される使用法を示しています。 MPLSの多くの配備は、ドメイン単位であるため、各ドメインは、そのEXPの使用を完全にコントロールを持っており、各ドメインは、ドメインのサポート治療凝集体に対して異なるEXPフィールドの割り当てを使用することができます。
A.1. Network Control Treatment Aggregate with E-LSP
A.1。 E-LSPとネットワーク制御の処理集計
The usage of E-LSP for Network Control Treatment Aggregate needs to adhere to the recommendations indicated in section 4.1.1 of this document and section 3.2 of RFC 4594 [3]. Reinforcing these recommendations, there should be no drop precedence associated with the MPLS PSC used for Network Control Treatment Aggregate because dropping of Network Control Treatment Aggregate traffic should be prevented.
ネットワーク制御処理集約のためのE-LSPの使用は、この文書のセクション4.1.1及びセクションに示されている推奨事項に準拠する必要がRFC 4594の3.2 [3]。これらの推奨事項を補強、MPLS PSCに関連付けられたドロップ優先順位があってはならないネットワーク制御処理集約トラフィックの落下を防止しなければならないので、ネットワーク制御処理集約のために使用しました。
A.2. Real-Time Treatment Aggregate with E-LSP
A.2。 E-LSPとリアルタイム処理の集約
In addition to the recommendations provided in section 4.1.2 of this document and in member service classes' sections of RFC 4594 [3], we want to indicate that Real-Time Treatment Aggregate traffic should not be dropped, as some of the applications whose traffic is carried in the Real-Time Treatment Aggregate do not react well to dropped packets. As indicated in section 4.1.2 of this document, admission control should be performed on each service class contributing to the Real-Time Treatment Aggregate to prevent packet loss due to insufficient resources allocated to Real-Time Treatment Aggregate. Further, admission control and policing may also be applied on the sum of all traffic aggregated into this treatment aggregate.
このドキュメントのセクション4.1.2にし、RFC 4594の会員サービスクラスのセクションに記載されている推奨に加えて、[3]、我々はリアルタイム処理集約トラフィックは、そのアプリケーションの一部として、廃棄されるべきでないことを示すためにしたいですトラフィックがドロップされたパケットによく反応しないリアルタイム処理集計で運ばれます。この文書のセクション4.1.2に示すように、アドミッション制御が原因リアルタイム処理集約に割り当てられたリソース不足にパケット損失を防止するために、リアルタイム処理の集約に寄与する各サービスクラスに対して実行されるべきです。さらに、アドミッション制御とポリシングもこの治療集合に集約するすべてのトラフィックの合計に適用されてもよいです。
A.3. Assured Elastic Treatment Aggregate with E-LSP
A.3。 E-LSPと安心伸縮性治療集計
EXP field markings of 010 and 011 are used for the Assured Elastic Treatment Aggregate. The two encodings are used to provide two levels of drop precedence indications, with 010 encoded traffic having a lower probability of being dropped than 011 encoded traffic. This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. If the domain chooses to support only one drop precedence for this treatment aggregate, we recommend the use of 010 for EXP field marking.
010と011のEXPフィールドのマーキングは、アシュアード弾性治療の集計のために使用されています。 2つのエンコーディングは、010符号化されたトラフィックは、011符号化されたトラフィックよりもドロップさの低い確率を有する、ドロップ優先指標2つのレベルを提供するために使用されます。これは、EXP 010にCS2、AF31、AF21、AF11とのマッピングを提供し;ドメインは、この治療集約のための唯一の廃棄優先順位をサポートすることを選択した場合とEXP 011にAF32、AF22、AF12とAF33、AF23、AF13は、我々はマーキングEXPフィールドの010を使用することをお勧めします。
A.4. Elastic Treatment Aggregate with E-LSP
A.4。 E-LSPに弾治療集計
EXP field markings of 000 and 001 are used for the Elastic Treatment Aggregate. The two encodings are used to provide two levels of drop precedence indications, with 000 encoded traffic having a lower probability of being dropped than 001 encoded traffic. This provides for the mapping of Default/CS0 into 000; and CS1 into 001. Notice that with this mapping, during congestion, CS1-marked traffic may be starved. If the domain chooses to support only one drop precedence for this treatment aggregate, we recommend the use of 000 for EXP field marking.
000と001のEXPフィールドのマーキングは、弾性治療集約のために使用されます。 2つのエンコーディングは、000符号化されたトラフィックは、001符号化されたトラフィックよりもドロップさの低い確率を有する、ドロップ優先指標2つのレベルを提供するために使用されます。これは、000にデフォルト/ CS0のマッピングを提供します。そして001お知らせにCS1混雑時にこのマッピングと、CS1-マークされたトラフィックが不足することができること。ドメインは、この治療集約のための唯一の廃棄優先順位をサポートすることを選択した場合、我々は、マーキングEXPフィールドの000を使用することをお勧めします。
A.5. Treatment Aggregates and L-LSP
A.5。治療集約とL-LSP
Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per LSP, the support of each treatment aggregate is on a per-LSP basis. This document does not further specify any additional recommendation (beyond what has been indicated in section 4 of this document) for treatment aggregate to L-LSP mapping, leaving this to each individual MPLS domain administration.
L-LSP（ラベルのみ推論PSC LSP）がLSPごとに単一のPSCをサポートしているため、各治療集計のサポートがあたり-LSPベースです。この文書は、各個々のMPLSドメインの管理にこれを残して、L-LSPへのマッピング処理凝集体のための（本書のセクション4に示されたものを超えて）追加の推奨を指定していません。
Authors' Addresses
著者のアドレス
Kwok Ho Chan Nortel 600 Technology Park Drive Billerica, MA 01821 US
クォックホーチャンノーテル600テクノロジーパークドライブビレリカ、MA 01821米国
Phone: +1-978-288-8175 Fax: +1-978-288-8700 EMail: khchan@nortel.com
電話：+ 1-978-288-8175ファックス：+ 1-978-288-8700 Eメール：khchan@nortel.com
Jozef Z. Babiarz Nortel 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada
ヨゼフZ. Babiarzノーテル3500カーリングアベニューオタワ、オンタリオ。 K2H 8E9カナダ
Phone: +1-613-763-6098 Fax: +1-613-768-2231 EMail: babiarz@nortel.com
電話：+ 1-613-763-6098ファックス：+ 1-613-768-2231 Eメール：babiarz@nortel.com
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッドベイカーシスコシステムズ1121ヴィアデル・レイサンタバーバラ、カリフォルニア州93117米国
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
電話：+ 1-408-526-4257ファックス：+ 1-413-473-2403 Eメール：fred@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。