MPLS Working Group F. Zhang
Internet-Draft F. Yang
Intended status: Standards Track L. Jin
Expires: September 2, 2010 W. Jiang
ZTE Corporation
March 1, 2010
RSVP-TE Extentions to Realize Dynamic Binding of Associated
Bidirectional LSP
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-00
Abstract
This document provides a method to realize dynamic binding control of
associated bidirectional LSP, by extending the ASSOCIATION object
defined in RFC 4872 and RFC 4873.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2010.
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
Zhang, et al. Expires September 2, 2010 [Page 1]
Internet-Draft RSVP-TE Extentions of Associated LSP March 2010
(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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Extension to the ASSOCIATION object. . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Master/slave mode . . . . . . . . . . . . . . . . . . . . . 6
4.2. Peer mode . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Acknowledgement of the binding . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative references . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Zhang, et al. Expires September 2, 2010 [Page 2]
Internet-Draft RSVP-TE Extentions of Associated LSP March 2010
1. Introduction
According to [RFC5654], the MPLS-TP's control plane MUST support
establishing associated bidirectional P2P LSP. Furthermore, this
requirement is elaborated as follows, and repeated in
[tp-cp-framework]:
10 All nodes on the path of a co-routed bidirectional transport path
in the same (sub)layer as the path MUST be aware of the pairing
relationship of the forward and the backward directions of the
transport path.
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.
Although the co-routed bidirectional LSP always exists in transport
networks, but the forward and backward paths are signalled/routed
independently in IP/MPLS networks. In this situation, the
association is useful for protection switching, for OAM that requires
a reply (from MIP or MEP), and for defect correlation.
The ASSOCIATION object, as defined in [RFC4872] and [RFC4873]
respectively, is used to provide end-to-end and segment recovery.
This document extends the ASSOCIATION object to realize dynamic
binding control of associated bidirectional LSP.
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. Extension to the ASSOCIATION object.
The ASSOCIATION object is used to associate LSPs with each other.
The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with
value = 199, C-Type = 1) has the format:
Zhang, et al. Expires September 2, 2010 [Page 3]
Internet-Draft RSVP-TE Extentions of Associated LSP March 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 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 ASSOCIATION object
The IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with
value = 199, C-Type = 2) 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 (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 ASSOCIATION object
Now, the following values of the Association Type have been defined.
Value Type
----- ----
0 Reserved
1 Recovery (R)
2 Resource sharing
In order to bind two reverse unidirectional LSPs to be an associated
bidirectional LSP, this document defined two new values:
Zhang, et al. Expires September 2, 2010 [Page 4]
Internet-Draft RSVP-TE Extentions of Associated LSP March 2010
Value Type
----- ----
3 Association (master/slave mode)
4 Association (peer mode)
Just likes the other two types, these newly defined Association Types
are only carried in PATH messages also, such identification only
takes place based on PATH state.
An ASSOCIATION object with an Association Type set to the value
"Association" is used to bind two reverse unidirectional LSP to be an
associated bidirectional LSP. Any node originating a LSP need to be
bound MUST insert an ASSOCIATION object with the following setting:
The Association Type MUST be set to the value "Association" in the
Path message of the LSP.
The Association ID MUST be set to be set to a value that uniquely
identifies the association of LSPs, this SHOULD be set to the Tunnel
ID of the bound LSP (master/slave mode) or the Tunnel ID of the
binding LSP (peer mode).
The (IPv4/IPv6) Association Source SHOULD be set to the Tunnel Sender
Address of the bound LSP (master/slave mode) or the Tunnel Sender
Address of the binding LSP (peer mode), MAY be set to the Tunnel End
Point Address.
Terminating (the same transit) nodes MUST (SHOULD) use received
ASSOCIATION object(s) with the Association Type set to the value
"Association" to bind the two reverse unidirectional LSPs together.
Once included, an ASSOCIATION object with an Association Type
"Association" SHOULD NOT be removed from the PATH messages associated
with an LSP.
Any node processing a PATH message which contains an ASSOCIATION
object with an Association type, examines existing LSPs for matching
Association Type, Association Source, and Association ID values. If
any match is found, then dynamic binding of the two reverse LSPs
SHOULD be provided.
4. Operation
Consider the following example:
Zhang, et al. Expires September 2, 2010 [Page 5]
Internet-Draft RSVP-TE Extentions of Associated LSP March 2010
A-------D-------B
\ /
\ /
\ /
C
Figure 3: An Example of Associated Bidirectional LSP
Two reverse unidirectional LSPs are 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].
4.1. Master/slave mode
In this mode, the ingress node sends the PATH message, inserting
ASSOCIATION object; and the egress node sets up a backward LSP
triggered by the ASSOCIATION object. That is to say, the ingress
node can actively setup the forward LSP and trigger the egress node
to setup backward LSP.
The procedure can be as follows::
(1) Node A sends PATH message of LSP1, inserting the ASSOCIATION
object. Association Type is set to Association, Association ID is
the Tunnel ID of LSP1, and Association Source is the Tunnel Sender
Address, for example, the IP address of Node A.
(2) When node D receives the PATH message of LSP1, it needs to check
ASSOCIATION object. If it does not know this Association Type, just
ignore it and forward it to the next node. Of course, Node D can
send PathErr Message indicating that it does not know this
Association Type, but this would increase the failed possibility of
establishing LSP1. If the Association Type is Association, it
indicates that Node D should bind one backward LSP with LSP1 to form
an associated bidirectional LSP if it is the same node of these two
LSPs.
(3)Similarly with node D, when node B receives the PATH message of
LSP1, it needs to check ASSOCIATION object also. For node B is the
end point of LSP1 with master/slave mode, and it SHOULD be triggered
to set up the backward LSP2 to bind it with LSP1. So it sends PATH
message of LSP2, inserting the ASSOCIATION object, which has the same
value as it is in the PATH message of LSP1. In other words,
Association Type is Association, Association ID is Tunnel ID1,
Association Source is the IP address of node A.
(4) When node D receives the PATH message of LSP2, it checks
Zhang, et al. Expires September 2, 2010 [Page 6]
Internet-Draft RSVP-TE Extentions of Associated LSP March 2010
ASSOCIATION object and finds that it needs to bind LSP2 with another
LSP, examining existing LSPs for matching Association Type,
Association ID and Association Source. Obviously, LSP1 and LSP2
match with each other, so they will be bound together.
(5) For node C, because it is not the same middle node of LSP1 and
LSP2, so it can not find matched LSPs, but this does not affect the
setting up of the two reverse unidirectional LSPs.
(6)Node A behaves the same with node D, except that it is the end
point of LSP2.
4.2. Peer mode
In this mode, the ingress node sends the PATH message, inserting
ASSOCIATION object, indicating to bind which backward LSP with the
forward LSP. Then the egress node sets up the corresponding backward
LSP with the Tunnel ID carried in the ASSOCIATION object of the
forward LSP, and there is no need to insert the ASSOCIATION object in
the PATH message of the backward LSP. Ingress/egress and the same
transit node compare the Tunnel ID carried in the ASSOCIATION object
of the forward LSP and the Tunnel ID of the backward LSP, and bind
them together if the two Tunnel IDs are the same.
4.3. Acknowledgement of the binding
In the description above, The Ingress node do not know whether the
binding of the Egress and the same transit nodes are successful or
not. This can be done by putting the ASSOCIATION object in the RESV
refresh message of the bound LSP if the binding is successful.
5. IANA Considerations
Within the current document, a new Association Type is defined.
6. Security Considerations
TBD.
7. Acknowledgement
The author would like to thank Xihua, Fu and Bo, Wu for their useful
discussion.
Zhang, et al. Expires September 2, 2010 [Page 7]
Internet-Draft RSVP-TE Extentions of Associated LSP March 2010
8. References
8.1. Normative references
[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.
8.2. Informative References
[tp-cp-framework]
Loa, Andersson., Lou, Berger., Luyuan, Fang., and Bitar.
Nabil, "MPLS-TP Control Plane Framework", February 2010.
Authors' Addresses
Fei Zhang
ZTE Corporation
4C, RD Building 2, Zijinghua Road
Yuhuatai District, Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: zhang.fei3@zte.com.cn
Fan Yang
ZTE Corporation
3C, RD Building 1, Zijinghua Road
Yuhuatai District, Nanjing 210012
P.R.China
Phone: +86 025 52872302
Email: yang.fan5@zte.com.cn
Zhang, et al. Expires September 2, 2010 [Page 8]
Internet-Draft RSVP-TE Extentions of Associated LSP March 2010
LZ Jin
ZTE Corporation
889, Bibo Road, Zijinghua Road
Pudong District, Shanghai 201203
P.R.China
Phone: +86 021 68896273
Email: lizhong.jin@zte.com.cn
WL jiang
ZTE Corporation
3C, RD Building 1, Zijinghua Road
GYuhuatai District, Nanjing 210012
P.R.China
Phone: +86 025 52877315
Email: jiang.weilian@zte.com.cn
Zhang, et al. Expires September 2, 2010 [Page 9]