summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7551.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7551.txt')
-rw-r--r--doc/rfc/rfc7551.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc7551.txt b/doc/rfc/rfc7551.txt
new file mode 100644
index 0000000..24c3126
--- /dev/null
+++ b/doc/rfc/rfc7551.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) F. Zhang, Ed.
+Request for Comments: 7551 Huawei
+Category: Standards Track R. Jing
+ISSN: 2070-1721 China Telecom
+ R. Gandhi, Ed.
+ Cisco Systems
+ May 2015
+
+
+ RSVP-TE Extensions
+ for Associated Bidirectional Label Switched Paths (LSPs)
+
+Abstract
+
+ This document describes Resource Reservation Protocol (RSVP)
+ extensions to bind two point-to-point unidirectional Label Switched
+ Paths (LSPs) into an associated bidirectional LSP. The association
+ is achieved by defining new Association Types for use in ASSOCIATION
+ and in Extended ASSOCIATION Objects. One of these types enables
+ independent provisioning of the associated bidirectional LSPs on both
+ sides, while the other enables single-sided provisioning. The
+ REVERSE_LSP Object is also defined to enable a single endpoint to
+ trigger creation of the reverse LSP and to specify parameters of the
+ reverse LSP in the single-sided provisioning case.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7551.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 1]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 2]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Conventions Used in This Document ...............................5
+ 2.1. Key Word Definitions .......................................5
+ 2.2. Reverse Unidirectional LSPs ................................5
+ 2.3. Message Formats ............................................5
+ 3. Overview ........................................................6
+ 3.1. Provisioning Model Overview ................................6
+ 3.1.1. Single-Sided Provisioning ...........................6
+ 3.1.2. Double-Sided Provisioning ...........................6
+ 3.2. Association Signaling Overview .............................6
+ 3.2.1. Single-Sided Provisioning ...........................7
+ 3.2.2. Double-Sided Provisioning ...........................7
+ 3.3. Asymmetric Bandwidth Signaling Overview ....................8
+ 3.3.1. Single-Sided Provisioning ...........................8
+ 3.3.2. Double-Sided Provisioning ...........................8
+ 3.4. Recovery LSP Overview ......................................8
+ 4. Message and Object Definitions ..................................9
+ 4.1. RSVP Message Formats .......................................9
+ 4.2. ASSOCIATION Object .........................................9
+ 4.3. Extended ASSOCIATION Object ...............................10
+ 4.4. REVERSE_LSP Object Definition .............................11
+ 4.4.1. REVERSE_LSP Object Format ..........................11
+ 4.4.2. REVERSE_LSP Subobjects .............................11
+ 5. Processing Rules ...............................................12
+ 5.1. Rules for ASSOCIATION Object ..............................12
+ 5.1.1. Compatibility for ASSOCIATION Object ...............14
+ 5.2. Rules for REVERSE_LSP Object ..............................14
+ 5.2.1. Compatibility for REVERSE_LSP Object ...............16
+ 6. IANA Considerations ............................................16
+ 6.1. Association Types .........................................16
+ 6.2. REVERSE_LSP Object ........................................16
+ 6.3. Reverse LSP Failure PathErr Sub-code ......................17
+ 7. Security Considerations ........................................17
+ 8. References .....................................................18
+ 8.1. Normative References ......................................18
+ 8.2. Informative References ....................................19
+ Acknowledgements ..................................................20
+ Contributors ......................................................20
+ Authors' Addresses ................................................20
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 3]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+1. Introduction
+
+ The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
+ specifies that MPLS-TP MUST support associated bidirectional point-
+ to-point Label Switched Paths (LSPs). These requirements are given
+ in Section 2.1 ("General Requirements") of that document and are
+ partially rephrased 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.
+
+ 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].
+
+ Furthermore, an associated bidirectional LSP is also useful for
+ protection-switching for Operations, Administration, and Maintenance
+ (OAM) messages that require a return path.
+
+ A variety of applications, such as Internet services and the return
+ paths of OAM messages, exist and may have different upstream and
+ downstream bandwidth requirements. [RFC5654] specifies an asymmetric
+ bandwidth requirement in Section 2.1 ("General Requirements"), and it
+ 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].
+
+ The method of association and the corresponding Resource Reservation
+ Protocol (RSVP) ASSOCIATION Object are defined in [RFC4872],
+ [RFC4873], and [RFC6689]. In that context, the ASSOCIATION Object is
+ used to associate a recovery LSP with the LSP it is protecting. This
+
+
+
+Zhang, et al. Standards Track [Page 4]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ object also has broader applicability as a mechanism to associate
+ RSVP states. [RFC6780] defines the Extended ASSOCIATION Objects that
+ can be more generally applied for this purpose. This document uses
+ the term "(Extended) ASSOCIATION Objects" to refer collectively to
+ the ASSOCIATION Objects defined in [RFC4872] and the Extended
+ ASSOCIATION Objects defined in [RFC6780].
+
+ This document specifies mechanisms for binding two reverse
+ unidirectional LSPs into an associated bidirectional LSP. The
+ association is achieved by defining new Association Types for use in
+ (Extended) ASSOCIATION Objects. One of these types enables
+ independent provisioning of the associated bidirectional LSPs, while
+ the other enables single-sided provisioning. The REVERSE_LSP Object
+ is also defined to enable a single endpoint to trigger creation of
+ the reverse LSP and to specify parameters of the reverse LSP in the
+ single-sided provisioning case. For example, the REVERSE_LSP Object
+ allow asymmetric upstream and downstream bandwidths for the
+ associated bidirectional LSP.
+
+2. Conventions Used in This Document
+
+2.1. Key Word Definitions
+
+ 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.2. Reverse Unidirectional LSPs
+
+ Two reverse unidirectional LSPs are setup in the opposite directions
+ between a pair of source and destination nodes to form an associated
+ bidirectional LSP. A reverse unidirectional LSP originates on the
+ same node where the forward unidirectional LSP terminates, and it
+ terminates on the same node where the forward unidirectional LSP
+ originates.
+
+2.3. Message Formats
+
+ This document uses the Routing Backus-Naur Form (RBNF) to define
+ message formats as defined in [RFC5511].
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 5]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+3. Overview
+
+3.1. Provisioning Model Overview
+
+ This section provides an overview and definition of the models for
+ provisioning associated bidirectional LSPs.
+
+ The associated bidirectional LSP's forward and reverse unidirectional
+ LSPs are established, monitored, and protected independently as
+ specified by [RFC5654]. Configuration information regarding the LSPs
+ can be provided at one or both endpoints of the associated
+ bidirectional LSP. Depending on the method chosen, there are two
+ models of creating an associated bidirectional LSP -- single-sided
+ provisioning and double-sided provisioning.
+
+3.1.1. Single-Sided Provisioning
+
+ For the single-sided provisioning, the Traffic Engineering (TE)
+ tunnel is configured only on one endpoint. An LSP for this tunnel is
+ initiated by the initiating endpoint with the (Extended) ASSOCIATION
+ and REVERSE_LSP Objects inserted in the Path message. The other
+ endpoint then creates the corresponding reverse TE tunnel and signals
+ the reverse LSP in response using information from the REVERSE_LSP
+ Object and other objects present in the received Path message.
+
+3.1.2. Double-Sided Provisioning
+
+ For the double-sided provisioning, two unidirectional TE tunnels are
+ configured independently, one on each endpoint. The LSPs for the
+ tunnels are signaled with (Extended) ASSOCIATION Objects inserted in
+ the Path message by both endpoints to indicate that the two LSPs are
+ to be associated to form a bidirectional LSP.
+
+3.2. Association Signaling Overview
+
+ This section provides an overview of the association signaling
+ methods for the associated bidirectional LSPs.
+
+ Three scenarios exist for binding two unidirectional LSPs together to
+ form an associated bidirectional LSP. These are:
+
+ 1) Neither unidirectional LSP exists, and both must be established.
+
+ 2) Both unidirectional LSPs exist, but the association must be
+ established.
+
+ 3) One LSP exists, but the reverse associated LSP must be
+ established.
+
+
+
+Zhang, et al. Standards Track [Page 6]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ The following sections describe the applicable provisioning models
+ for each of these scenarios.
+
+ Path Computation Element (PCE)-based approaches [RFC4655] may be used
+ for path computation of an associated bidirectional LSP. However,
+ these approaches are outside the scope of this document.
+
+ Consider the topology described in Figure 1. LSP1 from node A to B,
+ takes the path A,D,B, and LSP2 from node B to A takes the path
+ B,D,C,A. These two LSPs, once established and associated, form an
+ associated bidirectional LSP between nodes A and B.
+
+ LSP1 -->
+ A-------D-------B
+ \ / <-- LSP2
+ \ /
+ \ /
+ C
+
+ Figure 1: An Example of Associated Bidirectional LSP
+
+3.2.1. Single-Sided Provisioning
+
+ For the single-sided provisioning model, creation of reverse LSP1
+ shown in Figure 1 is triggered by LSP2, or creation of reverse LSP2
+ is triggered by LSP1. When creation of reverse LSP2 is triggered by
+ LSP1, LSP1 is provisioned first (or refreshed, if LSP1 already
+ exists) at node A. LSP1 is then signaled with an (Extended)
+ ASSOCIATION, and REVERSE_LSP Objects are inserted in the Path
+ message. The Association Type indicates single-sided provisioning.
+ Upon receiving this Path message for LSP1, node B establishes reverse
+ LSP2. The (Extended) ASSOCIATION Object inserted in LSP2's Path
+ message is the same as that received in LSP1's Path message.
+
+ A similar procedure is used if LSP2 is provisioned first at node B,
+ and the creation of reverse LSP1 at node A is triggered by LSP2. In
+ both scenarios, the two unidirectional LSPs are bound together to
+ form an associated bidirectional LSP based on identical (Extended)
+ ASSOCIATION Objects in the two LSPs' Path messages.
+
+3.2.2. Double-Sided Provisioning
+
+ For the double-sided provisioning model, both LSP1 and LSP2 shown in
+ Figure 1 are signaled independently with (Extended) ASSOCIATION
+ Objects inserted in the Path messages, in which the Association Type
+ indicating double-sided provisioning is included. In this case, the
+ two unidirectional LSPs are bound together to form an associated
+ bidirectional LSP based on identical (Extended) ASSOCIATION Objects
+
+
+
+Zhang, et al. Standards Track [Page 7]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ in the two LSPs' Path messages. In all three scenarios described in
+ Section 3.2, the LSPs to be selected for the association are
+ provisioned by the management action applied at both endpoints.
+
+3.3. Asymmetric Bandwidth Signaling Overview
+
+ This section provides an overview of the methods for signaling
+ asymmetric upstream and downstream bandwidths for the associated
+ bidirectional LSPs.
+
+3.3.1. Single-Sided Provisioning
+
+ A new REVERSE_LSP Object for use in the single-sided provisioning
+ model is defined in this document, in Section 4.4. The REVERSE_LSP
+ Object allows the initiating node of the single-sided provisioned LSP
+ to trigger creation of the reverse LSP on the remote node. When the
+ single-sided provisioning model is used, a SENDER_TSPEC Object can be
+ added in the REVERSE_LSP Object as a subobject in the initiating
+ LSP's Path message to specify a different bandwidth for the reverse
+ LSP. As described in Section 4.4, addition of the REVERSE_LSP Object
+ also allows the initiating node to control other aspects of the
+ reverse LSP (such as its path) by including other objects in a
+ REVERSE_LSP Object.
+
+ Consider again the topology described in Figure 1, where the creation
+ of reverse LSP2 is triggered by LSP1. Node A signals LSP1 with the
+ (Extended) ASSOCIATION Object with Association Type indicating
+ single-sided provisioning and inserts a SENDER_TSPEC subobject for
+ use by LSP2 in the REVERSE_LSP Object in the Path message. Node B
+ then establishes the LSP2 in the reverse direction using the
+ asymmetric bandwidth thus specified by LSP1 and allows node A to
+ control the reverse LSP2.
+
+3.3.2. Double-Sided Provisioning
+
+ When the double-sided provisioning model is used, the two
+ unidirectional LSPs are established with separate bandwidths, which
+ may or may not be identical. However, these LSPs are associated
+ purely based on the identical contents of their (Extended)
+ ASSOCIATION Objects.
+
+3.4. Recovery LSP Overview
+
+ Recovery of each unidirectional LSP forming the bidirectional LSP is
+ independent [RFC5654] and is based on the parameters signaled in
+ their respective RSVP Path messages.
+
+
+
+
+
+Zhang, et al. Standards Track [Page 8]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ Recovery LSP association is based on the identical content of the
+ (Extended) ASSOCIATION Objects signaled in their Path messages during
+ the initial LSP setup for both single-sided and double-sided
+ provisioning. As defined in [RFC6780], multiple ASSOCIATION Objects
+ may be present in the signaling of a single LSP.
+
+4. Message and Object Definitions
+
+4.1. 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> ]
+ [ [<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> ]
+ [ <ASSOCIATION> ... ]
+ [ <REVERSE_LSP> ... ]
+ [ <POLICY_DATA> ... ]
+ <sender descriptor>
+
+ The format of the <sender descriptor> is not modified by this
+ document.
+
+4.2. ASSOCIATION Object
+
+ The ASSOCIATION Object is populated using the rules defined below for
+ associating two reverse unidirectional LSPs to form an associated
+ bidirectional LSP.
+
+ Association Types:
+
+ In order to bind two reverse unidirectional LSPs to be an
+ associated bidirectional LSP, the Association Type MUST be set to
+ indicate either single-sided or double-sided LSPs.
+
+
+
+
+
+Zhang, et al. Standards Track [Page 9]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ The new Association Types are defined as follows:
+
+ Value Type
+ ----- -----
+ 3 Double-Sided Associated Bidirectional LSP (D)
+ 4 Single-Sided Associated Bidirectional LSP (A)
+
+ Association ID:
+
+ For both single-sided and double-sided provisioning, Association
+ ID MUST be set to a value assigned by the node that originates the
+ association for the bidirectional LSP.
+
+ Association Source:
+
+ Association Source MUST be set to an address selected by the node
+ that originates the association for the bidirectional LSP. For
+ example, this may be a management entity or, in the case of
+ single-sided provisioning, an address assigned to the node that
+ originates the LSP.
+
+4.3. Extended ASSOCIATION Object
+
+ The Extended ASSOCIATION Object is populated using the rules defined
+ below for associating two reverse unidirectional LSPs to form a
+ bidirectional LSP.
+
+ The Association Type, Association ID, and Association Source MUST be
+ set as defined for the ASSOCIATION Object in Section 4.1.
+
+ Global Association Source:
+
+ For both single-sided and double-sided provisioning, Global
+ Association Source, when used, MUST be set to the Global_ID
+ [RFC6370] of the node that originates the association for the
+ bidirectional LSP.
+
+ Extended Association ID:
+
+ For both single-sided and double-sided provisioning, Extended
+ Association ID, when used, MUST be set to a value selected by the
+ node that originates the association for the bidirectional LSP.
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 10]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+4.4. REVERSE_LSP Object Definition
+
+4.4.1. REVERSE_LSP Object Format
+
+ The REVERSE_LSP Object is carried in the Path message of a forward
+ LSP to provide information to be used by the reverse LSP. The object
+ also indicates that the LSP is the forward LSP of a single-sided
+ associated bidirectional LSP.
+
+ The Object has the following format:
+
+ Class_Num = 203, C_Type = 1.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ // (Subobjects) //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.4.2. REVERSE_LSP Subobjects
+
+ Subobjects are used to override the default contents of a Path
+ message of a reverse LSP; see Section 5.2. The contents of a
+ REVERSE_LSP Object is zero or more variable-length subobjects that
+ have the same format as RSVP Objects; see Section 3.1.2 of [RFC2205].
+ Any object that may be carried in a Path message MAY be carried in
+ the REVERSE_LSP Object. Subobject ordering MUST follow any Path
+ message Object ordering requirements.
+
+ Examples of the Path message Objects that can be carried in the
+ REVERSE_LSP Object are (but not limited to):
+
+ - SENDER_TSPEC [RFC2205]
+ - EXPLICIT_ROUTE Object (ERO) [RFC3209]
+ - SESSION_ATTRIBUTE Object [RFC3209]
+ - ADMIN_STATUS Object [RFC3473]
+ - LSP_REQUIRED_ATTRIBUTES Object [RFC5420]
+ - PROTECTION Object [RFC3473] [RFC4872]
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 11]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+5. Processing Rules
+
+ In general, the processing rules for the ASSOCIATION Object are as
+ specified in [RFC4872], and those for the Extended ASSOCIATION Object
+ are as specified in [RFC6780]. The following sections describe the
+ rules for processing (Extended) ASSOCIATION Objects for both double-
+ sided and single-sided associated bidirectional LSPs and REVERSE_LSP
+ Objects for single-sided associated bidirectional LSPs.
+
+5.1. Rules for ASSOCIATION Object
+
+ This section defines the processing for the association of two
+ unidirectional LSPs to form an associated bidirectional LSP. Such
+ association is based on the use of an (Extended) ASSOCIATION Object.
+
+ The procedures related to the actual identification of associations
+ between LSPs based on (Extended) ASSOCIATION Objects are defined in
+ [RFC6780]. [RFC6780] specifies that in the absence of rules for
+ identifying the association that are specific to the Association
+ Type, the included (Extended) ASSOCIATION Objects in the LSPs MUST be
+ identical in order for an association to exist. This document adds
+ no specific rules for the new Association Types defined, and the
+ identification of an LSP association therefore proceeds as specified
+ in [RFC6780].
+
+ As described in [RFC6780], association of LSPs can be upstream or
+ downstream initiated, as indicated by (Extended) ASSOCIATION Objects
+ in Path or Resv Messages. The association of bidirectional LSPs is
+ always upstream initiated; therefore, the Association Types defined
+ in this document are only to be interpreted in Path Messages. These
+ types SHOULD NOT be used in ASSOCIATION Objects carried in Resv
+ messages and SHOULD be ignored if present.
+
+ To indicate an associated bidirectional LSP, an ingress node MUST
+ insert an (Extended) ASSOCIATION Object into the Path message of the
+ unidirectional LSP that is part of the associated bidirectional LSP
+ it initiates. If either Global Association Source or Extended
+ Association Address is required, then an Extended ASSOCIATION Object
+ [RFC6780] MUST be inserted in the Path message. Otherwise, an
+ ASSOCIATION Object MAY be used. (Extended) ASSOCIATION Objects with
+ both single-sided and double-sided Association Types MUST NOT be
+ added or sent in the same Path message.
+
+ The ingress node MUST set the Association Type field in the
+ (Extended) ASSOCIATION Object to "Single-Sided Associated
+ Bidirectional LSP" when single-sided provisioning is used, and to
+ "Double-Sided Associated Bidirectional LSP" when double-sided
+ provisioning is used.
+
+
+
+Zhang, et al. Standards Track [Page 12]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ A transit node MAY identify the unidirectional LSPs of an associated
+ bidirectional LSP based on (Extended) ASSOCIATION Objects, with the
+ Association Type values defined in this document, carried in Path
+ messages. Clearly, such associations are only possible when the LSPs
+ transit the node. As mentioned above, such associations are made per
+ the rules defined in [RFC6780].
+
+ Egress nodes that support the Association Types defined in this
+ document identify the unidirectional LSPs of an associated
+ bidirectional LSP based on (Extended) ASSOCIATION Objects carried in
+ Path messages. Note that an ingress node will normally be the
+ ingress for one of the unidirectional LSPs that make up an associated
+ bidirectional LSP. When an egress node receives a Path message
+ containing an (Extended) ASSOCIATION Object with one of the
+ Association Types defined in this document, it MUST attempt to
+ identify other LSPs (including ones for which it is an ingress node)
+ with which the LSP being processed is associated. As defined above,
+ such associations are made per the rules defined in [RFC6780]. An
+ LSP not being associated at the time of signaling (for example,
+ during rerouting or re-optimization) on an egress node is not
+ necessarily considered an error condition.
+
+ Associated bidirectional LSP teardown follows the standard procedures
+ defined in [RFC3209] and [RFC3473] either without or with the
+ administrative status. Generally, the teardown procedures of the
+ unidirectional LSPs forming an associated bidirectional LSP are
+ independent of each other, so it is possible that while one LSP
+ follows graceful teardown with administrative status, the reverse LSP
+ is torn down without administrative status (using
+ PathTear/ResvTear/PathErr with state removal). See Section 5.2 for
+ additional rules related to LSPs established using single-sided
+ provisioning.
+
+ When an LSP signaled with a Path message containing an (Extended)
+ ASSOCIATION Object with an Association Type defined in this document
+ is torn down, the processing node SHALL remove the binding of the LSP
+ to any previously identified associated bidirectional LSP.
+
+ No additional processing is needed for Path messages with an
+ (Extended) ASSOCIATION Object containing an Association Type field
+ set to "Double-Sided Associated Bidirectional LSP".
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 13]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+5.1.1. Compatibility for ASSOCIATION Object
+
+ The ASSOCIATION Object has been defined in [RFC4872] and the Extended
+ ASSOCIATION Object has been defined in [RFC6780], both with class
+ numbers in the form 11bbbbbb, which ensures compatibility with non-
+ supporting nodes. Per [RFC2205], such nodes will ignore the object
+ but forward it without modification.
+
+ Operators wishing to use a function supported by a particular
+ Association Type SHOULD ensure that the type is supported on any node
+ that is expected to act on the association [RFC6780].
+
+ An egress node that does not support the Association Types defined in
+ this document is expected to return a PathErr with Error Code
+ "Admission Control Failure" (1) [RFC2205] and Sub-code "Bad
+ Association Type" (5) [RFC4872].
+
+ LSP recovery as defined in [RFC4872] and [RFC4873] is not impacted by
+ this document. The recovery mechanisms defined in [RFC4872] and
+ [RFC4873] rely on the use of the (Extended) ASSOCIATION Objects, but
+ they use a different value for Association Type; multiple ASSOCIATION
+ Objects can be present in the LSP Path message and can coexist with
+ the procedures defined in this document.
+
+5.2. Rules for REVERSE_LSP Object
+
+ When a node initiates setup of an LSP using a Path message containing
+ an ASSOCIATION or Extended ASSOCIATION Object, and the Association
+ Type set to "Single-Sided Associated Bidirectional LSP", the Path
+ message MUST carry the REVERSE_LSP Object to trigger creation of a
+ reverse LSP on the egress node.
+
+ The REVERSE_LSP subobject MAY contain any of the objects that the
+ initiating node desires to have included in the Path message for the
+ associated reverse LSP. The REVERSE_LSP Object SHOULD NOT be
+ included in a REVERSE_LSP Object.
+
+ A transit node receiving a valid Path message containing a
+ REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in
+ the outgoing Path message.
+
+ An egress node, upon receiving a Path message containing an
+ REVERSE_LSP Object MUST verify that the Path message contains an
+ ASSOCIATION or Extended ASSOCIATION Object with the Association Type
+ set to "Single-Sided Associated Bidirectional LSP". If it does not,
+ the Path message MUST NOT trigger a reverse LSP. This verification
+ failure SHOULD NOT trigger any RSVP message but can be logged
+ locally, and perhaps reported through network management mechanisms.
+
+
+
+Zhang, et al. Standards Track [Page 14]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ Once validated, the egress node MUST create an LSP in the reverse
+ direction or reject the Path message. If the creation of a reverse
+ LSP fails, the egress node MUST return a PathErr with Error Code
+ "Admission Control Failure" (1) [RFC2205] and Sub-code "Reverse LSP
+ Failure" (6) defined in this document. Note that normal Resv
+ processing SHOULD NOT be impacted by the presence of an ASSOCIATION
+ Object with an Association Type set to "Single-Sided Associated
+ Bidirectional LSP".
+
+ The egress node MUST use the subobjects contained in the REVERSE_LSP
+ Object for initiating the reverse LSP. When a subobject is not
+ present in the received REVERSE_LSP Object, the egress node SHOULD
+ initiate the reverse LSP based on the information contained in the
+ received Path message of the forward LSP as follows:
+
+ o The egress node SHOULD copy the information from the received
+ SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION,
+ ADMIN_STATUS, and PROTECTION Objects in the forward LSP Path
+ message to form the Path message of the reverse LSP when the
+ object is not present in the received REVERSE_LSP Object.
+
+ o The IP address in the reverse LSP's SESSION Object SHOULD be set
+ to the IP address carried in the received SENDER_TEMPLATE Object;
+ and conversely, the IP address in the SENDER_TEMPLATE Object
+ SHOULD be set to the IP address carried in the received SESSION
+ Object. There are no additional requirements related to the IDs
+ carried in the SESSION and SENDER_TEMPLATE Objects.
+
+ o When the forward LSP Path message contains a RECORD_ROUTE Object,
+ the egress node SHOULD include the received RECORD_ROUTE Object in
+ the reverse LSP Path message. Local node information SHOULD also
+ be recorded per standard Path message processing.
+
+ o There are no specific requirements related to other objects.
+
+ The resulting Path message is used to create the reverse LSP. From
+ this point on, standard Path message processing is used in processing
+ the resulting Path message.
+
+ Note that the contents of a forward LSP, including a carried
+ REVERSE_LSP Object, may change over the life of an LSP, and such
+ changes MUST result in corresponding changes in the reverse LSP. In
+ particular, any object or subobject that was copied during the
+ creation of the initial reverse LSP's Path message MUST be copied
+ when modified in the forward LSP, and a trigger Path message MUST be
+ processed.
+
+
+
+
+
+Zhang, et al. Standards Track [Page 15]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ The removal of the REVERSE_LSP Object in the received Path message
+ SHOULD cause the egress node to tear down any previously established
+ reverse LSP.
+
+ When the egress node receives a PathTear message for the forward LSP
+ or whenever the forward LSP is torn down, the node MUST remove the
+ associated reverse LSP using standard PathTear message processing.
+ Teardown of the reverse LSP for other reasons SHOULD NOT trigger
+ removal of the initiating LSP, but it SHOULD result in the egress
+ node sending a PathErr with Error Code "Admission Control Failure"
+ (1) [RFC2205] and Sub-code "Reverse LSP Failure" (6) defined in this
+ document.
+
+5.2.1. Compatibility for REVERSE_LSP Object
+
+ The REVERSE_LSP Object is defined with class numbers in the form
+ 11bbbbbb, which ensures compatibility with non-supporting nodes. Per
+ [RFC2205], such nodes will ignore the object but forward it without
+ modification.
+
+6. IANA Considerations
+
+ IANA has registered values for the namespace defined in this document
+ and summarized in this section.
+
+6.1. Association Types
+
+ IANA maintains the "Generalized Multi-Protocol Label Switching
+ (GMPLS) Signaling Parameters" registry (see
+ <http://www.iana.org/assignments/gmpls-sig-parameters>). The
+ "Association Type" subregistry is included in this registry.
+
+ This registry has been updated by new Association Types for
+ ASSOCIATION and Extended ASSOCIATION Objects defined in this document
+ as follows:
+
+ Value Name Reference
+ 3 Double-Sided Associated Bidirectional LSP (D) Section 4.2
+ 4 Single-Sided Associated Bidirectional LSP (A) Section 4.2
+
+6.2. REVERSE_LSP Object
+
+ IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
+ registry (see <http://www.iana.org/assignments/rsvp-parameters>).
+ The "Class Names, Class Numbers, and Class Types" subregistry is
+ included in this registry.
+
+
+
+
+
+Zhang, et al. Standards Track [Page 16]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+ This registry has been extended for new Class Number (Class-Num) and
+ Class Type (C-type) for RSVP REVERSE_LSP Object requested in the
+ 11bbbbbb range defined in this document as follows:
+
+ Class Number Class Name Reference
+ 203 REVERSE_LSP Section 4.4
+
+ o REVERSE_LSP : Class Type or C-type = 1
+
+6.3. Reverse LSP Failure PathErr Sub-code
+
+ IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
+ registry (see <http://www.iana.org/assignments/rsvp-parameters>).
+ The "Error Codes and Globally-Defined Error Value Sub-Codes"
+ subregistry is included in this registry.
+
+ This registry has been extended for the new PathErr Sub-code defined
+ in this document as follows:
+
+ Error Code = 01: "Admission Control Failure" (see [RFC2205])
+
+ o "Reverse LSP Failure" (6)
+
+
+7. Security Considerations
+
+ This document introduces two new Association Types for the (Extended)
+ ASSOCIATION Object, Double-Sided Associated Bidirectional LSP and
+ Single-Sided Associated Bidirectional LSP. These types, by
+ themselves, introduce no additional information to signaling.
+ Related security considerations are already covered for this in RFC
+ 6780.
+
+ The REVERSE_LSP Object is carried in the Path message of a forward
+ LSP of the single-sided associated bidirectional LSP. It can carry
+ parameters for the reverse LSP. This does allow for additional
+ information to be conveyed, but this information is not fundamentally
+ different from the information that is already carried in a
+ bidirectional LSP message. The processing of such messages is
+ already subject to local policy as well as security considerations
+ discussions. For a general discussion on MPLS- and GMPLS-related
+ security issues, see the MPLS/GMPLS security framework [RFC5920].
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 17]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+ Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+ Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
+ September 1997, <http://www.rfc-editor.org/info/rfc2205>.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+ <http://www.rfc-editor.org/info/rfc3209>.
+
+ [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation Protocol-
+ Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+ DOI 10.17487/RFC3473, January 2003,
+ <http://www.rfc-editor.org/info/rfc3473>.
+
+ [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
+ Ed., "RSVP-TE Extensions in Support of End-to-End
+ Generalized Multi-Protocol Label Switching (GMPLS)
+ Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
+ <http://www.rfc-editor.org/info/rfc4872>.
+
+ [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
+ "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
+ May 2007, <http://www.rfc-editor.org/info/rfc4873>.
+
+ [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+ Used to Form Encoding Rules in Various Routing Protocol
+ Specifications", RFC 5511, DOI 10.17487/RFC5511, April
+ 2009, <http://www.rfc-editor.org/info/rfc5511>.
+
+ [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
+ ASSOCIATION Object Extensions", RFC 6780,
+ DOI 10.17487/RFC6780, October 2012,
+ <http://www.rfc-editor.org/info/rfc6780>.
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 18]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+8.2. Informative References
+
+ [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture", RFC 4655,
+ DOI 10.17487/RFC4655, August 2006,
+ <http://www.rfc-editor.org/info/rfc4655>.
+
+ [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
+ Ayyangarps, "Encoding of Attributes for MPLS LSP
+ Establishment Using Resource Reservation Protocol Traffic
+ Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
+ February 2009, <http://www.rfc-editor.org/info/rfc5420>.
+
+ [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+ Sprecher, N., and S. Ueno, "Requirements of an MPLS
+ Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
+ September 2009, <http://www.rfc-editor.org/info/rfc5654>.
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+ <http://www.rfc-editor.org/info/rfc5920>.
+
+ [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+ Profile (MPLS-TP) Identifiers", RFC 6370,
+ DOI 10.17487/RFC6370, September 2011,
+ <http://www.rfc-editor.org/info/rfc6370>.
+
+ [RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar,
+ N., Ed., and E. Gray, Ed., "MPLS Transport Profile
+ (MPLS-TP) Control Plane Framework", RFC 6373,
+ DOI 10.17487/RFC6373, September 2011,
+ <http://www.rfc-editor.org/info/rfc6373>.
+
+ [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
+ Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
+ Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387,
+ September 2011, <http://www.rfc-editor.org/info/rfc6387>.
+
+ [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object",
+ RFC 6689, DOI 10.17487/RFC6689, July 2012,
+ <http://www.rfc-editor.org/info/rfc6689>.
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 19]
+
+RFC 7551 RSVP-TE Extensions for Associated LSP May 2015
+
+
+Acknowledgements
+
+ The authors would like to thank Lou Berger and George Swallow for
+ their great guidance in this work; Jie Dong for the discussion of the
+ recovery LSP; Lamberto Sterling for his valuable comments about
+ asymmetric bandwidth signaling; Attila Takacs for the discussion of
+ the provisioning model; Siva Sivabalan, Eric Osborne, and Robert
+ Sawaya for the discussions on the ASSOCIATION Object; and Matt
+ Hartley for providing useful suggestions on the document. At the
+ same time, the authors would like to acknowledge the contributions of
+ Bo Wu, Xihua Fu, and Lizhong Jin for the initial discussions; Wenjuan
+ He for the prototype implementation; and Lou Berger, Daniel King, and
+ Deborah Brungard for the review of the document.
+
+Contributors
+
+ Fan Yang
+ ZTE
+
+ EMail: yang.fan240347@gmail.com
+
+
+ Weilian Jiang
+ ZTE
+
+ EMail: jiang.weilian@gmail.com
+
+Authors' Addresses
+
+ Fei Zhang (editor)
+ Huawei
+
+ EMail: zhangfei7@huawei.com
+
+
+ Ruiquan Jing
+ China Telecom
+
+ EMail: jingrq@ctbri.com.cn
+
+
+ Rakesh Gandhi (editor)
+ Cisco Systems
+
+ EMail: rgandhi@cisco.com
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 20]
+