CCAMP Working Group
Internet Engineering Task Force (IETF)                   S. Belotti, Ed.
Internet-Draft
Request for Comments: 7096                                     P. Grandi
Intended status:
Category: Informational                                   Alcatel-Lucent
Expires: May 9, 2014
ISSN: 2070-1721                                       D. Ceccarelli, Ed.
                                                             D. Caviglia
                                                                Ericsson
                                                                F. Zhang
                                                                   D. Li
                                                     Huawei Technologies
                                                        November 5, 2013
                                                            January 2014

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

Abstract

   ITU-T recommendation [G.709-2012] G.709-2012 has introduced new fixed and flexible
   Optical channel 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. OTNs.

Status of this This Memo

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

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

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

   Internet-Drafts are draft documents valid 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 maximum candidate for any level of Internet
   Standard; see Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It 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.
   http://www.rfc-editor.org/info/rfc7096.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

1.  Introduction

   GMPLS routing [RFC4203] [RFC5307] and signaling, as defined by [RFC4203], [RFC5307], signaling [RFC3473] and [RFC4328], provides [RFC4328]
   provide the mechanisms for basic GMPLS control of Optical Transport
   Networks (OTNs) based on the 2001 revision of the G.709 specification. specification
   [G.709-2001].  The 2012 revision of the G.709
   specification, [G.709-2012], specification
   [G.709-2012] includes new OTN features which that 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]. [RFC7062].  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 OTN-layered structure is comprised of the digital path
   layer (ODU) and the digital section layer (OTU).  An OTU (Optical
   channel Transport Unit) section layer supports one ODU path layer as
   a 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, and 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
   flexible ODU (ODUflex) are explained in G.709.  G.872 [G.872]
   provides two tables defining mapping and multiplexing capabilities of
   OTNs, which are reported below.

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

               Figure 1: OTN mapping capability Mapping Capability
       +=================================+=========================+
       |           ODU client            |       ODU server        |
       +---------------------------------+-------------------------+
       |        1.25 Gbps Gbit/s client       |                         |
       +---------------------------------+          ODU0           |
       |                 -               |                         |
       +=================================+=========================+
       |         2.5 Gbps Gbit/s client       |                         |
       +---------------------------------+          ODU1           |
       |              ODU0               |                         |
       +=================================+=========================+
       |         10 Gbps Gbit/s client        |                         |
       +---------------------------------+          ODU2           |
       |        ODU0,ODU1,ODUflex        |                         |
       +=================================+=========================+
       |        10.3125 Gbps Gbit/s client    |                         |
       +---------------------------------+          ODU2e          |
       |                 -               |                         |
       +=================================+=========================+
       |         40 Gbps Gbit/s client        |                         |
       +---------------------------------+          ODU3           |
       |  ODU0,ODU1,ODU2,ODU2e,ODUflex   |                         |
       +=================================+=========================+
       |        100 Gbps Gbit/s 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
       |GFP-F** mapped packet clients from|    |          ODUflex        |
       |1.25
       |from 1.25 Gbit/s to 100 Gbit/s.  |                         |
       +---------------------------------+                         |
       |                 -               |                         |
       +=================================+=========================+
       (*) - Constant Bit Rate
       (**) - Generic Framing Procedure - Framed (GFP-F)

                   Figure 2: OTN multiplexing capability Multiplexing Capability

   In the following, the terms ODUj Optical channel Data Unit-j (ODUj) and ODUk
   Optical channel Data Unit-k (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 Optical channel Transport Unit-k (OTUk) section,
   with the same path and section being at
   the same rate rates as that of the connection
   service (see Table Figure 1).  In this case, an entire lambda of capacity
   is consumed in transporting 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 Figure 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], [RFC7062], client ODUk connection services can be
   transported over:

      o

   Case A) A:  one or more wavelength sub-networks subnetworks connected by optical
      links
            links, or

      o

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

      o granularity), or

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

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

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

3.  Tributary Slot Granularity

   G.709 defines two types of Tributary Slot (TS) granularity. granularities.  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:

      -

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

      -

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

3.1.  Data Plane  Data-Plane Considerations

3.1.1.  Payload Type and TS granularity relationship Granularity Relationship

   As defined in G.709 G.709, an ODUk container consist consists of an Optical channel
   Payload
   Unit Unit-k (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 overhead, there is the payload structure
   identifier (PSI) that includes the payload type (PT).  The payload type (PT) 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
   the frame alignment overhead and then mapped into an Optical channel
   Data Tributary Unit (ODTU).  Two different types of ODTU ODTUs are
   defined:

      -

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

      - [G.709-2012].

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

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

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

      - structures for ODTUGx:

   o  Value 0x20: supporting ODTUjk only,

      - only

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

   The distinction is needed for OPUk with K =2 k=2 or 3, 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. PT=0x20 (see table Figure 6).The 6).  The relationship
   between PT and TS granularity, granularity is in due to the fact that the two
   different ODTUGk types discriminated by PT and OPUk are characterized
   by two different TS granularities of the related OPUk, the former at
   2.5Gbps,
   2.5 Gbit/s and the latter at 1.25Gbps. 1.25 Gbit/s.

   In order to complete the picture, in the PSI OH OH, there is also the
   Multiplex Structure Identifier (MSI) that provides the information on
   which tributary slots of 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 ODTUk.ts   |-----Client
        |OPUk|     +--------+      +------------+
        |    |
        |    |     +--------+      +------------+
        |    |     |        |------| ODTUjk     |-----Client
        |    |-----|        |      +-----.------+
        +----+     | ODTUGk |            .
                   | PT=0x20|      +-----.------+
                   |        |------| ODTUjk     |-----Client
                   +--------+      +------------+

                     Figure 3: OTN client multiplexing Client Multiplexing

3.1.2.  Fall-back procedure  Fallback Procedure

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

   Therefore, in order to let the NE Network Element (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 one is PT=0x21, the node must fallback fall
   back to PT=0x20.  In this case case, the fallback process makes the system self-consistent
   self-consistent, and the only reason for signaling the TS granularity
   is to provide the correct label
   (i.e. (i.e., the 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 Resource Reservation Protocol-
   Traffic Engineering (RSVP-TE) consequent actions need to be defined
   in case of a TS mismatch need to be defined. mismatch.

3.2.  Control Plane considerations  Control-Plane Considerations

   When setting up an ODUj over an ODUk, it is possible to identify two
   types of TS granularity (TSG), (TSG): the server and the client one. client.  The server
   TS granularity is used to map an end to end end-to-end ODUj onto a server ODUk
   LSP or links.  This parameter cannot be influenced in any way from
   the ODUj LSP: the ODUj LSP will be mapped on tributary slots
   available on the different links/ODUk 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) links / Forwarding Adjacencies (FAs) structured with 1.25Gbps 1.25
   Gbit/s or 2.5Gbps 2.5 Gbit/s TS granularity is completely transparent to the end to end
   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 nodes, and this is the only thing that the ODUj has to guarantee.

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

                            ODU1-LSP
           .........................................
      TSG-C|                                       |TSG-C
       1.25|                   ODU2-H-LSP          |1.25
           +------------X--------------------------+ Gbit/s
     Gbit/s+------------X--------------------------+
           |       TSG-S|                          |TSG-S
           |         2.5|                          |2.5 Gbit/s
           |            |      Gbit/s|       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 Granularity Example
   In this scenario, an ODU3 LSP is setup set up from node nodes B to Z.  Node B
   has an old interface that is able to support 2.5Gbps 2.5 Gbit/s TS granularity, hence
   granularity; hence, only client TS granularity equal to 2.5Gbps 2.5 Gbit/s
   can be exported to ODU3 H-LSP
   possible H-LSP-possible clients.  An ODU2 LSP is setup set
   up from node nodes A to node Z with client TS granularity 1.25Gbps 1.25 Gbit/s signaled
   and exported towards clients.  The ODU2 LSP is carried by ODU3 H-LSP
   from nodes B to Z.  Due to the limitations of the old node B
   interface, the ODU2 LSP is mapped with
   2.5Gbps 2.5 Gbit/s TS granularity over
   the ODU3 H-LSP.  Then  Then, an ODU1 LSP is
   setup set up from nodes A to Z, which
   is carried by the ODU2 H-LSP and mapped over it using
   a 1.25Gbps 1.25 Gbit/s TS
   granularity.

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

   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 Figure 4).

   Moreover, also TS granularity information also needs to be signaled.
   Consider as example  As
   an example, consider the setup of an ODU3 forwarding adjacency that
   is going to carry an ODU0, hence ODU0; hence, the support of 1.25Gbps 1.25 Gbit/s TS is
   needed.  The information related to the TS granularity has to be
   carried in the signaling to permit node C (see figure Figure 5) to choose
   the right one among the different interfaces (with different TS granularitys)
   granularities) 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 Granularity in signaling Signaling

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

   In a multi-stage multiplexing environment environment, any layer can have a
   different TS granularity structure, e.g. structure; for example, in a multiplexing
   hierarchy such as ODU0->ODU2->ODU3, the ODU3 can be structured at TS
   granularity=2.5Gbps
   granularity = 2.5 Gbit/s in order to support an ODU2 connection, but
   this ODU2 connection can be a tunnel for ODU0, and hence ODU0 and, hence, structured
   with
   1.25Gbps 1.25 Gbit/s TS granularity.  Therefore  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.

                 +------------------------------------------------+
                 |    2.5G 2.5 Gbit/s TS ||          1.25G     1.25 Gbit/s 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 Mapping Types
                    (Source: Table 7-10 [G.709-
                                  2012]) [G.709-2012], Tables7-10)

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

   In conclusion conclusion, both routing and signaling needs need 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 mode, which assumes
   that the Tributary Port Number (TPN) is automatically assigned in the
   transmit direction and is not checked in the receive direction.

   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), multiframe), each of which is used to indicate
   the association between tributary
   port number the TPN and tributary slot TS of the ODUk.

   The association between Tributary Port Number (TPN) the 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] [RFC7062] for further details). details.)  As a consequence,
   the RSVP-TE signaling needs to be extended to support the TPN
   assignment function.

5.  Signal type Type

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

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

   Moreover

   Moreover, actual tools provided by [RFC4203] and [RFC5307] only allow
   advertising signal types with fixed bandwidth and implicit hierarchy
   (e.g.  SDH/SONET networks)
   (e.g., Synchronous Digital Hierarchy (SDH) networks / Synchronous
   Optical Networks (SONETs)) or variable bandwidth with no hierarchy
   (e.g.
   (e.g., packet switching networks) but networks); but, they do not provide the means
   for advertising networks with a mixed approach (e.g. (e.g., ODUflex CBR
   Constant Bit Rate (CBR) and ODUflex packet).

   For example, when advertising ODU0 as MIN LSP bandwidth and ODU4 as
   MAX LSP bandwidth bandwidth, it is not possible to state whether the advertised
   link supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 ODU0, and
   ODUflex.  Such ambiguity is not present in SDH networks where the
   hierarchy is implicit and flexible containers like ODUFlex 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

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

      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 an attempt to
   look for a more optimized solution, solution without proliferations proliferation of the
   number of ISCD ISCDs advertised.

   Per [RFC2328], OSPF messages are directly encapsulated in IP
   datagrams and depend on IP fragmentation when transmitting packets
   larger than the network network's MTU.  [RFC2328] recommends that "IP
   fragmentation should be avoided whenever possible." possible".  This
   recommendation further constraints constrains solutions as since OSPF does not
   support any generic mechanism to fragment OSPF Link State
   Advertisements (LSAs).  Even when used in IP environments environments, IS-IS [RFC1195],
   [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, 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 Rate and tolerance Tolerance

   In the current traffic parameters signaling, bit rate and tolerance
   are implicitly defined by the signal type.  ODUflex CBR and Packet ODUflex
   packet can have variable bit rates(please rates (please refer to [OTN-FWK] table [RFC7062],
   Table 2); hence hence, signaling traffic parameters need to be upgraded.

   With respect to
   tolerance tolerance, there is no need to upgrade GMPLS
   protocols as a fixed value (+/-100 ppm parts per million (ppm) or +/-20ppm +/-20
   ppm depending on the signal type) is defined for each signal type.

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, priority; this leads not to know uncertainty about how many LSPs
   of a specific signal type can be restored.  As example it is possible to an example, consider
   the scenario depicted in the following figure.

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

                   Figure 7: Concurrent path computation Path Computation

   Consider the case where a TE link is composed of 3 three ODU3 component
   links with 32TSs 32 TSs available on the first one, 24TSs 24 TSs on the second,
   24TSs
   and 24 TSs on the third and is supporting ODU2 and ODU3 signal types.
   The node would advertise a TE link with unreserved bandwidth equal to
   80 TSs and a MAX LSP bandwidth equal to 32 TSs.  In case of restoration
   restoration, the network could try to restore 2 ODU3 (64TSs) two ODU3s (64 TSs) in
   such TE-link a TE link while only a single ODU3 can be set up up, and a crank-back
   crankback would be originated.  In more complex network scenarios scenarios,
   the number of crank-
   backs crankbacks 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, 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 per-
   priority maximum LSP bandwidth advertisement of both fixed and
   variable ODU types.

9.  Distinction between terminating Terminating and switching capability Switching Capabilities

   The capability advertised by an interface needs further distinction
   in order to separate termination terminating and switching capabilities.  Due to
   internal constraints and/or limitations, the type of signal being
   advertised by an interface could be just be switched (i.e. (i.e., forwarded to
   the switching matrix without multiplexing/demultiplexing actions), just
   terminated (demultiplexed) (demultiplexed), or both.  The following figures help
   explaining
   explain the switching and terminating capabilities.

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

         Figure 8: Switching and Terminating capabilities Capabilities

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

      -

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

      -

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

   In this case 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 consequence,
   signaling must have the possibility capability to setup set up an LSP LSP, allowing the
   local selection of resources to be consistent with the limitations
   considered during the path computation.

   In figures Figure 9 and 10 Figure 10, there are two examples of the need of
   termination/switching terminating/
   switching capability differentiation.  In both examples 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 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 the 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 being considered in the path computation.

               ODU0 transparently transported Transparently Transported
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |           ODU2 LSP Carrying ODU0 service 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 Capabilities - Example 1

   Figure 10 addresses the scenario in which the restoration of the ODU2
   LSP (ABCD) (A-B-C-D) 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 (A-B-C-D).  However, such ODU2
   unreserved bandwidth must be advertised since it can be used for a
   different ODU2 LSP terminating on E, e.g.  (FBE). e.g., F-B-E.  Node A has to know
   that the ODU2 capability on the OTU2 link can only be terminated terminated, and
   that the restoration of (ABCD) A-B-C-D can only be performed using the ODU2
   bandwidth available on the OTU3 link.

               ODU0 transparently transported Transparently Transported
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       |           ODU2 LSP Carrying ODU0 service 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 Capabilities - Example 2

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

10.  Priority Support

   [RFC4202] defines 8 eight 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
   OTNs.  But, any such inefficiency should also be considered as part
   of the optimization effort identified in Section 5.

11.  Multi-stage multiplexing Multiplexing

   With reference to [RFC7062], 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 the IETF for the advertisement of adaptation
   capabilities is the Interface Adaptation Capability Descriptor (IACD)
   (IACD), as defined in [RFC4202] and [RFC5339]. [RFC6001].

   With respect to routing, please note that in case of multi stage multi-stage
   multiplexing hierarchy (e.g. (e.g., ODU1->ODU2->ODU3), not only the ODUk/
   OTUk bandwidth (ODU3) and service layer service-layer bandwidth (ODU1) are needed, needed
   but also the intermediate one (ODU2).  This is a typical case of a
   spatial allocation problem.

   Suppose in

   In this scenario to have scenario, suppose 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 two links are bundled together and 3 three
   ODU1->ODU2->ODU3 are available on a component link and 2 two on the
   other
   one, one; in such a case no case, the ODU2 FA could not 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 (ODU2 FA can
   cannot be created), while in case of ODU1 spatial allocation (4+1) (4+1),
   the ODU2 available bandwidth would be 1 (1 ODU2 FA can be created).

   What said

   The information stated 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 as defined in [G.709-2012] [G.709-2012], but it would be
   difficult to further enhance it to support possible new signal types.

   Furthermore

   Furthermore, such a 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 1.25 Gbit/s
   tributary slots, it would require the utilization of thirty-one 31 labels
   (31*4*8=992 bits) to be allocated allocated, while an ODUflex into an ODU4 may
   need up to eighty 80 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] ([RFC4202], [RFC4203], and [RFC5307] [RFC5307]) and signaling
   mechanism [RFC3471], [RFC3473]
   mechanisms ([RFC3471], [RFC3473], and [RFC4328]in [RFC4328]) in GMPLS.

   This document defines new types of information to be carried that
   described
   describes OTN containers and hierarchies.  It does not define any new
   protocol elements elements, and from a security standpoint 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, Sadler
   Tellabs
   EMail: jonathan.sadler@tellabs.com

   John Drake, Drake
   Juniper
   EMail: jdrake@juniper.net

   Francesco Fondelli
   Ericsson
   Via Moruzzi 1
   Pisa - 56100

      Email:
   EMail: francesco.fondelli@ericsson.com

16.

15.  Acknowledgements

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

17.

16.  References

17.1.

16.1.  Normative References

   [G.709-2001]   ITU-T, "Rec G.709, version 1", approved by ITU-T in "Interfaces for the Optical Transport Network
                  (OTN)", G.709/Y.1331 Recommendation, February 2001.

   [G.709-2012]   ITU-T, "Rec G.709, version 4", approved by ITU-T in "Interfaces for the Optical Transport Network
                  (OTN)", G.709/Y.1331 Recommendation, February 2012.

   [G.798]        ITU-T, "Revised version "Characteristics of Optical Transport Network
                  Hierarchy Equipment Functional Blocks", G.798 Characteristics of
              optical transport network hierarchy equipment functional
              blocks", consented by ITU-T on
                  Recommendation, December 2012.

   [G.872]        ITU-T, "Revised version "Architecture of G.872: Architecture of optical
              transport networks for consent", consented by ITU-T on
              December Optical Transport Networks",
                  G.872 Recommendation, October 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]

   [RFC6001]      Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
                  Brungard, D., and JL. Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing
              GMPLS Protocols against "Generalized MPLS
                  (GMPLS) Protocol Extensions for Multi-Layer and
                  Multi-Region Networks (MLN/MRN)", (MLN/ MRN)", RFC 5339, September 2008.

17.2. 6001, October
                  2010.

16.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,     Ceccarelli, D., Zhang, F., Belotti, S., Rao, R., and
                  J.  Drake, "Traffic Engineering Extensions to OSPF for
                  Generalized MPLS (GMPLS) Control of Evolutive Evolving G.709 OTN
                  Networks", work Work in
              progress draft-ietf-ccamp-gmpls-ospf-g709v3-07, June Progress, November 2013.

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

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

   [RFC7062]      Zhang, F., Li, D., Li, H., Belotti, S., and D.
                  Ceccarelli, "Framework for GMPLS and PCE Control of
                  G.709 Optical Transport Networks", RFC 7062, November
                  2013.

Authors' Addresses

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

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

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

   Email:
   EMail: pietro_vittorio.grandi@alcatel-lucent.com

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

   Email:
   EMail: daniele.ceccarelli@ericsson.com

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

   Email:
   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
   Shenzhen  518129
   P.R. China
   Phone: +86-755-28972912

   Email:
   EMail: zhangfatai@huawei.com

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

   Email:
   EMail: danli@huawei.com