Network Working Group                                   Fatai
Internet Engineering Task Force (IETF)                     F. Zhang, Ed.
Internet Draft                                                    Dan
Request for Comments: 7062                                         D. Li
Category: Informational                                           Huawei
                                                                  Han
ISSN: 2070-1721                                                    H. Li
                                                                    CMCC
                                                               S.Belotti
                                                              S. Belotti
                                                          Alcatel-Lucent
                                                           D. Ceccarelli
                                                                Ericsson
Expires: March 22, 2014                               September 22,
                                                           November 2013

                 Framework for GMPLS and PCE Control of
                    G.709 Optical Transport Networks

               draft-ietf-ccamp-gmpls-g709-framework-15.txt

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 (OTN) (OTNs) as specified in ITU-T
   Recommendation G.709 as published in 2012.

Status of this This Memo

   This Internet-Draft document is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force (IETF), its areas,
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and its working groups.  Note that
   other groups may also distribute working has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents as Internet-
   Drafts.

   Internet-Drafts
   approved by the IESG are draft documents valid for a maximum candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It
   http://www.rfc-editor.org/info/rfc7062.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is inappropriate subject to use Internet-Drafts 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 reference
   material or they describe your rights and restrictions with respect
   to cite them other than this document.  Code Components extracted from this document must
   include Simplified BSD License text as "work described in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list Section 4.e of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 22, 2014.
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ................................................. 2 ....................................................2
   2. Terminology .................................................. 3 .....................................................3
   3. G.709 Optical Transport Network .............................. 4 .................................4
      3.1. OTN Layer Network ....................................... 4 ..........................................4
           3.1.1. Client signal mapping .............................. 5 Signal Mapping ...............................5
           3.1.2. Multiplexing ODUj onto Links ....................... 7 ........................6
                  3.1.2.1. Structure of MSI information .................. 8 Information ...............8
   4. Connection management Management in OTN ................................. 9 ....................................9
      4.1. Connection management Management of the ODU ........................ 10 ..........................10
   5. GMPLS/PCE Implications  ...................................... 12 .........................................12
      5.1. Implications for Label Switch Switched Path (LSP) Hierarchy ...... 12 ......12
      5.2. Implications for GMPLS Signaling ........................ 13 ..........................13
      5.3. Implications for GMPLS Routing .......................... 15 ............................15
      5.4. Implications for Link Management Protocol ............... 17 .................17
      5.5. Implications for Control Plane Control-Plane Backward Compatibility ... 18 .....18
      5.6. Implications for Path Computation Elements .............. 19 ................19
      5.7. Implications for Management of GMPLS Networks ........... 20 .............19
   6. Data Plane Data-Plane Backward Compatibility Considerations ............. 20 ...............20
   7. Security Considerations  ..................................... 21 ........................................20
   8. IANA Considerations .......................................... 21
   9. Acknowledgments .............................................. 21 ................................................21
   9. Contributors ...................................................21
   10. References .................................................. 21 ....................................................22
      10.1. Normative References ................................... 21 .....................................22
      10.2. Informative References  ................................ 23
   11. Authors' Addresses .......................................... 24
   12. Contributors ................................................ 25 ...................................23

1.  Introduction

   Optical Transport Networks (OTN) has (OTNs) have become a mainstream layer 1
   technology for the transport network.  Operators want to introduce
   control plane
   control-plane capabilities based on GMPLS to OTN, 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 Time
   Division Multiplexing (TDM) networks (e.g., Synchronous Optical
   NETwork (SONET)/ (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- 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.25Gbps 1.25 Gbps and 2.5Gbps), 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 control-plane protocols and examines why and
   how to update the mechanisms described in [RFC4328].  This document
   additionally provides a framework for the GMPLS control of OTN and
   includes a discussion of the implication implications for the use of the PCE
   [RFC4655].

   For the purposes of the control plane plane, the OTN can be considered as
   being 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 Channel Payload Unit

   ODU: Optical channel Channel Data Unit

   OTU: Optical channel Channel Transport Unit

   OMS: Optical multiplex section 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,
   flex.) 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, 4.) 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' "ODUj" is used to refer to ODU
   entities acting as an LO ODU, and 'ODUk' "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 those the aspects of the
   OTN impacting control plane 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 technology, many new features have
   been specified in ITU-T recommendations, including including, for example, new
   ODU0, ODU2e, ODU4 ODU4, and ODUflex containers as described in
   [G709-2012].

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. (e.g., Optical Transmission Section (OTS)) are
   not included in this Figure. figure.  The full signal hierarchy is provided
   in [G709-2012].

                               Client signal
                                    |
                                   ODUj
                                    |
                                 OTU/OCh
                                   OMS

                   Figure 1 - 1: Basic OTN signal hierarchy 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.

3.1.1.  Client signal mapping Signal Mapping

   The client signals are mapped into a an LO ODUj.  The current values of
   j defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, Flex. and flex.  The
   approximate bit rates of these signals are defined in [G709-2012] and
   are reproduced in Tables 1 and 2.

                     Table 1 - ODU types and bit rates

   +-----------------------+-----------------------------------+
   |       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  |                                   |
   +-----------------------+-----------------------------------+
   NOTE -

                     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) (ODU4), and 10,399,525.316 Kbps (ODU2e).

                     Table 2 - ODU types and tolerance

   +-----------------------+-----------------------------------+
   |      ODU Type         |       ODU bit-rate 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  Thus, the bit rate is
      defined by the client signal 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 j=k, the ODUj is mapped into the OTU/OCh without
   multiplexing.

   The initial versions of G.709 referenced by [RFC4328] only provided a
   single TS granularity, nominally 2.5Gbps. 2.5 Gbps.  [G709-2012] added an
   additional TS granularity, nominally 1.25Gbps. 1.25 Gbps.  The number and type
   of
   TSs TS provided by each of the currently identified OTUk is are provided
   below:

             Tributary Slot Granularity
                2.5Gbps     1.25Gbps
                2.5 Gbps     1.25 Gbps           Nominal Bit rate Rate
     OTU1         1             2                  2.5Gbps                  2.5 Gbps
     OTU2         4             8                   10Gbps                   10 Gbps
     OTU3        16            32                   40Gbps                   40 Gbps
     OTU4        --            80                  100Gbps                  100 Gbps

   To maintain backwards backward compatibility while providing the ability to
   interconnect nodes that support 1.25Gbps a 1.25 Gbps TS at one end of a link
   and
   2.5Gbps a 2.5 Gbps TS at the other, [G709-2012] requires 'new' equipment
   to fall back to the use of a 2.5Gbps 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
   Thus, the number of TSs occupied by an ODUj may vary depending on the
   values of j and k.  For example 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 (referring to Table Tables 7-9 of [G709-2012]):

   -  ODU0 into ODU1, ODU2, ODU3 ODU3, or ODU4 multiplexing with 1,25Gbps 1.25 Gbps TS
      granularity
      o  ODU0 occupies 1 of the 2, 8, 32 32, or 80 TSs for ODU1, ODU2, ODU3
         ODU3, or ODU4

   -  ODU1 into ODU2, ODU3 ODU3, or ODU4 multiplexing with 1,25Gbps 1.25 Gbps TS
      granularity
      o  ODU1 occupies 2 of the 8, 32 32, or 80 TSs for ODU2, ODU3 ODU3, or ODU4

   -  ODU1 into ODU2, ODU2 or ODU3 multiplexing with 2.5Gbps 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.25Gbps 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.5Gbps 2.5 Gbps TS granularity
      o  ODU2 occupies 4 of the 16 TSs for ODU3

   -  ODU3 into ODU4 multiplexing with 1.25Gbps 1.25 Gbps TS granularity
      o  ODU3 occupies 31 of the 80 TSs for ODU4
   -  ODUflex into ODU2, ODU3 ODU3, or ODU4 multiplexing with 1.25Gbps 1.25 Gbps TS
      granularity
      o  ODUflex occupies n of the 8, 32 32, or 80 TSs for ODU2, ODU3 ODU3, or
         ODU4 (n <= Total TS number of ODUk)

   -  ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps 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 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, end or Network Management
   System (NMS)) through Explicit Label Control [RFC3473].

3.1.2.1.  Structure of MSI information Information

   When multiplexing an ODUj into a 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 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 a an HO ODU3 is described by 4 entries
   in the OPU3 overhead when the TS granularity is 2.5Gbps, 2.5 Gbps, and by 8
   entries when the TS granularity is 1.25Gbps. 1.25 Gbps.

   On each node and on every link, two MSI values have to be provisioned
   (Referring
   (referring to [G798-V4]): [G798]):

   -  The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,
      OPU3) overhead by the source of the HO ODUk trail.

   -  The expected Expected MSI (ExMSI) information that is used to check the
      accepted
      Accepted MSI (AcMSI) information.  The AcMSI information is the
      MSI valued received in-band, after a three-frame integration.

   As described in [G798-V4], [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 dropped, and a
   payload mismatch alarm is generated.

   Provisioning of TPN can be performed either 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
   base. link-by-link
   basis.

4.  Connection management 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 as 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
   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 link-layer topology may be provided via various
   infrastructure alternatives, including point-to-point optical
   connections, optical connections fully in the optical domain domain, and
   optical connections involving hybrid sub-lambda/lambda nodes
   involving 3R, etc, see etc.  See [RFC6163] for additional information.

4.1.  Connection management Management of the ODU

   An LO ODUj can be either mapped into the OTUk signal (j = k), 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 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 setup 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 - 2: Example Topology for LO ODU connection management Connection Management

   If an ODUj connection is requested between Node C and Node E E,
   routing/path computation must select a path that has the required
   number of TS 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 ODUj-to-OTUk mapping (j = k) or multiplexing (j
   < k), 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
   node
   nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM), (ROADM) or
   Optical Cross-Connect (OXC)) that are capable of OCh switching, which switching; this
   is illustrated in Figure Figures 3 and Figure 4.  There are the ODU layer and the
   OCh layer, so it is simply a Multi-Layer Networks Network (MLN) (see
   [RFC6001]).  OCh connections may be created on demand, which is
   described in
   section 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 process, in
   which case the topology would be as shown in Figure 4.  In Figure 3
   below, instead, 3,
   however, a cloud representing OCh capable OCh-capable switching nodes is
   represented.  In Figure 3, the operator choice is to hide the real OCh
   layer
   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 - 3: OCh Hidden Topology for LO ODU connection management 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 - 4: OCh Visible Topology for LO ODUj connection management Connection Management
   In Figure 4, the cloud of 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., Figure Figures 3 and Figure 4), we have considered the case
   in which LO ODUj connections are supported by an OCh connection, connection and
   the case in which the supporting underlying connection can be 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 Switch 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, 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] [RFC6001], and [RFC6107], etc. [RFC6107].

   As discussed in section 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, ODU0
   and ODUflex) into a legacy network configuration (i.e., the legacy
   OTN referenced by [RFC4328]).  In this scenario, it may be needed 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.

   In such case, 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, 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 multi-
   layer network signaling described in [RFC4206], [RFC6107] [RFC6107], and
   [RFC6001] (including related modifications, if needed) are 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 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 Type, and the
   Generalized Protocol Identifier (Generalized-PID) constituting the
   common part of the Generalized Label Request.  The G.709 Traffic
   Parameters traffic
   parameters are also defined in [RFC4328]. The  In addition, the following
   signaling aspects not included in [RFC4328] should be considered additionally since [RFC4328] was
   published: considered:

   -  Support for specifying the new signal types and the related traffic
      information

      The traffic parameters should be extended in a signaling message
      to support the new ODUj ODUj, including:

      -  ODU0
      -  ODU2e
      -  ODU4
      -  ODUflex

      For the ODUflex signal type, its the bit rate must be carried
      additionally in the Traffic Parameter traffic parameter to setup set up an ODUflex
      connection.

      For other ODU signal types, their the bit rates and tolerances are fixed
      and can be deduced from the signal types.

   -  Support for LSP setup using different TS granularity

      The signaling protocol should be able to identify the TS
      granularity (i.e., the 2.5Gbps 2.5 Gbps TS granularity and the new 1.25Gbps 1.25
      Gbps TS granularity) to be used for establishing an a Hierarchical
      LSP
      which 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 TSs TS's
      allocation information related to the extended mapping and
      multiplexing hierarchy (For (for example, ODU0 into ODU2 multiplexing
      (with 1.25Gbps 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 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 the control plane control-plane signaling to initiate the
      adjustment procedure in order to avoid the manual configuration at
      each node along the path.

      From the perspective of the control plane, the 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 and Switching Capability, related Maximum LSP Bandwidth Bandwidth, and the
   Switching Capability specific information.  When the Switching
   Capability field is TDM TDM, the Switching Capability Specific Information specific
   information field includes Minimum LSP Bandwidth, an indication
   whether the interface supports Standard or Arbitrary SONET/SDH, and
   padding.
   Hence  Hence, a new Switching Capability value needs to be defined
   for [G709-
   2012] [G709-2012] ODU switching in order to allow the definition of a
   new Switching Capability Specific Information field definition. specific information field.  The following
   requirements should be considered:

   -  Support for carrying the link multiplexing capability

      As discussed in section 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.25G 1.25 Gbps TS in an OTU2 is about 1.249409620Gbps, 1.249409620 Gbps,
      while the bandwidth of a 1.25G 1.25 Gbps TS in an OTU3 is about
       1.254703729Gbps.
      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
      multiplexed into an ODU4.  For ODUflex, the total number of TSs to
      be reserved in a 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.
      (i.e., forwarded to switching matrix without
      multiplexing/demultiplexing actions), restricted to terminated
       (demuxed)
      (demuxed), or both of them. 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 TS TSs, but each link can only
      support a single type at a given time.  In order to perform a
      correct path computation (i.e. (i.e., the LSP end points endpoints have matching
      Tributary Slot Granularity values) the Tributary Slot Granularity
      needs to be advertised.

   -  Support different priorities for resource reservation

      How many priorities 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 amount number of TE links that has 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 as that
      a TE
       link. link does.  Note that link bundling is optional and is
      implementation dependent.

   -  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) or not,
      and how much resource 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 Section 5.3, Path 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 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. User-
   Network (e.g., in
   the case of a User-Network Interface (UNI) case) (UNI)), we need to extend link
   management protocol capabilities to cover this aspect. In case of  If routing
   presence, the is
   present, discovery via LMP could also be optional.

   -  Correlating the granularity of the TS

      As discussed in section Section 3.1.2, the two ends of a link may support
      different TS granularity.  In order to allow interconnection interconnection, the
      node with 1.25Gbps 1.25 Gbps granularity should fall back to 2.5Gbps 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
       and of the TE
      link.

   -  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 ODU2e, and ODUflex.  It is possible that
      equipment does not support all the LO ODU signal types introduced
      by those new standards or drafts. documents.  Furthermore, since multiplexing
      hierarchy may not be supported by the legacy OTN, OTNs, it is possible
      that only one end of an ODU link can support multiplexing
      hierarchy capability, 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 the control and management consideration, it is necessary for the
      two ends of an HO ODU link to correlate which the types of LO ODU that
      can be supported and what the multiplexing hierarchy capabilities that
      can be provided by the other end.

5.5.  Implications for Control Plane 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
   control plane 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 on of nodes supporting the legacy OTN referenced by [RFC4328]
   with a new OTN control plane, but such nodes can be considered as new
   nodes with limited capabilities.

   This section discusses the compatibility of nodes implementing the
   control plane
   control-plane procedures defined [RFC4328], in [RFC4328] in support of the
   legacy
   OTN, OTN and the control plane control-plane procedures defined to support [G709-2012],
   [G709-2012] as outlined by this document.

   Compatibility needs to be considered only when controlling ODU1 or
   ODU2 an ODU1,
   ODU2, or ODU3 connection, connection because the legacy OTN only support supports these
   three ODU signal types.  In such cases, there are several possible
   options
   options, including:

   -  A node supporting [G709-2012] could support only the [G709-2012] control-plane
      procedures related control plane procedures, 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 [G709-2012]
      related control plane
      related to [G709-2012] and the control plane defined in [RFC4328].

      o  Such a node could identify which set of procedure 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 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 which that can
   be contained in the path calculation request message from the PCC or
   the PCE defined in [RFC5440] includes include switching capability, encoding
   type, signal type, etc.

   As described in section 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, it 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]
   (see (for more in information, see Sections 3&4). Regarding 3 and
   4).  OTN Operations, Administration Administration, and Maintenance (OAM) configuration, it
   configuration could be done through either Network Management Systems
   (NMS) or the GMPLS control plane as defined in [TDM-OAM]. Further  For
   further details of on management aspects for GMPLS networks networks, refer to
   [RFC3945].

   In case PCE is used to perform path computation in OTN, the PCE
   manageability should be considered (see (for more in information, see
   Section 8 of [RFC5440]).

6. Data Plane  Data-Plane Backward Compatibility Considerations

   If MI AUTOpayloadtype is activated (see [G798-V4]), [G798]), a node supporting
   1.25Gbps
   1.25 Gbps TS can interwork with the other nodes that supporting
   2.5Gbps support 2.5 Gbps
   TS by combining Specific 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 - 5: Interworking between 1.25Gbps 1.25 Gbps TS and 2.5Gbps 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.5Gbps 2.5 Gbps TS
   while node B supports the 1.25Gbps 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.25Gbps. 1.25 Gbps.  But in the label sent from
   B to A, it is indicated that the TS#i with the granularity of 2.5Gbps 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.5Gbps 2.5 Gbps is
   reserved, node B will reserved reserve the TS#i and TS#i+4 with the
   granularity of
   1.25Gbps 1.25 Gbps in its data plane.

7.  Security Considerations

   The use of control plane control-plane protocols for signaling, routing routing, and path
   computation opens an OTN to security threats through attacks on those
   protocols. Although,  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
   control-plane protocols is likely to be in the in-fiber overhead, which
   which, together with access lists at the network edges, provides a
   significant security feature.  For further details of the specific
   security measures measures, refer to the documents that define the protocols
   ([RFC3473], [RFC4203], [RFC5307], [RFC4204] [RFC4204], and [RFC5440]).
   [RFC5920] provides an overview of security vulnerabilities and
   protection mechanisms for the GMPLS control plane.

8. IANA Considerations

   This document makes not requests for IANA action.

9.  Acknowledgments

   We would like to thank Maarten Vissers and Lou Berger for their
   review
   reviews and useful comments.

10. References

10.1. Normative References

   [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., Editor, "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Functional Description", RFC
               3471, January 2003.

   [RFC3473]   L. Berger, Ed., "Generalized Multi-Protocol Label
               Switching (GMPLS)

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

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]   K.   Kompella, Y. K., Rekhter, Ed., Y., and L. Berger, "Link Bundling
               in MPLS Traffic Engineering (TE)", RFC 4201, October
               2005.

   [RFC4202]   K.   Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
               Extensions in Support of Generalized Multi-Protocol Label
               Switching (GMPLS)", RFC 4202, October 2005.

   [RFC4203]   K.   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]   K.   Kompella, K. and Y. Rekhter, Ed., "Label Switched Paths (LSP)
               Hierarchy with Generalized Multi-Protocol Label Switching
               (GMPLS) Traffic Engineering (TE)", RFC 4206, October
               2005.

   [RFC4328]   D.   Papadimitriou, Ed. D., Ed., "Generalized Multi-Protocol
               LabelSwitching Label
               Switching (GMPLS) Signaling Extensions for G.709 Optical
               Transport Networks Control", RFC 4328, Jan January 2006.

   [RFC5307]   K.   Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
               in Support of Generalized Multi-Protocol Label Switching
               (GMPLS)", RFC 5307, October 2008.

   [RFC5440]   JP.   Vasseur, JP., Ed., and JL. Le Roux, Ed.," Path Ed., "Path
               Computation Element (PCE) Communication Protocol (PCEP)",
               RFC 5440, March 2009.

   [RFC6001]   Dimitri Papadimitriou et al,   Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
               D., and JL. Le Roux, "Generalized Multi-Protocol
               Label Switching MPLS (GMPLS) Protocol
               Extensions for Multi-
               Layer Multi-Layer and Multi-Region Networks
               (MLN/MRN)", RFC6001,
               February 21, RFC 6001, October 2010.

   [RFC6107]   K.   Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
               Dynamically Signaled Hierarchical Label Switched Paths", RFC6107,
               RFC 6107, February 2011.

   [RFC6344]   G. Bernstein et al,   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)",
               RFC6344, August, RFC 6344, August
               2011.

   [G709-2012] ITU-T, "Interface for the Optical Transport Network
               (OTN)", G.709/Y.1331 Recommendation, February 2012.

10.2.  Informative References

   [G798-V4]

   [G798]   ITU-T, "Characteristics of optical transport network
               hierarchy equipment functional blocks", G.798
               Recommendation, October 2010.

   [G7042]     ITU-T, "Link capacity adjustment scheme (LCAS) for
               virtual concatenated signals", G.7042/Y.1305, March 2006. 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.

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

   [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., J.-P., and J. Ash, "A Path
               Computation Element (PCE)-Based Architecture", RFC 4655,
               August 2006.

   [RFC6163]   Y.   Lee, G. Y., Ed., Bernstein, G., Ed., and W. Imajuku,
               "Framework for GMPLS and PCE Path Computation Element (PCE)
               Control of Wavelength Switched Optical Networks
               (WSON)", RFC6163, (WSONs)",
               RFC 6163, April 2011.

   [RFC5920]   Fang, L., Ed., "Security Framework for MPLS and GMPLS
               Networks", RFC5920, RFC 5920, July 2010.

   [RFC7025]   Tomohiro   Otani, Kenichi T., Ogaki, Diego K., Caviglia, and Fatai D., Zhang, F., and C.
               Margaria, "Requirements for GMPLS applications Applications of PCE",
               RFC7025,
               RFC 7025, September 2013.

   [TDM-OAM]   A.   Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for
               SONET/SDH and OTN OAM Configuration", draft-ietf-ccamp-
               rsvp-te-sdh-otn-oam-ext, Work in Progress.

11. Progress,
               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
   P.R. China

   Phone: +86-755-28972912
   Email:
   EMail: zhangfatai@huawei.com

   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China
   P.R. China

   Phone: +86-755-28973237
   Email:
   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:
   EMail: lihan@chinamobile.com
   Sergio Belotti
   Alcatel-Lucent
   Optics CTO
   Via Trento 30
   20059 Vimercate (Milano)
   Italy

   Phone: +39 039 6863033

   Email:
   EMail: sergio.belotti@alcatel-lucent.it

   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email:

   EMail: daniele.ceccarelli@ericsson.com

12. 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
   +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

 Intellectual Property

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.

Disclaimer of Validity

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

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.