doc: Add RFC documents

1 files changed, 1907 insertions, 0 deletions

diff --git a/doc/rfc/rfc3471.txt b/doc/rfc/rfc3471.txt
new file mode 100644
index 0000000..3204bd6
--- /dev/null
+++ b/doc/rfc/rfc3471.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   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.
+
+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
+
+
+
+Berger                      Standards Track                     [Page 1]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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
+
+   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).
+
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 2]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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).
+
+   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.
+
+   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].
+
+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
+
+
+
+Berger                      Standards Track                     [Page 3]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+
+Berger                      Standards Track                     [Page 4]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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.
+
+   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.
+
+   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].
+
+
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 5]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+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
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 6]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+3.1.1. Required Information
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 7]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+      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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                     [Page 8]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+      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
+
+
+
+Berger                      Standards Track                     [Page 9]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+    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
+
+3.1.2. Bandwidth Encoding
+
+   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].
+
+     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
+
+
+
+
+
+Berger                      Standards Track                    [Page 10]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+3.2. Generalized Label
+
+   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 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.
+
+3.2.1. Required Information
+
+   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.
+
+3.2.1.1. 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.
+
+
+
+Berger                      Standards Track                    [Page 11]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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].
+
+3.2.1.2. 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.
+
+3.3. Waveband Switching
+
+   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.
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 12]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+3.3.1. Required information
+
+   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.
+
+      End Label: 32 bits
+
+         Indicates the channel identifier of the highest value
+         wavelength making up the waveband, from the object/TLV sender's
+         perspective.
+
+   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.
+
+3.4. Suggested Label
+
+   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
+
+
+
+
+Berger                      Standards Track                    [Page 13]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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.
+
+3.5. Label Set
+
+   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.
+
+
+
+
+Berger                      Standards Track                    [Page 14]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+3.5.1. Required Information
+
+   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.
+
+   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
+
+         Indicates that the object/TLV contains one or more subchannel
+         elements that are included in the Label Set.
+
+      1 - Exclusive List
+
+         Indicates that the object/TLV contains one or more subchannel
+         elements that are excluded from the Label Set.
+
+      2 - Inclusive Range
+
+         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.
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 15]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+      3 - Exclusive Range
+
+         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.
+
+   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.
+
+   Subchannel:
+
+      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:
+
+   *  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
+
+
+
+Berger                      Standards Track                    [Page 16]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+      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.
+
+   *  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.
+
+   *  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
+
+   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.
+
+4.2. Contention Resolution
+
+   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
+
+
+
+Berger                      Standards Track                    [Page 17]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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.
+
+   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.
+
+   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).
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 18]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+        +------------+                         +------------+
+        +   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    +
+        +            +                     UL2 +            +
+        +          1 +------------------------>+ 6          +
+        +            + UL1                     +            +
+        +          2 +<------------------------+ 7          +
+        +            +                         +            +
+        +            +                      L1 +            +
+        +          3 +------------------------>+ 8          +
+        +            + L2                      +            +
+        +          4 +<------------------------+ 9          +
+        +------------+                         +------------+
+
+    Figure 2. Label Contention Resolution without resource restrictions
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 19]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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.
+
+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
+
+
+
+Berger                      Standards Track                    [Page 20]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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.
+
+   To cover this case, the Label ERO subobject / ER Hop is introduced.
+
+6.1. Required Information
+
+   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.
+
+   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
+
+
+
+Berger                      Standards Track                    [Page 21]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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
+
+   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.
+
+         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.
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 22]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+         0x10  Dedicated 1+1
+
+            Indicates that a dedicated link layer protection scheme,
+            i.e., 1+1 protection, should be used to support the 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.
+
+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".
+
+   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.
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 23]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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
+
+   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.
+
+      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.
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 24]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+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.
+
+9.1. Interface Identification
+
+   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.)
+
+   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.
+
+9.1.1. Required Information
+
+   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                             ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 25]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   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.
+
+      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.
+
+
+
+Berger                      Standards Track                    [Page 26]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+      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.
+
+9.2. Fault Handling
+
+   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.
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 27]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+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].
+
+12. IANA Considerations
+
+   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].
+
+   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
+
+   All future assignments should be allocated through IETF Consensus
+   action or documented in a Specification.
+
+   LSP Encoding Type - valid value range is 1-255.  This document
+   defines values 1-11.
+
+   Switching Type - valid value range is 1-255.  This document defines
+   values 1-4, 100, 150 and 200.
+
+   Generalized PID (G-PID) - valid value range is 0-1500.  This document
+   defines values 0-46.
+
+   Action - valid value range is 0-255.  This document defines values
+   0-3.
+
+   Interface_ID Type - valid value range is 1-65535.  This document
+   defines values 1-5.
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 28]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+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.
+
+14. References
+
+14.1. Normative References
+
+   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
+                    Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+   [RFC3036]        Andersson, L., Doolan, P., Feldman, N., Fredette, A.
+                    and B. Thomas, "LDP Specification", RFC 3036,
+                    January 2001.
+
+   [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.
+
+   [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.
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 29]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   [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.
+
+   [RFC3473]        Berger, L., Editor "Generalized Multi-Protocol Label
+                    Switching (GMPLS) Signaling - Resource ReserVation
+                    Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                    RFC 3473, January 2003.
+
+14.2. Informative References
+
+   [GMPLS-RTG]      Kompella, K., et al., "Routing Extensions in Support
+                    of Generalized MPLS", Work in Progress.
+
+   [GMPLS-SONET]    Ashwood-Smith, P., et al., "GMPLS - SONET / SDH
+                    Specifics", Work in Progress.
+
+   [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-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
+                    MPLS TE", Work in Progress.
+
+   [RFC2026]        Bradner, S., "The Internet Standards Process --
+                    Revision 3," BCP 9, RFC 2026, October 1996.
+
+   [RFC2434]        Narten, T. and H. Alvestrand, "Guidelines for
+                    Writing an IANA Considerations Section in RFCs", BCP
+                    26, RFC 2434, October 1998.
+
+   [RFC3031]        Rosen, E., Viswanathan, A. and R. Callon,
+                    "Multiprotocol label switching Architecture", RFC
+                    3031, January 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 30]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+15. Contributors
+
+   Peter Ashwood-Smith
+   Nortel Networks Corp.
+   P.O. Box 3511 Station C,
+   Ottawa, ON K1Y 4H7
+   Canada
+
+   Phone:  +1 613 763 4534
+   EMail:  petera@nortelnetworks.com
+
+
+   Ayan Banerjee
+   Calient Networks
+   5853 Rue Ferrari
+   San Jose, CA 95138
+
+   Phone:  +1 408 972-3645
+   EMail:  abanerjee@calient.net
+
+
+   Lou Berger
+   Movaz Networks, Inc.
+   7926 Jones Branch Drive
+   Suite 615
+   McLean VA, 22102
+
+   Phone:  +1 703 847-1801
+   EMail:  lberger@movaz.com
+
+
+   Greg Bernstein
+
+   EMail:  gregb@grotto-networking.com
+
+
+   John Drake
+   Calient Networks
+   5853 Rue Ferrari
+   San Jose, CA 95138
+
+   Phone:  +1 408 972 3720
+   EMail:  jdrake@calient.net
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 31]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   Yanhe Fan
+   Axiowave Networks, Inc.
+   200 Nickerson Road
+   Marlborough, MA 01752
+
+   Phone: + 1 774 348 4627
+   EMail: yfan@axiowave.com
+
+
+   Kireeti Kompella
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA 94089
+
+   EMail:  kireeti@juniper.net
+
+
+   Jonathan P. Lang
+   EMail:  jplang@ieee.org
+
+
+   Eric Mannie
+   Independent Consultant
+   2 Avenue de la Folle Chanson
+   1050 Brussels
+   Belgium
+   EMail:  eric_mannie@hotmail.com
+
+
+   Bala Rajagopalan
+   Tellium, Inc.
+   2 Crescent Place
+   P.O. Box 901
+   Oceanport, NJ 07757-0901
+
+   Phone:  +1 732 923 4237
+   Fax:    +1 732 923 9804
+   EMail:  braja@tellium.com
+
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+
+   EMail:  yakov@juniper.net
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 32]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+   Debanjan Saha
+   EMail:  debanjan@acm.org
+
+
+   Vishal Sharma
+   Metanoia, Inc.
+   1600 Villa Street, Unit 352
+   Mountain View, CA 94041-1174
+   Phone:  +1 650-386-6723
+   EMail:  v.sharma@ieee.org
+
+
+   George Swallow
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA 01824
+
+   Phone:  +1 978 244 8143
+   EMail:  swallow@cisco.com
+
+
+   Z. Bo Tang
+   EMail:  botang01@yahoo.com
+
+16. Editor's Address
+
+   Lou Berger
+   Movaz Networks, Inc.
+   7926 Jones Branch Drive
+   Suite 615
+   McLean VA, 22102
+
+   Phone:  +1 703 847-1801
+   EMail:  lberger@movaz.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 33]
+
+RFC 3471        GMPLS Signaling Functional Description
+
+
+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.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger                      Standards Track                    [Page 34]
+