CCAMP Working Group F. Zhang, Ed.
Internet-Draft ZTE
Intended status: Standards Track R. Jing
Expires: September 7, 2012 China Telecom
March 06, 2012
RSVP-TE Extensions for Associated Bidirectional LSPs
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03
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 7, 2012.
Copyright Notice
Copyright (c) 2012 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
Zhang & Jing Expires September 7, 2012 [Page 1]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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 . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . 6
3.2.4. Recovery Considerations . . . . . . . . . . . . . . . 6
3.2.5. Teardown of associated bidirectional LSPs . . . . . . 7
4. Association of LSPs . . . . . . . . . . . . . . . . . . . . . 7
4.1. Association Types . . . . . . . . . . . . . . . . . . . . 7
4.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1.1. Subobjects . . . . . . . . . . . . . . . . . . . . 9
4.2.2. LSP Control . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Updated RSVP Message Formats . . . . . . . . . . . . . 9
4.2.4. Compatibility . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. Association Type . . . . . . . . . . . . . . . . . . . . . 10
5.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative references . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Zhang & Jing Expires September 7, 2012 [Page 2]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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 [I-D.ietf-ccamp-assoc-info] . 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 [I-D.ietf-ccamp-assoc-ext]
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.
Zhang & Jing Expires September 7, 2012 [Page 3]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
2. 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].
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.
Zhang & Jing Expires September 7, 2012 [Page 4]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
LSP1 and LSP2 are referenced at the data plane level by the
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, Association
Type is set to "Single Sided Associated Bidirectional LSPs",
Association ID set to a value that uniquely identifies the sessions
to be associated within the context of the Association Source field
(like A-Tunnel_Num), Association Source set to A-Node_ID, Global
Association Source set to A-Global_ID. The Extended Association ID
field must be included when the Association ID field is insufficient
to uniquely identify association. As described in
[I-D.ietf-ccamp-assoc-ext], when included, this field must be set to
a value that, together with the other fields in the object, uniquely
identifies the sessions to be associated. 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 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 Association objects in the two LSPs' Path
message, 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" and the other
values used in the Extended ASSOCIATION object are outside the scope
of this document. For example, they may be communicated via the
management plane. No matter how the values are communicated,
Zhang & Jing Expires September 7, 2012 [Page 5]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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
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 descirbed 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 simultanously.
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 or not.
When node A detects that LSP1 is broken, LSP3 will be initialized or
refreshed with the Extended ASSOCIATION object inherited from LSP1's
Path message. In this way, based on the same Extended ASSOCIATION
object, LSP2 and LSP3 will compose the new associated bidirectional
LSPs.
Zhang & Jing Expires September 7, 2012 [Page 6]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
3.2.5. 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).
4. Association of LSPs
4.1. Association Types
The Extended ASSOCIATION object is defined in
[I-D.ietf-ccamp-assoc-ext], which enables MPLS-TP required
identification. In order to bind two reverse unidirectional LSPs to
be an associated bidirectional LSP, the new Association Types are
defined in this document:
o Association Types:
Value Type
----- -----
4 (TBD) Doubled Sided Associated Bidirectional LSPs (D)
5 (TBD) Single Sided Associated Bidirectional LSPs (A)
See [I-D.ietf-ccamp-assoc-ext] for the definition of other fields and
values.
As described in [I-D.ietf-ccamp-assoc-ext], association is always
done based on matching Path state or Resv state. Upstream
initializted association is represented in Extended ASSOCIATION
objects carried in Path message and downstream initializted
association is represented in Extended ASSOCIATION objects carried in
Resv messages. The new defined Association Types here are only used
Zhang & Jing Expires September 7, 2012 [Page 7]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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 [I-D.ietf-ccamp-assoc-ext].
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
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 "Associated
Bidirectional LSPs".
Zhang & Jing Expires September 7, 2012 [Page 8]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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 "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> ]
[ [<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>
Zhang & Jing Expires September 7, 2012 [Page 9]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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)
5.2. REVERSE_LSP Object
A new class named REVERSE_LSP has been created in the 11bbbbbb rang
(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.
Zhang & Jing Expires September 7, 2012 [Page 10]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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.
8. References
8.1. Normative references
[I-D.ietf-ccamp-assoc-ext]
Berger, L., Faucheur, F., and A. Narayanan, "RSVP
Association Object Extensions",
draft-ietf-ccamp-assoc-ext-02 (work in progress),
February 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
Zhang & Jing Expires September 7, 2012 [Page 11]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[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.
8.2. Informative References
[I-D.ietf-ccamp-assoc-info]
Berger, L., "Usage of The RSVP Association Object",
draft-ietf-ccamp-assoc-info-03 (work in progress),
October 2011.
[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.
Authors' Addresses
Fei Zhang (editor)
ZTE
Email: zhang.fei3@zte.com.cn
Zhang & Jing Expires September 7, 2012 [Page 12]
Internet-Draft RSVP-TE Extensions for Associated LSPs March 2012
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
Zhang & Jing Expires September 7, 2012 [Page 13]