--- 1/draft-ietf-mpls-ldp-p2mp-06.txt 2009-07-12 14:12:13.000000000 +0200 +++ 2/draft-ietf-mpls-ldp-p2mp-07.txt 2009-07-12 14:12:13.000000000 +0200 @@ -1,22 +1,22 @@ Network Working Group I. Minei (Editor) Internet-Draft K. Kompella Intended status: Standards Track Juniper Networks -Expires: October 22, 2009 I. Wijnands (Editor) +Expires: January 13, 2010 I. Wijnands (Editor) B. Thomas Cisco Systems, Inc. - April 20, 2009 + July 12, 2009 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths - draft-ietf-mpls-ldp-p2mp-06 + draft-ietf-mpls-ldp-p2mp-07 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -35,45 +35,46 @@ 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 October 22, 2009. + This Internet-Draft will expire on January 13, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol - Label Switching (MPLS) networks. LDP constructs the P2MP or MP2MP - LSPs without interacting with or relying upon any other multicast - tree construction protocol. Protocol elements and procedures for - this solution are described for building such LSPs in a receiver- - initiated manner. There can be various applications for P2MP/MP2MP - LSPs, for example IP multicast or support for multicast in BGP/MPLS - L3VPNs. Specification of how such applications can use a LDP - signaled P2MP/MP2MP LSP is outside the scope of this document. + Label Switching (MPLS) networks. These extensions are also referred + to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs + without interacting with or relying upon any other multicast tree + construction protocol. Protocol elements and procedures for this + solution are described for building such LSPs in a receiver-initiated + manner. There can be various applications for P2MP/MP2MP LSPs, for + example IP multicast or support for multicast in BGP/MPLS L3VPNs. + Specification of how such applications can use a LDP signaled P2MP/ + MP2MP LSP is outside the scope of this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9 @@ -95,42 +96,39 @@ 5.2. LDP Messages containing LDP MP Status messages . . . . . . 22 5.2.1. LDP MP Status sent in LDP notification messages . . . 22 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 - 8. MP2MP micro loop prevention . . . . . . . . . . . . . . . . . 26 - 8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 27 - 8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 27 - 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27 - 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28 - 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29 - 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29 - 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 - 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 - 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31 - 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 - 9.4.4. Receiving a Label Map with MBB status code . . . . . . 32 - 9.4.5. Receiving a Notification with MBB status code . . . . 32 - 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 - 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 - 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 + 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 + 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 + 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 + 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 + 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 + 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 + 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 + 8.4.4. Receiving a Label Map with MBB status code . . . . . . 31 + 8.4.5. Receiving a Notification with MBB status code . . . . 31 + 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 + 12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction The LDP protocol is described in [RFC5036]. It defines mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document describes extensions to LDP for setting up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs. These are collectively referred to as multipoint LSPs (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) node to be delivered to a number of leaf (or egress) nodes. A MP2MP @@ -1093,64 +1091,21 @@ The advantage of pre-building multiple MP2MP LSPs for a single opaque value is that convergence from a root node failure happens as fast as the unicast routing protocol is able to notify. There is no need for an additional protocol to advertise to the leaf nodes which root node is the active root. The root selection is a local leaf policy that does not need to be coordinated with other leafs. The disadvantage of pre-building multiple MP2MP LSPs is that more label resources are used, depending on how many root nodes are defined. -8. MP2MP micro loop prevention - - A MP LSP is built hop by hop following the best path to reach the - root of the LSP. If the routing protocol used to calculate the best - path is subjected to micro-loops, the MP LSP may contain a micro - loop. Both P2MP and MP2MP LSPs may end up containing a micro-loop. - However, there is a difference between loops in P2MP and MP2MP LSP. - In a P2MP LSP, once a loop s formed, no new packet can enter it, but - in a MP2MP LSP, packets may continue to enter the loop. This makes a - loop in MP2MP LSP worse compared to loop in P2MP LSP. If the routing - protocol is not subjected to micro-loops, the MP LSP will not end up - in a micro-loop and no additional procedures are necessary. The - following section describes procedures that MAY be applied to prevent - micro-loops in MP2MP LSPs in case the routing protocol is not able to - guarantee a loop-free best path selection. - -8.1. MP2MP upstream path - - A MP2MP LSP has multiple injection points, there is one injection - point from the root down the LSP towards the leafs, which is the same - as a P2MP LSP. Other injection point(s) are from each leaf towards - the root of the LSP. These procedures solve micro-loops which are - the result of injecting packets from the leaf towards the root. It - does not solve micro-loops which are the result of injecting packets - from the root. This makes the MP2MP LSP as good as P2MP LSPs. - -8.2. MP2MP micro loop prevention procedures - - Based on the procedures defined in Section 4.3.1.3 ordered mode is - used to build the upstream path from the root down to the leaves. - The MP2MP-U Label Map will add a path vector TLV [RFC5036] as - optional parameter to the MP2MP-U Label Map message. Each LSR will - add its own router ID to the path list TLV before sending the MP2MP-U - Label Map to the downstream LSRs. Suppose node Z receives - a MP2MP-U Label Map from LSR D with Label Lu. If node Z finds its - own router ID in the path vector list it will complete the procedures - for MP2MP LSP's defined in this draft with the following exception, - the Label Forwarding Database for the MP2MP upstream with - Lu is not installed, but is retained. By not installing Label Lu the - loop is prevented. If node Z receives a MP2MP-U Label Map that - updates the path vector list such that it does not include its own - router ID, Label Lu can be safely installed into forwarding. - -9. Make Before Break (MBB) +8. Make Before Break (MBB) An LSR selects as its upstream LSR for a MP LSP the LSR that is its next hop to the root of the LSP. When the best path to reach the root changes the LSR must choose a new upstream LSR. Sections Section 2.4.3 and Section 4.3.3 describe these procedures. When the best path to the root changes the LSP may be broken temporarily resulting in packet loss until the LSP "reconverges" to a new upstream LSR. The goal of MBB when this happens is to keep the duration of packet loss as short as possible. In addition, there are @@ -1150,31 +1105,30 @@ root changes the LSR must choose a new upstream LSR. Sections Section 2.4.3 and Section 4.3.3 describe these procedures. When the best path to the root changes the LSP may be broken temporarily resulting in packet loss until the LSP "reconverges" to a new upstream LSR. The goal of MBB when this happens is to keep the duration of packet loss as short as possible. In addition, there are scenarios where the best path from the LSR to the root changes but the LSP continues to forward packets to the prevous next hop to the root. That may occur when a link comes up or routing metrics change. - In such a case a new LSP should be established before the old LSP is removed to limit the duration of packet loss. The procedures described below deal with both scenarios in a way that an LSR does not need to know which of the events described above caused its upstream router for an MBB LSP to change. This MBB procedures are an optional extension to the MP LSP building procedures described in this draft. -9.1. MBB overview +8.1. MBB overview The MBB procedues use additional LDP signaling. Suppose some event causes a downstream LSR-D to select a new upstream LSR-U for FEC-A. The new LSR-U may already be forwarding packets for FEC-A; that is, to downstream LSR's other than LSR-D. After LSR-U receives a label for FEC-A from LSR-D, it will notify LSR-D when it knows that the LSP for FEC-A has been established from the root to itself. When LSR-D receives this MBB notification it will change its next hop for the LSP root to LSR-U. @@ -1198,23 +1152,23 @@ After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U MUST NOT reply with an MBB notification to LSR-D until its state for the LSP is state #3 above. If the state of the LSP at LSR-U is state #1 or #2, LSR-U should remember receipt of the Label Mapping message from LSR-D while waiting for an MBB notification from its upstream LSR for the LSP. When LSR-U receives the MBB notification from its upstream LSR it transitions to LSP state #3 and sends an MBB notification to LSR-D. -9.2. The MBB Status code +8.2. The MBB Status code - As noted in Section 9.1, the procedures to establish an MBB MP LSP + As noted in Section 8.1, the procedures to establish an MBB MP LSP are different from those to establish normal MP LSPs. When a downstream LSR sends a Label Mapping message for MP LSP to its upstream LSR it MAY include an LDP MP Status TLV that carries a MBB Status Code to indicate MBB procedures apply to the LSP. This new MBB Status Code MAY also appear in an LDP Notification message used by an upstream LSR to signal LSP state #3 to the downstream LSR; that is, that the upstream LSR's state for the LSP exists and that it has received notification from its upstream LSR that the LSP is in state #3. @@ -1229,21 +1183,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MBB Type: Type 1 (to be assigned by IANA) Length: 1 Status code: 1 = MBB request 2 = MBB ack -9.3. The MBB capability +8.3. The MBB capability An LSR MAY advertise that it is capable of handling MBB LSPs using the capability advertisement as defined in [I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| LDP MP MBB Capability | Length = 1 | @@ -1259,26 +1213,26 @@ |1|0| LDP MP MBB Capability | Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved | +-+-+-+-+-+-+-+-+ If an LSR has not advertised that it is MBB capable, its LDP peers MUST NOT send it messages which include MBB parameters. If an LSR receives a Label Mapping message with a MBB parameter from downstream LSR-D and its upstream LSR-U has not advertised that it is MBB capable, the LSR MUST send an MBB notification immediatly to LSR-U - (see Section 9.4). If this happens an MBB MP LSP will not be + (see Section 8.4). If this happens an MBB MP LSP will not be established, but normal a MP LSP will be the result. -9.4. The MBB procedures +8.4. The MBB procedures -9.4.1. Terminology +8.4.1. Terminology 1. MBB LSP : A P2MP or MP2MP Make Before Break (MBB) LSP entry with Root Node Address X and Opaque Value Y. 2. A(N, L): An Accepting element that consists of an upstream Neighbor N and Local label L. This LSR assigned label L to neighbor N for a specific MBB LSP. For an active element the corresponding Label is stored in the label forwarding database. 3. iA(N, L): An inactive Accepting element that consists of an @@ -1294,40 +1248,40 @@ 5. F'(N, L): A Forwarding state that has been marked for sending a MBB Notification message to Neighbor N with Label L. 6. MBB Notification : A LDP notification message with a MP LSP , Label L and MBB Status code 2. 7. MBB Label Map : A P2MP Label Map or MP2MP Label Map downstream with a FEC element , Label L and MBB Status code 1. -9.4.2. Accepting elements +8.4.2. Accepting elements An accepting element represents a specific label value L that has been advertised to a neighbor N for a MBB LSP and is a candidate for accepting labels switched packets on. An LSR can have two accepting elements for a specific MBB LSP LSP, only one of them MUST be active. An active element is the element for which the label value has been installed in the label forwarding database. An inactive accepting element is created after a new upstream LSR is chosen and is pending to replace the active element in the label forwarding database. Inactive elements only exist temporarily while switching to a new upstream LSR. Once the switch has been completed only one active element remains. During network convergence it is possible that an inactive accepting element is created while an other inactive accepting element is pending. If that happens the older inactive accepting element MUST be replaced with an newer inactive element. If an accepting element is removed a Label Withdraw has to be send for label L to neighbor N for . -9.4.3. Procedures for upstream LSR change +8.4.3. Procedures for upstream LSR change Suppose a node Z has a MBB LSP with an active accepting element A(N1, L1). Due to a routing change it detects a new best path for root X and selects a new upstream LSR N2. Node Z allocates a new local label L2 and creates an inactive accepting element iA(N2, L2). Node Z sends MBB Label Map to N2 and waits for the new upstream LSR N2 to respond with a MBB Notification for . During this transition phase there are two accepting elements, the element A(N1, L1) still accepting packets from N1 over label L1 and the new inactive element iA(N2, L2). @@ -1336,66 +1290,66 @@ possible that an other transition occurs due to a routing change. Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) is created and the old inactive element iA(N2, L2) MUST be removed. A label withdraw MUST be sent to N2 for from N2 will be ignored because the inactive element is removed. It is possible that the MBB Notification from upstream LSR is never received due to link or node failure. To prevent waiting indefinitely for the MBB Notification a timeout SHOULD be applied. - As soon as the timer expires, the procedures in Section 9.4.5 are + As soon as the timer expires, the procedures in Section 8.4.5 are applied as if a MBB Notification was received for the inactive element. -9.4.4. Receiving a Label Map with MBB status code +8.4.4. Receiving a Label Map with MBB status code Suppose node Z has state for a MBB LSP and receives a MBB Label Map from N2. A new forwarding state F(N2, L2) will be added to the MP LSP if it did not already exist. If this MBB LSP has an active accepting element or node Z is the root of the MBB LSP a MBB notification is send to node N2. If node Z has an inactive accepting element it marks the Forwarding state as . -9.4.5. Receiving a Notification with MBB status code +8.4.5. Receiving a Notification with MBB status code Suppose node Z receives a MBB Notification from N. If node Z has state for MBB LSP and an inactive accepting element iA(N, L) that matches with N and L, we activate this accepting element and install label L in the label forwarding database. If an other active accepting was present it will be removed from the label forwarding database. If this MBB LSP also has Forwarding states marked for sending MBB Notifications, like , MBB Notifications are send to these downstream LSRs. If node Z receives a MBB Notification for an accepting element that is not inactive or does not match the Label value and Neighbor address, the MBB notification is ignored. -9.4.6. Node operation for MP2MP LSPs +8.4.6. Node operation for MP2MP LSPs The procedures described above apply to the downstream path of a MP2MP LSP. The upstream path of the MP2MP is setup as normal without including a MBB Status code. If the MBB procedures apply to a MP2MP downstream FEC element, the upstream path to a node N is only installed in the label forwarding database if node N is part of the active accepting element. If node N is part of an inactive accepting element, the upstream path is installed when this inactive accepting element is activated. -10. Security Considerations +9. Security Considerations The same security considerations apply as for the base LDP specification, as described in [RFC5036]. -11. IANA considerations +10. IANA considerations This document creates a new name space (the LDP MP Opaque Value Element type) that is to be managed by IANA, and the allocation of the value 1 for the type of Generic LSP Identifier. This document requires allocation of three new LDP FEC Element types: 1. the P2MP FEC type - requested value 0x06 2. the MP2MP-up FEC type - requested value 0x07 @@ -1406,44 +1360,44 @@ three new Capability Parameter TLVs, corresponding to the advertisement of the P2MP, MP2MP and MBB capabilities. The values requested are: P2MP Capability Parameter - requested value 0x0508 MP2MP Capability Parameter - requested value 0x0509 MBB Capability Parameter - requested value 0x050A - This document requires the assignment of a LDP Status TLV code to + This document requires the assignment of a LDP Status Code to indicate a LDP MP Status TLV is following in the Notification - message. The value requested is: + message. The value requested from the LDP Status Code Name Space: - LDP MP status - requested value 0x0000002D + LDP MP status - requested value 0x00000040 This document requires the assigment of a new code point for a LDP MP - Status TLV. The value requested is: + Status TLV. The value requested from the LDP TLV Type Name Space: - LDP MP Status TLV Type - requested value 0x096D + LDP MP Status TLV Type - requested value 0x096F This document creates a new name space (the LDP MP Status Value Element type) that is to be managed by IANA, and the allocation of the value 1 for the type of MBB Status. -12. Acknowledgments +11. Acknowledgments The authors would like to thank the following individuals for their review and contribution: Nischal Sheth, Yakov Rekhter, Rahul Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas Morin. -13. Contributing authors +12. Contributing authors Below is a list of the contributing authors in alphabetical order: Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 US Email: Shane.Amante@Level3.com @@ -1502,23 +1456,23 @@ Norway Email: lei.wang@telenor.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium E-mail: ice@cisco.com -14. References +13. References -14.1. Normative References +13.1. Normative References [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. @@ -1531,21 +1485,21 @@ [I-D.ietf-mpls-ldp-upstream] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for LDP", draft-ietf-mpls-ldp-upstream-02 (work in progress), November 2007. [I-D.ietf-mpls-ldp-capabilities] Thomas, B., "LDP Capabilities", draft-ietf-mpls-ldp-capabilities-02 (work in progress), March 2008. -14.2. Informative References +13.2. Informative References [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [I-D.ietf-mpls-mp-ldp-reqs]