RFC5127 日本語訳
5127 Aggregation of DiffServ Service Classes. K. Chan, J. Babiarz, F.Baker. February 2008. (Format: TXT=43751 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Chan
Request for Comments: 5127 J. Babiarz
Category: Informational Nortel
F. Baker
Cisco Systems
February 2008
コメントを求めるワーキンググループK.チェン要求をネットワークでつないでください: 5127年のJ.Babiarzカテゴリ: 情報のノーテルF.ベイカーシスコシステムズ2008年2月
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サービスのクラスの集合のためのガイドラインを推進処理に提供します。
Chan, et al. Informational [Page 1] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[1ページ]のRFC5127集合は2008年2月に属します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 要件記法. . . . . . . . . . . . . . . . . . 4 2 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 サービスクラス集合. . . . . . . . . . . . 5 4の概観。 処理へのサービスのクラスはマッピング. . . . . . . . 6 4.1に集められます。 .1に4つの処理集合. . 7 4.1にサービスのクラスを写像します。 規制処理集合. . . . . . . . . 9 4.1.2をネットワークでつないでください。 リアルタイムの処理集合. . . . . . . . . . . . 10 4.1.3。 確実な弾性の処理集合. . . . . . . . . 10 4.1.4。 弾性の処理集合. . . . . . . . . . . . . 12 5。 処理集合と相互プロバイダー関係. . . . 12 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 13 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 13 8.2。 処理にMPLSを使用する有益な参照. . . . . . . . . . . . . . . . . . 14付録A.が.15A.1に集められます。 電子LSP.17A.2と共に規制処理集合をネットワークでつないでください。 電子LSP.17A.3とのリアルタイムの処理集合。 電子LSP.17A.4との確実な弾性の処理集合。 電子LSP.17A.5との弾性の処理集合。 処理集合とL-LSP. . . . . . . . . . . . . . 18
Chan, et al. Informational [Page 2] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[2ページ]のRFC5127集合は2008年2月に属します。
1. Introduction
1. 序論
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再ルーティングかMultiprotocol Label Switching(MPLS)保護モードの切り換えのどちらか)を別ルートで送った後にこれが本当のままで残っているのは起こりました。
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]の最もよく設計にされるのに現れるサブ2番目の大波はリアルタイムのアプリケーションに影響します。 そのうえ、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
RFC4594[3]はネットワークから終わりから終わりへの特定の振舞いを必要とするアプリケーションの観点から1セットの基本的なDiffservのクラスを定義します。 サービスのクラスはパケット損失、遅れ、および遅れ変化(ジター)へのアプリケーションペイロードの寛容に基づいて微分されます。 これらの評価基準の異なった度合いはリアルタイムで弾性の交通の必要性を支持する基礎を形成します。 また、RFC4594[3]はこれらのサービスのクラスの治療法のための推薦を提供します。 しかし、終わりまでの端の経路のいくつかのネットワークセグメントでは、ネットワーク処理分化のレベルの数はネットワークセグメントが支持する必要があるサービスのクラスの数より少ないかもしれません。 そのような状況で、そのネットワークセグメントは、複数のサービスのクラスを支持するのに同じ処理を使用するかもしれません。 本書では、私たちは複数のサービスのクラスがどう推進処理集合に集められるかもしれないかに関するガイドラインを提供します。 これは、RFC4594[3]によって説明されるようにDSCP(Services Code Pointを微分する)を使用することで言い表されたサービスのクラスに属すIP交通を持っているのを伴います。 与えられたドメインでは、私たちが、支持されたサービスのクラスが推進処理集合に集められるのを推薦するかもしれないことに注意してください。 しかしながら、これは、すべてのサービスのクラスが支持されて、したがって、集合が支持されるために必要とする処理をすべて進める必要でないことを意味しません。 ドメインはそうするかもしれません。
Chan, et al. Informational [Page 3] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[3ページ]のRFC5127集合は2008年2月に属します。
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).
より少ないかこのドキュメントによって推薦されるより大きい数の推進処理集合をサポートしてください。 どのサービスのクラスとどの推進処理集合がドメインによってサポートされるかは、ドメイン管理まであって、ビジネス目的か他の理由(例えば、操作上の問題)によって影響を及ぼされるかもしれません。
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 MPLSの上でE-LSPを使用することでこの集合を実行する例(付録の)、EXP Inferred PHB Scheduling Class(PSC)は(LSP)とSwitched Pathをラベルします。
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交通の集合を考えるだけです。 E-LSPの非IP交通による使用について議論しません。
1.1. Requirements Notation
1.1. 要件記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Terminology
2. 用語
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で定義したこのドキュメントと参照で導入して、このドキュメントは定義を新学期に提供します。
Chan, et al. Informational [Page 4] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[4ページ]のRFC5127集合は2008年2月に属します。
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]の集合と定義されます。 処理集合は集められた交通を推進処理だけに関係があります。(交通は複数のDSCPsと共に示されるかもしれません)。 処理集合はBehavior Aggregate[2]とTraffic Aggregate[14]と異なっています。それはそれぞれ独身のDiffserv codepointを持って、独身のPer Hop Behavior(PHB)を利用する集められた交通を示します。
For terms from existing RFCs, we provide the reference to the appropriate section of the relevant RFC that contain the definition:
既存のRFCsからの用語のときに、私たちは定義を含む関連RFCの相当区の参照を提供します:
o Real-Time and Elastic Applications and their traffic. Section 3.1
of RFC 1633 [4].
o リアルタイム、Elastic Applications、および彼らの交通。 RFC1633[4]のセクション3.1。
o Diffserv Service Class. Section 1.3 of RFC 4594 [3].
o Diffservはクラスにサービスを提供します。 RFC4594[3]のセクション1.3。
o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched
Path (LSP). Section 1.2 of RFC 3270 [6].
o MPLS電子LSP、EXPはPHBスケジューリングのクラス(PSC)のラベルの切り換えられた経路(LSP)を推論しました。 RFC3270[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)を推論しただけです。 RFC3270[6]のセクション1.3。
3. Overview of Service Class Aggregation
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. 処理の集合SHOULDは同様の交通の特性と性能要件があるメンバーサービスのクラスを含むだけです。
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
4. 集合が実行されるとき、終わりから終わりへのサービス個々のクラスの概念を破壊してはいけません。 終わりから端への経路に沿った各ドメインは終わりから終わりへのサービス元のクラスに基づいて集合を異なって実行するかもしれません。 私たちは小休止を推薦します。
Chan, et al. Informational [Page 5] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[5ページ]のRFC5127集合は2008年2月に属します。
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.
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. それぞれの処理集合には、限りある資源があります。 したがって、交通調節、そして/または、入場はSHOULDを制御します。それぞれのサービスのクラスには、処理集合に集められて、実行されてください。 追加入場コントロールと取り締まりは処理集合に集められたすべての交通の合計で使用されるかもしれません。
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、Virtual兵士のLAN Service)には、あまりそれほど予測できないパターンがあるかもしれませんが。
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サービスのクラス[3]の使用に基づくIP交通の集合について説明するだけです。
4. Service Classes to Treatment Aggregate Mapping
4. 処理の集合マッピングへのサービスのクラス
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.
RFC4594[3]での選択が多くの例で2に関するマッピングを許容するために定義されたか、またはことによると以上がサービスを提供するサービスのクラスとDSCPはただ一つの推進処理集合に属します。 リンク速度と、待ち行列の深さと、遅れと、ジターの間には、関係/トレードオフがあるのに注意してください。 集合の度合いとしたがって、処理集合の数は損失、遅れ、およびジターへの集合の影響に依存するでしょう。 これは集合を実行するのに使用されるリンクとスケジューラの振舞いの速度が異なったパケットサイズに交通を混ぜるという効果を最小にして、待ち行列の深さのレートを伝えることができるかどうかによります。 一般的な経験則は、より高いリンク速度が、よりより多くの集合/少ない数の処理集合を考慮するということです、設計されたレベルの中にリンク利用があると仮定して。
Chan, et al. Informational [Page 6] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[6ページ]のRFC5127集合は2008年2月に属します。
4.1. Mapping Service Classes into Four Treatment Aggregates
4.1. 4つの処理集合にサービスのクラスを写像します。
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].
このセクションはRFC4594[3]で4つの処理集合と定義されたすべてのサービスのクラスを写像する例を提供します。 4つの処理集合の使用は、それぞれの処理集合に割り当てられたリソースがそれぞれのサービスのクラス[3]の必要な振舞いを光栄に思うために十分であると仮定します。 どうサービスのクラスを処理に写像するかに関するガイドが集めるとき、私たちはアプリケーション/エンドユーザからの性能要件(損失、遅れ、およびジターへの寛容)を使用します。 また、私たちは、レアル-時間とElasticアプリケーションの定義のときに指導を私たちに提供するのにRFC1633[4]のセクション3.1を使用しました。 図1でサービスのクラスと4つの処理集合の間のマッピングの概観を提供します、マッピングが性能要件に基づいていて。 図1では、右側コラムの「サービスのクラス」と「損失/遅れ/ジターへの寛容」はRFC4594[3]の図2から来ています。
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.
あるサービスのクラスが特殊療法集合に写像されるのは、お勧めです。 しかし、これは、その処理集合のために推薦されたすべてのサービスのクラスが、支持される必要を意味しません。 したがって、与えられたドメインに、処理集合はこのドキュメントのお勧めのサービスのクラスの部分集合だけを含むかもしれません、すなわち、そのドメインによって支持されたサービスのクラス。 ドメインの非サポートされたサービスのクラスの処理はドメインのローカルの方針に基づくべきです。 顧客との協定でこのローカルの方針は影響を及ぼされるかもしれません。 パケット、またはある他のアレンジメントを落として、そのような処理はElastic Treatment Aggregateを使用するかもしれません。
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つの処理集合だけをサポートして、どんなネットワーク制御交通もAssured Elastic処理集合に写像するかもしれません。 これは管理ドメインにはある選択です。 したがって、4つの処理集合に関するこの例は集合1が実行しなければならない処理の最小の必要なセットを表しません。 また、それは集合1が実行できる処理の最大のセットを表しません。
Chan, et al. Informational [Page 7] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[7ページ]のRFC5127集合は2008年2月に属します。
--------------------------------------------------------------------- |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 | | | | ---------------------------------------------------------------------
--------------------------------------------------------------------- |処理| 寛容||サービスのクラス| 寛容| |集合| 損失|遅れ|ジター|| | 損失|遅れ|ジター| |==========+======+======+======++===============+======+======+======| | ネットワーク| 安値| 安値| はい|| ネットワーク| 安値| 安値| はい| | コントロール| | | || コントロール| | | | |==========+======+======+======++===============+======+======+======| | 本当| まさしくその| まさしくその| まさしくその|| 電話| VLow| VLow| VLow| | 時間| 安値| 安値| 安値||---------------+------+------+------| | | | | || シグナリング| 安値| 安値| はい| | | | | ||---------------+------+------+------| | | | | || マルチメディア|下である、-| まさしくその| 安値| | | | | || 会議|媒体| 安値| | | | | | ||---------------+------+------+------| | | | | || リアルタイムで| 安値| まさしくその| 安値| | | | | || インタラクティブ| | 安値| | | | | | ||---------------+------+------+------| | | | | || 放送| まさしくその|媒体| 安値| | | | | || ビデオ| 安値| | | |==========+======+======+======++===============+======+======+======| | 保証されます。| 安値|下である、-| はい|| マルチメディア|下である、-|媒体| はい| | ゴムひも| |媒体| || ストリーミング|媒体| | | | | | | ||---------------+------+------+------| | | | | || 低遅延| 安値|下である、-| はい| | | | | || データ| |媒体| | | | | | ||---------------+------+------+------| | | | | || OAM| 安値|媒体| はい| | | | | ||---------------+------+------+------| | | | | ||高生産性| 安値|媒体| はい| | | | | || データ| |- 高値| | |==========+======+======+======++===============+======+======+======| | ゴムひも| 指定されません。|| 規格| 指定されません。| | | | | ||---------------+------+------+------| | | | | || 低い優先度| 高値| 高値| はい| | | | | || データ| | | | ---------------------------------------------------------------------
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
また、終わりまでの個々の終わりのサービスのクラスの概念を保存することを勧めているように、私たちは、処理集合が使用されているとき、オリジナルのDSCP分野マークが変えられないことを勧めます。 代わりに、DSCP分野のコンテンツに基づくパケットを選択するクラシファイアはメンバーDiffservサービスのクラスからそれぞれの処理集合を扱う待ち行列にパケットを向けるのに使用されるべきです、パケットのDSCP分野を述べさせないで。 これはそうです。
Chan, et al. Informational [Page 8] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[8ページ]のRFC5127集合は2008年2月に属します。
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.
図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 |
------------------------------------------------------------
------------------------------------------------------------ |処理|処理|| DSCP| |集合|集合|| | | |振舞い|| | |==========+==========++=====================================| | ネットワーク| Cs|| CS6| | コントロール|(RFC2474)|| | |==========+==========++=====================================| | 本当| EF|| EF、CS5、AF41、AF42、AF43、CS4、CS3| | 時間|(RFC3246)|| | |==========+==========++=====================================| | 保証されます。| AF|| CS2、AF31、AF21、AF11| | ゴムひも|(RFC2597)||-------------------------------------| | | || AF32、AF22、AF12| | | ||-------------------------------------| | | || AF33、AF23、AF13| |==========+==========++=====================================| | ゴムひも| デフォルト|| デフォルト、(CS0)| | |(RFC2474)||-------------------------------------| | | || 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のための注意: Assured ElasticとElastic Treatment Aggregatesに関して、セクション4.1.3と4.1を見てください。.4 処理の中の追加優先権に関する詳細に関して、それぞれ、集めてください。
4.1.1. Network Control Treatment Aggregate
4.1.1. ネットワーク制御処理集合
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.
Network Control Treatment AggregateはすべてのDoS攻撃か他の高トラヒック負荷間隔の間ネットワークの生存に機能上必要なサービスのクラスに集めます。 理論は本当であっても、他のことなら何でもネットワークが我が身をかばわなければならないということです。 これはRFC4594[3]がNetwork Controlサービスのクラスに含まれているとして特徴付ける交通を含んでいます。
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).
Class Selector(CS)のためにRFC2474[2]、セクション4.2.2で.2について説明するとき、Network Control Treatment Aggregateの交通はPHBと共に一般的な待ち行列かクラスで運ばれるべきです。 この処理集合は、パケット損失の低い確率を持って、深い目標比較的平均である待ち行列の深さに堪えるべきです(分敷居はRED(無作為のEarly Detection)であるなら使用されています)。
Chan, et al. Informational [Page 9] RFC 5127 Aggregation of Diffserv Service Classes February 2008
チェン、他 Diffservサービスの情報[9ページ]のRFC5127集合は2008年2月に属します。
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.
このNetwork Control Treatment Aggregateが顧客のネットワーク制御交通に使用されることになっているのに注意してください。 プロバイダーは、それ自身のネットワーク制御交通を異なって扱うのを選ぶかもしれません、恐らく顧客のネットワーク制御交通で集められないそれ自身のサービスのクラスで。
4.1.2. Real-Time Treatment Aggregate
4.1.2. リアルタイムの処理集合
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.
レアル-時間Treatment Aggregateはすべてのリアルタイム(弾力性のない)のサービスのクラスに集めます。 理論はリアルタイムの交通がモデルの下で認められて、集合の前にネットワークの縁で経営された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]からの以下のサービスのクラスを含むかもしれません、他の局所的に定義されたクラスに加えて: レアル時間の電話、Signaling、Multimedia Conferencing、Interactive、およびBroadcast Video。
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].
レアル-時間Treatment Aggregateの交通はPHB(1Hop Behaviorあたりの)と共にRFC3246[9]とRFC3247[10]で説明されるように一般的な待ち行列かクラスで運ばれるべきです。
4.1.3. Assured Elastic Treatment Aggregate
4.1.3. 確実な弾性の処理集合
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.
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.
Chan, et al. Informational [Page 10] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 10] RFC 5127 Aggregation of Diffserv Service Classes February 2008
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.
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.
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.
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.
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:
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:
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 <= memory assigned to the queue
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.
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.
Chan, et al. Informational [Page 11] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 11] RFC 5127 Aggregation of Diffserv Service Classes February 2008
4.1.4. Elastic Treatment Aggregate
4.1.4. Elastic Treatment Aggregate
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.
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.
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.
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.
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.
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.
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.
5. Treatment Aggregates and Inter-Provider Relationships
5. Treatment Aggregates and Inter-Provider Relationships
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.
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.
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.
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.
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.
Chan, et al. Informational [Page 12] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 12] RFC 5127 Aggregation of Diffserv Service Classes February 2008
6. Security Considerations
6. Security Considerations
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.
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.
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.
7. Acknowledgements
7. Acknowledgements
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.
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.
8. References
8. References
8.1. Normative References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
for DiffServ Service Classes", RFC 4594, August 2006.
[3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[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., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[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., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
Chan, et al. Informational [Page 13] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 13] RFC 5127 Aggregation of Diffserv Service Classes February 2008
[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., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[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., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[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., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[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., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[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., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
8.2. Informative References
8.2. Informative References
[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., 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>.
[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. and J. Cowie, "Internet Routing Behavior on 9/11", March 2002, <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. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[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", November 2006, < 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, "Network Performance Objectives for IP-Based Services", Recommendation Y.1541, February 2006.
Chan, et al. Informational [Page 14] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 14] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Appendix A. Using MPLS for Treatment Aggregates
Appendix A. Using MPLS for Treatment Aggregates
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.
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.
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.
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.
Chan, et al. Informational [Page 15] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 15] RFC 5127 Aggregation of Diffserv Service Classes February 2008
-------------------------------------------
|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 |
-------------------------------------------
------------------------------------------- |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
Figure 3: Treatment Aggregate and MPLS EXP Field Usage
* 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).
* 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).
Chan, et al. Informational [Page 16] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 16] RFC 5127 Aggregation of Diffserv Service Classes February 2008
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.
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.
A.1. Network Control Treatment Aggregate with E-LSP
A.1. Network Control Treatment Aggregate with 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.
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.
A.2. Real-Time Treatment Aggregate with E-LSP
A.2. Real-Time Treatment Aggregate with 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.
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.
A.3. Assured Elastic Treatment Aggregate with E-LSP
A.3. Assured Elastic Treatment Aggregate with 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.
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.
A.4. Elastic Treatment Aggregate with E-LSP
A.4. Elastic Treatment Aggregate with 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
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
Chan, et al. Informational [Page 17] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 17] RFC 5127 Aggregation of Diffserv Service Classes February 2008
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.
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.
A.5. Treatment Aggregates and L-LSP
A.5. Treatment Aggregates and 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.
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.
Authors' Addresses
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
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 Canada
Phone: +1-613-763-6098 Fax: +1-613-768-2231 EMail: babiarz@nortel.com
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
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
Chan, et al. Informational [Page 18] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Chan, et al. Informational [Page 18] RFC 5127 Aggregation of Diffserv Service Classes February 2008
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
Copyright (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.
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.
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.
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.
Intellectual Property
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.
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.
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.
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.
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.
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.
Chan, et al. Informational [Page 19]
Chan, et al. Informational [Page 19]
一覧
スポンサーリンク
