MPLS Working Group Y. Ji
Internet Draft Y. Lu
Intended status: Standards Track Z. Du
Expires: September 2010 BUPT University
March 4, 2010
Bidirectional Label Assignment in MPLS-TP
draft-ji-mpls-tp-bidirectional-label-00
Abstract
This document describes a new mechanism for the label allocation of
co-routed bidirectional point-to-point paths in MPLS Transport
Profile (MPLS-TP) networks, which is called the bidirectional label
allocation mechanism. The nodes on co-routed bidirectional point-to-
point paths will not need to record the label pairing relationship of
the forward and the backward directions in this mechanism because the
labels are symmetrical. In addition, the compression of the LIB
becomes possible because of the existing of symmetrical elements.
Requirements Language
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 RFC 2119 [RFC2119].
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
Ji, et al. Expires September 4, 2010 [Page 1]
Internet-Draft mpls-tp-bidirectional-label March 2010
This Internet-Draft will expire on September 4, 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
(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.
Table of Contents
1. Introduction...................................................2
2. Bidirectional Label Allocation Mechanism.......................3
3. Label Crash....................................................5
4. Applicability..................................................5
5. Security Considerations........................................5
6. IANA Considerations............................................6
7. References.....................................................6
7.1. Normative References......................................6
7.2. Informative References....................................6
8. Acknowledgments................................................6
1. Introduction
This document describes a new mechanism for the label allocation of
co-routed bidirectional point-to-point paths in MPLS Transport
Profile (MPLS-TP) networks.
It is required that 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 in 2.1 General Requirements 10 of
RFC 5654 [RFC5654]. This requires that each node records the pairing
relationship, and thus needs to take up additional memories.
This document uses a bidirectional label allocation mechanism to
solve the problem. In this mechanism, labels of the forward and the
backward directions are set to be symmetrical to each other and thus
get the pairing relationship by nature.
Ji, et al. Expires September 4, 2010 [Page 2]
Internet-Draft mpls-tp-bidirectional-label March 2010
2. Bidirectional Label Allocation Mechanism
The mechanism described in this document is based on RSVP-TE defined
in RFC 3209 [RFC3209] and RSVP-TE extensions defined in RFC 3471 and
RFC 3473 [RFC3471] [RFC3473].
A simple method for the co-routed bidirectional point-to-point path
establishment is to set up two unidirectional paths independently
according to the mechanism in RFC 3209.
An Upstream Label is introduced for the bidirectional LSP setup
mechanism in RFC 3471. The downstream and upstream paths are built
together using a single set of signaling messages in the mechanism.
The mechanism reduces the setup latency to essentially one initiator-
terminator round trip time plus processing time, and limits the
control overhead to the same number of messages as an unidirectional
LSP.
The new mechanism in this document also only needs one round time by
the using of the similar method described in RFC 3471. However, the
label assignments in the downstream and upstream paths in the new
mechanism are in the same time, and the labels for the two paths are
symmetrical as described in Figure 1. The traditional method will
assign the downstream and upstream label independently.
Ji, et al. Expires September 4, 2010 [Page 3]
Internet-Draft mpls-tp-bidirectional-label March 2010
|<----------------- LSP ----------------->|
| |
V V
Initiator Terminator
+-----+ +-----+ +-----+ +-----+ +-----+
| LSR |-----| LSR |-----| LSR |-----| LSR |-----| LSR |
+-----+ +-----+ +-----+ +-----+ +-----+
(a) Traditional Method, Independent LSP Labels Example
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| |19|---->|19|17|---->|17|38|---->|38|46|---->|46| |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| |44|<----|44|68|<----|68|22|<----|22|32|<----|32| |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
(b) Bidirectional Label Method, Symmetrical LSP Labels Example
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| |32|---->|32|55|---->|55|24|---->|24|17|---->|17| |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| |32|<----|32|55|<----|55|24|<----|24|17|<----|17| |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
Figure 1 Comparing Symmetrical LSP Labels with Independent LSP Labels
In Figure 1, traditional methods build independent LSP labels
separately according to RFC 3209 or at one round according to RFC
3471, and the bidirectional label method builds symmetrical LSP
labels at one round.
The new method builds the backward path LSP label besides building
the forward path LSP label comparing to the method of RFC 3209. The
label carried in Resv message is stored in the Label Information Base
(LIB) as the outgoing label for the forward path and as the incoming
label for the backward path.
The Upstream Label need not be used in the new mechanism because only
one label from the downstream node is required for LSPs of both
directions.
The new mechanism requires the label allocation result to be
symmetrical; therefore, there is a certain possibility of the label
provided by the downstream node is occupied in the upstream node when
it is using the per platform label space. Using this type of label
space means that platform-wide incoming labels are used for
interfaces that can share the same labels [RFC5036].
Ji, et al. Expires September 4, 2010 [Page 4]
Internet-Draft mpls-tp-bidirectional-label March 2010
3. Label Crash
If the label crash in an upstream node does happen, the node will
generate a PathErr/NOTIFICATION message with an "Unacceptable label
value" indication for the downstream node. The downstream node that
provided the unsuitable label is required to resend another label
chosen at random from the available label space. If the new label
received at the second time also causes a label crash, the upstream
node will send the message described above again until receiving an
acceptable label. The loop time could be restricted to a certain
number to avoid the infinite loop.
An Acceptable Label Set object described in RFC 3471 could be
included in the PathErr/NOTIFICATION message to indicate which labels
would be acceptable. It is useful for the node to receive an
acceptable label.
In fact, this situation does not happen normally unless the number of
the available labels is limited to a small amount. The number of the
available labels is very large in MPLS [RFC3032]. The probability of
the label crash is very low in a certain network layer if every label
is chosen at random. Therefore, our new method does not cause too
much trouble for the label assignment and is acceptable for the MPLS-
TP network.
4. Applicability
The mechanism of this document can be used in the point-to-point co-
routed bidirectional path of the MPLS-TP network if all LSRs support
this mechanism.
This mechanism can be used in a network where different kinds of
paths coexist because it is only a new label assignment method and
does not conflict with the fundamental forwarding functions of MPLS.
The mechanism of this document could also be used in the GMPLS
networks by the using of the mechanism described in RFC 3471, such as
Label Set object.
5. Security Considerations
Security considerations discussed in RFC 3209, RFC 3471, and RFC 3473
apply to this document.
Ji, et al. Expires September 4, 2010 [Page 5]
Internet-Draft mpls-tp-bidirectional-label March 2010
6. IANA Considerations
This document requires defining an LSR initialization parameter to
indicate if this mechanism is supported.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[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.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
7.2. Informative References
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
8. Acknowledgments
The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.
This document was prepared using 2-Word-v2.0.template.dot.
Ji, et al. Expires September 4, 2010 [Page 6]
Internet-Draft mpls-tp-bidirectional-label March 2010
Authors' Addresses
Yuefeng Ji
Beijing University of Posts and Telecommunications
P.O. Box 128, No.10, Xi Tu Cheng Road, Beijing 100876, China
Email: jyf@bupt.edu.cn
Yueming Lu
Beijing University of Posts and Telecommunications
P.O. Box 90, No.10, Xi Tu Cheng Road, Beijing 100876, China
Email: ymlu@bupt.edu.cn
Zongpeng Du
Beijing University of Posts and Telecommunications
Email: duzongpeng@gmail.com
Ji, et al. Expires September 4, 2010 [Page 7]