RSVP-TE Extensions for Associated Bidirectional LSPs
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06

CCAMP Working Group                                        F. Zhang, Ed.
Internet-Draft                                                       ZTE
Intended status: Standards Track                                 R. Jing
Expires: September 19, 2013                                China Telecom
                                                               R. Gandhi
                                                           Cisco Systems
                                                          March 18, 2013

          RSVP-TE Extensions for Associated Bidirectional LSPs
         draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06

Abstract

   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654],
   describes that MPLS-TP MUST support associated bidirectional point-
   to-point LSPs.

   This document provides a method to bind two unidirectional Label
   Switched Paths (LSPs) into an associated bidirectional LSP.  The
   association is achieved by defining the new Association Types in the
   Extended ASSOCIATION object.

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 19, 2013.

Copyright Notice

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

Zhang & Jing           Expires September 19, 2013               [Page 1]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Provisioning Model . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Signaling Procedure  . . . . . . . . . . . . . . . . . . .  4
       3.2.1.  Single Sided Provisioning Model  . . . . . . . . . . .  5
       3.2.2.  Double Sided Provisioning Model  . . . . . . . . . . .  5
       3.2.3.  Asymmetric Bandwidth LSPs  . . . . . . . . . . . . . .  5
       3.2.4.  Recovery Considerations  . . . . . . . . . . . . . . .  6
       3.2.5.  Associated Bidirectional LSPs and LSP Recovery . . . .  6
       3.2.6.  Associated Bidirectional LSPs and TE Mesh-Groups . . .  7
       3.2.7.  MPLS-TP Associated Bidirectional LSP Identifiers . . .  7
       3.2.8.  Teardown of Associated Bidirectional LSPs  . . . . . .  7
   4.  Association of LSPs  . . . . . . . . . . . . . . . . . . . . .  8
     4.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . .  8
       4.1.1  Signaling of the Extended Association Object  . . . . .  9
     4.2.  REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . .  9
       4.2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . .  9
         4.2.1.1.  Subobjects . . . . . . . . . . . . . . . . . . . . 10
       4.2.2.  LSP Control  . . . . . . . . . . . . . . . . . . . . . 10
       4.2.3.  Updated RSVP Message Formats . . . . . . . . . . . . . 10
       4.2.4.  Compatibility  . . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Association Type . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

 

Zhang & Jing           Expires September 19, 2013               [Page 2]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

1.  Introduction

   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
   describes that MPLS-TP MUST support associated bidirectional point-
   to-point LSPs.  Furthermore, an associated bidirectional LSP is
   useful for protection switching, for Operations, Administrations and
   Maintenance (OAM) messages that require a reply path.

   The requirements described in [RFC5654] are specifically mentioned in
   Section 2.1.  (General Requirements), and are repeated below:

   7.  MPLS-TP MUST support associated bidirectional point-to-point
   LSPs.

   11.  The end points of an associated bidirectional LSP MUST be aware
   of the pairing relationship of the forward and reverse LSPs used to
   support the bidirectional service.

   12.  Nodes on the LSP of an associated bidirectional LSP where both
   the forward and backward directions transit the same node in the same
   (sub)layer as the LSP SHOULD be aware of the pairing relationship of
   the forward and the backward directions of the LSP.

   14.  MPLS-TP MUST support bidirectional LSPs with asymmetric
   bandwidth requirements, i.e., the amount of reserved bandwidth
   differs between the forward and backward directions.

   50.  The MPLS-TP control plane MUST support establishing associated
   bidirectional P2P LSP including configuration of protection functions
   and any associated maintenance functions.

   The above requirements are also repeated in [RFC6373].

   The notion of association, as well as the corresponding Resource
   reSerVation Protocol (RSVP) ASSOCIATION object, is defined in
   [RFC4872], [RFC4873] and [RFC6689]. In that context, the object is
   used to associate recovery LSPs with the LSP they are protecting.
   This object also has broader applicability as a mechanism to
   associate RSVP state, and [RFC6780] defines the Extended ASSOCIATION
   object that can be more generally applied.

   This document provides a method to bind two reverse unidirectional
   Label Switched Paths (LSPs) into an associated bidirectional LSP. The
   association is achieved by defining the new Association Types in the
   Extended ASSOCIATION object.

2.  Conventions used in this document

 

Zhang & Jing           Expires September 19, 2013               [Page 3]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

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

3.  Overview

3.1.  Provisioning Model

   The associated bidirectional LSP's forward and backward directions
   are set up, monitored, and protected independently as required by
   [RFC5654].  Configuration information regarding the LSPs can be sent
   to one end or both ends of the LSP.  Depending on the method chosen,
   there are two models of signaling associated bidirectional LSP.  The
   first model is the single sided provisioning, the second model is the
   double sided provisioning.

   For the single sided provisioning, the configurations are sent to one
   end.  Firstly, a unidirectional tunnel is configured on this end,
   then a LSP under this tunnel is initiated with the Extended
   ASSOCIATION object carried in the Path message to trigger the peer
   end to set up the corresponding reverse TE tunnel and LSP.

   For the double sided provisioning, the two unidirectional TE tunnels
   are configured independently, then the LSPs under the tunnels are
   signaled with the Extended ASSOCIATION objects carried in the Path
   message to indicate each other to associate the two LSPs together to
   be an associated bidirectional LSP.

   A number of scenarios exist for binding LSPs together to be an
   associated bidirectional LSP.  These include: (1) both of them do not
   exist; (2) both of them exist; (3) one LSP exists, but the other one
   need to be established.  In all scenarios described, the provisioning
   models discussed above are applicable.

3.2.  Signaling Procedure

   This section describes the signaling procedures for associating
   bidirectional LSPs.

   Consider the topology described in Figure 1.  (An example of
   associated bidirectional LSP).  The LSP1 [via nodes A,D,B] (from A to
   B) and LSP2 [via nodes B,D,C,A] (from B to A) are being established
   or have been established, which can form an associated bidirectional
   LSP between node A and node B.

   LSP1 and LSP2 are referenced at the data plane level by the
 

Zhang & Jing           Expires September 19, 2013               [Page 4]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

   identifiers: A-Node_ID::A-Tunnel_Num::A-LSP_Num::B-Node_ID and
   B-Node_ID::B-Tunnel_Num::B-LSP_Num::A-Node_ID, respectively
   [RFC6370].

                             A-------D-------B
                              \     /
                               \   /
                                \ /
                                 C

           Figure 1: An example of associated bidirectional LSP

3.2.1.  Single Sided Provisioning Model

   For the single sided provisioning model, LSP1 is triggered by LSP2 or
   LSP2 is triggered by LSP1.  When LSP2 is triggered by LSP1, LSP1 is
   initialized or refreshed (if LSP1 already exists) at node A with the
   Extended ASSOCIATION object inserted in the Path message, the
   Association Type must be set to "Single Sided Associated
   Bidirectional LSPs". Terminating node B is triggered to set up LSP2
   by the received Extended ASSOCIATION object with the Association Type
   set to the value "Single Sided Associated Bidirectional LSPs", the
   Extended ASSOCIATION object inserted in LSP2's Path message is the
   same as in LSP1's Path message.

   When LSP1 is triggered by LSP2, the same rules are applicable. Based
   on the same values of the Extended ASSOCIATION objects in the two
   LSPs' Path messages, the two LSPs can be bound together to be an
   associated bidirectional LSP.

3.2.2.  Double Sided Provisioning Model

   For the double sided provisioning model, the Association Type must be
   set to "Double Sided Associated Bidirectional LSPs".

   Identification of the LSPs as being Associated Bidirectional LSPs
   occurs based on the identical contents in the LSPs' Extended
   ASSOCIATION objects.

3.2.3.  Asymmetric Bandwidth LSPs

   A variety of applications, such as Internet services and the return
   paths of OAM messages, exist and which MAY have different bandwidth
   requirements for each direction.  Additional [RFC5654] also specifies
   an asymmetric bandwidth requirement.  This requirement is
 

Zhang & Jing           Expires September 19, 2013               [Page 5]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

   specifically mentioned in Section 2.1.  (General Requirements), and
   is repeated below:

   14.  MPLS-TP MUST support bidirectional LSPs with asymmetric
   bandwidth requirements, i.e., the amount of reserved bandwidth
   differs between the forward and backward directions.

   The approach for supporting asymmetric bandwidth co-routed
   bidirectional LSPs is defined in [RFC6387].  As to the asymmetric
   bandwidth associated bidirectional LSPs, the existing SENDER_TSPEC
   object must be carried in the REVERSE_LSP object as a sub-object in
   the initialized LSP's Path message to specify the reverse LSP's
   traffic parameters in case that single sided provisioning model is
   adopted. Consider the topology described in Figure 1 in the context
   of asymmetric associated bidirectional LSP, and take LSP2 triggered
   by LSP1 as an example.  Node B is triggered to set up the reverse
   LSP2 with the corresponding asymmetric bandwidth by the Extended
   ASSOCIATION object with Association Type "Single Sided Associated
   Bidirectional LSPs" and the SENDER_TSPEC sub-object in LSP1's Path
   message, and the SENDER_TSPEC object in the LSP2' Path message is the
   same as the the SENDER_TSPEC sub-object in LSP1's Path message.  When
   double sided provisioning model is used, the two opposite LSPs with
   asymmetric bandwidths are concurrently initialized, and this
   requirement will be satisfied simultaneously.

3.2.4.  Recovery Considerations

   Consider the topology described in Figure 1, LSP1 and LSP2 form the
   associated bidirectional LSP.  Under the scenario of recovery, a
   third LSP (LSP3) may be used to protect LSP1.  LSP3 can be
   established before or after the failure occurs, it can share the same
   TE tunnel with LSP1.

   When node A detects that LSP1 is broken or needs to be reoptimized,
   LSP3 will be initialized or refreshed with the Extended ASSOCIATION
   object inherited from LSP1's Path message. Furthermore, if LSP3 is
   the protecting LSP [RFC4872], the ASSOCIATION object and PROTECTION
   object [RFC4872] need to be inherited from the LSP1 also. In this
   way, based on the same Extended ASSOCIATION object, LSP2 and LSP3
   will compose the new associated bidirectional LSPs.

3.2.5.  Associated Bidirectional LSPs and LSP Recovery

   LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not
   impacted by this document. The recovery mechanisms defined in
   [RFC4872] and [RFC4873] rely on the use of ASSOCIATION Objects, but
   use a different Association Type field value than defined in this
 

Zhang & Jing           Expires September 19, 2013               [Page 6]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

   document so should not be impacted. The mechanisms defined in
   [RFC4090] does not rely on the use of ASSOCIATION Objects and is
   therefore also not impacted by the mechanisms defined in this
   document.

3.2.6.  Associated Bidirectional LSPs and TE Mesh-Groups

   TE mesh-groups is defined in [RFC4972]. A node supporting both
   Associated Bidirectional LSPs and TE mesh-groups, MAY include an
   ASSOCIATION object as defined in this document in Path messages of
   LSPs used to support the mesh-group. To enable unambiguous
   identification of the mesh-group's associated bidirectional LSPs, the
   information carried in the ASSOCIATION object, including the contents
   of the Association Source and Identifier fields MUST be provisioned.

3.2.7.  MPLS-TP Associated Bidirectional LSP Identifiers

   [RFC6370] defines the LSP associated identifiers based on the
   signaling parameters of each unidirectional LSP. The combination
   of each unidirectional LSP's parameters is used to identify the
   Associated Bidirectional LSP.  Using the mechanisms defined in
   this document, any node that is along the path of both
   unidirectional LSPs can identify which pair of unidirectional LSPs
   support an Associated Bidirectional LSP as well as the signaling
   parameters required by [RFC6370].  Note that the LSP end-points
   will always be the path of both unidirectional LSPs.

3.2.8.  Teardown of Associated Bidirectional LSPs

   Associated bidirectional LSPs teardown also follows standard
   procedures defined in [RFC3209] and [RFC3473] either without or with
   the administrative status.  Note that teardown procedures of the
   associated bidirectional LSPs are independent of each other, so it is
   possible that while one LSP1 follows graceful teardown with
   administrative status, the other LSP2 is torn down without
   administrative status (using PathTear/ResvTear/PathErr with state
   removal).  However, for the double sided associated bidirectional
   LSPs, the teardown of LSP1 does not mean that LSP2 must be deleted,
   which depends on the local policy.  While for the single sided
   associated bidirectional LSPs, the teardown of the initialized LSP
   should induce the teardown of the trigger-established LSP, but the
   teardown of the trigger-established LSP (using PathErr with state
   removal) should not induce the teardown of the initialized LSP (which
   depends on the local policy).

 

Zhang & Jing           Expires September 19, 2013               [Page 7]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

4.  Association of LSPs

4.1. Extended ASSOCIATION Object 

   The Extended ASSOCIATION object is defined in [RFC6780], which
   enables MPLS-TP required LSP identification. The Extended ASSOCIATION
   object is used as follows for associated bidirectional LSPs.

   Association Types:

      In order to bind two reverse unidirectional LSPs to be an
      associated bidirectional LSP, new Association Types are defined in
      this document:

      Value      Type
      -----      -----
      4 (TBD)    Double Sided Associated Bidirectional LSPs (D)
      5 (TBD)    Single Sided Associated Bidirectional LSPs (A)

   Association ID: 16 bits

      For both double sided and single sided provisioning, Association
      ID is a value assigned by the node that originates the
      association.

   Association Source: 4 or 16 bytes

      Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].

      For double sided provisioning, Association Source is set to an
      address selected by the node that originates the association
      (which may be a management entity.)

      For single sided provisioning, Association Source is set to an
      address assigned to the node that originates the LSP.

   Global Association Source: 4 bytes

      Same as for IPv4 and IPv6 Extended ASSOCIATION objects defined in
      [RFC6780].

      For both double sided and single sided provisioning, Global
      Association Source, when used, is set to the Global_ID [RFC6370]
      of the node that originates association.

   Extended Association ID: 4 or 16 bytes

      This field contains data that is additional information to support
 

Zhang & Jing           Expires September 19, 2013               [Page 8]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

      unique identification.

      For both double sided and single sided provisioning, Extended
      Association ID, when used, is selected by the node that originates
      the association.

      If either Global Association Source or Extended Association
      Address is required, an Extended ASSOCIATION object [RFC6780] is
      used. Otherwise an ASSOCIATION object [RFC4872] is used.

4.1.1  Signaling of the Extended Association Object

   As described in [RFC6780], association is always done based on
   matching Path state or Resv state.  Upstream initialized association
   is represented in Extended ASSOCIATION objects carried in Path
   message and downstream initialized association is represented in
   Extended ASSOCIATION objects carried in Resv messages. The new
   Association Types defined in this document are only used in upstream
   initialized association. Thus they can only appear in Extended
   ASSOCIATION objects signaled in Path message.

   The rules associated with the processing of the Extended ASSOCIATION
   objects in RSVP message are discussed in [RFC6780]. It said that in
   the absence of Association Type-specific rules for identifying
   association, the included Extended ASSOCIATION objects MUST be
   identical.  This document adds no specific rules, the association
   will always operate based on the same Extended ASSOCIATION objects.

4.2.  REVERSE_LSP Object

   Path Computation Element (PCE)-based approaches, see [RFC4655], may
   be used for path computation of a GMPLS LSP, and consequently an
   associated bidirectional LSP, across domains and in a single domain.
   The ingress Label Switching Router (LSR), maybe serve as a PCE or
   Path Computation Client (PCC), has more information about the reverse
   LSP.  When the forward LSP is signaled, the reverse LSP's traffic
   parameters, explicit route, LSP attributes, etc, can be carried in
   the REVERSE_LSP object of the forward LSP's Path message.  The egress
   LSR can be triggered to establish the reverse LSP according to the
   control information.

4.2.1.  Format

   The information of the reverse LSP is specified via the REVERSE_LSP
   object, which is optional with class numbers in the form 11bbbbbb has
 

Zhang & Jing           Expires September 19, 2013               [Page 9]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

   the following format:

   Class = TBD (of the form 11bbbbbb), C_Type = 1 (TBD)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                        (Subobjects)                          //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This object MUST NOT be used when the Extended ASSOCIATION object do
   not exist or exist but the Association Type is not "Single Sided
   Associated Bidirectional LSPs".

4.2.1.1.  Subobjects

   The contents of a REVERSE_LSP object are a series of variable-length
   data items called subobjects, which can be SENDER_TSPCE,
   EXPLICIT_ROUTE object (ERO), Session Attribute Object, Admin Status
   Object, LSP_ATTRIBUTES Object, LSP_REQUIRED_ATTRIBUTES Object,
   PROTECTION Object, ASSOCIATION Object, Extended ASSOCIATION Objects,
   etc.

4.2.2.  LSP Control

   The signaling procedure without the REVERSE_LSP object carried in the
   LSP1's Path message is described in section 3.2.1, which is the
   default option.  A node includes a REVERSE_LSP object and Extended
   ASSOCIATION object with an "Single Sided Associated Bidirectional
   LSPs" Association Type in an outgoing Path message when it wishes to
   control the reverse LSP, and the receiver node B MUST convert the
   subobjects of the REVERSE_LSP object into the corresponding objects
   that carried in LSP2's Path message.  The case of a non-supporting
   egress node is outside of this document.  If node A want to tear down
   the associated bidirectional LSP, a PathTear message will be sent out
   and Node B is triggered to tear down LSP2.

4.2.3.  Updated RSVP Message Formats

   This section presents the RSVP message-related formats as modified by
   this document.  Unmodified RSVP message formats are not listed.

   The format of a Path message is as follows:

      <Path Message> ::= <Common Header> [ <INTEGRITY> ]
 

Zhang & Jing           Expires September 19, 2013              [Page 10]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <SESSION> <RSVP_HOP>
                         <TIME_VALUES>
                         [ <EXPLICIT_ROUTE> ]
                         <LABEL_REQUEST>
                         [ <PROTECTION> ]
                         [ <LABEL_SET> ... ]
                         [ <SESSION_ATTRIBUTE> ]
                         [ <NOTIFY_REQUEST> ... ]
                         [ <ADMIN_STATUS> ]
                         [ <EXTENDED_ASSOCIATION> ... ]
                         [ <REVERSE_LSP]
                         [ <POLICY_DATA> ... ]
                         <sender descriptor>

   The format of the <sender descriptor> is not modified by the present
   document.

4.2.4.  Compatibility

   The REVERSE_LSP object is defined with class numbers in the form
   11bbbbbb, which ensures compatibility with non-supporting nodes.  Per
   [RFC2205], nodes not supporting this extension will ignore the object
   but forward it, unexamined and unmodified, in all messages resulting
   from this message.  Especially, this object received in PathTear, or
   PathErr messages should be forwarded immediately in the same message,
   but should be saved with the corresponding state and forwarded in any
   refresh message resulting from that state when received in Path
   message.

5.  IANA Considerations

   IANA is requested to administer assignment of new values for
   namespace defined in this document and summarized in this section.

5.1.  Association Type

   Within the current document, two new Association Types are defined in
   the Extended ASSOCIATION object.

   Value      Type
   -----      -----
   4 (TBD)    Double Sided Associated Bidirectional LSPs (D)
   5 (TBD)    Single Sided Associated Bidirectional LSPs (A)

 

Zhang & Jing           Expires September 19, 2013              [Page 11]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

5.2.  REVERSE_LSP Object

   A new class named REVERSE_LSP has been created in the 11bbbbbb range
   (TBD) with the following definition:

   Class Types or C-types (1, TBD):

   There are no other IANA considerations introduced by this document.

6.  Security Considerations

   This document introduces two new Association Types, and except this,
   there are no security issues about the Extended ASSOCIATION object
   are introduced here.

   The procedures defined in this document result in an increase in the
   amount of topology information carried in signaling messages since
   the presence of the REVERSE_LSP object necessarily means that there
   is more information about associated bidirectional LSPs.  Thus, in
   the event of the interception of a signaling message, slightly more
   could be deduced about the state of the network than was previously
   the case, but this is judged to be a very minor security risk as this
   information is already available via routing.

   Otherwise, this document introduces no additional security
   considerations.  For a general discussion on MPLS and GMPLS related
   security issues, see the MPLS/GMPLS security framework [RFC5920].

7.  Acknowledgement

   The authors would like to thank Lou Berger for his great guidance in
   this work, George Swallow and Jie Dong for the discussion of
   recovery, Lamberto Sterling for his valuable comments on the section
   of asymmetric bandwidths, Daniel King for the review of the document,
   Attila Takacs for the discussion of the provisioning model.  At the
   same time, the authors would also like to acknowledge the
   contributions of Bo Wu, Xihua Fu, Lizhong Jin for the initial
   discussions, and Wenjuan He for the prototype implementation. The
   authors would also like to thank Siva Sivabalan, Eric Osborne and
   Robert Sawaya for the discussion on the association object.

 

Zhang & Jing           Expires September 19, 2013              [Page 12]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

8.  References

8.1.  Normative references

   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
              Association Object Extensions", RFC 6780, October 2012.

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

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 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.

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

   [RFC4090]  Pan, P., Swallow, G., Atlas, A., "Fast Reroute Extensions
              to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

   [RFC4872]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
              Extensions in Support of End-to-End Generalized Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
              2007.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, May 2007.

   [RFC4972]  Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S.,
              Psenak, P., Mabbey, P., "Routing Extensions for Discovery
              of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic
              Engineering (TE) Mesh Membership", RFC 4972, July 2007.

 

Zhang & Jing           Expires September 19, 2013              [Page 13]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

8.2.  Informative References

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

   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

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

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.

   [RFC6373]  Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
              Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
              Framework", RFC 6373, September 2011.

   [RFC6387]  Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
              Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
              Switched Paths (LSPs)", RFC 6387, September 2011.

   [RFC6689]  Berger, L., "Usage of The RSVP Association Object", RFC
              6689, July 2012.

 

Zhang & Jing           Expires September 19, 2013              [Page 14]
Internet-Draft   RSVP-TE Extensions for Associated LSPs   March 18, 2013

Authors' Addresses

   Fei Zhang (editor)
   ZTE

   Email: zhang.fei3@zte.com.cn

   Ruiquan Jing
   China Telecom

   Email: jingrq@ctbri.com.cn

   Fan Yang
   ZTE

   Email: yang.fan5@zte.com.cn

   Weilian Jiang
   ZTE

   Email: jiang.weilian@zte.com.cn

   Rakesh Gandhi
   Cisco Systems

   Email: rgandhi@cisco.com

Zhang & Jing           Expires September 19, 2013              [Page 15]