MPLS Working Group Y. Huang Internet-Draft Y. Jiang Intended Status: Standards Track Huawei Technologies Expires: April 2011 October 25, 2010 Signaling extension for MPLS ring protection draft-huang-mpls-ring-signaling-extension-01.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 25, 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 & Jiang Expires April 25, 2011 [Page 1] Internet-Draft Signaling Extension for MPLS 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.........................................8 4.1. LDP extension.........................................10 4.2. RSVP-TE extension......................................12 5. Security Considerations.....................................12 6. IANA Considerations........................................12 7. Conclusions................................................12 8. References.................................................12 8.1. Normative References...................................12 8.2. Informative References.................................13 9. Acknowledgments............................................13 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 solution for MPLS ring. MPLS Fast Re-Route [MPLS-FRR] can 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 service LSPs 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 25, 2011 [Page 2] Internet-Draft Signaling Extension for MPLS 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 MPLS Multi-Protocol Label Switching MPLS-TP MPLS Transport Profile SPME Sub-path Maintenance Element 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 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 packet outermost label is service LSP label. That is to say, no SPME 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. Huang & Jiang Expires April 25, 2011 [Page 3] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 3. Control layer, service LSPs crossing the ring can be created normally by LSP signaling with the extension in section 4. The extension is to send label switch information to downstream ring node or backup node. 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 the 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. After popping the protection label, the downstream node adjacent to the failure can do the label switching work in working direction with additional label switching information got from the failure node during the setup of the service LSP. The detailed procedure and the definition of the information is referred to section 4. 8. To protect failure of ingress or egress node of a ring, a backup node can be assigned during MPLS ring 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 a closed LSP in CCW direction and 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 Huang & Jiang Expires April 25, 2011 [Page 4] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 3. The bottom of the stack will be denoted by the string "B" for two or more label layer. +---+ [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 Huang & Jiang Expires April 25, 2011 [Page 5] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 For example, the link between B and C goes down as shown in figure 2. After recovering, the packet forwarding path is denoted by '***' in the working direction and '###' in the protection direction. The forwarding path and encapsulation on link 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, so 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. Then at node D, the service LSP drops the ring after normal label switching. 3.1.2. Node Failure example For example, the Node B goes down as shown in figure 3. After recovering, the packet forwarding path is denoted by '***' in working direction and '###' in protection direction. The forwarding path and the encapsulation on link 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 25, 2011 [Page 6] Internet-Draft Signaling Extension for MPLS 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] supported by label switching information notified by node B during setup of the LSP. This notification operation uses the signaling extensions defined in section 4. Node C then sends out packet with [L4] to link C-D. At node D, the service LSP drops the ring after normal label switching. 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 Each pair of adjacent nodes on the ring should deploy OAM continuity check (CC) mechanism to detecting failures between each other. When one node gets event(s) that the CC check to one peer node fails, it will inform from the opposite direction to inform the event for the ring. That is to say, using section OAM can do the job. Huang & Jiang Expires April 25, 2011 [Page 7] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 Section OAM also can meet the need for multiple logical ring instances be deployed in one physical link. The possible scenario in industry regarding this is two tangent rings which share one or more links between two ring nodes (the ring nodes can be adjacent or not). Theoretically one may worry about the case that when do wrapping, how to recognize different logical ring and push related protection label on the packets. In reality, as long as we design the two ring under the same policy, that is, taking CW (or vice versa) as working direction on both rings (this is the most popular case), there is no problem in question on the shared link(s). How to perform the OAM CC and how to inform the failure event to the right receiver, is out of scope of this document. We think that both MPLS and MPLS-TP OAM mechanism can be used for the purpose. 4. Signaling extension The purpose of the signaling extension is to backup the protected node's label switching information to one backup node. Under ring topology the backup type has two case: Case 1: For protecting transit ring node, the backup node is the immediate downstream node to the protected one. Case 2: For protecting ingress/egress ring node, backup node is provisioned by operator. Case 1 can be illustrated in the same example shown in figure 3, the normal forwarding path and labels on links are: A -> [L2] -> B -> [L3] -> C -> [L4] -> D. During the LSP setup, when node B gets the mapping label from C [L3], it allocate [L2] to node A and locally generate label switching information for forwarding. At this point of time, Node C send a new message to Node C containing the local switching information . When node C gets the message containing the label mapping information , combines it's local label switching information , and generates a new label mapping info as . The new label switching information can help node C to finish the work described in section 3.1.2. Every protected node should perform the signaling procedure like node B in above example. Note that above mechanism needs to do some label planning work to avoid duplicate label for adjacent links (e.g. link C-D and link B-C are adjacent links). Huang & Jiang Expires April 25, 2011 [Page 8] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 Case 2 can be illustrated in figure 4. [P1|L4|B] +---+ ##########+---+ | F |-----------| A | <---LSP 1 +---+ +---+ #/ *\# [P2|L4|B] #/ *\# [P6|L4|B] #/ [L2] *\# #/ *\# +---+ +---+ | E | | B | +---+ +---+ | \ */# [L5] | \ [L3] */# | X */# [P5|L4|B] V \ */# LSP 1 +---+ +---+ +---+ <---| T |<---| D |-----X-----+ C | +---+ +---+ +---+ [L5] [L4] Figure 4 Packet flow when node D failure Definition for illustration: Port E-T : Means physical port at node E which connects node T. Backup id: An id number to correlate two ports. To protect node D which is the egress node of some service LSPs (e.g. LSP 1 in figure 4), a backup node E should be selected and configured. The port E-T and port D-T are configured one same backup id for example 1000. When node D gets the allocated label [L5] from downstream node T which is not the ring node, it allocate label [L4] to node C. At the mean time, node D send a new message containing label mapping information and backup id 1000 to pre-configured backup node E. At node E, after getting the message, E generate a new local label switching information take in-port as ring port E-D and out-port as the port E-T according to backup id. Huang & Jiang Expires April 25, 2011 [Page 9] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 In figure 4, When E gets packets from the protection ring direction with encapsulation [P2|L4|B], it pop the protection label and switch [L4] to [l5] and send out the packet to node T. Node T can handle the packet from port T-E just like it comes from port T-D. 4.1. LDP extension A TLV bearing the label mapping information described above can meet both case 1 and case 2. The TLV can be named as Label Mapping Information TLV. For LDP protocol, it use Notification message ([LDP] Section 3.5.1 ) to contain the new TLV. The TLV is optional. If a LSR is configured to perform ring protection as section 3, after it gets one label (egress label) from it's downstream peer and allocate a new label (ingress label) to the peer LSR which stands at upstream, it SHOULD send a Notification message containing the Label Mapping Information TLV to the downstream LSR under the Case 1 or to the backup LSR under the Case 2. The LSR can discriminate the different cases by the fact that whether the egress port for the label is the port which belongs to the ring. If a LSR gets the Notification message which contains the Label- Mapping-Info TLV, it SHOULD generate a new local label switching information for forwarding. The LSR can recognize the cases by the TLV content. The Label-Mapping-Info TLV will be put in the optional parameter field following the status TLV and be described as following: Optional Parameter Type Length Value Label-Mapping-Info TBD 20 See below Label Mapping Information TLV 's format is shown in figure 5. Huang & Jiang Expires April 25, 2011 [Page 10] Internet-Draft Signaling Extension for MPLS Ring Protection 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Label Mapping Info(0x ??) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IMT | EMT | Reserved | +---------------------------------------------------------------+ | Ingress Ring id/Backup id | +---------------------------------------------------------------+ | Ingress Label | +---------------------------------------------------------------+ | Egress Ring id /Backup id | +---------------------------------------------------------------+ | Egress Label | +---------------------------------------------------------------+ Figure 5 Label Mapping Info TLV format in LDP Following gives some explanation of Label Mapping Info TLV. IMT Ingress Mapping Type 0: Denote that the value in field Ingress Ring id/Backup id is the ring id to which the LSP belongs at the ingress port. 1: Denote that the value in field Ingress Ring id/Backup id is the backup id which the ingress port correlates. Other: Reserved. EMT Egress Mapping Type 0: Denote that the value in field Egress Ring id/Backup id is the ring id to which the LSP belongs at the egress port. 1: Denote that the value in field Egress Ring id/Backup id is the backup id which the egress port correlates. Other: Reserved. Ingress ring/backup id: The value of ingress ring id or backup id of the ingress port. Ingress Label: The value of ingress label. Huang & Jiang Expires April 25, 2011 [Page 11] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 Egress ring/backup id: The value of egress ring id or backup id of the egress port. Egress Label: The value of Egress label. 4.2. RSVP-TE extension TBD 5. Security Considerations TBD 6. IANA Considerations A new LDP protocol TLV code for Label-Mapping-Info TLV need to be assigned by IANA. RSVP-TE extension: 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. Huang & Jiang Expires April 25, 2011 [Page 12] Internet-Draft Signaling Extension for MPLS Ring Protection October 2010 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. 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 25, 2011 [Page 13]