[要約] RFC 3564は、異なるサービスを意識したMPLSトラフィックエンジニアリングの要件を定義しています。このRFCの目的は、MPLSネットワークでのトラフィックエンジニアリングにおいて、異なるサービス品質を提供するための要件を明確にすることです。

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

差別化されたサービス認識MPLSトラフィックエンジニアリングのサポートの要件

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.

Copyright(c)The Internet Society(2003)。無断転載を禁じます。

Abstract

概要

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-TE).

このドキュメントでは、差別化されたサービス(diff-serv)を支持する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-Aware Traffic Engineeringがニーズに対応できるサービスプロバイダーによって特定されたアプリケーションの例のシナリオについて説明します。技術的なソリューションで対処する必要がある詳細な要件もレビューされています。最後に、ドキュメントは、技術的なソリューションの選択と定義のために考慮されるべき評価基準を特定します。

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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

1. Introduction
1. はじめに
1.1. Problem Statement
1.1. 問題文

Diff-Serv is used by some Service Providers to achieve scalable network designs supporting multiple classes of services.

Diff-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.

ネットワーク全体で送信リソースの最適化が求められていないこのような差別的なネットワークでは、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.

トランスミッションリソースの最適化が求められる他のネットワークでは、diff-servメカニズム[diff-mpls]は、MPLSトラフィックエンジニアリングメカニズム[TE-REQ] [ISIS-TE] [OSOSP-TE] [RSVP-TE]によって補完される場合があります。すべてのDiff-Servクラスのサービスにわたって総合的に動作します。この場合、Diff-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]で説明されているように、トランスミッションリソースの微調整された最適化とネットワークのパフォーマンスと効率をさらに強化するには、集合レベルではなくクラスごとのレベルでトラフィックエンジニアリングを実行することが望ましい場合があります。特定のDIFSERVサービスクラスのサービスのトラフィックを別のLSPにマッピングすることにより、このトラフィックは、最短パスと非短いパスの両方で特定のクラスで利用可能なリソースを利用し、特定のエンジニアリングの制約を満たすパスに従うことができます。与えられたクラスに。これは、「Diff-Serv-Aware Traffic Engineering(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.

このドキュメントは、ドメイン内操作に焦点を当てています。ドメイン間操作は考慮されません。

1.2. Definitions
1.2. 定義

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):同じ(diff-serv)コードポイントを持つパケットのコレクションは、特定の方向にリンクを越えます。

Per-Hop-Behavior (PHB): the externally observable forwarding behavior applied at a DS-compliant node to a Diff-Serv behavior aggregate.

PER-HOP-BEHAVIOR(PHB):DSに準拠したノードで適用される外部的に観察可能な転送動作は、Diff-Servの動作の集合体に適用されます。

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):順序付けの制約を共有するBASのセット。この一連の動作集合体に適用される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.

Traffic Aggregate(TA):同じPHBにマッピングするコードポイントを備えたパケットのコレクション、通常はDSドメインまたはDSドメインのサブセット。FOO PHBにマークされたトラフィックの集計は、「Foo Traffic Aggregate」または「Foo Grogigate」と同じ意味で呼ばれます。これは、リンクからネットワークへの動作の概念を一般化します。

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.

特定のPSCのPHBのセットに対応するTAのセットを、{Ta} PSCと呼びます。与えられた{TA} PSCは、対応するPSCに関連するPDBの治療を受けます。このドキュメントでは、{Ta} PSCを「Diff-Serv Class of Service」または「サービスのクラス」と大まかに参照しています。例として、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)([MPLS-ARCH])に関連付けられているパケットのコレクションをA <FEC/TA>と呼びます。

We refer to the set of <FEC/TA> whose TAs belong to a given {TA}PSC as a <FEC/{TA}PSC>.

TASが与えられた{ta} PSCに属している<fec/ta>のセットをa <fec/{ta} psc>と呼びます。

1.3. Mapping of traffic to LSPs
1.3. LSPへのトラフィックのマッピング

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.

ネットワークには、サービスを希望する複数のトラフィック集合体(TA)がある場合があります。[diff-mpls]から思い出して、特定のFECの<fec/{ta} psc>のセットを、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のすべての<fec/{ta} psc>は、単一の共有制約セットに従って集合的にルーティングされ、同じパスに従います。このようなトラフィックトランクを輸送するLSPは、定義上、[diff-mpls]で定義されている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.

別のオプションは、特定のFECの異なる<fec/{ta} psc>を{ta} pscに基づいて複数のトラフィックトランクに分割することです。言い換えれば、1つの指定されたノードから別のノードへのトラフィックは、「サービスのクラス」に基づいて、別々のLSPで輸送され、ネットワークを介して異なるパスに従う可能性がある複数のトラフィックトランクに分割されます。DS-TEはこれを利用し、各LSPの個別のパスを計算します。そうすることで、DS-TEは、各LSPで輸送されるトラフィックトランクの特定の要件を考慮することができます(例:帯域幅要件、先制の優先順位)。さらに、DS-TEは、これらのトラフィックトランクのセットに対して実施する特定のエンジニアリングの制約を考慮することができます(たとえば、特定の{TA} PSCをリンク容量のx%に輸送するすべてのトラフィックトランクを制限します)。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からのトラフィックは、負荷分散の目的で複数のトラフィックトランクに分割される場合があることに注意する必要があります。

2. Application Scenarios
2. アプリケーションシナリオ
2.1. シナリオ1:リンク上のクラスの割合を制限する

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トラフィックを運ぶ必要がある場合があります。たとえば、20msのパケット化で10,000個の非圧縮呼び出しにより、約1gbpsのIPトラフィックが発生します。これは、OC-48Cベースのネットワークで重要です。リンク/ノード障害などのトポロジの変更の場合、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トラフィックに対して施行される帯域幅の制約は各リンク容量の「特定の」割合である可能性がありますが、「サービスのクラス」の残りの部分で帯域幅の制約が強制される可能性があります。リンク容量の残りの部分へのアクセス。

2.2. Scenario 2: Maintain relative proportion of traffic
2.2. シナリオ2:トラフィックの相対的な割合を維持します

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つの「クラスのサービス」をサポートするとします。ネットワーク管理者は、トラフィックの負荷を分配するためにトラフィックエンジニアリングを実行したいと考えています。また、「サービスのクラス」全体の割合は、ソース/宛先ポップによって大きく異なると仮定します。

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が異なる「サービスのクラス」に対して異なる帯域幅の制約を実施できるようにするための要件に再びつながります。これは、トンネルがルーティングされる順序に関係なく、先制の優先順位に関係なく、失敗状況に関係なく、リンク上にルーティングされる各「サービスクラス」のトラフィックの量がDIFF-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がこのシナリオにどのように対処するかの例として、ネットワーク管理者は、「サービスのクラス」(1,2,3)のDiff-Servキューのサービスレートを(45%、35%、20%)に(45%、35%、20%)に構成することができます。それぞれ。管理者は、「サービスのクラス」ごとにトラフィックを個別のトラフィックトランクに分割し、それらのトラフィックトランクを輸送する各LSPに帯域幅を関連付けます。また、ネットワーク管理者は、各LSPの先制優先度を構成して、最高の優先度の「サービスのクラス」と媒体の優先順位をメディア「クラスのサービス」に設定することもできます。その後、DS-TEは、失敗後、「サービスのクラス」1トラフィックがリンク帯域幅の45%のサービスレートを超えることなく、リンク容量での最初のアクセスで再ルーティングされることを保証できます。「サービスのクラス」2トラフィックは、割り当てを超えることなく、リンク容量で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ソリューションのオプションの追加要件です。

2.3. Scenario 3: Guaranteed Bandwidth Services
2.3. シナリオ3:保証された帯域幅サービス

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.

Best Effect Serviceに加えて、IP/MPLSネットワークオペレーターは、プロバイダーが特定のレベルのパフォーマンスを提供することを誓約するポイントツーポイントの「保証帯域幅」サービスを提供したい場合があります(帯域幅/遅延/損失...)イングレスポートから出口ポートまでのネットワークを介してエンドツーエンド。目標は、サブスクライブされたサービスレベルの仕様の範囲に基づくすべての「保証された」トラフィックが、このサービスレベルの仕様の許容範囲内で配信されることを保証することです。

One approach for deploying such "guaranteed" service involves:

このような「保証された」サービスを展開するための1つのアプローチには、次のものが含まれます。

- 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

- diff-serv phb(または[diff-new]で定義されているdiff-serv psc)を「保証された」トラフィックに捧げる - ポリシングトラフィック契約に対するイングレスの保証されたトラフィックと、対応するDSCP/で「保証された」パケットをマークする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.

ただし、ネットワークオペレーターは、制約ベースのルーティングが異なる帯域幅の制約を実施することもできます。保証されたトラフィックのためのもの。

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メカニズムが必要です。

3. Detailed Requirements for DS-TE
3. 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ソリューションから必要とする機能を指定します。このような機能を達成するための実際の技術的プロトコルメカニズムと手順は、このドキュメントの範囲外です。

3.1. DS-TE Compatibility
3.1. 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が既存のTEメカニズムと組み合わされた場合に使用されると予想されます。セクション2で説明したシナリオのように、異なる「サービスのクラス」にさまざまな帯域幅の制約を実施する必要がある場所)。DSTEの利点がネットワークのトポロジーサブセットでのみ必要とされる場合、一部のネットワークオペレーターは、このトポロジーサブセットにDS-TEのみを展開することを望む場合があります。

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)

(i) 既存の展開されたTEメカニズムに関する相互運用性の問題は発生しません。(ii)必要なレベルの粒度と範囲へのDS-TEの展開を許可します(たとえば、トポロジのサブセットでのみ、または考慮されたネットワークで必要なクラスの数のみ)

3.2. Class-Types
3.2. クラスタイプ

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.

[TEWG-FW]は、Diff-Serv環境でのMPLSトラフィックエンジニアリングの操作について議論する際に、クラスタイプの概念を紹介します。

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.

クラスタイプ(CT):リンクを横切るトラフィックトランクのセットは、帯域幅の制約の特定のセットによって支配されます。CTは、リンク帯域幅の割り当て、制約ベースのルーティング、および入場制御の目的に使用されます。特定のトラフィックトランクは、すべてのリンクで同じCTに属します。

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.

同じCTからトラフィックトランクを輸送するさまざまなLSPが、以下のセクション3.4で説明するように、同じまたは異なる先制優先順位を使用している可能性があることに注意してください。

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にマッピングでき、1つの{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:

イラストの目的のために、EF PHB [EF]、AF1X PSC [AF]、AF2X PSC、およびデフォルト(つまり、ベストエフェクト)PHBに基づいて、それぞれ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.

o すべてのDS-TEヘッドエンドからすべてのDS-TEテールエンドまで、トラフィックを4つのトラフィックトランクに分割します。1つは{ta} psc oのトラフィック用です。類似の性質の(たとえば、おそらく異なるレベルでは低い損失をターゲットにしている)、同じ(Set of)帯域幅の制約は、AF1XトラフィックトランクとAF2Xトラフィックトランクに集合的に適用される場合があります。したがって、ネットワーク管理者は3つのCTのみを定義できます。1つはEFトラフィックトランク用、もう1つはAF1XおよびAF2Xトラフィックトランク用、もう1つは最良のトラフィックトランクです。

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).

{ta} PSCのCTSへのマッピングの別の例として、ネットワークオペレーターは、EFに関連付けられたトラフィックからトラフィックを2つの異なるトラフィックトランクに分割するため、トラフィックトランクの各セットが異なる制約の対象となるようにすることができます。アクセスできる帯域幅。この場合、EF {TA} PSCトラフィックに対して2つの異なるCTが定義されています。1つは最初の(セットの)帯域幅の制約の対象となるトラフィックサブセットの場合は、もう1つは2番目の対象となるトラフィックサブセットの場合(セットのセット)帯域幅の制約。

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つのCTSをサポートする必要があります。これらはCTC、0 <= c <= maxct-1 = 7と呼ばれます。DS-TEソリューションは、各CTの異なる帯域幅の制約を強制できる必要があります。DSTEの実装は、少なくとも2つのCTSをサポートする必要があり、最大8つのCTSをサポートする必要があります。

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ソリューションでは、ネットワーク管理者が常に最大数のCTSを展開するように要求してはなりません。DS-TEソリューションでは、ネットワーク管理者が実際に使用されるCTSの数のみを展開できるようにする必要があります。

3.3. Bandwidth Constraints
3.3. 帯域幅の制約

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.

- 帯域幅の制約の最大数。および - 各帯域幅の制約がどのように適用されるか、どのように適用されますか。

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
        

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)」をCTCに属するすべての確立されたLSPによって予約された帯域幅の合計として定義します。

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

- maxbc = maxct -範囲のbの各値について0 <= b <=(maxct -1):予約(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)以下を使用します - CT1からのトラフィックトランクをサポートするすべてのLSPは50(例えば、プレミアムデータ<= 50)を使用します - CT0からのトラフィックトランクをサポートするすべてのLSP20を超えない(例えば、最高の努力<= 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)

- maxbc = maxct -範囲内のbの各値について0 <= b <=(maxct -1):sum(reserved(ctc))<= bcb、範囲のすべての「c」<= 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つのCTを使用する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).

- CT2からのトラフィックトランクをサポートするすべてのLSPは60以下(音声<= 60)以下を使用します - CT1またはCT2からのトラフィックトランクをサポートするすべてのLSPは80(例:音声プレミアムデータ<= 80)を使用します - トラフィックをサポートするすべてのLSPCT0または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のサポートを許可する必要があります。

3.4. Preemption and TE-Classes
3.4. プリエンプションとTEクラス

[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の優先度が高い場合(つまり、数値優先度が低い)場合、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.

TE-Class:(i)クラスタイプ(ii)そのクラスタイプに許可される先制の優先度。これは、そのクラスタイプからトラフィックトランクを輸送するLSPが、その先制の優先順位を、保持優先度またはその両方として、セットアップの優先度として使用できることを意味します。

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.

- 特定のクラスタイプの場合、そのクラスタイプを使用して1つまたは複数のTEクラスがあり、それぞれが異なる先制優先度を使用して - 特定の先制優先度については、その先制を使用して1つまたは複数のTEクラス(ES)がある場合があります。優先度、それぞれが異なるクラスタイプを使用しています。

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ソリューションは、ネットワーク管理者が、Preemption 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ソリューションでは、同じクラスタイプのトラフィックトランクを輸送する2つのLSPが異なる先制優先順位を使用することを許可し、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ソリューションは、ネットワーク管理者が3つのTEクラスを含むクラス型を定義できるようにする必要があります。1つは先制0を使用し、1つはプリエンプション1を使用し、もう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がリソースを争うときに優先度が低いものを先取りすることを許可する必要があります。

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)を定義できるようにする必要があります。

-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

-1つのTEクラスグループCT0およびプリエンプション0 -1つのTEクラスグループCT0およびプリエンプション2 -ONE TEクラスグループCT1およびプリエンプション1 -ONE TEクラスグループCT1およびPreemption 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.

- セットアップの優先度= 0でLSPにCT0トラフィックトランクを輸送し、優先度を保持します= 0-セットアップ優先度= 2を保持しているLSPでCT0トラフィックトランクを輸送し、優先順位を保持します。1および優先度を保持= 1-セットアップ優先度= 3を使用してLSPを介してCT1トラフィックトランクを輸送し、優先度= 1を保持します。

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でLSPでCT0トラフィックトランクを輸送し、優先度を保持します= 1 -CT1トラフィックトランクをセットアップ優先度= 0でLSPに輸送し、優先度= 0を保持します

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ソリューションは、異なるCTSを使用して同じ先制優先度を使用できるようにする必要があります。これにより、ネットワーク管理者は、必要に応じてクラスタイプ全体でプリエンプションが発生しないようにすることができます。

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を使用する1つのTEクラスを構成します。その場合、プリエンプションは発生しません。

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ソリューションは、これらのTEクラスが(8)クラスタイプと(8)プリエンプション優先順位の可能な組み合わせから8(64)の可能な組み合わせから任意の任意のサブセットを含むことを許可する必要があります。

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の制約のリラックス、またはその他の動作に対する定期的な試みが含まれる場合があります。

3.5. Mapping of Traffic to LSPs
3.5. 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>).

DS-TEソリューションは、特定のFECの複数の<FEC/{TA} PSC>を介してE-LSPを介して動作する場合があります。これは、それらの複数の<FEC/{TA} PSC>がDSによって効果的に処理できる条件下で-te単一の原子トラフィックトランクとして(特にこれは、それらの複数の<fec/{ta} psc>が全体として、単一の集合帯域幅要件、単一の親和性属性、単一のプリエンプションレベル、単一のクラスに基づいてルーティングされることを意味します。-Typeなど)。その場合、複数の{ta} PSCは、DS-TEドメイン全体で一貫した方法でグループ化されていると想定されています(例:<fecx/{ta} psc1>および<fecx/{ta} psc2>の場合e-lspで一緒に輸送されると、l-lsp輸送<fecy/{ta} psc1>または<fecy/{ta} psc2>はそれ自体で輸送されず、e-lsp輸送はありません<fecz/{ta} psc1>および/または<fecz/{ta} psc2> with <fecz/{ta} psc3>)。

3.6. Dynamic Adjustment of Diff-Serv PHBs
3.6. DIF-Serv PHBの動的調整

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の量に基づいて、DIF-Serv PHBSパラメーター(例:キュー帯域幅)の調整をサポートする場合があります。このような動的調整は、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で一緒に輸送される場合、複数のOASにスケジューリングリソース(サービスレートなど)をどのように配分する必要があるかを制御する構成可能なパラメーターが含まれます。

Where supported, the dynamic adjustment MUST take account of the performance requirements of each PDB when computing required adjustments.

サポートされている場合、動的調整は、必要な調整を計算するときに各PDBのパフォーマンス要件を考慮する必要があります。

3.7. Overbooking
3.7. オーバーブッキング

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帯域幅のサイジング時および/またはリンク上の最大予約可能帯域幅を構成した時点で、オーバーブッキング比率を考慮して展開で達成されてきました。

The DS-TE solution MUST also allow overbooking and MUST effectively allow different overbooking ratios to be enforced for different CTs.

DS-TEソリューションは、オーバーブッキングも許可する必要があり、異なるCTSに対して異なるオーバーブッキング比を効果的に実施する必要があります。

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の有効オーバーブッキング比をネットワークのさまざまな部分で異なる方法で調整できるようにする必要があります。

3.8. Restoration
3.8. 復元

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]の出力文書に記載されています。

4. Solution Evaluation Criteria
4. ソリューション評価基準

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ソリューションを評価するために使用する必要がある評価基準を特定します。

4.1. Satisfying detailed requirements
4.1. 満足のいく詳細な要件

The solution MUST address all the scenarios described in section 2 and satisfy all the requirements listed in section 3.

ソリューションは、セクション2で説明されているすべてのシナリオに対処し、セクション3にリストされているすべての要件を満たす必要があります。

4.2. Flexibility
4.2. 柔軟性

- number of Class-Types that can be supported, compared to number identified in Requirements section - number of PDBs within a Class-Type

- 要件セクションで識別された数と比較して、クラスタイプ内のPDBの数と比較して、サポートできるクラスタイプの数

4.3. Extendibility
4.3. 拡張性

- how far can the solution be extended in the future if requirements for more Class-Types are identified in the future.

- 将来、より多くのクラスタイプの要件が特定された場合、将来どの程度拡張できますか。

4.4. Scalability
4.4. スケーラビリティ

- 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を許可することができます。

4.5. Backward compatibility/Migration
4.5. 後方互換性/移行

- 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メカニズムとの/からの後方互換性/移行 - 特定のネットワークで実際に展開されているクラスタイプの数を増や/減少させるときの後方互換性/移行。

4.6. Bandwidth Constraints Model
4.6. 帯域幅の制約モデル

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.

(1) セクション2(2)のシナリオのアドレスは、通常と過負荷条件の両方でうまく機能します(3)は、プリエンプションが有効または無効化されている場合に等しく適用されます(4)シグナリング負荷処理要件を最小化する(5)ネットワークの効率的な使用を最大化する(6)最小化実装と展開の複雑さ。

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の量を確立しようとしていることを意味します。「過負荷状態」とは、ネットワークが設計されたものを超えてDS-TE LSPの量を確立しようとしていることを意味します。「うまく機能する」とは、これらの条件下では、ネットワークが予想されるパフォーマンスを維持できるはずです。

5. Security Considerations
5. セキュリティに関する考慮事項

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ソリューションのプロトコル/手順拡張によって損なわれないようにするか、これに対処するためのセキュリティメカニズムを提供する必要があることを確認する必要があります。

6. Acknowledgment
6. 了承

We thank David Allen for his help in aligning with up-to-date Diff-Serv terminology.

David Allenが最新のDiff-Servの用語と協力してくれた彼の助けに感謝します。

7. Normative References
7. 引用文献

[AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.

[AF] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Rosen、E.、Viswanathan、A。and R. Callon、「Multiprotocol Label Switching Architecture」、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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。and J. Heinanen、 "Multi-Protocol Label差別化されたサービスの切り替え(MPLS)サポート」、RFC 3270、2002年5月。

[DIFF-NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.

[Diff-New] Grossman、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] Davie、B.、Charny、A.、Bennet、J.C.R.、Benson、K.、Le Boudec、J.Y.、Davari、S.、Courtney、W.、Firioiu、V。and D. Stiliadis」PHB(PER-HOP行動)」、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.、Chiu、A.、Elwalid、A.、Widjaja、I。、and X. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、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.、Malcolm、J.、Agogbua、J.、O'Dell、M.、J。McManus、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

8. Informative References
8. 参考引用

[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] Nichols、K。およびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、RFC 3086、2001年4月。

[ISIS-TE] Smit, Li, "IS-IS extensions for Traffic Engineering", Work in Progress, December 2002.

[ISIS-TE] Smit、Li、「IS-IS Traffic Engineering for Traffic Engineering」、2002年12月、進行中の作業。

[OSPF-TE] Katz, et al., "Traffic Engineering Extensions to OSPF", Work in Progress, October 2002.

[OSPF-TE] Katz、et al。、「Traffic Engineering Extensions to 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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE:LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。

[SURVIV-REQ] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.

[Surviv-req] Lai、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] Lai、W。、「Diffserv-Aware MPLSトラフィックエンジニアリングの帯域幅制約モデル:パフォーマンス評価」、2002年6月、Work in Progress。

[BC-CONS] F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress, June 2002.

[BC-Cons] F. Le 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] Ash、J。、「MPLS/DIFFSERV TE&Performance比較の予約帯域幅制約モデルを備えた最大割り当て」、2003年5月、進行中の作業。

9. Contributing Authors
9. 貢献している著者

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
        
   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
        
   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
      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
        
   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
        

Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9, Phone: (613) 765-2252 EMail: dareks@nortelnetworks.com

Darek Skalecki Nortel Networks 3500 Carling Ave、Nepean K2H 8e9、電話:(613)765-2252メール:dareks@nortelnetworks.com

10. Editors' Addresses
10. 編集者のアドレス

Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis, France

Francois Le Faucheur Cisco Systems、Inc。Village D'Entreprise Green Side -Batiment T3 400、Avenue de Roumanille 06410 Biot -Sophia Antipolis、フランス

   Phone: +33 4 97 23 26 19
   EMail: flefauch@cisco.com
        

Wai Sum Lai AT&T Labs 200 Laurel Avenue Middletown, New Jersey 07748, USA

Wai Sum Lai AT&T Labs 200 Laurel Avenue Middletown、ニュージャージー07748、米国

Phone: (732) 420-3712 EMail: wlai@att.com

電話:(732)420-3712メール:wlai@att.com

11. 完全な著作権声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。