--- 1/draft-ietf-mpls-ldp-p2mp-13.txt 2011-06-16 20:15:42.000000000 +0200 +++ 2/draft-ietf-mpls-ldp-p2mp-14.txt 2011-06-16 20:15:42.000000000 +0200 @@ -1,56 +1,56 @@ Network Working Group I. Minei, Ed. Internet-Draft Juniper Networks Intended status: Standards Track IJ. Wijnands, Ed. -Expires: October 24, 2011 Cisco Systems, Inc. +Expires: December 18, 2011 Cisco Systems, Inc. K. Kompella Juniper Networks B. Thomas - Cisco Systems, Inc. - April 22, 2011 + June 16, 2011 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths - draft-ietf-mpls-ldp-p2mp-13 + draft-ietf-mpls-ldp-p2mp-14 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. These extensions are also referred - to as Multipoint LDP (mLDP). mLDP constructs the P2MP or MP2MP LSPs - without interacting with or relying upon any other multicast tree + for the setup of Point-to-Multipoint and Multipoint-to-Multipoint + Label Switched Paths in Multi-Protocol Label Switching networks. + These extensions are also referred to as Multipoint LDP. Multipoint + LDP constructs the P2MP or MP2MP Label Switched Paths 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 LSPs is outside the scope of this document. + solution are described for building such Label Switched Paths in a + receiver-initiated manner. There can be various applications for + Multipoint Label Switched Paths, for example IP multicast or support + for multicast in BGP/MPLS L3VPNs. Specification of how such + applications can use a LDP signaled Multipoint Label Switched Path is + outside the scope of this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on October 24, 2011. + This Internet-Draft will expire on December 18, 2011. Copyright Notice Copyright (c) 2011 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 @@ -70,81 +70,81 @@ 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. 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 . . . . . . . . . . . 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 . . . . . . . . . . . . . . 10 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 11 - 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11 + 2.4.1. Label Mapping . . . . . . . . . . . . . . . . . . . . 11 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 13 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 14 3. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 15 3.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 15 3.2. The MP2MP downstream and upstream FEC Elements. . . . . . 16 3.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 16 - 3.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 18 + 3.3.1. MP2MP Label Mapping . . . . . . . . . . . . . . . . . 18 3.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 21 3.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 22 4. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 22 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 22 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 23 5.2. LDP Messages containing LDP MP Status messages . . . . . . 24 5.2.1. LDP MP Status sent in LDP notification messages . . . 24 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 24 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 25 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 25 - 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 25 + 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 26 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 26 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 26 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 27 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 27 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 28 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 30 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 - 8.4.4. Receiving a Label Map with MBB status code . . . . . . 32 + 8.4.4. Receiving a Label Mapping with MBB status code . . . . 32 8.4.5. Receiving a Notification with MBB status code . . . . 32 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 33 9. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction The LDP protocol is described in [RFC5036]. It defines mechanisms - for setting up point-to-point (P2P) and multipoint-to-point (MP2P) + 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 + 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 + to a LDP neighbor 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. @@ -191,23 +191,30 @@ 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 + LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR. + CRC32: This contains a Cyclic Redundancy Check value of the + uncompressed data computed according to CRC-32 algorithm used in + the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T + recommendation V.42. (See http://www.iso.ch for ordering ISO + documents. See gopher://info.itu.ch for an online version of + ITU-T V.42.) + 2. Setting up P2MP LSPs with LDP A P2MP LSP consists of a single root node, zero or more transit nodes and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and tear-down. Leaf nodes also install forwarding state to deliver the traffic received on a P2MP LSP to wherever it needs to go; how this 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 @@ -222,43 +229,46 @@ 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 | + |S| Reserved | +-+-+-+-+-+-+-+-+ + S: As specified in [RFC5561] + The P2MP Capability TLV MUST be supported in the LDP Initialization Message. Advertisement of the P2MP Capability indicates support of the procedures for P2MP LSP setup detailed in this document. If the peer has not advertised the corresponding capability, then label messages using the P2MP FEC Element SHOULD NOT be sent to the peer. 2.2. The P2MP FEC Element For the setup of a P2MP LSP with LDP, we define one new protocol entity, the P2MP FEC Element to be used as a FEC Element in the FEC TLV. Note that the P2MP FEC Element does not necessarily identify the traffic that must be mapped to the LSP, so from that point of view, the use of the term FEC is a misnomer. The description of the P2MP FEC Element follows. The P2MP FEC Element consists of the address of the root of the P2MP LSP and an opaque value. The opaque value consists of one or more LDP MP Opaque Value Elements. The opaque value is unique within the - context of the root node. The combination of (Root Node Address, - Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. + context of the root node. The combination of (Root Node Address + type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP + within the MPLS network. The P2MP FEC Element is encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P2MP Type (TBD)| Address Family | Address Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Root Node Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -312,22 +322,22 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type < 255 | Length | Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: The Type of the LDP MP Opaque Value Element basic type is to - be assigned by IANA. + Type: The Type of the LDP MP Opaque Value Element. IANA maintains a + registry of basic types (see Section 11). Length: The length of the Value field, in octets. Value: String of Length octets, to be interpreted as specified by the Type field. The LDP MP Opaque Value Element extended type is encoded as follows: 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 @@ -337,22 +347,22 @@ | Length (low) | Value | +-+-+-+-+-+-+-+-+ | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = 255. - Extended Type: The Extended Type of the LDP MP Opaque Value Element - extended type is to be assigned by IANA. + Extended Type: The Extended Type of the LDP MP Opaque Value Element. + IANA maintains a registry of extended types (see Section 11). Length: The length of the Value field, in octets. Value: String of Length octets, to be interpreted as specified by the Type field. 2.3.1. The Generic LSP Identifier The generic LSP identifier is a type of Opaque Value Element basic type encoded as follows: @@ -369,154 +379,160 @@ 2.4. Using the P2MP FEC Element This section defines the rules for the processing and propagation of the P2MP FEC Element. The following notation is used in the processing rules: 1. P2MP FEC Element : a FEC Element with Root Node Address X and Opaque Value Y. - 2. P2MP Label Map : a Label Map message with a FEC TLV with - a single P2MP FEC Element and Label TLV with label L. - Label L MUST be allocated from the per-platform label space (see - [RFC3031] section 3.14) of the LSR sending the Label Map Message. + 2. P2MP Label Mapping : a Label Mapping message with a FEC + TLV with a single P2MP FEC Element and Label TLV with + label L. Label L MUST be allocated from the per-platform label + space (see [RFC3031] section 3.14) of the LSR sending the Label + Mapping Message. The use of the interface label space is outside + the scope of this document. 3. P2MP Label Withdraw : a Label Withdraw message with a FEC TLV with a single P2MP FEC Element and Label TLV with label L. 4. P2MP LSP (or simply ): a P2MP LSP with Root Node Address X and Opaque Value Y. 5. The notation L' -> { ..., } on LSR X means that on receiving a packet with label L', X makes n copies of the packet. For copy i of the packet, X swaps L' with Li and sends it out over interface Ii. The procedures below are organized by the role which the node plays in the P2MP LSP. Node Z knows that it is a leaf node by a discovery process which is outside the scope of this document. During the course of protocol operation, the root node recognizes its role because it owns the Root Node Address. A transit node is any node - (other than the root node) that receives a P2MP Label Map message + (other than the root node) that receives a P2MP Label Mapping message (i.e., one that has leaf nodes downstream of it). Note that a transit node (and indeed the root node) may also be a leaf node. -2.4.1. Label Map +2.4.1. Label Mapping - 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 + The remainder of This section specifies the procedures for + originating P2MP Label Mapping messages and for processing received + P2MP Label Mapping 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 [RFC5332] 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 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 + When there are several candidate upstream LSRs, the LSR MUST select one upstream LSR. The algorithm used for the LSR selection is a local matter. If the LSR selection is done over a LAN interface and the Section 6 procedures are applied, the following procedure SHOULD be applied to ensure that the same upstream LSR is elected among a set of candidate receivers on that LAN. 1. The candidate upstream LSRs are numbered from lower to higher IP address - 2. The following hash is performed: H = (CRC32(Opaque value)) modulo - N, where N is the number of upstream LSRs. + 2. The following hash is performed: H = (CRC32(Opaque Value)) modulo + N, where N is the number of upstream LSRs. The 'Opaque Value' is + the field identified in the FEC Element right after 'Opaque + Length'. The 'Opaque Length' indicates the size of the Opaque + Value used in this calculation. 3. The selected upstream LSR U is the LSR that has the number H. This procedure will ensure that there is a single forwarder over the LAN for a particular LSP. 2.4.1.2. Determining the forwarding interface to an LSR - Suppose LSR U receives a MP Label Map message from a downstream LSR - D, specifying label L. Suppose further that U is connected to D over - several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U - needs to transmit to D a data packet whose top label is L, U is free - to transmit the packet on any of those interfaces. The algorithm it - uses to choose a particular interface and next-hop for a particular - such packet is a local matter. For completeness the following - procedure MAY be used. LSR U may do a lookup in the unicast routing - table to find the best interface and next-hop to reach LSR D. If the - next-hop and interface are also advertised by LSR D via the LDP - session it can be used to transmit the packet to LSR D. + Suppose LSR U receives a MP Label Mapping message from a downstream + LSR D, specifying label L. Suppose further that U is connected to D + over several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If + U needs to transmit to D a data packet whose top label is L, U is + free to transmit the packet on any of those interfaces. The + algorithm it uses to choose a particular interface and next-hop for a + particular such packet is a local matter. For completeness the + following procedure MAY be used. LSR U may do a lookup in the + unicast routing table to find the best interface and next-hop to + reach LSR D. If the next-hop and interface are also advertised by LSR + D via the LDP session it can be used to transmit the packet to LSR D. 2.4.1.3. 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. + Label Mapping to U. 2.4.1.4. Transit Node operation - Suppose a transit node Z receives a P2MP Label Map from LSR - T. Z checks whether it already has state for . If not, Z + Suppose a transit node Z receives a P2MP Label Mapping 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. Interface I is determind via the procedures in - Section 2.4.1.2. + Using this Label Mapping 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 + Mapping to LSR U. Interface I is determind via the + procedures in Section 2.4.1.2. - 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'-> { ..., , }. 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. + If Z already has state for , then Z does not send a Label + Mapping message for P2MP LSP . If LSR T is not equal to the + upstream LSR of and does not already exist as + forwarding state, the forwarding state updated. Assuming its old + forwarding state was L'-> { ..., }, its new + forwarding state becomes L'-> { ..., , }. If the LSR T is equal to the installed upstream LSR, the Label + Mapping from LSR T MUST be retained and MUST NOT update the label + forwarding table. 2.4.1.5. Root Node Operation - 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). + Suppose the root node Z receives a P2MP Label Mapping 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 LSR T and determined via the procedures in Section 2.4.1.2. 2.4.2. Label Withdraw The following section 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 - If a leaf node Z discovers (by means outside the scope of this - document) that it has no downstream neighbors in that LSP, and that - it has no need to be an egress LSR for that LSP, then it SHOULD send - a Label Withdraw to its upstream LSR U for , where L - is the label it had previously advertised to U for . + If a leaf node Z discovers that it has no downstream neighbors in + that LSP, and that it has no need to be an egress LSR for that LSP + (by means outside the scope of this document), then it SHOULD send a + Label Withdraw to its upstream LSR U for , where L is + the label it had previously advertised to U for . 2.4.2.2. Transit Node Operation If a transit node Z receives a Label Withdraw message from a node W, it deletes label L from its forwarding state, and sends a Label Release message with label L to W. If deleting L from Z's forwarding state for P2MP LSP results in no state remaining for , then Z propagates the Label Withdraw for , to its upstream T, by sending a Label Withdraw @@ -533,23 +549,24 @@ 2.4.3. Upstream LSR change 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. Z MUST update its forwarding state as follows. It allocates a new label, L', for . The forwarding state for L' is copied from the forwarding state for L, with one exception: if U' was present in the forwarding state of L, it MUST NOT be installed in the forwarding state of L'. Then the forwarding state for L is deleted and the forwarding state for L' is installed. 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.4 it can now be installed. + Label Mapping 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.4 it can now be + installed. While changing the upstream LSR the following must be taken into consideration. If L' is added before L is removed, there is a potential risk of packet duplication, and/or the creation of a transient dataplane forwarding loop. If L is removed before L' is added, packet loss may result. Ideally the change from L to L' is done atomically such that no packet loss or duplication occurs. If that is not possible, the RECOMMENDED default behavior is to remove L before adding L'. @@ -588,23 +605,25 @@ 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 | + |S| Reserved | +-+-+-+-+-+-+-+-+ + S: As specified in [RFC5561] + The MP2MP Capability TLV MUST be supported in the LDP Initialization Message. Advertisement of the MP2MP Capability indicates support of the procedures for MP2MP LSP setup detailed in this document. If the peer has not advertised the corresponding capability, then label messages using the MP2MP upstream and downstream FEC Elements SHOULD NOT be sent to the peer. 3.2. The MP2MP downstream and upstream FEC Elements. For the setup of a MP2MP LSP with LDP we define 2 new protocol @@ -640,31 +659,33 @@ MP2MP LSP upstream path for downstream node D with root node address X and opaque value Y. 3. MP2MP downstream FEC Element : a FEC Element with root node address X and opaque value Y used for a downstream MP2MP LSP. 4. MP2MP upstream FEC Element : a FEC Element with root node address X and opaque value Y used for an upstream MP2MP LSP. - 5. MP2MP-D Label Map : A Label Map message with a FEC TLV - with a single MP2MP downstream FEC Element and label TLV - with label L. Label L MUST be allocated from the per-platform - label space (see [RFC3031] section 3.14) of the LSR sending the - Label Map Message. + 5. MP2MP-D Label Mapping : A Label Mapping message with a + FEC TLV with a single MP2MP downstream FEC Element and + label TLV with label L. Label L MUST be allocated from the per- + platform label space (see [RFC3031] section 3.14) of the LSR + sending the Label Mapping Message. The use of the interface + label space is outside the scope of this document. - 6. MP2MP-U Label Map : A Label Map message with a FEC TLV - with a single MP2MP upstream FEC Element and label TLV - with label Lu. Label Lu MUST be allocated from the per-platform - label space (see [RFC3031] section 3.14) of the LSR sending the - Label Map Message. + 6. MP2MP-U Label Mapping : A Label Mapping message with a + FEC TLV with a single MP2MP upstream FEC Element and + label TLV with label Lu. Label Lu MUST be allocated from the + per-platform label space (see [RFC3031] section 3.14) of the LSR + sending the Label Mapping Message. The use of the interface + label space is outside the scope of this document. 7. MP2MP-D Label Withdraw : a Label Withdraw message with a FEC TLV with a single MP2MP downstream FEC Element and label TLV with label L. 8. MP2MP-U Label Withdraw : a Label Withdraw message with a FEC TLV with a single MP2MP upstream FEC Element and label TLV with label Lu. 9. MP2MP-D Label Release : a Label Release message with a @@ -673,190 +694,190 @@ 10. MP2MP-U Label Release : a Label Release message with a FEC TLV with a single MP2MP upstream FEC Element and label TLV with label Lu. The procedures below are organized by the role which the node plays in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery process which is outside the scope of this document. During the course of the protocol operation, the root node recognizes its role because it owns the root node address. A transit node is any node - (other then the root node) that receives a MP2MP Label Map message - (i.e., one that has leaf nodes downstream of it). + (other then the root node) that receives a MP2MP Label Mapping + message (i.e., one that has leaf nodes downstream of it). Note that a transit node (and indeed the root node) may also be a leaf node and the root node does not have to be an ingress LSR or leaf of the MP2MP LSP. -3.3.1. MP2MP Label Map +3.3.1. MP2MP Label Mapping - 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 + The remainder of This section specifies the procedures for + originating MP2MP Label Mapping messages and for processing received + MP2MP Label Mapping 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 [RFC5332] except those which are assigned using the procedures of Section 6. 3.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. 3.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 + A LDP peer U which receives a MP2MP-D Label Mapping from a LDP peer D will treat D as downstream MP2MP LSR. 3.3.1.3. Installing the upstream path of a MP2MP LSP There are two methods for installing the upstream path of a MP2MP LSP to a downstream neighbor. 1. We can install the upstream MP2MP path (to a downstream neighbor) - based on receiving a MP2MP-D Label Map from the downstream + based on receiving a MP2MP-D Label Mapping from the downstream neighbor. This will install the upstream path on a per hop by hop basis. 2. We install the upstream MP2MP path (to a downstream neighbor) - based on receiving a MP2MP-U Label Map from the upstream - neighbor. An LSR does not need to wait for the MP2MP-U Label Map - if it is the root of the MP2MP LSP or already has received an - MP2MP-U Label Map from the upstream neighbor. We call this - method ordered mode. The typical result of this mode is that the - downstream path of the MP2MP is built hop by hop towards the - root. Once the root is reached, the root node will trigger a - MP2MP-U Label Map to the downstream neighbor(s). + based on receiving a MP2MP-U Label Mapping from the upstream + neighbor. An LSR does not need to wait for the MP2MP-U Label + Mapping if it is the root of the MP2MP LSP or already has + received an MP2MP-U Label Mapping from the upstream neighbor. We + call this method ordered mode. The typical result of this mode + is that the downstream path of the MP2MP is built hop by hop + towards the root. Once the root is reached, the root node will + trigger a MP2MP-U Label Mapping to the downstream neighbor(s). For setting up the upstream path of a MP2MP LSP ordered mode MUST be used. Due to ordered mode the upstream path of the MP2MP LSP is installed at the leaf node once the path to the root is completed. The advantage is that when a leaf starts sending immediately after the upstream path is installed, packets are able to reach the root node without being dropped due to an incomplete LSP. Method 1 is not able to guarantee that the upstream path is completed before the leaf starts sending. 3.3.1.4. MP2MP leaf node operation A leaf node Z of a MP2MP LSP determines its upstream LSR U for as per Section 3.3.1.1, allocates a label L, and sends a - MP2MP-D Label Map to U. + MP2MP-D Label Mapping to U. - Leaf node Z expects an MP2MP-U Label Map from node U in - 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 + Leaf node Z expects an MP2MP-U Label Mapping from node U + in response to the MP2MP-D Label Mapping 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. 3.3.1.5. MP2MP transit node operation - Suppose node Z receives a MP2MP-D Label Map from LSR D. Z - checks whether it has forwarding state for downstream . If + Suppose node Z receives a MP2MP-D Label Mapping from LSR D. + Z checks whether it has forwarding state for downstream . If not, Z determines its upstream LSR U for as per - Section 3.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 associated with LSR D and send a MP2MP-D Label Map to U. Interface I is determined via the procedures in - Section 2.4.1.2. + Section 3.3.1.1. Using this Label Mapping 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 associated with LSR D and send a MP2MP-D Label + Mapping to U. Interface I is determined via the procedures + in Section 2.4.1.2. 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. + Label Mapping from LSR D MUST be retained and MUST NOT update the + label forwarding table. Node Z checks if upstream LSR U already assigned a label Lu to . If not, transit node Z waits until it receives a MP2MP-U Label - Map from LSR U. See Section 3.3.1.3. Once the MP2MP-U - Label Map is received from LSR U, node Z checks whether it already - has forwarding state upstream . If it does, then no further - action needs to happen. If it does not, it allocates a label Lu' and - creates a new label swap for Lu' with Label Lu over interface Iu. - Interface Iu is determined via the procedures in Section 2.4.1.2. In - addition, it also adds the label swap(s) from the forwarding state - downstream , omitting the swap on interface I for node D. The - swap on interface I for node D is omitted to prevent packet - originated by D to be forwarded back to D. + Mapping from LSR U. See Section 3.3.1.3. Once the MP2MP-U + Label Mapping is received from LSR U, node Z checks whether it + already has forwarding state upstream . If it does, then no + further action needs to happen. If it does not, it allocates a label + Lu' and creates a new label swap for Lu' with Label Lu over interface + Iu. Interface Iu is determined via the procedures in + Section 2.4.1.2. In addition, it also adds the label swap(s) from + the forwarding state downstream , omitting the swap on + interface I for node D. The swap on interface I for node D is omitted + to prevent packet originated by D to be forwarded back to D. Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2, - and sends a MP2MP-U Label Map to node D. + and sends a MP2MP-U Label Mapping to node D. 3.3.1.6. MP2MP root node operation 3.3.1.6.1. Root node is also a leaf - Suppose root/leaf node Z receives a MP2MP-D Label Map from - node D. Z checks whether it already has forwarding state downstream - . If not, Z creates forwarding state for downstream to push - label L on traffic that Z wants to forward down the MP2MP LSP. How - it determines what traffic to forward on this MP2MP LSP is outside - the scope of this document. If Z already has forwarding state for - downstream , then Z will add the label push for L over - interface I to it. Interface I is determined via the procedures in - Section 2.4.1.2. + Suppose root/leaf node Z receives a MP2MP-D Label Mapping + from node D. Z checks whether it already has forwarding state + downstream . If not, Z creates forwarding state for downstream + to push label L on traffic that Z wants to forward down the MP2MP + LSP. How it determines what traffic to forward on this MP2MP LSP is + outside the scope of this document. If Z already has forwarding + state for downstream , then Z will add the label push for L + over interface I to it. Interface I is determined via the procedures + in Section 2.4.1.2. Node Z checks if it has forwarding state for upstream If not, Z allocates a label Lu' and creates upstream forwarding state to swap Lu' with the label swap(s) from the forwarding state downstream , except the swap on interface I for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node from which the traffic was received. Node Z determines the downstream MP2MP LSR as per section Section 3.3.1.2, and sends a - MP2MP-U Label Map to node D. Since Z is the root of the - tree Z will not send a MP2MP-D Label Map and will not receive a - MP2MP-U Label Map. + MP2MP-U Label Mapping to node D. Since Z is the root of + the tree Z will not send a MP2MP-D Label Mapping and will not receive + a MP2MP-U Label Mapping. 3.3.1.6.2. Root node is not a leaf - Suppose the root node Z receives a MP2MP-D Label Map from - node D. Z checks whether it already has forwarding state for + Suppose the root node Z receives a MP2MP-D Label Mapping + from node D. Z checks whether it already has forwarding state for downstream . If not, Z creates downstream forwarding state and installs a outgoing label L over interface I. Interface I is determined via the procedures in Section 2.4.1.2. If Z already has forwarding state for downstream , then Z will add label L over interface I to the existing state. Node Z checks if it has forwarding state for upstream . If not, Z allocates a label Lu' and creates forwarding state to swap Lu' with the label swap(s) from the forwarding state downstream , except the swap for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node is was received from. Root node Z determines the downstream MP2MP LSR D as per - Section 3.3.1.2, and sends a MP2MP-U Label Map to it. - Since Z is the root of the tree Z will not send a MP2MP-D Label Map - and will not receive a MP2MP-U Label Map. + Section 3.3.1.2, and sends a MP2MP-U Label Mapping to it. + Since Z is the root of the tree Z will not send a MP2MP-D Label + Mapping and will not receive a MP2MP-U Label Mapping. 3.3.2. MP2MP Label Withdraw The following section lists procedures for generating and processing MP2MP Label Withdraw messages for nodes that participate in a MP2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the MP2MP LSP. 3.3.2.1. MP2MP leaf operation If a leaf node Z discovers (by means outside the scope of this document) that it has no downstream neighbors in that LSP, and that - it has no need to be an egress LSR for that LSP, then it SHOULD send - a MP2MP-D Label Withdraw to its upstream LSR U for , - where L is the label it had previously advertised to U for . - Leaf node Z will also send a unsolicited label release to - U to indicate that the upstream path is no longer used and that Label - Lu can be removed. + it has no need to be an egress LSR for that LSP (by means outside the + scope of this document), then it SHOULD send a MP2MP-D Label Withdraw + to its upstream LSR U for , where L is the label it + had previously advertised to U for . Leaf node Z will also send + a unsolicited label release to U to indicate that the + upstream path is no longer used and that Label Lu can be removed. Leaf node Z expects the upstream router U to respond by sending a downstream label release for L. 3.3.2.2. MP2MP transit node operation If a transit node Z receives a MP2MP-D Label Withdraw message from node D, it deletes label L from its forwarding state downstream and from all its upstream states for . Node Z sends a MP2MP-D Label Release message with label L to D. Since node @@ -895,21 +916,21 @@ able to prevent this inconsistency by never allowing an upstream LDP neighbor to be added as a downstream LDP neighbor into the Label Forwarding Table (LFT) for the same FEC. Micro-loops that involve more than 2 LSRs are not prevented. Micro-loops that involve more than 2 LSRs may create a micro-loop in the downstream path of either a MP2MP LSP or P2MP LSP and the upstream path of the MP2MP LSP. The loops are transient and will disappear as soon as the unicast routing protocol converges. Micro- loops that occur in the upstream path of a MP2MP LSP may be detected - by including LDP path vector in the MP2MP-U Label Map messages. + by including LDP path vector in the MP2MP-U Label Mapping messages. These procedures are currently under investigation and are subjected to further study. 5. The LDP MP Status TLV An LDP MP capable router MAY use an LDP MP Status TLV to indicate additional status for a MP LSP to its remote peers. This includes signaling to peers that are either upstream or downstream of the LDP MP capable router. The value of the LDP MP status TLV will remain opaque to LDP and MAY encode one or more status elements. @@ -934,47 +955,48 @@ Value: One or more LDP MP Status Value elements. 5.1. The LDP MP Status Value Element The LDP MP Status Value Element that is included in the LDP MP Status TLV Value has the following encoding. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type(TBD) | Length | Value ... | + | Type | Length | Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: The type of the LDP MP Status Value Element is to be assigned - by IANA. + Type: The type of the LDP MP Status Value Element. IANA maintains a + registry of status value types (see Section 11). Length: The length of the Value field, in octets. Value: String of Length octets, to be interpreted as specified by the Type field. 5.2. LDP Messages containing LDP MP Status messages - The LDP MP status message may appear either in a label mapping - message or a LDP notification message. + The LDP MP Status TLV may appear either in a Label Mapping message or + a LDP Notification message. 5.2.1. LDP MP Status sent in LDP notification messages An LDP MP status TLV sent in a notification message must be - accompanied with a Status TLV. The general format of the - Notification Message with an LDP MP status TLV is: + accompanied with a Status TLV, as described in [RFC5036]. The + general format of the Notification Message with an LDP MP status TLV + is: 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| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1040,23 +1062,22 @@ 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 - [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is - sent to the upstream LSR. The label mapping that is received from + sent 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 in 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 @@ -1245,25 +1266,27 @@ An LSR MAY advertise that it is capable of handling MBB LSPs using the capability advertisement as defined in [RFC5561]. 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 | + |S| Reserved | +-+-+-+-+-+-+-+-+ Note: LDP MP MBB Capability (Pending IANA assignment) + S: As specified in [RFC5561] + 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 8.4). If this happens an MBB MP LSP will not be established, but normal a MP LSP will be the result. 8.4. The MBB procedures @@ -1286,23 +1309,23 @@ 4. F(N, L): A Forwarding state that consists of downstream Neighbor N and Label L. This LSR is sending label packets with label L to neighbor N for a specific FEC. 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. + 7. MBB Label Mapping : A P2MP Label Mapping or MP2MP Label + Mapping downstream with a FEC element , Label L and MBB + Status code 1. 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 @@ -1315,22 +1338,22 @@ 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 . 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 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). While waiting for the MBB Notification from upstream LSR N2, it is possible that another 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 @@ -1339,28 +1362,28 @@ 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 8.4.5 are applied as if a MBB Notification was received for the inactive element. If a downstream LSR detects that the old upstream LSR went down while waiting for the MBB Notification from the new upstream LSR, the downstream LSR can immediately proceed without waiting for the timer to expire. -8.4.4. Receiving a Label Map with MBB status code +8.4.4. Receiving a Label Mapping 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 sent to node N2. If node Z has an - inactive accepting element it marks the Forwarding state as 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 sent to node N2. If node Z has + an inactive accepting element it marks the Forwarding state as . If router Z upstream LSR for happens to be N2, then Z MUST NOT send an MBB notification to N2 at once. Sending the MBB notification to N2 must be done only after Z upstream for stops being N2. 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 @@ -1385,39 +1408,49 @@ element, the upstream path is installed when this inactive accepting element is activated. 9. Typed Wildcard for mLDP FEC Element The format of the mLDP FEC Typed Wildcard FEC is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Typed Wcard | Type = mLDP | Len = 2 | AFI ~ + | Typed Wcard | Type | Len = 2 | AFI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | +-+-+-+-+-+-+-+-+ Type Wcard: As specified in [RFC5918] - Type: mLDP FEC Element Type as documented in this draft. + Type: The type of FEC Element Type. Either the P2MP FEC Element or + the MP2MP FEC Element using the values defined for those FEC + Elements when carried in the FEC TLV as defined in this document. Len: Len FEC Type Info, two octets (=0x02). AFI: Address Family, two octet quantity containing a value from IANA's "Address Family Numbers" registry. 10. Security Considerations The same security considerations apply as for the base LDP specification, as described in [RFC5036]. + The protocol specified in this document does not provide any + authorization mechanism for controlling the set of LSRs that may join + a given MP LSP. If such authorization is desirable, additional + mechanisms, outside the scope of this document, are needed. Note + that authorization policies cannot be implemented and/or configure + solely at the root node of the LSP, because the root node does not + learn the identities of all the leaf nodes. + 11. IANA Considerations This document creates three new registries to be managed by IANA. 1. "LDP MP Opaque Value Element basic type" The range is 0-255, with the following values allocated in this document: 1: Generic LSP identifier @@ -1438,20 +1471,23 @@ 3. "LDP MP Status Value Element type" The range is 0-255, with the following value allocated in this document: 1: MBB Status The allocation policy for this space is 'Standards Action with Early Allocation' + The requested code point values listed below have been allocated by + IANA through early allocation. + This document requires allocation of three new code points from the IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type Name Space". The values are: P2MP FEC type - requested value 0x06 MP2MP-up FEC type - requested value 0x07 MP2MP-down FEC type - requested value 0x08 @@ -1582,43 +1620,45 @@ [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009. [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010. 14.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] Morin, T., "Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol", draft-ietf-mpls-mp-ldp-reqs-06 (work in progress), December 2010. [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-10 (work in progress), January 2010. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. + [ITU.V42.1994] + International Telecommunications Union, "Error-correcting + Procedures for DCEs Using Asynchronous-to-Synchronous + Conversion", ITU-T Recommendation V.42, 1994. + Authors' Addresses Ina Minei (editor) Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: ina@juniper.net @@ -1622,25 +1662,25 @@ Email: ina@juniper.net IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com + Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: kireeti@juniper.net Bob Thomas - Cisco Systems, Inc. 300 Beaver Brook Road Boxborough 01719 US Email: bobthomas@alum.mit.edu