[Search] [pdf|bibtex] [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: September 30, 2011                              ZTE Corporation
                                                                 R. Jing
                                                                  X. Huo
                                                           China Telecom
                                                          March 29, 2011


 RSVP-TE Signaling Extension for Explicit Control of LSP Boundary in A
      GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
           draft-fuxh-ccamp-boundary-explicit-control-ext-02

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,
   some attributes have to be attached with the boundary nodes in order
   to explicit control the hierarchy LSP creation.  This document
   extends GMPLS signaling protocol for the requirement of explicit
   control the hierarchy LSP creation.

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 September 30, 2011.

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



Fu, et al.             Expires September 30, 2011               [Page 1]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


   (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
     1.1.  Conventions Used In This Document  . . . . . . . . . . . .  3
   2.  Explicit Route Boundary Object (ERBO)  . . . . . . . . . . . .  3
     2.1.  Switching Capability subobject . . . . . . . . . . . . . .  3
     2.2.  Encoding Type subobject  . . . . . . . . . . . . . . . . .  4
     2.3.  Signal Type subobject  . . . . . . . . . . . . . . . . . .  4
     2.4.  Multiplexing Hierarchy subobject . . . . . . . . . . . . .  5
     2.5.  Signaling Procedure  . . . . . . . . . . . . . . . . . . .  7
   3.  XRO Subobjects . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Encoding Type subobject  . . . . . . . . . . . . . . . . .  7
     3.2.  Signal Type subobject  . . . . . . . . . . . . . . . . . .  8
     3.3.  Multiplexing Hierarchy subobject . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






















Fu, et al.             Expires September 30, 2011               [Page 2]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


1.  Introduction

   [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,
   some attributes have to be attached with the boundary nodes in order
   to explicitly control the hierarchy LSP creation.  This document
   extends GMPLS signaling protocol for the requirement of explicit
   control the hierarchy LSP creation.

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.  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.  Other subobjects may be inserted
   into ERBO between source and sink node to indicates how to select the
   FA/Component Link or create them.

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 4 Switching Capability subobject in ERBO






Fu, et al.             Expires September 30, 2011               [Page 3]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


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

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

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

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  |



Fu, et al.             Expires September 30, 2011               [Page 4]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


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

                  Figure 6 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.


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

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




Fu, et al.             Expires September 30, 2011               [Page 5]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


   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.


     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



Fu, et al.             Expires September 30, 2011               [Page 6]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


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.  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 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 and
   other detail subobject infomration (e.g., Latency) from ERBO.  If it
   is necessary, it will 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.  XRO Subobjects

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 8 Encoding 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
      encoding type SHOULD be excluded or avoided with respect to the
      preceding numbered or unnumbered interface subobject.




Fu, et al.             Expires September 30, 2011               [Page 7]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


   o  Encoding Type: It may need to further indicate which encoding type
      have to excluded.  It is the same as the one in [RFC3471].

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 9 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 sub-layers have to be excluded.
      The value of ST is the same as the one in ERBO.

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:


      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  Multiplexing Hierarchy subobject in XRO





Fu, et al.             Expires September 30, 2011               [Page 8]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 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
      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 MHs
      have to be excluded over a specified TE link, The value of
      multiplexing hierarchy is the same as the one in ERBO.


4.  Security Considerations

   TBD


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.

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



Fu, et al.             Expires September 30, 2011               [Page 9]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


   [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

   [I-D.ietf-ccamp-gmpls-mln-extensions]
              Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
              D., and J. Roux, "Generalized Multi-Protocol Label
              Switching (GMPLS) Protocol Extensions for Multi-Layer and
              Multi-Region Networks (MLN/MRN)",
              draft-ietf-ccamp-gmpls-mln-extensions-12 (work in
              progress), February 2010.

   [I-D.ietf-rtgwg-cl-requirement]
              Ning, S., Malis, A., McDysan, D., Yong, L., JOUNAY, F.,
              and Y. Kamite, "Requirements for MPLS Over a Composite
              Link", draft-ietf-rtgwg-cl-requirement-00 (work in
              progress), February 2010.


Authors' Addresses

   Xihua Fu
   ZTE Corporation
   West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
   Xi An  710065
   P.R.China

   Phone: +8613798412242
   Email: fu.xihua@zte.com.cn
   URI:   http://wwwen.zte.com.cn/







Fu, et al.             Expires September 30, 2011              [Page 10]


Internet-Draft      RSVP-TE for LSP Boundary Control          March 2011


   Qilei Wang
   ZTE Corporation
   No.68 ZiJingHua Road,Yuhuatai District
   Nanjing  210012
   P.R.China

   Phone: +8613585171890
   Email: wang.qilei@zte.com.cn
   URI:   http://www.zte.com.cn/


   Yuanlin Bao
   ZTE Corporation
   5/F, R.D. Building 3, ZTE Industrial Park, Liuxian Road
   Shenzhen  518055
   P.R.China

   Phone: +86 755 26773731
   Email: bao.yuanlin@zte.com.cn
   URI:   http://www.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 September 30, 2011              [Page 11]