MPLS Working Group Y. Huang Internet-Draft Y. Jiang Intended Status: Standards Track Huawei Technologies Expires: April 2011 October 19, 2010 Signaling extension for MPLS ring protection draft-huang-mpls-ring-signaling-extension-00.txt 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 April 19, 2011. Abstract When using Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSP) on a ring topology, it is needed to minimize the labels for protection purpose and minimize the configuration effort. Though MPLS Fast Re-Route [MPLS-FRR] can achieve automatic LSP service protection, it is not optimized as many labels are used to create lots of detour LSPs. This document describes a MPLS ring mechanism and some extensions on signaling protocol to facilitate the establishment of Label Switched Paths (LSPs) using Label Distribution Protocol [LDP] or RSVP-TE protocol [RSVP-TE] to achieve automated link and node protection. Huang & Expires April 19, 2011 [Page 1] Internet-Draft MPLS Signaling extension for ring protection October 2010 Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Ring Protection Scheme.........................................3 3.1. P-to-p LSP example........................................4 3.1.1. Link Failure example.................................4 3.1.2. Node Failure example.................................6 3.2. p-t-mp LSP example........................................7 3.2.1. Link Failure example.................................7 3.2.2. Node Failure example.................................7 3.3. OAM Consideration.........................................7 4. Signaling extension............................................7 4.1. LDP extension.............................................7 4.2. RSVP-TE extension.........................................8 5. Security Considerations........................................8 6. IANA Considerations............................................8 7. Conclusions....................................................8 8. References.....................................................8 8.1. Normative References......................................8 8.2. Informative References....................................8 9. Acknowledgments................................................9 1. Introduction More and more network operators have considered using unified IP/MPLS technology in a single network infrastructure to provide multi- service, including fixed and mobile services. Since a large amount of access and aggregation network segments are fiber ring topology network, it is expected to use MPLS on a ring topology network. The industry is interested to find a lightweight planning, easy provision and little resource consumption for a MPLS ring solution. MPLS Fast Re-Route [MPLS-FRR] is a good technology to automatically create protection LSP and minimize the network provision work, but it is not optimized since it uses many labels and creates lots of detour LSPs, especially in ring topology. This document describes a simple MPLS ring mechanism under which numerous LSP service can be created automatically across the ring with some extensions on signaling protocol. The extensions on signaling solves label switch disruption because of node failure. Section 3 describes the ring protection scheme based on wrapping Huang & Jiang Expires April 19, 2011 [Page 2] Internet-Draft MPLS Signaling extension for ring protection October 2010 mechanism. Section 4 describes the signaling extensions for both LDP and RSVP-TE. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. CW Clock Wise CCW Counter Clock Wise 3. Ring Protection Scheme Several Internet Drafts on MPLS Ring said that both Steering mode and Wrapping mode can be used in a ring network. The scheme in this document only discusses wrapping mechanism. The idea is that steering method takes no advantage of ring topology and can just be achieved by known technology, such as MPLS TE FRR or PW redundancy. It is not indented to compare the two methods and to say which one is better than the other in this document and it should only be up to the operator's choices. In general, the scheme includes several technical points as following. 1. For data transport layer on the ring, for each upstream /downstream direction, assigning CW as working path direction and CCW as protection path direction or vice versa. (The following examples in this document take CW as working direction on the ring). On working ring direction (CW), the transport outermostlabel is service LSP label. That is to say, no PSME label be added to service LSP packet at ring working direction. 2. Pre-provision a closed protection LSP on ring protection direction. The ring protection LSP is to protect all service LSPs when a link or node failure occurs. 3. Control layer, service LSPs crossing the ring can be created normally by LSP signaling with the extension provided in section 4. The extension is to send label switch information to downstream ring node or backup node. Huang & Jiang Expires April 19, 2011 [Page 3] Internet-Draft MPLS Signaling extension for ring protection October 2010 4. Normally, service LSP packet is forwarded along working direction, each ring node performs the normal MPLS forwarding at service LSP label level. 5. When a link or node failure occurs, upstream node adjacent to the failure performs wrapping and pushes a protection ring label to the service LSP packet, and the packet is wrapped around in the protection ring direction and goes to downstream node adjacent to the failure. 6. For a link failure, the downstream node adjacent to the failure is its immediate downstream node, it just pops the protection label and forwards the packet to the working direction. 7. For a node failure, the downstream node adjacent to the failure is one hop away from the upstream node adjacent to the failure performs the wrapping operation. Then the downstream node adjacent to the failure can do the label switching work by receiving the label switching information from the failure node during the setup of the service LSP. How to notify the LSP information will be defined in section 4. 8. To protect failure of ingress or egress node of a ring, a backup node can be assigned during provisioning. The signaling extensions defined in section 4 also provide the ability to notify the backup node the label switching information. Following sections provide some examples in details. 3.1. P-to-p LSP example 3.1.1. Link Failure example A LSP (LSP 1 in figure 1) crosses ring nodes A->B->C->D with labels: . . . [L1]->[L2]->[L3]->[L4]->[L5]-> . . . A protection LSP is denoted as: [p1]->[p2]->[p3]->[p4]->[p5]->[p6]- >[p1]. Here we give some symbol illustration for the label stack 1. The label stack will be enclosed in square brackets ("[]") 2. Each level in the stack will be separated by the '|' character 3. The bottom of the stack will be denoted by the string "B" for two or more label layer. Huang & Jiang Expires April 19, 2011 [Page 4] Internet-Draft MPLS Signaling extension for ring protection October 2010 +---+ [P1] +---+ | F |-------------| A | <- LSP 1 [L1] +---+ +---+ / \ [P2]/ [L2]\[P6] / \ +---+ +---+ | E | | B | +---+ +---+ \ / [P3]\ [L3]/[P5] \ / +---+ [L4] +---+ LSP 1[L5]<-- | D |-------------| C | +---+ [P4] +---+ Figure 1: Labels allocation example for p-t-p LSP protection +---+ +---+ | F |-----------| A | <---LSP 1 +---+ ##########+---+ / # [P1|L3|B] # \ * / # # \ * [L2] / #[P2|L3|B] [P6|L3|B] # \ * / # # \ * +---+ +---+ | E | | B | +---+ +---+ \ #[P3|L3|B] / \ # x \ # / \ # [P4|L3|B] / +---+###########+---+ LSP 1<---| D |-----------+ C | +---+***********+---+ [L4] Figure 2: packet flow when link B-C failure For example, the link between B and C goes down as shown in figure 2. The packet forwarding path is denoted by '***' in the working direction and '###' in the protection direction. Huang & Jiang Expires April 19, 2011 [Page 5] Internet-Draft MPLS Signaling extension for ring protection October 2010 The forwarding path is: A-> [l2]-> B ->[P6|L3|B] -> A -> [P1|L3|B] -> F -> [P2|L3|B] -> E -> [P3|L3|B] -> D -> [P4|L3|B] -> C -> [L4] -> D. When node B finds the link to C is failed, it push protection label [P5] to the out going packet with [L3] at egress port to C, thus the label stack is [P5|L3|B], do wrapping and switch [P5|L3|B] to [P6|L3|B], then send out to link B-A. Node A,F,E,D just do Protection label switching and send the packet to C, and C receives the packet with [P4|L3|B]. When node C finds the link to B has failed, at egress port to B, it pops protection label [P5] and extracts [L3], do wrapping and switch [L3] to [L4] based on normal label switching table entry, then send out [L4] to link C-D. 3.1.2. Node Failure example For example, the Node B goes down as shown in figure 3. The packet forwarding path is denoted by '***' in working direction and '###' in protection direction. The forwarding path is: A -> [P1|L2|B] -> F -> [P2|L2|B] -> E -> [P3|L2|B] -> D -> [P4|L2|B] -> C -> [L4] -> D. When node A finds the link to B is failed, it push protection label [P6] to the outgoing packet with [L2] at egress port to B, thus the label stack is [P6|L2|B], do wrapping and switch [P6|L2|B] to [P1|L2|B], then send out to link A-F. Node F,E,D just do Protection label switching and send the packet to C, and C receives the packet with [P4|L2|B]. Huang & Jiang Expires April 19, 2011 [Page 6] Internet-Draft MPLS Signaling extension for ring protection October 2010 +---+ +---+ | F |-----------| A | <---LSP 1 +---+ ##########+---+ / # [P1|L2|B] \ / # \ [L2] / #[P2|L2|B] X / # \ +---+ +---+ | E | | B | +---+ +---+ \ #[P3|L2|B] / \ # X \ # / \ # [P4|L2|B] / +---+###########+---+ LSP 1<---| D |-----------+ C | +---+***********+---+ [L4] Figure 3: packet flow when node B failure When node C finds the link to B is failed, it pops the protection label [P5] and gets [L2] at egress port to B, does wrapping and switches [L2] to [L4] based on label switching information notified by node B during setup of the LSP using the signaling extensions defined in section 4, and then send out packet with [L4] to link C-D. 3.2. p-t-mp LSP example TBD 3.2.1. Link Failure example TBD 3.2.2. Node Failure example TBD 3.3. OAM Consideration TBD 4. Signaling extension 4.1. LDP extension TBD Huang & Jiang Expires April 19, 2011 [Page 7] Internet-Draft MPLS Signaling extension for ring protection October 2010 4.2. RSVP-TE extension TBD 5. Security Considerations TBD 6. IANA Considerations TBD 7. Conclusions TBD 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. [MPLS-FRR] P. Pan, G. Swallow and A. Atlas., " Fast Reroute Extensions to RSVP-TE for LSP Tunnels ", BCP 14, RFC 4090, May 2005. [LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 8.2. Informative References [Inf-1] Y. Weingarten, et al, "MPLS-TP Ring Protection", August 2010. [Inf-2] I. Umansky, et al, "MPLS-TP Ring Protection Switching (MRPS)", August 2010. [Inf-3] S. Kini, et al, "Efficient Fast Re-route (FRR) using Facility backup in ring topology", August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Huang & Jiang Expires April 19, 2011 [Page 8] Internet-Draft MPLS Signaling extension for ring protection October 2010 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Yong Huang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: huang.yong@huawei.com Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: yljiang@huawei.com 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. Huang & Jiang Expires April 19, 2011 [Page 9]