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]