--- 1/draft-ietf-mpls-ldp-p2mp-10.txt 2010-10-08 18:12:10.000000000 +0200 +++ 2/draft-ietf-mpls-ldp-p2mp-11.txt 2010-10-08 18:12:10.000000000 +0200 @@ -1,22 +1,22 @@ Network Working Group I. Minei (Editor) Internet-Draft K. Kompella Intended status: Standards Track Juniper Networks -Expires: January 12, 2011 I. Wijnands (Editor) +Expires: April 11, 2011 I. Wijnands (Editor) B. Thomas Cisco Systems, Inc. - July 11, 2010 + October 8, 2010 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths - draft-ietf-mpls-ldp-p2mp-10 + draft-ietf-mpls-ldp-p2mp-11 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 mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this @@ -40,21 +40,21 @@ 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 January 12, 2011. + This Internet-Draft will expire on April 11, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -81,63 +81,63 @@ 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.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12 - 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 14 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16 - 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 19 - 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 20 - 5. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 20 + 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20 + 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21 + 5. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 21 6. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 6.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 - 6.2. LDP Messages containing LDP MP Status messages . . . . . . 22 - 6.2.1. LDP MP Status sent in LDP notification messages . . . 22 + 6.2. LDP Messages containing LDP MP Status messages . . . . . . 23 + 6.2.1. LDP MP Status sent in LDP notification messages . . . 23 6.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 7. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 7.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 - 7.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 - 7.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 + 7.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 25 + 7.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 25 8. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 - 8.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 + 8.1. Root node redundancy - procedures for P2MP LSPs . . . . . 26 8.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 - 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 + 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 - 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 - 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 - 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 + 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29 + 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 + 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 - 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 + 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 9.4.4. Receiving a Label Map with MBB status code . . . . . . 31 - 9.4.5. Receiving a Notification with MBB status code . . . . 31 - 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 + 9.4.5. Receiving a Notification with MBB status code . . . . 32 + 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32 10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 - 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 - 14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 15.1. Normative References . . . . . . . . . . . . . . . . . . . 35 - 15.2. Informative References . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 + 14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 36 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction The LDP protocol is described in [RFC5036]. It defines mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document describes extensions to LDP for setting up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs. These are collectively referred to as multipoint LSPs (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) node to be delivered to a number of leaf (or egress) nodes. A MP2MP @@ -398,45 +398,50 @@ 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 - one upstream LSR using the following procedure: + 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 7 procedures are applied, the following procedure SHOULD + be applied to ensure that the same upstream LSR is elected amoung 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. 3. The selected upstream LSR U is the LSR that has the number H. - This allows for load balancing of a set of LSPs among a set of - candidate upstream LSRs, while ensuring that on a LAN interface a - single upstream LSR is selected. + 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. LSR U is able to - discover the directly connected interfaces via the LDP Discovery - messages exchanged between the LSR U and D. The algorithm it uses to - choose a particular interface for a particular such packet is a local - matter. + 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. 2.4.1.4. Transit Node operation Suppose a transit node Z receives a P2MP Label Map from LSR @@ -461,21 +466,21 @@ 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). 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 determind via the procedures in + associated with LSR T and determined via the procedures in Section 2.4.1.2. 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 @@ -505,26 +510,24 @@ would not propagate the Label Withdraw upstream (as it has no upstream). 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. 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.4 it can now be installed. + forwarding state for L'. 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. 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, @@ -760,80 +762,80 @@ 4.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 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 associated with LSR D and send a MP2MP-D Label Map to U. Interface I is determind via the procedures in + L'> 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. 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 4.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 determind via the procedures in Section 2.4.1.2. In + 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 4.3.1.2, and sends a MP2MP-U Label Map to node D. 4.3.1.6. MP2MP root node operation 4.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 determind via the procedures in + 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 - push Lu' with the label push(s) from the forwarding state downstream - , except the push on interface I for node D. This allows + 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 4.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. 4.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 downstream . If not, Z creates downstream forwarding state and installs a outgoing label L over interface I. Interface I is - determind via the procedures in Section 2.4.1.2. If Z already has + 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 4.3.1.2, and sends a MP2MP-U Label Map to it. @@ -894,24 +896,24 @@ 5. Micro-loops in MP LSPs Micro-loops created by the unicast routing protocol during convergence may also effect mLDP MP LSPs. Since the tree building logic in mLDP is based on unicast routing, a unicast routing loop may also result in a micro-loop in the MP LSPs. Micro-loops that involve 2 directly connected routers don't create a loop in mLDP. mLDP is able to prevent this inconsistency by never allowing an upstream LDP neighbor to be added as a downstream LDP neighbor into the LFT for - the same FEC. Micro-loops that involve more then 2 LSRs are not + the same FEC. Micro-loops that involve more than 2 LSRs are not prevented. - Micro-loops that involve more then 2 LSRs may create a micro-loop in + 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. These procedures are currently under investigation and are subjected to further study. 6. The LDP MP Status TLV @@ -1021,21 +1023,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional LDP MP Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. 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 + there is more than 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 [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute upstream labels using LDP is documented in [I-D.ietf-mpls-ldp-upstream]. 7.1. LDP Multipoint-to-Multipoint on a LAN The procedure to allocate a context label on a LAN is defined in @@ -1166,72 +1168,75 @@ duration of packet loss as short as possible. In addition, there are scenarios where the best path from the LSR to the root changes but the LSP continues to forward packets to the prevous next hop to the root. That may occur when a link comes up or routing metrics change. In such a case a new LSP should be established before the old LSP is removed to limit the duration of packet loss. The procedures described below deal with both scenarios in a way that an LSR does not need to know which of the events described above caused its upstream router for an MBB LSP to change. - This MBB procedures are an optional extension to the MP LSP building - procedures described in this draft. + The MBB procedures are an optional extension to the MP LSP building + procedures described in this draft. The procedures in this section + offer a make-before-break behavior, except in cases where the new + path is part of a transient routing loop involving more than 2 LSRs + (also see Section 5). 9.1. MBB overview - The MBB procedues use additional LDP signaling. + The MBB procedures use additional LDP signaling. Suppose some event causes a downstream LSR-D to select a new upstream LSR-U for FEC-A. The new LSR-U may already be forwarding packets for - FEC-A; that is, to downstream LSR's other than LSR-D. After LSR-U + FEC-A; that is, to downstream LSRs other than LSR-D. After LSR-U receives a label for FEC-A from LSR-D, it will notify LSR-D when it knows that the LSP for FEC-A has been established from the root to itself. When LSR-D receives this MBB notification it will change its next hop for the LSP root to LSR-U. The assumption is that if LSR-U has received an MBB notification from its upstream router for the FEC-A LSP and has installed forwarding state the LSP it is capable of forwarding packets on the LSP. At that point LSR-U should signal LSR-D by means of an MBB notification that it has become part of the tree identified by FEC-A and that LSR-D should initiate its switchover to the LSP. At LSR-U the LSP for FEC-A may be in 1 of 3 states. 1. There is no state for FEC-A. 2. State for FEC-A exists and LSR-U is waiting for MBB notification that the LSP from the root to it exists. - 3. State for FEC-A exists and the MBB notification has been - received. + 3. State for FEC-A exists and the MBB notification has been received + or it is the Root node for FEC-A. After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U MUST NOT reply with an MBB notification to LSR-D until its state for the LSP is state #3 above. If the state of the LSP at LSR-U is state #1 or #2, LSR-U should remember receipt of the Label Mapping message from LSR-D while waiting for an MBB notification from its upstream - LSR for the LSP. When LSR-U receives the MBB notification from its - upstream LSR it transitions to LSP state #3 and sends an MBB - notification to LSR-D. + LSR for the LSP. When LSR-U receives the MBB notification from LSR-U + it transitions to LSP state #3 and sends an MBB notification to + LSR-D. 9.2. The MBB Status code As noted in Section 9.1, the procedures to establish an MBB MP LSP are different from those to establish normal MP LSPs. When a downstream LSR sends a Label Mapping message for MP LSP to its upstream LSR it MAY include an LDP MP Status TLV that carries a MBB Status Code to indicate MBB procedures apply to the LSP. This new MBB Status Code MAY also appear in an LDP Notification message used by an upstream LSR to signal LSP state #3 to the downstream LSR; that - is, that the upstream LSR's state for the LSP exists and that it has + is, that the upstream LSRs state for the LSP exists and that it has received notification from its upstream LSR that the LSP is in state #3. The MBB Status is a type of the LDP MP Status Value Element as described in Section 6.1. It 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBB Type = 1 | Length = 1 | Status code | @@ -1347,31 +1352,37 @@ is created and the old inactive element iA(N2, L2) MUST be removed. A label withdraw MUST be sent to N2 for from N2 will be ignored because the inactive element is removed. It is possible that the MBB Notification from upstream LSR is never received due to link or node failure. To prevent waiting indefinitely for the MBB Notification a timeout SHOULD be applied. As soon as the timer expires, the procedures in Section 9.4.5 are applied as if a MBB Notification was received for the inactive - element. + 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. 9.4.4. Receiving a Label Map with MBB status code Suppose node Z has state for a MBB LSP and receives a MBB Label Map from N2. A new forwarding state F(N2, L2) will be added to the MP LSP if it did not already exist. If this MBB LSP has an active accepting element or node Z is the root of the MBB LSP a MBB notification is send to node N2. If node Z has an inactive accepting element it marks the Forwarding state as . + F'(N2, L2)>. 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. 9.4.5. Receiving a Notification with MBB status code Suppose node Z receives a MBB Notification from N. If node Z has state for MBB LSP and an inactive accepting element iA(N, L) that matches with N and L, we activate this accepting element and install label L in the label forwarding database. If an other active accepting was present it will be removed from the label forwarding database.