MPLS Working Group F. Zhang, Ed.
Internet-Draft ZTE
Intended status: Standards Track R. Jing
Expires: October 18, 2011 China Telecom
April 16, 2011
RSVP-TE Extensions to Establish Associated Bidirectional LSP
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-00
Abstract
This document provides a method to bind two unidirectional Label
Switched Paths (LSPs) into an associated bidirectional LSP, by
increasing a new Association Type in the context of 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 October 18, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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 & Jing Expires October 18, 2011 [Page 1]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Association of Two Reverse Unidirectional LSPs . . . . . . . . 4
3.1. Provisioning Model . . . . . . . . . . . . . . . . . . . . 4
3.2. Signaling Procedure . . . . . . . . . . . . . . . . . . . 4
3.2.1. Asymmetric Bandwidth LSPs . . . . . . . . . . . . . . 5
3.3. Recovery Considerations . . . . . . . . . . . . . . . . . 6
4. Extensions to the Extended ASSOCIATION object . . . . . . . . 6
5. REVERSE_TSPEC Object . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Association Type . . . . . . . . . . . . . . . . . . . . . 8
6.2. REVERSE_TSPEC Object . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative references . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhang & Jing Expires October 18, 2011 [Page 2]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
1. Introduction
The associated bidirectional LSP, defined in the requirements of MPLS
Transport Profile (MPLS-TP) [RFC5654], is constructed from a pair of
unidirectional LSPs that are associated with each other at the LSP's
ingress/egress points. It is useful for protection switching, for
Operations, Administrations and Maintenance (OAM) messages that
require a reply path. The corresponding requirements are also
specified in as follow:
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.
Furthermore, these requirements are repeated in
[I-D.ietf-ccamp-mpls-tp-cp-framework].
The notion of association as well as the corresponding Resource
reSerVation Protocol (RSVP) ASSOCIATION object is defined in
[RFC4872] and [RFC4873]. 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-info] defines the Extended
ASSOCIATION object that can be more generally applied.
This document defines a new association type to establish associated
bidirectional LSPs in the context of the Extended ASSOCIATION object.
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].
Zhang & Jing Expires October 18, 2011 [Page 3]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
3. Association of Two Reverse Unidirectional LSPs
3.1. Provisioning Model
The associated bidirectional LSP's forward and backward directions
are set up, monitored, and protected independently [RFC5654], so the
configurations about it can be sent to one end or two ends.
Depending on this, there are two models of signaling associated
bidirectional LSP, one is the single sided provisioning and the other
is the double sided provisioning.
For the single sided provisioning, the configurations are sent to one
end.Firstly, a unidirectional 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.
It can happen to bind two reverse unidirectional LSPs to be an
associated bidirectional LSP not only when they are being created,
but also when they have existed; or when one LSP exists, but the
other one needs to be established. To all these scenarios, the
provisioning models discussed above are applicable.
3.2. Signaling Procedure
Consider the topology described in figure 1, LSP1 [A,D,B] (from west
to east) and LSP2 [B,D,C,A] (from east to west) are being established
or have been established, which can be bound together to be an
associated bidirectional LSP. LSP1 is uniquely identified by East-
Global_ID::East-Node_ID::East-LSP_Num; similarly LSP2 is identified
by West-Global_ID::West-Node_ID::West-Tunnel_Num::West-LSP_Num
[I-D.ietf-mpls-tp-identifiers].
A-------D-------B
\ /
\ /
\ /
C
Figure 1: An example of associated bidirectional LSP
Zhang & Jing Expires October 18, 2011 [Page 4]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
For single sided provisioning model, LSP1 is triggered by LSP2 or
LSP2 is triggered by LSP1. When LSP2 is triggered by LSP1, LSP1 is
initialized at node A with the Extended ASSOCIATION object inserted
in the Path message, Association Type is set to "Association of two
reverse unidirectional LSPs", Association ID set to East-LSP_Num,
Association Source set to East-Node_ID, Global Association Source set
to East-Global_ID, and Extended Association ID set to East-
Tunnel_Num. Terminating node B is triggered to set up LSP2 by the
received Extended ASSOCIATION object with the Association Type set to
the value "Association of two reverse unidirectional LSPs", the
Association Object inserted in LSP2's Path message is the same as in
LSP1's Path message. when When LSP1 is triggered by LSP2, the same
rules are applicable.
For double sided provisioning model, LSP1 and LSP2 are concurrently
initialized with the Extended ASSOCIATION object inserted in the
their Path messages, and Association Types are set to "Association of
two reverse unidirectional LSPs". For LSP1, Association ID set to
East-LSP_Num, Association Source set to East-Node_ID, Global
Association Source set to East-Global_ID, and Extended Association ID
set to East-Tunnel_Num; for LSP2, Association ID set to West-LSP_Num,
Association Source set to West-Node_ID, Global Association Source set
to West-Global_ID, and Extended Association ID set to West-
Tunnel_Num. According to the general rules defined in
[I-D.ietf-ccamp-assoc-info], the two LSPs cannot be bound together to
be an associated bidirectional LSP because of the different values.
In this case, the two edge nodes should firstly compare their Global-
Node_ID, then the bigger one sends Path refresh message, replacing
the old Extended ASSOCIATION object with the new Extended ASSOCIATION
object carried in the reverse LSP. Based on this Path refresh
message, the two LSPs can be bounded together to be an associated
bidirectional LSP also.
3.2.1. Asymmetric Bandwidth LSPs
There are some kind of applications, such as internet services and
the return paths of OAM messages, which MAY have different bandwidth
requirements for each direction. [RFC5654] specifies the
requirements as follow:
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
[I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis], which introduces three new
objects named UPSTREAM_FLOWSPEC object, UPSTREAM_TSPEC object and
Zhang & Jing Expires October 18, 2011 [Page 5]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
UPSTREAM_ADSPEC object to represent the asymmetric upstream traffic
flow. For the asymmetric bandwidth associated bidirectional LSPs,
the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC are complemented with
the addition of new REVERSE_TSPEC object, which is used in exactly
the same fashion as the old SENDER_TSPEC object, but refers to set up
the reverse unidirectional LSP.
In the context of asymmetric associated bidirectional LSP, the
REVERSE_TSPEC object MUST be carried in the LSP's Path message
together with the Extended ASSOCIATION object whose Association Type
is "Association of two reverse unidirectional LSPs" to trigger the
peer end to set up the reverse LSP with the corresponding asymmetric
bandwidth. For the single sided provisioning, the peer end just
copies the value of the REVERSE_TSPEC object into the SENDER_TSPEC
object in the Path message. For the double sided provisioning, the
ends need to compare the values of the SENDER_TSPEC and REVERSE_TSPEC
objects in the two Path messages. If match, the end with the bigger
Global-Node_ID sends Path refresh message, carrying the Extended
ASSOCIATION object of the reverse LSP.
Nodes not supporting this extension will not recognize the new class
number and should respond with an "Unknown Object Class".
3.3. Recovery Considerations
Assume that LSP3 is used to protect LSP1, which can be established
before or after the failure occurs, can share the same TE tunnel with
LSP1 or not. LSP3 SHOULD inherits the associated bidirectional
attributes between LSP1 and LSP2 when the traffic is switched from
LSP1 to LSP3. This can be done by inserting the Extended ASSOCIATION
object in LSP3's Path message with the same value as in LSP1's Path
message.
4. Extensions to the Extended ASSOCIATION object
The Extended ASSOCIATION object is defined in
[I-D.ietf-ccamp-assoc-info], which enables MPLS-TP required
identification.
o Association Type:
In order to bind two reverse unidirectional LSPs to be an associated
bidirectional LSP, this document defines a new Association Type:
Value Type
----- ----
Zhang & Jing Expires October 18, 2011 [Page 6]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
TBD Association of two reverse unidirectional LSPs (A)
If the downstream nodes do not know this Association Type, MUST
return a PathErr message with error code/sub-code "LSP Admission
Failure/Bad Association Type".
Under the context of this Association Type, any node associating an
associated bidirectional LSP MUST insert an ASSOCIATION object with
the following setting:
o Association ID:
The Association ID MUST be set to its own signaled LSP ID (default);
if known, it MAY be set to the LSP ID of the associated reverse LSP.
o Association Source:
The Association source MUST be set to the tunnel sender address of
this LSP (default); if known, it May be set to the tunnel sender
address of the peer node.
o Global Association Source:
The format is described in [I-D.ietf-ccamp-assoc-info].
o Extended Association ID:
Because the two LSPs (one is from west to east, and the other is from
east to west) are in different tunnels, the Association ID is
insufficient to uniquely identify association for associated
bidirectional LSP. Hence, this document adds specific rules: the
first 16-bits MUST be set to its own tunnel ID (default); if known,
it May be set to the tunnel ID of the the associated reverse tunnel.
As described in [I-D.ietf-ccamp-assoc-info], 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 type in this document is
only defined for use in upstream initialized association. Thus it
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-info].
It said that in the absence of Association Type-specific rules for
Zhang & Jing Expires October 18, 2011 [Page 7]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
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.
5. REVERSE_TSPEC Object
The REVERSE_TSPEC object is used in Path, PathTear, PathErr, and
Notify message (via sender descriptor). This includes the definition
of class type and format. It's class number is TBD (of the form
0bbbbbbb), and class type and format is the same as the SENDER_TSPEC
object.
This object modifies the RSVP message-related formats defined in
[RFC2205], [RFC3209] and [RFC3473]. See [RFC5511] for the syntax
used by RSVP. The format of the sender description for asymmetric
associated bidirectional LSPs is:
<sender descriptor>::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[<ADSPEC>]
[<RCEORD_ROUTE>]
[<SUGGESTED_LABEL>]
[<RECOVERY_LABEL>]
<REVERSE_TSPEC>
6. IANA Considerations
IANA is requested to administer assignment of new values for
namespace defined in this document and summarized in this section.
6.1. Association Type
Within the current document, a new Association Type is defined in the
Extended ASSOCIATION object.
Value Type
----- ----
TBD Association of two reverse unidirectional LSPs (A)
Zhang & Jing Expires October 18, 2011 [Page 8]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
6.2. REVERSE_TSPEC Object
A new class named REVERSE_TSPEC has been created in the 0bbbbbbb rang
(TBD) with the following definition:
Class Types or C-types:
Same values as SENDER_TPSCE object (C-Num 12)
There are no other IANA considerations introduced by this document.
7. Security Considerations
This document introduces a new association type, and except this,
there are no security issues about the Extended ASSOCIATION object
are introduced here.
Furthermore, this document introduces the REVERSE_TSPEC object for
use in GMPLS signaling [RFC3473], which is parallel the existing
SENDER_TSPEC object. As such, any vulnerabilities that are due to
the use of the old SENDER_TSPEC object now apply here also.
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].
8. Acknowledgement
The authors would like to thank Lou Berger for his great guidance in
this work, George Swallow for the discussion of recovery, Lamberto
Sterling for his valuable comments on the section of asymmetric
bandwidths. At the same time, the authors would also like to
acknowledge the contributions of Bo Wu, Xihua Fu, Lizhong Jin for the
initial discussions.
9. References
9.1. Normative references
[I-D.ietf-ccamp-assoc-info]
Berger, L., Faucheur, F., and A. Narayanan, "Usage of The
RSVP Association Object", draft-ietf-ccamp-assoc-info-01
(work in progress), March 2011.
[I-D.ietf-ccamp-mpls-tp-cp-framework]
Zhang & Jing Expires October 18, 2011 [Page 9]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
Andersson, L., Berger, L., Fang, L., Bitar, N., Gray, E.,
Takacs, A., Vigoureux, M., and E. Bellagamba, "MPLS-TP
Control Plane Framework",
draft-ietf-ccamp-mpls-tp-cp-framework-06 (work in
progress), February 2011.
[I-D.ietf-mpls-tp-identifiers]
Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
Identifiers", draft-ietf-mpls-tp-identifiers-04 (work in
progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
9.2. Informative References
[I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis]
Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)",
draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 (work in
progress), January 2011.
[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.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Zhang & Jing Expires October 18, 2011 [Page 10]
Internet-Draft RSVP-TE Extensions of Associated LSP April 2011
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Fei Zhang (editor)
ZTE
Email: zhang.fei3@zte.com.cn
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Zhang & Jing Expires October 18, 2011 [Page 11]
