Network Working Group F. Le Faucheur
Request for Comments: 3564 Cisco Systems, Inc.
Category: Informational W. Lai
AT&T
July 2003
Requirements for Support of Differentiated Services-aware
MPLS Traffic Engineering
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-TE).
この文書では、差別化サービス（差分-SERV）をサポートするためのサービスプロバイダの要件-aware MPLSトラフィックエンジニアリング（DS-TE）を提示しています。
Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document.
その目的は、これらの要件に対処する技術的なソリューションの定義、選択、仕様のガイダンスを提供することです。このソリューション自体の仕様は、このドキュメントの範囲外です。
A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution.
問題文が最初に提供されます。その後、文書は既存のMPLSトラフィックエンジニアリング機構は及ばないとのDiff-Servの対応のトラフィックエンジニアリングは、ニーズに対応できるサービスプロバイダによって識別されるサンプルアプリケーションのシナリオについて説明します。技術的な解決策で対処する必要が詳細な要件も検討されています。最後に、文書には、技術的な解決策の選択と定義を考慮すべきである評価基準を識別します。
Table of Contents
目次
Specification Requirements ....................................... 2
1. Introduction ................................................. 3
1.1. Problem Statement ...................................... 3
1.2. Definitions ............................................ 3
1.3. Mapping of traffic to LSPs ............................. 5
2. Application Scenarios ........................................ 6
2.1. Scenario 1: Limiting Proportion of Classes on a Link ... 6
2.2. Scenario 2: Maintain relative proportion of traffic .... 6
2.3. Scenario 3: Guaranteed Bandwidth Services .............. 8
3. Detailed Requirements for DS-TE .............................. 9
3.1. DS-TE Compatibility .................................... 9
3.2. Class-Types ............................................ 9
3.3. Bandwidth Constraints .................................. 11
3.4. Preemption and TE-Classes .............................. 12
3.5. Mapping of Traffic to LSPs ............................. 15
3.6. Dynamic Adjustment of Diff-Serv PHBs ................... 15
3.7. Overbooking ............................................ 16
3.8. Restoration ............................................ 16
4. Solution Evaluation Criteria ................................. 16
4.1. Satisfying detailed requirements ....................... 17
4.2. Flexibility ............................................ 17
4.3. Extendibility .......................................... 17
4.4. Scalability ............................................ 17
4.5. Backward compatibility/Migration ....................... 17
4.6. Bandwidth Constraints Model ............................ 18
5. Security Considerations ...................................... 18
6. Acknowledgment ............................................... 18
7. Normative References ......................................... 18
8. Informative References ....................................... 19
9. Contributing Authors ......................................... 20
10. Editors' Addresses ........................................... 21
11. Full Copyright Statement ..................................... 22
Specification Requirements
仕様要件
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Diff-Serv is used by some Service Providers to achieve scalable network designs supporting multiple classes of services.
デフ-Servのは、サービスの複数のクラスをサポートするスケーラブルなネットワーク設計を実現するために、いくつかのサービスプロバイダによって使用されています。
In some such Diff-Serv networks, where optimization of transmission resources on a network-wide basis is not sought, MPLS Traffic Engineering (TE) mechanisms may not be used.
ネットワーク全体に基づいて、伝送リソースの最適化が求められていないいくつかのこのような相違-SERVネットワークにおいて、MPLSトラフィックエンジニアリング（TE）機構が使用されなくてもよいです。
In other networks, where optimization of transmission resources is sought, Diff-Serv mechanisms [DIFF-MPLS] may be complemented by MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] [OSPF-TE] [RSVP-TE] which operate on an aggregate basis across all Diff-Serv classes of service. In this case, Diff-Serv and MPLS TE both provide their respective benefits.
送信リソースの最適化が求められる他のネットワークにおいて、差分-SERVメカニズム[DIFF-MPLS]によって補完することができるMPLSトラフィックエンジニアリングメカニズム[TE-REQ] [ISIS-TE] [OSPF-TE] [RSVP-TE]いますサービスのすべてのDiff-Servのクラスの集計に基づいて動作します。この場合、差分-SERVおよびMPLS TEの両方が、それぞれの利点を提供します。
To achieve fine-grained optimization of transmission resources and further enhanced network performance and efficiency, as discussed in [TEWG-FW], it may be desirable to perform traffic engineering at a per-class level instead of at an aggregate level. By mapping the traffic from a given Diff-Serv class of service on a separate LSP, it allows this traffic to utilize resources available to the given class on both shortest paths and non-shortest paths, and follow paths that meet engineering constraints which are specific to the given class. This is what we refer to as "Diff-Serv-aware Traffic Engineering (DS-TE)".
送信リソースのきめ細かい最適化を達成し、さらに[TEWG-FW]で説明したように、ネットワークの性能と効率を向上するためには、クラスごとのレベルで代わりの集約レベルでトラフィック・エンジニアリングを実行することが望ましい場合があります。別LSP上のサービスの所与のDiff-Servのクラスからのトラフィックをマッピングすることにより、このトラフィックは、最短パスと非最短経路の両方に与えられたクラスに対して利用可能なリソースを活用し、特定されている技術の制約を満たす経路をたどることを可能にします与えられたクラスへ。これは、私たちが「差分-Servのを意識したトラフィックエンジニアリング（DS-TE）」と呼ぶものです。
This document focuses exclusively on the specific environments which would benefit from DS-TE. Some examples include:
この文書では、DS-TEの恩恵を受ける特定の環境のみに焦点を当てています。いくつかの例は次のとおりです。
- networks where bandwidth is scarce (e.g., transcontinental networks) - networks with significant amounts of delay-sensitive traffic - networks where the relative proportion of traffic across classes of service is not uniform
- 帯域幅が不足しているネットワーク（例えば、大陸ネットワーク） - 遅延に敏感なトラフィックのかなりの量とネットワーク - サービスクラス間でトラフィックの相対的な割合が均一でないネットワーク
This document focuses on intra-domain operation. Inter-domain operation is not considered.
この文書では、ドメイン内の操作に焦点を当てています。ドメイン間の動作は考慮されていません。
For the convenience of the reader, relevant Diff-Serv ([DIFF-ARCH], [DIFF-NEW] and [DIFF-PDB]) definitions are repeated herein.
読者の便宜のため、関連のDiff-Servの（[DIFF-ARCH]、[DIFF-NEW]と[DIFF-PDB]）の定義は、本明細書に繰り返されます。
Behavior Aggregate (BA): a collection of packets with the same (Diff-Serv) codepoint crossing a link in a particular direction.
動作集約（BA）：同じ（差分-SERV）を有するパケットの集合は、特定の方向にリンクを横切るコードポイント。
Per-Hop-Behavior (PHB): the externally observable forwarding behavior applied at a DS-compliant node to a Diff-Serv behavior aggregate.
ホップ毎の行動（PHB）：外部から観察可能な転送動作は、差分-Servの行動の集計にDS対応のノードに適用されます。
PHB Scheduling Class (PSC): A PHB group for which a common constraint is that ordering of at least those packets belonging to the same microflow must be preserved.
PHBスケジューリングクラス（PSC）：一般的な制約は、少なくともそれらの同じマイクロフローに属するパケットが保存されなければならないの発注されたPHBグループ。
Ordered Aggregate (OA): a set of BAs that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class.
注文した集計（OA）：順序制約を共有するのBAのセット。行動集約のこのセットに適用されているのPHBのセットは、PHBスケジューリングクラスを構成しています。
Traffic Aggregate (TA): a collection of packets with a codepoint that maps to the same PHB, usually in a DS domain or some subset of a DS domain. A traffic aggregate marked for the foo PHB is referred to as the "foo traffic aggregate" or "foo aggregate" interchangeably. This generalizes the concept of Behavior Aggregate from a link to a network.
トラフィック集計（TA）：通常、DSドメインやDSドメインのサブセットでは、同じPHBにマップコードポイントを持つパケットのコレクション。 fooというPHBのためにマークされたトラフィックの集約は、「fooのトラフィック集約」または同義的に「FOOの集約」と呼ばれています。これは、ネットワークへのリンクから行動集計の概念を一般化します。
Per-Domain Behavior (PDB): the expected treatment that an identifiable or target group of packets will receive from "edge-to-edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.
ドメインごとの挙動（PDB）：パケットの識別可能またはターゲットグループがDSドメインの「エッジ・ツー・エッジ」から受ける期待治療。特定のPHB（又は、該当する場合、のPHBのリスト）と交通調節要件は、各PDBに関連付けられています。
We also repeat the following definition from [TE-REQ]:
また、[TE-REQ]から次の定義を繰り返します。
Traffic Trunk: an aggregation of traffic flows of the same class which are placed inside a Label Switched Path.
交通トランク：ラベルスイッチパスの内側に配置されている同じクラスのトラフィックフローの集合体。
In the context of the present document, "flows of the same class" is to be interpreted as "flows from the same Forwarding Equivalence Class which are to be treated equivalently from the DS-TE perspective".
本文書の文脈において、「同じクラスの流れ」は、「DS-TEの観点から等価的に処理すべきである同一の転送等価クラスから流れ」として解釈されるべきです。
We refer to the set of TAs corresponding to the set of PHBs of a given PSC, as a {TA}PSC. A given {TA}PSC will receive the treatment of the PDB associated with the corresponding PSC. In this document, we also loosely refer to a {TA}PSC as a "Diff-Serv class of service", or a "class of service". As an example, the set of packets within a DS domain with a codepoint that maps to the EF PHB may form one {TA}PSC in that domain. As another example, the set of packets within a DS domain with a codepoint that maps to the AF11 or AF12 or AF13 PHB may form another {TA}PSC in that domain.
我々は、{TA} PSCとして、所与のPSCのPHBのセットに対応するTAのセットを指します。所与{TA} PSCは、対応するPSCに関連付けられたPDBの治療を受けます。この文書では、我々はまた、緩く「サービスの差分-SERVクラス」、または「サービスのクラス」として{TA} PSCを指します。一例として、EF PHBにマップコードポイントとのDSドメイン内のパケットの組は、そのドメイン内の1つ{TA} PSCを形成してもよいです。別の例として、AF11又はAF12またはAF13 PHBにマップコードポイントとのDSドメイン内のパケットの組は、そのドメイン内の別{TA} PSCを形成してもよいです。
We refer to the collection of packets which belong to a given Traffic Aggregate and are associated with a given MPLS Forwarding Equivalence Class (FEC) ([MPLS-ARCH]) as a <FEC/TA>.
我々は、与えられたトラフィック集合に属し、所与のMPLS転送等価クラス（FEC）<FEC / TA>として（[MPLS-ARCH]）に関連付けられているパケットの集合を指します。
We refer to the set of <FEC/TA> whose TAs belong to a given {TA}PSC as a <FEC/{TA}PSC>.
我々は、のTAとして与えられた{TA} PSCに属する<FEC / TA> <FEC / {TA} PSC>のセットを指します。
A network may have multiple Traffic Aggregates (TAs) it wishes to service. Recalling from [DIFF-MPLS], there are several options on how the set of <FEC/{TA}PSC> of a given FEC can be split into Traffic Trunks for mapping onto LSPs when running MPLS Traffic Engineering.
ネットワークは、それがサービスを希望する複数のトラフィック集約（TAS）を有していてもよいです。 [DIFF-MPLS]からリコール、上のいくつかのオプションがあるかの組<FEC / {TA} PSC>与えられたFECのは、MPLSトラフィックエンジニアリングを実行するときのLSPにマッピングするためのトラフィックトランクに分割することができます。
One option is to not split this set of <FEC/{TA}PSC> so that each Traffic Trunk comprises traffic from all the {TA}/PSC. This option is typically used when aggregate traffic engineering is deployed using current MPLS TE mechanisms. In that case, all the <FEC/{TA}PSC> of a given FEC are routed collectively according to a single shared set of constraints and will follow the same path. Note that the LSP transporting such a Traffic Trunk is, by definition, an E-LSP as defined in [DIFF-MPLS].
1つのオプションは、各トラフィックトランクがすべて{TA} / PSCからのトラフィックを含むように<FEC / {TA} PSC>のこのセットを分割しないことです。集約トラフィックエンジニアリングは、現在のMPLS TEメカニズムを使用して展開されている場合、このオプションは一般的に使用されています。その場合、すべての<FEC / {TA} PSC>与えられたFECの制約の単一の共有セットに従って一括してルーティングされ、同じ経路を辿るであろう。 [DIFF-MPLS]で定義されるようにLSPは、そのようなトラフィックトランクを輸送することは、定義により、E-LSPであることに留意されたいです。
Another option is to split the different <FEC/{TA}PSC> of a given FEC into multiple Traffic Trunks on the basis of the {TA}PSC. In other words, traffic, from one given node to another, is split, based on the "classes of service", into multiple Traffic Trunks which are transported over separate LSP and can potentially follow different paths through the network. DS-TE takes advantage of this and computes a separate path for each LSP. In so doing, DS-TE can take into account the specific requirements of the Traffic Trunk transported on each LSP (e.g., bandwidth requirement, preemption priority). Moreover DS-TE can take into account the specific engineering constraints to be enforced for these sets of Traffic Trunks (e.g., limit all Traffic Trunks transporting a particular {TA}PSC to x% of link capacity). DS-TE achieves per LSP constraint based routing with paths that match specific objectives of the traffic while forming the corresponding Traffic Trunk.
別のオプションは、{TA} PSCに基づいて複数のトラフィックトランクに与えられたFECの異なる<FEC / {TA} PSC>を分割することです。換言すれば、トラフィックは、別の所定のノードから、別LSP上に搬送され、潜在的にネットワークを介して異なる経路をたどることができる複数のトラフィックトランクに、「サービスのクラス」に基づいて、分割されています。 DS-TEは、この利点を取り、各LSPのために別々の経路を計算します。そうすることで、DS-TEを考慮に入れることができます交通トランクの特定の要件は、各LSP（例えば、帯域幅要件、プリエンプションの優先順位）に搬送されます。またDS-TEは、トラフィックトランクのこれらのセットのために適用される特定の工学的制約を考慮に入れることができる（例えば、すべてのトラフィックがトランクにX％リンク容量の特定{TA} PSCを輸送制限）。 DS-TEは、LSPごとに対応するトラフィックトランクを形成しながら、トラフィックの特定の目的に一致するパスを持つ制約ベースのルーティングを達成します。
For simplicity, and because this is the specific topic of this document, the above paragraphs in this section only considered splitting traffic of a given FEC into multiple Traffic Aggregates on the basis of {TA}PSC. However, it should be noted that, in addition to this, traffic from every {TA}PSC may also be split into multiple Traffic Trunks for load balancing purposes.
これはこの文書の特定のトピックであるため簡単にするために、及び、このセクションで上記のパラグラフのみ{TA} PSCに基づいて複数のトラフィック凝集体に与えられたFECの分割トラフィックを検討しました。しかしながら、これに加えて、すべての{TA} PSCからのトラフィックは、負荷分散のために複数のトラフィックトランクに分割されてもよいことに留意すべきです。
An IP/MPLS network may need to carry a significant amount of VoIP traffic compared to its link capacity. For example, 10,000 uncompressed calls at 20ms packetization result in about 1Gbps of IP traffic, which is significant on an OC-48c based network. In case of topology changes such as link/node failure, VoIP traffic levels can even approach the full bandwidth on certain links.
IP / MPLSネットワークは、そのリンクの容量に比べてVoIPトラフィックを大量に運ぶために必要があるかもしれません。例えば、OC-48Cベースのネットワーク上で重要であり、IPトラフィックのおよその1Gbps、中20msのパケット化結果10,000非圧縮のコール。そのようなリンク/ノードの障害として、トポロジの変更の場合には、VoIPトラフィックレベルでも、特定のリンク上の全帯域幅に近づくことができます。
For delay/jitter reasons, some network administrators see it as undesirable to carry more than a certain percentage of VoIP traffic on any link. The rest of the available link bandwidth can be used to route other "classes of service" corresponding to delay/jitter insensitive traffic (e.g., Best Effort Internet traffic). The exact determination of this "certain" percentage is outside the scope of this requirements document.
遅延/ジッタの理由から、一部のネットワーク管理者は、任意のリンク上のVoIPトラフィックの一定割合以上を運ぶために望ましくないとして、それを参照してください。利用可能なリンク帯域幅の残りの部分は、ルートに/ジッタ小文字を区別しないトラフィック（例えば、ベストエフォートのインターネットトラフィックを）遅らせるために対応する他の「サービスクラス」を使用することができます。この「ある」の割合の正確な決意は、この要件文書の範囲外です。
During normal operations, the VoIP traffic should be able to preempt other "classes of service" (if these other classes are designated as preemptable and they have lower preemption priority), so that it will be able to use the shortest available path, only constrained by the maximum defined link utilization ratio/percentage of the VoIP class.
通常の操作時には、VoIPトラフィックは、最短利用可能パスを使用することができるようになりますように、（これらの他のクラスが優先使用可能として指定され、彼らは低い先取り優先権を持っている場合）、「サービスクラス」他を先取りすることができるはずです、唯一の制約VoIPのクラスの最大定義されたリンク利用率/パーセントによります。
Existing TE mechanisms only allow constraint based routing of traffic based on a single bandwidth constraint common to all "classes of service", which does not satisfy the needs described here. This leads to the requirement for DS-TE to be able to enforce a different bandwidth constraint for different "classes of service". In the above example, the bandwidth constraint to be enforced for VoIP traffic may be the "certain" percentage of each link capacity, while the bandwidth constraint to be enforced for the rest of the "classes of service" might have their own constraints or have access to the rest of the link capacity.
既存のTEメカニズムは、ここでしか説明のニーズを満たしていないすべての「サービスクラス」、に共通の単一の帯域幅の制約に基づいてトラフィックの制約ベースのルーティングを可能にします。これは、異なる「サービスクラス」のために異なる帯域幅の制約を強制することができるようにDS-TEの必要性につながります。 「サービスクラス」の残りのために実施される、帯域幅の制約は、独自の制約を持っているか持っているかもしれないが、上記の例では、VoIPトラフィックのために実施される、帯域幅の制約は、各リンク容量の「ある」の割合かもしれリンク容量の残りの部分へのアクセス。
Suppose an IP/MPLS network supports 3 "classes of service". The network administrator wants to perform Traffic Engineering to distribute the traffic load. Also assume that proportion across "classes of service" varies significantly depending on the source/destination POPs.
IP / MPLSネットワークは3「サービスクラス」をサポートしていたとします。ネットワーク管理者は、トラフィックの負荷を分散するトラヒックエンジニアリングを実行したいと考えています。また、「サービスクラス」全体でその割合は、送信元/宛先のPOPによって大きく異なると仮定します。
With existing TE mechanisms, the proportion of traffic from each "class of service" on a given link will vary depending on multiple factors including:
既存のTEメカニズムでは、与えられたリンクの各「サービスクラス」からのトラフィックの割合は、以下を含む複数の要因によって異なります。
- in which order the different TE-LSPs are established - the preemption priority associated with the different TE-LSPs - link/node failure situations
- ここで確立されている異なるTE-LSPを注文 - 異なるTE-LSPを関連付けられた先取優先 - リンク/ノードの障害状況を
This may make it difficult or impossible for the network administrator to configure the Diff-Serv PHBs (e.g., queue bandwidth) to ensure that each "class of service" gets the appropriate treatment. This leads again to the requirement for DS-TE to be able to enforce a different bandwidth constraint for different "classes of service". This could be used to ensure that, regardless of the order in which tunnels are routed, regardless of their preemption priority and regardless of the failure situation, the amount of traffic of each "class of service" routed over a link matches the Diff-Serv scheduler configuration on that link to the corresponding class (e.g., queue bandwidth).
これは、それが困難または不可能にネットワーク管理者がそれぞれの「サービスのクラスは、」適切な治療を受けることを確実にするためのDiff-ServののPHB（例えば、キューの帯域幅）を設定できるようにするためです。これは、異なる「サービスクラス」のために異なる帯域幅の制約を強制することができるようにDS-TEのための要求に再びつながります。これは関係なく、自分の先取り優先順位のにかかわらず、トンネルがルーティングされる順序の、それを確実にするために使用することができ、関係なく、障害状況の、リンクの上にルーティングされたそれぞれの「サービスクラス」のトラフィック量は、差分-Servのと一致しました対応するクラス（例えば、キューの帯域幅）へリンクしているページ上のスケジューラ構成。
As an illustration of how DS-TE would address this scenario, the network administrator may configure the service rate of Diff-Serv queues to (45%,35%,20%) for "classes of service" (1,2,3) respectively. The administrator would then split the traffic into separate Traffic Trunks for each "class of service" and associate a bandwidth to each LSP transporting those Traffic Trunks. The network administrator may also want to configure preemption priorities of each LSP in order to give highest restoration priority to the highest priority "class of service" and medium priority to the medium "class of service". Then DS-TE could ensure that after a failure, "class of service" 1 traffic would be rerouted with first access at link capacity without exceeding its service rate of 45% of the link bandwidth. "Class of service" 2 traffic would be rerouted with second access at the link capacity without exceeding its allotment. Note that where "class of service" 3 is the Best-Effort service, the requirement on DS-TE may be to ensure that the total amount of traffic routed across all "classes of service" does not exceed the total link capacity of 100% (as opposed to separately limiting the amount of Best Effort traffic to 20 even if there was little "class of service" 1 and "class of service" 2 traffic).
DS-TEは、このシナリオに対処するだろうかの実例として、ネットワーク管理者は、「サービスのクラス」の（45％、35％、20％）に（1,2,3）のDiff-Servのキューのサービス速度を構成することができますそれぞれ。管理者は、それぞれの「サービスのクラス」のために別々のトラフィックトランクにトラフィックを分割し、それらのトラフィックトランクを運ぶ各LSPに帯域幅を関連付けます。ネットワーク管理者は、メディア「サービスのクラス」に優先順位が最も高い「サービスクラス」と中位の優先順位を最復旧の優先順位を与えるために、各LSPのプリエンプションの優先順位を設定することもできます。そして、DS-TEは、障害発生後、「サービスのクラスが」1つのトラフィックがリンク帯域幅の45％のそのサービス率を超えることなく、リンク容量の最初のアクセスで再ルーティングされることを保証することができます。 「サービスのクラスは、」2トラフィックは、その割当てを超えることなく、リンク容量で第二のアクセスで再ルーティングされます。 3「サービスのクラスは、」ベストエフォート型のサービスであり、DS-TE上の要件は、すべての「サービスクラス」全体にルーティングされたトラフィックの総量は100％の総リンク容量を超えないことを確実にすることであってもよいことに注意してください（別途少し「サービスのクラス」1「サービスのクラス」2トラフィックがあった場合でも、20にベストエフォートトラフィックの量を制限することとは対照的に）。
In this scenario, DS-TE would allow for the maintenance of a more steady distribution of "classes of service", even during rerouting. This would rely on the required capability of DS-TE to adjust the amount of traffic of each "class of service" routed on a link based on the configuration of the scheduler and the amount of bandwidth available for each "class of service".
このシナリオでは、DS-TEでも再ルーティングの際に、「サービスクラス」のより安定した分布の維持を可能にします。これは、スケジューラの構成やそれぞれの「サービスのクラス」のために利用可能な帯域幅の量に基づいて、リンク上でルーティングされた各「サービスクラス」のトラフィック量を調整するためにDS-TEのに必要な能力に依存しています。
Alternatively, some network administrators may want to solve the problem by having the scheduler dynamically adjusted based on the amount of bandwidth of the LSPs admitted for each "class of service". This is an optional additional requirement on the DS-TE solution.
あるいは、いくつかのネットワーク管理者は、動的にそれぞれの「サービスのクラス」のために入院LSPの帯域幅の量に基づいて調整スケジューラを持つことによって、問題を解決することをお勧めします。これは、DS-TE溶液にオプションの追加要件です。
In addition to the Best effort service, an IP/MPLS network operator may desire to offer a point-to-point "guaranteed bandwidth" service whereby the provider pledges to provide a given level of performance (bandwidth/delay/loss...) end-to-end through its network from an ingress port to an egress port. The goal is to ensure that all the "guaranteed" traffic under the scope of a subscribed service level specification, will be delivered within the tolerances of this service level specification.
ベストエフォートサービスに加えて、IP / MPLSネットワークオペレータは、プロバイダが、性能（帯域幅/遅延/損失...）の与えられたレベルを提供するために約束することにより、ポイントツーポイント「保証帯域幅」サービスを提供することを望むかもしれませんエンドツーエンドの出力ポートに入力ポートからそのネットワークを介し。目標は、加入したサービスレベルの仕様の範囲の下にあるすべての「保証」のトラフィックは、このサービスレベルの仕様の許容範囲内で配信されることを確実にするためです。
One approach for deploying such "guaranteed" service involves:
そのような「保証」サービスを展開するための一つの方法は、以下のものを含みます：
- dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in [DIFF-NEW]) to the "guaranteed" traffic - policing guaranteed traffic on ingress against the traffic contract and marking the "guaranteed" packets with the corresponding DSCP/EXP value
トラフィック契約に対する入力に保証トラフィックをポリシングし、対応するDSCPと「保証」パケットをマーキング - - 「保証」トラフィックに（[DIFF-NEW]で定義されるように又は相違-SERV PSC）のDiff-ServのPHBを専用/ EXP値
Where a very high level of performance is targeted for the "guaranteed" service, it may be necessary to ensure that the amount of "guaranteed" traffic remains below a given percentage of link capacity on every link. Where the proportion of "guaranteed" traffic is high, constraint based routing can be used to enforce such a constraint.
パフォーマンスの非常に高いレベルが「保証」サービスの対象とされている場合、「保証」トラフィックの量は、すべてのリンク上のリンク容量の一定割合以下に留まることを保証する必要があるかもしれません。 「保証」トラフィックの割合が高い場合、制約ベースのルーティングは、このような制約を強制するために使用することができます。
However, the network operator may also want to simultaneously perform Traffic Engineering for the rest of the traffic (i.e., non-guaranteed traffic) which would require that constraint based routing is also capable of enforcing a different bandwidth constraint, which would be less stringent than the one for guaranteed traffic.
しかし、ネットワークオペレータは、その制約ベースのルーティングを必要とする（すなわち、非保証のトラフィックが）未満厳しくなると思われる、また、異なる帯域幅の制約を強制することができ、同時にトラフィックの残りのトラフィックエンジニアリングを実行することがあります保証トラフィックのための1。
Again, this combination of requirements can not be addressed with existing TE mechanisms. DS-TE mechanisms allowing enforcement of a different bandwidth constraint for guaranteed traffic and for non-guaranteed traffic are required.
ここでも、要件のこの組み合わせは、既存のTEメカニズムで対処することはできません。保証トラフィック用と非保証トラフィックに対して異なる帯域幅の制約の施行を可能DS-TEのメカニズムが必要とされています。
This section specifies the functionality that the above scenarios require out of the DS-TE solution. Actual technical protocol mechanisms and procedures to achieve such functionality are outside the scope of this document.
このセクションでは、上記のシナリオは、DS-TE溶液から必要な機能を指定します。実際の技術的なプロトコル機構およびそのような機能を達成するための手順は、この文書の範囲外です。
Since DS-TE may impact scalability (as discussed later in this document) and operational practices, DS-TE is expected to be used when existing TE mechanisms combined with Diff-Serv cannot address the network design requirements (i.e., where constraint based routing is required and where it needs to enforce different bandwidth constraints for different "classes of service", such as in the scenarios described above in section 2). Where the benefits of DSTE are only required in a topological subset of their network, some network operators may wish to only deploy DS-TE in this topological subset.
DS-TEは、（本書で後述するように）スケーラビリティと運用慣行に影響を与える可能性があるため、DS-TEは、（すなわち、制約ベースのルーティングであり、ネットワーク設計要件に対応することができないのDiff-Servのと組み合わさTEメカニズムを既存のときに使用されることが期待されます必要とこのようなセクション2で上述したシナリオのように異なる「サービスクラス」）のための異なる帯域幅の制約を適用する必要があります。 DSTEのメリットだけ彼らのネットワークのトポロジのサブセットで必要とされている場合は、いくつかのネットワークオペレータは、このトポロジカルサブセットでDSTEを展開することを望むかもしれません。
Thus, the DS-TE solution MUST be developed in such a way that:
：このように、DS-TEのソリューションは、そのような方法で開発しなければなりません
(i) it raises no interoperability issues with existing deployed TE mechanisms. (ii) it allows DS-TE deployment to the required level of granularity and scope (e.g., only in a subset of the topology, or only for the number of classes required in the considered network)
（私は）それは、既存の展開TEメカニズムとは相互運用性の問題を提起しません。 （ii）は、それが粒状とスコープの必要なレベルにDS-TEの展開を可能にする（例えば、唯一のトポロジのサブセットで、あるいはのみ考えネットワークで必要なクラス数の）
The fundamental requirement for DS-TE is to be able to enforce different bandwidth constraints for different sets of Traffic Trunks.
DS-TEのための基本的な要件は、交通トランクスの異なるセットに異なる帯域幅の制約を強制することができることです。
[TEWG-FW] introduces the concept of Class-Types when discussing operations of MPLS Traffic Engineering in a Diff-Serv environment.
デフ-Servの環境でMPLSトラフィックエンジニアリングの動作を議論する際、[TEWG-FW]はクラスタイプの概念を導入しています。
We refine this definition into the following:
私たちは、次のように、この定義を絞り込みます：
Class-Type (CT): the set of Traffic Trunks crossing a link,
that is governed by a specific set of Bandwidth constraints.
CT is used for the purposes of link bandwidth allocation,
constraint based routing and admission control. A given
Traffic Trunk belongs to the same CT on all links.
Note that different LSPs transporting Traffic Trunks from the same CT may be using the same or different preemption priorities as explained in more details in section 3.4 below.
以下のセクション3.4でより詳細に説明したのと同じCTからのトラフィックトランクを輸送する別のLSPは、同一または異なる先取り優先順位を使用してもよいことに留意されたいです。
Mapping of {TA}PSC to Class-Types is flexible. Different {TA}PSC can be mapped to different CTs, multiple {TA}PSC can be mapped to the same CT and one {TA}PSC can be mapped to multiple CTs.
クラスタイプの{TA} PSCのマッピングは柔軟です。異なる{TA} PSCが異なるのCTにマッピングすることができ、複数{TA} PSCは、同じCTにマッピングすることができる一{TA} PSCは、複数のCTにマッピングすることができます。
For illustration purposes, let's consider the case of a network running 4 Diff-Serv PDBs which are respectively based on the EF PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e., Best-Effort) PHB [DIFF-FIELD]. The network administrator may decide to deploy DS-TE in the following way:
例示の目的のために、AF1x PSC [AF]、AF2x PSCおよびデフォルト（すなわち、ベストエフォート）PHBのそれぞれEF PHB [EF]に基づいている4のDiff-ServののPDBを実行しているネットワークの場合を考えます[DIFF-FIELD]。ネットワーク管理者は、次のようにDS-TEを展開することを決定することがあります。
o from every DS-TE Head-end to every DS-TE Tail-end, split the
traffic into 4 Traffic Trunks: one for traffic of each
{TA}PSC
o because the QoS objectives for the AF1x PDB and for the AF2x
PDB may be of similar nature (e.g., both targeting low loss
albeit at different levels perhaps), the same (set of)
Bandwidth Constraint(s) may be applied collectively over the
AF1x Traffic Trunks and the AF2x Traffic Trunks. Thus, the
network administrator may only define three CTs: one for the
EF Traffic Trunks, one for the AF1x and AF2x Traffic Trunks
and one for the Best Effort Traffic Trunks.
As another example of mapping of {TA}PSC to CTs, a network operator may split the traffic from the {TA}PSC associated with EF into two different sets of traffic trunks, so that each set of traffic trunks is subject to different constraints on the bandwidth it can access. In this case, two distinct CTs are defined for the EF {TA}PSC traffic: one for the traffic subset subject to the first (set of) bandwidth constraint(s), the other for the traffic subset subject to the second (set of) bandwidth constraint(s).
トラフィックトランクの各セットは、上の異なる制約を受けるようにCTのに{TA} PSCのマッピングの別の例として、ネットワークオペレータは、トラフィックトランクの2つの異なるセットにEFに関連付けられた{TA} PSCからのトラフィックを分割することができます帯域幅は、それがアクセスすることができます。この場合、2回の別個のCTは、EF {TA} PSCのトラフィックに対して定義されている：最初の（一連の）帯域幅制限（単数または複数）の第二（設定対象トラフィックサブセットのための他の対象のトラフィックサブセットのいずれかを）帯域幅の制約（複数可）。
The DS-TE solution MUST support up to 8 CTs. Those are referred to as CTc, 0 <= c <= MaxCT-1 = 7. The DS-TE solution MUST be able to enforce a different set of Bandwidth Constraints for each CT. A DS-TE implementation MUST support at least 2 CTs, and MAY support up to 8 CTs.
DS-TEのソリューションは、最大8回のCTをサポートしなければなりません。それらは、CTC、0 <= C <= MaxCT-1 = 7と呼ばれるDS-TE溶液を各CTのための帯域幅の制約の異なるセットを適用できなければなりません。 DS-TEの実装では、少なくとも2回のCTをサポートしなければならない、と8回のCTをサポートするかもしれません。
In a given network, the DS-TE solution MUST NOT require the network administrator to always deploy the maximum number of CTs. The DS-TE solution MUST allow the network administrator to deploy only the number of CTs actually utilized.
与えられたネットワークでは、DS-TEのソリューションは、常にCTの最大数を展開するネットワーク管理者に要求してはなりません。 DS-TEのソリューションは、ネットワーク管理者が実際に利用のCT数のみを展開することを可能にしなければなりません。
We refer to a Bandwidth Constraint Model as the set of rules defining:
私たちは、定義する規則のセットとして帯域幅制約モデルを参照してください。
- the maximum number of Bandwidth Constraints; and - which CTs each Bandwidth Constraint applies to and how.
- 帯域幅の制約の最大数。そして - これはCTを各帯域幅の制約が適用されるとどのように。
By definition of CT, each CT is assigned either a Bandwidth Constraint, or a set of Bandwidth Constraints.
CTの定義により、各CTは、帯域幅制約、または帯域幅制約のセットのいずれかが割り当てられます。
We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1
我々は、BCB、0 <= bの<= MaxBC-1のような帯域幅の制約を参照します
For a given Class-Type CTc, 0 <= c <= MaxCT-1, let us define "Reserved(CTc)" as the sum of the bandwidth reserved by all established LSPs which belong to CTc.
指定されたクラス型CTC、0 <= C <= MaxCT-1のために、私たちはCTCに属するすべての確立のLSPによって予約された帯域幅の合計として「予約（CTC）」を定義してみましょう。
Different models of Bandwidth Constraints are conceivable for control of the CTs.
帯域幅の制約の異なるモデルは、CTSの制御のために考えられます。
For example, a model with one separate Bandwidth Constraint per CT could be defined. This model is referred to as the "Maximum Allocation Model" and is defined by:
例えば、CTごとに1つの別個の帯域幅の制約を持つモデルを定義することができました。このモデルは、「最大配分モデル」と呼ばれ、によって定義されます。
- MaxBC= MaxCT
- for each value of b in the range 0 <= b <= (MaxCT - 1):
Reserved (CTb) <= BCb
For illustration purposes, on a link of 100 unit of bandwidth where three CTs are used, the network administrator might then configure BC0=20, BC1= 50, BC2=30 such that:
例示の目的のために、3つのCTSが使用されている帯域幅の100単位のリンクに、ネットワーク管理者は、次に、BC0 = 20、BC1 = 50を設定するかもしれない、BC2 = 30その結果：
- All LSPs supporting Traffic Trunks from CT2 use no more than 30 (e.g., Voice <= 30) - All LSPs supporting Traffic Trunks from CT1 use no more than 50 (e.g., Premium Data <= 50) - All LSPs supporting Traffic Trunks from CT0 use no more than 20 (e.g., Best Effort <= 20)
- CT2からのトラフィックトランクをサポートしているすべてのLSPは、使用していない30以上（例えば、音声<= 30） - からのトラフィックトランクスをサポートするすべてのLSP - CT1からのトラフィックトランクをサポートしているすべてのLSPには50以上（例えば、プレミアムデータ<= 50）を使用していませんCT0は20（例えば、ベストエフォート<= 20）以下で使用しません
As another example, a "Russian Doll" model of Bandwidth Constraints may be defined whereby:
別の例として、帯域幅制約の「ロシア人形」モデルがそれにより定義することができます。
- MaxBC= MaxCT
- for each value of b in the range 0 <= b <= (MaxCT - 1):
SUM (Reserved (CTc)) <= BCb,
for all "c" in the range b <= c <= (MaxCT - 1)
For illustration purposes, on a link of 100 units of bandwidth where three CTs are used, the network administrator might then configure BC0=100, BC1= 80, BC2=60 such that:
例示の目的のために、3つのCTSが使用されている帯域幅の100単位のリンクに、ネットワーク管理者は、次に設定可能性がBC0 = 100、BC1 = 80、BC2 = 60その結果：
- All LSPs supporting Traffic Trunks from CT2 use no more than 60 (e.g., Voice <= 60) - All LSPs supporting Traffic Trunks from CT1 or CT2 use no more than 80 (e.g., Voice + Premium Data <= 80) - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no more than 100 (e.g., Voice + Premium Data + Best Effort <= 100).
- CT1またはCT2からのトラフィックトランクをサポートするすべてのLSPを使用しません80以上（例えば、音声+プレミアムデータ<= 80） - - すべてのLSP CT2からのトラフィックトランクをサポートしているすべてのLSPには60以上（例えば、音声<= 60）を使用していませんCT0またはCT1またはCT2から支える交通トランクスには100以上の（例えば、音声+プレミアムデータ+ベストエフォート<= 100）を使用していません。
Other Bandwidth Constraints model can also be conceived. Those could involve arbitrary relationships between BCb and CTc. Those could also involve additional concepts such as associating minimum reservable bandwidth to a CT.
他の帯域幅の制約モデルも考えられます。これらは、BCBとCTC間の任意の関係を伴う可能性があります。それらはまた、CTに最小予約可能帯域幅を関連付けるなどの追加の概念を必要とすることができます。
The DS-TE technical solution MUST have the capability to support multiple Bandwidth Constraints models. The DS-TE technical solution MUST specify at least one bandwidth constraint model and MAY specify multiple Bandwidth Constraints models. Additional Bandwidth Constraints models MAY also be specified at a later stage if deemed useful based on operational experience from DS-TE deployments. The choice of which (or which set of) Bandwidth Constraints model(s) is to be supported by a given DS-TE implementation, is an implementation choice. For simplicity, a network operator may elect to use the same Bandwidth Constraints Model on all the links of his/her network. However, if he/she wishes/needs to do so, the network operator may elect to use different Bandwidth Constraints models on different links in a given network.
DS-TE技術ソリューションは、複数の帯域幅の制約モデルをサポートする機能を持たなければなりません。 DS-TEの技術的な解決策は、少なくとも1つの帯域幅の制約モデルを指定しなければならないし、複数の帯域幅の制約モデルを指定するかもしれません。 DS-TEの展開から運用経験に基づいて有用であると考えた場合、追加の帯域幅制約モデルも後の段階で指定することができます。帯域幅制約モデル（単数または複数）が与えられたDS-TEの実装によってサポートされるべき（または設定する）の選択は、実装上の選択です。簡単にするために、ネットワークオペレータは、彼/彼女のネットワークのすべてのリンクに同じ帯域幅の制約モデルを使用することを選んでもよいです。彼/彼女は/そうする必要が希望する場合は、ネットワークオペレータは、与えられたネットワーク内の別のリンクに異なる帯域幅の制約モデルを使用することを選んでもよいです。
Regardless of the Bandwidth Constraint Model, the DS-TE solution MUST allow support for up to 8 BCs.
かかわらず、帯域幅制約モデルの、DS-TEのソリューションは、最大8つのBCのサポートを許容しなければなりません。
[TEWG-FW] defines the notion of preemption and preemption priority. The DS-TE solution MUST retain full support of such preemption. However, a network administrator preferring not to use preemption for user traffic MUST be able to disable the preemption mechanisms described below.
[TEWG-FW]はプリエンプションと先取り優先順位の概念を定義します。 DS-TEのソリューションは、このような先取りの全面的な支援を保有しなければなりません。しかし、ユーザトラフィックのためにプリエンプションを使用しない好む、ネットワーク管理者は、下記のプリエンプションメカニズムを無効にすることができなければなりません。
The preemption attributes defined in [TE-REQ] MUST be retained and applicable across all Class Types. The preemption attributes of setup priority and holding priority MUST retain existing semantics, and in particular these semantics MUST not be affected by the Ordered Aggregate transported by the LSP or by the LSP's Class Type. This means that if LSP1 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher set-up preemption priority (i.e., lower numerical priority value) than LSP2's holding preemption priority regardless of LSP1's OA/CT and LSP2's OA/CT.
[TE-REQ]で定義されたプリエンプション属性は保持され、すべてのクラスの型全体に適用されなければなりません。セットアップの優先順位と保持優先度のプリエンプション属性は、既存のセマンティクスを保持しなければならない、特にこれらのセマンティクスは、LSPまたはLSPのクラスタイプによって運ば発注集約による影響を受けてはいけません。これは、LSP1がリソースをLSP2と競合場合LSP1は関係なくLSP1のOA / CTおよびLSP2のOA / CTのLSP2の保持先取り優先順位よりも高く設定アップ先取り優先順位（すなわち、より低いプライオリティ値）を有する場合、LSP1はLSP2を先取りすることができることを意味します。
We introduce the following definition:
私たちは、次の定義を紹介します：
TE-Class: A pair of:
(i) a Class-Type
(ii) a preemption priority allowed for that
Class-Type. This means that an LSP transporting a
Traffic Trunk from that Class-Type can use that
preemption priority as the set-up priority, as the
holding priority or both.
Note that by definition:
定義によってそれに注意してください。
- for a given Class-Type, there may be one or multiple TE-classes using that Class-Type, each using a different preemption priority - for a given preemption priority, there may be one or multiple TE-Class(es) using that preemption priority, each using a different Class-Type.
- 指定されたクラス型のために、一つまたは異なる先取り優先順位を使用してそれぞれ、そのクラスタイプを使用して、複数のTE-クラスが存在し得る - 所与先取り優先順位のために、それを使用して、1つまたは複数のTEクラス（複数可）が存在してもよいです先取り優先順位、異なるクラスタイプを使用して、各。
The DS-TE solution MUST allow all LSPs transporting Traffic Trunks of a given Class-Type to use the same preemption priority. In other words, the DS-TE solution MUST allow a Class-Type to be used by single TE-Class. This effectively allows the network administrator to ensure that no preemption happens within that Class-Type, when so desired.
DS-TEのソリューションは、指定されたクラス型のトラフィックトランクを運ぶすべてのLSPが同じ先取り優先順位を使用することを許容しなければなりません。言い換えれば、DS-TEのソリューションは、クラス型は、単一のTE-クラスによって使用されることを許容しなければなりません。これは、効果的にネットワーク管理者は何の先取りが所望そのクラス型内に起こらないことを保証することができます。
As an example, the DS-TE solution MUST allow the network administrator to define a Class-Type comprising a single TE-class using preemption 0.
一例として、DS-TE溶液は、ネットワーク管理者がプリエンプション0を使用して単一のTE-クラスを含むクラス型を定義することを可能にしなければなりません。
The DS-TE solution MUST allow two LSPs transporting Traffic Trunks of the same Class-Type to use different preemption priorities, and allow the LSP with higher (numerically lower) set-up priority to preempt the LSP with lower (numerically higher) holding priority when they contend for resources. In other words, the DS-TE solution MUST allow multiple TE-Classes to be defined for a given Class-Type. This effectively allows the network administrator to enable preemption within a Class-Type, when so desired.
DS-TE溶液は、二つのLSPを保持する下部（数値的により高い）優先的にLSPを先取りするようにセットアップ（数値的に低い）優先的にLSPを異なる先取優先度を使用し、可能にするために、同じクラス型のトラフィックトランクを搬送可能にしなければなりません彼らは、リソースを競合するとき。言い換えれば、DS-TEのソリューションは、複数のTE-クラスが指定されたクラス型のために定義することを許可する必要があります。これは、効果的に、ネットワーク管理者は、所望のクラス型、内プリエンプションを有効にすることができます。
As an example, the DS-TE solution MUST allow the network administrator to define a Class-Type comprising three TE-Classes; one using preemption 0, one using preemption 1 and one using preemption 4.
一例として、DS-TE溶液は、三TE-クラスを含むクラス型を定義するために、ネットワーク管理者を許可する必要があります。プリエンプション0用いたもの、プリエンプション1を用いたものとプリエンプション4を用いたもの。
The DS-TE solution MUST allow two LSPs transporting Traffic Trunks from different Class-Types to use different preemption priorities, and allow the LSP with higher setup priority to preempt the one with lower holding priority when they contend for resources.
DS-TEのソリューションは、異なるクラスタイプからトラフィックトランクを運ぶ2つのLSPが異なる先取優先順位を使用することができ、彼らがリソースを争う場合は、高設定の優先度を持つLSPが低く保持優先度に1を先取りすることを可能にしなければなりません。
As an example, the DS-TE solution MUST allow the network administrator to define two Class-Types (CT0 and CT1) each comprising two TE-Classes where say:
一例として、DS-TE溶液は、ネットワーク管理者は、2つのクラスタイプ（CT0とCT1）と言うそれぞれ含む二TE-クラスを定義することを可能にしなければなりません。
-one TE-Class groups CT0 and preemption 0 -one TE-Class groups CT0 and preemption 2 -one TE-Class groups CT1 and preemption 1 -one TE-Class groups CT1 and preemption 3
TEクラス基CT0とプリエンプション0 - オンTEクラス基CT0とプリエンプション2オンTEクラスグループCT1とプリエンプション-1-オンTEクラスグループCT1とプリエンプション3 - オン
The network administrator would then, in particular, be able to:
ネットワーク管理者は、その後、特に、できるようになります。
- transport a CT0 Traffic Trunk over an LSP with setup priority=0 and holding priority=0 - transport a CT0 Traffic Trunk over an LSP with setup priority=2 and holding priority=0 - transport a CT1 Traffic Trunk over an LSP with setup priority=1 and holding priority=1 - transport a CT1 Traffic Trunk over an LSP with setup priority=3 and holding priority=1.
- 設定の優先順位を持つLSP上CT0トラフィックトランクを輸送= 0及び保持優先順位= 0 - セットアップ優先度LSP上CT0トラフィックトランクを輸送= 2及び保持優先順位= 0 - セットアップ優先度LSP上CT1トラフィックトランクを輸送= 1及び保持優先順位= 1 - セットアップ優先度= 3および保持優先順位= 1とLSP上CT1トラフィックトランクを運びます。
The network administrator would then, in particular, NOT be able to:
ネットワーク管理者は、その後、特に、することはできません。
- transport a CT0 Traffic Trunk over an LSP with setup priority=1 and holding priority=1 - transport a CT1 Traffic Trunk over an LSP with setup priority=0 and holding priority=0
- 設定の優先順位= 1及び保持優先順位= 1のLSP上搬送CT0トラフィックトランク - セットアップ優先順位= 0及び保持優先順位= 0のLSP上CT1トラフィックトランクを輸送
The DS-TE solution MUST allow two LSPs transporting Traffic Trunks from different Class-Types to use the same preemption priority. In other words, the DS-TE solution MUST allow TE-classes using different CTs to use the same preemption priority. This effectively allows the network administrator to ensure that no preemption happens across Class-Types, if so desired.
DS-TEのソリューションは、異なるクラスタイプからトラフィックトランクを運ぶ2つのLSPは、同じ先取り優先順位を使用することを許容しなければなりません。言い換えれば、DS-TEのソリューションは、同じ先取り優先順位を使用するように異なるのCTを使用してTE-クラスを許容しなければなりません。これは、効果的に、ネットワーク管理者が必要に応じて何のプリエンプションは、クラス・タイプ間で起こらないことを保証することができます。
As an example, the DS-TE solution MUST allow the network administrator to define three Class-Types (CT0, CT1 and CT2) each comprising one TE-Class which uses preemption 0. In that case, no preemption will ever occur.
一例として、DS-TE溶液は、ネットワーク管理者は3クラスタイプ（CT0、CT1及びCT2）その場合、プリエンプション0を使用してそれぞれ含むものTE-Classは、何プリエンプションがこれまで発生しない定義することができなければなりません。
Since there are 8 preemption priorities and up to 8 Class-Types, there could theoretically be up to 64 TE-Classes in a network. This is felt to be beyond current practical requirements. The current practical requirement is that the DS-TE solution MUST allow support for up to 8 TE-classes. The DS-TE solution MUST allow these TE-classes to comprise any arbitrary subset of 8 (or less) from the (64) possible combinations of (8) Class-Types and (8) preemption priorities.
最大8クラス型への8つのプリエンプションの優先順位とがあるので、理論的には、ネットワーク内の最大64 TE-クラスがあるかもしれません。これは、現在の実用的な要件を超えていると感じています。現在の実用的な要件は、DS-TEのソリューションは、最大8 TE-クラスのサポートを許可しなければならないということです。 DS-TE溶液（8）クラスタイプおよび（8）先取り優先順位の（64）の可能な組合せから、これらのTE-クラスは8（またはそれ以下）の任意のサブセットを含むことができるようにしなければなりません。
As with existing TE, an LSP which gets preempted is torn down at preemption time. The Head-end of the preempted LSP may then attempt to reestablish that LSP, which involves re-computing a path by Constraint Based Routing based on updated available bandwidth information and then signaling for LSP establishment along the new path. It is to be noted that there may be cases where the preempted LSP cannot be reestablished (e.g., no possible path satisfying LSP bandwidth constraints as well as other constraints). In such cases, the Head-end behavior is left to implementation. It may involve periodic attempts at reestablishing the LSP, relaxing of the LSP constraints, or other behaviors.
既存のTEと同様に、差し替えられますLSPをプリエンプション時に解体されます。プリエンプトLSPのヘッドエンドは、その後、更新された利用可能な帯域幅の情報に基づいて、制約ベースのルーティングによって経路を再計算し、新しいパスに沿ってLSPの確立のためのシグナリングを伴うそのLSPを再確立しようと試みることができます。それはプリエンプトLSPを再確立できない場合場合があることに留意すべきである（例えば、無LSP帯域幅の制約を満足可能な経路ならびに他の制約）。このような場合には、ヘッドエンドの動作は実装に任されています。これは、LSPの制約の緩和、LSPを再確立で定期的に試み、またはその他の行動を含むことができます。
The DS-TE solution MUST allow operation over E-LSPs onto which a single <FEC/{TA}PSC> is transported.
DS-TE溶液は、単一の<FEC / {TA} PSC>が搬送され、その上にE-LSPの上操作を可能にしなければなりません。
The DS-TE solution MUST allow operation over L-LSPs.
DS-TEのソリューションは、L-LSPを超える運転を許容しなければなりません。
The DS-TE solution MAY allow operation over E-LSPs onto which multiple <FEC/{TA}PSC> of a given FEC are transported, under the condition that those multiple <FEC/{TA}PSC> can effectively be treated by DS-TE as a single atomic traffic trunk (in particular this means that those multiple <FEC/{TA}PSC> are routed as a whole based on a single collective bandwidth requirement, a single affinity attribute, a single preemption level, a single Class-Type, etc.). In that case, it is also assumed that the multiple {TA}PSCs are grouped together in a consistent manner throughout the DS-TE domain (e.g., if <FECx/{TA}PSC1> and <FECx/{TA}PSC2> are transported together on an E-LSP, then there will not be any L-LSP transporting <FECy/{TA}PSC1> or <FECy/{TA}PSC2> on its own, and there will not be any E-LSP transporting <FECz/{TA}PSC1> and/or <FECz/{TA}PSC2> with <FECz/{TA}PSC3>).
与えられたFECの溶液れる複数にE-LSPの上操作を可能-TEのDS <FEC / {TAは} PSC> <FEC / {TA} PSC>これらの複数が、効果的にDSによって治療することができることを条件として、搬送されます単一原子トラフィックトランクとして-TE（特に、これは、これら複数の<FEC / {TA} PSC>は単一の集合帯域幅要件、単一親和性属性、単一プリエンプトレベル、単一のクラスに基づいて、全体として配線されていることを意味します型、など）。その場合には、DSは、TEドメイン（例えば、<FECx / {TA} PSC1> IFおよび<FECx / {TA} PSC2>は全体の複数{TA}のPSCを一貫した方法で一緒にグループ化されることも想定されますE-LSP上に一緒に運ば、次いで任意L-LSPが<FECy / {TA} PSC1>または<FECy / {TA} PSC2>独自での輸送、および任意のE-LSPの輸送が存在しないであろうが存在しません< FECz / {TA} PSC1>及び/又は<FECz / {TA} PSC2>と<FECz / {TA} PSC3>）。
As discussed in section 2.2, the DS-TE solution MAY support adjustment of Diff-Serv PHBs parameters (e.g., queue bandwidth) based on the amount of TE-LSPs established for each OA/Class-Type. Such dynamic adjustment is optional for DS-TE implementations.
セクション2.2で議論したように、DS-TE溶液を各OA /クラスタイプについて確立TE-LSPの量に基づいて、差分-SERVのPHBのパラメータ（例えば、キューの帯域幅）の調整をサポートするかもしれません。そのような動的な調整は、DS-TEの実装のためにオプションです。
Where this dynamic adjustment is supported, it MUST allow for disabling via configuration (thus reverting to PHB treatment with static scheduler configuration independent of DS-TE operations). It MAY involve a number of configurable parameters which are outside the scope of this specification. Those MAY include configurable parameters controlling how scheduling resources (e.g., service rates) need to be apportioned across multiple OAs when those belong to the same Class-Type and are transported together on the same E-LSP.
この動的調整がサポートされている場合、それは（したがって、DS-TE動作の静的スケジューラ構成独立による治療をPHBに戻す）構成を介してディスエーブルを可能にしなければなりません。これは、この仕様の範囲外である設定可能なパラメータの数を含むことができます。それらはどのようにスケジューリングリソース（例えば、サービス率）を制御する設定可能なパラメータを含むことができるものは、同じクラスの型に属し、同じE-LSP上で一緒に輸送される際に、複数のOA間で配分する必要があります。
Where supported, the dynamic adjustment MUST take account of the performance requirements of each PDB when computing required adjustments.
サポートされている場合、動的な調整が必要な調整を計算する各PDBの性能要件を考慮しなければなりません。
Existing TE mechanisms allow overbooking to be applied on LSPs for Constraint Based Routing and admission control. Historically, this has been achieved in TE deployment through factoring overbooking ratios at the time of sizing the LSP bandwidth and/or at the time of configuring the Maximum Reservable Bandwidth on links.
既存のTEメカニズムは、制約ベースのルーティングとアドミッション制御のためのLSPに適用されるオーバーブッキングを可能にします。歴史的に、これはLSPの帯域幅および/またはリンク上で予約可能な最大帯域幅を設定する時にはサイジングの際にオーバーブッキング比率を加味してTEの展開で達成されています。
The DS-TE solution MUST also allow overbooking and MUST effectively allow different overbooking ratios to be enforced for different CTs.
DS-TE溶液は、オーバーブッキング可能にしなければならないと有効異なるオーバーブッキング比が異なるのCTのために適用されることを可能にしなければなりません。
The DS-TE solution SHOULD optionally allow the effective overbooking ratio of a given CT to be tweaked differently in different parts of the network.
DS-TE溶液は、必要に応じて、所与のCTの効果的なオーバーブッキング比はネットワークの異なる部分に異なる微調整することが可能にすべきです。
With existing TE, restoration policies use standard priority mechanisms such as, for example, the preemption priority to effectively control the order/importance of LSPs for restoration purposes.
既存のTEと、復旧ポリシーは、例えば、先取り優先順位を効果的に復元のためにLSPの順序/重要性を制御する、などの標準的な優先順位メカニズムを使用します。
The DS-TE solution MUST ensure that similar application of the use of standard priority mechanisms for implementation of restoration policy are not prevented since those are expected to be required for achieving the survivability requirements of DS-TE networks.
DS-TE溶液は、それらをDS-TEネットワークの生存要件を達成するために必要とされることが予想されるので、復元ポリシーの実施のための標準的な優先機構の使用の同様のアプリケーションが防止されていないことを確認しなければなりません。
Further discussion of restoration requirements are presented in the output document of the TEWG Requirements Design Team [SURVIV-REQ].
復元の要件のさらなる議論はTEWG要件設計チーム[SURVIV-REQ]の出力文書で提示されています。
A range of solutions is possible for the support of the DS-TE requirements discussed above. For example, some solutions may require that all current TE protocols syntax (IGP, RSVP-TE,) be extended in various ways. For instance, current TE protocols could be modified to support multiple bandwidth constraints rather than the existing single aggregate bandwidth constraint. Alternatively, other solutions may keep the existing TE protocols syntax unchanged but modify their semantics to allow for the multiple bandwidth constraints.
ソリューションの範囲は、上述のDS-TE要件をサポートするために可能です。例えば、いくつかのソリューションは、現在のすべてのTEプロトコル構文（IGP、RSVP-TEは、）は、様々な方法で拡張することを必要とするかもしれません。例えば、現在のTEプロトコルは、複数の帯域幅の制約ではなく、既存の単一の集約帯域幅の制約をサポートするように変更することができます。また、他のソリューションは変わらず、既存のTEプロトコルの構文を保つが、複数の帯域幅の制約を許容するために彼らのセマンティクスを変更することがあります。
This section identifies the evaluation criteria that MUST be used to assess potential DS-TE solutions for selection.
このセクションでは、選択のための潜在的なDS-TEソリューションを評価するために使用されなければならない評価基準を識別する。
The solution MUST address all the scenarios described in section 2 and satisfy all the requirements listed in section 3.
溶液は、セクション2で説明したすべてのシナリオに対処し、セクション3に記載されているすべての要件を満たさなければなりません。
- number of Class-Types that can be supported, compared to number identified in Requirements section - number of PDBs within a Class-Type
- 要件セクションで識別された数と比較サポートすることができるクラスタイプの数 - クラスタイプ内のPDBの数
- how far can the solution be extended in the future if requirements for more Class-Types are identified in the future.
- より多くのクラスタイプの要件が将来的に同定されている場合はどのくらいソリューションは、将来的に拡張することができます。
- impact on network scalability in what is propagated, processed, stored and computed (IGP signaling, IGP processing, IGP database, TE-Tunnel signaling ,...). - how does scalability impact evolve with number of Class-Types/PDBs actually deployed in a network. In particular, is it possible to keep overhead small for a large networks which only use a small number of Class-Types/PDBs, while allowing higher number of Class-Types/PDBs in smaller networks which can bear higher overhead)
- ネットワークのスケーラビリティへの影響、伝播処理、格納され、計算されたもの（IGPシグナリング、IGP処理、IGPデータベースを、TEトンネルシグナリング、...）。 - どのようにスケーラビリティの影響が実際にネットワークに配備クラスタイプ/のPDBの数と進化ありません。具体的には、クラスタイプのより高い数を可能にしながら、唯一のクラスタイプ/のPDBの小さな数を使用する大規模ネットワークのためのオーバーヘッド小さい維持することが可能である/より高いオーバーヘッドを負担することができる小規模なネットワークでのPDB）
- backward compatibility/migration with/from existing TE mechanisms - backward compatibility/migration when increasing/decreasing the number of Class-Types actually deployed in a given network.
- 既存のTEメカニズムからの/との下位互換性/移行 - 後方互換性/移行増加/実際、所与のネットワークに配備クラスタイプの数を減少させます。
Work is currently in progress to investigate the performance and trade-offs of different operational aspects of Bandwidth Constraints models (for example see [BC-MODEL], [BC-CONS] and [MAR]). In this investigation, at least the following criteria are expected to be considered:
仕事は、パフォーマンスと帯域幅の制約モデルの異なる運用面のトレードオフ（例えば[BC-MODEL]を参照してください、[BC-CONS]および[MAR]）を調査するために現在進行中です。この調査では、少なくとも以下の基準を考慮することが期待されています。
(1) addresses the scenarios in Section 2
(2) works well under both normal and overload conditions
(3) applies equally when preemption is either enabled or disabled
(4) minimizes signaling load processing requirements
(5) maximizes efficient use of the network
(6) Minimizes implementation and deployment complexity.
In selection criteria (2), "normal condition" means that the network is attempting to establish a volume of DS-TE LSPs for which it is designed; "overload condition" means that the network is attempting to establish a volume of DS-TE LSPs beyond the one it is designed for; "works well" means that under these conditions, the network should be able to sustain the expected performance, e.g., under overload it is x times worse than its normal performance.
選択基準（2）において、「正常な条件」は、ネットワークは、それが設計されているDS-TE LSPの容積を確立しようとしていることを意味します。 「過負荷状態が」ネットワークは、それがために設計されている1を超えるDS-TEのLSPのボリュームを確立しようとしていることを意味します。 「うまく機能」は、これらの条件下で、ネットワークが過負荷の下で、その通常の性能よりもX倍悪くなり、例えば、期待される性能を維持することができなければならないことを意味します。
The solution developed to address the DS-TE requirements defined in this document MUST address security aspects. DS-TE does not raise any specific additional security requirements beyond the existing security requirements of MPLS TE and Diff-Serv. The solution MUST ensure that the existing security mechanisms (including those protecting against DOS attacks) of MPLS TE and Diff-Serv are not compromised by the protocol/procedure extensions of the DS-TE solution or otherwise MUST provide security mechanisms to address this.
ソリューションは、セキュリティの側面に対処しなければならない。この文書で定義されたDS-TEの要件に対処するために開発します。 DS-TEは、MPLS TEとのDiff-Servの既存のセキュリティ要件を越えた特定の追加のセキュリティ要件は発生しません。溶液は、MPLS TEとのDiff-Servのの（DOS攻撃から保護するものを含む）既存のセキュリティメカニズムはDS-TE溶液のプロトコル/手順の拡張によって損なわれないか、そうでなければこれに対処するためのセキュリティメカニズムを提供しなければならないことを保証しなければなりません。
We thank David Allen for his help in aligning with up-to-date Diff-Serv terminology.
私たちは、最新のDiff-Servの用語で揃えるの彼の助けのためデビッド・アレンに感謝します。
[AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DIFF-ARCH]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[DIFF-FIELD] 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.
[DIFF-FIELD]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[DIFF-MPLS] 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.
[DIFF-MPLS]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.及びJ. Heinanen、「マルチプロトコルラベル差別化サービスの（MPLS）サポート」、RFC 3270、2002年5月を切り替えます。
[DIFF-NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[DIFF-NEW]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
[EF] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
【EF】デイビー、B.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、Davari、S.、コートニー、W.、Firioiu、V.およびD. Stiliadis、「緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[TEWG-FW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[TEWG-FW] Awduche、D.、チウ、A.、Elwalid、A.、Widjaja、I.およびX.シャオ、 "インターネットトラフィックエンジニアリングの概要と原則"、RFC 3272、2002年5月。
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[TE-REQ] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、 "MPLSのトラフィックエンジニアリングのための要件"、RFC 2702、1999年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[DIFF-PDB] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[DIFF-PDB]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、RFC 3086、2001年4月。
[ISIS-TE] Smit, Li, "IS-IS extensions for Traffic Engineering", Work in Progress, December 2002.
[ISIS-TE]スミット、李、 "トラフィックエンジニアリングのためのISISの拡張"、進歩、2002年12月の作業。
[OSPF-TE] Katz, et al., "Traffic Engineering Extensions to OSPF", Work in Progress, October 2002.
[OSPF-TE]カッツら、 "OSPFへのトラフィックエンジニアリングの拡張"、進歩、2002年10月の作業。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニバサン、V.およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209、 2001年12月。
[SURVIV-REQ] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[SURVIV-REQ]ライ、W.およびD. McDysan、 "ネットワーク階層と多層耐障害"、RFC 3386、2002年11月。
[BC-MODEL] Lai, W., "Bandwidth Constraints Models for Diffserv-aware MPLS Traffic Engineering: Performance Evaluation", Work in Progress, June 2002.
[BC-MODEL]ライ、W.、 "Diffservの認識MPLSトラフィックエンジニアリングのための帯域幅の制約モデル：性能評価"、進歩、2002年6月での作業。
[BC-CONS] F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress, June 2002.
[BC-CONS] F.ルFaucheur、 "DS-TEのための帯域幅制約モデルの検討"、進歩、2002年6月での作業。
[MAR] Ash, J., "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", Work in Progress, May 2003.
[MAR]アッシュ、J.、「MPLS / DiffServのTE＆パフォーマンスの比較のために予約の帯域幅制約モデルとの最大の割り当て」進行中、仕事、2003年5月。
This document was the collective work of several people. The text and content of this document was contributed by the editors and the co-authors listed below. (The contact information for the editors appears below.)
この文書では、数人の集団的な作業でした。この文書のテキストやコンテンツを編集し、以下のとおり共著者によって寄贈されました。 （編集者の連絡先情報が下に表示されます。）
Martin Tatham Thomas Telkamp BT Global Crossing Adastral Park, Martlesham Heath, Oudkerkhof 51, 3512 GJ Utrecht Ipswich IP5 3RE, UK The Netherlands Phone: +44-1473-606349 Phone: +31 30 238 1250 EMail: martin.tatham@bt.com EMail: telkamp@gblx.net
マーティンタサムトーマスTelkamp BTグローバル・クロッシングAdastral公園、Martleshamヒース、51 Oudkerkhof、3512 GJユトレヒトイプスウィッチIP5 3RE、英国オランダ電話：+ 44-1473-606349電話：+31 30 238 1250 Eメール：martin.tatham@bt.comメールアドレス：telkamp@gblx.net
David Cooper Jim Boyle Global Crossing Protocol Driven Networks, Inc. 960 Hamlin Court 1381 Kildaire Farm Road #288 Sunnyvale, CA 94089, USA Cary, NC 27511, USA Phone: (916) 415-0437 Phone: (919) 852-5160 EMail: dcooper@gblx.net EMail: jboyle@pdnets.com
デビッド・クーパージム・ボイルグローバル・クロッシングプロトコルドリブンネットワークス株式会社960ハムリン法廷1381 Kildaire農道＃288サニーベール、CA 94089、USAカリー、NC 27511、USA電話：（916）415から0437まで電話：（919）852から5160 Eメール：dcooper@gblx.net Eメール：jboyle@pdnets.com
Luyuan Fang Gerald R. Ash AT&T Labs AT&T Labs 200 Laurel Avenue 200 Laurel Avenue Middletown, New Jersey 07748, USA Middletown, New Jersey 07748,USA Phone: (732) 420-1921 Phone: (732) 420-4578 EMail: luyuanfang@att.com EMail: gash@att.com
Luyuan牙ジェラルドR.アッシュAT＆T LabsのAT＆T Labsの200ローレルアベニュー200ローレルアベニューミドルタウン、ニュージャージー州07748、USAミドルタウン、ニュージャージー州07748、USA電話：（732）420から1921まで電話：（732）420から4578 Eメール：luyuanfang @ att.com Eメール：gash@att.com
Pete Hicks Angela Chiu CoreExpress, Inc AT&T Labs-Research 12655 Olive Blvd, Suite 500 200 Laurel Ave. Rm A5-1F13 St. Louis, MO 63141, USA Middletown, NJ 07748, USA Phone: (314) 317-7504 Phone: (732) 420-9061 EMail: pete.hicks@coreexpress.net EMail: chiu@research.att.com
ピート・ヒックスアンジェラ・チウCoreExpress、株式会社AT＆T Labsの研究-12655オリーブブルバード、スイート500 200ローレルアベニュー。 RmのA5-1F13セントルイス、MO 63141、USAミドルタウン、NJ 07748、USA電話：（314）317から7504まで電話：（732）420から9061 Eメール：pete.hicks@coreexpress.net Eメール：chiu@research.att .COM
William Townsend Thomas D. Nadeau Tenor Networks Cisco Systems, Inc. 100 Nagog Park 300 Beaver Brook Road Acton, MA 01720, USA Boxborough, MA 01719 Phone: +1 978-264-4900 Phone: +1-978-936-1470 EMail:btownsend@tenornetworks.com EMail: tnadeau@cisco.com
ウィリアム・タウンゼント・トーマスD.ナドーテナーネットワークシスコシステムズ社100 Nagog公園300ビーバーブルックロードアクトン、MA 01720、USAボックスボロー、MA 01719電話：+1 978-264-4900電話：+ 1-978-936-1470 Eメール：btownsend@tenornetworks.com Eメール：tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9, Phone: (613) 765-2252 EMail: dareks@nortelnetworks.com
Darek Skalecki Nortel Networksの3500カーリングアベニュー、ネピアンK2H 8E9、電話：（613）765から2252 Eメール：dareks@nortelnetworks.com
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis, France
フランソワ・リーパーシスコシステムズ社コーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanille 06410ビオ・ソフィアアンティポリス、フランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
Wai Sum Lai AT&T Labs 200 Laurel Avenue Middletown, New Jersey 07748, USA
ワイ合計ライAT＆T Labsの200ローレルアベニューミドルタウン、ニュージャージー州07748、USA
Phone: (732) 420-3712 EMail: wlai@att.com
電話：（732）420-3712 Eメール：wlai@att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。