MPLS Working Group F. Zhang, Ed.
Internet-Draft F. Yang
Intended status: Standards Track L. Jin
Expires: April 28, 2011 W. Jiang
ZTE Corporation
October 25, 2010
RSVP-TE Extensions to Establish Associated Bidirectional LSP
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-01
Abstract
This document provides a method to bind two unidirectional LSPs into
an associated bidirectional LSP, by extending the Extended
ASSOCIATION object defined in [I-D.berger-ccamp-assoc-info].
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 April 28, 2011.
Copyright Notice
Copyright (c) 2010 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. Expires April 28, 2011 [Page 1]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 4
3. Extensions to the Extended ASSOCIATION object. . . . . . . . . 4
4. Association of Two Reverse Unidirectional LSPs . . . . . . . . 6
4.1. Asymmetric Bandwidth LSPs . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative references . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Zhang, et al. Expires April 28, 2011 [Page 2]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
1. Introduction
The associated bidirectional path, defined in[RFC5654], is
constructed from a pair of unidirectional paths that are associated
with one another at the path's ingress/egress points. The forward
and backward directions are setup, monitored, and protected
independently.
[RFC5654] specifies the requirements about associated bidirectional
paths in requirement 7, 11, 12, 50:
7 MPLS-TP MUST support associated bidirectional point-to-point
transport paths.
11 The end points of an associated bidirectional transport path MUST
be aware of the pairing relationship of the forward and reverse paths
used to support the bidirectional service.
12 Nodes on the path of an associated bidirectional transport path
where both the forward and backward directions transit the same node
in the same (sub)layer as the path SHOULD be aware of the pairing
relationship of the forward and the backward directions of the
transport path.
50 The MPLS-TP control plane MUST support stabling associated
bidirectional P2P path 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 associated bidirectional
LSP is useful for protection switching, for OAM that requires a reply
(from MIP or MEP), and for defect correlation. The binding can
happen when the two unidirectional LSPs are being established or have
been established.
The notion of association as well as the corresponding RSVP
ASSOCIATION object are defined in [RFC4872] and [RFC4873]. In this
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.berger-ccamp-assoc-info]
defines the Extended ASSOCIATION object that can be more generally
applied.
This document extends the Extended ASSOCIATION object to establish
associated bidirectional LSPs
Zhang, et al. Expires April 28, 2011 [Page 3]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
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. Extensions to the Extended ASSOCIATION object.
The Extended ASSOCIATION object is defined in
[I-D.berger-ccamp-assoc-info].
The Extended IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb
with value = 199, C-Type = TBA) has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID (Continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended IPv4 ASSOCIATION object
The Extended IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb
with value = 199, C-Type = TBA) has the format:
Zhang, et al. Expires April 28, 2011 [Page 4]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID (Continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended IPv6 ASSOCIATION object
o Association Type:
Now, the following values of the Association Type have been defined.
Value Type
----- ----
0 Reserved
1 Recovery (R)
2 Resource sharing (S)
In order to bind two reverse unidirectional LSPs to be an associated
bidirectional LSP, this document defined a new value:
Value Type
----- ----
4 Association of two reverse unidirectional LSP (A)
If the midpoints do not know this Association Type, just ignore it
and forward it to the next node, but the egress nodes MUST return a
PathErr message with error code/sub-code "LSP Admission Failure/Bad
Association Type" if they do not know this Association Type.
o Association Source:
The general rule is that the address is "associated to the node that
originate the association" and provide global scope (within the
Zhang, et al. Expires April 28, 2011 [Page 5]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
address sapce) to identified association,see [RFC4872] and
[I-D.berger-ccamp-assoc-info]. This document adds specific rules:
the Association source MUST set to the tunnel sender address of the
initiating node .
o Association ID:
The association ID is set to a value that uniquely identifies the set
of LSPs to be associated and the generic definition does not provide
any specific rules on how matching is to be done. This document adds
specific rules: the first 16 bits MUST set to the tunnel ID of the
initiating node and the following 16 bits MUST set to the LSP ID of
the corresponding tunnel, the rest MUST be set to zero on
transmission and MUST be ignored on receipt.
As described in [I-D.berger-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 initializted association. Thus it
can only appear in Extended ASSOCIATION objects signaled in Path
message.
[I-D.berger-ccamp-assoc-info] discussed the rules associated with the
processing of the Extended ASSOCIATION objects in RSVP message. 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 be operation based on the same Extended
ASSOCIATION objects.
4. Association of Two Reverse Unidirectional LSPs
Consider the following example:
A-------D-------B
\ /
\ /
\ /
C
Figure 3: An example of associated bidirectional LSP
Zhang, et al. Expires April 28, 2011 [Page 6]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
Two reverse unidirectional LSPs are being established or have been
established, the forward LSP1 is from A to B over [A,D,B], and the
associated backward LSP2 is from B to A over [B,D,C,A].
Just like the end-to-end recovery LSP association
[I-D.berger-ccamp-assoc-info], the following combination may occur
when binding LSP1 and LSP2 together to be an associated bidirectional
LSP
Case 1. The Extended ASSOCIATION object of LSP1 is initialized
before the Extended ASSOCIATION objects of LSP2, The Extended
ASSOCIATION object of LSP1 and LSP2 will carry the same value and
this value should be LSP1'tunnel ID, LSP ID and tunnel sender
address.
Case 2. The Extended ASSOCIATION object of LSP2 is initialized
before the Extended ASSOCIATION objects of LSP1, The Extended
ASSOCIATION object of LSP1 and LSP2 will carry the same value and
this value should be LSP2'tunnel ID, LSP ID and tunnel sender
address.
Case 3. The Extended ASSOCIATION object of both the LSPs are
concurrently initialized, the values of the Extended ASSOCIATION
object carried in LSP1's Path message are LSP1's tunnel ID, LSP ID
and tunnel sender address; the values of the Extended ASSOCIATION
object carried in LSP2's Path message are LSP1's tunnel ID, LSP ID
and tunnel sender address. According to the general rules defined in
[I-D.berger-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 router ID, then the bigger one sends Path refresh message,
carrying the Extended ASSOCIATION object of the reverse LSP. Based
on this Path refresh message, the two LSPs can be bounded together to
be an associated bidirectional LSP also.
4.1. Asymmetric Bandwidth LSPs
There are some kind of services which have different bandwidth
requirements for each direction, and associated bidirectional LSPs
SHOULD support them. [RFC5467] defined three new objects named
UPSTREAM_FLOWSPEC object, UPSTREAM_TSPEC object and UPSTREAM_ADSPEC
object, which refer to the upstream traffic flow. In this document,
UPSTREAM_TSPEC MUST be carried in the initializing LSP's Path message
to trigger the egress node to setup the reverse LSP with
corresponding asymmetric bandwidth. If the midpoints do not know
this object, just ignore it and forward it to the next node, but the
egress nodes MUST return a PathErr message with error code/sub-code
"Admission Control failure/Unknown object" if they do not know this
Zhang, et al. Expires April 28, 2011 [Page 7]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
object.
5. IANA Considerations
Within the current document, a new Association Type is defined in
Extended ASSOCIATION object.
Value Type
----- ----
4 Association of two reverse unidirectional LSPs (A)
There are no other IANA considerations introduced by this document.
6. Security Considerations
No new security considerations are introduced in this document.
7. Acknowledgement
The author would like to thank Xihua Fu and Bo Wu for their useful
discussion; thank Lou Berger for his suggestion on the organization
of this document; thank Lamberto Sterling for his valuable comments
on the section of asymmetric bandwidths.
8. Normative references
[I-D.berger-ccamp-assoc-info]
Berger, L., Faucheur, F., and A. Narayanan, "Usage of The
RSVP Association Object", draft-berger-ccamp-assoc-info-01
(work in progress), March 2010.
[I-D.ietf-ccamp-mpls-tp-cp-framework]
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-03 (work in
progress), October 2010.
[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
Zhang, et al. Expires April 28, 2011 [Page 8]
Internet-Draft RSVP-TE Extensions of Associated LSP October 2010
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.
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 5467, March 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
Authors' Addresses
Fei Zhang (editor)
ZTE Corporation
Email: zhang.fei3@zte.com.cn
Fan Yang
ZTE Corporation
Email: yang.fan5@zte.com.cn
LZ Jin
ZTE Corporation
Email: lizhong.jin@zte.com.cn
WL jiang
ZTE Corporation
Email: jiang.weilian@zte.com.cn
Zhang, et al. Expires April 28, 2011 [Page 9]