Network Working Group                                     F. Le Faucheur
Request for Comments: 4125                           Cisco Systems, Inc.
Category: Experimental                                            W. Lai
                                                               AT&T Labs
                                                               June 2005
         Maximum Allocation Bandwidth Constraints Model for
                Diffserv-aware MPLS Traffic Engineering

Status of This Memo


This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2005).




This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model.


Table of Contents


   1. Introduction ....................................................2
      1.1. Specification of Requirements ..............................2
   2. Definitions .....................................................2
   3. Maximum Allocation Model Definition .............................3
   4. Example Formulas for Computing "Unreserved TE-Class [i]" with
      Maximum Allocation Model.........................................6
   5. Security Considerations .........................................7
   6. IANA Considerations .............................................7
   7. Acknowledgements ................................................7
   Appendix A: Addressing [DSTE-REQ] Scenarios.........................8
   Normative References...............................................10
   Informative References.............................................10
1. Introduction
1. はじめに

[DSTE-REQ] presents the Service Providers requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes the fundamental requirement to be able to enforce different Bandwidth Constraints for different classes of traffic.

[DSTE - REQ]のDiffservを意識したMPLSトラフィックエンジニアリング(DSTE)をサポートするためのサービスプロバイダの要件を提示します。これは、トラフィックの異なるクラスに対して異なる帯域幅の制約を強制することができるように基本的な要件が含まれています。

[DSTE-REQ] also defines the concept of Bandwidth Constraints Model for DS-TE and states that "The DS-TE technical solution MUST specify at least one Bandwidth Constraints Model and MAY specify multiple Bandwidth Constraints Models."


This document provides a detailed description of one particular Bandwidth Constraints Model for DS-TE, which is introduced in [DSTE-REQ] and called the Maximum Allocation Model (MAM).


[DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for support of DS-TE. These extensions support MAM.

[DSTE - プロト]はIGPとRSVP-TEはDSTEのサポートのための拡張シグナリング指定します。これらの拡張機能は、MAMをサポートしています。

1.1. Specification of Requirements
1.1. 要件の仕様

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2. Definitions

For readability, a number of definitions from [DSTE-REQ] are repeated here:

読みやすくするために、[DSTE - REQ]からの定義の数は、ここでは繰り返されています。

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に属します。

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.


A number of recovery mechanisms, under investigation or specification in the IETF, take advantage of the concept of bandwidth sharing across particular sets of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based Computation Model" in [MPLS-BACKUP] are example mechanisms that increase bandwidth efficiency by sharing bandwidth across backup LSPs protecting against independent failures. To ensure that the notion of "Reserved (CTc)" introduced in [DSTE-REQ] is compatible with such a concept of bandwidth sharing across multiple LSPs, the wording of the "Reserved (CTc)" definition provided in [DSTE-REQ] is generalized into the following:

回復メカニズムの数は、IETFでの調査や仕様の下で、LSPの特定のセットの間の帯域幅の共有の概念を活用します。 [GMPLS-RECOV]で「共有メッシュ修復」と[MPLS-BACKUP]中の「施設ベースの計算モデルは、」独立障害に対する保護のバックアップLSPを横切って帯域幅を共有することによって帯域幅効率を高める例示的機構です。概念「予約(CTC)は、」[DSTE-REQ]で導入されていることを保証するためには、「予約(CTC)」の文言が定義内に設けられた複数のLSPを横切って帯域幅共有のような概念と互換性がある[DSTE-REQ]以下に一般化されます。

Reserved (CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ), let us define "Reserved(CTc)" as the total amount of the bandwidth reserved by all the established LSPs which belong to CTc.

予約(CTC):指定されたクラス型CTC(0 <= C <= MaxCT)のために、私たちはCTCに属するすべての確立のLSPによって予約された帯域幅の合計量として「予約(CTC)」を定義してみましょう。

With this generalization, the Maximum Allocation Model definition provided in this document is compatible with Shared Mesh Restoration defined in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate simultaneously. This assumes that Shared Mesh Restoration operates independently within each DS-TE Class-Type and does not operate across Class-Types (for example, backup LSPs protecting Primary LSPs of CTx also need to belong to CTx; Excess Traffic LSPs sharing bandwidth with Backup LSPs of CTx also need to belong to CTx).


We also introduce the following definition:


Reserved(CTb,q): Let us define "Reserved(CTb,q)" as the total amount of the bandwidth reserved by all the established LSPs that belong to CTb and have a holding priority of q. Note that if q and CTb do not form one of the 8 possible configured TE-Classes, then there cannot be any established LSPs that belongs to CTb and has a holding priority of q; therefore, in this case, Reserved(CTb,q) = 0.

(CTB、Q)予約:私たちはCTbをに属しているとqの保持優先度を持つすべての確立のLSPによって予約された帯域幅の合計量として「予約(CTB、q)を」定義しよう。 qおよびCTbを8可能に構成TE-クラスのいずれかを形成しない場合、CTbをに属し、Qの保持優先度を有する任意の確立したLSPが存在しないことに注意してください。従って、この場合、リザーブ(CTB、Q)= 0。

3. Maximum Allocation Model Definition

MAM is defined in the following manner:


        o Maximum Number of Bandwidth Constraints (MaxBC) =
             Maximum Number of Class-Types (MaxCT) = 8

o for each value of c in the range 0 <= c <= (MaxCT - 1): Reserved (CTc) <= BCc <= Max-Reservable-Bandwidth,

O範囲0 <= C <=(MaxCT - 1)におけるcの値ごとに:予約(CTC)<= BCC <=最大予約可能帯域幅、

o SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)

入出力SUM(予約(CTC))<= SUM範囲におけるcの全ての値を横切っている最大予約可能帯域幅0 <= C <=(MaxCT - 1)

A DS-TE LSR implementing MAM MUST support enforcement of Bandwidth Constraints in compliance with this definition.

MAMを実装DS-TE LSRは、この定義に準拠した帯域幅の制約の施行をサポートしなければなりません。

To increase the degree of bandwidth sharing among the different CTs, the sum of Bandwidth Constraints may exceed the Maximum Reservable Bandwidth, so that the following relationship may hold true:


         o SUM (BCc) > Max-Reservable-Bandwidth,
              where the SUM is across all values of c in the range
              0 <= c <= (MaxCT - 1)

The sum of Bandwidth Constraints may also be equal to (or below) the Maximum Reservable Bandwidth. In that case, the Maximum Reservable Bandwidth does not actually constrain CT bandwidth reservations (in other words, the 3rd bullet item of the MAM definition above will never effectively come into play). This is because the 2nd bullet item of the MAM definition above implies that:


SUM (reserved(CTc)) <= SUM (BCc)


and we assume here that


SUM (BCc) <= Maximum Reservable Bandwidth.


Therefore, it will always be true that:


SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth.


Both preemption within a CT and across CTs is allowed.


Where 8 CTs are active, the MAM Bandwidth Constraints can also be expressed in the following way:


- All LSPs from CT7 use no more than BC7

- CT7からのすべてのLSPはBC7以下で使用しません

- All LSPs from CT6 use no more than BC6

- CT6からのすべてのLSPはBC6以下で使用しません

- All LSPs from CT5 use no more than BC5

- CT5からのすべてのLSPはBC5以下で使用しません

- etc.

- など

- All LSPs from CT0 use no more than BC0

- CT0からのすべてのLSPはBC0以下で使用しません

- All LSPs from all CTs collectively use no more than the Maximum Reservable Bandwidth

- すべてのCTからのすべてのLSPは、総称して、最大予約可能帯域幅よりも多くを使用していません

Purely for illustration purposes, the diagram below represents MAM in a pictorial manner when 3 CTs are active:


        <---BC0--->                  I
        I---------I                  I
        I         I                  I
        I   CT0   I                  I
        I         I                  I
        I---------I                  I
        I                            I
        I                            I
        <-------BC1------->          I
        I-----------------I          I
        I                 I          I
        I       CT1       I          I
        I                 I          I
        I-----------------I          I
        I                            I
        I                            I
        <-----BC2----->              I
        I-------------I              I
        I             I              I
        I     CT2     I              I
        I             I              I
        I-------------I              I
        I                            I
        I        CT0+CT1+CT2         I
        I                            I

<--Max Reservable Bandwidth-->

< - 最大予約可能帯域幅 - >

(Note that, in this illustration, the sum BC0 + BC1 + BC2 exceeds the Max Reservable Bandwidth.)

(なお、この図では、和BC0 + 1 BC1 + BC2は、最大予約可能帯域幅を超えています。)

While more flexible/sophisticated Bandwidth Constraints Models can be defined (and are indeed defined; see [DSTE-RDM]), the Maximum Allocation Model is attractive in some DS-TE environments for the following reasons:


- Network administrators generally find MAM simple and intuitive

- ネットワーク管理者は、一般的にMAMは、シンプルで直感的な発見します

- MAM matches simple bandwidth control policies that Network Administrators may want to enforce, such as setting an individual Bandwidth Constraint for a given type of traffic (a.k.a. Class-Type) and simultaneously limit the aggregate of reserved bandwidth across all types of traffic.

- MAMは、このようなトラフィックの特定のタイプ(別称、クラス型)のために、個々の帯域幅の制約を設定すると同時に、すべてのタイプのトラフィック全体で確保された帯域幅の集約を制限するなどのネットワーク管理者は、強制することがあり、単純な帯域制御ポリシーを、一致しました。

- MAM can be used in a way which ensures isolation across Class-Types, whether preemption is used or not.

- MAMは、プリエンプションが使用されているか否かを、クラスタイプ間の分離を確実にするように使用することができます。

- MAM can simultaneously achieve isolation, bandwidth efficiency, and protection against QoS degradation of the premium CT.

- MAMは同時に分離、帯域幅の効率化、およびプレミアムCTのQoSの劣化に対する保護を達成することができます。

- MAM only requires limited protocol extensions such as the ones defined in [DSTE-PROTO].

- MAMのみような[DSTE - プロト]で定義されるものと限定されたプロトコルの拡張を必要とします。

MAM may not be attractive in some DS-TE environments because:


- MAM cannot simultaneously achieve isolation, bandwidth efficiency, and protection against QoS degradation of CTs other than the Premium CT.

- MAMは同時に分離、帯域幅の効率化、およびプレミアムCT以外のCTSのQoS劣化に対する保護を達成することはできません。

Additional considerations on the properties of MAM, and its comparison with RDM, can be found in [BC-CONS] and [BC-MODEL].


As a very simple example of usage of MAM, a network administrator using one CT for Voice (CT1) and one CT for Data (CT0) might configure on a given 2.5 Gb/s link:

MAM、1ボイスのCT(CT1)とデータ用CT(CT0)が与えられた2.5 Gb /秒のリンクを設定する可能性があるものを使用して、ネットワーク管理者の使用の非常に簡単な例として:

- BC0 = 2 Gb/s (i.e., Data is limited to 2 Gb/s)

- BC0 = 2 Gb /秒(すなわち、データは、2 Gb /秒に制限されています)

- BC1 = 1 Gb/s (i.e., Voice is limited to 1 Gb/s)

- BC1 = 1 Gb /秒(すなわち、音声が1 Gb /秒に制限されています)

- Maximum Reservable Bandwidth = 2.5 Gb/s (i.e., aggregate Data + Voice is limited to 2.5 Gb/s)

- 最大予約可能帯域幅= 2.5ギガビット/秒(すなわち、集約データ+ボイス2.5 Gb /秒に制限されます)

4. Example Formulas for Computing "Unreserved TE-Class [i]" with Maximum Allocation Model


As specified in [DSTE-PROTO], formulas for computing "Unreserved TE-Class [i]" MUST reflect all of the Bandwidth Constraints relevant to the CT associated with TE-Class[i], and thus, depend on the Bandwidth Constraints Model. Thus, a DS-TE LSR implementing MAM MUST reflect the MAM Bandwidth Constraints defined in Section 3 when computing "Unreserved TE-Class [i]".

[DSTE - プロト]で指定されているように、計算するための式「非予約TEクラス[i]は」[i]のTE-クラスに関連付けられているCTに関連する帯域幅の制約のすべてを反映しなければなりませんし、したがって、帯域幅の制約モデルに依存します。したがって、DS-TE LSR実施MAM「は、未予約TEクラス[I]」を計算するときに、セクション3で定義されたMAMの帯域幅の制約を反映しなければなりません。

As explained in [DSTE-PROTO], the details of admission control algorithms, as well as formulas for computing "Unreserved TE-Class [i]", are outside the scope of the IETF work. Keeping that in mind, we provide in this section an example, for illustration purposes, of how values for the unreserved bandwidth for TE-Class[i] might be computed with MAM. In the example, we assume the use of the basic admission control algorithm, which simply deducts the exact bandwidth of any established LSP from all of the Bandwidth Constraints relevant to the CT associated with that LSP.

[DSTE - プロト]で説明したように、「未予約TEクラス[I]」を計算するためのアドミッション制御アルゴリズムの詳細、ならびに式は、IETF作業の範囲外です。心の中で、我々はTEクラス[i]のために予約されていない帯域幅の値がMAMで計算されるかもしれない方法で、例示の目的のために、このセクションの例を提供することを維持します。例では、我々は単にそのLSPに関連したCTに関連する帯域幅の制約の全てから任意の確立LSPの正確な帯域幅が差し引かれ、基本的なアドミッション制御アルゴリズムの使用を前提としています。



"Unreserved TE-Class [i]" =

"非予約TEクラス[i]を" =

MIN [ [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p , [ Max-Res-Bw - SUM (Reserved(CTb,q)) ] for q <= p and 0 <= b <= 7, ]

MIN [BCC - qに対してSUM(予約(CTC、Q))<= P、[マックス-RES-幅Bw - SUM qに対して((CTB、q)は予約済み)<= P 0 <= B <= 7、 ]

where: TE-Class [i] <--> < CTc , preemption p> in the configured TE-Class mapping.

ここで、TEクラス[I] < - > <CTC、プリエンプションP>構成TEクラスのマッピングです。

5. Security Considerations

Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints Model, including MAM specified in this document.

DSTEの使用に関連するセキュリティ上の考慮事項は、[DSTE - プロト]で議論されています。これらは、この文書で指定されたMAMを含む、帯域幅の制約モデルとは独立して適用されます。

6. IANA Considerations
6. IANAの考慮事項

[DSTE-PROTO] defines a new name space for "Bandwidth Constraints Model Id". The guidelines for allocation of values in that name space are detailed in section 13.1 of [DSTE-PROTO]. In accordance with these guidelines, IANA has assigned a Bandwidth Constraints Model Id for MAM from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).

[DSTE - プロト]は、「帯域幅の制約モデルID」の新しい名前空間を定義します。その名前空間内の値の割り当てのためのガイドラインは[DSTE - プロト]のセクション13.1に詳述されています。これらのガイドラインによれば、IANAは、([IANA-CONS]で定義された「仕様必須」ポリシーに従って管理される)範囲0から239からMAMの帯域幅制約モデルIDが割り当てられています。

Bandwidth Constraints Model Id 1 was allocated by IANA to MAM.


7. Acknowledgements

A lot of the material in this document has been derived from ongoing discussions within the TEWG work. This involved many people including Jerry Ash and Dimitry Haskin.

この文書に記載されている材料の多くはTEWG作業中、進行中の議論に由来しています。これは、ジェリー・アッシュとのDimitry Haskinを含む多くの人々が関与しました。

Appendix A: Addressing [DSTE-REQ] Scenarios

付録A:アドレッシング[DSTE - REQ]シナリオ

This Appendix provides examples of how the Maximum Allocation Bandwidth Constraints Model can be used to support each of the scenarios described in [DSTE-REQ].


A.1. Scenario 1: Limiting Amount of Voice


By configuring on every link:


- Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage" of link capacity

- リンク容量の帯域幅制約1(CT1 =ボイス用)=「一定の割合」

- Bandwidth Constraint 0 (for CT0 = Data) = link capacity (or a constraint specific to data traffic)

- 帯域幅制約0 =リンク容量(またはデータトラフィックに固有の制約)(CT0 =データ用)

- Max Reservable Bandwidth = link capacity

- 最大予約可能帯域幅=リンク容量

By configuring:


- every CT1/Voice TE-LSP with preemption = 0

- 先取り= 0を持つすべてのCT1 /音声TE-LSP

- every CT0/Data TE-LSP with preemption = 1

- 先取り= 1毎CT0 /データTE-LSP

DS-TE with the Maximum Allocation Model will address all the requirements:


- amount of Voice traffic limited to desired percentage on every link

- すべてのリンク上の所望の割合に制限され、音声トラフィックの量

- data traffic capable of using all remaining link capacity (or up to its own specific constraint)

- 残りのすべてのリンク容量を使用することが可能なデータトラフィック(またはその固有の制約まで)

- voice traffic capable of preempting other traffic

- 他のトラフィックを優先処理できる音声トラフィック

A.2. Scenario 2: Maintain Relative Proportion of Traffic Classes


By configuring on every link:


- BC2 (for CT2) = e.g., 45% of link capacity

- リンク容量のBC2(用CT2)=例えば、45%

- BC1 (for CT1) = e.g., 35% of link capacity

- リンク容量のBC1(用CT1)=例えば、35%

- BC0 (for CT0) = e.g., 100% of link capacity

- リンク容量のBC0(用CT0)=例えば、100%

- Max Reservable Bandwidth = link capacity

- 最大予約可能帯域幅=リンク容量

DS-TE with the Maximum Allocation Model will ensure that the amount of traffic of each CT established on a link is within acceptable levels as compared to the resources allocated to the corresponding Diffserv Per Hop Behaviors (PHBs) regardless of which order the LSPs are routed in, regardless of which preemption priorities are used by which LSPs and regardless of failure situations.


By also configuring:


- every CT2/Voice TE-LSP with preemption = 0

- 先取り= 0を持つすべてのCT2 /音声TE-LSP

- every CT1/Premium Data TE-LSP with preemption = 1

- 先取り= 1を持つすべてのCT1 /プレミアムデータTE-LSP

- every CT0/Best-Effort TE-LSP with preemption = 2

- 先取り= 2を持つすべてのCT0 /ベストエフォートTE-LSP

DS-TE with the Maximum Allocation Model will also ensure that:


- CT2 Voice LSPs always have first preemption priority in order to use the CT2 capacity

- CT2音声LSPは常にCT2の容量を使用するために、最初の先取り優先権を持っています

- CT1 Premium Data LSPs always have second preemption priority in order to use the CT1 capacity

- CT1プレミアムデータLSPは常にCT1の容量を使用するために、第2の先取り優先権を持っています

- Best-Effort can use up to link capacity of what is left by CT2 and CT1.

- ベストエフォートはCT2とCT1で残っているものの容量をリンクするまで使用できます。

Optional automatic adjustment of Diffserv scheduling configuration could be used for maintaining very strict relationships between the amounts of established traffic of each CT and corresponding Diffserv resources.


A.3. Scenario 3: Guaranteed Bandwidth Services


By configuring on every link:


- BC1 (for CT1) = "given" percentage of link bandwidth (appropriate to achieve the QoS objectives of the Guaranteed Bandwidth service)

- BC1(CT1用)=「与えられた」リンク帯域幅の割合(適切な保証帯域幅サービスのQoS目標を達成するために)

- BC0 (for CT0 = Data) = link capacity (or a constraint specific to data traffic)

- BC0(CT0 =データ用)=リンク容量(またはデータトラフィックに固有の制約)

- Max Reservable Bandwidth = link capacity

- 最大予約可能帯域幅=リンク容量

DS-TE with the Maximum Allocation Model will ensure that the amount of Guaranteed Bandwidth Traffic established on every link remains below the given percentage so that it will always meet its QoS objectives. At the same time, it will allow traffic engineering of the rest of the traffic such that links can be filled up (or limited to the specific constraint for such traffic).


Normative References


[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.

[DSTE - REQ]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのための要件"、RFC 3564、2003年7月。

[DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.

[DSTE - プロト]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張機能"、RFC 4124、2005年6月。

[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月。

[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[IANA-CONS] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。

Informative References


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

[BC-CONS]ルFaucheur、F.、 "DS-TEのための帯域幅制約モデルの検討"、進歩、2002年6月での作業。

[BC-MODEL] Lai, W., "Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation", RFC 4128, June 2005.

[BC-MODEL]ライ、W.、 "差別化サービス(DiffServ)のための帯域幅制約モデルの-aware MPLSトラフィックエンジニアリング:性能評価"、RFC 4128、2005年6月。

[DSTE-RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.

[DSTE - RDM]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのためのロシア人形の帯域幅制約モデル"、RFC 4127、2005年6月。

[GMPLS-RECOV] Lang, et al., "Generalized MPLS Recovery Functional Specification", Work in Progress.

[GMPLS-RECOV]ラングら、 "一般化MPLS回復機能的な仕様"、ProgressのWork。

[MPLS-BACKUP] Vasseur, et al., "MPLS Traffic Engineering Fast reroute: Bypass Tunnel Path Computation for Bandwidth Protection", Work in Progress.

[MPLS-BACKUP] Vasseurら、「MPLSトラフィックエンジニアリング高速リルート:帯域幅保護のためのバイパストンネル経路計算」が進行中で働いています。

Authors' Addresses


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:

電話:+33 4 97 23 26 19 Eメール

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:

電話:(732)420-3712 Eメール

Full Copyright Statement


Copyright (C) The Internet Society (2005).


This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。