doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc3946.txt b/doc/rfc/rfc3946.txt
new file mode 100644
index 0000000..8a081c0
--- /dev/null
+++ b/doc/rfc/rfc3946.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                          E. Mannie
+Request for Comments: 3946                                    Consultant
+Category: Standards Track                               D. Papadimitriou
+                                                                 Alcatel
+                                                            October 2004
+
+
+   Generalized Multi-Protocol Label Switching (GMPLS) Extensions for
+                Synchronous Optical Network (SONET) and
+              Synchronous Digital Hierarchy (SDH) Control
+
+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 (2004).
+
+Abstract
+
+   This document is a companion to the Generalized Multi-Protocol Label
+   Switching (GMPLS) signaling.  It defines the Synchronous Optical
+   Network (SONET)/Synchronous Digital Hierarchy (SDH) technology
+   specific information needed when using GMPLS signaling.
+
+Table of Contents
+
+   1.  Introduction .................................................  2
+   2.  SONET and SDH Traffic Parameters .............................  2
+       2.1.  SONET/SDH Traffic Parameters ...........................  3
+       2.2.  RSVP-TE Details ........................................  9
+       2.3.  CR-LDP Details .........................................  9
+   3.  SONET and SDH Labels ......................................... 10
+   4.  Acknowledgments .............................................. 15
+   5.  Security Considerations ...................................... 16
+   6.  IANA Considerations .......................................... 16
+   7.  References ................................................... 16
+       7.1.  Normative References ................................... 16
+   Appendix 1 - Signal Type Values Extension for VC-3 ............... 18
+   Annex 1 - Examples ............................................... 18
+   Contributors ..................................................... 21
+   Authors' Addresses ............................................... 25
+   Full Copyright Statement ......................................... 26
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 1]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+1.  Introduction
+
+   As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from
+   supporting packet (Packet Switching Capable - PSC) interfaces and
+   switching to include support of four new classes of interfaces and
+   switching: Layer-2 Switch Capable (L2SC), Time-Division Multiplex
+   (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC).  A
+   functional description of the extensions to MPLS signaling needed to
+   support the new classes of interfaces and switching is provided in
+   [RFC3471].  [RFC3473] describes RSVP-TE specific formats and
+   mechanisms needed to support all five classes of interfaces, and CR-
+   LDP extensions can be found in [RFC3472].  This document presents
+   details that are specific to Synchronous Optical Network
+   (SONET)/Synchronous Digital Hierarchy (SDH).  Per [RFC3471],
+   SONET/SDH specific parameters are carried in the signaling protocol
+   in traffic parameter specific objects.
+
+   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].
+
+   Moreover, the reader is assumed to be familiar with the terminology
+   in ANSI [T1.105], ITU-T [G.707] as well as [RFC3471], [RFC3472], and
+   [RFC3473].  The following abbreviations are used in this document:
+
+   DCC: Data Communications Channel.
+   LOVC: Lower Order Virtual Container
+   HOVC: Higher Order Virtual Container
+   MS: Multiplex Section.
+   MSOH: Multiplex Section overhead.
+   POH: Path overhead.
+   RS: Regenerator Section.
+   RSOH: Regenerator section overhead.
+   SDH: Synchronous digital hierarchy.
+   SOH: Section overhead.
+   SONET: Synchronous Optical Network.
+   SPE: Synchronous Payload Envelope.
+   STM(-N): Synchronous Transport Module (-N) (SDH).
+   STS(-N): Synchronous Transport Signal-Level N (SONET).
+   VC-n: Virtual Container-n (SDH).
+   VTn: Virtual Tributary-n (SONET).
+
+2.  SONET and SDH Traffic Parameters
+
+   This section defines the GMPLS traffic parameters for SONET/SDH.  The
+   protocol specific formats, for the SONET/SDH-specific RSVP-TE objects
+   and CR-LDP TLVs are described in sections 2.2 and 2.3 respectively.
+
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 2]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   These traffic parameters specify indeed a base set of capabilities
+   for SONET ANSI [T1.105] and SDH ITU-T [G.707] such as concatenation
+   and transparency.  Other documents may further enhance this set of
+   capabilities in the future.  For instance, signaling for SDH over PDH
+   ITU-T G.832 or sub-STM-0 ITU-T G.708 interfaces could be defined.
+
+   The traffic parameters defined hereafter (see Section 2.1) MUST be
+   used when the label is encoded as SUKLM as defined in this memo (see
+   Section 3).  They MUST also be used when requesting one of Section/RS
+   or Line/MS overhead transparent STS-1/STM-0, STS-3*N/STM-N (N=1, 4,
+   16, 64, 256) signals.
+
+   The traffic parameters and label encoding defined in [RFC3471],
+   Section 3.2, MUST be used for fully transparent STS-1/STM-0,
+   STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal requests.  A fully
+   transparent signal is one for which all overhead is left unmodified
+   by intermediate nodes, i.e., when all defined Transparency (T) bits
+   would be set if the traffic parameters defined in section 2.1 were
+   used.
+
+2.1.  SONET/SDH Traffic Parameters
+
+   The traffic parameters for SONET/SDH are organized as follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Signal Type  |      RCC      |              NCC              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              NVC              |        Multiplier (MT)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Transparency (T)                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Profile (P)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Annex 1 lists examples of SONET and SDH signal coding.
+
+   Signal Type (ST): 8 bits
+
+   This field indicates the type of Elementary Signal that comprises the
+   requested LSP.  Several transforms can be applied successively on the
+   Elementary Signal to build the Final Signal being actually requested
+   for the LSP.
+
+   Each transform application is optional and must be ignored if zero,
+   except the Multiplier (MT) that cannot be zero and is ignored if
+   equal to one.
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 3]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   Transforms must be applied strictly in the following order:
+
+   -  First, contiguous concatenation (by using the RCC and NCC fields)
+      can be optionally applied on the Elementary Signal, resulting in a
+      contiguously concatenated signal.
+
+   -  Second, virtual concatenation (by using the NVC field) can be
+      optionally applied on the Elementary Signal resulting in a
+      virtually concatenated signal.
+
+   -  Third, some transparency (by using the Transparency field) can be
+      optionally specified when requesting a frame as signal rather than
+      an SPE or VC based signal.
+
+   -  Fourth, a multiplication (by using the Multiplier field) can be
+      optionally applied either directly on the Elementary Signal, or on
+      the contiguously concatenated signal obtained from the first
+      phase, or on the virtually concatenated signal obtained from the
+      second phase, or on these signals combined with some transparency.
+
+   Permitted Signal Type values for SONET/SDH are:
+
+   Value  Type (Elementary Signal)
+   -----  ------------------------
+    1     VT1.5  SPE / VC-11
+    2     VT2    SPE / VC-12
+    3     VT3    SPE
+    4     VT6    SPE / VC-2
+    5     STS-1  SPE / VC-3
+    6     STS-3c SPE / VC-4
+    7     STS-1      / STM-0   (only when requesting transparency)
+    8     STS-3      / STM-1   (only when requesting transparency)
+    9     STS-12     / STM-4   (only when requesting transparency)
+    10    STS-48     / STM-16  (only when requesting transparency)
+    11    STS-192    / STM-64  (only when requesting transparency)
+    12    STS-768    / STM-256 (only when requesting transparency)
+
+   A dedicated signal type is assigned to a SONET STS-3c SPE instead of
+   coding it as a contiguous concatenation of three STS-1 SPEs.  This is
+   done in order to provide easy interworking between SONET and SDH
+   signaling.
+
+   Appendix 1 adds one signal type (optional) to the above values.
+
+   Requested Contiguous Concatenation (RCC): 8 bits
+
+   This field is used to request the optional SONET/SDH contiguous
+   concatenation of the Elementary Signal.
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 4]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   This field is a vector of flags.  Each flag indicates the support of
+   a particular type of contiguous concatenation.  Several flags can be
+   set at the same time to indicate a choice.
+
+   These flags allow an upstream node to indicate to a downstream node
+   the different types of contiguous concatenation that it supports.
+   However, the downstream node decides which one to use according to
+   its own rules.
+
+   A downstream node receiving simultaneously more than one flag chooses
+   a particular type of contiguous concatenation, if any supported, and
+   based on criteria that are out of this document scope.  A downstream
+   node that doesn't support any of the concatenation types indicated by
+   the field must refuse the LSP request.  In particular, it must refuse
+   the LSP request if it doesn't support contiguous concatenation at
+   all.
+
+   When several flags have been set, the upstream node retrieves the
+   (single) type of contiguous concatenation the downstream node has
+   selected by looking at the position indicated by the first label and
+   the number of label(s) as returned by the downstream node (see also
+   Section 3).
+
+   The entire field is set to zero to indicate that no contiguous
+   concatenation is requested at all (default value).  A non-zero field
+   indicates that some contiguous concatenation is requested.
+
+   The following flag is defined:
+
+      Flag 1 (bit 1): Standard contiguous concatenation.
+
+   Flag 1 indicates that the standard SONET/SDH contiguous concatenation
+   as defined in [T1.105]/[G.707] is supported.  Note that bit 1 is the
+   low order bit.  Other flags are reserved for extensions, if not used
+   they must be set to zero when sent, and should be ignored when
+   received.
+
+   See note 1 hereafter in the section on the NCC about the SONET
+   contiguous concatenation of STS-1 SPEs when the number of components
+   is a multiple of three.
+
+      Number of Contiguous Components (NCC): 16 bits
+
+   This field indicates the number of identical SONET SPEs/SDH VCs
+   (i.e., Elementary Signal) that are requested to be concatenated, as
+   specified in the RCC field.
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 5]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
+      Elementary Signal to use must always be an STS-3c_SPE signal type
+      and the value of NCC must always be equal to X.  This allows also
+      facilitating the interworking between SONET and SDH.  In
+      particular, it means that the contiguous concatenation of three
+      STS-1 SPEs can not be requested because according to this
+      specification, this type of signal must be coded using the STS-3c
+      SPE signal type.
+
+   Note 2: when requesting a transparent STS-N/STM-N signal
+      limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc,
+      the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set
+      to 1.
+
+   The NCC value must be consistent with the type of contiguous
+   concatenation being requested in the RCC field.  In particular, this
+   field is irrelevant if no contiguous concatenation is requested (RCC
+   = 0), in that case it must be set to zero when sent, and should be
+   ignored when received.  A RCC value different from 0 must imply a
+   number of contiguous components greater than 1.
+
+      Number of Virtual Components (NVC): 16 bits
+
+   This field indicates the number of signals that are requested to be
+   virtually concatenated.  These signals are all of the same type by
+   definition.  They are Elementary Signal SPEs/VCs for which signal
+   types are defined in this document, i.e., VT1.5_SPE/VC-11,
+   VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or
+   STS-3c_SPE/VC-4.
+
+   This field is set to 0 (default value) to indicate that no virtual
+   concatenation is requested.
+
+      Multiplier (MT): 16 bits
+
+   This field indicates the number of identical signals that are
+   requested for the LSP, i.e., that form the Final Signal.  These
+   signals can be either identical Elementary Signals, or identical
+   contiguously concatenated signals, or identical virtually
+   concatenated signals.  Note that all these signals belong thus to the
+   same LSP.
+
+   The distinction between the components of multiple virtually
+   concatenated signals is done via the order of the labels that are
+   specified in the signaling.  The first set of labels must describe
+   the first component (set of individual signals belonging to the first
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 6]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   virtual concatenated signal), the second set must describe the second
+   component (set of individual signals belonging to the second virtual
+   concatenated signal) and so on.
+
+   This field is set to one (default value) to indicate that exactly one
+   instance of a signal is being requested.  Intermediate and egress
+   nodes MUST verify that the node itself and the interfaces on which
+   the LSP will be established can support the requested multiplier
+   value.  If the requested values can not be supported, the receiver
+   node MUST generate a PathErr/NOTIFICATION message (see Section
+   2.2/2.3, respectively).
+
+   Zero is an invalid value.  If received, the node MUST generate a
+   PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively).
+
+   Note 1: when requesting a transparent STS-N/STM-N signal limited to a
+   single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the multiplier
+   field MUST be equal to 1 (only valid value).
+
+      Transparency (T): 32 bits
+
+   This field is a vector of flags that indicates the type of
+   transparency being requested.  Several flags can be combined to
+   provide different types of transparency.  Not all combinations are
+   necessarily valid.  The default value for this field is zero, i.e.,
+   no transparency requested.
+
+   Transparency, as defined from the point of view of this signaling
+   specification, is only applicable to the fields in the SONET/SDH
+   frame overheads.  In the SONET case, these are the fields in the
+   Section Overhead (SOH), and the Line Overhead (LOH).  In the SDH
+   case, these are the fields in the Regenerator Section Overhead
+   (RSOH), the Multiplex Section overhead (MSOH), and the pointer fields
+   between the two.  With SONET, the pointer fields are part of the LOH.
+
+   Note as well that transparency is only applicable when using the
+   following Signal Types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4,
+   STS-48/STM-16, STS-192/STM-64 and STS-768/STM-256.  At least one
+   transparency type must be specified when requesting such a signal
+   type.
+
+   Transparency indicates precisely which fields in these overheads must
+   be delivered unmodified at the other end of the LSP.  An ingress LSR
+   requesting transparency will pass these overhead fields that must be
+   delivered to the egress LSR without any change.  From the ingress and
+   egress LSRs point of views, these fields must be seen as unmodified.
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 7]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   Transparency is not applied at the interfaces with the initiating and
+   terminating LSRs, but is only applied between intermediate LSRs.
+
+   The transparency field is used to request an LSP that supports the
+   requested transparency type; it may also be used to setup the
+   transparency process to be applied at each intermediate LSR.
+
+   The different transparency flags are the following:
+
+      Flag 1 (bit 1): Section/Regenerator Section layer.
+      Flag 2 (bit 2): Line/Multiplex Section layer.
+
+   Where bit 1 is the low order bit.  Other flags are reserved, they
+   should be set to zero when sent, and should be ignored when received.
+   A flag is set to one to indicate that the corresponding transparency
+   is requested.
+
+   Intermediate and egress nodes MUST verify that the node itself and
+   the interfaces on which the LSP will be established can support the
+   requested transparency.  If the requested flags can not be supported,
+   the receiver node MUST generate a PathErr/NOTIFICATION message (see
+   Section 2.2/2.3, respectively).
+
+   Section/Regenerator Section layer transparency means that the entire
+   frames must be delivered unmodified.  This implies that pointers
+   cannot be adjusted.  When using Section/Regenerator Section layer
+   transparency all other flags MUST be ignored.
+
+   Line/Multiplex Section layer transparency means that the LOH/MSOH
+   must be delivered unmodified.  This implies that pointers cannot be
+   adjusted.
+
+   Profile (P): 32 bits
+
+   This field is intended to indicate particular capabilities that must
+   be supported for the LSP, for example monitoring capabilities.
+
+   No standard profile is currently defined and this field SHOULD be set
+   to zero when transmitted and SHOULD be ignored when received.
+
+   In the future TLV based extensions may be created.
+
+
+
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 8]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+2.2.  RSVP-TE Details
+
+   For RSVP-TE, the SONET/SDH traffic parameters are carried in the
+   SONET/SDH SENDER_TSPEC and FLOWSPEC objects.  The same format is used
+   both for SENDER_TSPEC object and FLOWSPEC objects.  The content of
+   the objects is defined above in Section 2.1.  The objects have the
+   following class and type:
+
+   For SONET ANSI T1.105 and SDH ITU-T G.707:
+
+   SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4
+   SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4
+
+   There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
+   Either the Adspec is omitted or an int-serv Adspec with the Default
+   General Characterization Parameters and Guaranteed Service fragment
+   is used, see [RFC2210].
+
+   For a particular sender in a session the contents of the FLOWSPEC
+   object received in a Resv message SHOULD be identical to the contents
+   of the SENDER_TSPEC object received in the corresponding Path
+   message.  If the objects do not match, a ResvErr message with a
+   "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.
+
+   Intermediate and egress nodes MUST verify that the node itself and
+   the interfaces on which the LSP will be established can support the
+   requested Signal Type, RCC, NCC, NVC and Multiplier (as defined in
+   Section 2.1).  If the requested value(s) can not be supported, the
+   receiver node MUST generate a PathErr message with a "Traffic Control
+   Error/ Service unsupported" indication (see [RFC2205]).
+
+   In addition, if the MT field is received with a zero value, the node
+   MUST generate a PathErr message with a "Traffic Control Error/Bad
+   Tspec value" indication (see [RFC2205]).
+
+   Intermediate nodes MUST also verify that the node itself and the
+   interfaces on which the LSP will be established can support the
+   requested Transparency (as defined in Section 2.1).  If the requested
+   value(s) can not be supported, the receiver node MUST generate a
+   PathErr message with a "Traffic Control Error/Service unsupported"
+   indication (see [RFC2205]).
+
+2.3.  CR-LDP Details
+
+   For CR-LDP, the SONET/SDH traffic parameters are carried in the
+   SONET/SDH Traffic Parameters TLV.  The content of the TLV is defined
+   above in Section 2.1.  The header of the TLV has the following
+   format:
+
+
+
+Mannie & Papadimitriou      Standards Track                     [Page 9]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |U|F|          Type             |      Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The type field for the SONET/SDH Traffic Parameters TLV is: 0x0838.
+
+   Intermediate and egress nodes MUST verify that the node itself and
+   the interfaces on which the LSP will be established can support the
+   requested Signal Type, RCC, NCC, NVC and Multiplier (as defined in
+   Section 2.1).  If the requested value(s) can not be supported, the
+   receiver node MUST generate a NOTIFICATION message with a "Resource
+   Unavailable" status code (see [RFC3212]).
+
+   In addition, if the MT field is received with a zero value, the node
+   MUST generate a NOTIFICATION message with a "Resource Unavailable"
+   status code (see [RFC3212]).
+
+   Intermediate nodes MUST also verify that the node itself and the
+   interfaces on which the LSP will be established can support the
+   requested Transparency (as defined in Section 2.1).  If the requested
+   value(s) can not be supported, the receiver node MUST generate a
+   NOTIFICATION message with a "Resource Unavailable" status code (see
+   [RFC3212]).
+
+3.  SONET and SDH Labels
+
+   SONET and SDH each define a multiplexing structure.  Both structures
+   are trees whose roots are respectively an STS-N or an STM-N; and
+   whose leaves are the signals that can be transported via the time-
+   slots and switched between time-slots within an ingress port and
+   time-slots within an egress port, i.e., a VTx SPE, an STS-x SPE or a
+   VC-x.  A SONET/SDH label will identify the exact position (i.e.,
+   first time-slot) of a particular VTx SPE, STS-x SPE or VC-x signal in
+   a multiplexing structure.  SONET and SDH labels are carried in the
+   Generalized Label per [RFC3473] and [RFC3472].
+
+   Note that by time-slots we mean the time-slots as they appear
+   logically and sequentially in the multiplex, not as they appear after
+   any possible interleaving.
+
+   These multiplexing structures will be used as naming trees to create
+   unique multiplex entry names or labels.  The same format of label is
+   used for SONET and SDH.  As explained in [RFC3471], a label does not
+   identify the "class" to which the label belongs.  This is implicitly
+   determined by the link on which the label is used.
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 10]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   In case of signal concatenation or multiplication, a list of labels
+   can appear in the Label field of a Generalized Label.
+
+   In case of contiguous concatenation, only one label appears in the
+   Label field.  This label identifies the lowest time-slot occupied by
+   the contiguously concatenated signal.  By lowest time-slot we mean
+   the one having the lowest label (value) when compared as integer
+   values, i.e., the time-slot occupied by the first component signal of
+   the concatenated signal encountered when descending the tree.
+
+   In case of virtual concatenation, the explicit ordered list of all
+   labels in the concatenation is given.  Each label indicates the first
+   time-slot occupied by a component of the virtually concatenated
+   signal.  The order of the labels must reflect the order of the
+   payloads to concatenate (not the physical order of time-slots).  The
+   above representation limits virtual concatenation to remain within a
+   single (component) link; it imposes as such a restriction compared to
+   the ANSI [T1.105]/ITU-T [G.707] recommendations.
+
+   The standard definition for virtual concatenation allows each virtual
+   concatenation components to travel over diverse paths.  Within GMPLS,
+   virtual concatenation components must travel over the same
+   (component) link if they are part of the same LSP.  This is due to
+   the way that labels are bound to a (component) link.  Note however,
+   that the routing of components on different paths is indeed
+   equivalent to establishing different LSPs, each one having its own
+   route.  Several LSPs can be initiated and terminated between the same
+   nodes and their corresponding components can then be associated
+   together (i.e., virtually concatenated).
+
+   In case of multiplication (i.e., using the multiplier transform), the
+   explicit ordered list of all labels that take part in the Final
+   Signal is given.  In case of multiplication of virtually concatenated
+   signals, the first set of labels indicates the time-slots occupied by
+   the first virtually concatenated signal, the second set of labels
+   indicates the time-slots occupied by the second virtually
+   concatenated signal, and so on.  The above representation limits
+   multiplication to remain within a single (component) link.
+
+   The format of the label for SONET and/or SDH TDM-LSR link 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               S               |   U   |   K   |   L   |   M   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 11]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   This is an extension of the numbering scheme defined in [G.707]
+   sections 7.3.7 to 7.3.13, i.e., the (K, L, M) numbering.  Note that
+   the higher order numbering scheme defined in [G.707] sections 7.3.1
+   to 7.3.6 is not used here.
+
+   Each letter indicates a possible branch number starting at the parent
+   node in the multiplex structure.  Branches are considered as numbered
+   in increasing order, starting from the top of the multiplexing
+   structure.  The numbering starts at 1, zero is used to indicate a
+   non-significant or ignored field.
+
+   When a field is not significant or ignored in a particular context it
+   MUST be set to zero when transmitted, and MUST be ignored when
+   received.
+
+   When a hierarchy of SONET/SDH LSPs is used, a higher order LSP with a
+   given bandwidth can be used to carry lower order LSPs.  Remember here
+   that a higher order LSP is established through a SONET/SDH higher
+   order path layer network and a lower order LSP, through a SONET/SDH
+   lower order path layer network (see also ITU-T G.803, Section 3 for
+   the corresponding definitions).  In this context, the higher order
+   SONET/SDH LSP behaves as a "virtual link" with a given bandwidth
+   (e.g., VC-3), it may also be used as a Forwarding Adjacency.  A lower
+   order SONET/SDH LSP can be established through that higher order LSP.
+   Since a label is local to a (virtual) link, the highest part of that
+   label (i.e., the S, U and K fields) is non-significant and is set to
+   zero, i.e., the label is "0,0,0,L,M".  Similarly, if the structure of
+   the lower order LSP is unknown or not relevant, the lowest part of
+   that label (i.e., the L and M fields) is non-significant and is set
+   to zero, i.e., the label is "S,U,K,0,0".
+
+   For instance, a VC-3 LSP can be used to carry lower order LSPs.  In
+   that case the labels allocated between the two ends of the VC-3 LSP
+   for the lower order LSPs will have S, U and K set to zero, i.e.,
+   non-significant, while L and M will be used to indicate the signal
+   allocated in that VC-3.
+
+   In case of tunneling such as VC-4 containing VC-3 containing
+   VC-12/VC-11 where the SUKLM structure is not adequate to represent
+   the full signal structure, a hierarchical approach must be used,
+   i.e., per layer network signaling.
+
+   The possible values of S, U, K, L and M are defined as follows:
+
+   1. S=1->N is the index of a particular STS-3/AUG-1 inside an
+      STS-N/STM-N multiplex.  S is only significant for SONET STS-N
+      (N>1) and SDH STM-N (N>0).  S must be 0 and ignored for STS-1 and
+      STM-0.
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 12]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an
+      STS-3/AUG-1.  U is only significant for SONET STS-N (N>1) and SDH
+      STM-N (N>0).  U must be 0 and ignored for STS-1 and STM-0.
+
+   3. K=1->3 is the index of a particular TUG-3 within a VC-4.  K is
+      only significant for an SDH VC-4 structured in TUG-3s.  K must be
+      0 and ignored in all other cases.
+
+   4. L=1->7 is the index of a particular VT_Group/TUG-2 within an
+      STS-1_SPE/TUG-3 or VC-3.  L must be 0 and ignored in all other
+      cases.
+
+   5. M is the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12 or
+      VT3_SPE within a VT_Group/TUG-2.  M=1->2 indicates a specific VT3
+      SPE inside the corresponding VT Group, these values MUST NOT be
+      used for SDH since there is no equivalent of VT3 with SDH.  M=3->5
+      indicates a specific VT2_SPE/VC-12 inside the corresponding
+      VT_Group/TUG-2.  M=6->9 indicates a specific VT1.5_SPE/VC-11
+      inside the corresponding VT_Group/TUG-2.
+
+   Note that a label always has to be interpreted according the
+   SONET/SDH traffic parameters, i.e., a label by itself does not allow
+   knowing which signal is being requested (a label is context
+   sensitive).
+
+   The label format defined in this section, referred to as SUKLM, MUST
+   be used for any SONET/SDH signal requests that are not transparent
+   i.e., when all Transparency (T) bits defined in section 2.1 are set
+   to zero.  Any transparent STS-1/STM-0/STS-3*N/STM-N (N=1, 4, 16, 64,
+   256) signal request MUST use a label format as defined in [RFC3471].
+
+   The S encoding is summarized in the following table:
+
+    S    SDH                     SONET
+   ------------------------------------------------
+    0    other                   other
+    1    1st AUG-1               1st STS-3
+    2    2nd AUG-1               2nd STS-3
+    3    3rd AUG-1               3rd STS-3
+    4    4rd AUG-1               4rd STS-3
+    :    :                       :
+    N    Nth AUG-1               Nth STS-3
+
+
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 13]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   The U encoding is summarized in the following table:
+
+    U    SDH AUG-1               SONET STS-3
+   -------------------------------------------------
+    0    other                   other
+    1    1st VC-3                1st STS-1 SPE
+    2    2nd VC-3                2nd STS-1 SPE
+    3    3rd VC-3                3rd STS-1 SPE
+
+   The K encoding is summarized in the following table:
+
+    K    SDH VC-4
+   ---------------
+    0    other
+    1    1st TUG-3
+    2    2nd TUG-3
+    3    3rd TUG-3
+
+   The L encoding is summarized in the following table:
+
+    L    SDH TUG-3    SDH VC-3    SONET STS-1 SPE
+   -------------------------------------------------
+    0    other        other       other
+    1    1st TUG-2    1st TUG-2   1st VTG
+    2    2nd TUG-2    2nd TUG-2   2nd VTG
+    3    3rd TUG-2    3rd TUG-2   3rd VTG
+    4    4th TUG-2    4th TUG-2   4th VTG
+    5    5th TUG-2    5th TUG-2   5th VTG
+    6    6th TUG-2    6th TUG-2   6th VTG
+    7    7th TUG-2    7th TUG-2   7th VTG
+
+   The M encoding is summarized in the following table:
+
+    M    SDH TUG-2                 SONET VTG
+   -------------------------------------------------
+    0    other                     other
+    1    -                         1st VT3 SPE
+    2    -                         2nd VT3 SPE
+    3    1st VC-12                 1st VT2 SPE
+    4    2nd VC-12                 2nd VT2 SPE
+    5    3rd VC-12                 3rd VT2 SPE
+    6    1st VC-11                 1st VT1.5 SPE
+    7    2nd VC-11                 2nd VT1.5 SPE
+    8    3rd VC-11                 3rd VT1.5 SPE
+    9    4th VC-11                 4th VT1.5 SPE
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 14]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   Examples of labels:
+
+   Example 1: the label for the STS-3c_SPE/VC-4 in the Sth STS-3/AUG-1
+      is: S>0, U=0, K=0, L=0, M=0.
+
+   Example 2: the label for the VC-3 within the Kth-1 TUG-3 within
+      the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
+
+   Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth
+      STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.
+
+   Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2
+      in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 is: S>0,
+      U>0, K=0, L>0, M=0.
+
+   Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT
+      Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the Sth STS-
+      3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.
+
+   Example 6: the label for the STS-12c/VC-4-4c which uses the 9th
+      STS-3/AUG-1 as its first timeslot is: S=9, U=0, K=0, L=0, M=0.
+
+   In case of contiguous concatenation, the label that is used is the
+   lowest label (value) of the contiguously concatenated signal as
+   explained before.  The higher part of the label indicates where the
+   signal starts and the lowest part is not significant.
+
+   In case of STM-0/STS-1, the values of S, U and K must be equal to
+   zero according to the field coding rules.  For instance, when
+   requesting a VC-3 in an STM-0 the label is S=0, U=0, K=0, L=0, M=0.
+   When requesting a VC-11 in a VC-3 in an STM-0 the label is S=0, U=0,
+   K=0, L>0, M=6..9.
+
+   Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS-
+   3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM label
+   format and encoding is not applicable and the label encoding MUST
+   follow the rules defined in [RFC3471] Section 3.2.
+
+4.  Acknowledgments
+
+   Valuable comments and input were received from the CCAMP mailing list
+   where outstanding discussions took place.
+
+
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 15]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+5.  Security Considerations
+
+   This document introduces no new security considerations to either
+   [RFC3473] or [RFC3472].  GMPLS security is described in section 11 of
+   [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] for
+   CR-LDP.
+
+6.  IANA Considerations
+
+   Three values have been defined by IANA for this document:
+
+   Two RSVP C-Types in registry:
+      http://www.iana.org/assignments/rsvp-parameters
+
+   -  A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (see
+      section 2.2).
+
+   -  A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see section
+      2.2).
+
+   One LDP TLV Type in registry:
+      http://www.iana.org/assignments/ldp-namespaces
+
+   -  A type field for the SONET/SDH Traffic Parameters TLV (see section
+      2.3).
+
+7.  References
+
+7.1.  Normative References
+
+   [G.707]      ITU-T Recommendation G.707, "Network Node Interface for
+                the Synchronous Digital Hierarchy", October 2000.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
+                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
+                1 Functional Specification", RFC 2205, September 1997.
+
+   [RFC2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
+                Services", RFC 2210, September 1997.
+
+   [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.
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 16]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   [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.
+
+   [RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
+                (MPLS) Signaling Functional Description", RFC 3471,
+                January 2003.
+
+   [RFC3472]    Ashwood-Smith, P. and L. Berger, "Generalized
+                Multi-Protocol Label Switching (MPLS) Signaling
+                - Constraint-based Routed Label Distribution Protocol
+                (CR-LDP) Extensions", RFC 3472, January 2003.
+
+   [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
+                (MPLS) Signaling - Resource ReserVation Protocol Traffic
+                Engineering (RSVP-TE) Extensions", RFC 3473, January
+                2003.
+
+   [RFC3945]    Mannie, E., Ed., "Generalized Multiprotocol Label
+                Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+   [T1.105]     "Synchronous Optical Network (SONET): Basic Description
+                Including Multiplex Structure, Rates, and Formats", ANSI
+                T1.105, October 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 17]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+Appendix 1 - Signal Type Values Extension for VC-3
+
+   This appendix defines the following optional additional Signal Type
+   value for the Signal Type field of section 2.1:
+
+   Value         Type
+   -----  ---------------------
+    20     "VC-3 via AU-3 at the end"
+
+   According to the ITU-T [G.707] recommendation a VC-3 in the TU-
+   3/TUG-3/VC-4/AU-4 branch of the SDH multiplex cannot be structured in
+   TUG-2s, however a VC-3 in the AU-3 branch can be. In addition, a VC-3
+   could be switched between the two branches if required.
+
+   A VC-3 circuit could be terminated on an ingress interface of an LSR
+   (e.g., forming a VC-3 forwarding adjacency). This LSR could then want
+   to demultiplex this VC-3 and switch internal low order LSPs. For
+   implementation reasons, this could be only possible if the LSR
+   receives the VC-3 in the AU-3 branch.  E.g., for an LSR not able to
+   switch internally from a TU-3 branch to an AU-3 branch on its
+   incoming interface before demultiplexing and then switching the
+   content with its switch fabric.
+
+   In that case it is useful to indicate that the VC-3 LSP must be
+   terminated at the end in the AU-3 branch instead of the TU-3 branch.
+
+   This is achieved by using the "VC-3 via AU-3 at the end" signal type.
+   This information can be used, for instance, by the penultimate LSR to
+   switch an incoming VC-3 received in any branch to the AU-3 branch on
+   the outgoing interface to the destination LSR.
+
+   The "VC-3 via AU-3 at the end" signal type does not imply that the
+   VC-3 must be switched via the AU-3 branch at some other places in the
+   network. The VC-3 signal type just indicates that a VC-3 in any
+   branch is suitable.
+
+Annex 1 - Examples
+
+   This annex defines examples of SONET and SDH signal coding. Their
+   objective is to help the reader to understand how works the traffic
+   parameter coding and not to give examples of typical SONET or SDH
+   signals.
+
+   As stated above, signal types are Elementary Signals to which
+   successive concatenation, multiplication and transparency transforms
+   can be applied to obtain Final Signals.
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 18]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   1.   A VC-4 signal is formed by the application of RCC with value 0,
+        NCC with value 0, NVC with value 0, MT with value 1 and T with
+        value 0 to a VC-4 Elementary Signal.
+
+   2.   A VC-4-7v signal is formed by the application of RCC with value
+        0, NCC with value 0, NVC with value 7 (virtual concatenation of
+        7 components), MT with value 1 and T with value 0 to a VC-4
+        Elementary Signal.
+
+   3.   A VC-4-16c signal is formed by the application of RCC with flag
+        1 (standard contiguous concatenation), NCC with value 16, NVC
+        with value 0, MT with value 1 and T with value 0 to a VC-4
+        Elementary Signal.
+
+   4.   An STM-16 signal with Multiplex Section layer transparency is
+        formed by the application of RCC with value 0, NCC with value 0,
+        NVC with value 0, MT with value 1 and T with flag 2 to an STM-16
+        Elementary Signal.
+
+   5.   An STM-4 signal with Multiplex Section layer transparency is
+        formed by the application of RCC with flag 0, NCC with value 0,
+        NVC with value 0, MT with value 1 and T with flag 2 applied to
+        an STM-4 Elementary Signal.
+
+   6.   An STM-256 signal with Multiplex Section layer transparency is
+        formed by the application of RCC with flag 0, NCC with value 0,
+        NVC with value 0, MT with value 1 and T with flag 2 applied to
+        an STM-256 Elementary Signal.
+
+   7.   An STS-1 SPE signal is formed by the application of RCC with
+        value 0, NCC with value 0, NVC with value 0, MT with value 1 and
+        T with value 0 to an STS-1 SPE Elementary Signal.
+
+   8.   An STS-3c SPE signal is formed by the application of RCC with
+        value 1 (standard contiguous concatenation), NCC with value 1,
+        NVC with value 0, MT with value 1 and T with value 0 to an STS-
+        3c SPE Elementary Signal.
+
+   9.   An STS-48c SPE signal is formed by the application of RCC with
+        flag 1 (standard contiguous concatenation), NCC with value 16,
+        NVC with value 0, MT with value 1 and T with value 0 to an STS-
+        3c SPE Elementary Signal.
+
+   10.  An STS-1-3v SPE signal is formed by the application of RCC with
+        value 0, NVC with value 3 (virtual concatenation of 3
+        components), MT with value 1 and T with value 0 to an STS-1 SPE
+        Elementary Signal.
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 19]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   11.  An STS-3c-9v SPE signal is formed by the application of RCC with
+        value 1, NCC with value 1, NVC with value 9 (virtual
+        concatenation of 9 STS-3c), MT with value 1 and T with value 0
+        to an STS-3c SPE Elementary Signal.
+
+   12.  An STS-12 signal with Section layer (full) transparency is
+        formed by the application of RCC with value 0, NVC with value 0,
+        MT with value 1 and T with flag 1 to an STS-12 Elementary
+        Signal.
+
+   13.  3 x STS-768c SPE signal is formed by the application of RCC with
+        flag 1, NCC with value 256, NVC with value 0, MT with value 3,
+        and T with value 0 to an STS-3c SPE Elementary Signal.
+
+   14.  5 x VC-4-13v composed signal is formed by the application of RCC
+        with value 0, NVC with value 13, MT with value 5 and T with
+        value 0 to a VC-4 Elementary Signal.
+
+   The encoding of these examples is summarized in the following table:
+
+   Signal                     ST   RCC   NCC   NVC   MT   T
+   --------------------------------------------------------
+   VC-4                        6     0     0     0    1   0
+   VC-4-7v                     6     0     0     7    1   0
+   VC-4-16c                    6     1    16     0    1   0
+   STM-16 MS transparent      10     0     0     0    1   2
+   STM-4 MS transparent        9     0     0     0    1   2
+   STM-256 MS transparent     12     0     0     0    1   2
+   STS-1 SPE                   5     0     0     0    1   0
+   STS-3c SPE                  6     1     1     0    1   0
+   STS-48c SPE                 6     1    16     0    1   0
+   STS-1-3v SPE                5     0     0     3    1   0
+   STS-3c-9v SPE               6     1     1     9    1   0
+   STS-12 Section transparent  9     0     0     0    1   1
+   3 x STS-768c SPE            6     1   256     0    3   0
+   5 x VC-4-13v                6     0     0    13    5   0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 20]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+Contributors
+
+   Contributors are listed by alphabetical order:
+
+   Stefan Ansorge (Alcatel)
+   Lorenzstrasse 10
+   70435 Stuttgart, Germany
+
+   EMail: stefan.ansorge@alcatel.de
+
+
+   Peter Ashwood-Smith (Nortel)
+   PO. Box 3511 Station C,
+   Ottawa, ON K1Y 4H7, Canada
+
+   EMail:petera@nortelnetworks.com
+
+
+   Ayan Banerjee (Calient)
+   5853 Rue Ferrari
+   San Jose, CA 95138, USA
+
+   EMail: abanerjee@calient.net
+
+
+   Lou Berger (Movaz)
+   7926 Jones Branch Drive
+   McLean, VA 22102, USA
+
+   EMail: lberger@movaz.com
+
+
+   Greg Bernstein (Ciena)
+   10480 Ridgeview Court
+   Cupertino, CA 94014, USA
+
+   EMail: greg@ciena.com
+
+
+   Angela Chiu (Celion)
+   One Sheila Drive, Suite 2
+   Tinton Falls, NJ 07724-2658
+
+   EMail: angela.chiu@celion.com
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 21]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   John Drake (Calient)
+   5853 Rue Ferrari
+   San Jose, CA 95138, USA
+
+   EMail: jdrake@calient.net
+
+
+   Yanhe Fan (Axiowave)
+   100 Nickerson Road
+   Marlborough, MA 01752, USA
+
+   EMail: yfan@axiowave.com
+
+
+   Michele Fontana (Alcatel)
+   Via Trento 30,
+   I-20059 Vimercate, Italy
+
+   EMail: michele.fontana@alcatel.it
+
+
+   Gert Grammel (Alcatel)
+   Lorenzstrasse, 10
+   70435 Stuttgart, Germany
+
+   EMail: gert.grammel@alcatel.de
+
+
+   Juergen Heiles (Siemens)
+   Hofmannstr. 51
+   D-81379 Munich, Germany
+
+   EMail: juergen.heiles@siemens.com
+
+
+   Suresh Katukam (Cisco)
+   1450 N. McDowell Blvd,
+   Petaluma, CA 94954-6515, USA
+
+   EMail: suresh.katukam@cisco.com
+
+
+   Kireeti Kompella (Juniper)
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA 94089, USA
+
+   EMail: kireeti@juniper.net
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 22]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+
+   Jonathan P. Lang (Calient)
+   25 Castilian
+   Goleta, CA 93117, USA
+
+   EMail: jplang@calient.net
+
+
+   Fong Liaw (Solas Research)
+
+   EMail: fongliaw@yahoo.com
+
+
+   Zhi-Wei Lin (Lucent)
+   101 Crawfords Corner Rd
+   Holmdel, NJ  07733-3030, USA
+
+   EMail: zwlin@lucent.com
+
+
+   Ben Mack-Crane (Tellabs)
+
+   EMail: ben.mack-crane@tellabs.com
+
+
+   Dimitrios Pendarakis (Tellium)
+   2 Crescent Place, P.O. Box 901
+   Oceanport, NJ 07757-0901, USA
+
+   EMail: dpendarakis@tellium.com
+
+
+   Mike Raftelis (White Rock)
+   18111 Preston Road
+   Dallas, TX 75252, USA
+
+
+   Bala Rajagopalan (Tellium)
+   2 Crescent Place, P.O. Box 901
+   Oceanport, NJ 07757-0901, USA
+
+   EMail: braja@tellium.com
+
+
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 23]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+   Yakov Rekhter (Juniper)
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA 94089, USA
+
+   EMail: yakov@juniper.net
+
+
+   Debanjan Saha (Tellium)
+   2 Crescent Place, P.O. Box 901
+   Oceanport, NJ 07757-0901, USA
+
+   EMail: dsaha@tellium.com
+
+
+   Vishal Sharma (Metanoia)
+   335 Elan Village Lane
+   San Jose, CA 95134, USA
+
+   EMail: vsharma87@yahoo.com
+
+
+   George Swallow (Cisco)
+   250 Apollo Drive
+   Chelmsford, MA 01824, USA
+
+   EMail: swallow@cisco.com
+
+
+   Z. Bo Tang (Tellium)
+   2 Crescent Place, P.O. Box 901
+   Oceanport, NJ 07757-0901, USA
+
+   EMail: btang@tellium.com
+
+
+   Eve Varma (Lucent)
+   101 Crawfords Corner Rd
+   Holmdel, NJ  07733-3030, USA
+
+   EMail: evarma@lucent.com
+
+
+   Yangguang Xu (Lucent)
+   21-2A41, 1600 Osgood Street
+   North Andover, MA 01845, USA
+
+   EMail: xuyg@lucent.com
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 24]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+Authors' Addresses
+
+   Eric Mannie (Consultant)
+   Avenue de la Folle Chanson, 2
+   B-1050 Brussels, Belgium
+   Phone:  +32 2 648-5023
+   Mobile: +32 (0)495-221775
+
+   EMail:  eric_mannie@hotmail.com
+
+
+   Dimitri Papadimitriou (Alcatel)
+   Francis Wellesplein 1,
+   B-2018 Antwerpen, Belgium
+   Phone:  +32 3 240-8491
+
+   EMail:  dimitri.papadimitriou@alcatel.be
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 25]
+
+RFC 3946         GMPLS Extensions for SONET/SDH Control     October 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Mannie & Papadimitriou      Standards Track                    [Page 26]
+