doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc7062.txt b/doc/rfc/rfc7062.txt
new file mode 100644
index 0000000..47d0d13
--- /dev/null
+++ b/doc/rfc/rfc7062.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     F. Zhang, Ed.
+Request for Comments: 7062                                         D. Li
+Category: Informational                                           Huawei
+ISSN: 2070-1721                                                    H. Li
+                                                                    CMCC
+                                                              S. Belotti
+                                                          Alcatel-Lucent
+                                                           D. Ceccarelli
+                                                                Ericsson
+                                                           November 2013
+
+
+                 Framework for GMPLS and PCE Control of
+                    G.709 Optical Transport Networks
+
+Abstract
+
+   This document provides a framework to allow the development of
+   protocol extensions to support Generalized Multi-Protocol Label
+   Switching (GMPLS) and Path Computation Element (PCE) control of
+   Optical Transport Networks (OTNs) as specified in ITU-T
+   Recommendation G.709 as published in 2012.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see 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/rfc7062.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 1]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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. G.709 Optical Transport Network .................................4
+      3.1. OTN Layer Network ..........................................5
+           3.1.1. Client Signal Mapping ...............................6
+           3.1.2. Multiplexing ODUj onto Links ........................7
+                  3.1.2.1. Structure of MSI Information ...............9
+   4. Connection Management in OTN ...................................10
+      4.1. Connection Management of the ODU ..........................11
+   5. GMPLS/PCE Implications .........................................13
+      5.1. Implications for Label Switched Path (LSP) Hierarchy ......13
+      5.2. Implications for GMPLS Signaling ..........................14
+      5.3. Implications for GMPLS Routing ............................16
+      5.4. Implications for Link Management Protocol .................18
+      5.5. Implications for Control-Plane Backward Compatibility .....19
+      5.6. Implications for Path Computation Elements ................20
+      5.7. Implications for Management of GMPLS Networks .............20
+   6. Data-Plane Backward Compatibility Considerations ...............21
+   7. Security Considerations ........................................21
+   8. Acknowledgments ................................................22
+   9. Contributors ...................................................22
+   10. References ....................................................23
+      10.1. Normative References .....................................23
+      10.2. Informative References ...................................24
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 2]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+1.  Introduction
+
+   Optical Transport Networks (OTNs) have become a mainstream layer 1
+   technology for the transport network.  Operators want to introduce
+   control-plane capabilities based on GMPLS to OTN to realize the
+   benefits associated with a high-function control plane (e.g.,
+   improved network resiliency, resource usage efficiency, etc.).
+
+   GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass Time
+   Division Multiplexing (TDM) networks (e.g., Synchronous Optical
+   NETwork (SONET) / Synchronous Digital Hierarchy (SDH), Plesiochronous
+   Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching
+   optical networks, and spatial switching (e.g., incoming port or fiber
+   to outgoing port or fiber).  The GMPLS architecture is provided in
+   [RFC3945], signaling function and Resource Reservation Protocol -
+   Traffic Engineering (RSVP-TE) extensions are described in [RFC3471]
+   and [RFC3473], routing and Open Shortest Path First (OSPF) extensions
+   are described in [RFC4202] and [RFC4203], and the Link Management
+   Protocol (LMP) is described in [RFC4204].
+
+   The GMPLS signaling extensions defined in [RFC4328] provide the
+   mechanisms for basic GMPLS control of OTN based on the 2001 revision
+   of the G.709 specification.  The 2012 revision of the G.709
+   specification, [G709-2012], includes new features, for example,
+   various multiplexing structures, two types of Tributary Slots (TSs)
+   (i.e., 1.25 Gbps and 2.5G bps), and extension of the Optical channel
+   Data Unit-j (ODUj) definition to include the ODUflex function.
+
+   This document reviews relevant aspects of OTN technology evolution
+   that affect the GMPLS control-plane protocols and examines why and
+   how to update the mechanisms described in [RFC4328].  This document
+   additionally provides a framework for GMPLS control of OTN and
+   includes a discussion of the implications for the use of the PCE
+   [RFC4655].
+
+   For the purposes of the control plane, the OTN can be considered to
+   be comprised of ODU and wavelength (Optical Channel (OCh)) layers.
+   This document focuses on the control of the ODU layer, with control
+   of the wavelength layer considered out of the scope.  Please refer to
+   [RFC6163] for further information about the wavelength layer.
+
+2.  Terminology
+
+   OTN: Optical Transport Network
+
+   OPU: Optical Channel Payload Unit
+
+   ODU: Optical Channel Data Unit
+
+
+
+Zhang, et al.                 Informational                     [Page 3]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   OTU: Optical Channel Transport Unit
+
+   OMS: Optical Multiplex Section
+
+   MSI: Multiplex Structure Identifier
+
+   TPN: Tributary Port Number
+
+   LO ODU: Lower Order ODU.  The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, or
+   flex) represents the container transporting a client of the OTN that
+   is either directly mapped into an OTUk (k = j) or multiplexed into a
+   server HO ODUk (k > j) container.
+
+   HO ODU: Higher Order ODU.  The HO ODUk (k can be 1, 2, 2e, 3, or 4)
+   represents the entity transporting a multiplex of LO ODUj tributary
+   signals in its OPUk area.
+
+   ODUflex: Flexible ODU.  A flexible ODUk can have any bit rate and a
+   bit rate tolerance of +/-100 ppm (parts per million).
+
+   In general, throughout this document, "ODUj" is used to refer to ODU
+   entities acting as an LO ODU, and "ODUk" is used to refer to ODU
+   entities being used as an HO ODU.
+
+3.  G.709 Optical Transport Network
+
+   This section provides an informative overview of the aspects of the
+   OTN impacting control-plane protocols.  This overview is based on the
+   ITU-T Recommendations that contain the normative definition of the
+   OTN.  Technical details regarding OTN architecture and interfaces are
+   provided in the relevant ITU-T Recommendations.
+
+   Specifically, [G872-2012] describes the functional architecture of
+   optical transport networks providing optical signal transmission,
+   multiplexing, routing, supervision, performance assessment, and
+   network survivability.  The legacy OTN referenced by [RFC4328]
+   defines the interfaces of the optical transport network to be used
+   within and between subnetworks of the optical network.  With the
+   evolution and deployment of OTN technology, many new features have
+   been specified in ITU-T recommendations, including, for example, new
+   ODU0, ODU2e, ODU4, and ODUflex containers as described in
+   [G709-2012].
+
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 4]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+3.1.  OTN Layer Network
+
+   The simplified signal hierarchy of OTN is shown in Figure 1, which
+   illustrates the layers that are of interest to the control plane.
+   Other layers below OCh (e.g., Optical Transmission Section (OTS)) are
+   not included in this figure.  The full signal hierarchy is provided
+   in [G709-2012].
+
+                               Client signal
+                                    |
+                                   ODUj
+                                    |
+                                 OTU/OCh
+                                   OMS
+
+                   Figure 1: Basic OTN Signal Hierarchy
+
+   Client signals are mapped into ODUj containers.  These ODUj
+   containers are multiplexed onto the OTU/OCh.  The individual OTU/OCh
+   signals are combined in the OMS using Wavelength Division
+   Multiplexing (WDM), and this aggregated signal provides the link
+   between the nodes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 5]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+3.1.1.  Client Signal Mapping
+
+   The client signals are mapped into an LO ODUj.  The current values of
+   j defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, and flex.  The
+   approximate bit rates of these signals are defined in [G709-2012] and
+   are reproduced in Tables 1 and 2.
+
+   +-----------------------+-----------------------------------+
+   |       ODU Type        |       ODU nominal bit rate        |
+   +-----------------------+-----------------------------------+
+   |         ODU0          |          1,244,160 Kbps           |
+   |         ODU1          |     239/238 x 2,488,320 Kbps      |
+   |         ODU2          |     239/237 x 9,953,280 Kbps      |
+   |         ODU3          |     239/236 x 39,813,120 Kbps     |
+   |         ODU4          |     239/227 x 99,532,800 Kbps     |
+   |         ODU2e         |     239/237 x 10,312,500 Kbps     |
+   |                       |                                   |
+   |     ODUflex for       |                                   |
+   |Constant Bit Rate (CBR)| 239/238 x client signal bit rate  |
+   |    Client signals     |                                   |
+   |                       |                                   |
+   |   ODUflex for Generic |                                   |
+   |   Framing Procedure   |        Configured bit rate        |
+   |   - Framed (GFP-F)    |                                   |
+   | Mapped client signal  |                                   |
+   +-----------------------+-----------------------------------+
+
+                     Table 1: ODU Types and Bit Rates
+
+   NOTE: The nominal ODUk rates are approximately: 2,498,775.126 Kbps
+   (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3),
+   104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 6]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   +-----------------------+-----------------------------------+
+   |      ODU Type         |       ODU bit rate tolerance      |
+   +-----------------------+-----------------------------------+
+   |        ODU0           |            +/-20 ppm              |
+   |        ODU1           |            +/-20 ppm              |
+   |        ODU2           |            +/-20 ppm              |
+   |        ODU3           |            +/-20 ppm              |
+   |        ODU4           |            +/-20 ppm              |
+   |        ODU2e          |            +/-100 ppm             |
+   |                       |                                   |
+   |   ODUflex for CBR     |                                   |
+   |   Client signals      |            +/-100 ppm             |
+   |                       |                                   |
+   |  ODUflex for GFP-F    |                                   |
+   | Mapped client signal  |            +/-100 ppm             |
+   +-----------------------+-----------------------------------+
+
+                     Table 2: ODU Types and Tolerance
+
+   One of two options is for mapping client signals into ODUflex
+   depending on the client signal type:
+
+   -  Circuit clients are proportionally wrapped.  Thus, the bit rate is
+      defined by the client signal, and the tolerance is fixed to +/-100
+      ppm.
+
+   -  Packet clients are mapped using the Generic Framing Procedure
+      (GFP).  [G709-2012] recommends that the ODUflex(GFP) will fill an
+      integral number of tributary slots of the smallest HO ODUk path
+      over which the ODUflex(GFP) may be carried, and the tolerance
+      should be +/-100 ppm.
+
+   Note that additional information on G.709 client mapping can be found
+   in [G7041].
+
+3.1.2.  Multiplexing ODUj onto Links
+
+   The links between the switching nodes are provided by one or more
+   wavelengths.  Each wavelength carries one OCh, which carries one OTU,
+   which carries one ODU.  Since all of these signals have a 1:1:1
+   relationship, we only refer to the OTU for clarity.  The ODUjs are
+   mapped into the TSs (Tributary Slots) of the OPUk.  Note that in the
+   case where j=k, the ODUj is mapped into the OTU/OCh without
+   multiplexing.
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 7]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   The initial versions of G.709 referenced by [RFC4328] only provided a
+   single TS granularity, nominally 2.5 Gbps.  [G709-2012] added an
+   additional TS granularity, nominally 1.25 Gbps.  The number and type
+   of TS provided by each of the currently identified OTUk are provided
+   below:
+
+             Tributary Slot Granularity
+                2.5 Gbps     1.25 Gbps           Nominal Bit Rate
+     OTU1         1             2                  2.5 Gbps
+     OTU2         4             8                   10 Gbps
+     OTU3        16            32                   40 Gbps
+     OTU4        --            80                  100 Gbps
+
+   To maintain backward compatibility while providing the ability to
+   interconnect nodes that support a 1.25 Gbps TS at one end of a link
+   and a 2.5 Gbps TS at the other, [G709-2012] requires 'new' equipment
+   to fall back to the use of a 2.5 Gbps TS when connected to legacy
+   equipment.  This information is carried in band by the payload type.
+
+   The actual bit rate of the TS in an OTUk depends on the value of k.
+   Thus, the number of TSs occupied by an ODUj may vary depending on the
+   values of j and k.  For example, an ODU2e uses 9 TSs in an OTU3 but
+   only 8 in an OTU4.  Examples of the number of TSs used for various
+   cases are provided below (referring to Tables 7-9 of [G709-2012]):
+
+   -  ODU0 into ODU1, ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
+      granularity
+      o  ODU0 occupies 1 of the 2, 8, 32, or 80 TSs for ODU1, ODU2,
+         ODU3, or ODU4
+
+   -  ODU1 into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
+      granularity
+      o  ODU1 occupies 2 of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4
+
+   -  ODU1 into ODU2 or ODU3 multiplexing with 2.5 Gbps TS granularity
+      o  ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3
+
+   -  ODU2 into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity
+      o  ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4
+
+   -  ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity
+      o  ODU2 occupies 4 of the 16 TSs for ODU3
+
+   -  ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity
+      o  ODU3 occupies 31 of the 80 TSs for ODU4
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 8]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   -  ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
+      granularity
+      o  ODUflex occupies n of the 8, 32, or 80 TSs for ODU2, ODU3, or
+         ODU4 (n <= Total TS number of ODUk)
+
+   -  ODU2e into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity
+      o  ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for
+         ODU4
+
+   In general, the mapping of an ODUj (including ODUflex) into a
+   specific OTUk TS is determined locally, and it can also be explicitly
+   controlled by a specific entity (e.g., head end or Network Management
+   System (NMS)) through Explicit Label Control [RFC3473].
+
+3.1.2.1.  Structure of MSI Information
+
+   When multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the
+   information that has to be transported in-band in order to allow for
+   correct demultiplexing.  This information, known as MSI, is
+   transported in the OPUk overhead and is local to each link.  In case
+   of bidirectional paths, the association between the TPN and TS must
+   be the same in both directions.
+
+   The MSI information is organized as a set of entries, with one entry
+   for each HO ODUj TS.  The information carried by each entry is:
+
+   -  Payload Type: the type of the transported payload.
+
+   -  TPN: the port number of the ODUj transported by the HO ODUk.  The
+      TPN is the same for all the TSs assigned to the transport of the
+      same ODUj instance.
+
+   For example, an ODU2 carried by an HO ODU3 is described by 4 entries
+   in the OPU3 overhead when the TS granularity is 2.5 Gbps, and by 8
+   entries when the TS granularity is 1.25 Gbps.
+
+   On each node and on every link, two MSI values have to be provisioned
+   (referring to [G798]):
+
+   -  The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,
+      OPU3) overhead by the source of the HO ODUk trail.
+
+   -  The Expected MSI (ExMSI) information that is used to check the
+      Accepted MSI (AcMSI) information.  The AcMSI information is the
+      MSI valued received in-band, after a three-frame integration.
+
+
+
+
+
+
+Zhang, et al.                 Informational                     [Page 9]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   As described in [G798], the sink of the HO ODU trail checks the
+   complete content of the AcMSI information against the ExMSI.  If the
+   AcMSI is different from the ExMSI, then the traffic is dropped, and a
+   payload mismatch alarm is generated.
+
+   Provisioning of TPN can be performed by either a network management
+   system or control plane.  In the last case, the control plane is also
+   responsible for negotiating the provisioned values on a link-by-link
+   basis.
+
+4.  Connection Management in OTN
+
+   OTN-based connection management is concerned with controlling the
+   connectivity of ODU paths and OCh.  This document focuses on the
+   connection management of ODU paths.  The management of OCh paths is
+   described in [RFC6163].
+
+   While [G872-2001] considered the ODU to be a set of layers in the
+   same way as SDH has been modeled, recent ITU-T OTN architecture
+   progress [G872-2012] includes an agreement to model the ODU as a
+   single-layer network with the bit rate as a parameter of links and
+   connections.  This allows the links and nodes to be viewed in a
+   single topology as a common set of resources that are available to
+   provide ODUj connections independent of the value of j.  Note that
+   when the bit rate of ODUj is less than the server bit rate, ODUj
+   connections are supported by HO ODU (which has a one-to-one
+   relationship with the OTU).
+
+   From an ITU-T perspective, the ODU connection topology is represented
+   by that of the OTU link layer, which has the same topology as that of
+   the OCh layer (independent of whether the OTU supports an HO ODU,
+   where multiplexing is utilized, or an LO ODU in the case of direct
+   mapping).
+
+   Thus, the OTU and OCh layers should be visible in a single
+   topological representation of the network, and from a logical
+   perspective, the OTU and OCh may be considered as the same logical,
+   switchable entity.
+
+   Note that the OTU link-layer topology may be provided via various
+   infrastructure alternatives, including point-to-point optical
+   connections, optical connections fully in the optical domain, and
+   optical connections involving hybrid sub-lambda/lambda nodes
+   involving 3R, etc.  See [RFC6163] for additional information.
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 10]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+4.1.  Connection Management of the ODU
+
+   An LO ODUj can be either mapped into the OTUk signal (j = k) or
+   multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
+   mapped into an OCh.
+
+   From the perspective of the control plane, there are two kinds of
+   network topology to be considered.
+
+   (1) ODU layer
+
+   In this case, the ODU links are presented between adjacent OTN nodes,
+   as illustrated in Figure 2.  In this layer, there are ODU links with
+   a variety of TSs available, and nodes that are Optical Digital Cross
+   Connects (ODXCs).  LO ODU connections can be set up based on the
+   network topology.
+
+                  Link #5       +--+---+--+        Link #4
+     +--------------------------|         |--------------------------+
+     |                          |  ODXC   |                          |
+     |                          +---------+                          |
+     |                             Node E                            |
+     |                                                               |
+   +-++---+--+        +--+---+--+        +--+---+--+        +--+---+-++
+   |         |Link #1 |         |Link #2 |         |Link #3 |         |
+   |         |--------|         |--------|         |--------|         |
+   |  ODXC   |        |  ODXC   |        |  ODXC   |        |  ODXC   |
+   +---------+        +---------+        +---------+        +---------+
+      Node A             Node B              Node C            Node D
+
+        Figure 2: Example Topology for LO ODU Connection Management
+
+   If an ODUj connection is requested between Node C and Node E,
+   routing/path computation must select a path that has the required
+   number of TSs available and that offers the lowest cost.  Signaling
+   is then invoked to set up the path and to provide the information
+   (e.g., selected TSs) required by each transit node to allow the
+   configuration of the ODUj-to-OTUk mapping (j = k) or multiplexing (j
+   < k) and demapping (j = k) or demultiplexing (j < k).
+
+   (2) ODU layer with OCh switching capability
+
+   In this case, the OTN nodes interconnect with wavelength switched
+   nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM) or
+   Optical Cross-Connect (OXC)) that are capable of OCh switching; this
+   is illustrated in Figures 3 and 4.  There are the ODU layer and the
+   OCh layer, so it is simply a Multi-Layer Network (MLN) (see
+
+
+
+
+Zhang, et al.                 Informational                    [Page 11]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   [RFC6001]).  OCh connections may be created on demand, which is
+   described in Section 5.1.
+
+   In this case, an operator may choose to allow the underlying OCh
+   layer to be visible to the ODU routing/path computation process, in
+   which case the topology would be as shown in Figure 4.  In Figure 3,
+   however, a cloud representing OCh-capable switching nodes is
+   represented.  In Figure 3, the operator choice is to hide the real
+   OCh-layer network topology.
+
+                                Node E
+         Link #5              +--------+       Link #4
+     +------------------------|        |------------------------+
+     |                          ------                          |
+     |                       //        \\                       |
+     |                      ||          ||                      |
+     |                      | OCh domain |                      |
+   +-+-----+        +------ ||          || ------+        +-----+-+
+   |       |        |        \\        //        |        |       |
+   |       |Link #1 |          --------          |Link #3 |       |
+   |       +--------+         |        |         +--------+       +
+   | ODXC  |        |  ODXC   +--------+  ODXC   |        | ODXC  |
+   +-------+        +---------+Link #2 +---------+        +-------+
+     Node A            Node B             Node C            Node D
+
+      Figure 3: OCh Hidden Topology for LO ODU Connection Management
+
+           Link #5            +---------+            Link #4
+     +------------------------|         |-----------------------+
+     |                   +----| ODXC    |----+                  |
+     |                 +-++   +---------+   ++-+                |
+     |         Node f  |  |     Node E      |  |  Node g        |
+     |                 +-++                 ++-+                |
+     |                   |       +--+        |                  |
+   +-+-----+        +----+----+--|  |--+-----+---+        +-----+-+
+   |       |Link #1 |         |  +--+  |         |Link #3 |       |
+   |       +--------+         | Node h |         +--------+       |
+   | ODXC  |        | ODXC    +--------+ ODXC    |        | ODXC  |
+   +-------+        +---------+ Link #2+---------+        +-------+
+     Node A            Node B            Node C             Node D
+
+
+     Figure 4: OCh Visible Topology for LO ODUj Connection Management
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 12]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   In Figure 4, the cloud in the previous figure is substituted by the
+   real topology.  The nodes f, g, and h are nodes with OCh switching
+   capability.
+
+   In the examples (i.e., Figures 3 and 4), we have considered the case
+   in which LO ODUj connections are supported by an OCh connection and
+   the case in which the supporting underlying connection can also be
+   made by a combination of HO ODU/OCh connections.
+
+   In this case, the ODU routing/path selection process will request an
+   HO ODU/OCh connection between node C and node E from the OCh domain.
+   The connection will appear at the ODU level as a Forwarding
+   Adjacency, which will be used to create the ODU connection.
+
+5.  GMPLS/PCE Implications
+
+   The purpose of this section is to provide a set of requirements to be
+   evaluated for extensions of the current GMPLS protocol suite and the
+   PCE applications and protocols to encompass OTN enhancements and
+   connection management.
+
+5.1.  Implications for Label Switched Path (LSP) Hierarchy
+
+   The path computation for an ODU connection request is based on the
+   topology of the ODU layer.
+
+   The OTN path computation can be divided into two layers.  One layer
+   is OCh/OTUk; the other is ODUj.  [RFC4206] and [RFC6107] define the
+   mechanisms to accomplish creating the hierarchy of LSPs.  The LSP
+   management of multiple layers in OTN can follow the procedures
+   defined in [RFC4206], [RFC6001], and [RFC6107].
+
+   As discussed in Section 4, the route path computation for OCh is in
+   the scope of the Wavelength Switched Optical Network (WSON)
+   [RFC6163].  Therefore, this document only considers the ODU layer for
+   an ODU connection request.
+
+   The LSP hierarchy can also be applied within the ODU layers.  One of
+   the typical scenarios for ODU layer hierarchy is to maintain
+   compatibility with introducing new [G709-2012] services (e.g., ODU0
+   and ODUflex) into a legacy network configuration (i.e., the legacy
+   OTN referenced by [RFC4328]).  In this scenario, it may be necessary
+   to consider introducing hierarchical multiplexing capability in
+   specific network transition scenarios.  One method for enabling
+   multiplexing hierarchy is by introducing dedicated boards in a few
+   specific places in the network and tunneling these new services
+   through the legacy containers (ODU1, ODU2, ODU3), thus postponing the
+   need to upgrade every network element to [G709-2012] capabilities.
+
+
+
+Zhang, et al.                 Informational                    [Page 13]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   In such cases, one ODUj connection can be nested into another ODUk
+   (j<k) connection, which forms the LSP hierarchy in the ODU layer.
+   The creation of the outer ODUk connection can be triggered via
+   network planning or by the signaling of the inner ODUj connection.
+   For the former case, the outer ODUk connection can be created in
+   advance based on network planning.  For the latter case, the multi-
+   layer network signaling described in [RFC4206], [RFC6107], and
+   [RFC6001] (including related modifications, if needed) is relevant to
+   create the ODU connections with multiplexing hierarchy.  In both
+   cases, the outer ODUk connection is advertised as a Forwarding
+   Adjacency (FA).
+
+5.2.  Implications for GMPLS Signaling
+
+   The signaling function and RSVP-TE extensions are described in
+   [RFC3471] and [RFC3473].  For OTN-specific control, [RFC4328] defines
+   signaling extensions to support control for the legacy G.709 Optical
+   Transport Networks.
+
+   As described in Section 3, [G709-2012] introduced some new features
+   that include the ODU0, ODU2e, ODU4, and ODUflex containers.  The
+   mechanisms defined in [RFC4328] do not support such new OTN features,
+   and protocol extensions will be necessary to allow them to be
+   controlled by a GMPLS control plane.
+
+   [RFC4328] defines the LSP Encoding Type, the Switching Type, and the
+   Generalized Protocol Identifier (Generalized-PID) constituting the
+   common part of the Generalized Label Request.  The G.709 traffic
+   parameters are also defined in [RFC4328].  In addition, the following
+   signaling aspects not included in [RFC4328] should be considered:
+
+   -  Support for specifying new signal types and related traffic
+      information
+
+      The traffic parameters should be extended in a signaling message
+      to support the new ODUj, including:
+
+      -  ODU0
+      -  ODU2e
+      -  ODU4
+      -  ODUflex
+
+      For the ODUflex signal type, the bit rate must be carried
+      additionally in the traffic parameter to set up an ODUflex
+      connection.
+
+      For other ODU signal types, the bit rates and tolerances are fixed
+      and can be deduced from the signal types.
+
+
+
+Zhang, et al.                 Informational                    [Page 14]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   -  Support for LSP setup using different TS granularity
+
+      The signaling protocol should be able to identify the TS
+      granularity (i.e., the 2.5 Gbps TS granularity and the new 1.25
+      Gbps TS granularity) to be used for establishing a Hierarchical
+      LSP that will be used to carry service LSP(s) requiring a specific
+      TS granularity.
+
+   -  Support for LSP setup of new ODUk/ODUflex containers with related
+      mapping and multiplexing capabilities
+
+      A new label format must be defined to carry the exact TS's
+      allocation information related to the extended mapping and
+      multiplexing hierarchy (for example, ODU0 into ODU2 multiplexing
+      (with 1.25 Gbps TS granularity)), in order to set up the ODU
+      connection.
+
+   -  Support for TPN allocation and negotiation
+
+      TPN needs to be configured as part of the MSI information (see
+      more information in Section 3.1.2.1).  A signaling mechanism must
+      be identified to carry TPN information if the control plane is
+      used to configure MSI information.
+
+   -  Support for ODU Virtual Concatenation (VCAT) and Link Capacity
+      Adjustment Scheme (LCAS)
+
+      GMPLS signaling should support the creation of Virtual
+      Concatenation of an ODUk signal with k=1, 2, 3.  The signaling
+      should also support the control of dynamic capacity changing of a
+      VCAT container using LCAS ([G7042]).  [RFC6344] has a clear
+      description of VCAT and LCAS control in SONET/SDH and OTN.
+
+   -  Support for Control of Hitless Adjustment of ODUflex (GFP)
+
+      [G7044] has been created in ITU-T to specify hitless adjustment of
+      ODUflex (GFP) (HAO) that is used to increase or decrease the
+      bandwidth of an ODUflex (GFP) that is transported in an OTN.
+
+      The procedure of ODUflex (GFP) adjustment requires the
+      participation of every node along the path.  Therefore, it is
+      recommended to use control-plane signaling to initiate the
+      adjustment procedure in order to avoid manual configuration at
+      each node along the path.
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 15]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+      From the perspective of the control plane, control of ODUflex
+      resizing is similar to control of bandwidth increasing and
+      decreasing as described in [RFC3209].  Therefore, the Shared
+      Explicit (SE) style can be used for control of HAO.
+
+   All the extensions above should consider the extensibility to match
+   future evolvement of OTN.
+
+5.3.  Implications for GMPLS Routing
+
+   The path computation process needs to select a suitable route for an
+   ODUj connection request.  In order to perform the path computation,
+   it needs to evaluate the available bandwidth on each candidate link.
+   The routing protocol should be extended to convey sufficient
+   information to represent ODU Traffic Engineering (TE) topology.
+
+   The Interface Switching Capability Descriptors defined in [RFC4202]
+   present a new constraint for LSP path computation.  [RFC4203] defines
+   the Switching Capability, related Maximum LSP Bandwidth, and
+   Switching Capability specific information.  When the Switching
+   Capability field is TDM, the Switching Capability specific
+   information field includes Minimum LSP Bandwidth, an indication
+   whether the interface supports Standard or Arbitrary SONET/SDH, and
+   padding.  Hence, a new Switching Capability value needs to be defined
+   for [G709-2012] ODU switching in order to allow the definition of a
+   new Switching Capability specific information field.  The following
+   requirements should be considered:
+
+   -  Support for carrying the link multiplexing capability
+
+      As discussed in Section 3.1.2, many different types of ODUj can be
+      multiplexed into the same OTUk.  For example, both ODU0 and ODU1
+      may be multiplexed into ODU2.  An OTU link may support one or more
+      types of ODUj signals.  The routing protocol should be capable of
+      carrying this multiplexing capability.
+
+   -  Support any ODU and ODUflex
+
+      The bit rate (i.e., bandwidth) of each TS is dependent on the TS
+      granularity and the signal type of the link.  For example, the
+      bandwidth of a 1.25 Gbps TS in an OTU2 is about 1.249409620 Gbps,
+      while the bandwidth of a 1.25 Gbps TS in an OTU3 is about
+      1.254703729 Gbps.
+
+      One LO ODU may need a different number of TSs when multiplexed
+      into different HO ODUs.  For example, for ODU2e, 9 TSs are needed
+      when multiplexed into an ODU3, while only 8 TSs are needed when
+
+
+
+
+Zhang, et al.                 Informational                    [Page 16]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+      multiplexed into an ODU4.  For ODUflex, the total number of TSs to
+      be reserved in an HO ODU equals the maximum of [bandwidth of
+      ODUflex / bandwidth of TS of the HO ODU].
+
+      Therefore, the routing protocol should be capable of carrying the
+      necessary link bandwidth information for performing accurate route
+      computation for any of the fixed rate ODUs as well as ODUflex.
+
+   -  Support for differentiating between terminating and switching
+      capability
+
+      Due to internal constraints and/or limitations, the type of signal
+      being advertised by an interface could be restricted to switched
+      (i.e., forwarded to switching matrix without
+      multiplexing/demultiplexing actions), restricted to terminated
+      (demuxed), or both.  The capability advertised by an interface
+      needs further distinction in order to separate termination and
+      switching capabilities.
+
+      Therefore, to allow the required flexibility, the routing protocol
+      should clearly distinguish the terminating and switching
+      capability.
+
+   -  Support for Tributary Slot Granularity advertisement
+
+      [G709-2012] defines two types of TSs, but each link can only
+      support a single type at a given time.  In order to perform a
+      correct path computation (i.e., the LSP endpoints have matching
+      Tributary Slot Granularity values) the Tributary Slot Granularity
+      needs to be advertised.
+
+   -  Support different priorities for resource reservation
+
+      How many priority levels should be supported depends on the
+      operator's policy.  Therefore, the routing protocol should be
+      capable of supporting up to 8 priority levels as defined in
+      [RFC4202].
+
+   -  Support link bundling
+
+      As described in [RFC4201], link bundling can improve routing
+      scalability by reducing the number of TE links that have to be
+      handled by the routing protocol.  The routing protocol should be
+      capable of supporting the bundling of multiple OTU links, at the
+      same line rate and muxing hierarchy, between a pair of nodes that
+      a TE link does.  Note that link bundling is optional and is
+      implementation dependent.
+
+
+
+
+Zhang, et al.                 Informational                    [Page 17]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   -  Support for Control of Hitless Adjustment of ODUflex (GFP)
+
+      The control plane should support hitless adjustment of ODUflex, so
+      the routing protocol should be capable of differentiating whether
+      or not an ODU link can support hitless adjustment of ODUflex (GFP)
+      and how many resources can be used for resizing.  This can be
+      achieved by introducing a new signal type "ODUflex(GFP-F),
+      resizable" that implies the support for hitless adjustment of
+      ODUflex (GFP) by that link.
+
+   As mentioned in Section 5.1, one method of enabling multiplexing
+   hierarchy is via usage of dedicated boards to allow tunneling of new
+   services through legacy ODU1, ODU2, and ODU3 containers.  Such
+   dedicated boards may have some constraints with respect to switching
+   matrix access; detection and representation of such constraints is
+   for further study.
+
+5.4.  Implications for Link Management Protocol
+
+   As discussed in Section 5.3, path computation needs to know the
+   interface switching capability of links.  The switching capability of
+   two ends of the link may be different, so the link capability of two
+   ends should be correlated.
+
+   LMP [RFC4204] provides a control-plane protocol for exchanging and
+   correlating link capabilities.
+
+   Note that LO ODU type information can be, in principle, discovered by
+   routing.  Since in certain cases, routing is not present (e.g., in
+   the case of a User-Network Interface (UNI)), we need to extend link
+   management protocol capabilities to cover this aspect.  If routing is
+   present, discovery via LMP could also be optional.
+
+   -  Correlating the granularity of the TS
+
+      As discussed in Section 3.1.2, the two ends of a link may support
+      different TS granularity.  In order to allow interconnection, the
+      node with 1.25 Gbps granularity should fall back to 2.5 Gbps
+      granularity.
+
+      Therefore, it is necessary for the two ends of a link to correlate
+      the granularity of the TS.  This ensures the correct use of the TE
+      link.
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 18]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   -  Correlating the supported LO ODU signal types and multiplexing
+      hierarchy capability
+
+      Many new ODU signal types have been introduced in [G709-2012],
+      such as ODU0, ODU4, ODU2e, and ODUflex.  It is possible that
+      equipment does not support all the LO ODU signal types introduced
+      by new standards or documents.  Furthermore, since multiplexing
+      hierarchy may not be supported by the legacy OTNs, it is possible
+      that only one end of an ODU link can support multiplexing
+      hierarchy capability or that the two ends of the link support
+      different multiplexing hierarchy capabilities (e.g., one end of
+      the link supports ODU0 into ODU1 into ODU3 multiplexing while the
+      other end supports ODU0 into ODU2 into ODU3 multiplexing).
+
+      For control and management consideration, it is necessary for the
+      two ends of an HO ODU link to correlate the types of LO ODU that
+      can be supported and the multiplexing hierarchy capabilities that
+      can be provided by the other end.
+
+5.5.  Implications for Control-Plane Backward Compatibility
+
+   With the introduction of [G709-2012], there may be OTN composed of a
+   mixture of nodes, some of which support the legacy OTN and run the
+   control-plane protocols defined in [RFC4328], while others support
+   [G709-2012] and the new OTN control plane characterized in this
+   document.  Note that a third case, for the sake of completeness,
+   consists of nodes supporting the legacy OTN referenced by [RFC4328]
+   with a new OTN control plane, but such nodes can be considered new
+   nodes with limited capabilities.
+
+   This section discusses the compatibility of nodes implementing the
+   control-plane procedures defined in [RFC4328] in support of the
+   legacy OTN and the control-plane procedures defined to support
+   [G709-2012] as outlined by this document.
+
+   Compatibility needs to be considered only when controlling an ODU1,
+   ODU2, or ODU3 connection because the legacy OTN only supports these
+   three ODU signal types.  In such cases, there are several possible
+   options, including:
+
+
+   -  A node supporting [G709-2012] could support only the control-plane
+      procedures related to [G709-2012], in which case both types of
+      nodes would be unable to jointly control an LSP for an ODU type
+      that both nodes support in the data plane.
+
+   -  A node supporting [G709-2012] could support both the control plane
+      related to [G709-2012] and the control plane defined in [RFC4328].
+
+
+
+Zhang, et al.                 Informational                    [Page 19]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+      o  Such a node could identify which set of procedures to follow
+         when initiating an LSP based on the Switching Capability value
+         advertised in routing.
+
+      o  Such a node could follow the set of procedures based on the
+         Switching Type received in signaling messages from an upstream
+         node.
+
+      o  Such a node, when processing a transit LSP, could select which
+         signaling procedures to follow based on the Switching
+         Capability value advertised in routing by the next-hop node.
+
+5.6.  Implications for Path Computation Elements
+
+   [RFC7025] describes the requirements for GMPLS applications of PCE in
+   order to establish GMPLS LSP.  PCE needs to consider the GMPLS TE
+   attributes appropriately once a Path Computation Client (PCC) or
+   another PCE requests a path computation.  The TE attributes that can
+   be contained in the path calculation request message from the PCC or
+   the PCE defined in [RFC5440] include switching capability, encoding
+   type, signal type, etc.
+
+   As described in Section 5.2, new signal types and new signals with
+   variable bandwidth information need to be carried in the extended
+   signaling message of path setup.  For the same consideration, the PCE
+   Communication Protocol (PCECP) also has a desire to be extended to
+   carry the new signal type and related variable bandwidth information
+   when a PCC requests a path computation.
+
+5.7.  Implications for Management of GMPLS Networks
+
+   From the management perspective, the management function should be
+   capable of managing not only the legacy OTN referenced by [RFC4328],
+   but also new management functions introduced by the new features as
+   specified in [G709-2012] (for more information, see Sections 3 and
+   4).  OTN Operations, Administration, and Maintenance (OAM)
+   configuration could be done through either Network Management Systems
+   (NMS) or the GMPLS control plane as defined in [TDM-OAM].  For
+   further details on management aspects for GMPLS networks, refer to
+   [RFC3945].
+
+   In case PCE is used to perform path computation in OTN, the PCE
+   manageability should be considered (for more information, see
+   Section 8 of [RFC5440]).
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 20]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+6.  Data-Plane Backward Compatibility Considerations
+
+   If MI AUTOpayloadtype is activated (see [G798]), a node supporting
+   1.25 Gbps TS can interwork with the other nodes that support 2.5 Gbps
+   TS by combining specific TSs together in the data plane.  The control
+   plane must support this TS combination.
+
+                                Path
+            +----------+   ------------>    +----------+
+            |     TS1==|===========\--------+--TS1     |
+            |     TS2==|=========\--\-------+--TS2     |
+            |     TS3==|=======\--\--\------+--TS3     |
+            |     TS4==|=====\--\--\--\-----+--TS4     |
+            |          |      \  \  \  \----+--TS5     |
+            |          |       \  \  \------+--TS6     |
+            |          |        \  \--------+--TS7     |
+            |          |         \----------+--TS8     |
+            +----------+   <------------    +----------+
+               node A           Resv           node B
+
+         Figure 5: Interworking between 1.25 Gbps TS and 2.5 Gbps TS
+
+   Take Figure 5 as an example.  Assume that there is an ODU2 link
+   between node A and B, where node A only supports the 2.5 Gbps TS
+   while node B supports the 1.25 Gbps TS.  In this case, the TS#i and
+   TS#i+4 (where i<=4) of node B are combined together.  When creating
+   an ODU1 service in this ODU2 link, node B reserves the TS#i and
+   TS#i+4 with the granularity of 1.25 Gbps.  But in the label sent from
+   B to A, it is indicated that the TS#i with the granularity of 2.5
+   Gbps is reserved.
+
+   In the opposite direction, when receiving a label from node A
+   indicating that the TS#i with the granularity of 2.5 Gbps is
+   reserved, node B will reserve the TS#i and TS#i+4 with the
+   granularity of 1.25 Gbps in its data plane.
+
+7.  Security Considerations
+
+   The use of control-plane protocols for signaling, routing, and path
+   computation opens an OTN to security threats through attacks on those
+   protocols.  However, this is not greater than the risks presented by
+   the existing OTN control plane as defined by [RFC4203] and [RFC4328].
+   Meanwhile, the Data Communication Network (DCN) for OTN GMPLS
+   control-plane protocols is likely to be in the in-fiber overhead,
+   which, together with access lists at the network edges, provides a
+   significant security feature.  For further details of specific
+   security measures, refer to the documents that define the protocols
+
+
+
+
+Zhang, et al.                 Informational                    [Page 21]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   ([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]).
+   [RFC5920] provides an overview of security vulnerabilities and
+   protection mechanisms for the GMPLS control plane.
+
+8.  Acknowledgments
+
+   We would like to thank Maarten Vissers and Lou Berger for their
+   reviews and useful comments.
+
+9.  Contributors
+
+   Jianrui Han
+   Huawei Technologies Co., Ltd.
+   F3-5-B R&D Center, Huawei Base
+   Bantian, Longgang District
+   Shenzhen 518129
+   P.R. China
+   Phone: +86-755-28972913
+   EMail: hanjianrui@huawei.com
+
+
+   Malcolm Betts
+   EMail: malcolm.betts@rogers.com
+
+
+   Pietro Grandi
+   Alcatel-Lucent
+   Optics CTO
+   Via Trento 30
+   20059 Vimercate (Milano)
+   Italy
+   Phone: +39 039 6864930
+   EMail: pietro_vittorio.grandi@alcatel-lucent.it
+
+
+   Eve Varma
+   Alcatel-Lucent
+   1A-261, 600-700 Mountain Av
+   PO Box 636
+   Murray Hill, NJ  07974-0636
+   USA
+   EMail: eve.varma@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 22]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+10.  References
+
+10.1.  Normative References
+
+   [G709-2012] ITU-T, "Interface for the Optical Transport Network
+               (OTN)", G.709/Y.1331 Recommendation, February 2012.
+
+   [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.
+
+   [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.
+
+   [RFC4201]   Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
+               in MPLS Traffic Engineering (TE)", RFC 4201, October
+               2005.
+
+   [RFC4202]   Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
+               Extensions in Support of Generalized Multi-Protocol Label
+               Switching (GMPLS)", RFC 4202, October 2005.
+
+   [RFC4203]   Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
+               in Support of Generalized Multi-Protocol Label Switching
+               (GMPLS)", RFC 4203, October 2005.
+
+   [RFC4204]   Lang, J., Ed., "Link Management Protocol (LMP)", RFC
+               4204, October 2005.
+
+   [RFC4206]   Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+               Hierarchy with Generalized Multi-Protocol Label Switching
+               (GMPLS) Traffic Engineering (TE)", RFC 4206, October
+               2005.
+
+   [RFC4328]   Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Extensions for G.709 Optical
+               Transport Networks Control", RFC 4328, January 2006.
+
+   [RFC5307]   Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
+               in Support of Generalized Multi-Protocol Label Switching
+               (GMPLS)", RFC 5307, October 2008.
+
+
+
+
+Zhang, et al.                 Informational                    [Page 23]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   [RFC5440]   Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
+               Computation Element (PCE) Communication Protocol (PCEP)",
+               RFC 5440, March 2009.
+
+   [RFC6001]   Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
+               D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
+               Extensions for Multi-Layer and Multi-Region Networks
+               (MLN/MRN)", RFC 6001, October 2010.
+
+   [RFC6107]   Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
+               Dynamically Signaled Hierarchical Label Switched Paths",
+               RFC 6107, February 2011.
+
+   [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.
+
+10.2.  Informative References
+
+   [G798]      ITU-T, "Characteristics of optical transport network
+               hierarchy equipment functional blocks", G.798
+               Recommendation, December 2012.
+
+   [G872-2001] ITU-T, "Architecture of optical transport networks",
+               G.872 Recommendation, November 2001.
+
+   [G872-2012] ITU-T, "Architecture of optical transport networks",
+               G.872 Recommendation, October 2012.
+
+   [G7041]     ITU-T, "Generic framing procedure", G.7041/Y.1303, April
+               2011.
+
+   [G7042]     ITU-T, "Link capacity adjustment scheme (LCAS) for
+               virtual concatenated signals", G.7042/Y.1305, March 2006.
+
+   [G7044]     ITU-T, "Hitless adjustment of ODUflex (HAO)",
+               G.7044/Y.1347, October 2011.
+
+   [RFC3945]   Mannie, E., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+   [RFC4655]   Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+               Computation Element (PCE)-Based Architecture", RFC 4655,
+               August 2006.
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 24]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+   [RFC6163]   Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
+               "Framework for GMPLS and Path Computation Element (PCE)
+               Control of Wavelength Switched Optical Networks (WSONs)",
+               RFC 6163, April 2011.
+
+   [RFC5920]   Fang, L., Ed., "Security Framework for MPLS and GMPLS
+               Networks", RFC 5920, July 2010.
+
+   [RFC7025]   Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
+               Margaria, "Requirements for GMPLS Applications of PCE",
+               RFC 7025, September 2013.
+
+   [TDM-OAM]   Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for
+               SONET/SDH and OTN OAM Configuration", Work in Progress,
+               November 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                 Informational                    [Page 25]
+
+RFC 7062                      OTN Framework                November 2013
+
+
+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
+
+
+   Dan Li
+   Huawei Technologies
+   F3-5-B R&D Center, Huawei Base
+   Bantian, Longgang District
+   Shenzhen 518129
+   P.R. China
+   Phone: +86-755-28973237
+   EMail: huawei.danli@huawei.com
+
+
+   Han Li
+   China Mobile Communications Corporation
+   53 A Xibianmennei Ave. Xuanwu District
+   Beijing 100053
+   P.R. China
+   Phone: +86-10-66006688
+   EMail: lihan@chinamobile.com
+
+
+   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
+
+
+
+
+Zhang, et al.                 Informational                    [Page 26]
+