Skip to main content

Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)
draft-ietf-ccamp-otn-g709-info-model-13

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7096.
Authors Sergio Belotti , Pietro Grandi , Daniele Ceccarelli , Diego Caviglia , Fatai Zhang , Dan Li
Last updated 2018-12-20 (Latest revision 2013-11-05)
Replaces draft-bccg-ccamp-otn-g709-info-model
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Lou Berger
Shepherd write-up Show Last changed 2013-07-04
IESG IESG state Became RFC 7096 (Informational)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Adrian Farrel
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
draft-ietf-ccamp-otn-g709-info-model-13
CCAMP Working Group                                      S. Belotti, Ed.
Internet-Draft                                                 P. Grandi
Intended status: Informational                            Alcatel-Lucent
Expires: May 9, 2014                                  D. Ceccarelli, Ed.
                                                             D. Caviglia
                                                                Ericsson
                                                                F. Zhang
                                                                   D. Li
                                                     Huawei Technologies
                                                        November 5, 2013

Evaluation of existing GMPLS encoding against G.709v3 Optical Transport
                             Networks (OTN)
                draft-ietf-ccamp-otn-g709-info-model-13

Abstract

   ITU-T recommendation [G.709-2012] has introduced new fixed and
   flexible Optical Data Unit (ODU) containers in Optical Transport
   Networks (OTNs).

   This document provides an evaluation of existing Generalized
   Multiprotocol Label Switching (GMPLS) routing and signaling protocols
   against the G.709 OTN networks.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 9, 2014.

Copyright Notice

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

Belotti, et al.            Expires May 9, 2014                  [Page 1]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   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.  G.709 Mapping and Multiplexing Capabilities  . . . . . . . . .  3
   3.  Tributary Slot Granularity . . . . . . . . . . . . . . . . . .  6
     3.1.  Data Plane Considerations  . . . . . . . . . . . . . . . .  7
       3.1.1.  Payload Type and TS granularity relationship . . . . .  7
       3.1.2.  Fall-back procedure  . . . . . . . . . . . . . . . . .  8
     3.2.  Control Plane considerations . . . . . . . . . . . . . . .  9
   4.  Tributary Port Number  . . . . . . . . . . . . . . . . . . . . 12
   5.  Signal type  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Bit rate and tolerance . . . . . . . . . . . . . . . . . . . . 14
   7.  Unreserved Resources . . . . . . . . . . . . . . . . . . . . . 15
   8.  Maximum LSP Bandwidth  . . . . . . . . . . . . . . . . . . . . 15
   9.  Distinction between terminating and switching capability . . . 15
   10. Priority Support . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Multi-stage multiplexing . . . . . . . . . . . . . . . . . . . 18
   12. Generalized Label  . . . . . . . . . . . . . . . . . . . . . . 19
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     17.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22

Belotti, et al.            Expires May 9, 2014                  [Page 2]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

1.  Introduction

   GMPLS routing and signaling, as defined by [RFC4203], [RFC5307],
   [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS
   control of Optical Transport Networks (OTNs) based on the 2001
   revision of the G.709 specification.  The 2012 revision of the G.709
   specification, [G.709-2012], includes new OTN features which are not
   supported by GMPLS.

   This document provides an evaluation of exiting GMPLS signaling and
   routing protocols against G.709 requirements.  Background information
   and a framework for the GMPLS protocol extensions needed to support
   G.709 is provided in [OTN-FWK].  Specific routing and signaling
   extensions defined in [OTN-OSPF] and [OTN-RSVP] specifically address
   the gaps identified in this document.

2.  G.709 Mapping and Multiplexing Capabilities

   The digital OTN layered structure is comprised of the digital path
   layer (ODU) and the digital section layer (OTU).  An OTU (Optical
   Transport Unit) section layer supports one ODU path layer as client
   and provides monitoring capability for the Optical Channel (OCh),
   which is the optical path carrying the digital OTN structure.  An ODU
   path layer may transport a heterogeneous assembly of ODU clients.
   Some types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a
   client or server role within the context of a particular networking
   domain.  The terms ODU1, ODU2, ODU3, ODU4, and ODUflex are explained
   in G.709.  G.872 [G.872] provides two tables defining mapping and
   multiplexing capabilities of OTNs, which are reported below.

Belotti, et al.            Expires May 9, 2014                  [Page 3]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

         +--------------------+--------------------+
         |     ODU client     |     OTU server     |
         +--------------------+--------------------+
         |        ODU0        |          -         |
         +--------------------+--------------------+
         |        ODU1        |        OTU 1       |
         +--------------------+--------------------+
         |        ODU2        |        OTU 2       |
         +--------------------+--------------------+
         |        ODU2e       |          -         |
         +--------------------+--------------------+
         |        ODU3        |        OTU 3       |
         +--------------------+--------------------+
         |        ODU4        |        OTU 4       |
         +--------------------+--------------------+
         |        ODUflex     |          -         |
         +--------------------+--------------------+

                     Figure 1: OTN mapping capability

Belotti, et al.            Expires May 9, 2014                  [Page 4]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

       +=================================+=========================+
       |           ODU client            |       ODU server        |
       +---------------------------------+-------------------------+
       |        1.25 Gbps client         |                         |
       +---------------------------------+          ODU0           |
       |                 -               |                         |
       +=================================+=========================+
       |         2.5 Gbps client         |                         |
       +---------------------------------+          ODU1           |
       |              ODU0               |                         |
       +=================================+=========================+
       |         10 Gbps client          |                         |
       +---------------------------------+          ODU2           |
       |        ODU0,ODU1,ODUflex        |                         |
       +=================================+=========================+
       |        10.3125 Gbps client      |                         |
       +---------------------------------+          ODU2e          |
       |                 -               |                         |
       +=================================+=========================+
       |         40 Gbps client          |                         |
       +---------------------------------+          ODU3           |
       |  ODU0,ODU1,ODU2,ODU2e,ODUflex   |                         |
       +=================================+=========================+
       |        100 Gbps client          |                         |
       +---------------------------------+          ODU4           |
       |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex|                         |
       +=================================+=========================+
       |CBR* clients from greater than   |                         |
       |2.5 Gbit/s to 100 Gbit/s: or     |                         |
       |GFP-F**mapped packet clients from|          ODUflex        |
       |1.25 Gbit/s to 100 Gbit/s.       |                         |
       +---------------------------------+                         |
       |                 -               |                         |
       +=================================+=========================+
           (*) - Constant Bit Rate
           (**) - Generic Framing Procedure - Framed (GFP-F)

                   Figure 2: OTN multiplexing capability

   In the following, the terms ODUj and ODUk are used in a multiplexing
   scenario to identify the lower order signal (ODUj) and the higher
   order signal (ODUk).  How an ODUk connection service is transported
   within an operator network is governed by operator policy.  For
   example, the ODUk connection service might be transported over an
   ODUk path over an OTUk section, with the path and section being at
   the same rate as that of the connection service (see Table 1).  In
   this case, an entire lambda of capacity is consumed in transporting

Belotti, et al.            Expires May 9, 2014                  [Page 5]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   the ODUk connection service.  On the other hand, the operator might
   exploit different multiplexing capabilities in the network to improve
   infrastructure efficiencies within any given networking domain.  In
   this case, ODUk multiplexing may be performed prior to transport over
   various rate ODU servers (as per Table 2) over associated OTU
   sections.

   From the perspective of multiplexing relationships, a given ODUk may
   play different roles as it traverses various networking domains.

   As detailed in [OTN-FWK], client ODUk connection services can be
   transported over:

      o Case A) one or more wavelength sub-networks connected by optical
      links or

      o Case B) one or more ODU links (having sub-lambda and/or lambda
      bandwidth granularity)

      o Case C) a mix of ODU links and wavelength sub-networks.

   This document considers the TE information needed for ODU path
   computation and parameters needed to be signaled for Label Switched
   Path (LSP) setup.

   The following sections list and analyze, for each type of data that
   needs to be advertised and signaled, what is already there in GMPLS
   and what is missing.

3.  Tributary Slot Granularity

   G.709 defines two types of Tributary Slot (TS) granularity.  This TS
   granularity is defined per layer, meaning that both ends of a link
   can select proper TS granularity differently for each supported
   layer, based on the rules below:

      - If both ends of a link are new cards supporting both 1.25Gbps TS
      and 2.5Gbps TS, then the link will work with 1.25Gbps TS.

      - If one end is a new card supporting both the 1.25Gbps and
      2.5Gbps TS granularities, and the other end is an old card
      supporting just the 2.5Gbps TS granularity, the link will work
      with 2.5Gbps TS granularity.

Belotti, et al.            Expires May 9, 2014                  [Page 6]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

3.1.  Data Plane Considerations

3.1.1.  Payload Type and TS granularity relationship

   As defined in G.709 an ODUk container consist of an Optical Payload
   Unit (OPUk) plus a specific ODUk Overhead (OH).  OPUk OH information
   is added to the OPUk information payload to create an OPUk.  It
   includes information to support the adaptation of client signals.
   Within the OPUk overhead there is the payload structure identifier
   (PSI) that includes the payload type (PT).  The payload type (PT) is
   used to indicate the composition of the OPUk signal.  When an ODUj
   signal is multiplexed into an ODUk, the ODUj signal is first extended
   with frame alignment overhead and then mapped into an Optical channel
   Data Tributary Unit (ODTU).  Two different types of ODTU are defined:

      - ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12,
      ODTU13 and ODTU23) in which an ODUj signal is mapped via the
      Asynchronous Mapping Procedure (AMP), defined in clause 19.5 of
      G.709.

      - ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a
      lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is
      mapped via the Generic Mapping Procedure (GMP), defined in clause
      19.6 of G.709.

   G.709 introduces also a logical entity, called Optical Data Tributary
   Unit Group (ODTUGk), characterizing the multiplexing of the various
   ODTU.  The ODTUGk is then mapped into OPUK.  ODTUjk and ODTUk.ts
   signals are directly time-division multiplexed into the tributary
   slots of an HO OPUk.

   When PT is assuming value 0x20 or 0x21,together with OPUk type (K=
   1,2,3,4), it is used to discriminate two different ODU multiplex
   structure ODTUGx :

      - Value 0x20: supporting ODTUjk only,

      - Value 0x21: supporting ODTUk.ts or ODTUk.ts and ODTUjk.

   The distinction is needed for OPUk with K =2 or 3, since OPU2 and
   OPU3 are able to support both the different ODU multiplex structures.
   For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with
   PT=0x21 and ODTUG1 with PT=0x20. (see table Figure 6).The
   relationship between PT and TS granularity, is in the fact that the
   two different ODTUGk discriminated by PT and OPUk are characterized
   by two different TS granularities of the related OPUk, the former at
   2.5Gbps, the latter at 1.25Gbps.

Belotti, et al.            Expires May 9, 2014                  [Page 7]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   In order to complete the picture, in the PSI OH there is also the
   Multiplex Structure Identifier (MSI) that provides the information on
   which tributary slots the different ODTUjk or ODTUk.ts are mapped
   into the related OPUk.  The following figure shows how the client
   traffic is multiplexed till the OPUk layer.

                   +--------+      +------------+
        +----+     |        !------| ODTUjk     |-----Client
        |    |     | ODTUGk |      +-----.------+
        |    |-----| PT=0x21|            .
        |    |     |        |      +-----.------+
        |    |     |        |------| ODTUk.TS   |-----Client
        |OPUk|     +--------+      +------------+
        |    |
        |    |     +--------+      +------------+
        |    |     |        |------| ODTUjk     |-----Client
        |    |-----|        |      +-----.------+
        +----+     | ODTUGk |            .
                   | PT=0x20|      +-----.------+
                   |        |------| ODTUjk     |-----Client
                   +--------+      +------------+

                     Figure 3: OTN client multiplexing

3.1.2.  Fall-back procedure

   G.798 [G.798] describes the so called PT=0x21-to-PT=0x20 interworking
   process that explains how two nodes with interfaces with different
   PayloadType, and hence different TS granularity (1.25Gbps vs.
   2.5Gbps), can be coordinated so to permit the equipment with 1.25 TS
   granularity to adapt his TS allocation accordingly to the different
   TS granularity (2.5Gbps) of a neighbor.

   Therefore, in order to let the NE change TS granularity accordingly
   to the neighbor requirements, the AUTOpayloadtype [G.798] needs to be
   set.  When both the neighbors (link or trail) have been configured as
   structured, the payload type received in the overhead is compared to
   the transmitted PT.  If they are different and the transmitted
   PT=0x21, the node must fallback to PT=0x20.  In this case the
   fallback process makes the system self-consistent and the only reason
   for signaling the TS granularity is to provide the correct label
   (i.e. label for PT=0x21 has twice the TS number of PT=0x20).  On the
   other side, if the AUTOpayloadtype is not configured, the RSVP-TE
   consequent actions in case of TS mismatch need to be defined.

Belotti, et al.            Expires May 9, 2014                  [Page 8]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

3.2.  Control Plane considerations

   When setting up an ODUj over an ODUk, it is possible to identify two
   types of TS granularity (TSG), the server and the client one.  The
   server TS granularity is used to map an end to end ODUj onto a server
   ODUk LSP or links.  This parameter cannot be influenced in any way
   from the ODUj LSP: ODUj LSP will be mapped on tributary slots
   available on the different links/ODUk LSPs.  When setting up an ODUj
   at a given rate, the fact that it is carried over a path composed by
   links/Forwarding Adjacencies(FAs) structured with 1.25Gbps or 2.5Gbps
   TS granularity is completely transparent to the end to end ODUj.

   The client TS granularity information is one of the parameters needed
   to correctly select the adaptation towards the client layers at the
   end nodes and this is the only thing that the ODUj has to guarantee.

   In figure 4 an example of client and server TS granularity
   utilization in a scenario with mixed [RFC4328] OTN and [G.709-2012]
   OTN interfaces is shown.

                            ODU1-LSP
           .........................................
      TSG-C|                                       |TSG-C
       1.25|                   ODU2-H-LSP          |1.25
           +------------X--------------------------+
           |       TSG-S|                          |TSG-S
           |         2.5|                          |2.5
           |            |       ODU3-H-LSP         |
           |            |------------X-------------|
           |            |                          |
        +--+--+      +--+--+                   +---+-+
        |     |      |     |     +-+   +-+     |     |
        |  A  +------+  B  +-----+ +***+ +-----+  Z  |
        | V.3 | OTU2 | V.1 |OTU3 +-+   +-+ OTU3| V.3 |
        +-----+      +-----+                   +-----+

         ... Service LSP
         --- Hierarchical-LSP (H-LSP)

              Figure 4: Client-Server TS granularity example

   In this scenario, an ODU3 LSP is setup from node B to Z. Node B has
   an old interface able to support 2.5Gbps TS granularity, hence only
   client TS granularity equal to 2.5Gbps can be exported to ODU3 H-LSP
   possible clients.  An ODU2 LSP is setup from node A to node Z with
   client TS granularity 1.25Gbps signaled and exported towards clients.

Belotti, et al.            Expires May 9, 2014                  [Page 9]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   The ODU2 LSP is carried by ODU3 H-LSP from B to Z. Due to the
   limitations of old node B interface, the ODU2 LSP is mapped with
   2.5Gbps TS granularity over the ODU3 H-LSP.  Then an ODU1 LSP is
   setup from A to Z, carried by the ODU2 H-LSP and mapped over it using
   a 1.25Gbps TS granularity.

   What is shown in the example is that the TS granularity processing is
   a per layer issue: even if the ODU3 H-LSP is created with TS
   granularity client at 2.5Gbps, the ODU2 H-LSP must guarantee a
   1.25Gbps TS granularity client.  ODU3 H-LSP is eligible from ODU2 LSP
   perspective since from the routing it is known that this ODU3
   interface at node Z, supports an ODU2 termination exporting a TS
   granularity 1.25Gbps/2.5Gbps.

   The TS granularity information is needed in the routing protocol as
   the ingress node (A in the previous example) needs to know if the
   interfaces at the last hop can support the required TS granularity.
   In case they cannot, A will compute an alternate path from itself to
   Z (see figure 4).

   Moreover, also TS granularity information needs to be signaled.
   Consider as example the setup of an ODU3 forwarding adjacency that is
   going to carry an ODU0, hence the support of 1.25Gbps TS is needed.
   The information related to the TS granularity has to be carried in
   the signaling to permit node C (see figure 5) choose the right one
   among the different interfaces (with different TS granularitys)
   towards D. In case the full Explicit Route Object (ERO) is provided
   in the signaling with explicit interface declaration, there is no
   need for C to choose the right interface towards D as it has been
   already decided by the ingress node or by the Path Computation
   Element (PCE).

                                ODU3
                               <---------------------->

                                ODU0
               <-------------------------------------->
               |                                      |
      +--------+      +--------+      +--------+      +--------+
      |        |      |        |      |        | 1.25 |        |
      |  Node  |      |  Node  |      |  Node  +------+  Node  |
      |   A    +------+   B    +------+   C    | ODU3 |   D    |
      |        | ODU3 |        | ODU3 |        +------+        |
      +--------+ 1.25 +--------+ 2.5  +--------+ 2.5  +--------+

                   Figure 5: TS granularity in signaling

Belotti, et al.            Expires May 9, 2014                 [Page 10]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   In case an ODUk FA_LSP needs to be set up nesting another ODUj (as
   depicted in figure 5), there might be the need to know the hierarchy
   of nested LSPs in addition to TS granularity, to permit the
   penultimate hop (i.e.  C) choosing the correct interface towards the
   egress node or any intermediate node (i.e.  B) choosing the right
   path when performing ERO expansion.  This is not needed in case we
   allow bundling only component links with homogeneous hierarchies.  In
   case of specific implementation not specifying in the ERO the last
   hop interface, crank-back can be a solution.

   In a multi-stage multiplexing environment any layer can have a
   different TS granularity structure, e.g. in a multiplexing hierarchy
   such as ODU0->ODU2->ODU3, the ODU3 can be structured at TS
   granularity=2.5Gbps in order to support an ODU2 connection, but this
   ODU2 connection can be a tunnel for ODU0, and hence structured with
   1.25Gbps TS granularity.  Therefore any multiplexing level has to
   advertise its TS granularity capabilities in order to allow a correct
   path computation by the end nodes (both of the ODUk trail and of the
   H-LSP/FA).

   The following table shows the different mapping possibilities
   depending on the TS granularity types.  The client types are shown in
   the left column, while the different OPUk server and related TS
   granularities are listed in the top row.  The table also shows the
   relationship between the TS granularity and the payload type.

Belotti, et al.            Expires May 9, 2014                 [Page 11]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

                 +------------------------------------------------+
                 |    2.5G TS    ||          1.25G TS             |
                 | OPU2  | OPU3  || OPU1  | OPU2  | OPU3  | OPU4  |
         +-------+------------------------------------------------+
         |       |   -   |   -   ||  AMP  |  GMP  |  GMP  |  GMP  |
         | ODU0  |       |       ||PT=0x20|PT=0x21|PT=0x21|PT=0x21|
         +-------+------------------------------------------------+
         |       |  AMP  |  AMP  ||   -   |  AMP  |  AMP  |  GMP  |
         | ODU1  |PT=0x20|PT=0x20||       |PT=0x21|PT=0x21|PT=0x21|
         +-------+------------------------------------------------+
         |       |   -   |  AMP  ||   -   |   -   |  AMP  |  GMP  |
         | ODU2  |       |PT=0x20||       |       |PT=0x21|PT=0x21|
         +-------+------------------------------------------------+
         |       |   -   |   -   ||   -   |   -   |  GMP  |  GMP  |
         | ODU2e |       |       ||       |       |PT=0x21|PT=0x21|
         +-------+------------------------------------------------+
         |       |   -   |   -   ||   -   |   -   |   -   |  GMP  |
         | ODU3  |       |       ||       |       |       |PT=0x21|
         +-------+------------------------------------------------+
         |       |   -   |   -   ||   -   |  GMP  |  GMP  |  GMP  |
         | ODUfl |       |       ||       |PT=0x21|PT=0x21|PT=0x21|
         +-------+------------------------------------------------+

    Figure 6: ODUj into OPUk mapping types (Source: Table 7-10 [G.709-
                                  2012])

   Specific information could be defined in order to carry the
   multiplexing hierarchy and adaptation information (i.e.  TS
   granularity/PT, AMP/GMP) to enable precise path selection.  In this
   way, when the penultimate node (or the intermediate node performing
   ERO expansion) receives such object, together with the Traffic
   Parameters Object, it is possible to choose the correct interface
   towards the egress node.

   In conclusion both routing and signaling needs to be extended to
   appropriately represent the TS granularity/PT information.  Routing
   needs to represent a link's TS granularity and PT capabilities as
   well as the supported multiplexing hierarchy.  Signaling needs to
   represent the TS granularity/PT and multiplexing hierarchy encoding.

4.  Tributary Port Number

   [RFC4328] supports only the deprecated auto-MSI mode which assumes
   that the Tributary Port Number is automatically assigned in the
   transmit direction and not checked in the receive direction.

Belotti, et al.            Expires May 9, 2014                 [Page 12]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   As described in [G.709-2012] and [G.798], the OPUk overhead in an
   OTUk frame contains n (n = the total number of TSs of the ODUk) MSI
   (Multiplex Structure Identifier) bytes (in the form of multi-frame),
   each of which is used to indicate the association between tributary
   port number and tributary slot of the ODUk.

   The association between Tributary Port Number (TPN) and TS has to be
   configured by the control plane and checked by the data plane on each
   side of the link.  (Please refer to [OTN-FWK] for further details).
   As a consequence, the RSVP-TE signaling needs to be extended to
   support the TPN assignment function.

5.  Signal type

   From a routing perspective, GMPLS OSPF [RFC4203] and GMPLS IS-IS
   [RFC5307] only allow advertising [RFC4328] interfaces (single TS
   type) without the capability of providing precise information about
   bandwidth specific allocation.  For example, in case of link
   bundling, dividing the unreserved bandwidth by the MAX LSP bandwidth
   it is not possible to know the exact number of LSPs at MAX LSP
   bandwidth size that can be set up. (see example fig. 3)

   The lack of spatial allocation heavily impacts the restoration
   process, because the lack of information of free resources highly
   increases the number of crank-backs affecting network convergence
   time.

   Moreover actual tools provided by [RFC4203] and [RFC5307] only allow
   advertising signal types with fixed bandwidth and implicit hierarchy
   (e.g.  SDH/SONET networks) or variable bandwidth with no hierarchy
   (e.g. packet switching networks) but do not provide the means for
   advertising networks with mixed approach (e.g.  ODUflex CBR and
   ODUflex packet).

   For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX
   LSP bandwidth it is not possible to state whether the advertised link
   supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and
   ODUflex.  Such ambiguity is not present in SDH networks where the
   hierarchy is implicit and flexible containers like ODUFlex do not
   exist.  The issue could be resolved by declaring 1 Interface
   Switching Capability Descriptor (ISCD) for each signal type actually
   supported by the link.

   Supposing for example to have an equivalent ODU2 unreserved bandwidth
   in a TE-link (with bundling capability) distributed on 4 ODU1, it
   would be advertised via the ISCD in this way:

Belotti, et al.            Expires May 9, 2014                 [Page 13]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

      MAX LSP Bandwidth: ODU1

      MIN LSP Bandwidth: ODU1

      - Maximum Reservable Bandwidth (of the bundle) set to ODU2

      - Unreserved Bandwidth (of the bundle) set to ODU2

   In conclusion, the routing extensions defined in [RFC4203] and
   [RFC5307] require a different ISCD per signal type in order to
   advertise each supported container.  This motivates attempting to
   look for a more optimized solution, without proliferations of the
   number of ISCD advertised.

   Per [RFC2328], OSPF messages are directly encapsulated in IP
   datagrams and depend on IP fragmentation when transmitting packets
   larger than the network MTU.  [RFC2328] recommends that "IP
   fragmentation should be avoided whenever possible."  This
   recommendation further constraints solutions as OSPF does not support
   any generic mechanism to fragment OSPF Link State Advertisements
   (LSAs).  Even when used in IP environments IS-IS [RFC1195], does not
   support message sizes larger than a link's maximum frame size.

   With respect to link bundling [RFC4201], the utilization of the ISCD
   as it is, would not allow precise advertising of spatial bandwidth
   allocation information unless using only one component link per TE
   link.

   On the other hand, from a signaling point of view, [RFC4328]
   describes GMPLS signaling extensions to support the control of G.709
   OTNs defined before 2011 [G.709-2001].  However, [RFC4328] needs to
   be updated because it does not provide the means to signal all the
   new signal types and related mapping and multiplexing
   functionalities.

6.  Bit rate and tolerance

   In the current traffic parameters signaling, bit rate and tolerance
   are implicitly defined by the signal type.  ODUflex CBR and Packet
   can have variable bit rates(please refer to [OTN-FWK] table 2); hence
   signaling traffic parameters need to be upgraded.  With respect to
   tolerance there is no need to upgrade GMPLS protocols as a fixed
   value (+/-100 ppm or +/-20ppm depending on the signal type) is
   defined for each signal type.

Belotti, et al.            Expires May 9, 2014                 [Page 14]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

7.  Unreserved Resources

   Unreserved resources need to be advertised per priority and per
   signal type in order to allow the correct functioning of the
   restoration process.  [RFC4203] only allows advertising unreserved
   resources per priority, this leads not to know how many LSPs of a
   specific signal type can be restored.  As example it is possible to
   consider the scenario depicted in the following figure.

                  +------+ component link 1 +------+
                  |      +------------------+      |
                  |      | component link 2 |      |
                  |  N1  +------------------+  N2  |
                  |      | component link 3 |      |
                  |      +------------------+      |
                  +------+                  +---+--+

                   Figure 7: Concurrent path computation

   Consider the case where a TE link is composed of 3 ODU3 component
   links with 32TSs available on the first one, 24TSs on the second,
   24TSs on the third and supporting ODU2 and ODU3 signal types.  The
   node would advertise a TE link unreserved bandwidth equal to 80 TSs
   and a MAX LSP bandwidth equal to 32 TSs.  In case of restoration the
   network could try to restore 2 ODU3 (64TSs) in such TE-link while
   only a single ODU3 can be set up and a crank-back would be
   originated.  In more complex network scenarios the number of crank-
   backs can be much higher.

8.  Maximum LSP Bandwidth

   Maximum LSP bandwidth is currently advertised per priority in the
   common part of the ISCD.  Section 5 reviews some of the implications
   of advertising OTN network information using ISCDs, and identifies
   the need for a more optimized solution.  While strictly not required,
   such an optimization effort should also consider the optimization of
   the per priority maximum LSP bandwidth advertisement of both fixed
   and variable ODU types.

9.  Distinction between terminating and switching capability

   The capability advertised by an interface needs further distinction
   in order to separate termination and switching capabilities.  Due to
   internal constraints and/or limitations, the type of signal being

Belotti, et al.            Expires May 9, 2014                 [Page 15]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   advertised by an interface could be just switched (i.e. forwarded to
   switching matrix without multiplexing/demultiplexing actions), just
   terminated (demultiplexed) or both.  The following figures help
   explaining the switching and terminating capabilities.

             MATRIX                   LINE INTERFACE
       +-----------------+          +-----------------+
       |    +-------+    |   ODU2   |                 |
      ----->| ODU2  |----|----------|--------\        |
       |    +-------+    |          |      +----+     |
       |                 |          |       \__/      |
       |                 |          |        \/       |
       |    +-------+    |   ODU3   |         | ODU3  |
      ----->| ODU3  |----|----------|------\  |       |
       |    +-------+    |          |       \ |       |
       |                 |          |        \|       |
       |                 |          |      +----+     |
       |                 |          |       \__/      |
       |                 |          |        \/       |
       |                 |          |         ---------> OTU-3
       +-----------------+          +-----------------+

             Figure 8: Switching and Terminating capabilities

   The figure in the example shows a line interface able to:

      - Multiplex an ODU2 coming from the switching matrix into and ODU3
      and map it into an OTU3

      - Map an ODU3 coming from the switching matrix into an OTU3

   In this case the interface bandwidth advertised is ODU2 with
   switching capability and ODU3 with both switching and terminating
   capabilities.

   This piece of information needs to be advertised together with the
   related unreserved bandwidth and signal type.  As a consequence
   signaling must have the possibility to setup an LSP allowing the
   local selection of resources consistent with the limitations
   considered during the path computation.

   In figures 9 and 10 there are two examples of the need of
   termination/switching capability differentiation.  In both examples
   all nodes only support single-stage capability.  Figure 9 represents
   a scenario in which a failure on link B-C forces node A to calculate

Belotti, et al.            Expires May 9, 2014                 [Page 16]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   another ODU2 LSP path carrying ODU0 service along the nodes B-E-D.
   As node D is a single stage capable node, it is able to extract ODU0
   service only from ODU2 interface.  Node A has to know that from E to
   D exists an available OTU2 link from which node D can extract the
   ODU0 service.  This information is required in order to avoid that
   the OTU3 link is considered in the path computation.

               ODU0 transparently transported
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |           ODU2 LSP Carrying ODU0 service                  |
       |       |'''''''''''''''''''''''''''''''''''''''''''|       |
       |       |                                           |       |
       |  +----++  OTU2   +-----+   OTU2  +-----+  OTU2   ++----+  |
     ODU0 |     |  Link   |     |   Link  |     |  Link   |     | ODU0
     ---->|  A  |_________|  B  |_________|  C  |_________|  D  |---->
          |     |         |     |         |     |         |     |
          +-----+         +--+--+         +-----+         ++--+-+
                             |                             |  |
                         OTU3|                             |  |
                         Link|    +-----+__________________|  |
                             |    |     |    OTU3 Link        |
                             |____|  E  |                     |
                                  |     |_____________________|
                                  +-----+    OTU2 Link

       Figure 9: Switching and Terminating capabilities - Example 1

   Figure 10 addresses the scenario in which the restoration of the ODU2
   LSP (ABCD) is required.  The two bundled component links between B
   and E could be used, but the ODU2 over the OTU2 component link can
   only be terminated and not switched.  This implies that it cannot be
   used to restore the ODU2 LSP (ABCD).  However such ODU2 unreserved
   bandwidth must be advertised since it can be used for a different
   ODU2 LSP terminating on E, e.g.  (FBE).  Node A has to know that the
   ODU2 capability on the OTU2 link can only be terminated and that the
   restoration of (ABCD) can only be performed using the ODU2 bandwidth
   available on the OTU3 link.

Belotti, et al.            Expires May 9, 2014                 [Page 17]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

               ODU0 transparently transported
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |           ODU2 LSP Carrying ODU0 service                  |
       |       |'''''''''''''''''''''''''''''''''''''''''''|       |
       |       |                                           |       |
       |  +----++  OTU2   +-----+   OTU2  +-----+  OTU2   ++----+  |
     ODU0 |     |  Link   |     |   Link  |     |  Link   |     | ODU0
     ---->|  A  |_________|  B  |_________|  C  |_________|  D  |---->
          |     |         |     |         |     |         |     |
          +-----+         ++-+-++         +-----+         +--+--+
                           | | |                             |
                       OTU2| | |                             |
             +-----+   Link| | |   OTU3    +-----+           |
             |     |       | | |   Link    |     |           |
             |  F  |_______| | |___________|  E  |___________|
             |     |         |_____________|     | OTU2 Link
             +-----+            OTU2 Link  +-----+

       Figure 10: Switching and Terminating capabilities - Example 2

   The issue shown above is analyzed in an OTN context but it is a
   general technology independent GMPLS limitation.

10.  Priority Support

   [RFC4202] defines 8 priorities for resource availability and usage.
   As defined, each is advertised independent of the number of
   priorities supported by a network, and even unsupported priorities
   are included.  As is the case in Section 8, addressing any
   inefficiency with such advertisements is not required to support OTN
   networks.  But any such inefficiency should also be considered as
   part of the optimization effort identified in Section 5.

11.  Multi-stage multiplexing

   With reference to the [OTN-FWK], introduction of multi-stage
   multiplexing implies the advertisement of cascaded adaptation
   capabilities together with the matrix access constraints.  The
   structure defined by IETF for the advertisement of adaptation
   capabilities is Interface Adaptation Capability Descriptor (IACD) as
   in [RFC4202] and [RFC5339].

   With respect to routing, please note that in case of multi stage
   multiplexing hierarchy (e.g.  ODU1->ODU2->ODU3), not only the ODUk/

Belotti, et al.            Expires May 9, 2014                 [Page 18]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed,
   but also the intermediate one (ODU2).  This is a typical case of
   spatial allocation problem.

   Suppose in this scenario to have the following advertisement:

      Hierarchy: ODU1->ODU2->ODU3

      Number of ODU1==5

   The number of ODU1 suggests that it is possible to have an ODU2 FA,
   but it depends on the spatial allocation of such ODU1s.

   It is possible that 2 links are bundled together and 3
   ODU1->ODU2->ODU3 are available on a component link and 2 on the other
   one, in such a case no ODU2 FA could be set up.  The advertisement of
   the ODU2 is needed because in case of ODU1 spatial allocation (3+2),
   the ODU2 available bandwidth would be 0 (no ODU2 FA can be created),
   while in case of ODU1 spatial allocation (4+1) the ODU2 available
   bandwidth would be 1 (1 ODU2 FA can be created).

   What said above implies augmenting both the ISCD and the IACD.

12.  Generalized Label

   The ODUk label format defined in [RFC4328] could be updated to
   support new signal types defined in [G.709-2012] but it would be
   difficult to further enhance it to support possible new signal types.

   Furthermore such label format may have scalability issues due to the
   high number of labels needed when signaling large LSPs.  For example,
   when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it
   would require the utilization of thirty-one labels (31*4*8=992 bits)
   to be allocated while an ODUflex into an ODU4 may need up to eighty
   labels (80*4*8=2560 bits).

   A new flexible and scalable ODUk label format needs to be defined.

13.  Security Considerations

   This document provides an evaluation of OTN requirements against
   actual routing [RFC4202], [RFC4203] and [RFC5307] and signaling
   mechanism [RFC3471], [RFC3473] and [RFC4328]in GMPLS.

   This document defines new types of information to be carried that
   described OTN containers and hierarchies.  It does not define any new

Belotti, et al.            Expires May 9, 2014                 [Page 19]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   protocol elements and from a security standpoint this memo does not
   introduce further risks with respect to the information that can be
   currently conveyed via GMPLS protocols.  For a general discussion on
   MPLS and GMPLS-related security issues, see the MPLS/GMPLS security
   framework [RFC5920].

14.  IANA Considerations

   This informational document does not make any requests for IANA
   action.

15.  Contributors

      Jonathan Sadler, Tellabs

      EMail: jonathan.sadler@tellabs.com

      John Drake, Juniper

      EMail: jdrake@juniper.net

      Francesco Fondelli

      Ericsson

      Via Moruzzi 1

      Pisa - 56100

      Email: francesco.fondelli@ericsson.com

16.  Acknowledgements

   The authors would like to thank Lou Berger, Eve Varma and Sergio
   Lanzone for their precious collaboration and review.

17.  References

Belotti, et al.            Expires May 9, 2014                 [Page 20]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

17.1.  Normative References

   [G.709-2001]
              ITU-T, "Rec G.709, version 1", approved by ITU-T in 2001.

   [G.709-2012]
              ITU-T, "Rec G.709, version 4", approved by ITU-T in 2012.

   [G.798]    ITU-T, "Revised version of G.798 Characteristics of
              optical transport network hierarchy equipment functional
              blocks", consented by ITU-T on December 2012.

   [G.872]    ITU-T, "Revised version of G.872: Architecture of optical
              transport networks for consent", consented by ITU-T on
              December 2012.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

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

   [RFC4203]  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
              of Generalized Multi-Protocol Label Switching (GMPLS)",
              RFC 4203, October 2005.

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

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

   [RFC5339]  Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing
              GMPLS Protocols against Multi-Layer and Multi-Region
              Networks (MLN/MRN)", RFC 5339, September 2008.

Belotti, et al.            Expires May 9, 2014                 [Page 21]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

17.2.  Informative References

   [OTN-FWK]  F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework
              for GMPLS and PCE Control of G.709 Optical Transport
              Networks", work in
              progress draft-ietf-ccamp-gmpls-g709-framework-14, August
              2013.

   [OTN-OSPF]
              D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot
              ti, "Traffic Engineering Extensions to OSPF for
              Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN
              Networks", work in
              progress draft-ietf-ccamp-gmpls-ospf-g709v3-07, June 2013.

   [OTN-RSVP]
              F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan,
              "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Extensions for the evolving G.709 Optical
              Transport Networks Control, work in progress
              draft-ietf-ccamp-gmpls-signaling-g709v3-11", August 2012.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC4201]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
              in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

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

Authors' Addresses

   Sergio Belotti (editor)
   Alcatel-Lucent
   Via Trento, 30
   Vimercate
   Italy

   Email: sergio.belotti@alcatel-lucent.com

Belotti, et al.            Expires May 9, 2014                 [Page 22]
Internet-Draft    GMPLS evaluation against G.709v3 OTN     November 2013

   Pietro Vittorio Grandi
   Alcatel-Lucent
   Via Trento, 30
   Vimercate
   Italy

   Email: pietro_vittorio.grandi@alcatel-lucent.com

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

   Email: daniele.ceccarelli@ericsson.com

   Diego Caviglia
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: diego.caviglia@ericsson.com

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28972912

   Email: zhangfatai@huawei.com

   Dan Li
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28973237

   Email: danli@huawei.com

Belotti, et al.            Expires May 9, 2014                 [Page 23]