Network Working Group                                              X. Fu
Internet-Draft                                                  M. Betts
Intended status: Standards Track                         ZTE Corporation
Expires: October 28, 2010                                        R. Jing
                                                                  X. Huo
                                                           China Telecom
                                                          April 26, 2010


 RSVP-TE Extension for Multi Stages Multiplexing Configuration in G.709
                       Optical Transport Network
         draft-fuxh-ccamp-multi-stage-multiplex-config-rsvp-00

Abstract

   Multi stages multiplexing configuration requirement is defined in
   [MULTI-STAGES-MULTIPLEXING-CONFIG-REQ] document.  Multi stages
   multiplexing configuration framework is diefined in [MULTI-STAGES-
   MULTIPLEXING-CONFIG-FRW] document.  They describe some scenarios for
   the interworking between regions with 1.25G TS and 2.5G TS and the
   multi-domain OTN applications based on the tunnel design.  Multi
   stages multiplexing is desirable to facilitate the introduction of
   new ODU0 and ODUflex signals to an existing network without having to
   upgrade every node in the network.  So ODU0/ODUflex can be mapped
   into ODU1/ODU2/ODU3 transit across the 2.5G TS region.  Multi stages
   multiplexing/demultiplexing are also used to support the multi-domain
   OTN applications based on the tunnel design.  This document describes
   the RSVP-TE extension for multi stages multiplexing configuration in
   G.709 Optical Transport Network.

Conventions Used In This Document

   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 RFC 2119 [RFC2119].

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Fu, et al.              Expires October 28, 2010                [Page 1]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


   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 October 28, 2010.

Copyright Notice

   Copyright (c) 2010 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.
































Fu, et al.              Expires October 28, 2010                [Page 2]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  RSVP-TE Extension for Multi Stages Multiplexing
       Configuration  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Multi Stages Multiplexing Hierarchy Sub-TLV  . . . . . . .  5
     2.2.  Signaling Procedure for Multi Stages Multiplexing
           Configuration  . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Signaling Procedure Example  . . . . . . . . . . . . . . .  8
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13




































Fu, et al.              Expires October 28, 2010                [Page 3]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


1.  Introduction

   G.709 has supported a single stage of ODU multiplexing.  The
   practical consequence of this in OTNv1 is an ODU1 can be mapped
   directly to a tributary slot of an ODU3, without having to be first
   mapped into an ODU2.  The motivation for this architecture is
   reducing complexity.  In the normal progression of things, new
   additions to the OTN were expected to be at faster bit rates, and
   thus the single stage concept could be easily maintained going
   forward.

   The introduction of ODU0 and ODUflex to the OTN hierarchy creates a
   situation where the newly added ODUk signals have a bit rate that is
   lower than any of the existing signals, which presents some different
   challenges because the new signals can be clients of the existing
   signals.  As a result, there are clear applications where multi
   stages of multiplexing would be desirable to facilitate the
   introduction of these new ODU0 and ODUflex signals to an existing
   network without having to upgrade every node in the network.  Using
   multi stages of multiplexing at the domain boundary allows the
   operator to confine the new rates to only those nodes that need to
   support them.

   A second potential application for multi stages outside of an upgrade
   scenario would be a network design based on tunnels.  Multi stages
   multiplexing are used to support the multi-domain OTN applications
   based on the tunnel design.

   Based on the [MULTI-STAGES-MULTIPLEXING-CONFIG-OSPFTE-EXT], path
   computation entity can get multi stages multiplexing/demultiplexing
   capability of each gateway nodes for path computation.  So the path
   computation entity must select some proper kinds of multi stages
   multiplexing/demultiplexing for different gateway nodes along a
   specific end-to-end connection.  All kinds of multi stages
   multiplexing which has been determined for all gateway nodes along
   one end-to-end connection by path computation entity must be carried
   with signaling message.  After one gateway node receives the
   signaling message who carries one kind of multi stages multiplexing
   for it, it must config this kind of multi stages multiplexing to its
   data plane.

   This document describes the RSVP-TE extension for multi stages
   multiplexing configuration in G.709 Optical Transport Network.


2.  RSVP-TE Extension for Multi Stages Multiplexing Configuration

   The Explicit Route Object [RFC3209] allows the ingress node to



Fu, et al.              Expires October 28, 2010                [Page 4]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


   partially or fully specify the route of an LSP.  The route is encoded
   as a sequence of hops that identifies a node or interface that must
   be crossed.  Further attributes assigned to each hop can be added to
   the route such as per-hop label control [RFC3473] and list of
   prohibited resources between two nodes [RFC4874].

   After path computation entity gets multi stages multiplexing/
   demultiplexing capability information of each gateway nodes, it must
   determine a proper kind of multi stages multiplexing of each gateway
   nodes along one end-to-end connection.  All kinds of multi stages
   multiplexing of each gateway nodes can be carried in ERO object.
   After one gateway node receives the signaling message who carries one
   kind of multi stages multiplexing for it, the gateway node must
   determine what tunnel must be created between both gateway nodes
   located at the domain boundary for one end-to-end connection whose
   bandwidth is lower than it by the multi stages multiplexing
   hierarchy.  So the tunnel can be triggered based on [RFC4206].  It
   must config this kind of multi stages multiplexing to its data plane.

   In order to carry the multi stages multiplexing information in ERO,
   it is desirable to extend the ERO object.  [HOP_ATTRIBUTES] introduce
   a new ERO sub-object that encodes attributes relevant to a particular
   node or interface within the node.  The HOP_ATTRIBUTES subobject can
   be inserted into ERO, SERO, RRO and SRRO.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|    Type     |     Length    |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Attribute TLVs                         |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.  Multi Stages Multiplexing Hierarchy Sub-TLV

   This document extends the HOP_ATTRIBUTES defined in document
   [HOP_ATTRIBUTES].  It defineds a new Attributes TLV.


    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 (TBD)  (IANA)       |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MSMH  | ...Multi Stages Multiplexing Capability... |  padding |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Fu, et al.              Expires October 28, 2010                [Page 5]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


   MSMH and MSMC indicate the multi stages multiplexing hierarchy
   detailed information.

   o  Type: Indicates the type of Attribute TLV.

   o  MSMH (Multi Stages Multiplexing Hierarchies): Indicates the number
      of Multi Stages Multiplexing Hierarchies relevant to a particular
      internal node or interface of the LSP.

   o  MSMC (Multi Stages Multiplexing Capability): Indicates the kind of
      multi stages multiplexing capability relevant to a particular
      internal node or interface of the LSP.  The length of Multi Stages
      Multiplexing Capability (MSMC) information depends on the number
      of multi stages multiplexing hierarchies (MSMH).  So the length of
      MSMC is (MSMH+1) * 4.  Each ODUk (k=1, 2, 3, 4, 2e, flex) is
      indicated by 4 bits.  Following is the Signal Type for G.709
      Amendment 3.


                     Value  Type
                     -----  ----
                     0000    ODU0
                     0001    ODU1
                     0010    ODU2
                     0011    ODU3
                     0100    ODU4
                     0101    ODU2e
                     0110    ODUflex
                     7-15    Reserved (for future use)

   o  The padding is used to make the Multi Stages Multiplexing
      Capability sub-TLV 32-bits aligned.

2.2.  Signaling Procedure for Multi Stages Multiplexing Configuration

   In this section we describe signaling procedures for multi stages
   multiplexing configuration.  The path computation entity computes and
   returns an end-to-end ODUk path to ingress LSR converted to an
   Explicit Route Object (ERO) for use in RSVP-TE signaling.  What
   tunnel must be determined between both gateway nodes located at the
   domain boundary for one end-to-end connection whose bandwidth is
   lower than it by the multi stages multiplexing hierarchy of gateway
   nodes.  Establishment/termination of ODUk tunnel may be triggered
   either by mechanisms outside of GMPLS (e.g., via Management Plane
   and/or planning tool), or by mechanisms within GMPLS ([RFC4206]).So
   the tunnel can be created based on [RFC4206].  If this ODUk (lower
   ODUk) path is to be tunneled over an FA-LSP (Higher ODUk) between a
   pair of gateway nodes, all kinde of multi stages multiplexing encoded



Fu, et al.              Expires October 28, 2010                [Page 6]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


   into ERO determined by path computation entity or Management Plane
   must be carried by Path message.  One pairs or multiple pairs of
   gateway nodes can be carried in Path message.

   The end-to-end ODUk connection setup procedure is described below:

   1.  Ingress node initiates the setup of end-to-end connection.  A
       specific kind of multi stages multiplexing hierarchy relevant to
       a particular gateway node or interface within this gateway node
       along the path is included in a HOP_ATTRIBUTES subobject, which
       is inserted into the ERO.

   2.  On reception of a Path message containing HOP_ATTRIBUTES whose
       type of Attributes TLV is Multi States Multiplexing Hierarchy
       Sub-TLV, the receiver of message along the path must check the
       local data plane capability to see if this kind of multi stages
       multiplexing/demultiplexing is acceptable on specific interface
       or gateway node.  If there is an acceptable kind of multi stages
       multiplexing/demultiplexing, then this kind of multi stages
       multiplexing/demultiplexing hierarchy must be configed into the
       data plane, and forward the Path message to the downstream node.
       Otherwise the Path message will be terminated, and a PathErr
       message with a "Routing problem/Multi Stages Multiplexing
       Hierarchy not Acceptable" indication will be generated.

   3.  A node that does not recognize the type of a Attribute TLV
       carried in the HOP_ATTRIBUTES object must reject the PATH message
       and issue a PathErr message with Error Code "Unknown Attribute
       TLV" and the Error Value is set to the type code of the unknown
       TLV.

   4.  The multi stages multiplexing configuration must be together with
       cross-connection configuration.  So if the cross-connection is
       configed during the Resv message, the kind of multi stages
       multiplexing which is received by Path message must be stored
       into internal node.  When a Resv message is received at an
       gateway node, if there is a kind of multi stages multiplexing
       which has not yet been configed, the gateway node must check the
       local data plane capability to see if this kind of multi stages
       multiplexing/demultiplexing is acceptable on specific interface
       or gateway node.  If there is an acceptable kind of multi stages
       multiplexing/demultiplexing, then this kind of multi stages
       multiplexing/demultiplexing hierarchy must be configed into the
       data plane







Fu, et al.              Expires October 28, 2010                [Page 7]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


2.3.  Signaling Procedure Example

   In Figure 1, node 4, 5, 6 and 7 have ODU1 and ODU2 switching
   capability.  All nodes only support 2.5G TS granularity.  They can't
   support ODU0/ODUflex directly.  They could not have any visibility to
   the ODU0/ODUflex.


                                    --
                                  /|12|\
                                 /  --  \
                                /        \
                            -- /   ODU2   \--
                           |11| Network 4 |13|
                            -- \         / --
                                \       /
                                 \  -  /
                                  \| |/
                                    - Gateway4
                                    |
                                    |
               -                    -                     -
             /|2|\                /|5|\                 /|8|\
            /  -  \              /  -  \               /  -  \
           /       \            /       \             /       \
        - /   ODU2  \ -      - /   ODU3  \ -       - /   ODU2  \ --
       |1| Network 1 | |----|4| Network 2 |7|---- | | Network 3 |10|
        - \         / -      - \         / -       - \         / --
           \       /Gateway1    \       /     Gateway3\       /
            \  -  /              \  -  /               \  -  /
             \|3|/                \|6|/                 \|9|/
               -                    -                     -

   There are three 10G OTN networks are deployed, such as ODU2 Network
   1, ODU 2 Network 3 and ODU2 Network 4.  All ODU2 networks are
   interconnected with ODU3 network by OTU3 link.  All nodes of three
   ODU2 networks support the 1.25G TS granularity and are based on G.709
   v3.  All nodes in ODU2 Network 1 and ODU2 Network 4 can support ODU0,
   ODU1 and ODUflex switching capability.

   ODU2 Network 3 is only desirable to support GigE and ODUflex
   services, so all nodes in ODU2 Network 3 only support ODU0 and
   ODUflex for more economical cost.  It doesn't support ODU1 (e.g.,
   STM-16) application.

   The operator limits the ODUflex application of ODU2 Network 4 to the
   local network.  There is no any multi-domain ODUflex application
   which goes into ODU2 Network 4 and vice versa.



Fu, et al.              Expires October 28, 2010                [Page 8]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


   In order for the interworking between 1.25G TS and 2.5G TS networks,
   there should be some gateway nodes (i.e., Gateway 1, Gateway 3 and
   Gateway 4) which are added in order to support ODU0/ODUflex.  Within
   the gateway nodes, multi stages multiplexing/demultiplexing allow
   ODU0/ODUflex to be supported across the legacy network.  ODU0/ODUflex
   is mapped first to ODU1 or ODU2, and that ODU1/2 is then mapped into
   ODU3.

   Gateway 1 is supposed to support the following multi stages
   multiplexing/demultiplexing capability.

   o  ODU0-ODU1-ODU3

   o  ODU0-ODU2-ODU3

   o  ODU1-ODU2-ODU3

   o  ODUflex-ODU2-ODU3

   Gateway 3 is supposed to support the following multi stages
   multiplexing/demultiplexing capability.

   o  ODU0-ODU2-ODU3

   o  ODUflex-ODU2-ODU3

   Gateway 4 is supposed to support the following multi stages
   multiplexing/demultiplexing capability.  There is no any multi-domain
   ODUflex application which goes into ODU2 Network 4 and vice versa.
   The operator limits the ODUflex application to the local network.  It
   doesn't support the ODUflex-ODU2-ODU3 multiplexing.

   o  ODU0-ODU1-ODU3

   o  ODU0-ODU2-ODU3

   For a end-to-end ODU0 connection between node 1 and node 10, path
   computation entity return a path to ingress LSR.  The routing of path
   is 1, 3, Gateway 1, 4, 6, 7, Gateway 3, 9 and 10.  This ODU0
   connection is to be tunneled over an FA-LSP (i.e., ODU2 tunnel)
   between Gateway 1 and Gateway 3.  The two stages multiplexing
   hierarchy ODU0-ODU2-ODU3 must be configed in Gateway 1 and Gateway 3.

   1.  Ingress node 1 initiates the setup of end-to-end connection.  The
       two stages multiplexing hierarchy ODU0-ODU2-ODU3 relevant to
       Gateway 1 and Gateway 3 are included in a Attribute TLV of
       HOP_ATTRIBUTES subobject which is inserted into different ERO
       subobject (i.e., Gateway 1 and Gateway 3).



Fu, et al.              Expires October 28, 2010                [Page 9]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


      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 (TBD)(IANA)         |          Length(4)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 1 0|0 0 0 0|0 0 1 0|0 0 1 1|           padding             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   2.  On reception of a Path message containing HOP_ATTRIBUTES whose
       type of Attributes TLV is Multi States Multiplexing Hierarchy
       Sub-TLV, Gateway 1 check the local data plane capability to see
       if this kind of multi stages multiplexing/demultiplexing is
       acceptable on specific interface or gateway node.  There is an
       acceptable kind of multi stages multiplexing/demultiplexing,
       Gateway 1 determin an ODU2 tunnel must be created between Gateway
       1 and Gateway 3.  So it creates a ODU2 tunnel based on [RFC4206]
       for this ODU0 end-to-end connection which will tunnel over it.

   3.  The creation of ODU0 connection is to be continued.  The kind of
       multi stages multiplexing/demultiplexing (i.e., ODU0-ODU2-ODU3)
       is configed into the data plane of Gateway 1.  Gateway 1 forward
       the Path message to the downstream node.

   4.  On reception of a Path message containing HOP_ATTRIBUTES whose
       type of Attributes TLV is Multi States Multiplexing Hierarchy
       Sub-TLV, Gateway 3 check the local data plane capability to see
       if this kind of multi stages multiplexing/demultiplexing is
       acceptable on specific interface or gateway node.  There is an
       acceptable kind of multi stages multiplexing/demultiplexing, so
       this kind of multi stages multiplexing/demultiplexing (i.e.,
       ODU0-ODU2-ODU3) is configed into the data plane.  Gateway 3
       forward the Path message to the downstream node.

   For a end-to-end ODUflex (e.g., Bandwidth is 5*1.25G TS) connection
   between node 1 and node 8, path computation entity return a path to
   ingress LSR.  Both ODUflex and ODU0 connection transport a same pair
   of gateway node (i.e., Gateway 1 and Gateway3).  They can share a
   same ODU2 tunnel.  The routing of this ODUflex connection is 1, 3,
   Gateway 1, 4, 6, 7, Gateway 3, and 8.  This ODUflex connection is to
   be tunneled over an FA-LSP (i.e., ODU2 tunnel) which has been
   created.  The two stages multiplexing hierarchy ODUflex-ODU2-ODU3
   must be configed in Gateway 1 and Gateway 3.

   1.  Ingress node 1 initiates the setup of end-to-end connection.  The
       two stages multiplexing hierarchy ODUflex-ODU2-ODU3 relevant to
       Gateway 1 and Gateway 3 are included in a Attribute TLV of
       HOP_ATTRIBUTES subobject which is inserted into different ERO
       subobject (i.e., Gateway 1 and Gateway 3).



Fu, et al.              Expires October 28, 2010               [Page 10]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


      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 (TBD)(IANA)         |          Length(4)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 1 0|0 1 1 0|0 0 1 0|0 0 1 1|           padding             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   2.  On reception of a Path message containing HOP_ATTRIBUTES whose
       type of Attributes TLV is Multi States Multiplexing Hierarchy
       Sub-TLV, Gateway 1 and Gateway 3 check the local data plane
       capability to see if this kind of multi stages multiplexing/
       demultiplexing is acceptable on specific interface or gateway
       node.  There is an acceptable kind of multi stages multiplexing/
       demultiplexing, so this kind of multi stages multiplexing/
       demultiplexing (i.e., ODUflex-ODU2-ODU3) is configed into the
       data plane.  Gateway 3 forward the Path message to the downstream
       node.

   For a end-to-end ODU0 connection between node 2 and node 12, path
   computation entity return a path to ingress LSR.  The routing of path
   is 2, Gateway 1, 4, 5, Gateway 4, 11 and 12.  This ODU0 connection is
   to be tunneled over an FA-LSP (i.e., ODU1 tunnel) between Gateway 1
   and Gateway 4.  The two stages multiplexing hierarchy ODU0-ODU1-ODU3
   must be configed in Gateway 1 and Gateway 4.

   1.  Ingress node 2 initiates the setup of end-to-end connection.  The
       two stages multiplexing hierarchy ODU0-ODU1-ODU3 relevant to
       Gateway 1 and Gateway 4 are included in a Attribute TLV of
       HOP_ATTRIBUTES subobject which is inserted into different ERO
       subobject (i.e., Gateway 1 and Gateway 4).


      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 (TBD)(IANA)         |          Length(4)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 1 0|0 0 0 0|0 0 0 1|0 0 1 1|           padding             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   2.  On reception of a Path message containing HOP_ATTRIBUTES whose
       type of Attributes TLV is Multi States Multiplexing Hierarchy
       Sub-TLV, Gateway 1 check the local data plane capability to see
       if this kind of multi stages multiplexing/demultiplexing is
       acceptable on specific interface or gateway node.  There is an
       acceptable kind of multi stages multiplexing/demultiplexing,
       Gateway 1 determin an ODU1 tunnel must be created between Gateway



Fu, et al.              Expires October 28, 2010               [Page 11]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


       1 and Gateway 4.  So it creates a ODU1 tunnel based on [RFC4206]
       for this ODU0 end-to-end connection which will tunnel over it.

   3.  The creation of ODU0 connection is to be continued.  The kind of
       multi stages multiplexing/demultiplexing (i.e., ODU0-ODU1-ODU3)
       is configed into the data plane of Gateway 1.  Gateway 1 forward
       the Path message to the downstream node.

   4.  On reception of a Path message containing HOP_ATTRIBUTES whose
       type of Attributes TLV is Multi States Multiplexing Hierarchy
       Sub-TLV, Gateway 4 check the local data plane capability to see
       if this kind of multi stages multiplexing/demultiplexing is
       acceptable on specific interface or gateway node.  There is an
       acceptable kind of multi stages multiplexing/demultiplexing, so
       this kind of multi stages multiplexing/demultiplexing (i.e.,
       ODU0-ODU1-ODU3) is configed into the data plane.  Gateway 4
       forward the Path message to the downstream node.


3.  Security Considerations

   The use of control plane protocols for signaling, routing, and path
   computation opens an OTN to security threats through attacks on those
   protocols.  The data plane technology for an OTN does not introduce
   any specific vulnerabilities, and so the control plane may be secured
   using the mechanisms defined for the protocols discussed.  For
   further details of the specific security measures refer to the
   documents that define the protocols ([RFC3473], [RFC4203], [RFC4205],
   [RFC4204], and [RFC5440]).  [GMPLS-SEC] provides an overview of
   security vulnerabilities and protection mechanisms for the GMPLS
   control plane.


4.  IANA Considerations

   TBD


5.  References

5.1.  Normative References

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







Fu, et al.              Expires October 28, 2010               [Page 12]


Internet-Draft   Multi Stages Multiplexing Configuration      April 2010


5.2.  Informative References

   [I-D.kern-ccamp-rsvpte-hop-attributes]
              Kern, A. and A. Takacs, "Encoding of Attributes of LSP
              intermediate hops using RSVP-TE",
              draft-kern-ccamp-rsvpte-hop-attributes-00 (work in
              progress), October 2009.

   [I-D.ietf-ccamp-gmpls-g709-framework]
              Zhang, F., Li, D., Li, H., Belotti, S., Han, J., Betts,
              M., Grandi, P., and E. Varma, "Framework for GMPLS and PCE
              Control of G.709 Optical Transport Networks",
              draft-ietf-ccamp-gmpls-g709-framework-00 (work in
              progress), April 2010.


Authors' Addresses

   Xihua Fu
   ZTE Corporation

   Email: fu.xihua@zte.com.cn


   Malcolm Betts
   ZTE Corporation

   Email: malcolm.betts@zte.com.cn


   Ruiquan Jing
   China Telecom

   Email: jingrq@ctbri.com.cn


   Xiaoli Huo
   China Telecom

   Email: huoxl@ctbri.com.cn











Fu, et al.              Expires October 28, 2010               [Page 13]