Network Working Group                                  L. Berger, Editor
Request for Comments: 3471                                Movaz Networks
Category: Standards Track                                   January 2003
           Generalized Multi-Protocol Label Switching (GMPLS)
                    Signaling Functional Description

Status of this Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice


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




This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.

この文書では、マルチプロトコルラベルスイッチング(MPLS)一般MPLSをサポートするために必要なシグナルの拡張機能について説明します。一般MPLSは時分割(例えば、同期光ネットワークと同期デジタル・ハイアラーキ、SONET / SDH)、波長(光ラムダ)と空間スイッチング(出力ポートまたはファイバ例えば、着信ポートまたはファイバ)を包含するMPLSコントロールプレーンを拡張します。この文書では、拡張の機能説明を提示しています。プロトコル固有の形式とメカニズム、および技術の特定の詳細が別の文書で指定されています。

Table of Contents


   1.  Introduction  ...............................................   2
   2.  Overview   ..................................................   3
   3.  Label Related Formats   .....................................   6
     3.1  Generalized Label Request  ...............................   6
     3.2  Generalized Label  .......................................  11
     3.3  Waveband Switching  ......................................  12
     3.4  Suggested Label  .........................................  13
     3.5  Label Set  ...............................................  14
   4.  Bidirectional LSPs  .........................................  16
     4.1  Required Information  ....................................  17
     4.2  Contention Resolution  ...................................  17
   5.  Notification on Label Error  ................................  20
   6.  Explicit Label Control  .....................................  20
     6.1  Required Information  ....................................  21
   7.  Protection Information  .....................................  21
     7.1  Required Information  ....................................  22
   8.  Administrative Status Information  ..........................  23
     8.1  Required Information  ....................................  24
   9.  Control Channel Separation  .................................  25
     9.1  Interface Identification  ................................  25
     9.2  Fault Handling  ..........................................  27
   10. Acknowledgments  ............................................  27
   11. Security Considerations  ....................................  28
   12. IANA Considerations  ........................................  28
   13. Intellectual Property Considerations  .......................  29
   14. References  .................................................  29
     14.1  Normative References  ...................................  29
     14.2  Informative References  .................................  30
   15. Contributors  ...............................................  31
   16. Editor's Address  ...........................................  33
   17. Full Copyright Statement  ...................................  34
1. Introduction
1. はじめに

The Multiprotocol Label Switching (MPLS) architecture [RFC3031] has been defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing cell boundaries).


The original architecture has recently been extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, can't forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports.


Given the above, LSRs, or more precisely interfaces on LSRs, can be subdivided into the following classes:


1. Interfaces that recognize packet/cell boundaries and can forward data based on the content of the packet/cell header. Examples include interfaces on routers that forward data based on the content of the "shim" header, interfaces on (Asynchronous Transfer Mode) ATM-LSRs that forward data based on the ATM VPI/VCI. Such interfaces are referred to as Packet-Switch Capable (PSC).

パケット/セル境界を認識し、パケット/セル・ヘッダの内容に基づいてデータを転送することができる1.インターフェース。例としては、(非同期転送モード)の「シム」ヘッダ、インターフェイスATM VPI / VCIに基づいてデータを転送するATM-のLSRの内容に基づいてデータを転送するルータのインタフェースを含みます。そのようなインターフェースは、可能なパケット交換(PSC)と呼ばれます。

2. Interfaces that forward data based on the data's time slot in a repeating cycle. An example of such an interface is an interface on a SONET/SDH Cross-Connect. Such interfaces are referred to as Time-Division Multiplex Capable (TDM).

繰り返し周期内のデータのタイムスロットに基づいてデータを転送する2.インタフェース。そのようなインターフェイスの例は、SONET / SDHクロスコネクトのインターフェイスです。そのようなインタフェースは、可能な時分割多重(TDM)と呼ばれます。

3. Interfaces that forward data based on the wavelength on which the data is received. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of an individual wavelength. Such interfaces are referred to as Lambda Switch Capable (LSC).


4. Interfaces that forward data based on a position of the data in the real world physical spaces. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of a single (or multiple) fibers. Such interfaces are referred to as Fiber-Switch Capable (FSC).


Using the concept of nested Label Switched Paths (LSPs) allows the system to scale by building a forwarding hierarchy. At the top of this hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on an LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface. See [MPLS-HIERARCHY] for more information on LSP hierarchies.

ネストされたラベルの概念を使用すると、パス(LSPの)システムが転送階層を構築することで拡張することができますを交換しました。この階層の最上位にPSCインターフェース続いTDMインタフェース続いLSCインターフェース続くFSCインタフェースは、、、です。この方法は、PSCインタフェース上で開始し、終了するLSPが起動し、TDMインタフェースで終了LSPに(一緒に、他のLSPとの)ネストすることができます。このLSP、順番に、起動し、起動し、FSCインタフェースで終わるLSPに順番に(他のLSPと一緒に)入れ子にすることができるLSCインターフェースで終了LSPに(一緒に、他のLSPとの)入れ子にすることができ。 LSP階層の詳細については、[MPLS-HIERARCHY]を参照してください。

The establishment of LSPs that span only the first class of interfaces is defined in [RFC3036, RFC3212, RFC3209]. This document presents a functional description of the extensions needed to generalize the MPLS control plane to support each of the four classes of interfaces. Only signaling protocol independent formats and definitions are provided in this document. Protocol specific formats are defined in [RFC3473] and [RFC3472]. Technology specific details are outside the scope of this document and will be specified in technology specific documents, such as [GMPLS-SONET].


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

Generalized MPLS differs from traditional MPLS in that it supports multiple types of switching, i.e., the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional types of switching has driven generalized MPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties, how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress.


In traditional MPLS Traffic Engineering, links traversed by an LSP can include an intermix of links with heterogeneous label encodings. For example, an LSP may span links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the real world physical space. Just like with traditional MPLS TE, where not all LSRs are capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in their forwarding plane, generalized MPLS includes support for LSRs that can't recognize (IP) packet boundaries in their forwarding plane. In traditional MPLS TE an LSP that carries IP has to start and end on a router. Generalized MPLS extends this by requiring an LSP to start and end on similar type of LSRs. Also, in generalized MPLS the type of a payload that can be carried by an LSP is extended to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These changes from traditional MPLS are reflected in how labels are requested and communicated in generalized MPLS, see Sections 3.1 and 3.2. A special case of Lambda switching, called Waveband switching is also described in Section 3.3.

伝統的なMPLSトラフィックエンジニアリングでは、LSPが通過するリンクは、異種のラベルエンコーディングとのリンクの混在を含めることができます。例えば、LSPは、ルータ、ルータとATM-LSRの間のリンク、およびATM-LSRの間のリンク間のリンクをまたがってもよいです。一般MPLSラベルがタイムスロット、または波長、または現実世界の物理的な空間における位置としてエンコードされたリンクを含むことによって、これを拡張します。ただ、必ずしもすべてのLSRが自分のフォワーディングプレーンに(IP)パケット境界(例えば、ATM-LSR)を認識することができる伝統的なMPLS TE、と同じように、一般的なMPLSはに(IP)パケットの境界を認識することができないのLSRのサポートが含まれています彼らのフォワーディングプレーン。伝統的なMPLS TEでIPを運ぶLSPが起動し、ルータに終了する必要があります。一般MPLSは、開始とのLSRの同様の種類に終了するLSPを要求することによって、これを延びています。また、一般にMPLS LSPによって実施することができるペイロードのタイプは、SONET / SDH、または1または10 Gbイーサネットのようなペイロードを可能にするように拡張されます。伝統的なMPLSからのこれらの変更は、セクション3.1と3.2を参照して、ラベルが一般化MPLSに要求されたと伝えているどのように反映されています。波長群スイッチングと呼ばれるラムダスイッチングの特別な場合は、また、第3.3節に記載されています。

Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.3. There are also likely to be (much) fewer labels on non-PSC links than on PSC links. Note that the use of Forwarding Adjacencies (FA), see [MPLS-HIERARCHY], provides a mechanism that may improve bandwidth utilization, when bandwidth allocation can be performed only in discrete units, as well as a mechanism to aggregate forwarding state, thus allowing the number of required labels to be reduced.

一般のMPLS LSPの伝統的および非PSCタイプとの間の別の基本的な違いは、LSPの帯域幅割り当ては、セクション3.1.3を参照して、唯一の別個の単位で行うことができることです。また、PSCのリンクよりも非PSCリンク上(多くの)少数のラベルである可能性が高いがあります。 、帯域幅帯域幅割り当てだけ個別の単位で行うことができる利用、ならびに転送状態を集約するためのメカニズムを改善することができるメカニズムを提供し、従って可能にフォワーディング隣接関係の使用(FA)は、[MPLS階層]を参照のことに注意してください必要なラベルの数を減少させることができます。

Generalized MPLS allows for a label to be suggested by an upstream node, see Section 3.4. This suggestion may be overridden by a downstream node but, in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the norm) the MAPPING/Resv message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. The suggested label is also valuable when recovering from nodal faults.

一般化されたMPLSラベルが上流ノードによって示唆されるようにするために、3.4節を参照できます。この提案は、いくつかの場合において、より高いLSPセットアップ時間を犠牲にして、下流のノードによってオーバーライドなくてもよいです。スイッチングファブリックの設定で(電気換算)長い遅延が存在し得る光学機器の特定の種類を介してLSPを確立する際に提案ラベルは価値があります。例えば、マイクロミラーが上昇又は移動させる必要があり、この物理的運動とその後の減衰時間がかかります。ラベルひいてはスイッチングファブリックが逆方向(ノルム)で構成されている場合MAPPING / Resvメッセージには、使用可能な転送パスを確立するためにホップ毎ミリ秒10件のだけ遅延される必要があるかもしれません。リンパ節の障害からの回復時に提案されたラベルにも貴重なものです。

Generalized MPLS extends on the notion of restricting the range of labels that may be selected by a downstream node, see Section 3.5. In generalized MPLS, an ingress or other upstream node may restrict the labels that may be used by an LSP along either a single hop or along the whole LSP path. This feature is driven from the optical domain where there are cases where wavelengths used by the path must be restricted either to a small subset of possible wavelengths, or to one specific wavelength. This requirement occurs because some equipment may only be able to generate a small set of the wavelengths that intermediate equipment may be able to switch, or because intermediate equipment may not be able to switch a wavelength at all, being only able to redirect it to a different fiber.


While traditional traffic engineered MPLS (and even LDP) are unidirectional, generalized MPLS supports the establishment of bidirectional LSPs, see Section 4. The need for bidirectional LSPs comes from non-PSC applications. There are multiple reasons why such LSPs are needed, particularly possible resource contention when allocating reciprocal LSPs via separate signaling sessions, and simplifying failure restoration procedures in the non-PSC case. Bidirectional LSPs also have the benefit of lower setup latency and lower number of messages required during setup.


Generalized MPLS supports the communication of a specific label to use on a specific interface, see Section 6. [RFC3473] also supports an RSVP specific mechanism for rapid failure notification.

一般MPLSは、特定のインターフェイスで使用する特定のラベルの通信をサポートし、第6 [RFC3473]は、迅速な障害通知のためのRSVP特定のメカニズムをサポート参照します。

Generalized MPLS formalizes possible separation of control and data channels, see Section 9. Such support is particularly important to support technologies where control traffic cannot be sent in-band with the data traffic.


Generalized MPLS also allows for the inclusion of technology specific parameters in signaling. The intent is for all technology specific parameters to be carried, when using RSVP, in the SENDER_TSPEC and other related objects, and when using CR-LDP, in the Traffic Parameters TLV. Technology specific formats will be defined on an as needed basis. For an example definition, see [GMPLS-SONET].

一般MPLSはまた、シグナリングにおける技術の特定のパラメータを含めることが可能になります。 SENDER_TSPECおよび他の関連するオブジェクトに、RSVPを使用する場合、およびCR-LDPを使用する場合、すべての技術の特定のパラメータがトラフィックパラメータTLVで、実施するために意図されます。テクノロジー固有の形式は、のように必要に応じて定義されます。例えば、定義については、[GMPLS-SONET]を参照。

3. Label Related Formats

To deal with the widening scope of MPLS into the optical and time domain, several new forms of "label" are required. These new forms of label are collectively referred to as a "generalized label". A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. This section defines a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.


Note that since the nodes sending and receiving the new form of label know what kinds of link they are using, the generalized label does not contain a type field, instead the nodes are expected to know from context what type of label to expect.


3.1. Generalized Label Request
3.1. 一般ラベル要求

The Generalized Label Request supports communication of characteristics required to support the LSP being requested. These characteristics include LSP encoding and LSP payload. Note that these characteristics may be used by transit nodes, e.g., to support penultimate hop popping.


The Generalized Label Request carries an LSP encoding parameter, called LSP Encoding Type. This parameter indicates the encoding type, e.g., SONET/SDH/GigE etc., that will be used with the data associated with the LSP. The LSP Encoding Type represents the nature of the LSP, and not the nature of the links that the LSP traverses. A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats depending on the resource availability and capacity of the link. For example, consider an LSP signaled with "lambda" encoding. It is expected that such an LSP would be supported with no electrical conversion and no knowledge of the modulation and speed by the transit nodes. Other formats normally require framing knowledge, and field parameters are broken into the framing type and speed as shown below.

一般ラベル要求は、LSPのエンコードタイプと呼ばれるLSPのエンコーディングパラメータを、運びます。このパラメータは、LSPに関連するデータと共に使用される符号化の種類、例えば、SONET / SDH /ギガビットイーサネットなどを示します。 LSPエンコードタイプはLSPの性質ではなく、LSPが横断リンクの性質を表しています。リンクは、支持リンクは、リンクのリソース可用性と容量に応じて、これらの符号化フォーマットのうちの1つまたは複数の信号を搬送し、切り替えることができることを意味する符号化フォーマットのセットをサポートすることができます。たとえば、「ラムダ」エンコーディングで合図LSPを検討してください。このようなLSPがない電気変換及びトランジットノードによって変調速度の知識を用いてサポートされることが予想されます。他の形式は、通常、フレーミング知識を必要とし、以下に示すように、フィールドパラメータは、フレーミングタイプと速度に分割されます。

The Generalized Label Request also indicates the type of switching that is being requested on a link. This field normally is consistent across all links of an LSP.


3.1.1. Required Information
3.1.1. 必要な情報

The information carried in a Generalized Label Request is:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   | LSP Enc. Type |Switching Type |             G-PID             |

LSP Encoding Type: 8 bits


Indicates the encoding of the LSP being requested. The following shows permitted values and their meaning:


   Value       Type
   -----       ----
     1         Packet
     2         Ethernet
     3         ANSI/ETSI PDH
     4         Reserved
     5         SDH ITU-T G.707 / SONET ANSI T1.105
     6         Reserved
     7         Digital Wrapper
     8         Lambda (photonic)
     9         Fiber
    10         Reserved
    11         FiberChannel
         The ANSI PDH and ETSI PDH types designate these respective
         networking technologies.  DS1 and DS3 are examples of ANSI PDH
         LSPs.  An E1 LSP would be ETSI PDH.  The Lambda encoding type
         refers to an LSP that encompasses a whole wavelengths.  The
         Fiber encoding type refers to an LSP that encompasses a whole
         fiber port.

Switching Type: 8 bits


Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. This field should map to one of the values advertised for the corresponding link in the routing Switching Capability Descriptor, see [GMPLS-RTG].


The following are currently defined values:


   Value       Type
   -----       ----
     1         Packet-Switch Capable-1 (PSC-1)
     2         Packet-Switch Capable-2 (PSC-2)
     3         Packet-Switch Capable-3 (PSC-3)
     4         Packet-Switch Capable-4 (PSC-4)
     51        Layer-2 Switch Capable  (L2SC)
     100       Time-Division-Multiplex Capable (TDM)
     150       Lambda-Switch Capable   (LSC)
     200       Fiber-Switch Capable    (FSC)

Generalized PID (G-PID): 16 bits


An identifier of the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This is used by the nodes at the endpoints of the LSP, and in some cases by the penultimate hop. Standard Ethertype values are used for packet and Ethernet LSPs; other values are:


   Value   Type                                   Technology
   -----   ----                                   ----------
     0     Unknown                                All
     1     Reserved
     2     Reserved
     3     Reserved
     4     Reserved
     5     Asynchronous mapping of E4             SDH
     6     Asynchronous mapping of DS3/T3         SDH
     7     Asynchronous mapping of E3             SDH
     8     Bit synchronous mapping of E3          SDH
     9     Byte synchronous mapping of E3         SDH
    10     Asynchronous mapping of DS2/T2         SDH
    11     Bit synchronous mapping of DS2/T2      SDH
    12     Reserved
    13     Asynchronous mapping of E1             SDH
    14     Byte synchronous mapping of E1         SDH
    15     Byte synchronous mapping of 31 * DS0   SDH
    16     Asynchronous mapping of DS1/T1         SDH
    17     Bit synchronous mapping of DS1/T1      SDH
    18     Byte synchronous mapping of DS1/T1     SDH
    19     VC-11 in VC-12                         SDH
    20     Reserved
    21     Reserved
    22     DS1 SF Asynchronous                    SONET
    23     DS1 ESF Asynchronous                   SONET
    24     DS3 M23 Asynchronous                   SONET
    25     DS3 C-Bit Parity Asynchronous          SONET
    26     VT/LOVC                                SDH
    27     STS SPE/HOVC                           SDH
    28     POS - No Scrambling, 16 bit CRC        SDH
    29     POS - No Scrambling, 32 bit CRC        SDH
    30     POS - Scrambling, 16 bit CRC           SDH
    31     POS - Scrambling, 32 bit CRC           SDH
    32     ATM mapping                            SDH
    33     Ethernet                               SDH, Lambda, Fiber
    34     SONET/SDH                              Lambda, Fiber
    35     Reserved (SONET deprecated)            Lambda, Fiber
    36     Digital Wrapper                        Lambda, Fiber
    37     Lambda                                 Fiber

38 ANSI/ETSI PDH SDH 39 Reserved SDH 40 Link Access Protocol SDH SDH (LAPS - X.85 and X.86) 41 FDDI SDH, Lambda, Fiber 42 DQDB (ETSI ETS 300 216) SDH 43 FiberChannel-3 (Services) FiberChannel 44 HDLC SDH 45 Ethernet V2/DIX (only) SDH, Lambda, Fiber 46 Ethernet 802.3 (only) SDH, Lambda, Fiber

38 ANSI / ETSI PDH SDH 39留保SDH 40 SDH SDHリンクアクセスプロトコル(ラップ - X.85およびX.86)41 FDDI SDH、ラムダ、ファイバ42 DQDB(ETSI ETS 300 216)SDH 43個のファイバーチャネル-3(サービス)ファイバーチャネル44 HDLC SDH 45イーサネットV2 / DIX(のみ)SDH、ラムダ、ファイバ46イーサネット802.3(のみ)SDH、ラムダ、ファイバ

3.1.2. Bandwidth Encoding
3.1.2. 帯域幅のエンコーディング

Bandwidth encodings are carried in 32 bit number in IEEE floating point format (the unit is bytes per second). For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP. Some typical values for the requested bandwidth are enumerated below. (These values are guidelines.) Additional values will be defined as needed. Bandwidth encoding values are carried in a per protocol specific manner, see [RFC3473] and [RFC3472].

帯域エンコーディング(単位は、秒あたりのバイト数である)IEEE浮動小数点形式の32ビット数で運ばれます。非パケットのLSPのために、LSPの帯域幅を識別するために、離散的な値を定義することが有用です。要求された帯域幅のためのいくつかの典型的な値は、以下に列挙されています。 (これらの値はガイドラインです。)必要に応じて追加の値が定義されます。帯域符号化値は[RFC3473]及び[RFC3472]を参照して、プロトコル当たりの特定の方法で実施されます。

     Signal Type   (Bit-rate)              Value (Bytes/Sec)
                                         (IEEE Floating point)
   --------------  ---------------       ---------------------
              DS0  (0.064 Mbps)              0x45FA0000
              DS1  (1.544 Mbps)              0x483C7A00
               E1  (2.048 Mbps)              0x487A0000
              DS2  (6.312 Mbps)              0x4940A080
               E2  (8.448 Mbps)              0x4980E800
         Ethernet  (10.00 Mbps)              0x49989680
               E3  (34.368 Mbps)             0x4A831A80
              DS3  (44.736 Mbps)             0x4AAAA780
            STS-1  (51.84 Mbps)              0x4AC5C100
    Fast Ethernet  (100.00 Mbps)             0x4B3EBC20
               E4  (139.264 Mbps)            0x4B84D000
        FC-0 133M                            0x4B7DAD68
       OC-3/STM-1  (155.52 Mbps)             0x4B9450C0
        FC-0 266M                            0x4BFDAD68
        FC-0 531M                            0x4C7D3356
      OC-12/STM-4  (622.08 Mbps)             0x4C9450C0
             GigE  (1000.00 Mbps)            0x4CEE6B28
       FC-0 1062M                            0x4CFD3356
     OC-48/STM-16  (2488.32 Mbps)            0x4D9450C0
    OC-192/STM-64  (9953.28 Mbps)            0x4E9450C0
       10GigE-LAN  (10000.00 Mbps)           0x4E9502F9
   OC-768/STM-256  (39813.12 Mbps)           0x4F9450C0
3.2. Generalized Label
3.2. 一般ラベル

The Generalized Label extends the traditional label by allowing the representation of not only labels which travel in-band with associated data packets, but also labels which identify time-slots, wavelengths, or space division multiplexed positions. For example, the Generalized Label may carry a label that represents (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also carry a label that represents a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI).

一般化ラベルはまただけでなく、関連するデータパケットと帯域内移動ラベルが、タイムスロット、波長、または空間分割多重位置を識別ラベルの表現を可能にすることによって、伝統的なラベルを拡張します。例えば、一般化ラベルは、バンドルにおける(A)単一のファイバを表すラベル、(b)は、ファイバ内の単一波長帯、(c)の波長帯(またはファイバ)内の単一波長、または(D)Aを搬送することができます波長(またはファイバ)内のタイムスロットのセット。また、一般的なMPLSラベル、フレームリレーのラベル、またはATMラベル(VCI / VPI)を表しているラベルを運ぶことができます。

A Generalized Label does not identify the "class" to which the label belongs. This is implicit in the multiplexing capabilities of the link on which the label is used.


A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS-HIERARCHY].


Each Generalized Label object/TLV carries a variable length label parameter.

各汎用ラベルオブジェクト/ TLVは、可変長ラベルパラメータを運びます。

3.2.1. Required Information
3.2.1. 必要な情報

The information carried in a Generalized Label is:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |                             Label                             |
   |                              ...                              |

Label: Variable Length


Carries label information. The interpretation of this field depends on the type of the link over which the label is used.

ラベル情報を運びます。このフィールドの解釈は、ラベルが使用されている上、リンクの種類によって異なります。 Port and Wavelength Labels。ポートと波長ラベル

Some configurations of fiber switching (FSC) and lambda switching (LSC) use multiple data channels/links controlled by a single control channel. In such cases the label indicates the data channel/link to be used for the LSP. Note that this case is not the same as when [MPLS-BUNDLE] is being used.


The information carried in a Port and Wavelength label is:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |                             Label                             |

Label: 32 bits


Indicates port/fiber or lambda to be used, from the perspective of the sender of the object/TLV. Values used in this field only have significance between two neighbors, and the receiver may need to convert the received value into a value that has local significance. Values may be configured or dynamically determined using a protocol such as [LMP].

オブジェクト/ TLVの送信者の観点から、使用するポート/繊維又はラムダを示しています。この分野で使用される値は2つのだけネイバー間の有意性を持っており、受信機は、ローカルな意味を持つ値に受信した値を変換する必要があるかもしれません。値は、設定または動的に、このような[LMP]などのプロトコルを使用して決定することができます。 Other Labels。他のラベル

Generic MPLS labels and Frame Relay labels are encoded right justified aligned in 32 bits (4 octets). ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.

汎用MPLSラベルとフレームリレーラベルは右に32ビット(4つのオクテット)に並ん正当化符号化されます。 ATMラベルはビット16-31における右寄せのビット0-15及びVCIに正当化VPI権で符号化されます。

3.3. Waveband Switching
3.3. 波長群スイッチング

A special case of lambda switching is waveband switching. A waveband represents a set of contiguous wavelengths which can be switched together to a new waveband. For optimization reasons it may be desirable for an optical cross connect to optically switch multiple wavelengths as a unit. This may reduce the distortion on the individual wavelengths and may allow tighter separation of the individual wavelengths. The Waveband Label is defined to support this special case.


Waveband switching naturally introduces another level of label hierarchy and as such the waveband is treated the same way all other upper layer labels are treated.


As far as the MPLS protocols are concerned there is little difference between a waveband label and a wavelength label except that semantically the waveband can be subdivided into wavelengths whereas the wavelength can only be subdivided into time or statistically multiplexed labels.


3.3.1. Required information
3.3.1. 必要な情報

Waveband switching uses the same format as the generalized label, see section 3.2.1.


In the context of waveband switching, the generalized label has the following format:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |                          Waveband Id                          |
   |                          Start Label                          |
   |                           End Label                           |

Waveband Id: 32 bits


A waveband identifier. The value is selected by the sender and reused in all subsequent related messages.


Start Label: 32 bits


Indicates the channel identifier of the lowest value wavelength making up the waveband, from the object/TLV sender's perspective.

オブジェクト/ TLVの送信者の観点から、波長帯を構成する最小値の波長のチャネル識別子を示します。

End Label: 32 bits


Indicates the channel identifier of the highest value wavelength making up the waveband, from the object/TLV sender's perspective.

オブジェクト/ TLVの送信者の観点から、波長帯を構成する最高値の波長のチャネル識別子を示します。

Channel identifiers are established either by configuration or by means of a protocol such as LMP [LMP]. They are normally used in the label parameter of the Generalized Label one PSC and LSC.

チャネル識別子は、コンフィギュレーションによって、またはそのようなLMP [LMP]などのプロトコルの手段のいずれかによって確立されます。彼らは通常、汎用ラベル1 PSCとLSCのラベルパラメータで使用されています。

3.4. Suggested Label
3.4. 推奨ラベル

The Suggested Label is used to provide a downstream node with the upstream node's label preference. This permits the upstream node to start configuring its hardware with the proposed label before the label is communicated by the downstream node. Such early configuration is valuable to systems that take non-trivial time to establish a label in hardware. Such early configuration can reduce setup latency, and may be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.


The use of Suggested Label is only an optimization. If a downstream node passes a different label upstream, an upstream LSR reconfigures itself so that it uses the label specified by the downstream node, thereby maintaining the downstream control of a label. Note, the transmission of a suggested label does not imply that the suggested label is available for use. In particular, an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream.


The information carried in a suggested label is identical to a generalized label. Note, values used in the label field of a suggested label are from the object/TLV sender's perspective.

提案されたラベルに運ばれた情報は一般的なラベルと同じです。提案されたラベルのラベルフィールドで使用される値は、オブジェクト/ TLVの送信者の視点からのもの、注意してください。

3.5. Label Set
3.5. ラベルセット

The Label Set is used to limit the label choices of a downstream node to a set of acceptable labels. This limitation applies on a per hop basis.


We describe four cases where a Label Set is useful in the optical domain. The first case is where the end equipment is only capable of transmitting on a small specific set of wavelengths/bands. The second case is where there is a sequence of interfaces which cannot support wavelength conversion (CI-incapable) and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path. The third case is where it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals. The last case is where two ends of a link support different sets of wavelengths.


Label Set is used to restrict label ranges that may be used for a particular LSP between two peers. The receiver of a Label Set must restrict its choice of labels to one which is in the Label Set. Much like a label, a Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable (CI-incapable) interfaces.


The use of Label Set is optional, if not present, all labels from the valid label range may be used. Conceptually the absence of a Label Set implies a Label Set whose value is {U}, the set of all valid labels.


3.5.1. Required Information
3.5.1. 必要な情報

A label set is composed of one or more Label_Set objects/TLVs. Each object/TLV contains one or more elements of the Label Set. Each element is referred to as a subchannel identifier and has the same format as a generalized label.

ラベルセットは、1つのまたは複数のLabel_Setオブジェクト/のTLVで構成されています。各オブジェクト/ TLVは、ラベルセットの1つの以上の要素が含まれています。各要素は、サブチャネル識別子と呼ばれ、一般化されたラベルと同じフォーマットを有しています。

The information carried in a Label_Set is:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |    Action     |      Reserved     |        Label Type         |
   |                          Subchannel 1                         |
   |                              ...                              |
   :                               :                               :
   :                               :                               :
   |                          Subchannel N                         |
   |                              ...                              |

Action: 8 bits


0 - Inclusive List

0 - インクルーシブ一覧

Indicates that the object/TLV contains one or more subchannel elements that are included in the Label Set.

オブジェクト/ TLVはラベルセットに含まれている1つまたは複数のサブチャネル要素が含まれていることを示します。

1 - Exclusive List

1 - 排他的なリスト

Indicates that the object/TLV contains one or more subchannel elements that are excluded from the Label Set.

オブジェクト/ TLVはラベルセットから除外されている1つまたは複数のサブチャネル要素が含まれていることを示します。

2 - Inclusive Range

2 - 包含範囲

Indicates that the object/TLV contains a range of labels. The object/TLV contains two subchannel elements. The first element indicates the start of the range. The second element indicates the end of the range. A value of zero indicates that there is no bound on the corresponding portion of the range.

オブジェクト/ TLVはラベルの範囲が含まれていることを示します。オブジェクトは、/ TLVは、二つのサブチャネル要素が含まれています。最初の要素は、範囲の開始を示します。第2の要素は、範囲の端を示します。ゼロの値は、範囲の対応する部分には結合したがないことを示しています。

3 - Exclusive Range

3 - 独占レンジ

Indicates that the object/TLV contains a range of labels that are excluded from the Label Set. The object/TLV contains two subchannel elements. The first element indicates the start of the range. The second element indicates the end of the range. A value of zero indicates that there is no bound on the corresponding portion of the range.

オブジェクト/ TLVはラベルセットから除外されたラベルの範囲が含まれていることを示します。オブジェクトは、/ TLVは、二つのサブチャネル要素が含まれています。最初の要素は、範囲の開始を示します。第2の要素は、範囲の端を示します。ゼロの値は、範囲の対応する部分には結合したがないことを示しています。

Reserved: 10 bits


This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.


Label Type: 14 bits


Indicates the type and format of the labels carried in the object/TLV. Values are signaling protocol specific.

オブジェクト/ TLVで運ばれたラベルの種類や形式を示します。値は、プロトコルの特定のシグナリングされています。



The subchannel represents the label (wavelength, fiber ... ) which is eligible for allocation. This field has the same format as described for labels under section 3.2.


Note that subchannel to local channel identifiers (e.g., wavelength) mappings are a local matter.


4. Bidirectional LSPs

This section defines direct support of bidirectional LSPs. Support is defined for LSPs that have the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction. In the remainder of this section, the term "initiator" is used to refer to a node that starts the establishment of an LSP and the term "terminator" is used to refer to the node that is the target of the LSP. Note that for bidirectional LSPs, there is only one "initiator" and one "terminator".


Normally to establish a bidirectional LSP when using [RFC3209] or [RFC3212] two unidirectional paths must be independently established. This approach has the following disadvantages:

通常は[RFC3209]または[RFC3212] 2つの単方向経路を使用した場合、双方向LSPを確立するために独立して確立されなければなりません。このアプローチは、次のような欠点があります。

* The latency to establish the bidirectional LSP is equal to one round trip signaling time plus one initiator-terminator signaling transit delay. This not only extends the setup latency for successful LSP establishment, but it extends the worst-case latency for discovering an unsuccessful LSP to as much as two times the initiator-terminator transit delay. These delays are particularly significant for LSPs that are established for restoration purposes.

*双方向LSPを確立するための待ち時間は1回のラウンドトリップシグナリング時間プラスワンイニシエータターミネーターシグナル伝送遅延に等しいです。これが成功したLSPの確立のためのセットアップ・レイテンシを拡張するだけでなく、限り2回の開始剤 - ターミネーター通過遅延に失敗したLSPを発見するための最悪の場合の待ち時間を延長します。これらの遅延は、復旧のために確立されたLSPのために特に重要です。

* The control overhead is twice that of a unidirectional LSP. This is because separate control messages (e.g., Path and Resv) must be generated for both segments of the bidirectional LSP.


* Because the resources are established in separate segments, route selection is complicated. There is also additional potential race for conditions in assignment of resources, which decreases the overall probability of successfully establishing the bidirectional connection.


* It is more difficult to provide a clean interface for SONET/SDH equipment that may rely on bidirectional hop-by-hop paths for protection switching.

*保護スイッチングのための双方向のホップバイホップの経路に依存することがSONET / SDH機器のためのクリーンなインターフェイスを提供することはより困難です。

* Bidirectional optical LSPs (or lightpaths) are seen as a requirement for many optical networking service providers.


With bidirectional LSPs both the downstream and upstream data paths, i.e., from initiator to terminator and terminator to initiator, they are established using a single set of signaling messages. This reduces the setup latency to essentially one initiator-terminator round trip time plus processing time, and limits the control overhead to the same number of messages as a unidirectional LSP.


4.1. Required Information
4.1. 必要な情報

For bidirectional LSPs, two labels must be allocated. Bidirectional LSP setup is indicated by the presence of an Upstream Label object/TLV in the appropriate signaling message. An Upstream Label has the same format as the generalized label, see Section 3.2.

双方向のLSPのために、2つのラベルを割り当てる必要があります。双方向LSPセットアップは、適切なシグナリングメッセージの上流ラベルオブジェクト/ TLVの存在によって示されます。上流のラベルは、3.2節を参照してください、一般的なラベルと同じ形式を持っています。

4.2. Contention Resolution
4.2. 競合の解決

Contention for labels may occur between two bidirectional LSP setup requests traveling in opposite directions. This contention occurs when both sides allocate the same resources (labels) at effectively the same time. If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources, then both nodes will pass different labels upstream and there is no contention. However, if there is a restriction on the labels that can be used for the bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), or if there are no more resources available, then the contention must be resolved by other means. To resolve contention, the node with the higher node ID will win the contention and it MUST issue a PathErr/NOTIFICATION message with a "Routing problem/Label allocation failure" indication. Upon receipt of such an error, the node SHOULD try to allocate a different Upstream label (and a different Suggested Label if used) to the bidirectional path. However, if no other resources are available, the node must proceed with standard error handling.

ラベルの競合は反対方向に走行する2つの双方向LSP設定要求の間発生することがあります。両側が効果的に同時に同じリソース(ラベル)を割り当てる場合、この競合が発生します。双方向のLSPのために使用することができる標識には制限がない場合、代替リソースがある場合、両方のノードが上流の異なる標識を通過し、いかなる競合は存在しません。しかし、(彼らは物理的に1つのI / Oカードに結合されなければならない場合、例えば)双方向のLSPのために使用することができるラベルに制限が存在する場合、または使用可能なより多くのリソースが存在しない場合、競合がなければなりません他の手段によって解決されます。競合を解決するには、高いノードIDを持つノードが競合に勝つだろうし、それは、「ルーティング問題/ラベル割り当ての失敗」の表示とのPathErr / NOTIFICATIONメッセージを発行しなければなりません。このようなエラーを受信すると、ノードは、(使用する場合と異なる推奨ラベル)双方向パスに異なる上流のラベルを割り当てることを試みるべきです。他のリソースが利用可能でない場合は、ノードは、標準エラー処理を進める必要があります。

To reduce the probability of contention, one may impose a policy that the node with the lower ID never suggests a label in the downstream direction and always accepts a Suggested Label from an upstream node with a higher ID. Furthermore, since the labels may be exchanged using LMP, an alternative local policy could further be imposed such that (with respect to the higher numbered node's label set) the higher numbered node could allocate labels from the high end of the label range while the lower numbered node allocates labels from the low end of the label range. This mechanism would augment any close packing algorithms that may be used for bandwidth (or wavelength) optimization. One special case that should be noted when using RSVP and supporting this approach is that the neighbor's node ID might not be known when sending an initial Path message. When this case occurs, a node should suggest a label chosen at random from the available label space.

競合の確率を低減するためには、より低いIDを有するノードが決して下流方向にラベルを示唆していない、常により高いIDを持つ上流ノードから推奨ラベルを受け付けるポリシーを課すことができます。ラベルはLMPを使用して交換することができるので、別のローカルポリシーは、さらに高い番号のノードが低いながら、ラベル範囲の高い端部からラベルを割り当てることができ、このような(より高い番号のノードのラベルセットに対して)ことが課される可能性が番ノードは、ラベル範囲のローエンドからラベルを割り当てます。この機構は、帯域幅(又は波長)最適化のために使用することができる任意近いパッキングアルゴリズムを増大させるであろう。 RSVPを使用して、このアプローチをサポートする際に注意すべき一つの特別なケースでは、最初のPathメッセージを送信する際に、近隣のノードのIDが知られていない可能性がありますということです。この場合は、発生した場合、ノードは、利用可能なラベルスペースからランダムに選ばれたラベルを提案すべきです。

An example of contention between two nodes (PXC 1 and PXC 2) is shown in Figure 1. In this example PXC 1 assigns an Upstream Label for the channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and sends a Suggested Label for the channel corresponding to local BCId=1 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label for the channel corresponding to its local BCId=6 (local BCId=1 on PXC 1) and sends a Suggested Label for the channel corresponding to its local BCId=7 (local BCId=2 on PXC 1). If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources available, then both PXC 1 and PXC 2 will pass different labels upstream and the contention is resolved naturally (see Fig. 2). However, if there is a restriction on the labels that can be used for bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), then the contention must be resolved using the node ID (see Fig. 3).

二つのノード(PXC 1及びPXC 2)間の競合の例は、この例では、PXC 1では、図1に示されていることに対応するチャネルの上流のラベルを割り当てるローカルBCID = 2(ローカルBCID = 7 PXC 2上)と送信しますローカルBCID = 1(ローカルBCID = 6 PXC 2上)に対応するチャンネルの推奨ラベル。同時に、PXC 2は、そのローカルBCID = 6(PXC 1にBCID = 1ローカル)に対応するチャネルの上流のラベルを割り当て、PXC 1にBCID = 2 BCID = 7(ローカルローカルに対応するチャネルのための提案されたラベルを送信します)。 (図2参照)が上流の異なる標識を通過する代替リソースが利用可能である場合、双方向のLSPのために使用することができ、ラベルは、PXC 1及びPXC 2の両方に制限がなく、競合が自然に解決される場合。双方向のLSPのために使用することができる標識に制限がある場合(それらが物理的に1つのI / Oカードに結合されなければならない場合など)しかしながら、その後の競合は、ノードIDを使用して解決されなければならない(図4参照。 3)。

        +------------+                         +------------+
        +   PXC 1    +                         +   PXC 2    +
        +            +                 SL1,UL2 +            +
        +          1 +------------------------>+ 6          +
        +            + UL1, SL2                +            +
        +          2 +<------------------------+ 7          +
        +            +                         +            +
        +            +                         +            +
        +          3 +------------------------>+ 8          +
        +            +                         +            +
        +          4 +<------------------------+ 9          +
        +------------+                         +------------+
                           Figure 1.  Label Contention

In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1).

この例では、PXC 1(PXC 2にBCID = 7)BCID = 2を使用して上流のラベルおよび使用推奨ラベルを割り当てBCID = 1(BCID = 6 PXC 2上)。同時に、PXC 2はBCID = 6(PXC 1にBCID = 1)を用いて上流のラベルとBCID = 7(PXC 1にBCID = 2)を使用して推奨ラベルを割り当てます。

        +------------+                         +------------+
        +   PXC 1    +                         +   PXC 2    +
        +            +                     UL2 +            +
        +          1 +------------------------>+ 6          +
        +            + UL1                     +            +
        +          2 +<------------------------+ 7          +
        +            +                         +            +
        +            +                      L1 +            +
        +          3 +------------------------>+ 8          +
        +            + L2                      +            +
        +          4 +<------------------------+ 9          +
        +------------+                         +------------+

Figure 2. Label Contention Resolution without resource restrictions


In this example, there is no restriction on the labels that can be used by the bidirectional connection and there is no contention.


        +------------+                         +------------+
        +   PXC 1    +                         +   PXC 2    +
        +            +                     UL2 +            +
        +          1 +------------------------>+ 6          +
        +            + L2                      +            +
        +          2 +<------------------------+ 7          +
        +            +                         +            +
        +            +                      L1 +            +
        +          3 +------------------------>+ 8          +
        +            +  UL1                    +            +
        +          4 +<------------------------+ 9          +
        +------------+                         +------------+

Figure 3. Label Contention Resolution with resource restrictions


In this example, labels 1,2 and 3,4 on PXC 1 (labels 6,7 and 8,9 on PXC 2, respectively) must be used by the same bidirectional connection. Since PXC 2 has a higher node ID, it wins the contention and PXC 1 must use a different set of labels.

この例では、同一の双方向接続によって使用されなければならないPXC 1上の1,2及び3,4(それぞれ、PXC 2上の6,7及び8,9ラベル)ラベル。 PXC 2は、より高いノードIDを有しているので、競合に勝つとPXC 1は、ラベルの異なるセットを使用しなければなりません。

5. Notification on Label Error

There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication, see [RFC3209], [RFC3472] and [RFC3473]. When these cases occur, it can be useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol specific error messages, see [RFC3472] and [RFC3473].


The format of an Acceptable Label Set is identical to a Label Set, see section 3.5.1.


6. Explicit Label Control

In traditional MPLS, the interfaces used by an LSP may be controlled via an explicit route, i.e., ERO or ER-Hop. This enables the inclusion of a particular node/interface, and the termination of an LSP on a particular outgoing interface of the egress LSR. Where the interface may be numbered or unnumbered, see [MPLS-UNNUM].


There are cases where the existing explicit route semantics do not provide enough information to control the LSP to the degree desired. This occurs in the case when the LSP initiator wishes to select a label used on a link. Specifically, the problem is that ERO and ER-Hop do not support explicit label sub-objects. An example case where such a mechanism is desirable is where there are two LSPs to be "spliced" together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP. This last case is more likely to be used in the non-PSC classes of links.

既存の明示的経路セマンティクスが所望の程度にLSPを制御するのに十分な情報を提供しない場合があります。 LSPのイニシエータは、リンク上で使用するラベルを選択したいとき、これは場合に発生します。具体的には、問題がEROとERホップが明示的なラベルサブオブジェクトをサポートしていないということです。最初のLSPの尾部は、第二LSPの先頭に「スプライシングされる」ことになる一緒に「スプライシングされた」される2つのLSP、すなわち、存在する場合、そのような機構が望ましい例の場合です。この最後のケースでは、リンクの非PSCのクラスで使用される可能性が高いです。

To cover this case, the Label ERO subobject / ER Hop is introduced.

このケースをカバーするために、ラベルEROサブオブジェクト/ ERホップが導入されます。

6.1. Required Information
6.1. 必要な情報

The Label Explicit and Record Routes contains:


L: 1 bit


This bit must be set to 0.


U: 1 bit


This bit indicates the direction of the label. It is 0 for the downstream label. It is set to 1 for the upstream label and is only used on bidirectional LSPs.


Label: Variable


This field identifies the label to be used. The format of this field is identical to the one used by the Label field in Generalized Label, see Section 3.2.1.


Placement and ordering of these parameters are signaling protocol specific.


7. Protection Information

Protection Information is carried in a new object/TLV. It is used to indicate link related protection attributes of a requested LSP. The use of Protection Information for a particular LSP is optional. Protection Information currently indicates the link protection type desired for the LSP. If a particular protection type, i.e., 1+1, or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored. Note that the protection capabilities of a link may be advertised in routing, see [GMPLS-RTG]. Path computation algorithms may take this information into account when computing paths for setting up LSPs.

保護情報は、新しいオブジェクト/ TLVで運ばれます。要求されたLSPのリンク関連の保護属性を示すために使用されます。特定のLSPの保護情報の使用はオプションです。保護情報は、現在、LSPのために必要なリンク保護タイプを示します。すなわち、1 + 1、又は1、特に保護タイプの場合:N、要求され、次いで、接続要求は、所望の保護型が表彰することができる場合にのみ処理されます。リンクの保護機能は、ルーティングでアドバタイズされてもよいことに留意されたい、[GMPLS-RTG]参照。 LSPを設定するための経路を計算するときに経路計算アルゴリズムは、この情報を考慮することができます。

Protection Information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are not used until the primary LSP fails. The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP MUST be preempted.


7.1. Required Information
7.1. 必要な情報

The following information is carried in Protection Information:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |S|                  Reserved                       | Link Flags|

Secondary (S): 1 bit


When set, indicates that the requested LSP is a secondary LSP.


Reserved: 25 bits


This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes.


Link Flags: 6 bits


Indicates desired link protection type. As previously mentioned, protection capabilities of a link may be advertised in routing. A value of 0 implies that any, including no, link protection may be used. More than one bit may be set to indicate when multiple protection types are acceptable. When multiple bits are set and multiple protection types are available, the choice of protection type is a local (policy) decision.

目的のリンク保護タイプを示します。前述したように、リンクの保護機能は、ルーティングで広告することができます。 0の値は、リンクの保護を使用することができるなど、いずれかのことを意味します。複数のビットは、複数の保護タイプが許容可能であることを示すために設定されてもよいです。複数のビットが設定されていて、複数の保護タイプが用意されていている場合は、保護タイプの選択は、ローカル(ポリシー)の決定です。

The following flags are defined:


0x20 Enhanced


Indicates that a protection scheme that is more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING.

+ 1専用よりも信頼性が高い保護方式は、例えば、4ファイバBLSR / MS-SPRING、使用されるべきであることを示しています。

0x10 Dedicated 1+1

0x10の専用1 + 1

Indicates that a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP.

専用リンク層保護スキーム、すなわち、1 + 1保護は、LSPをサポートするために使用されるべきであることを示します。

0x08 Dedicated 1:1


Indicates that a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP.


0x04 Shared


Indicates that a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP.


0x02 Unprotected


Indicates that the LSP should not use any link layer protection.


0x01 Extra Traffic


Indicates that the LSP should use links that are protecting other (primary) traffic. Such LSPs may be preempted when the links carrying the (primary) traffic being protected fail.

LSPは、他の(プライマリ)トラフィックを保護しているリンクを使用する必要があることを示します。 (一次)を運ぶリンクトラフィックが保護されているが失敗したとき、そのようなLSPはプリエンプトしてもよいです。

8. Administrative Status Information

Administrative Status Information is carried in a new object/TLV. Administrative Status Information is currently used in two ways. In the first, the information indicates administrative state with respect to a particular LSP. In this usage, Administrative Status Information indicates the state of the LSP. State indications include "up" or "down", if it is in a "testing" mode, and if deletion is in progress. The actions taken by a node based on a state local decision. An example action that may be taken is to inhibit alarm reporting when an LSP is in "down" or "testing" states, or to report alarms associated with the connection at a priority equal to or less than "Non service affecting".

管理ステータス情報は、新しいオブジェクト/ TLVで運ばれます。管理ステータス情報は、現在、2つの方法で使用されます。最初に、情報は、特定のLSPに対する管理状態を示しています。この使用法では、管理ステータス情報は、LSPの状態を示します。削除が進行中であるならば、それは「テスト」モードになっている、とあれば状態表示は、「アップ」または「ダウン」が含まれます。状態ローカル決定に基づいて、ノードが実行したアクション。 LSPが「ダウン」または「テスト」状態にある、またはそれに等しいまたは「非サービスに影響」未満優先の接続に関連付けられたアラームを報告するときに取り得る例のアクションは、アラームレポートを阻害することです。

In the second usage of Administrative Status Information, the information indicates a request to set an LSP's administrative state. This information is always relayed to the ingress node which acts on the request.


The different usages are distinguished in a protocol specific fashion. See [RFC3473] and [RFC3472] for details. The use of Administrative Status Information for a particular LSP is optional.


8.1. Required Information
8.1. 必要な情報

The following information is carried in Administrative Status Information:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |R|                        Reserved                       |T|A|D|

Reflect (R): 1 bit


When set, indicates that the edge node SHOULD reflect the object/TLV back in the appropriate message. This bit MUST NOT be set in state change request, i.e., Notify, messages.

設定した場合、エッジノードは、バック適切なメッセージ内のオブジェクト/ TLVを反映すべきであることを示しています。このビットは、即ち、通知、状態変更要求のメッセージを設定してはいけません。

Reserved: 28 bits


This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes.


Testing (T): 1 bit


When set, indicates that the local actions related to the "testing" mode should be taken.


Administratively down (A): 1 bit


When set, indicates that the local actions related to the "administratively down" state should be taken.


Deletion in progress (D): 1 bit


When set, indicates that that the local actions related to LSP teardown should be taken. Edge nodes may use this flag to control connection teardown.


9. Control Channel Separation

The concept of a control channel being different than a data channel being signaled was introduced to MPLS in connection with link bundling, see [MPLS-BUNDLE]. In GMPLS, the separation of control and data channel may be due to any number of factors. (Including bundling and other cases such as data channels that cannot carry in-band control information.) This section will cover the two critical related issues: the identification of data channels in signaling and handling of control channel failures that don't impact data channels.

制御チャネルの概念は、データチャネルとは異なるされ、リンクバンドルに関連してMPLS [MPLS-BUNDLE]を参照するために導入された合図されます。 GMPLSにおいて、制御及びデータチャネルの分離は、任意の数の要因に起因し得ます。 (バンドルそのようなインバンド制御情報を運ぶことができないデータ・チャネルのような他の場合を含む。)このセクションでは、2つの重要な関連する問題について説明します:データチャネルに影響を与えない制御チャネル障害のシグナリングにおけるデータチャネルの識別および取り扱いを。

9.1. Interface Identification
9.1. インタフェース識別

In traditional MPLS there is an implicit one-to-one association of a control channel to a data channel. When such an association is present, no additional or special information is required to associate a particular LSP setup transaction with a particular data channel. (It is implicit in the control channel over which the signaling messages are sent.)

従来のMPLSにデータチャネルに対する制御チャネルの暗黙的な一対一の関連があります。そのような関連付けが存在する場合、追加の又は特別な情報は、特定のデータチャネルと、特定のLSPセットアップトランザクションを関連付けるために必要とされません。 (これは、シグナリングメッセージが送信される上に制御チャネルで暗黙です。)

In cases where there is not an explicit one-to-one association of control channels to data channels it is necessary to convey additional information in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. GMPLS allows the use of a number of interface identification schemes including IPv4 or IPv6 addresses, interface indexes (see [MPLS-UNNUM]) and component interfaces (established via configuration or a protocol such as [LMP]). In all cases the choice of the data interface is indicated by the upstream node using addresses and identifiers used by the upstream node.

データチャネルに対する制御チャネルの明示的な一対一の関連がない場合では、制御される特定のデータチャネルを識別するために、シグナリングに追加的な情報を伝える必要があります。 GMPLSは、インタフェース識別情報を提供することによって、明示的なデータチャネル識別をサポートします。 GMPLSは、([LMP]として構成またはプロトコルを介して確立された)IPv4またはIPv6アドレス、インターフェースインデックス([MPLS-UNNUM]を参照)、コンポーネント・インタフェースを含むインタフェース識別方式の数の使用を可能にします。全ての場合において、データインターフェースの選択は、上流のノードによって使用されるアドレスと識別子を用いて、上流ノードにより示されています。

9.1.1. Required Information
9.1.1. 必要な情報

The following information is carried in Interface_ID:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |                                                               |
   ~                              TLVs                             ~
   |                                                               |

Where each TLV has the following format:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |              Type             |             Length            |
   |                                                               |
   ~                             Value                             ~
   |                                                               |

Length: 16 bits


Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.

オクテットの値フィールドの長さ+ TLVの長さの合計を示し、すなわち、4。 TLVは4オクテット整列されるように、その長さが4の倍数でない値フィールドはゼロ埋めなければなりません。

Type: 16 bits


Indicates type of interface being identified. Defined values are:


   Type Length Format     Description
    1      8   IPv4 Addr. IPv4
    2     20   IPv6 Addr. IPv6
    3     12   See below  IF_INDEX                (Interface Index)
    4     12   See below  COMPONENT_IF_DOWNSTREAM (Component interface)
    5     12   See below  COMPONENT_IF_UPSTREAM   (Component interface)

For types 3, 4 and 5 the Value field has the format:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |                            IP Address                         |
   |                           Interface ID                        |

IP Address: 32 bits


The IP address field may carry either an IP address of a link or an IP address associated with the router, where associated address is the value carried in a router address TLV of routing.


Interface ID: 32 bits


For type 3 usage, the Interface ID carries an interface identifier.


For types 4 and 5, the Interface ID indicates a bundled component link. The special value 0xFFFFFFFF can be used to indicate the same label is to be valid across all component links.

タイプ4および5のために、インタフェースIDは、バンドルコンポーネントリンクを示しています。 0xFFFFFFFFには、同じラベルを示すために使用することができる特別な値は、すべてのコンポーネントリンク全体で有効になることです。

9.2. Fault Handling
9.2. 障害処理

There are two new faults that must be handled when the control channel is independent of the data channel. In the first, there is a link or other type of failure that limits the ability of neighboring nodes to pass control messages. In this situation, neighboring nodes are unable to exchange control messages for a period of time. Once communication is restored the underlying signaling protocol must indicate that the nodes have maintained their state through the failure. The signaling protocol must also ensure that any state changes that were instantiated during the failure are synchronized between the nodes.


In the second, a node's control plane fails and then restarts and losses most of its state information. In this case, both upstream and downstream nodes must synchronize their state information with the restarted node. In order for any resynchronization to occur the node undergoing the restart will need to preserve some information, such as its mappings of incoming to outgoing labels.


Both cases are addressed in protocol specific fashions, see [RFC3473] and [RFC3472].


Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures.


10. Acknowledgments

This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.


Valuable comments and input were received from a number of people, including Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri Papadimitriou, Fong Liaw and Juergen Heiles. Some sections of this document are based on text proposed by Fong Liaw.


11. Security Considerations

This document introduce no new security considerations to either [RFC3212] or [RFC3209]. The security considerations mentioned in [RFC3212] or [RFC3209] apply to the respective protocol specific forms of GMPLS, see [RFC3473] and [RFC3472].

この文書では、[RFC3212]か[RFC3209]のいずれかに全く新しいセキュリティの考慮事項を導入しません。 [RFC3212]または[RFC3209]に記載されたセキュリティ問題[RFC3473]及び[RFC3472]を参照して、GMPLSの各プロトコルの特定の形態にも適用されます。

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

The IANA will administer assignment of new values for namespaces defined in this document. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].

IANAは、この文書で定義された名前空間に新しい値の割り当てを管理します。このセクションでは、[BCP26]「RFCでIANA問題部に書くためのガイドライン」BCP 26の用語を使用しています。

This document defines the following namespaces:


o LSP Encoding Type: 8 bits o Switching Type: 8 bits o Generalized PID (G-PID): 16 bits o Action: 8 bits o Interface_ID Type: 16 bits

O LSP符号化タイプ:スイッチングタイプO 8ビット:一般PID(G-PID)O 8ビット:アクションO 16ビット:Interface_IDタイプO 8ビット:16ビット

All future assignments should be allocated through IETF Consensus action or documented in a Specification.

すべての将来の割り当ては、IETF Consensus動作によって割り当てられたか、仕様書に記載しなければなりません。

LSP Encoding Type - valid value range is 1-255. This document defines values 1-11.

LSPエンコーディングタイプ - 有効な値の範囲は1〜255です。この文書では、値1-11を定義します。

Switching Type - valid value range is 1-255. This document defines values 1-4, 100, 150 and 200.

スイッチングタイプ - 有効な値の範囲は1〜255です。この文書では、値1-4、100、150および200を画定します。

Generalized PID (G-PID) - valid value range is 0-1500. This document defines values 0-46.

一般化されたPID(G-PID) - 有効な値の範囲は0から1500です。この文書では、値が0から46までを定義します。

Action - valid value range is 0-255. This document defines values 0-3.

アクション - 有効な値の範囲は0〜255です。この文書では、値0-3を定義します。

Interface_ID Type - valid value range is 1-65535. This document defines values 1-5.

Interface_IDタイプ - 有効な値の範囲は1〜65535です。この文書では、値1-5を定義します。

13. Intellectual Property Considerations

This section is taken from Section 10.4 of [RFC2026].


The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.


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

IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情​​報を扱ってください。

14. References
14.1. Normative References
14.1. 引用規格

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

[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.

[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。

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

[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニバサン、V.およびG.ツバメ、 "RSVP-TE:ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209、2001年12月。

[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.

[RFC3212] Jamoussi、B.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、Girish、 M.、グレー、E.、Heinanen、J.、Kilty、T.およびA. Malis、 "LDPを使用して、制約ベースLSPセットアップ"、RFC 3212、2002年1月。

[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.

[RFC3472]アッシュウッド・スミス、P。およびL.バーガー、エディターズ、 "一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング - 制約ベースルーティングラベル配布プロトコル(CR-LDP)の拡張"、RFC 3472、2003年1月。

[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3473]バーガー、L.、エディタ "一般化マルチプロトコルラベルスイッチング(GMPLS)シグナリング - リソース予約プロトコル - トラフィックエンジニアリング(RSVP-TE)拡張機能"、RFC 3473、2003年1月。

14.2. Informative References
14.2. 参考文献

[GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.

[GMPLS-RTG] Kompella、K.、ら。、 "一般化MPLSのサポートにルーティング拡張"、ProgressのWork。

[GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH Specifics", Work in Progress.

[GMPLS-SONET]アッシュウッド・スミス、P.ら、 "GMPLS - SONET / SDH細目"、ProgressのWork。

[LMP] Lang, et al., "Link Management Protocol", Work in Progress.


[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.

[MPLS-BUNDLE] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSトラフィックエンジニアリングでのリンクバンドル" が進行中で働いています。

[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.

[MPLS階層] Kompella、K.、およびY. Rekhter、 "MPLS TE LSPと階層"、ProgressのWork。

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996.

[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3、" BCP 9、RFC 2026、1996年10月。

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

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

[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.

[RFC3031]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。

15. Contributors

Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada

ピーター・アッシュウッド・スミスノーテルネットワークス株式会社の私書箱K1Y 4H7カナダONボックス3511駅のC、オタワ、

Phone: +1 613 763 4534 EMail:

電話:+1 613 763 4534 Eメール

Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138


Phone: +1 408 972-3645 EMail:

電話:+1 408 972-3645 Eメール

Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102


Phone: +1 703 847-1801 EMail:

電話:+1 703 847-1801 Eメール

Greg Bernstein




John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138


Phone: +1 408 972 3720 EMail:

電話:+1 408 972 3720 Eメール

Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752

YanheファンAxiowaveネットワークス株式会社200ニッカーソン道路マールボロ、MA 01752

Phone: + 1 774 348 4627 EMail:

電話:+ 1 774 348 4627 Eメール

Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089

Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、CA 94089



Jonathan P. Lang EMail:


Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium EMail:


Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901

バラRajagopalan Tellium、Inc.の2クレセント置き私書箱ボックス901 Oceanport、NJ 07757から0901

Phone: +1 732 923 4237 Fax: +1 732 923 9804 EMail:

電話:+1 732 923 4237ファックス:+1 732 923 9804 Eメール

Yakov Rekhter Juniper Networks, Inc.




Debanjan Saha EMail:


Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174 Phone: +1 650-386-6723 EMail:

ヴィシャル・シャルマMetanoia、Inc.の1600ヴィラ・ストリート、ユニット352マウンテンビュー、カリフォルニア州94041から1174電話:+1 650-386-6723電子メール

George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824

ジョージツバメシスコシステムズ社250アポロドライブチェルムズフォード、MA 01824

Phone: +1 978 244 8143 EMail:

電話:+1 978 244 8143 Eメール

Z. Bo Tang EMail:


16. Editor's Address

Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102


Phone: +1 703 847-1801 EMail:

電話:+1 703 847-1801 Eメール

17. Full Copyright Statement

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


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.






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

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