[要約] RFC 5127は、DiffServサービスクラスの集約に関するガイドラインを提供するものであり、異なるDiffServサービスクラスを効果的に統合するための方法を示しています。目的は、ネットワークの効率性と品質を向上させることです。
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
diffservサービスクラスの集約
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つ以上のサービスクラスのトラフィック特性とパフォーマンス要件を満たすように構成される場合があります。これらの場合、2つ以上のDiffServサービスクラスを単一の転送治療に集約することが望ましい場合があります。このドキュメントは、Diffserv Service Classeを転送治療に集約するためのガイドラインを提供します。
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 Switching）が発生しました。
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]で発生するサブセカンドサージ[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]は、これらのサービスクラスの治療方法に関する推奨事項も提供しています。しかし、エンドツーエンドのパスの一部のネットワークセグメントでは、ネットワーク処理の差別化のレベルの数は、ネットワークセグメントがサポートする必要があるサービスクラスの数よりも少ない場合があります。このような状況では、そのネットワークセグメントは同じ処理を使用して複数のサービスクラスをサポートする場合があります。このドキュメントでは、複数のサービスクラスを転送処理の集約にどのように集約できるかについてのガイドラインを提供します。これには、RFC 4594 [3]で説明されているように、DSCP（差別化されたサービスコードポイント）を使用して表現されるサービスクラスに属するIPトラフィックを持つことが必要です。特定のドメインでは、サポートされているサービスクラスを転送処理凝集体に集約することをお勧めする場合があります。ただし、これはすべてのサービスクラスをサポートする必要があることを意味するわけではなく、したがって、すべての転送処理凝集体をサポートする必要はありません。ドメインは、このドキュメントで推奨されるよりも、転送処理凝集体の数が少ないか、それとも大幅にサポートする場合があります。どのサービスクラスと、どの転送処理凝集体がドメインによってサポートされているかは、ドメイン管理次第であり、ビジネス上の理由やその他の理由（運用上の考慮事項など）の影響を受ける可能性があります。
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).
o E-LSPを使用してMPLSを介してこの集約を実行する例（付録で）、EXPと推定されたPHBスケジューリングクラス（PSC）ラベルスイッチドパス（LSP）。
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は単なる例であることに注意してください。このドキュメントでは、他の方法の使用は除外されていません。この例は、IPトラフィックのe-lspへの集約のみを考慮しています。非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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
このドキュメントは、読者が差別化されたサービスで使用される用語に精通していることを前提としています。このドキュメントは、このドキュメントによって導入された新しい用語の定義と、差別化されたサービスで一般的に使用されていない既存の用語についてRFCSで定義された情報を参照してください。
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 CodePointを持ち、1つのホップあたりの動作（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].
o Diffserv Serviceクラス。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 [6]のセクション1.2。
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 [6]のセクション1.3。
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. 治療と割り当てられたリソースは、履歴交通パターンとこれらのパターンの変動性を考慮する場合があります。たとえば、ポイントポイントサービス（Pseudowireなど）には非常に予測可能なパターンがある場合がありますが、マルチポイントサービス（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.
2. diffservに加えて、他のコントロールは、特定のトラフィックの集合体に提供されるトラフィックレベルに影響を与えるために利用できます。これらには、ルーティングメトリックの調整、およびMPLSベースのトラフィックエンジニアリング手法の使用が含まれます。
This document only describes the aggregation of IP traffic based on the use of Diffserv service classes [3].
このドキュメントでは、DiffServサービスクラスの使用に基づくIPトラフィックの集約のみを説明しています[3]。
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.
RFC 4594 [3]のサービスクラスとDSCP選択は、多くの場合、2つまたはおそらくさらに多くのサービスクラスを単一の転送治療集計にマッピングできるように定義されています。リンク速度、キューの深さ、遅延、およびジッターの間に関係/トレードオフがあることに注意してください。凝集の程度、したがって治療凝集体の数は、損失、遅延、およびジッターに対する集約の影響に依存します。これは、集約の実装に使用されるリンクとスケジューラの動作の速度が、トラフィックを異なるパケットサイズと混合し、キューの深さに送信する効果を最小限に抑えることができるかどうかに依存します。一般的なサンプのルールは、リンクの使用率がエンジニアリングレベル内にあると仮定すると、より高いリンク速度により、より多くの集約/より少ない治療集合体が可能になることです。
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].
このセクションでは、RFC 4594 [3]で定義されているすべてのサービスクラスを4つの治療集合体にマッピングする例を示します。4つの治療凝集体の使用は、各治療総合材に割り当てられたリソースが各サービスクラスの必要な動作を尊重するのに十分であると仮定します[3]。アプリケーション/エンドユーザーのパフォーマンス要件（損失、遅延、およびジッターに対する耐性）を、サービスクラスを治療集合体にマッピングする方法に関するガイドとして使用します。また、RFC 1633 [4]のセクション3.1を使用して、リアルタイムおよび弾性アプリケーションの定義に関するガイダンスを提供しました。サービスクラスと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つの治療凝集体のこの例は、実装する必要がある治療凝集体の最小限のセットを表すものではありません。また、実装できる治療集計の最大セットを表していません。
---------------------------------------------------------------------
|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
図1：治療の集計とサービスクラスのパフォーマンス要件
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.
------------------------------------------------------------
|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 [2]に記載されているPHBを使用して、クラスセレクター（CS）のセクション4.2.2.2に記載されているPHBを使用して、共通のキューまたはクラスに携帯する必要があります。この処理総合材は、パケット損失の可能性が低く、比較的深いターゲット平均キューの深さ（赤（ランダム早期検出）が使用されている場合は最小控除）を負担する必要があります。
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.
この治療集合体には、他のローカル定義クラスに加えて、テレフォニー、シグナリング、マルチメディア会議、リアルタイムインタラクティブ、ブロードキャストビデオなど、DiffServサービスクラス[3]からの以下のサービスクラスが含まれる場合があります。
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 [9]およびRFC 3247 [10]に記載されているように、リアルタイム治療の骨材のトラフィックは、PHB（ホップあたりの動作あたり）の共通のキューまたはクラスで運ばれる必要があります。
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.
Assured Elastic Treatenceは、RFC 2597 [8]に記載されているように、保証された転送モデルを使用するすべての弾性トラフィックを集約します。このようなサービスの前提は、交渉されたSLAには、アクティブキュー管理を使用した損失の可能性が高い可能性と引き換えに、「コミットレート」とそのレート（おそらく2番目の「超過率」）を超える能力が含まれることです（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、ハイスループットデータなど、DiffServサービスクラス[3]からの以下のサービスクラスが含まれる場合があります。
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.
Assured Forwarding（AF）PHBグループと元のサービスクラスのクラスセレクターに属するDSCP値は、依然として重要な考慮事項であり、集約中に保存する必要があります。この治療総合材は、元のパケットのAF PHBグループマーキングを維持する必要があります。たとえば、AF3Xマークされたパケットは、この治療の総合材にAF3Xマークのままである必要があります。さらに、クラスセレクターDSCP値を変更しないでください。これらのDSCPを担うトラフィックは、RFC 2597 [8]に記載されているように、PHBを使用して共通のキューまたはクラスで運ばれます。実際、適切なターゲットレートのしきい値がエッジで適用され、トラフィックをAFN1（nの任意の値に対してコミット）、AFN2、およびAFN3（過剰）に分割しています。AFN1とCS2のマークされたパケットフローがネットワーク内に十分な帯域幅があるように、配信の高い保証を提供するように、サービスを設計する必要があります。トラフィックは弾力性があり、パケット損失に動的に応答するため、アクティブキュー管理[7]を使用して、主に輻輳ポイントでの転送率を最小保証率に低下させる必要があります。AFN1およびCS2トラフィックの損失の確率は、AFN2トラフィックの損失の可能性を超えてはなりません。これは、AFN3トラフィックの損失の可能性を超えてはなりません。
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:
赤[7]がAQMアルゴリズムとして使用されている場合、最小限はAFN1 CS2、AFN2、およびAFN3のそれぞれのターゲットキューの深さを指定し、最大限はそのようなDSCPのすべてのトラフィックを上回るキューの深さを指定します。ドロップまたはECNマーク。したがって、この処理の集合体では、次の不平等はキュー構成に保持する必要があります。
o min-threshold AFn3 < max-threshold AFn3
o min-threshold afn3 <max-threshold afn3
o max-threshold AFn3 <= min-threshold AFn2
o Max-Threshold afn3 <= min-threshold afn2
o min-threshold AFn2 < max-threshold AFn2
o min-threshold afn2 <max-threshold afn2
o max-threshold AFn2 <= min-threshold AFn1+CS2
o Max-Threshold afn2 <= min-threshold afn1 cs2
o min-threshold AFn1+CS2 < max-threshold AFn1+CS2
o min-threshold afn1 cs2 <max-threshold afn1 cs2
o max-threshold AFn1+CS2 <= memory assigned to the queue
o Max-Threshold 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.
注：この構成は、AFN2より前にAFN3トラフィックを、AFN1およびCS2の前にAFN2を落とす傾向があります。他の多くの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.
この治療集計には、他のローカルで定義されたクラス、標準および低優先度データに加えて、DiffServサービスクラス[3]からの以下のサービスクラスが含まれる場合があります。
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 [2]、セクション4.1、「デフォルトPHB」に記載されているように、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.
プロバイダーの境界で治療凝集体が使用される場合、プロバイダー間の関係をDiffServサービスクラスに基づくことをお勧めします[3]。これにより、このドキュメントのセクション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.
この文書は、多くの人々、特にシェーン・アマンテ、ブライアン・カーペンター、デイブ・マクディサンとの議論から恩恵を受けています。また、David Black、Marvin Krym、Bruce Davie、Fil Dickinson、およびJulie Ann Connaryによる詳細なレビューの恩恵を受けています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、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] Braden、B.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[5] Black、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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-Protocol Label Switching（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] 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。、およびL. Zhang、「インターネットにおけるキュー管理と混雑回避に関する推奨事項」、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.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、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] Davie、B.、Charny、A.、Bennet、J.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis、「迅速な転送」PHB（PER-HOP行動）」、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.、Bennet、J.、Benson、K.、Boudec、J.、Chiu、A.、Courtney、W.、Davari、S.、Firoiu、V.、Kalmanek、C。、およびK. Ramakrishnan、「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] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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] Choi、B.、Moon、S.、Zhang、Z.、Papagiannaki、K。、およびC. Diot、「運用ネットワークにおけるポイントツーポイントパケット遅延の分析」、Infocomm 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] Nichols、K。およびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、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 Communications Futures Program、「Inter-Provider Quality of Service」、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] International Telecommunications Union、「IPベースのサービスのネットワークパフォーマンス目標」、推奨Y.1541、2006年2月。
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およびTunnels [5]およびRFC 3270のRFC 2983 Diffservのサポート[6]は、このトピックに関する非常に良い背景を提供します。このドキュメントは、治療凝集体を実現するためにdiffserv [6]のMPLSサポートによって定義された、E-LSP、EXPED 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).
* 注：Assured Elastic（およびElastic）治療の凝集の場合、EXPフィールド値としての010または011（000または001）の使用は、低下確率に依存します。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フィールド割り当てを使用する場合があります。
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に関連するドロップの優先順位はないはずです。
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に示されているように、リアルタイム治療の総合的なリアルタイム治療の集合体に寄与する各サービスクラスで入場制御を実行する必要があります。さらに、この治療の総計に集約されたすべてのトラフィックの合計に加えて、入場制御とポリシングを適用することもできます。
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つのエンコーディングは、2つのレベルのドロップ優先度表示を提供するために使用され、010エンコードされたトラフィックは、011エンコードされたトラフィックよりも低下する可能性が低いためです。これにより、CS2、AF31、AF21、およびAF11をEXP 010にマッピングすることができます。AF32、AF22、AF12およびAF33、AF23、AF13はEXP 011になります。ドメインがこの治療の集合体で1つのドロップの優先順位のみをサポートすることを選択した場合、EXPフィールドマーキングに010を使用することをお勧めします。
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つのエンコーディングを使用して、2つのレベルのドロップ優先表示を提供し、001エンコードされたトラフィックよりも低下する確率が低い000エンコードトラフィックを備えています。これにより、デフォルト/CS0の000へのマッピングが提供されます。CS1への001。このマッピングにより、混雑中にCS1マークのトラフィックが飢えている可能性があることに注意してください。ドメインがこの治療の集合体に対して1つのドロップの優先順位のみをサポートすることを選択した場合、EXPフィールドマーキングに000を使用することをお勧めします。
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ごとにあります。このドキュメントでは、L-LSPマッピングへの治療の凝集について、追加の推奨事項（このドキュメントのセクション4に示されているものを超えて）をさらに指定しておらず、各MPLSドメイン管理にこれを残します。
Authors' Addresses
著者のアドレス
Kwok Ho Chan Nortel 600 Technology Park Drive Billerica, MA 01821 US
Kwok Ho Chan Nortel 600 Technology Park Drive Billerica、MA 01821 US
Phone: +1-978-288-8175
Fax: +1-978-288-8700
EMail: khchan@nortel.com
Jozef Z. Babiarz Nortel 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada
Jozef Z. Babiarz Nortel 3500 Carling Avenue Ottawa、ONT。K2H 8E9カナダ
Phone: +1-613-763-6098
Fax: +1-613-768-2231
EMail: babiarz@nortel.com
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッド・ベイカー・シスコ・システム1121
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。