doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc7139.txt b/doc/rfc/rfc7139.txt
new file mode 100644
index 0000000..a99e310
--- /dev/null
+++ b/doc/rfc/rfc7139.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     F. Zhang, Ed.
+Request for Comments: 7139                                        Huawei
+Updates: 4328                                                   G. Zhang
+Category: Standards Track                                           CATR
+ISSN: 2070-1721                                               S. Belotti
+                                                          Alcatel-Lucent
+                                                           D. Ceccarelli
+                                                                Ericsson
+                                                             K. Pithewan
+                                                                Infinera
+                                                              March 2014
+
+
+                       GMPLS Signaling Extensions
+        for Control of Evolving G.709 Optical Transport Networks
+
+Abstract
+
+   ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel
+   Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and
+   enhanced Optical Transport Network (OTN) flexibility.
+
+   This document updates the ODU-related portions of RFC 4328 to provide
+   extensions to GMPLS signaling to control the full set of OTN
+   features, including ODU0, ODU4, ODU2e, and ODUflex.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7139.
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 1]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. GMPLS Extensions for the Evolving G.709 -- Overview .............3
+   4. Generalized Label Request .......................................4
+   5. Extensions for Traffic Parameters for Evolving G.709 OTNs .......7
+      5.1. Usage of ODUflex(CBR) Traffic Parameters ...................8
+      5.2. Usage of ODUflex(GFP) Traffic Parameters ..................10
+      5.3. Notification on Errors of OTN-TDM Traffic Parameters ......11
+   6. Generalized Label ..............................................12
+      6.1. OTN-TDM Switching Type Generalized Label ..................12
+      6.2. Procedures ................................................14
+           6.2.1. Notification on Label Error ........................16
+      6.3. Supporting Virtual Concatenation and Multiplication .......17
+      6.4. Examples ..................................................17
+   7. Supporting Hitless Adjustment of ODUflex(GFP) ..................19
+   8. Operations, Administration, and Maintenance (OAM)
+      Considerations .................................................20
+   9. Control-Plane Backward-Compatibility Considerations ............20
+   10. Security Considerations .......................................21
+   11. IANA Considerations ...........................................21
+   12. References ....................................................23
+      12.1. Normative References .....................................23
+      12.2. Informative References ...................................24
+   13. Contributors ..................................................25
+   14. Acknowledgments ...............................................26
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 2]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+1.  Introduction
+
+   With the evolution and deployment of Optical Transport Network (OTN)
+   technology, it is necessary that appropriate enhanced control
+   technology support be provided for [G709-2012].
+
+   [RFC7062] provides a framework to allow the development of protocol
+   extensions to support GMPLS and Path Computation Element (PCE)
+   control of OTN as specified in [G709-2012].  Based on this framework,
+   [RFC7096] evaluates the information needed by the routing and
+   signaling process in OTNs to support GMPLS control of OTN.
+
+   [RFC4328] describes the control technology details that are specific
+   to the 2001 revision of the G.709 specification.  This document
+   updates the ODU-related portions of [RFC4328] to provide Resource
+   Reservation Protocol - Traffic Engineering (RSVP-TE) extensions to
+   support control for [G709-2012].
+
+2.  Terminology
+
+   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].
+
+3.  GMPLS Extensions for the Evolving G.709 -- Overview
+
+   New features for the evolving OTN, for example, new ODU0, ODU2e,
+   ODU4, and ODUflex containers, are specified in [G709-2012].  The
+   corresponding new Signal Types are summarized below:
+
+   -  Optical channel Transport Unit (OTUk):
+      o  OTU4
+
+   -  Optical channel Data Unit (ODUk):
+      o  ODU0
+      o  ODU2e
+      o  ODU4
+      o  ODUflex
+
+   A new tributary slot granularity (i.e., 1.25 Gbps) is also described
+   in [G709-2012].  Thus, there are now two tributary slot (TS)
+   granularities for the foundation OTN ODU1, ODU2, and ODU3 containers.
+   The TS granularity at 2.5 Gbps is used on the legacy interfaces while
+   the new 1.25 Gbps is used on the new interfaces.
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 3]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3,
+   4), [G709-2012] encompasses the multiplexing of ODUj (j = 0, 1, 2,
+   2e, 3, flex) into an ODUk (k > j), as described in Section 3.1.2 of
+   [RFC7062].
+
+   Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk)
+   (OPUk-Xv, k = 1/2/3, X = 1...256) is also supported by [G709-2012].
+   Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per
+   [G709-2012].
+
+   [RFC4328] describes GMPLS signaling extensions to support the control
+   for the 2001 revision of the G.709 specification.  However, [RFC7096]
+   does not provide the means to signal all the new Signal Types and
+   related mapping and multiplexing functionalities.  Moreover, it
+   supports only the deprecated auto-MSI (Multiframe Structure
+   Identifier) mode, which assumes that the Tributary Port Number (TPN)
+   is automatically assigned in the transmit direction and not checked
+   in the receive direction.
+
+   This document extends the G.709 Traffic Parameters described in
+   [RFC4328] and presents a new flexible and scalable OTN-TDM
+   Generalized Label format.  (Here, TDM refers to Time-Division
+   Multiplexing.)  Additionally, procedures about Tributary Port Number
+   assignment through the control plane are also provided in this
+   document.
+
+4.  Generalized Label Request
+
+   The GENERALIZED_LABEL_REQUEST object, as described in [RFC3471],
+   carries the Label Switched Path (LSP) Encoding Type, the Switching
+   Type, and the Generalized Protocol Identifier (G-PID).
+
+   [RFC4328] extends the GENERALIZED_LABEL_REQUEST object, introducing
+   two new code-points for the LSP Encoding Type (i.e., G.709 ODUk
+   (Digital Path) and G.709 Optical Channel) and adding a list of G-PID
+   values in order to accommodate the 2001 revision of the G.709
+   specification.
+
+   This document follows these extensions and introduces a new Switching
+   Type to indicate the ODUk Switching Capability [G709-2012] in order
+   to support backward compatibility with [RFC4328], as described in
+   [RFC7062].  The new Switching Type (OTN-TDM Switching Type) is
+   defined in [RFC7138].
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 4]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   This document also updates the G-PID values defined in [RFC4328]:
+
+   Value    G-PID Type
+   -----    ----------
+
+   47       Type field updated from "G.709 ODUj" to "ODU-2.5G" to
+            indicate transport of Digital Paths (e.g., at 2.5, 10, and
+            40 Gbps) via 2.5 Gbps TS granularity.
+
+   56       Type field updated from "ESCON" to "SBCON/ESCON" to align
+            with [G709-2012] payload type 0x1A.
+
+   Note: Value 47 includes mapping of Synchronous Digital Hierarchy
+   (SDH).
+
+   In the case of ODU multiplexing, the Lower Order ODU (LO ODU) (i.e.,
+   the client signal) may be multiplexed into a Higher Order ODU (HO
+   ODU) via 1.25G TS granularity, 2.5G TS granularity, or ODU-any.
+   Since the G-PID type "ODUk" defined in [RFC4328] is only used for 2.5
+   Gbps TS granularity, two new G-PID types are defined as follows:
+
+   -  ODU-1.25G:  Transport of Digital Paths at 1.25, 2.5, 10, 40, and
+                  100 Gbps via 1.25 Gbps TS granularity.
+
+   -  ODU-any:    Transport of Digital Paths at 1.25, 2.5, 10, 40, and
+                  100 Gbps via 1.25 or 2.5 Gbps TS granularity (i.e.,
+                  the fallback procedure is enabled and the default
+                  value of 1.25 Gbps TS granularity can fall back to 2.5
+                  Gbps if needed).
+
+   The full list of payload types defined in [G709-2012] and their
+   mapping to existing and new G-PID types are as follows:
+
+     G.709
+    Payload
+     Type     G-PID        Type/Comment             LSP Encoding
+     ====     =====    =====================     ===================
+     0x01              No standard value
+     0x02      49      CBRa                      G.709 ODUk
+     0x03      50      CBRb                      G.709 ODUk
+     0x04      32      ATM                       G.709 ODUk
+     0x05      59      Framed GFP                G.709 ODUk
+               54      Ethernet MAC (framed GFP) G.709 ODUk
+               70      64B/66B GFP-F Ethernet    G.709 ODUk (k=2)
+     0x06              Not signaled
+     0x07      55      Ethernet PHY              G.709 ODUk (k=0,3,4)
+                       (transparent GFP)
+     0x08      58      Fiber Channel             G.709 ODUk (k=2e)
+
+
+
+Zhang, et al.                Standards Track                    [Page 5]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+     0x09      59      Framed GFP                G.709 ODUk (k=2)
+               70      64B/66B GFP-F Ethernet    G.709 ODUk (k=2)
+     0x0A      60      STM-1                     G.709 ODUk (k=0)
+     0x0B      61      STM-4                     G.709 ODUk (k=0)
+     0x0C      58      Fiber Channel             G.709 ODUk (k=0)
+     0x0D      58      Fiber Channel             G.709 ODUk (k=1)
+     0x0E      58      Fiber Channel             G.709 ODUflex
+     0x0F      58      Fiber Channel             G.709 ODUflex
+     0x10      51      BSOT                      G.709 ODUk
+     0x11      52      BSNT                      G.709 ODUk
+     0x12      62      InfiniBand                G.709 ODUflex
+     0x13      62      InfiniBand                G.709 ODUflex
+     0x14      62      InfiniBand                G.709 ODUflex
+     0x15      63      Serial Digital Interface  G.709 ODUk (k=0)
+     0x16      64      SDI/1.001                 G.709 ODUk (k=1)
+     0x17      63      Serial Digital Interface  G.709 ODUk (k=1)
+     0x18      64      SDI/1.001                 G.709 ODUflex
+     0x19      63      Serial Digital Interface  G.709 ODUflex
+     0x1A      56      SBCON/ESCON               G.709 ODUk (k=0)
+     0x1B      65      DVB_ASI                   G.709 ODUk (k=0)
+     0x1C      58      Fiber Channel             G.709 ODUk
+     0x20      47      G.709 ODU-2.5G            G.709 ODUk (k=2,3)
+               66      G.709 ODU-1.25G           G.709 ODUk (k=1)
+     0x21      66      G.709 ODU-1.25G           G.709 ODUk (k=2,3,4)
+               67      G.709 ODU-any             G.709 ODUk (k=2,3)
+     0x55              No standard value
+     0x66              No standard value
+     0x80-0x8F         No standard value
+     0xFD      68      Null Test                 G.709 ODUk
+     0xFE      69      Random Test               G.709 ODUk
+     0xFF              No standard value
+
+   Note: Values 59 and 70 include mapping of SDH.
+
+   Note that the mapping types for ODUj into OPUk are unambiguously per
+   Table 7-10 of [G709-2012], so there is no need to carry mapping type
+   information in the signaling.
+
+   Note also that additional information on G.709 client mapping can be
+   found in [G7041].
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 6]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+5.  Extensions for Traffic Parameters for Evolving G.709 OTNs
+
+   The Traffic Parameters for the OTN-TDM-capable Switching Type are
+   carried in the OTN-TDM SENDER_TSPEC object in the Path message and
+   the OTN-TDM FLOWSPEC object in the Resv message.  The objects have
+   the following class and type:
+
+   -  OTN-TDM SENDER_TSPEC object: Class = 12, C-Type = 7
+   -  OTN-TDM FLOWSPEC object: Class = 9, C-Type = 7
+
+   The format of Traffic Parameters in these two objects is defined 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  |                       Reserved                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              NVC              |        Multiplier (MT)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Bit_Rate                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Signal Type: 8 bits
+
+      As defined in Section 3.2.1 of [RFC4328], with the following
+      additional values:
+
+      Value    Type
+      -----    ----
+      4        ODU4 (i.e., 100 Gbps)
+      9        OCh at 100 Gbps
+      10       ODU0 (i.e., 1.25 Gbps)
+      11       ODU2e (i.e., 10 Gbps for FC1200 and GE LAN)
+      12-19    Reserved (for future use)
+      20       ODUflex(CBR) (i.e., 1.25*N Gbps)
+      21       ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)
+      22       ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
+      23-255   Reserved (for future use)
+
+   Note: Above, CBR stands for Constant Bit Rate, and GFP-F stands for
+   Generic Framing Procedure - Framed.
+
+   NVC (Number of Virtual Components): 16 bits
+
+      As defined in Section 3.2.3 of [RFC4328].  This field MUST be set
+      to 0 for ODUflex Signal Types.
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 7]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   Multiplier (MT): 16 bits
+
+      As defined in Section 3.2.4 of [RFC4328].  This field MUST be set
+      to 1 for ODUflex Signal Types.
+
+   Bit_Rate: 32 bits
+
+      In the case of ODUflex, including ODUflex(CBR) and ODUflex(GFP)
+      Signal Types, this field indicates the nominal bit rate of ODUflex
+      expressed in bytes per second, encoded as a 32-bit IEEE single-
+      precision floating-point number (referring to [RFC4506] and
+      [IEEE]).  For other Signal Types, this field MUST be set to zero
+      on transmission, MUST be ignored on receipt, and SHOULD be passed
+      unmodified by transit nodes.
+
+5.1.  Usage of ODUflex(CBR) Traffic Parameters
+
+   In the case of ODUflex(CBR), the Bit_Rate information carried in the
+   ODUflex Traffic Parameters MUST be used to determine the actual
+   bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)).
+   Therefore, the total number of tributary slots N in the HO ODUk link
+   can be reserved correctly.  Where:
+
+         N = Ceiling of
+
+   ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
+   ---------------------------------------------------------------------
+       ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
+
+   In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of
+   the ODUflex(CBR) on the line side, i.e., the client signal bit rate
+   after applying the 239/238 factor (according to Clause 7.3, Table 7-2
+   of [G709-2012]) and the transcoding factor T (if needed) on the CBR
+   client.  According to Clauses 17.7.3, 17.7.4, and 17.7.5 of
+   [G709-2012]:
+
+   ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T
+
+   The ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary
+   slots) nominal bit rate is the nominal bit rate of the tributary slot
+   of ODUk, as shown in Table 1 (referring to Table 7-7 of [G709-2012]).
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 8]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+      ODUk.ts       Minimum          Nominal          Maximum
+      -----------------------------------------------------------
+      ODU2.ts    1,249,384.632    1,249,409.620     1,249,434.608
+      ODU3.ts    1,254,678.635    1,254,703.729     1,254,728.823
+      ODU4.ts    1,301,683.217    1,301,709.251     1,301,735.285
+
+              Table 1: Actual TS Bit Rate of ODUk (in Kbps)
+
+   Note that:
+
+      Minimum bit rate of ODUTk.ts =
+         ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
+
+      Maximum bit rate of ODTUk.ts =
+         ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance)
+
+      Where: HO OPUk bit rate tolerance = 20 ppm (parts per million)
+
+   Note that the bit rate tolerance is implicit in Signal Type and the
+   ODUflex(CBR) bit rate tolerance is fixed and it is equal to 100 ppm
+   as described in Table 7-2 of [G709-2012].
+
+   Therefore, a node receiving a Path message containing an ODUflex(CBR)
+   nominal bit rate can allocate a precise number of tributary slots and
+   set up the cross-connection for the ODUflex service.
+
+   Note that for different ODUk, the bit rates of the tributary slots
+   are different, so the total number of tributary slots to be reserved
+   for the ODUflex(CBR) may not be the same on different HO ODUk links.
+
+   An example is given below to illustrate the usage of ODUflex(CBR)
+   Traffic Parameters.
+
+       +-----+             +---------+             +-----+
+       |     +-------------+ +-----+ +-------------+     |
+       |     +=============+\| ODU |/+=============+     |
+       |     +=============+/| flex+-+=============+     |
+       |     +-------------+ |     |\+=============+     |
+       |     +-------------+ +-----+ +-------------+     |
+       |     |             |         |             |     |
+       |     |   .......   |         |   .......   |     |
+       |  A  +-------------+    B    +-------------+  C  |
+       +-----+   HO ODU4   +---------+   HO ODU2   +-----+
+
+         =========: TSs occupied by ODUflex
+         ---------: available TSs
+
+       Figure 1: Example of ODUflex(CBR) Traffic Parameters
+
+
+
+Zhang, et al.                Standards Track                    [Page 9]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   As shown in Figure 1, assume there is an ODUflex(CBR) service
+   requesting a bandwidth of 2.5 Gbps from node A to node C.
+
+   In other words, the ODUflex Traffic Parameters indicate that Signal
+   Type is 20 (ODUflex(CBR)) and Bit_Rate is 2.5 Gbps (note that the
+   tolerance is not signaled as explained above).
+
+   -  On the HO ODU4 link between node A and B:
+
+      The maximum bit rate of the ODUflex(CBR) equals 2.5 Gbps * (1 +
+      100 ppm), and the minimum bit rate of the tributary slot of ODU4
+      equals 1,301,683.217 Kbps, so the total number of tributary slots
+      N1 to be reserved on this link is:
+
+      N1 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,301,683.217 Kbps) = 2
+
+   -  On the HO ODU2 link between node B and C:
+
+      The maximum bit rate of the ODUflex equals 2.5 Gbps * (1 + 100
+      ppm), and the minimum bit rate of the tributary slot of ODU2
+      equals 1,249,384.632 Kbps, so the total number of tributary slots
+      N2 to be reserved on this link is:
+
+      N2 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,249,384.632 Kbps) = 3
+
+5.2.  Usage of ODUflex(GFP) Traffic Parameters
+
+   [G709-2012] recommends that the ODUflex(GFP) fill an integral number
+   of tributary slots of the smallest HO ODUk path over which the
+   ODUflex(GFP) may be carried, as shown in Table 2.
+
+                 ODU Type              | Nominal Bit Rate | Tolerance
+      ---------------------------------+------------------+-----------
+      ODUflex(GFP) of n TSs, 1<=n<=8   |   n * ODU2.ts    | +/-100 ppm
+      ODUflex(GFP) of n TSs, 9<=n<=32  |   n * ODU3.ts    | +/-100 ppm
+      ODUflex(GFP) of n TSs, 33<=n<=80 |   n * ODU4.ts    | +/-100 ppm
+
+         Table 2: Recommended ODUflex(GFP) Bit Rates and Tolerance
+
+   According to this table, the Bit_Rate field for ODUflex(GFP) MUST be
+   equal to one of the 80 values listed below:
+
+           1 * ODU2.ts;  2 * ODU2.ts; ...;  8 * ODU2.ts;
+           9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
+          33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 10]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   In this way, the number of required tributary slots for the
+   ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from
+   the Bit_Rate field.
+
+5.3.  Notification on Errors of OTN-TDM Traffic Parameters
+
+   There is no Adspec associated with the OTN-TDM SENDER_TSPEC object.
+   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 OTN-TDM
+   FLOWSPEC object received in a Resv message SHOULD be identical to the
+   contents of the OTN-TDM 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 MUST
+   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, NVC, and Bit_Rate values.  If the requested
+   value(s) cannot 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]).
+
+   Further, if the Signal Type is not ODU1, ODU2, or ODU3, and the NVC
+   field is not 0, the node MUST generate a PathErr message with a
+   "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 11]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+6.  Generalized Label
+
+   This section defines the format of the OTN-TDM Generalized Label.
+
+6.1.  OTN-TDM Switching Type Generalized Label
+
+   The following is the GENERALIZED_LABEL object format that MUST be
+   used with the OTN-TDM Switching Type:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |         TPN           |   Reserved    |        Length         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                   Bit Map          ......                     ~
+    ~              ......                   |     Padding Bits      ~
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The OTN-TDM GENERALIZED_LABEL object is used to indicate how the LO
+   ODUj signal is multiplexed into the HO ODUk link.  Note that the LO
+   OUDj Signal Type is indicated by Traffic Parameters, while the type
+   of HO ODUk link is identified by the selected interface carried in
+   the IF_ID RSVP_HOP object.
+
+   TPN: 12 bits
+
+      Indicates the TPN for the assigned tributary slot(s).
+
+      -  In the case of an LO ODUj multiplexed into an HO
+         ODU1/ODU2/ODU3, only the lower 6 bits of the TPN field are
+         significant; the other bits of the TPN field MUST be set to 0.
+
+      -  In the case of an LO ODUj multiplexed into an HO ODU4, only the
+         lower 7 bits of the TPN field are significant; the other bits
+         of the TPN field MUST be set to 0.
+
+      -  In the case of ODUj mapped into OTUk (j=k), the TPN is not
+         needed, and this field MUST be set to 0.
+
+      Per [G709-2012], the TPN is used to allow for correct
+      demultiplexing in the data plane.  When an LO ODUj is multiplexed
+      into an HO ODUk occupying one or more TSs, a new TPN value is
+      configured at the two ends of the HO ODUk link and is put into the
+      related MSI byte(s) in the OPUk overhead at the (traffic) ingress
+      end of the link, so that the other end of the link can learn which
+      TS(s) is/are used by the LO ODUj in the data plane.
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 12]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+      According to [G709-2012], the TPN field MUST be set according to
+      the following tables:
+
+      +-------+-------+----+-------------------------------------------+
+      |HO ODUk|LO ODUj|TPN |          TPN Assignment Rules             |
+      +-------+-------+----+-------------------------------------------+
+      | ODU2  | ODU1  |1-4 |Fixed, = TS# occupied by ODU1              |
+      +-------+-------+----+-------------------------------------------+
+      |       | ODU1  |1-16|Fixed, = TS# occupied by ODU1              |
+      | ODU3  +-------+----+-------------------------------------------+
+      |       | ODU2  |1-4 |Flexible, != other existing LO ODU2s' TPNs |
+      +-------+-------+----+-------------------------------------------+
+
+             Table 3: TPN Assignment Rules (2.5 Gbps TS Granularity)
+
+      +-------+-------+----+-------------------------------------------+
+      |HO ODUk|LO ODUj|TPN |          TPN Assignment Rules             |
+      +-------+-------+----+-------------------------------------------+
+      | ODU1  | ODU0  |1-2 |Fixed, = TS# occupied by ODU0              |
+      +-------+-------+----+-------------------------------------------+
+      |       | ODU1  |1-4 |Flexible, != other existing LO ODU1s' TPNs |
+      | ODU2  +-------+----+-------------------------------------------+
+      |       |ODU0 & |1-8 |Flexible, != other existing LO ODU0s and   |
+      |       |ODUflex|    |ODUflexes' TPNs                            |
+      +-------+-------+----+-------------------------------------------+
+      |       | ODU1  |1-16|Flexible, != other existing LO ODU1s' TPNs |
+      |       +-------+----+-------------------------------------------+
+      |       | ODU2  |1-4 |Flexible, != other existing LO ODU2s' TPNs |
+      | ODU3  +-------+----+-------------------------------------------+
+      |       |ODU0 & |    |Flexible, != other existing LO ODU0s and   |
+      |       |ODU2e &|1-32|ODU2s and ODUflexes' TPNs                  |
+      |       |ODUflex|    |                                           |
+      +-------+-------+----+-------------------------------------------+
+      | ODU4  |Any ODU|1-80|Flexible, != ANY other existing LO ODUs'   |
+      |       |       |    |TPNs                                       |
+      +-------+-------+----+-------------------------------------------+
+
+             Table 4: TPN Assignment Rules (1.25 Gbps TS Granularity)
+
+      Note that in the case of "Flexible", the value of TPN MAY not
+      correspond to the TS number as per [G709-2012].
+
+   Length: 12 bits
+
+      Indicates the number of bits of the Bit Map field, i.e., the total
+      number of TSs in the HO ODUk link.  The TS granularity, 1.25 Gbps
+      or 2.5 Gbps, may be derived by dividing the HO ODUk link's rate by
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 13]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+      the value of the Length field.  In the context of [G709-2012], the
+      values of 4 and 16 indicate a TS granularity of 2.5 Gbps, and the
+      values 2, 8, 32, and 80 indicate a TS granularity of 1.25 Gbps.
+
+      In the case of an ODUk mapped into OTUk, there is no need to
+      indicate which tributary slots will be used, so the Length field
+      MUST be set to 0.
+
+   Bit Map: variable
+
+      Indicates which tributary slots in the HO ODUk that the LO ODUj
+      will be multiplexed into.  The sequence of the Bit Map is
+      consistent with the sequence of the tributary slots in the HO
+      ODUk.  Each bit in the bit map represents the corresponding
+      tributary slot in the HO ODUk with a value of 1 or 0 indicating
+      whether the tributary slot will be used by the LO ODUj or not.
+
+   Padding Bits
+
+      Are added after the Bit Map to make the whole label a multiple of
+      four bytes if necessary.  Padding bits MUST be set to 0 and MUST
+      be ignored on receipt.
+
+6.2.  Procedures
+
+   The ingress node MUST generate a Path message and specify the OTN-TDM
+   Switching Type and corresponding G-PID in the
+   GENERALIZED_LABEL_REQUEST object, which MUST be processed as defined
+   in [RFC3473].
+
+   The ingress node of an LSP MAY include a Label ERO (Explicit Route
+   Object) subobject to indicate the label in each hop along the path.
+   Note that the TPN in the Label ERO subobject need not be assigned by
+   the ingress node.  When the TPN is assigned by a node, the node MUST
+   assign a valid TPN value and then put this value into the TPN field
+   of the GENERALIZED_LABEL object when receiving a Path message.
+
+   In order to create bidirectional LSP, the ingress node and upstream
+   node MUST generate an UPSTREAM_LABEL object on the outgoing interface
+   to indicate the reserved TSs of ODUk and the assigned TPN value in
+   the upstream direction.  This UPSTREAM_LABEL object is sent to the
+   downstream node via a Path massage for upstream resource reservation.
+
+   The ingress node or upstream node MAY generate a LABEL_SET object to
+   indicate which labels on the outgoing interface in the downstream
+   direction are acceptable.  The downstream node will restrict its
+   choice of labels, i.e., TS resource and TPN value, to one that is in
+   the LABEL_SET object.
+
+
+
+Zhang, et al.                Standards Track                   [Page 14]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   The ingress node or upstream node MAY also generate a SUGGESTED_LABEL
+   object to indicate the preference of TS resource and TPN value on the
+   outgoing interface in the downstream direction.  The downstream node
+   is not required to use the suggested labels; it may use another label
+   based on local decision and send it to the upstream node, as
+   described in [RFC3473].
+
+   When an upstream node receives a Resv message containing a
+   GENERALIZED_LABEL object with an OTN-TDM label, it MUST first
+   identify which ODU Signal Type is multiplexed or mapped into which
+   ODU Signal Type according to the Traffic Parameters and the IF_ID
+   RSVP_HOP object in the received message.
+
+   -  In the case of ODUj-to-ODUk multiplexing, the node MUST retrieve
+      the reserved tributary slots in the ODUk by its downstream
+      neighbor node according to the position of the bits that are set
+      to 1 in the Bit Map field.  The node determines the TS granularity
+      (according to the total TS number of the ODUk or pre-configured TS
+      granularity), so that the node can multiplex the ODUj into the
+      ODUk based on the TS granularity.  The node MUST also retrieve the
+      TPN value assigned by its downstream neighbor node from the label
+      and fill the TPN into the related MSI byte(s) in the OPUk overhead
+      in the data plane, so that the downstream neighbor node can check
+      whether the TPN received from the data plane is consistent with
+      the Expected MSI (ExMSI) and determine whether there is any
+      mismatch defect.
+
+   -  In the case of ODUk-to-OTUk mapping, the size of the Bit Map field
+      MUST be 0, and no additional procedure is needed.
+
+   When a downstream node or egress node receives a Path message
+   containing a GENERALIZED_LABEL_REQUEST object for setting up an ODUj
+   LSP from its upstream neighbor node, the node MUST generate an OTN-
+   TDM label according to the Signal Type of the requested LSP and the
+   available resources (i.e., available tributary slots of ODUk) that
+   will be reserved for the LSP and send the label to its upstream
+   neighbor node.
+
+   -  In the case of ODUj-to-ODUk multiplexing, the node MUST first
+      determine the size of the Bit Map field according to the Signal
+      Type and the tributary slot type of ODUk and then set the bits to
+      1 in the Bit Map field corresponding to the reserved tributary
+      slots.  The node MUST also assign a valid TPN, which MUST NOT
+      collide with other TPN values used by existing LO ODU connections
+      in the selected HO ODU link, and configure the Expected MSI
+      (ExMSI) using this TPN.  Then, the assigned TPN MUST be filled
+      into the label.
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 15]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   -  In the case of ODUk-to-OTUk mapping, the TPN field MUST be set to
+      0.  Bit Map information is not required and MUST NOT be included,
+      so the Length field MUST be set to 0 as well.
+
+6.2.1.  Notification on Label Error
+
+   When an upstream node receives a Resv message containing a
+   GENERALIZED_LABEL object with an OTN-TDM label, the node MUST verify
+   if the label is acceptable.  If the label is not acceptable, the node
+   MUST generate a ResvErr message with a "Routing problem/Unacceptable
+   label value" indication.  Per [RFC3473], the generated ResvErr
+   message MAY include an ACCEPTABLE_LABEL_SET object.  With the
+   exception of label semantics, a downstream node processing a received
+   ResvErr message and ACCEPTABLE_LABEL_SET object is not modified by
+   this document.
+
+   Similarly, when a downstream node receives a Path message containing
+   an UPSTREAM_LABEL object with an OTN-TDM label, the node MUST verify
+   if the label is acceptable.  If the label is not acceptable, the node
+   MUST generate a PathErr message with a "Routing problem/Unacceptable
+   label value" indication.  Per [RFC3473], the generated PathErr
+   message MAY include an ACCEPTABLE_LABEL_SET object.  With the
+   exception of label semantics, the upstream nodes processing a
+   received PathErr message and ACCEPTABLE_LABEL_SET object are not
+   modified by this document.
+
+   A received label SHALL be considered unacceptable when one of the
+   following cases occurs:
+
+   -  The received label doesn't conform to local policy;
+
+   -  An invalid value appears in the Length field;
+
+   -  The selected link only supports 2.5 Gbps TS granularity while the
+      Length field in the label along with ODUk Signal Type indicates
+      the 1.25 Gbps TS granularity;
+
+   -  The label includes an invalid TPN value that breaks the TPN
+      assignment rules; and
+
+   -  The indicated resources (i.e., the number of "1"s in the Bit Map
+      field) are inconsistent with the Traffic Parameters.
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 16]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+6.3.  Supporting Virtual Concatenation and Multiplication
+
+   Per [RFC6344], the Virtual Concatenation Groups (VCGs) can be created
+   using the One LSP approach or the Multiple LSPs approach.
+
+   In the case of the One LSP approach, the explicit ordered list of all
+   labels MUST reflect the order of VCG members, which is similar to
+   [RFC4328].  In the case of multiplexed virtually concatenated signals
+   (NVC > 1), the first label MUST indicate the components of the first
+   virtually concatenated signal; the second label MUST indicate the
+   components of the second virtually concatenated signal; and so on.
+   In the case of multiplication of multiplexed virtually concatenated
+   signals (MT > 1), the first label MUST indicate the components of the
+   first multiplexed virtually concatenated signal; the second label
+   MUST indicate components of the second multiplexed virtually
+   concatenated signal; and so on.
+
+   Support for Virtual Concatenation of ODU1, ODU2, and ODU3 Signal
+   Types, as defined by [RFC6344], is not modified by this document.
+   Virtual Concatenation of other Signal Types is not supported by
+   [G709-2012].
+
+   Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328].
+
+6.4.  Examples
+
+   The following examples are given in order to illustrate the label
+   format described in Section 6.1 of this document.
+
+   (1) ODUk-to-OTUk Mapping:
+
+   In this scenario, the downstream node along an LSP returns a label
+   indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the
+   corresponding OTUk.  The following example label indicates an ODU1
+   mapped into OTU1.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       TPN = 0         |   Reserved    |     Length = 0        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   (2) ODUj-to-ODUk Multiplexing:
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 17]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   In this scenario, this label indicates that an ODUj is multiplexed
+   into several tributary slots of OPUk and then mapped into OTUk.  Some
+   instances are shown as follows:
+
+   -  ODU0-to-ODU2 Multiplexing:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       TPN = 2         |   Reserved    |     Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 1 0 0 0 0 0 0|             Padding Bits (0)                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The label above indicates an ODU0 multiplexed into the second
+   tributary slot of ODU2, wherein there are 8 TSs in ODU2 (i.e., the
+   type of the tributary slot is 1.25 Gbps), and the TPN value is 2.
+
+   -  ODU1-to-ODU2 Multiplexing with 1.25 Gbps TS Granularity:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       TPN = 1         |   Reserved    |     Length = 8        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 1 0 1 0 0 0 0|             Padding Bits (0)                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The label above indicates an ODU1 multiplexed into the 2nd and the
+   4th tributary slots of ODU2, wherein there are 8 TSs in ODU2 (i.e.,
+   the type of the tributary slot is 1.25 Gbps), and the TPN value is 1.
+
+   -  ODU2 into ODU3 Multiplexing with 2.5 Gbps TS Granularity:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       TPN = 1         |   Reserved    |     Length = 16       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0|       Padding Bits (0)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The label above indicates an ODU2 multiplexed into the 2nd, 3rd, 5th,
+   and 7th tributary slots of ODU3, wherein there are 16 TSs in ODU3
+   (i.e., the type of the tributary slot is 2.5 Gbps), and the TPN value
+   is 1.
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 18]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+7.  Supporting Hitless Adjustment of ODUflex(GFP)
+
+   [G7044] describes the procedure of ODUflex(GFP) hitless resizing
+   using the Link Connection Resize (LCR) and Bandwidth Resize (BWR)
+   protocols in the OTN data plane.
+
+   For the control plane, signaling messages are REQUIRED to initiate
+   the adjustment procedure.  Sections 2.5 and 4.6.4 of [RFC3209]
+   describe how the Shared Explicit (SE) style is used in the Traffic
+   Engineering (TE) network for bandwidth increasing and decreasing,
+   which is still applicable for triggering the ODUflex(GFP) adjustment
+   procedure in the data plane.
+
+   Note that the SE style MUST be used at the beginning when creating a
+   resizable ODUflex connection (Signal Type = 21).  Otherwise an error
+   with Error Code "Conflicting reservation style" MUST be generated
+   when performing bandwidth adjustment.
+
+   -  Bandwidth Increasing
+
+      For the ingress node, in order to increase the bandwidth of an
+      ODUflex(GFP) connection, a Path message with SE style (keeping
+      Tunnel ID unchanged and assigning a new LSP ID) MUST be sent along
+      the path.
+
+      The ingress node will trigger the BWR protocol when successful
+      completion of LCR protocols on every hop after the Resv message is
+      processed.  On success of BWR, the ingress node SHOULD send a
+      PathTear message to delete the old control state (i.e., the
+      control state of the ODUflex(GFP) before resizing) on the control
+      plane.
+
+      A downstream node receiving a Path message with SE style compares
+      the old Traffic Parameters (stored locally) with the new one
+      carried in the Path message to determine the number of TSs to be
+      added.  After choosing and reserving new available TS(s), the
+      downstream node MUST send back a Resv message carrying both the
+      old and new GENERALIZED_LABEL objects in the SE flow descriptor.
+
+      An upstream neighbor receiving a Resv message with an SE flow
+      descriptor MUST determine which TS(s) is/are added and trigger the
+      LCR protocol between itself and its downstream neighbor node.
+
+   -  Bandwidth Decreasing
+
+      For the ingress node, a Path message with SE style SHOULD also be
+      sent for decreasing the ODUflex bandwidth.
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 19]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+      The ingress node will trigger the BWR protocol when successful
+      completion of LCR handshake on every hop after Resv message is
+      processed.  On success of BWR, the second step of LCR, i.e., link
+      connection decrease procedure will be started on every hop of the
+      connection.  After decreasing the bandwidth, the ingress node
+      SHOULD send a ResvErr message to tear down the old control state.
+
+      A downstream node receiving a Path message with SE style compares
+      the old Traffic Parameters with the new one carried in the Path
+      message to determine the number of TSs to be decreased.  After
+      choosing TSs to be decreased, the downstream node MUST send back a
+      Resv message carrying both the old and new GENERALIZED_LABEL
+      objects in the SE flow descriptor.
+
+      An upstream neighbor receiving a Resv message with an SE flow
+      descriptor MUST determine which TS(s) is/are decreased and trigger
+      the first step of the LCR protocol (i.e., LCR handshake) between
+      itself and its downstream neighbor node.
+
+8.  Operations, Administration, and Maintenance (OAM) Considerations
+
+   OTN OAM configuration could be done through either Network Management
+   Systems (NMSs) or the GMPLS control plane as defined in [TDM-OAM].
+   [RFC4783] SHOULD be used for communication of alarm information in
+   GMPLS-based OTN.
+
+   Management Information Bases (MIBs) may need be extended to read new
+   information (e.g., OTN-TDM Generalized Label and OTN-TDM
+   SENDER_TSPEC / FLOWSPEC) from the OTN devices.  This is outside the
+   scope of this document.
+
+   More information about the management aspects for GMPLS-based OTN,
+   refer to Section 5.7 of [RFC7062].
+
+9.  Control-Plane Backward-Compatibility Considerations
+
+   As described in [RFC7062], since [RFC4328] has been deployed in the
+   network for the nodes that support the 2001 revision of the G.709
+   specification, control-plane backward compatibility SHOULD be taken
+   into consideration.  More specifically:
+
+   o  Nodes supporting this document SHOULD support [RFC7138].
+
+   o  Nodes supporting this document MAY support [RFC4328] signaling.
+
+   o  A node supporting both sets of procedures (i.e., [RFC4328] and
+      this document) is not required to signal an LSP using both
+      procedures, i.e., to act as a signaling version translator.
+
+
+
+Zhang, et al.                Standards Track                   [Page 20]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   o  Ingress nodes that support both sets of procedures MAY select
+      which set of procedures to follow based on routing information or
+      local policy.
+
+   o  Per [RFC3473], nodes that do not support this document will
+      generate a PathErr message, with a "Routing problem/Switching
+      Type" indication.
+
+10.  Security Considerations
+
+   This document is a modification to [RFC3473] and [RFC4328]; it only
+   differs in specific information communicated.  As such, this document
+   introduces no new security considerations to the existing GMPLS
+   signaling protocols.  Refer to [RFC3473] and [RFC4328] for further
+   details of the specific security measures.  Additionally, [RFC5920]
+   provides an overview of security vulnerabilities and protection
+   mechanisms for the GMPLS control plane.
+
+11.  IANA Considerations
+
+   IANA has made the following assignments in the "Class Types or C-
+   Types - 9 FLOWSPEC" and "Class Types or C-Types - 12 SENDER_TSPEC"
+   section of the "Resource Reservation Protocol (RSVP) Parameters"
+   registry located at <http://www.iana.org/assignments/
+   rsvp-parameters>.
+
+      Value     Description         Reference
+      7         OTN-TDM             [RFC7139]
+
+   IANA maintains the "Generalized Multi-Protocol Label Switching
+   (GMPLS) Signaling Parameters" registry (see
+   <http://www.iana.org/assignments/gmpls-sig-parameters>).  The
+   "Generalized PIDs (G-PID)" subregistry is included in this registry,
+   which is extended and updated by this document as detailed below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 21]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+      Value Type                            Technology      Reference
+      ===== ======================          ==========      =========
+      47    G.709 ODU-2.5G                  G.709 ODUk      [RFC4328]
+            (IANA updated the Type field)                   [RFC7139]
+      56    SBCON/ESCON                     G.709 ODUk,     [RFC4328]
+            (IANA updated the Type field)   Lambda, Fiber   [RFC7139]
+      59    Framed GFP                      G.709 ODUk      [RFC7139]
+      60    STM-1                           G.709 ODUk      [RFC7139]
+      61    STM-4                           G.709 ODUk      [RFC7139]
+      62    InfiniBand                      G.709 ODUflex   [RFC7139]
+      63    SDI (Serial Digital Interface)  G.709 ODUk      [RFC7139]
+      64    SDI/1.001                       G.709 ODUk      [RFC7139]
+      65    DVB_ASI                         G.709 ODUk      [RFC7139]
+      66    G.709 ODU-1.25G                 G.709 ODUk      [RFC7139]
+      67    G.709 ODU-any                   G.709 ODUk      [RFC7139]
+      68    Null Test                       G.709 ODUk      [RFC7139]
+      69    Random Test                     G.709 ODUk      [RFC7139]
+      70    64B/66B GFP-F Ethernet          G.709 ODUk      [RFC7139]
+
+   The new G-PIDs are shown in the TC MIB managed by IANA at
+   <https://www.iana.org/assignments/ianagmplstc-mib> as follows:
+
+      g709FramedGFP(59),
+      g709STM1(60),
+      g709STM4(61),
+      g709InfiniBand(62),
+      g709SDI(63),
+      g709SDI1point001(64),
+      g709DVBASI(65),
+      g709ODU1point25G(66),
+      g709ODUAny(67),
+      g709NullTest(68),
+      g709RandomTest(69),
+      g709GFPFEthernet(70)
+
+   Note that IANA has not changed the names of the objects in this MIB
+   module with the values 47 and 56.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 22]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   IANA has defined an "OTN Signal Type" subregistry to the "Generalized
+   Multi-Protocol Label Switching (GMPLS) Signaling Parameters"
+   registry:
+
+      Value    Signal Type                           Reference
+      -----    -----------                           ---------
+      0        Not significant                       [RFC4328]
+      1        ODU1 (i.e., 2.5 Gbps)                 [RFC4328]
+      2        ODU2 (i.e., 10 Gbps)                  [RFC4328]
+      3        ODU3 (i.e., 40 Gbps)                  [RFC4328]
+      4        ODU4 (i.e., 100 Gbps)                 [RFC7139]
+      5        Unassigned                            [RFC4328]
+      6        Och at 2.5 Gbps                       [RFC4328]
+      7        OCh at 10 Gbps                        [RFC4328]
+      8        OCh at 40 Gbps                        [RFC4328]
+      9        OCh at 100 Gbps                       [RFC7139]
+      10       ODU0 (i.e., 1.25 Gbps)                [RFC7139]
+      11       ODU2e (i.e., 10 Gbps for FC1200       [RFC7139]
+               and GE LAN)
+      12-19    Unassigned                            [RFC7139]
+      20       ODUflex(CBR) (i.e., 1.25*N Gbps)      [RFC7139]
+      21       ODUflex(GFP-F), resizable             [RFC7139]
+               (i.e., 1.25*N Gbps)
+      22       ODUflex(GFP-F), non-resizable         [RFC7139]
+               (i.e., 1.25*N Gbps)
+      23-255   Unassigned                            [RFC7139]
+
+   New values are to be assigned via Standards Action as defined in
+   [RFC5226].
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205]   Braden, R., Ed., 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.
+
+
+
+Zhang, et al.                Standards Track                   [Page 23]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   [RFC3471]   Berger, L., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Functional Description", RFC
+               3471, January 2003.
+
+   [RFC3473]   Berger, L., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Resource ReserVation
+               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+               3473, January 2003.
+
+   [RFC4328]   Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Extensions for G.709 Optical
+               Transport Networks Control", RFC 4328, January 2006.
+
+   [RFC4506]   Eisler, M., Ed., "XDR: External Data Representation
+               Standard", STD 67, RFC 4506, May 2006.
+
+   [RFC4783]   Berger, L., Ed., "GMPLS - Communication of Alarm
+               Information", RFC 4783, December 2006.
+
+   [RFC6344]   Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van
+               Helvoort, "Operating Virtual Concatenation (VCAT) and the
+               Link Capacity Adjustment Scheme (LCAS) with Generalized
+               Multi-Protocol Label Switching (GMPLS)", RFC 6344, August
+               2011.
+
+   [RFC7138]   Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
+               J. Drake, "Traffic Engineering Extensions to OSPF for
+               GMPLS Control of Evolving G.709 Optical Transport
+               Networks", RFC 7138, March 2014.
+
+   [G709-2012] ITU-T, "Interfaces for the Optical Transport Network
+               (OTN)", G.709/Y.1331 Recommendation, February 2012.
+
+   [G7044]     ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347,
+               October 2011.
+
+   [G7041]     ITU-T, "Generic framing procedure", G.7041/Y.1303, April
+               2011.
+
+   [IEEE]      "IEEE Standard for Binary Floating-Point Arithmetic",
+               ANSI/IEEE Standard 754-1985, Institute of Electrical and
+               Electronics Engineers, August 1985.
+
+12.2.  Informative References
+
+   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+               May 2008.
+
+
+
+Zhang, et al.                Standards Track                   [Page 24]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   [RFC5920]   Fang, L., Ed., "Security Framework for MPLS and GMPLS
+               Networks", RFC 5920, July 2010.
+
+   [RFC7062]   Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
+               Ceccarelli, "Framework for GMPLS and PCE Control of G.709
+               Optical Transport Networks", RFC 7062, November 2013.
+
+   [RFC7096]   Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed.,
+               Caviglia, D., Zhang, F., and D. Li, "Evaluation of
+               Existing GMPLS Encoding against G.709v3 Optical Transport
+               Networks (OTNs)", RFC 7096, January 2014.
+
+   [TDM-OAM]   Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for
+               SONET/SDH and OTN OAM Configuration", Work in Progress,
+               November 2013.
+
+13. Contributors
+
+   Yi Lin
+   Huawei Technologies
+   F3-5-B R&D Center, Huawei Base
+   Bantian, Longgang District
+   Shenzhen 518129
+   P.R. China
+   Phone: +86-755-28972914
+   EMail: yi.lin@huawei.com
+
+   Yunbin Xu
+   China Academy of Telecommunication Research of MII
+   11 Yue Tan Nan Jie
+   Beijing
+   P.R. China
+   Phone: +86-10-68094134
+   EMail: xuyunbin@mail.ritt.com.cn
+
+   Pietro Grandi
+   Alcatel-Lucent
+   Optics CTO
+   Via Trento 30 20059 Vimercate
+   Milano
+   Italy
+   Phone: +39 039 6864930
+   EMail: pietro_vittorio.grandi@alcatel-lucent.it
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 25]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+   Diego Caviglia
+   Ericsson
+   Via A. Negrone 1/A
+   Genova - Sestri Ponente
+   Italy
+   EMail: diego.caviglia@ericsson.com
+
+   Rajan Rao
+   Infinera Corporation
+   169, Java Drive
+   Sunnyvale, CA 94089
+   USA
+   EMail: rrao@infinera.com
+
+   John E Drake
+   Juniper
+   EMail: jdrake@juniper.net
+
+   Igor Bryskin
+   Adva Optical
+   EMail: IBryskin@advaoptical.com
+
+   Jonathan Sadler, Tellabs
+   EMail: jonathan.sadler@tellabs.com
+
+   Kam LAM, Alcatel-Lucent
+   EMail: kam.lam@alcatel-lucent.com
+
+   Francesco Fondelli, Ericsson
+   EMail: francesco.fondelli@ericsson.com
+
+   Lyndon Ong, Ciena
+   EMail: lyong@ciena.com
+
+   Biao Lu, infinera
+   EMail: blu@infinera.com
+
+14.  Acknowledgments
+
+   The authors would like to thank Lou Berger, Deborah Brungard, and
+   Xiaobing Zi for their useful comments regarding this document.
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 26]
+
+RFC 7139               GMPLS Extensions for G.709             March 2014
+
+
+Authors' Addresses
+
+   Fatai Zhang (editor)
+   Huawei Technologies
+   F3-5-B R&D Center, Huawei Base
+   Bantian, Longgang District
+   Shenzhen 518129
+   P.R. China
+   Phone: +86-755-28972912
+   EMail: zhangfatai@huawei.com
+
+
+   Guoying Zhang
+   China Academy of Telecommunication Research of MII
+   11 Yue Tan Nan Jie
+   Beijing
+   P.R. China
+   Phone: +86-10-68094272
+   EMail: zhangguoying@mail.ritt.com.cn
+
+
+   Sergio Belotti
+   Alcatel-Lucent
+   Optics CTO
+   Via Trento 30 20059 Vimercate
+   Milano
+   Italy
+   Phone: +39 039 6863033
+   EMail: sergio.belotti@alcatel-lucent.it
+
+
+   Daniele Ceccarelli
+   Ericsson
+   Via A. Negrone 1/A
+   Genova - Sestri Ponente
+   Italy
+   EMail: daniele.ceccarelli@ericsson.com
+
+
+   Khuzema Pithewan
+   Infinera Corporation
+   169, Java Drive
+   Sunnyvale, CA 94089
+   USA
+   EMail: kpithewan@infinera.com
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 27]
+