CCAMP Working Group
Internet Engineering Task Force (IETF)                D. Ceccarelli, Ed.
Internet-Draft
Request for Comments: 7138                                      Ericsson
Intended status:
Category: Standards Track                                       F. Zhang
Expires: June 14, 2014
ISSN: 2070-1721                                      Huawei Technologies
                                                              S. Belotti
                                                          Alcatel-Lucent
                                                                  R. Rao
                                                    Infinera Corporation
                                                                J. Drake
                                                                 Juniper
                                                       December 11, 2013
                                                              March 2014

                 Traffic Engineering Extensions to OSPF
     for Generalized MPLS (GMPLS) GMPLS Control of Evolving G.709 OTN Optical Transport Networks
                 draft-ietf-ccamp-gmpls-ospf-g709v3-13

Abstract

   This document describes Open Shortest Path First - Traffic
   Engineering (OSPF-TE) routing protocol extensions to support
   Generalized MPLS (GMPLS) GMPLS
   control of Optical Transport Networks (OTN) (OTNs) specified in ITU-T
   Recommendation G.709 as published in 2012.  It extends mechanisms
   defined in RFC4203. RFC 4203.

Status of this This Memo

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

   Internet-Drafts are working documents an Internet Standards Track document.

   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 a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

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

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 ....................................................3
      1.1. Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3 ................................................3
   2. OSPF-TE Extensions . . . . . . . . . . . . . . . . . . . . . .  3 ..............................................3
   3. TE-Link Representation . . . . . . . . . . . . . . . . . . . .  5 ..........................................5
   4. ISCD format extensions . . . . . . . . . . . . . . . . . . . .  5 Format Extensions ..........................................5
      4.1. Switching Capability Specific Information  . . . . . . . .  7 ..................7
           4.1.1. Switching Capability Specific Information
                  for
               fixed containers . . . . . . . . . . . . . . . . . . .  8 Fixed Containers ................................8
           4.1.2. Switching Capability Specific Information
                  for
               variable containers  . . . . . . . . . . . . . . . . .  8 Variable Containers .............................9
           4.1.3. Switching Capability Specific Information - --
                  Field
               values Values and explanation . . . . . . . . . . . . . . . .  9 Explanation ........................9
   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 .......................................................12
      5.1. MAX LSP Bandwidth fields Fields in the ISCD . . . . . . . . . . . 12 ......................12
      5.2. Example of T,S T, S, and TS granularity utilization  . . . . . . 14 Granularity Utilization ...........15
           5.2.1. Example of different Different TS Granularities  . . . . . . . . 15 ..............16
      5.3. Example of ODUflex advertisement . . . . . . . . . . . . . 18 Advertisement ..........................19
      5.4. Example of single stage muxing . . . . . . . . . . . . . . 20 Single-Stage Muxing ............................21
      5.5. Example of multi stage muxing - Multi-Stage Muxing -- Unbundled link . . . . . . 22 Link ...........22
      5.6. Example of multi stage muxing - Multi-Stage Muxing -- Bundled links  . . . . . . 24 Links ............24
      5.7. Example of component links Component Links with non-homogeneous
           hierarchies  . . . . . . . . . . . . . . . . . . . . . . . 25 Non-Homogeneous
           Hierarchies ...............................................26
   6. OSPFv2 scalability . . . . . . . . . . . . . . . . . . . . . . 28 Scalability .............................................28
   7. Compatibility  . . . . . . . . . . . . . . . . . . . . . . . . 29 ..................................................29
   8. Security Considerations  . . . . . . . . . . . . . . . . . . . 29 ........................................29
   9. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29 ............................................30
      9.1. Switching types  . . . . . . . . . . . . . . . . . . . . . 30 Types ...........................................30
      9.2. New sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 30 Sub-TLVs ..............................................30
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 ..................................................31
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 ..............................................32
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 ....................................................32
      12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 .....................................32
      12.2. Informative References . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 ...................................33

1.  Introduction

   G.709 ("Interfaces for the Optical Transport Network (OTN) (OTN)")
   [G.709-2012] includes new fixed and flexible ODU (Optical channel
   Data Unit) containers, includes two types of
   Tributary Slots tributary slots (i.e., 1.25Gbps
   1.25 Gbps and 2.5Gbps), 2.5 Gbps), and supports various multiplexing
   relationships (e.g., ODUj multiplexed into ODUk (j<k)), two different
   tributary slots for ODUk (K=1, 2, 3) 3), and the ODUflex service type.
   In order to present advertise this information in routing, this document
   provides encoding specific to OTN technology specific encoding for use in GMPLS OSPF-TE
   as defined in [RFC4203].

   For a short overview of OTN evolution and implications of OTN
   requirements on GMPLS routing routing, please refer to [OTN-FWK]. [RFC7062].  The
   information model and an evaluation against the current solution are
   provided in [OTN-INFO]. [RFC7096].  The reader is supposed to be familiar with
   both of these documents.

   Routing information for Optical Channel Layer (OCh) layer (i.e.,
   wavelength) is beyond the scope of this document.  Please refer to
   [RFC6163] and [RFC6566] for further information.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  OSPF-TE Extensions

   In terms of GMPLS based GMPLS-based OTN networks, each OTUk Optical channel Transport
   Unit-k (OTUk) can be viewed as a component link, and each component
   link can carry one or more types of ODUj (j<k).

   Each TE Link TE-Link State Advertisement (LSA) can carry a top-level link
   Type Length Value (TLV) TLV
   with several nested sub-TLVs to describe different attributes of a TE link.
   TE-Link.  Two top-level TLVs are defined in
   [RFC3630]. [RFC3630]: (1) The Router
   Address TLV (referred to as the Node TLV) and (2) the TE link TE-Link TLV.
   One or more sub-TLVs can be nested into the two top-level TLVs.  The
   sub-TLV set for the two top-level TLVs are also defined in [RFC3630]
   and [RFC4203].

   As discussed in [OTN-FWK] [RFC7062] and [OTN-INFO], [RFC7096], OSPF-TE must be extended to
   be able to advertise the termination and switching capabilities Switching Capabilities of
   each different ODUj and ODUk/OTUk (Optical Transport Unit) and the
   advertisement of related multiplexing capabilities.  These
   capabilities are carried in the Switching Capability specific
   information field of the Interface Switching Capability Descriptor
   (ISCD) Switching Capability-specific information field using formats defined in this document.  As discussed in [SWCAP-
   UPDT],
   [RFC7062], the use of a technology specific technology-specific Switching Capability-specific Capability
   specific information field necessitates the definition of a new
   Switching Capability value and associated new Switching Capability.

   In the following, we will use ODUj to indicate a service type that is
   multiplexed into a higher order higher-order (HO) ODU, ODUk to indicate a higher higher-
   order ODU including an ODUj ODUj, and ODUk/OTUk to indicate the layer
   mapped into the OTUk.  Moreover, ODUj(S) and ODUk(S) are used to
   indicate the ODUj and ODUk supporting switching capability Switching Capability only, and
   the ODUj->ODUk format is used to indicate the ODUj into ODUk ODUj-into-ODUk
   multiplexing capability.

   This notation can be repeated as needed depending on the number of
   multiplexing levels.  In the following, the term "multiplexing tree"
   is used to identify a multiplexing hierarchy where the root is always
   a server ODUk/OTUk and any other supported multiplexed container is
   represented with increasing granularity until reaching the leaf of
   the tree.  The tree can be structured with more than one branch if
   the server ODUk/OTUk supports more than one hierarchy.

   For example, if a multiplexing hierarchy like the following one is
   considered:

             ODU2 ODU0    ODUflex ODU0
                \ /            \ /
                 |              |
               ODU3           ODU2
                  \            /
                   \          /
                    \        /
                     \      /
                       ODU4

   The

   the ODU4 is the root of the muxing tree, tree; ODU3 and ODU2 are containers
   directly multiplexed into the server server; and ODU2 and then ODU2, ODU0 are the
   leaves of the ODU3 branch, while ODUflex and ODU0 are the leaves of
   the ODU2 one.  This means that it is possible to have the following
   multiplexing capabilities:

       ODU2->ODU3->ODU4
       ODU0->ODU3->ODU4
       ODUflex->ODU2->ODU4
       ODU0->ODU2->ODU4

3.  TE-Link Representation

   G.709 ODUk/OTUk Links links are represented as TE-Links in GMPLS Traffic
   Engineering Topology for supporting ODUj layer switching.  These TE-
   Links can be modeled in multiple ways.

   OTUk physical Link(s) link(s) can be modeled as a TE-Link(s).  Figure 1 below
   provides an illustration of one hop one-hop OTUk TE-links. TE-Links.

           +-------+               +-------+               +-------+
           |  OTN  |               |  OTN  |               |  OTN  |
           |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
           |   A   |               |   B   |               |   C   |
           +-------+               +-------+               +-------+

                   |<-- TE-Link -->|       |<-- TE-Link -->|

                          Figure 1: OTUk TE-Links

   It is possible to create TE-Links that span more than one hop by
   creating FAs forwarding adjacencies (FAs) between non-adjacent nodes (see
   Figure 2).  As in the
   one hop one-hop case, multiple hop TE-links multiple-hop TE-Links advertise
   the ODU switching capacity. Switching Capability.

           +-------+               +-------+               +-------+
           |  OTN  |               |  OTN  |               |  OTN  |
           |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
           |   A   |               |   B   |               |   C   |
           +-------+               +-------+               +-------+
                                 ODUk Switched

                   |<------------- ODUk Link ------------->|
                   |<-------------- TE-Link--------------->|

                      Figure 2: Multiple hop Multiple-Hop TE-Link

4.  ISCD format extensions Format Extensions

   The ISCD describes the switching capability Switching Capability of an interface and is
   defined in [RFC4203].  This document defines a new Switching
   Capability value for OTN [G.709-2012] as follows:

   Value          Type
   -----          ----
   110 (TBA by IANA)            OTN-TDM capable (OTN-TDM)
   When supporting the extensions defined in this document, for both
   fixed and flexible ODUs, the Switching Capability and Encoding values
   MUST be used as follows:

   -

   o  Switching Capability = OTN-TDM
   -

   o  Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]

   The same switching type Switching Type and encoding values must be used for both
   fixed and flexible ODUs.  When Switching Capability and Encoding
   fields are set to values as stated above, the Interface Switching
   Capability Descriptor MUST be interpreted as defined in [RFC4203].

   Maximum LSP Bandwidth

   The MAX LSP Bandwidth field is used according to [RFC4203]: [RFC4203], i.e., 0
   <= MAX LSP Bandwidth <= ODUk/OTUk, and intermediate values are those
   on the branch of the OTN switching hierarchy supported by the
   interface.  For example, in the OTU4 link it could be possible to
   have ODU4 as MAX LSP Bandwidth for some priorities, ODU3 for others,
   ODU2 for some others, etc.  The bandwidth unit is in bytes per second in bytes/second and
   the encoding MUST be in Institute of Electrical and Electronic Engineers
   (IEEE) IEEE floating point format.  The discrete
   values for various ODUs are shown in the table below (please note
   that there are 1000 bits in a kbit kilobit according to normal practices
   in telecommunications).

+---------------------+------------------------------+-----------------+

   +-------------------+-----------------------------+-----------------+
   |     ODU Type      |    ODU nominal bit rate     |Value in Byte/Sec|
   |                   |                             |(floating p. val)|
+---------------------+------------------------------+-----------------+
   +-------------------+-----------------------------+-----------------+
   |       ODU0        |      1,244,160 kbit/s kbps         |    0x4D1450C0   |
   |       ODU1        | 239/238 x 2,488,320 kbit/s kbps    |    0x4D94F048   |
   |       ODU2        | 239/237 x 9,953,280 kbit/s kbps    |    0x4E959129   |
   |       ODU3        | 239/236 x 39,813,120 kbit/s kbps   |    0x4F963367   |
   |       ODU4        | 239/227 x 99,532,800 kbit/s kbps   |    0x504331E3   |
   |       ODU2e       | 239/237 x 10,312,500 kbit/s kbps   |    0x4E9AF70A   |
   |                   |                             |                 |
   |  ODUflex for CBR  |    239/238 x client signal  |     MAX LSP     |
   |  Client signals   |           bit rate          |    BANDWIDTH    Bandwidth    |
   |                   |                             |                 |
   | ODUflex for GFP-F |                             |     MAX LSP     |
|Mapped
   |  Mapped client signal    |      Configured bit rate    |    BANDWIDTH    Bandwidth    |
   |       signal      |                             |                 |
   |                   |                             |                 |
   |
|ODU flex resizable      ODUflex      |      Configured bit rate    |     MAX LSP     |
   |     resizable     |                             |    BANDWIDTH    Bandwidth    |
+---------------------+------------------------------+-----------------+
   +-------------------+-----------------------------+-----------------+
   A single ISCD MAY be used for the advertisement of unbundled or
   bundled links supporting homogeneous multiplexing hierarchies and the
   same TS (Tributary Slot) (tributary slot) granularity.  A different ISCD MUST be used
   for each different muxing hierarchy (muxing tree in the following
   examples) and different TS granularity supported within the TE Link. TE-Link.

   When a received LSA includes a sub-TLV not formatted accordingly to
   the precise specifications in this document, the problem SHOULD be
   logged and the wrongly formatted sub-TLV MUST NOT be used for path
   computation.

4.1.  Switching Capability Specific Information

   The technology specific technology-specific part of the OTN-TDM ISCD may include a
   variable number of sub-TLVs called Bandwidth sub-TLVs.  Each sub-TLV
   is encoded with the sub-TLV header as defined in [RFC3630] section [RFC3630],
   Section 2.3.2.  The muxing hierarchy tree MUST be encoded as an order
   independent
   order-independent list.  Two types of Bandwidth sub-TLV sub-TLVs are defined
   (TBA by IANA).  Note that type values are defined in this document
   and not in [RFC3630].

      -

   o  Type 1 - Unreserved Bandwidth for fixed containers

      -

   o  Type 2 - Unreserved/MAX LSP Bandwidth for flexible containers

   The Switching Capability-Specific Information Capability specific information (SCSI) MUST include one
   Type 1 sub-TLV for each fixed container and one Type 2 sub-TLV for
   each variable container.  Each container type is identified by a
   Signal Type.  Signal Type values are defined in [OTN-SIG]. [RFC7139].

   With respect to ODUflex, three different signal types Signal Types are allowed:

   o  20 - ODUflex Constant Bit Rate (CBR), ODUflex(CBR) (i.e., 1.25*N Gbps)

   o  21 - ODUflex Generic Framing
   Procedure-Frame mapped (GFP-F) ODUflex(GFP-F), resizable and (i.e., 1.25*N Gbps)

   o  22 - ODUflex (GFP-F)
   non-resizable. ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)

   where CBR stands for Constant Bit Rate, and GFP-F stands for Generic
   Framing Procedure - Framed.

   Each MUST always be advertised in separate Type 2 sub-TLVs as each
   uses different adaptation functions [G.805].  In the case that both
   GFP-F resizable and non-resizable (i.e., 21 and 22) are supported,
   only Signal Type 21 SHALL be advertised as this type also implies
   support for type Type 22 adaptation.

4.1.1.  Switching Capability Specific Information for fixed containers Fixed Containers

   The format of the Bandwidth sub-TLV for fixed containers is depicted
   in the following figure:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal type Type  | Num of stages |T|S| TSG | Res |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Stage#1    |      ...      |   Stage#N     |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 0    |             .....             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 7    |     Unreserved Padding        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Bandwidth sub-TLV - Sub-TLV -- Type 1 -

   The values of the fields shown in figure Figure 3 are explained in section
   Section 4.1.3.

4.1.2.  Switching Capability Specific Information for variable
        containers Variable
        Containers

   The format of the Bandwidth sub-TLV for variable containers is
   depicted in the following figure:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 2 (Unres/MAX-var)   |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal type Type  | Num of stages |T|S| TSG | Res |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Stage#1    |      ...      |   Stage#N     |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Unreserved Bandwidth at priority 0             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Unreserved Bandwidth at priority 7             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP Bandwidth at priority 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP Bandwidth at priority 7               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: Bandwidth sub-TLV - Sub-TLV -- Type 2 -

   The values of the fields shown in figure 4 are explained in section
   Section 4.1.3.

4.1.3.  Switching Capability Specific Information - -- Field values Values and
        explanation
        Explanation

   The fields in the Bandwidth sub-TLV MUST be filled as follows:

      -

   o  Signal Type (8 bits): Indicates the ODU type being advertised.
      Values are defined in [OTN-SIG].

      - Number [RFC7139].

   o  Num of stages (8 bits): This field indicates the number of
      multiplexing stages used to transport the indicated signal type. Signal Type.
      It MUST be set to the number of stages represented in the sub-TLV.

      -

   o  Flags (8 bits):

         -

      *  T Flag (bit 17): Indicates whether the advertised bandwidth can
         be terminated.  When the signal type Signal Type can be terminated T MUST
         be set, while when the signal type Signal Type cannot be terminated T MUST
         be cleared.

         -

      *  S Flag (bit 18): Indicates whether the advertised bandwidth can
         be switched.  When the signal type Signal Type can be switched switched, S MUST be set, while
         set; when the signal type Signal Type cannot be switched switched, S MUST be
         cleared.

      *  The value 0 in both the T bit and S bits bit MUST NOT be used.

      - TS Granularity: Tributary Slot Granularity

   o  TSG (3 bits): Tributary Slot Granularity.  Used for the
      advertisement of the supported Tributary Slot tributary slot granularity.  The
      following values MUST be used:

         -

      *  0 - Ignored

         -

      *  1 - 1.25Gbps/2.5Gbps

         - 1.25 Gbps / 2.5 Gbps

      *  2 - 2.5Gbps 2.5 Gbps only

         -

      *  3 - 1.25Gbps 1.25 Gbps only

         -

      *  4-7 - Reserved

      A value of 1 MUST be used on interfaces which that are configured to
      support the fall back fallback procedures defined in [G.798-a2]. [G.798].  A value of 2
      MUST be used on interfaces that only support 2.5Gbps time 2.5 Gbps tributary
      slots, such as [RFC4328] interfaces.  A value of 3 MUST be used on
      interfaces that are configured to only support 1.25Gbps time 1.25 Gbps tributary
      slots.  A value of 0 MUST be used for non-multiplexed signal types Signal Types
      (i.e., a non-OTN client).

      -

   o  Res (3 bits): reserved Reserved bits.  MUST be set to 0 and ignored on
      receipt.

      -

   o  Priority (8 bits): A bitmap used to indicate which priorities are
      being advertised.  The bitmap is in ascending order, with the
      leftmost bit representing priority level 0 (i.e., the highest) and
      the rightmost bit representing priority level 7 (i.e., the
      lowest).  A bit MUST be set (1) corresponding to each priority
      represented in the sub-TLV, sub-TLV and MUST NOT be set (0) when the
      corresponding priority is not represented.  At least one priority
      level MUST be advertised that, unless overridden by local policy,
      SHALL be at priority level 0.

      -

   o  Stage (8 bits): Each Stage field indicates a signal type Signal Type in the
      multiplexing hierarchy used to transport the signal indicated in
      the Signal Type field.  The number of Stage fields included in a
      sub-TLV MUST equal the value of the Number Num of Stages stages field.  The
      Stage fields MUST be ordered to match the data plane in ascending
      order (from the lowest order ODU to the highest order ODU).  The
      values of the Stage field are the same as those defined for the
      Signal Type field.  When the Number Num of stage stages field carries a 0, then
      the Stage and Padding fields MUST be omitted.

      -

      *  Example: For the ODU1->ODU2->OD3 hierarchy, the Signal Type
         field is set to ODU1 and two Stage fields are present, the
         first indicating ODU2 and the second ODU3 (server layer).

   o  Padding (variable): The Padding field is used to ensure the 32
      bit 32-bit
      alignment of stage fields.  The length of the Padding field is
      always a multiple of 8 bits (1 byte).  Its length can be
      calculated, in bytes, as: 4 - ( "value of Number Num of Stages stages field" %
      4).  The Padding field MUST be set to a zero (0) value on
      transmission and MUST be ignored on receipt.

      -

   o  Unreserved ODUj (16 bits): This field indicates the Unreserved
      Bandwidth at a particular priority level.  This field MUST be set
      to the number of ODUs at the indicated the Signal Type for a
      particular priority level.  One field MUST be present for each bit
      set in the Priority field, and is the fields are ordered to match the
      Priority field.  Fields MUST NOT be present for priority levels
      that are not indicated in the Priority field.

      -

   o  Unreserved Padding (16 bits): The Padding field is used to ensure
      the 32 bit 32-bit alignment of the Unreserved ODUj fields.  When
      present present,
      the Unreserved Padding field is 16 bits (2 byte) bytes) long.  When the
      number of priorities is odd, the Unreserved Padding field MUST be
      included.  When the number of priorities is even, the Unreserved
      Padding MUST be omitted.

      -

   o  Unreserved Bandwidth (32 bits): This field indicates the
      Unreserved Bandwidth at a particular priority level.  This field
      MUST be set to the bandwidth, in Bytes/sec bytes/second in IEEE floating
      point format, available at the indicated Signal Type for a
      particular priority level.  One field MUST be present for each bit
      set in the Priority field, and is the fields are ordered to match the
      Priority field.  Fields MUST NOT be present for priority levels
      that are not indicated in the Priority field.

      -

   o  Maximum LSP Bandwidth (32 bit): bits): This field indicates the maximum
      bandwidth that can be allocated for a single LSP at a particular
      priority level.  This field MUST be set to the maximum bandwidth,
      in Bytes/sec bytes/second in IEEE floating point format, available to a
      single LSP at the indicated Signal Type for a particular priority
      level.  One field MUST be present for each bit set in the Priority
      field, and is the fields are ordered to match the Priority field.
      Fields MUST NOT be present for priority levels that are not
      indicated in the Priority field.  The advertisement of the MAX LSP
      Bandwidth MUST take into account HO OPUk bit rate tolerance and be
      calculated according to the following formula:

      *  Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) *
         (1-HO OPUk bit rate tolerance)

5.  Examples

   The examples in the following pages are not normative and are not
   intended to imply or mandate any specific implementation.

5.1.  MAX LSP Bandwidth fields Fields in the ISCD

   This example shows how the MAX LSP Bandwidth fields of the ISCD are
   filled accordingly according to the evolving of the TE-link TE-Link bandwidth occupancy.
   In the example this example, an OTU4 link is considered, with supported
   priorities 0,2,4,7 and muxing hierarchy ODU1->ODU2->ODU3->ODU4.

   At time T0, with the link completely free, the advertisement would
   be:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SwCap=OTN_TDM | Encoding = 12 |    Reserved (all zeros)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 0 = 100Gbps 100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 1 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 2 = 100Gbps 100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 3 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 4 = 100Gbps 100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 5 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 6 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 7 = 100Gbps 100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Switching Capability Specific Information         |
   |                        (variable length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 5: Example 1 - MAX LSP Bandwidth fields Fields in the ISCD at T0
   At time T1, an ODU3 at priority 2 is set-up, set up, so for priority 0 0, the
   MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for
   priorities from 2 to 7 (excluding the non-supported ones) ones), the MAX
   LSP Bandwidth is equal to ODU3, as no more ODU4s are available and
   the next supported ODUj in the hierarchy is ODU3.  The advertisement
   is updated as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SwCap=OTN_TDM | Encoding = 12 |    Reserved (all zeros)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 0 = 100Gbps 100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 1 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 2 = 40Gbps 40 Gbps         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 3 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 4 = 40Gbps 40 Gbps         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 5 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 6 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 7 = 40Gbps 40 Gbps         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Switching Capability Specific Information         |
   |                        (variable length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Example 1 - 6: MAX LSP Bandwidth fields Fields in the ISCD at T1
   At time T2, an ODU2 at priority 4 is set-up. set up.  The first ODU3 is no
   longer has not
   been available since T1, T1 as it was kept by the ODU3 LSP, while the
   second is no more longer available and just 3 ODU2 ODU2s are left in it.  ODU2
   is now the MAX LSP Bandwidth for priorities higher than 4.  The
   advertisement is updated as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SwCap=OTN_TDM | Encoding = 12 |    Reserved (all zeros)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 0 = 100Gbps 100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 1 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 2 = 40Gbps 40 Gbps         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 3 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 4 = 10Gbps 10 Gbps         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 5 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 6 = 0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MAX LSP Bandwidth at priority 7 = 10Gbps 10 Gbps         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Switching Capability Specific Information         |
   |                        (variable length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 7: Example 1 - MAX LSP Bandwidth fields Fields in the ISCD at T2

5.2.  Example of T,S T, S, and TS granularity utilization Granularity Utilization

   In this example, an interface with Tributary Slot Type 1.25Gbps tributary slot type 1.25 Gbps and
   fallback procedure enabled is considered (TS granularity=1).  It
   supports the simple ODU1->ODU2->ODU3 hierarchy and priorities 0 and
   3.  Suppose that in this interface interface, the ODU3 signal type Signal Type can be both
   switched or terminated, the ODU2 can only be terminated, and the ODU1
   switched only.
   can only be switched.  Please note that since the ODU1 is not being
   advertised to support ODU0, the value of its TSG field is "ignored"
   (TS granularity=0).  For the advertisement of the capabilities of
   such an interface, a single ISCD is used and its used.  Its format is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU1  |  #stages= 2   |0|1|  0  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU2  | Stage#2=ODU3  |       Padding (all zeros)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU1 at Prio 0      |     Unres ODU1 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 1   |1|0|  1  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  |        Padding (all zeros)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU2 at Prio 0      |     Unres ODU2 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU3  |  #stages= 0   |1|1|  1  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU3 at Prio 0      |     Unres ODU3 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 8: Example 2 - TS granularity, T T, S, and S utilization TS Granularity Utilization

5.2.1.  Example of different Different TS Granularities

   In this example, two interfaces with homogeneous hierarchies but
   different Tributary Slot Types tributary slot types are considered.  The first one
   supports a an [RFC4328] interface (TS granularity=2) while the second
   one supports a G.709-2012 interface with fallback procedure disabled
   (TS granularity=3).  Both of them support the ODU1->ODU2->ODU3 hierarchy and
   priorities 0 and 3.  Suppose that in this interface interface, the ODU3
   signal type Signal
   Type can be both switched or terminated, the ODU2 can only be
   terminated, and the ODU1 switched only. can only be switched.  For the advertisement
   of the capabilities of such interfaces, two different ISCDs are used and the used.
   The format of their SCSIs is as follows:

   SCSI of ISCD 1 - -- TS granularity=2

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU1  |  #stages= 2   |0|1|  0  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU2  | Stage#2=ODU3  |       Padding (all zeros)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU1 at Prio 0      |     Unres ODU1 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 1   |1|0|  1  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  |        Padding (all zeros)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU2 at Prio 0      |     Unres ODU2 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU3  |  #stages= 0   |1|1|  2  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU3 at Prio 0      |     Unres ODU3 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 9: Example 2.1 - Utilization of Different TS Granularities utilization - -- ISCD 1
   SCSI of ISCD 2 - -- TS granularity=3

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU1  |  #stages= 2   |0|1|  0  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU2  | Stage#2=ODU3  |       Padding (all zeros)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU1 at Prio 0      |     Unres ODU1 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 1   |1|0|  1  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  |        Padding (all zeros)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU2 at Prio 0      |     Unres ODU2 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU3  |  #stages= 0   |1|1|  3  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODU3 at Prio 0      |     Unres ODU3 at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 10: Example 2.1 - Utilization of Different TS Granularities utilization - -- ISCD 2

   A particular case in which hierarchies

   Hierarchies with the same muxing tree but with different exported TS
   granularity MUST be considered as non-
   homogenous non-homogenous hierarchies.  This
   is the case in which an H-LPS H-LSP and the client LSP are terminated on
   the same egress node.  What can happen is that a loose Explicit Route
   Object (ERO) is used at the hop where the signaled LSP is nested into
   the Hierarchical-LSP (H-LSP) (penultimate hop of the LSP).

   In the following figure, node C receives from A a loose ERO from A; the ERO
   goes towards node E E, and node C must choose between the ODU2 H-LSP on
   if1 or the one on if2.  In this case, the H-LSP on if1 exports a TS=1.25Gbps,
   TS=1.25 Gbps, and the H-LSP on if2 exports a
   TS=2.5Gbps, TS=2.5 Gbps; because the
   service LSP being signaled needs a 1.25Gbps 1.25 Gbps tributary slot, only the
   H-LSP on if1 can be used to reach node E.  For further details,
   please see section 4.1 Section 3.2 of the [OTN-INFO]. [RFC7096].

                          ODU0-LSP
         ..........................................................+
         |                                                         |
         |                                     ODU2-H-LSP          |
         |                         +-------------------------------+
         |                         |                               |
      +--+--+      +-----+      +-----+ if1     +-----+         +-----+
      |     | OTU3 |     | OTU3 |     |---------|     |---------|     |
      |  A  +------+  B  +------+  C  | if2     |  D  |         |  E  |
      |     |      |     |      |     |---------|     |---------|     |
      +-----+      +-----+      +-----+         +-----+         +-----+

            ... Service LSP
            --- H-LSP

    Figure 11: Example - of Service LSP and H-LSP terminating Terminating on the same
                                   node Same
                                   Node

5.3.  Example of ODUflex advertisement Advertisement

   In this example, the advertisement of an ODUflex->ODU3 hierarchy is
   shown.  In the case of ODUflex advertisement, the MAX LSP Bandwidth
   needs to be advertised and, advertised, and in some cases, information about the
   Unreserved
   bandwidth Bandwidth could also be useful.  The amount of Unreserved bandwidth
   Bandwidth does not give a clear indication of how many ODUflex LSP LSPs
   can be set up either at the MAX LSP Bandwidth or at different rates,
   as it gives no information about the spatial allocation of the free
   TSs.

   An indication of the amount of Unreserved bandwidth Bandwidth could be useful
   during the path computation process, as shown in the following
   example.  Supposing  Suppose there are two TE-links TE-Links (A and B) with MAX LSP
   Bandwidth equal to 10 Gbps each.  In the case where 50Gbps 50 Gbps of
   Unreserved Bandwidth are available on Link A, 10Gbps 10 Gbps on Link B, and
   3 ODUflex LSPs of 10 GBps Gbps each have to be restored, for sure only one
   can be restored along Link B B, and it is probable, but not certain,
   that two of them can be restored along Link A.  The T, S S, and TS
   granularity TSG
   fields are not relevant to this example (filled with Xs).

   In the case of ODUflex advertisement, the Type 2 Bandwidth sub-TLV is
   used.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 2 (Unres/MAX-var)   |           Length  = 72        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S. type=ODUflex|  #stages= 1   |X|X|X X X|0 0 0| Priority(8)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU3 |          Padding (all zeros)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unreserved Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAX LSP  Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 12: Example 3 - ODUflex advertisement Advertisement

5.4.  Example of single stage muxing

   Supposing Single-Stage Muxing

   Suppose there is 1 OTU4 component link supporting single stage single-stage muxing
   of ODU1, ODU2, ODU3 ODU3, and ODUflex, the supported hierarchy can be
   summarized in a tree as in the following figure.  For the sake of
   simplicity, we also assume that only priorities 0 and 3 are
   supported.  The T, S S, and TS granularity TSG fields are not relevant to this
   example(filled example
   (filled with Xs).

          ODU1 ODU2  ODU3 ODUflex
             \   \    /   /
              \   \  /   /
               \   \/   /
                  ODU4

   and the

   The related SCSIs are as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU4  |  #stages= 0   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU4 at Prio 0 =1     |    Unres ODU4 at Prio 3 =1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU1  |  #stages= 1   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU4  |            Padding (all zeros)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU1 at Prio 0 =40    |    Unres ODU1 at Prio 3 =40   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 1   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU4  |            Padding (all zeros)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU2 at Prio 0 =10    |    Unres ODU2 at Prio 3 =10   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU3  |  #stages= 1   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU4  |            Padding (all zeros)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU3 at Prio 0 =2     |    Unres ODU3 at Prio 3 =2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 2 (Unres/MAX-var)   |           Length = 24         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S. type=ODUflex|  #stages= 1   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU4 |            Padding (all zeros)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Unreserved Bandwidth at priority 0 =100Gbps =100 Gbps       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Unreserved Bandwidth at priority 3 =100Gbps =100 Gbps       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MAX LSP Bandwidth at priority 0 =100Gbps =100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MAX LSP Bandwidth at priority 3 =100Gbps =100 Gbps        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 13: Example 4 - Single stage muxing Single-Stage Muxing

5.5.  Example of multi stage muxing - Multi-Stage Muxing -- Unbundled link

   Supposing Link

   Suppose there is 1 OTU4 component link with muxing capabilities as
   shown in the following figure:

          ODU2 ODU0    ODUflex ODU0
             \ /            \ /
              |              |
            ODU3           ODU2
               \            /
                \          /
                 \        /
                  \      /
                    ODU4

   and

   Considering only supported priorities 0 and 3, the advertisement is
   composed by the following Bandwidth sub-TLVs (T and S fields are not
   relevant to this example and filled with Xs):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU4  |  #stages= 0   |X|X|  1  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU4 at Prio 0 =1     |    Unres ODU4 at Prio 3 =1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU3  |  #stages= 1   |X|X|  1  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU4 |         Padding (all zeros)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU3 at Prio 0 =2     |    Unres ODU3 at Prio 3 =2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 1   |X|X|  1  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU4 |         Padding (all zeros)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU2 at Prio 0 =10    |    Unres ODU2 at Prio 3 =10   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 2   |X|X|  0  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU2 at Prio 0 =8     |    Unres ODU2 at Prio 3 =8    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU0  |  #stages= 2   |X|X|  0  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU0 at Prio 0 =64    |    Unres ODU0 at Prio 3 =64   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU0  |  #stages= 2   |X|X|  0  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU2  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU0 at Prio 0 =80    |    Unres ODU0 at Prio 3 =80   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 2 (Unres/MAX-var)   |           Length = 24         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S.type=ODUflex |  #stages= 2   |X|X|  0  |0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU2  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Unreserved Bandwidth at priority 0 =100Gbps =100 Gbps       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Unreserved Bandwidth at priority 3 =100Gbps =100 Gbps       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            MAX LSP Bandwidth at priority 0 =10Gbps =10 Gbps           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            MAX LSP Bandwidth at priority 3 =10Gbps =10 Gbps           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 14: Example 5 - Multi stage muxing - Multi-Stage Muxing -- Unbundled link Link

5.6.  Example of multi stage muxing - Multi-Stage Muxing -- Bundled links Links

   In this example, 2 OTU4 component links with the same supported TS
   granularity and homogeneous muxing hierarchies are considered.  The
   following muxing capabilities trees are supported:

   Component Link#1      Component Link#2
      ODU2 ODU0             ODU2 ODU0
         \ /                   \ /
          |                     |
         ODU3                  ODU3
          |                     |
         ODU4                  ODU4

   Considering only supported priorities 0 and 3, the advertisement is
   as follows (T, S (the T, S, and TS granularity TSG fields are not relevant to this example
   and filled with Xs):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU4  |  #stages= 0   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU4 at Prio 0 =2     |    Unres ODU4 at Prio 3 =2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU3  |  #stages= 1   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU4 |          Padding (all zeros)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU3 at Prio 0 =4     |    Unres ODU3 at Prio 3 =4    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 2   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU2 at Prio 0 =16    |    Unres ODU2 at Prio 3 =16   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU0  |  #stages= 2   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU0 at Prio 0 =128   |    Unres ODU0 at Prio 3 =128  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 15: Example 6 - Multi stage muxing - Multi-Stage Muxing -- Bundled links Links

5.7.  Example of component links Component Links with non-homogeneous hierarchies Non-Homogeneous Hierarchies

   In this example, 2 OTU4 component links with the same supported TS
   granularity and non-homogeneous muxing hierarchies are considered.
   The following muxing capabilities trees are supported:

   Component Link#1      Component Link#2
      ODU2 ODU0             ODU1 ODU0
         \ /                   \ /
          |                     |
         ODU3                  ODU2
          |                     |
         ODU4                  ODU4

   Considering only supported priorities 0 and 3, the advertisement uses
   two different ISCDs, one for each hierarchy (T, S (the T, S, and TS granularity TSG fields
   are not relevant to this example and filled with Xs).  In the
   following figure, the SCSI of each ISCD is shown:

   SCSI of ISCD 1 - -- Component Link#1

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU4  |  #stages= 0   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU4 at Prio 0 =1     |    Unres ODU4 at Prio 3 =1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU3  |  #stages= 1   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU4 |           Padding (all zeros)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU3 at Prio 0 =2     |    Unres ODU3 at Prio 3 =2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 2   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU2 at Prio 0 =8     |    Unres ODU2 at Prio 3 =8    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU0  |  #stages= 2   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU3  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU0 at Prio 0 =64    |    Unres ODU0 at Prio 3 =64   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 16: Example 7 - Multi stage muxing - Non-homogeneous
                           hierarchies - Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
                                  ISCD 1
   SCSI of ISCD 2 - -- Component Link#2

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU4  |  #stages= 0   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU4 at Prio 0 =1     |    Unres ODU4 at Prio 3 =1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU2  |  #stages= 1   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stage#1=ODU4 |           Padding (all zeros)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU2 at Prio 0 =10    |    Unres ODU2 at Prio 3 =10   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU1  |  #stages= 2   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU2  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU1 at Prio 0 =40    |    Unres ODU1 at Prio 3 =40   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type = 1 (Unres-fix)   |           Length = 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sig type=ODU0  |  #stages= 2   |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stage#1=ODU2  | Stage#2=ODU4  |    Padding (all zeros)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unres ODU0 at Prio 0 =80    |    Unres ODU0 at Prio 3 =80   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 17: Example 7 - Multi stage muxing - Non-homogeneous
                           hierarchies - Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
                                  ISCD 2

6.  OSPFv2 scalability Scalability

   This document does not introduce OSPF scalability issues with respect
   to existing GMPLS encoding and does not require any modification to
   flooding frequency.  Moreover, the design of the encoding has been
   carried out taking into account bandwidth optimization, and in
   particular:

      -

   o  Only unreserved and MAX LSP Bandwidth related to supported
      priorities are advertised

      - With respect of advertised.

   o  For fixed containers, only the number of available containers is
      advertised instead of the available bandwidth so in order to use only
      16 bits per container instead of 32 (as per former GMPLS
      encoding
      encoding).

   In order to further reduce the amount of data advertised it is
   RECOMMENDED to bundle component links with homogeneous hierarchies as
   described in [RFC4201] and illustrated in Section 5.6.

7.  Compatibility

   All implementations of this document MAY also support advertisement
   as defined in [RFC4328]. [RFC4203].  When nodes support both the advertisement
   methods,
   method in [RFC4203] and the one in this document, implementations
   MUST support the configuration of which advertisement method is
   followed.  The choice of which is used is based on policy and beyond
   the scope of this document.  This enables nodes following each method
   to identify similar supporting nodes and compute paths using only the
   appropriate nodes.

8.  Security Considerations

   This document extends [RFC4203].  As with[RFC4203], with [RFC4203], it specifies the
   contents of Opaque LSAs in OSPFv2.  As Opaque LSAs are not used for
   SPF
   Shortest Path First (SPF) computation or normal routing, the
   extensions specified here have no direct effect on IP routing.
   Tampering with GMPLS TE LSAs may have an effect on the underlying
   transport (optical and/or SONET-SDH) Synchronous Optical Network - Synchronous
   Digital Hierarchy (SONET-SDH) network.  [RFC3630] notes that the
   security mechanisms described in [RFC2328] apply to Opaque LSAs
   carried in OSPFv2.  An analysis of the security of OSPF is provided
   in [RFC6863] and applies to the extensions to OSPF as described in
   this document.  Any new mechanisms developed to protect the
   transmission of information carried in Opaque LSAs will also
   automatically protect the extensions defined in this document.

   For

   Please refer to [RFC5920] for details on security threats, threats; defensive techniques, monitoring/detection/
   techniques; monitoring, detection, and reporting of security attacks attacks;
   and requirements please refer to
   [RFC5920]. requirements.

9.  IANA Considerations

9.1.  Switching types

   Upon approval of this document, Types

   IANA will make has made the following assignment in the "Switching Types"
   section of the "GMPLS "Generalized Multi-Protocol Label Switching (GMPLS)
   Signaling Parameters" registry located at
   http://www.iana.org/assignments/gmpls-sig-parameters: <http://www.iana.org/
   assignments/gmpls-sig-parameters>:

   Value      Name                          Reference
   ---------  --------------------------    ----------
   110 (*)        OTN-TDM capable (OTN-TDM)    [This.I-D]

   (*) Suggested value

   Same               [RFC7138]

   The same type of modification needs to has been applied to the IANA-GMPLS-TC-MIB IANA-GMPLS-TC-
   MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib, <https://www.iana.org/assignments/ianagmplstc-mib>, where the
   value:

   OTN-TDM (110), -- Time-Division-Multiplex OTN-TDM capable

   Will be

   has been added to the IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION
   syntax list.

9.2.  New sub-TLVs Sub-TLVs

   This document defines 2 new sub-TLVs that are carried in Interface
   Switching Capability Descriptors [RFC4203] with the Signal Type OTN-TDM. OTN-
   TDM.  Each sub-TLV includes a 16-bit type identifier (the T-field).
   The same T-field values are applicable to the new sub-TLV.

   Upon approval of this document,

   IANA will create has created and will maintain a new sub-registry, the "Types for
   sub-TLVs of OTN-TDM SCSI (Switch
   Capability-Specific (Switching Capability Specific Information)"
   registry under the "Open Shortest Path First (OSPF) Traffic
   Engineering TLVs" registry, see http://
   www.iana.org/assignments/ospf-traffic-eng-tlvs/
   ospf-traffic-eng-tlvs.xml, <http://www.iana.org/assignments/
   ospf-traffic-eng-tlvs>, with the sub-TLV types as follows:

      This document defines new sub-TLV types as follows:

   Value       Sub-TLV                       Reference
   ---------   --------------------------    ----------
   0           Reserved                     [This.I-D]                      [RFC7138]
   1           Unreserved Bandwidth for     [This.I-D]      [RFC7138]
               fixed containers
   2           Unreserved/MAX Bandwidth for [This.I-D]  [RFC7138]
               flexible containers
   3-65535     Unassigned

   Types are to be assigned via Standards Action as defined in
   [RFC5226].

10.  Contributors

   Diego Caviglia, Caviglia
   Ericsson
   Via E.Melen, E. Melen, 77 -
   Genova -
   Italy

      Email:
   EMail: diego.caviglia@ericsson.com

   Dan Li, Li
   Huawei Technologies
   Bantian, Longgang District -
   Shenzhen 518129 P.R.China

      Email:
   P.R. China
   EMail: danli@huawei.com

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

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

   Khuzema Pithewan, Pithewan
   Infinera Corporation
   140 Caspian CT., Sunnyvale - CT.
   Sunnyvale, CA -
   USA

      Email:
   EMail: kpithewan@infinera.com

   Xiaobing Zi, Zi
   Huawei Technologies

      Email:
   EMail: zixiaobing@huawei.com

   Francesco Fondelli, Fondelli
   Ericsson
      Email:
   EMail: francesco.fondelli@ericsson.com

   Marco Corsi
   EMail: corsi.marco@gmail.com

   Eve Varma, Varma
   Alcatel-Lucent
   EMail: eve.varma@alcatel-lucent.com

   Jonathan Sadler, Sadler
   Tellabs
   EMail: jonathan.sadler@tellabs.com
   Lyndon Ong, Ong
   Ciena
   EMail: lyong@ciena.com

   Ashok Kunjidhapatham
   EMail: akunjidhapatham@infinera.com

   Snigdho Bardalai
   EMail: sbardalai@infinera.com

   Steve Balls
   EMail: Steve.Balls@metaswitch.com

   Jonathan Hardwick
   EMail: Jonathan.Hardwick@metaswitch.com

   Xihua Fu
   EMail: fu.xihua@zte.com.cn

   Cyril Margaria
   EMail: cyril.margaria@nsn.com

   Malcolm Betts
   EMail: Malcolm.betts@zte.com.cn

11.  Acknowledgements

   The authors would like to thank Fred Gruman and Lou Berger for the
   precious their
   valuable comments and suggestions.

12.  References

12.1.  Normative References

   [G.709-2012] ITU-T, "Interface for the optical transport network",
                Recommendation G.709/Y.1331, February 2012.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3630]    Katz, D., Kompella, K., and D. Yeung, "Traffic
                Engineering (TE) Extensions to OSPF Version 2", RFC
                3630, September 2003.

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

12.2.  Informative References

   [OTN-FWK]  F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework
              for GMPLS and PCE Control

   [G.798]      ITU-T, "Characteristics of G.709 Optical Transport
              networks, work in progress
              draft-ietf-ccamp-gmpls-g709-framework-13", June 2013.

   [OTN-INFO]
              S.Belotti, P.Grandi, D.Ceccarelli, D.Caviglia, F.Zhang,
              D.Li, "Information model for G.709 Optical Transport
              Networks (OTN), work in progress
              draft-ietf-ccamp-otn-g709-info-model-09", June 2013.

   [OTN-SIG]  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", June 2013. optical transport network
                hierarchy equipment functional blocks", Recommendation
                G.798, December 2012.

   [G.805]      ITU-T, "Generic functional architecture of transport
                networks", Recommendation G.805, March 2000.

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

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

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

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

   [RFC6566]    Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A
                Framework for the Control of Wavelength Switched Optical
                Networks (WSONs) with Impairments", RFC 6566, March
                2012.

   [RFC6863]    Hartman, S. and D. Zhang, "Analysis of OSPF Security
                According to the Keying and Authentication for Routing
                Protocols (KARP) Design Guide", RFC 6863, March 2013.

   [SWCAP-UPDT]
              F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli,

   [RFC7062]    Zhang, F., Li, D., Li, H., Belotti, S., and D.
                Ceccarelli, "Framework for GMPLS and PCE Control of
                G.709 Optical Transport
              networks, work in progress
              draft-ietf-ccamp-gmpls-g709-framework-13", June Networks", RFC 7062, November
                2013.

   [RFC7096]    Belotti, S., Grandi, P., Ceccarelli, D., Ed., Caviglia,
                D., and F. Zhang, "Evaluation of Existing GMPLS Encoding
                against G.709v3 Optical Transport Networks (OTNs)", RFC
                7096, January 2014.

   [RFC7139]    Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
                and K.  Pithewan, "GMPLS Signaling Extensions for
                Control of Evolving G.709 Optical Transport Networks",
                RFC 7139, March 2014.

Authors' Addresses

   Daniele Ceccarelli (editor)
   Ericsson
   Via E.Melen 77
   Genova - Erzelli
   Italy

   Email:

   EMail: daniele.ceccarelli@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

   Sergio Belotti
   Alcatel-Lucent
   Via Trento, 30
   Vimercate
   Italy

   Email:

   EMail: sergio.belotti@alcatel-lucent.com

   Rajan Rao
   Infinera Corporation
   140, Caspian CT.
   Sunnyvale, CA-94089
   USA

   Email:

   EMail: rrao@infinera.com
   John E E. Drake
   Juniper

   Email:

   EMail: jdrake@juniper.net