--- 1/draft-ietf-mpls-ldp-p2mp-05.txt 2009-04-20 21:12:05.000000000 +0200 +++ 2/draft-ietf-mpls-ldp-p2mp-06.txt 2009-04-20 21:12:05.000000000 +0200 @@ -1,158 +1,173 @@ Network Working Group I. Minei (Editor) Internet-Draft K. Kompella Intended status: Standards Track Juniper Networks -Expires: November 2, 2008 I. Wijnands (Editor) +Expires: October 22, 2009 I. Wijnands (Editor) B. Thomas Cisco Systems, Inc. + April 20, 2009 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths - draft-ietf-mpls-ldp-p2mp-05 + draft-ietf-mpls-ldp-p2mp-06 Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + 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 + the person(s) controlling the copyright in such materials, this + document may not be modified outside the IETF Standards Process, and + derivative works of it may not be created outside the IETF Standards + Process, except to format it for publication as an RFC or to + translate it into languages other than English. 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 November 2, 2008. + This Internet-Draft will expire on October 22, 2009. Copyright Notice + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. - Copyright (C) The IETF Trust (2008). + 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. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Conventions used in this document . . . . . . . . . . . . 4 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5 - 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6 - 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 - 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8 - 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8 - 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 9 - 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10 - 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 11 - 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12 - 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13 - 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 13 - 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 14 - 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 14 - 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16 - 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 19 - 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 20 - 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 20 - 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 20 - 5.2. LDP Messages containing LDP MP Status messages . . . . . . 21 - 5.2.1. LDP MP Status sent in LDP notification messages . . . 21 - 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 22 - 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 22 - 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 23 - 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 23 - 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 23 - 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 23 - 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 24 - 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 24 - 8. MP LSP micro loops . . . . . . . . . . . . . . . . . . . . . . 25 - 8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 25 - 8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 26 - 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 - 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 26 - 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 27 - 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 - 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 - 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 - 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 29 - 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 - 9.4.4. Receiving a Label Map with MBB status code . . . . . . 30 - 9.4.5. Receiving a Notification with MBB status code . . . . 31 - 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 - 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 - 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 32 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 - 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 - Intellectual Property and Copyright Statements . . . . . . . . . . 37 + 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 + 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 9 + 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 10 + 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11 + 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12 + 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 13 + 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 14 + 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 + 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 15 + 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 + 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 17 + 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20 + 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21 + 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 + 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 + 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 1. Introduction - The LDP protocol is described in [1]. 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 + 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 LSP allows traffic from multiple ingress nodes to be delivered to multiple egress nodes. Only a single copy of the packet will be sent on any link traversed by the MP LSP (see note at end of Section 2.4.1). This is accomplished without the use of a multicast protocol in the network. There can be several MP LSPs rooted at a given ingress node, each with its own identifier. The solution assumes that the leaf nodes of the MP LSP know the root node and identifier of the MP LSP to which they belong. The mechanisms for the distribution of this information are outside the scope of this document. The specification of how an application can use a MP LSP signaled by LDP is also outside the scope of this document. - Interested readers may also wish to peruse the requirements draft [9] - and other documents [8] and [10]. + Interested readers may also wish to peruse the requirements draft + [I-D.ietf-mpls-mp-ldp-reqs] and other documents [RFC4875] and + [I-D.ietf-l3vpn-2547bis-mcast]. 1.1. Conventions used in this document 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 [2]. + document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Terminology - The following terminology is taken from [9]. + The following terminology is taken from [I-D.ietf-mpls-mp-ldp-reqs]. P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs. MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR. MP2MP LSP: An LSP that connects a set of nodes, such that traffic @@ -163,23 +178,23 @@ Ingress LSR: An ingress LSR for a particular LSP is an LSR that can send a data packet along the LSP. MP2MP LSPs can have multiple ingress LSRs, P2MP LSPs have just one, and that node is often referred to as the "root node". Egress LSR: An egress LSR for a particular LSP is an LSR that can remove a data packet from that LSP for further processing. P2P and MP2P LSPs have only a single egress node, but P2MP and MP2MP LSPs can have multiple egress nodes. - Transit LSR: An LSR that has reachability to a) the root of the MP - LSP via a directly connected upstream LSR and b) via one or more - directly connected downstream LSRs. + Transit LSR: An LSR that has reachability to the root of the MP LSP + via a directly connected upstream LSR and one or more directly + connected downstream LSRs. Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs. Leaf node: A Leaf node can be either an Egress or Bud LSR when referred in the context of a P2MP LSP. In the context of a MP2MP LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR. 2. Setting up P2MP LSPs with LDP @@ -191,23 +206,24 @@ is done is outside the scope of this document. Transit nodes install MPLS forwarding state and propagate the P2MP LSP setup (and tear- down) toward the root. The root node installs forwarding state to map traffic into the P2MP LSP; how the root node determines which traffic should go over the P2MP LSP is outside the scope of this document. 2.1. Support for P2MP LSP setup with LDP Support for the setup of P2MP LSPs is advertised using LDP - capabilities as defined in [6]. An implementation supporting the - P2MP procedures specified in this document MUST implement the - procedures for Capability Parameters in Initialization Messages. + capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An + implementation supporting the P2MP procedures specified in this + document MUST implement the procedures for Capability Parameters in + Initialization Messages. A new Capability Parameter TLV is defined, the P2MP Capability. Following is the format of the P2MP Capability Parameter. 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| P2MP Capability (TBD IANA) | Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved | @@ -247,22 +263,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The type of the P2MP FEC Element is to be assigned by IANA. Address Family: Two octet quantity containing a value from ADDRESS - FAMILY NUMBERS in [3] that encodes the address family for the Root - LSR Address. + FAMILY NUMBERS in [RFC3232] that encodes the address family for + the Root LSR Address. Address Length: Length of the Root LSR Address in octets. Root Node Address: A host address encoded according to the Address Family field. Opaque Length: The length of the Opaque Value, in octets. Opaque Value: One or more MP Opaque Value elements, uniquely identifying the P2MP LSP in the context of the Root Node. This is @@ -359,26 +375,27 @@ leaf node. 2.4.1. Label Map The remainder of this section specifies the procedures for originating P2MP Label Map messages and for processing received P2MP label map messages for a particular LSP. The procedures for a particular LSR depend upon the role that LSR plays in the LSP (ingress, transit, or egress). - All labels discussed here are downstream-assigned [11] except those - which are assigned using the procedures of Section 6. + All labels discussed here are downstream-assigned + [I-D.ietf-mpls-multicast-encaps] except those which are assigned + using the procedures of Section 6. 2.4.1.1. Determining one's 'upstream LSR' - Each node that is either a Leaf or Transit LSR of an MP LSP needs to + Each node that is either an Leaf or Transit LSR of MP LSP needs to use the procedures below to select an upstream LSR. A node Z that wants to join a MP LSP determines the LDP peer U which is Z's next-hop on the best path from Z to the root node X. If there is more than one such LDP peer, only one of them is picked. U is Z's "Upstream LSR" for . When there are several candidate upstream LSRs, the LSR MAY select one upstream LSR using the following procedure: 1. The candidate upstream LSRs are numbered from lower to higher IP @@ -394,44 +411,49 @@ single upstream LSR is selected. 2.4.1.2. Leaf Operation A leaf node Z of P2MP LSP determines its upstream LSR U for as per Section 2.4.1.1, allocates a label L, and sends a P2MP Label Map to U. 2.4.1.3. Transit Node operation - Suppose a transit node Z receives a P2MP Label Map from LDP - peer T. Z checks whether it already has state for . If not, Z - allocates a label L', and installs state to swap L' with L over - interface I associated with peer T. Z also determines its upstream - LSR U for as per Section 2.4.1.1, and sends a P2MP Label Map - to U. + Suppose a transit node Z receives a P2MP Label Map from LSR + T. Z checks whether it already has state for . If not, Z + determines its upstream LSR U for as per Section 2.4.1.1. + Using this Label Map to update the label forwarding table MUST NOT be + done as long as LSR T is equal to LSR U. If LSR U is different from + LSR T, Z will allocate a label L', and install state to swap L' with + L over interface I associated with LSR T and send a P2MP Label Map + to LSR U. If Z already has state for , then Z does not send a Label Map message for P2MP LSP . All that Z needs to do in this case is + check that LSR T is not equal to the upstream LSR of and update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state - becomes L'-> { ..., , }. + becomes L'-> { ..., , }. If the LSR T + is equal to the installed upstream LSR, the Label Map from LSR T MUST + be retained and MUST not update the label forwarding table. 2.4.1.4. Root Node Operation - Suppose the root node Z receives a P2MP Label Map from peer + Suppose the root node Z receives a P2MP Label Map from LSR T. Z checks whether it already has forwarding state for . If not, Z creates forwarding state to push label L onto the traffic that Z wants to forward over the P2MP LSP (how this traffic is determined is outside the scope of this document). If Z already has forwarding state for , then Z adds "push label L, send over interface I" to the nexthop, where I is the interface - associated with peer T. + associated with LSR T. 2.4.2. Label Withdraw The following lists procedures for generating and processing P2MP Label Withdraw messages for nodes that participate in a P2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the P2MP LSP. 2.4.2.1. Leaf Operation @@ -455,40 +477,45 @@ 2.4.2.3. Root Node Operation The procedure when the root node of a P2MP LSP receives a Label Withdraw message are the same as for transit nodes, except that it would not propagate the Label Withdraw upstream (as it has no upstream). 2.4.3. Upstream LSR change - If, for a given node Z participating in a P2MP LSP , the - upstream LSR changes, say from U to U', then Z MUST update its - forwarding state by deleting the state for label L, allocating a new - label, L', for , and installing the forwarding state for L'. In - addition Z MUST send a Label Map to U' and send a Label - Withdraw to U. + Suppose that for a given node Z participating in a P2MP LSP , + the upstream LSR changes from U to U' as per Section 2.4.1.1. If U' + is present in the forwarding table of then it MUST be removed. + Z MUST also update its forwarding state by deleting the state for + label L, allocating a new label, L', for , and installing the + forwarding state for L'. Installing the forwarding state for L' MUST + NOT be done before the forwarding state L is removed to avoid + microloops. In addition Z MUST send a Label Map to U' and + send a Label Withdraw to U. Note, if there was a downstream + mapping from U that was not installed in the forwarding due to + Section 2.4.1.3 it can now be installed. 3. Shared Trees The mechanism described above shows how to build a tree with a single root and multiple leaves, i.e., a P2MP LSP. One can use essentially the same mechanism to build Shared Trees with LDP. A Shared Tree can be used by a group of routers that want to multicast traffic among themselves, i.e., each node is both a root node (when it sources traffic) and a leaf node (when any other member of the group sources traffic). A Shared Tree offers similar functionality to a MP2MP LSP, but the underlying multicasting mechanism uses a P2MP LSP. One example where a Shared Tree is useful is video-conferencing. Another - is Virtual Private LAN Service (VPLS) [7], where for some types of - traffic, each device participating in a VPLS must send packets to + is Virtual Private LAN Service (VPLS) [RFC4664], where for some types + of traffic, each device participating in a VPLS must send packets to every other device in that VPLS. One way to build a Shared Tree is to build an LDP P2MP LSP rooted at a common point, the Shared Root (SR), and whose leaves are all the members of the group. Each member of the Shared Tree unicasts traffic to the SR (using, for example, the MP2P LSP created by the unicast LDP FEC advertised by the SR); the SR then splices this traffic into the LDP P2MP LSP. The SR may be (but need not be) a member of the multicast group. @@ -524,28 +551,29 @@ downstream node MUST never be forwarded back out to that same node. Mapping traffic to the MP2MP LSP may happen at any leaf node. How that mapping is established is outside the scope of this document. Due to how a MP2MP LSP is built a leaf LSR that is sending packets on the MP2MP LSP does not receive its own packets. There is also no additional mechanism needed on the root or transit LSR to match upstream traffic to the downstream forwarding state. Packets that are forwarded over a MP2MP LSP will not traverse a link more than once, with the possible exception of LAN links (see Section 4.3.1), - if the procedures of [4] are not provided. + if the procedures of [I-D.ietf-mpls-upstream-label] are not provided. 4.1. Support for MP2MP LSP setup with LDP Support for the setup of MP2MP LSPs is advertised using LDP - capabilities as defined in [6]. An implementation supporting the - MP2MP procedures specified in this document MUST implement the - procedures for Capability Parameters in Initialization Messages. + capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An + implementation supporting the MP2MP procedures specified in this + document MUST implement the procedures for Capability Parameters in + Initialization Messages. A new Capability Parameter TLV is defined, the MP2MP Capability. Following is the format of the MP2MP Capability Parameter. 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| MP2MP Capability (TBD IANA) | Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved | @@ -568,23 +596,24 @@ FEC is a misnomer. The description of the MP2MP FEC Elements follow. The structure, encoding and error handling for the MP2MP downstream and upstream FEC Elements are the same as for the P2MP FEC Element described in Section 2.2. The difference is that two new FEC types are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element MUST be the only FEC Element in the FEC TLV. - Note, except when using the procedures of [4], the MPLS labels used - are "downstream-assigned" [11], even if they are bound to the - "upstream FEC element". + Note, except when using the procedures of + [I-D.ietf-mpls-upstream-label], the MPLS labels used are "downstream- + assigned" [I-D.ietf-mpls-multicast-encaps], even if they are bound to + the "upstream FEC element". 4.3. Using the MP2MP FEC Elements This section defines the rules for the processing and propagation of the MP2MP FEC Elements. The following notation is used in the processing rules: 1. MP2MP downstream LSP (or simply downstream ): an MP2MP LSP downstream path with root node address X and opaque value Y. @@ -637,22 +666,23 @@ leaf of the MP2MP LSP. 4.3.1. MP2MP Label Map The remainder of this section specifies the procedures for originating MP2MP Label Map messages and for processing received MP2MP label map messages for a particular LSP. The procedures for a particular LSR depend upon the role that LSR plays in the LSP (ingress, transit, or egress). - All labels discussed here are downstream-assigned [11] except those - which are assigned using the procedures of Section 6. + All labels discussed here are downstream-assigned + [I-D.ietf-mpls-multicast-encaps] except those which are assigned + using the procedures of Section 6. 4.3.1.1. Determining one's upstream MP2MP LSR Determining the upstream LDP peer U for a MP2MP LSP follows the procedure for a P2MP LSP described in Section 2.4.1.1. 4.3.1.2. Determining one's downstream MP2MP LSR A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D will treat D as downstream MP2MP LSR. @@ -696,24 +726,27 @@ response to the MP2MP-D Label Map it sent to node U. Z checks whether it already has forwarding state for upstream . If not, Z creates forwarding state to push label Lu onto the traffic that Z wants to forward over the MP2MP LSP. How it determines what traffic to forward on this MP2MP LSP is outside the scope of this document. 4.3.1.5. MP2MP transit node operation When node Z receives a MP2MP-D Label Map from LSR D associated with interface I, it checks whether it has forwarding - state for downstream . If not, Z allocates a label L' and - installs downstream forwarding state to swap label L' with label L - over interface I. Z also determines its upstream LSR U for as - per Section 4.3.1.1, and sends a MP2MP-D Label Map to U. + state for downstream . If not, Z determines its upstream LSR U + for as per Section 4.3.1.1. Using this Label Map to update + the label forwarding table MUST NOT be done as long as LSR D is equal + to LSR U. If LSR U is different from LSR D, Z will allocate a label + L' and install downstream forwarding state to swap label L' with + label L over interface I and send a MP2MP-D Label Map to + U. If Z already has forwarding state for downstream , all that Z needs to do in this case is check that LSR D is not equal to the upstream LSR of and update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. If the LSR D is equal to the installed upstream LSR, the Label Map from LSR D MUST be retained and MUST not update the label forwarding table. @@ -940,48 +971,52 @@ | Additional Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Upstream label allocation on a LAN On a LAN, the procedures so far discussed would require the upstream LSR to send a copy of the packet to each receiver individually. If there is more then one receiver on the LAN we don't take full benefit of the multi-access capability of the network. We may optimize the bandwidth consumption on the LAN and replication overhead on the - upstream LSR by using upstream label allocation [4]. Procedures on - how to distribute upstream labels using LDP is documented in [5]. + upstream LSR by using upstream label allocation + [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute + upstream labels using LDP is documented in + [I-D.ietf-mpls-ldp-upstream]. 6.1. LDP Multipoint-to-Multipoint on a LAN - The procedure to allocate a context label on a LAN is defined in [4]. - That procedure results in each LSR on a given LAN having a context - label which, on that LAN, can be used to identify itself uniquely. - Each LSR advertises its context label as an upstream-assigned label, - following the procedures of [5]. Any LSR for which the LAN is a + The procedure to allocate a context label on a LAN is defined in + [I-D.ietf-mpls-upstream-label]. That procedure results in each LSR + on a given LAN having a context label which, on that LAN, can be used + to identify itself uniquely. Each LSR advertises its context label + as an upstream-assigned label, following the procedures of + [I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a downstream link on some P2MP or MP2MP LSP will allocate an upstream- assigned label identifying that LSP. When the LSR forwards a packet downstream on one of those LSPs, the packet's top label must be the LSR's context label, and the packet's second label is the label identifying the LSP. We will call the top label the "upstream LSR label" and the second label the "LSP label". 6.1.1. MP2MP downstream forwarding The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so - we will use the same procedures as defined in [5]. A label request - for a LSP label is send to the upstream LSR. The label mapping that - is received from the upstream LSR contains the LSP label for the - MP2MP FEC and the upstream LSR context label. The MP2MP downstream - path (corresponding to the LSP label) will be installed the context - specific forwarding table corresponding to the upstream LSR label. - Packets sent by the upstream router can be forwarded downstream using - this forwarding state based on a two label lookup. + we will use the same procedures as defined in + [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is + send to the upstream LSR. The label mapping that is received from + the upstream LSR contains the LSP label for the MP2MP FEC and the + upstream LSR context label. The MP2MP downstream path (corresponding + to the LSP label) will be installed the context specific forwarding + table corresponding to the upstream LSR label. Packets sent by the + upstream router can be forwarded downstream using this forwarding + state based on a two label lookup. 6.1.2. MP2MP upstream forwarding A MP2MP LSP also has an upstream forwarding path. Upstream packets need to be forwarded in the direction of the root and downstream on any node on the LAN that has a downstream interface for the LSP. For a given MP2MP LSP on a given LAN, exactly one LSR is considered to be the upstream LSR. If an LSR on the LAN receives a packet from one of its downstream interfaces for the LSP, and if it needs to forward the packet onto the LAN, it ensures that the packet's top label is the @@ -1058,21 +1093,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. MP LSP micro loops +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 @@ -1088,32 +1123,32 @@ 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 [1] 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. + 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) 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 @@ -1196,22 +1232,23 @@ Length: 1 Status code: 1 = MBB request 2 = MBB ack 9.3. The MBB capability An LSR MAY advertise that it is capable of handling MBB LSPs using - the capability advertisement as defined in [6]. The LDP MP MBB - capability has the following format: + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved | +-+-+-+-+-+-+-+-+ Note: LDP MP MBB Capability (Pending IANA assignment) @@ -1341,21 +1379,21 @@ 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 The same security considerations apply as for the base LDP - specification, as described in [1]. + specification, as described in [RFC5036]. 11. 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 @@ -1467,65 +1506,72 @@ Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium E-mail: ice@cisco.com 14. References 14.1. Normative References - [1] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", - RFC 5036, October 2007. + [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP + Specification", RFC 5036, October 2007. - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. - [3] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- - line Database", RFC 3232, January 2002. + [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by + an On-line Database", RFC 3232, January 2002. - [4] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label - Assignment and Context-Specific Label Space", + [I-D.ietf-mpls-upstream-label] + Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream + Label Assignment and Context-Specific Label Space", draft-ietf-mpls-upstream-label-05 (work in progress), April 2008. - [5] 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-upstream] + Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment + for LDP", draft-ietf-mpls-ldp-upstream-02 (work in + progress), November 2007. - [6] Thomas, B., "LDP Capabilities", + [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 - [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual + [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. - [8] 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. + [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. - [9] Roux, J., "Requirements for Point-To-Multipoint Extensions to - the Label Distribution Protocol", + [I-D.ietf-mpls-mp-ldp-reqs] + Roux, J., "Requirements for Point-To-Multipoint Extensions + to the Label Distribution Protocol", draft-ietf-mpls-mp-ldp-reqs-04 (work in progress), February 2008. - [10] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., - Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/ - BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in - progress), January 2008. + [I-D.ietf-l3vpn-2547bis-mcast] + Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., + Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in + MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work + in progress), January 2008. - [11] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS - Multicast Encapsulations", draft-ietf-mpls-multicast-encaps-09 - (work in progress), May 2008. + [I-D.ietf-mpls-multicast-encaps] + Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS + Multicast Encapsulations", + draft-ietf-mpls-multicast-encaps-09 (work in progress), + May 2008. Authors' Addresses Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: ina@juniper.net @@ -1545,55 +1592,10 @@ Email: ice@cisco.com Bob Thomas Cisco Systems, Inc. 300 Beaver Brook Road Boxborough 01719 US Email: bobthomas@alum.mit.edu - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).