GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7062

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:
  1. Circuit clients are proportionally wrapped. Thus, the bit rate is

defined by the client signal, and the tolerance is fixed to +/-100

    ppm.
  1. 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]):
  1. 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
  1. 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
  1. 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

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

  1. ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity

o ODU2 occupies 4 of the 16 TSs for ODU3

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

  1. 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)
  1. 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:
  1. Payload Type: the type of the transported payload.
  1. 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]):
  1. The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,

OPU3) overhead by the source of the HO ODUk trail.

  1. 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:
  1. 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:
  1. ODU0
  2. ODU2e
  3. ODU4
  4. 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

  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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:
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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].
  1. 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

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

  1. 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:
  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7062.txt · Last modified: 2013/11/19 23:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki