[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                              X. Fu
Internet-Draft                                                   Q. Wang
Intended status: Standards Track                                  Y. Bao
Expires: January 9, 2012                                 ZTE Corporation
                                                                 R. Jing
                                                                  X. Huo
                                                           China Telecom
                                                            July 8, 2011


               RSVP-TE Extension for MRN/MLN Application
           draft-fuxh-ccamp-boundary-explicit-control-ext-03

Abstract

   [RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN).
   [RFC4206] introduces a region boundary determination algorithm and a
   Hierarchy LSP (H-LSP) creation method.  However, in some scenarios,
   there must be some additional information to facilitate hierarchy LSP
   creation.  This document extends RSVP-TE to meet this requirement.

Status of this Memo

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

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

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

   This Internet-Draft will expire on January 9, 2012.

Copyright Notice

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



Fu, et al.               Expires January 9, 2012                [Page 1]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


   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
     1.1.  Conventions Used In This Document  . . . . . . . . . . . .  3
   2.  Requirement Identification . . . . . . . . . . . . . . . . . .  3
     2.1.  Indication of Server Layer . . . . . . . . . . . . . . . .  3
     2.2.  Requirement in OTN Multi-Layer Network . . . . . . . . . .  4
       2.2.1.  Indication of ODUk Signal Type . . . . . . . . . . . .  4
       2.2.2.  Indication of Multi Stages Multiplexing Hierarchy  . .  4
   3.  Mechanism and Protocol Extensions  . . . . . . . . . . . . . .  5
     3.1.  Controlling FA-LSPs Boundaries . . . . . . . . . . . . . .  5
       3.1.1.  Boundaries Determination . . . . . . . . . . . . . . .  6
       3.1.2.  Example  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Explicit Route Boundary Object (ERBO)  . . . . . . . . . .  7
       3.2.1.  Switching Capability subobject . . . . . . . . . . . .  8
       3.2.2.  Encoding Type subobject  . . . . . . . . . . . . . . .  8
       3.2.3.  Signal Type subobject  . . . . . . . . . . . . . . . .  9
       3.2.4.  Multiplexing Hierarchy subobject . . . . . . . . . . . 10
       3.2.5.  Signaling Procedure  . . . . . . . . . . . . . . . . . 11
     3.3.  Exclude Route Object(XRO)  . . . . . . . . . . . . . . . . 12
       3.3.1.  Encoding Type subobject  . . . . . . . . . . . . . . . 12
       3.3.2.  Signal Type subobject  . . . . . . . . . . . . . . . . 13
       3.3.3.  Multiplexing Hierarchy subobject . . . . . . . . . . . 13
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
















Fu, et al.               Expires January 9, 2012                [Page 2]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


1.  Introduction

   This document describes some requirements of explicitly control
   Multi-Region and Multi-Layer Network.  It extends mechanisms and
   protocols defined in [RFC4206] and [RFC6001] to meet these
   requirement.

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


2.  Requirement Identification

2.1.  Indication of Server Layer

   [RFC4206] describes a region boundary determination algorithm and a
   hierarchical LSP creation method.  It is well applied to multi-region
   network.  However it isn't fully applied to multi-layer network
   within the same switching capability.

   In the following figure, three LSPs belong to the same TDM region and
   different latyers, but boundary node (e.g., B) could not determine
   that STM-N FA-LSP should be triggered according to the region
   boundary determination algorithm defined in [RFC4206].  The solution
   MUST support to explicitly indicate which server layer must be
   triggered.


       A           B           C           D            E           F
     +---+ STM-N +---+ STM-N +----+ OTUk +----+ STM-N +---+ STM-N +---+
     |VC4|-------|VC4|-------|ODUk|------|ODUk|-------|VC4|-------|VC4|
     +---+       +---+       +----+      +----+       +---+       +---+

      |<-------------------------- VC4 LSP ------------------------->|

                  |<------------- STM-N LSP ------------>|

                              |<--ODUk LSP-->|

               Figure 1: Example of Server Layer Indication








Fu, et al.               Expires January 9, 2012                [Page 3]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


2.2.  Requirement in OTN Multi-Layer Network

2.2.1.  Indication of ODUk Signal Type

   In Figure 2, node B and C in the OTN network are connected to 2.5G TS
   network by two OTU3 links.  They can support flexible multi stages
   multiplexing hierarchies.  There are two multi stages multiplexing
   hierarchies for ODU0 being mapped into OTU3 link in B and C (i.e.,
   ODU0-ODU1-ODU3 and ODU0-ODU2-ODU3).  But boundary node (e.g., B)
   could not determine which kind of ODUk FA-LSP (ODU1, ODU2 or ODU3)
   should be triggered during one e2e ODU0 connection signaling
   according to the region boundary determination algorithm defined in
   [RFC4206].

   If path computation entity select the ODU0-ODU2-ODU3 multi stages
   multiplexing hierarch in Node B and C for one end-to-end ODU0 service
   from A to Z, there has to be an ODU2 or ODU3 FA-LSP between B and C.
   The solution MUST support to explicitly indicate which type of ODUk
   FA-LSP must be triggered for ODUj (k>j).


                                                 3/1/0
                     2/0                         3/2/0
                     |            _______        |
    ___             _|_____      /       \      _|_____             ___
   | A |           | | B   |    |   40G   |    | | C   |           | Z |
   | o-|-----------|-o   o-|----| Network |----|-o   o-|-----------|-o |
   |___| OTU2 Link |_____|_|OTU3|(2.5G TS)|OTU3|_____|_| OTU2 Link |___|
         (1.25G TS)      |       \_______/           |   (1.25G TS)
                         |                           |
                     0/1/3                         0/2
                     0/2/3


              Figure 2 Example of ODUk Signal Type Indication

2.2.2.  Indication of Multi Stages Multiplexing Hierarchy

   In figure 2, if ODU3 FA-LSP will be triggered between B and C to
   directly support one end-to-end ODU0 service from A to Z, B should be
   informed which multi stages multiplexing hierarchy should be used for
   ODU0 mapping into ODU3.  So the solution MUST support to explicitly
   indicate which multi stages multiplexing hierarchy must be applied to
   a special interface.







Fu, et al.               Expires January 9, 2012                [Page 4]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


3.  Mechanism and Protocol Extensions

   This section defines protocol mechanisms and extensions to achieve
   the requirement described in the previous section.

   o  A generic boundaries determination mechanism is introduced first.
      Path computation entity or interim LSR along one end-to-end LSP
      which traverses multi-layer can rely on this mechnism to determine
      the boundary nodes of FA-LSP.

   o  Path computation entity can determine regions' boundaries.  After
      PCE compute an end-to-end paths across multi-layer, the boundary
      nodes and some limitation about how to create FA-LSP must be
      inform to interim nodes during signaling.

      A new object, Explicit Route Boundary Object(ERBO), is introduced
      to explicitly indicate a pair of FA-LSP boundary nodes and some
      attributes which indicates how to create FA-LSPs.

      This document also introduces some new subobjects as part of the
      XRO that explicitly indicate which Signal Type, Multiplexing
      Hierarchy and Encoding Type have to be excluded before initiating
      FA-LSP creation.

3.1.  Controlling FA-LSPs Boundaries

   The boundary determination mechanism in [RFC4206] depends on the
   comparing of interface switching capabilities.  For multi-layer
   network within the same TDM switching capability, the comparing of
   interface switching capabilities relies on the max LSP bandwidth of
   interface.  But one interface in OTN netowrk could support several
   ODUk signal type, the max LSP bandwidth makes no any sense to path
   computation entity.  The mechanism in [RFC4206] isn't well applied to
   OTN multi-layer network.  The solution MUST support the boundaries
   determination of ODUk FA-LSP.

   This document introduces a generic mechanism to determine the
   boundaries of FA-LSPs by using termination and switching capability
   from IGP database.  It can be applied to multi-layer network within
   same switching capability (e.g, OTN network) and multi-region
   network.  So this mechanism is compatible with the one in [RFC4206].
   The switching and termination capability could be induced by IACD
   [RFC6001] in multi-regin network.  In OTN multi-layer network, the
   switching and termiantion Capability [OTNv3-OSPF] is advertised by
   using SCSI (Switch Capability Specific Information) within ISCD.






Fu, et al.               Expires January 9, 2012                [Page 5]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


3.1.1.  Boundaries Determination

   Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2,
   node-2, ..., link-n, node-n.  Moreover, for link-i denote by [link-i,
   node-(i-1)] the interface that connects link-i to node-(i-1), and by
   [link-i, node-i] the interface that connects link-i to node-i.

   Suppose interface [link-(i+1), node-i] supports switching capability
   of one signal type ST-x and termination capability of one signal type
   ST-y.  Interface [link-(i+1), node-(i+1)] supports switiching
   capability of ST-y.  Switching capability of ST-y (e.g., LSC) is
   larger than ST-x (e.g., TDM/G.709) or ST-x (e.g., ODUj) could be
   mapped into ST-y (e.g., ODUk (k>j)).  So we say that the LSP has
   crossed a region boundary at node-i.  The 'other edge' of the region
   with respect to the LSP path is node-k, where k is the smallest
   number greater than i such that interface [link-k, node-(k-1)]
   supports switching capability of ST-y and interface [link-k, node-k]
   suuports switching capability of ST-x and termination capability of
   ST-y.

3.1.2.  Example

   A multi-layer OTN network is illustrated in figure 3.  Node B and D
   support ODUj being mapping into ODUk (k>j).  Interface IF-B and IF-D
   support ODUj switching capability (ODUj(S)) and ODUk termination
   capability (ODUk(T)).  Interface within C only supports ODUk
   switching capability.  So Node B and D could be boundaries of ODUk
   FA-LSP for ODUj LSP.



              ODUj(S)  ODUj(S)     ODUk(S)     ODUk(S)  ODUj(S)
                |        |          | |          |        |
              __|_      _|___      _|_|_      ___|_      _|___
             | A| |    | |B  |    | | | |    |  D| |    | |E  |
       ...---|o o-|----|-o o-|----|-o o-|----|-o o-|----|-o o-|---...
             |____|    |___|_|    |__C__|    |_|___|    |_____|
                           |                   |
                           |IF-B          IF-D |
                           |                   |
                      ODUj(S)--            --ODUj(S)
                               \          /
                               |          |
                      ODUk(T)<-/          \->ODUk(T)


          Figure 3 Example of Controlling ODUk FA-LSPs Boundaries




Fu, et al.               Expires January 9, 2012                [Page 6]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


   A multi-region network is illustrated in figure 4.  Node B and D
   which are hybrid nodes support PSC being mapping into ODUk (e.g., by
   GFP-F).  Interface IF-B and IF-D support PSC switching capability
   (PSC(S)) and ODUk termination capability (ODUk(T)).  Interface within
   C only supports ODUk switching capability.  So Node B and D could be
   boundaries of ODUk FA-LSP for PSC LSP.


              PSC(S)   PSC(S)      ODUk(S)     PSC(S)  PSC(S)
                |        |          | |          |        |
              __|_      _|___       | |       ___|_      _|___
             | A| |    | |B  |     _|_|_     |   | |    |     |
       ...---|o o-|----|-o   |    | | | |    |   o-|----|-o o-|---...
             |____|    |   o-|----|-o o-|----|-o   |    |_____|
                       |___|_|    |_____|    |_|___|
                           |                   |
                           |IF-B           IF-D|
                           |                   |
                   PSC-ODUk IACD       PSC-ODUK IACD


          Figure 4 Example of Controlling ODUk FA-LSPs Boundaries

3.2.  Explicit Route Boundary Object (ERBO)

   In order to explicitly control hierarchy LSP creation, this document
   introduce a new object (ERBO-Explicit Route Boundary Object) carried
   in Path message.  The format of ERBO object is the same as ERO.  It
   looks more like the SERO defined in [RFC4873].

   One or more ERBOs may be carried in Path message.  Multiple ERBOs
   could support cascading of FA easy.  An ERBO must contain at least
   two subobjects.  The first and final one indicate the source and sink
   node of a FA-LSP or Composite Link [CL-REQ] which will be passed by
   one e2e LSP.  Other subobjects may be inserted into ERBO between
   source and sink node to indicates how to select the FA/Component Link
   or create them.

   The purpose is not to extend ERO and to limit the modifications to
   existing RSVP-TE procedures.  ERBO is a top object and parsed easy.
   Many attributes could be inserted into ERBO in the future for other
   requirements.

   This document defines four subobjects (i.e., Switching Cap, Encoding
   Type, Signal Type and Multiplexing Hierarchy) in ERBO.  These
   subobjects may be inserted into ERBO between source and sink node to
   indicates how to select the FA/Component Link or create them.  It is
   very convenient to use these subobects independently or combine them.



Fu, et al.               Expires January 9, 2012                [Page 7]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


   For example, Signal Type and Multiplexing Hierarchy subobject are
   enough for OTN multi-layer network application.

3.2.1.  Switching Capability subobject

   A new subobject, called the switching capability subobject, is
   defined for use in the ERBO.  The format of the switching capability
   subobject is defined 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |    Reserved   | Switching Cap |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 5 Switching Capability subobject in ERBO

   o  L-bit: 0 indicates that the attribute specified MUST be included.
      1 indicates that the attribute specified SHOULD be included.

   o  Type: To be defined.

   o  Length: It is always 4.

   o  Switching Capability (SC): Indicates which corresponding server
      layer should be triggered by the boundary node.  The value of
      switching capability is the same as the one in [RFC3471].

3.2.2.  Encoding Type subobject

   A new subobject, called the encoding type subobject, is defined for
   use in the ERBO.  The format of the encoding type subobject is
   defined 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |    Reserved   | Encoding Type |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 6 Encoding Type subobject in ERBO

   o  L-bit: 0 indicates that the attribute specified MUST be included.
      1 indicates that the attribute specified SHOULD be included.





Fu, et al.               Expires January 9, 2012                [Page 8]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


   o  Type: To be defined.

   o  Length: It is always 4.

   o  Encoding Type: It may need to further indicate which encoding type
      (e.g., SDH/SONET or G.709 in TDM) should be triggered.  It is the
      same as the one in [RFC3471].

3.2.3.  Signal Type subobject

   A new subobject, called the signal type subobject, is defined for use
   in the ERBO.  The format of the encoding type subobject is defined 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |   Reserved    |  Signal Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7 Signal Type subobject in ERBO

   o  L-bit: 0 indicates that the attribute specified MUST be included.
      1 indicates that the attribute specified SHOULD be included.

   o  Type: To be defined.

   o  Length: It is always 4.

   o  Signal Type: If there are several sub-layers within one server
      layer, it can further indicates which sub-layer should be
      triggered by the boundary node.  Following is the signal type in
      OTN.

















Fu, et al.               Expires January 9, 2012                [Page 9]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


    Value  Type
    -----  ----
    0      Not significant
    1      ODU1
    2      ODU2
    3      ODU3
    4      ODU4
    5      ODU0
    6      ODUflex
    7      ODUflex(G.hao)
    8      ODU2e
    9      STM-1
    10     STM-4
    11     STM-16
    12     STM-64
    13-255 Reserved (for future use)

3.2.4.  Multiplexing Hierarchy subobject

   A new subobject, called the Multiplexing Hierarchy (MH) subobject, is
   defined for use in the ERBO.  The format of the multiplexing
   hierarchy subobject is defined 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |   Reserved    |      MH       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 8 Multiplexing Hierarchy subobject in ERBO

   o  L-bit: 0 indicates that the attribute specified MUST be included.
      1 indicates that the attribute specified SHOULD be included.

   o  Type: To be defined.

   o  Length: It is always 4.

   o  Multiplexing Hierarchy (MH): It explicitly indicates the
      multiplexing hierarchy used for boundary node to configure it to
      the data plane and trigger one specific corresponding tunnel
      creation.  Following is the multiplexing hierarchy in current OTN.








Fu, et al.               Expires January 9, 2012               [Page 10]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


     Value  Type
     -----  ------
     0     ODU1-ODU0
     1     ODU2-ODU0
     2     ODU2-ODU1
     3     ODU2-ODU1-ODU0
     4     ODU2-ODUflex
     5     ODU3-ODU0
     6     ODU3-ODU1
     7     ODU3-ODU1-ODU0
     8     ODU3-ODU2
     9     ODU3-ODU2-ODU0
     10    ODU3-ODU2-ODU1
     11    ODU3-ODU2-ODU1-ODU0
     12    ODU3-ODU2-ODUflex
     13    ODU3-ODUflex
     14    ODU3-ODU2e
     15    ODU4-ODU0
     16    ODU4-ODU1
     17    ODU4-ODU1-ODU0
     18    ODU4-ODU2
     19    ODU4-ODU2-ODU0
     20    ODU4-ODU2-ODU1
     21    ODU4-ODU2-ODU1-ODU0
     22    ODU4-ODU2-ODUflex
     23    ODU4-ODU3
     24    ODU4-ODU3-ODU0
     25    ODU4-ODU3-ODU1
     26    ODU4-ODU3-ODU1-ODU0
     27    ODU4-ODU3-ODU2
     28    ODU4-ODU3-ODU2-ODU0
     29    ODU4-ODU3-ODU2-ODU1
     30    ODU4-ODU3-ODU2-ODU1-ODU0
     31    ODU4-ODU3-ODU2-ODUflex
     32    ODU4-ODU3-ODUflex
     33    ODU4-ODU3-ODU2e
     34    ODU4-ODUflex
     35    ODU4-ODU2e

3.2.5.  Signaling Procedure

   In order to signal an end-to-end LSP across multi layer, the LSP
   source node sends the RSVP-TE PATH message with ERO which indicates
   LSP route and ERBO which indicates the LSP route boundary If. if
   there are cascading FAs need to be created, there must be multiple
   associated ERBOs.  There must be nesting routing informatoin in ERO.
   The first and final address of node in ERBO SHOULD also be listed in
   the ERO.  This ensures that they are along the LSP path.  When a



Fu, et al.               Expires January 9, 2012               [Page 11]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


   interim node receives a PATH message, it will check ERBO to see if it
   is the layer boundary node.  If a interim node isn't a layer
   boundary, it will process the PATH message as the normal one of
   single layer LSP.  If a interim node finds its address is in ERBO, it
   is a layer boundary node.  So it will directly extract another
   boundary egress node from ERBO.  If it is necessary, it must also
   extract the server layer/sub-layer routing information from ERO based
   on a pair of boundary node.  Then the layer boundary node holds the
   PATH message and selects or creates a server layer/sub-layer LSP
   based on the detailed information of subobject carried in ERBO.

3.3.  Exclude Route Object(XRO)

   [RFC6001] introduce SC (Switching Capability) subobjects into XRO
   [RFC4874] which enables (when desired) the explicit identification of
   at least one switching capability to be excluded from the resource
   selection process described multi-region signaling.  This document
   adds more subobjects into the XRO to make multi-region and multi-
   layer signaling more flexible.

   o  Encoding Type: explicitly indicates the encoding type should be
      excluded (e.g., SONET/SDH or G.709 in TDM).

   o  Signal Type (ST) : explicitly indicates at least one ODUk signal
      type have to be excluded from the resource selection.

   o  Multiplexing Hierarchy (MH): explicitly indicates at least one MH
      have to be excluded from the resource selection.

   L bit and Attribute is the same as the Switching Capability (SC)
   subobject defined in [RFC6001].

3.3.1.  Encoding Type subobject

   A new subobject, called the encoding type subobject, is defined for
   use in the XRO.  The format of the encoding type subobject is defined
   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |    Attribute  | Encoding Type |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 9 Encoding Type subobject in XRO





Fu, et al.               Expires January 9, 2012               [Page 12]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


   o  L-bit: 0 indicates that the attribute specified MUST be excluded.
      1 indicates that the attribute specified SHOULD be avoided.

   o  Type: To be defined.

   o  Length: It is always 4.

   o  Attribute: 0 reserved value. 1 indicates that the specified
      encoding type SHOULD be excluded or avoided with respect to the
      preceding numbered or unnumbered interface subobject.

   o  Encoding Type: It indicates which Encoding Type has to excluded.
      It is the same as the one in [RFC3471].

3.3.2.  Signal Type subobject

   A new subobject, called the signal type subobject, is defined for use
   in the XRO.  The format of the encoding type subobject is defined 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |   Attribute   |  Signal Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10 Signal Type subobject in XRO

   o  L-bit: 0 indicates that the attribute specified MUST be excluded.
      1 indicates that the attribute specified SHOULD be avoided.

   o  Type: To be defined.

   o  Length: It is always 4.

   o  Attribute: 0 reserved value. 1 indicates that the specified signal
      type SHOULD be excluded or avoided with respect to the preceding
      numbered or unnumbered interface subobject.

   o  Signal Type: It indicates which Signal Type has to be excluded.
      The value of ST is the same as the one in ERBO.

3.3.3.  Multiplexing Hierarchy subobject

   A new subobject, called the Multiplexing Hierarchy (MH) subobject, is
   defined for use in the XRO.  The format of the multiplexing hierarchy
   subobject is defined as follows:



Fu, et al.               Expires January 9, 2012               [Page 13]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |   Attribute   |      MH       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 11 Multiplexing Hierarchy subobject in XRO

   o  L-bit: 0 indicates that the attribute specified MUST be excluded.
      1 indicates that the attribute specified SHOULD be avoided.

   o  Type: To be defined.

   o  Length: It is always 4.

   o  Attribute: 0 reserved value. 1 indicates that the specified
      multiplexing hierarchy SHOULD be excluded or avoided with respect
      to the preceding numbered or unnumbered interface subobject.

   o  Multiplexing Hierarchy (MH): It explicitly indicates which MH has
      to be excluded over a specified TE link, The value of multiplexing
      hierarchy is the same as the one in ERBO.


4.  Security Considerations

   This document does not introduce any new security considerations from
   the ones already detailed in [RFC5920] that describes the MPLS and
   GMPLS security threats, the related defensive techniques, and the
   mechanisms for detection and reporting.


5.  IANA Considerations

   TBD


6.  References

6.1.  Normative References

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

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.




Fu, et al.               Expires January 9, 2012               [Page 14]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


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

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

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

   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label Switching
              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5212]  Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
              M., and D. Brungard, "Requirements for GMPLS-Based Multi-
              Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
              July 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

6.2.  Informative References

   [CL-REQ]   C. Villamizar, "Requirements for MPLS Over a Composite
              Link", draft-ietf-rtgwg-cl-requirement-04 .

   [OTNv3-OSPF]
              D. Ceccarelli, "Traffic Engineering Extensions to OSPF for
              Generalized MPLS (GMPLS) Control of Evolving G.709 OTN
              Networks", draft-ceccarelli-ccamp-gmpls-ospf-g709-06 .


Authors' Addresses

   Xihua Fu
   ZTE Corporation

   Email: fu.xihua@zte.com.cn






Fu, et al.               Expires January 9, 2012               [Page 15]


Internet-Draft      RSVP-TE for Hierarchy LSP Control          July 2011


   Qilei Wang
   ZTE Corporation

   Email: wang.qilei@zte.com.cn


   Yuanlin Bao
   ZTE Corporation

   Email: bao.yuanlin@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 January 9, 2012               [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/