draft-ietf-mpls-ldp-p2mp-15.txt   rfc6388.txt 
Network Working Group I. Minei, Ed. Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Internet-Draft Juniper Networks Request for Comments: 6388 Cisco Systems, Inc.
Intended status: Standards Track IJ. Wijnands, Ed. Category: Standards Track I. Minei, Ed.
Expires: February 5, 2012 Cisco Systems, Inc. ISSN: 2070-1721 K. Kompella
K. Kompella
Juniper Networks Juniper Networks
B. Thomas B. Thomas
August 4, 2011 November 2011
Label Distribution Protocol Extensions for Point-to-Multipoint and Label Distribution Protocol Extensions for
Multipoint-to-Multipoint Label Switched Paths Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-ldp-p2mp-15
Abstract Abstract
This document describes extensions to the Label Distribution Protocol This document describes extensions to the Label Distribution Protocol
for the setup of Point-to-Multipoint and Multipoint-to-Multipoint (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-
Label Switched Paths in Multi-Protocol Label Switching networks. multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.
These extensions are also referred to as Multipoint LDP. Multipoint These extensions are also referred to as multipoint LDP. Multipoint
LDP constructs the P2MP or MP2MP Label Switched Paths without LDP constructs the P2MP or MP2MP LSPs without interacting with or
interacting with or relying upon any other multicast tree relying upon any other multicast tree construction protocol.
construction protocol. Protocol elements and procedures for this Protocol elements and procedures for this solution are described for
solution are described for building such Label Switched Paths in a building such LSPs in a receiver-initiated manner. There can be
receiver-initiated manner. There can be various applications for various applications for multipoint LSPs, for example IP multicast or
Multipoint Label Switched Paths, for example IP multicast or support support for multicast in BGP/MPLS Layer 3 Virtual Private Networks
for multicast in BGP/MPLS L3VPNs. Specification of how such (L3VPNs). Specification of how such applications can use an LDP
applications can use a LDP signaled Multipoint Label Switched Path is signaled multipoint LSP is outside the scope of this document.
outside the scope of this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 5, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6388.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................3
1.1. Conventions used in this document . . . . . . . . . . . . 5 1.1. Conventions Used in This Document ..........................4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology ................................................4
2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6 1.3. Manageability ..............................................5
2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7 2. Setting Up P2MP LSPs with LDP ...................................6
2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7 2.1. Support for P2MP LSP Setup with LDP ........................6
2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9 2.2. The P2MP FEC Element .......................................6
2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 10 2.3. The LDP MP Opaque Value Element ............................8
2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 11 2.3.1. The Generic LSP Identifier ..........................9
2.4.1. Label Mapping . . . . . . . . . . . . . . . . . . . . 11 2.4. Using the P2MP FEC Element .................................9
2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 13 2.4.1. Label Mapping ......................................10
2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 14 2.4.2. Label Withdraw .....................................12
3. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 15 2.4.3. Upstream LSR Change ................................13
3.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 15 3. Setting up MP2MP LSPs with LDP .................................14
3.2. The MP2MP downstream and upstream FEC Elements. . . . . . 16 3.1. Support for MP2MP LSP Setup with LDP ......................14
3.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 16 3.2. The MP2MP Downstream and Upstream FEC Elements ............15
3.3.1. MP2MP Label Mapping . . . . . . . . . . . . . . . . . 18 3.3. Using the MP2MP FEC Elements ..............................15
3.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 21 3.3.1. MP2MP Label Mapping ................................17
3.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 22 3.3.2. MP2MP Label Withdraw ...............................20
4. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 22 3.3.3. MP2MP Upstream LSR Change ..........................21
5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 22 4. Micro-Loops in MP LSPs .........................................21
5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 23 5. The LDP MP Status TLV ..........................................21
5.2. LDP Messages containing LDP MP Status messages . . . . . . 24 5.1. The LDP MP Status Value Element ...........................22
5.2.1. LDP MP Status sent in LDP notification messages . . . 24 5.2. LDP Messages Containing LDP MP Status Messages ............22
5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 24 5.2.1. LDP MP Status Sent in LDP Notification Messages ....23
6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 25 5.2.2. LDP MP Status TLV in Label Mapping Message .........24
6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 25 6. Upstream Label Allocation on a LAN .............................24
6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 26 6.1. LDP Multipoint-to-Multipoint on a LAN .....................24
6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 26 6.1.1. MP2MP Downstream Forwarding ........................25
7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 26 6.1.2. MP2MP Upstream Forwarding ..........................25
7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 27 7. Root Node Redundancy ...........................................25
7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 27 7.1. Root Node Redundancy - Procedures for P2MP LSPs ...........26
8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 28 7.2. Root Node Redundancy - Procedures for MP2MP LSPs ..........26
8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28 8. Make Before Break (MBB) ........................................27
8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29 8.1. MBB Overview .............................................27
8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 30 8.2. The MBB Status Code .......................................28
8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 8.3. The MBB Capability ........................................29
8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 8.4. The MBB Procedures ........................................29
8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31 8.4.1. Terminology ........................................29
8.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 8.4.2. Accepting Elements .................................30
8.4.4. Receiving a Label Mapping with MBB status code . . . . 32 8.4.3. Procedures for Upstream LSR Change .................30
8.4.5. Receiving a Notification with MBB status code . . . . 32 8.4.4. Receiving a Label Mapping with MBB Status Code .....31
8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 33 8.4.5. Receiving a Notification with MBB Status Code ......31
9. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 33 8.4.6. Node Operation for MP2MP LSPs ......................32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Typed Wildcard for mLDP FEC Element ............................32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations .......................................32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations ...........................................33
13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 35 12. Acknowledgments ...............................................34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 13. Contributing Authors ..........................................35
14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 14. References ....................................................37
14.2. Informative References . . . . . . . . . . . . . . . . . . 38 14.1. Normative References .....................................37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 14.2. Informative References ...................................37
1. Introduction 1. Introduction
The LDP protocol is described in [RFC5036]. It defines mechanisms 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 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 (MP2MP) LSPs. These are collectively referred to as multipoint LSPs
(MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) (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 node to be delivered to a number of leaf (or egress) nodes. An MP2MP
LSP allows traffic from multiple ingress nodes to be delivered to LSP allows traffic from multiple ingress nodes to be delivered to
multiple egress nodes. Only a single copy of the packet will be sent multiple egress nodes. Only a single copy of the packet will be sent
to a LDP neighbor traversed by the MP LSP (see note at end of to an LDP neighbor traversed by the MP LSP. This is accomplished
Section 2.4.1). This is accomplished without the use of a multicast without the use of a multicast protocol in the network. There can be
protocol in the network. There can be several MP LSPs rooted at a several MP LSPs rooted at a given ingress node, each with its own
given ingress node, each with its own identifier. identifier.
The solution assumes that the leaf nodes of the MP LSP know the root 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 node and identifier of the MP LSP to which they belong. The
mechanisms for the distribution of this information are outside the mechanisms for the distribution of this information are outside the
scope of this document. The specification of how an application can 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 use an MP LSP signaled by LDP is also outside the scope of this
document. document.
Related documents that may be of interest include Related documents that may be of interest include [RFC6348],
[I-D.ietf-mpls-mp-ldp-reqs], [I-D.ietf-l3vpn-2547bis-mcast] and [L3VPN-MCAST], and [RFC4875].
[RFC4875].
1.1. Conventions used in this document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
All new fields shown as "reserved" in this document MUST be set to
zero on transmission and MUST be ignored on receipt.
1.2. Terminology 1.2. Terminology
Some of the following terminology is taken from Some of the following terminology is taken from [RFC6348].
[I-D.ietf-mpls-mp-ldp-reqs].
mLDP: Multipoint extensions for LDP. mLDP: Multipoint extensions for LDP.
P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. 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 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
LSRs. LSRs.
MP2P LSP: An LSP that has one or more Ingress LSRs and one unique MP2P LSP: An LSP that has one or more Ingress LSRs and one unique
Egress LSR. Egress LSR.
MP2MP LSP: An LSP with a distinguished root node that connects a set MP2MP LSP: An LSP with a distinguished root node that connects a set
of nodes, such that traffic sent by any node in the LSP is of nodes, such that traffic sent by any node in the LSP is
delivered to all others. delivered to all others.
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
Ingress LSR: An ingress LSR for a particular LSP is an LSR that can 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 send a data packet along the LSP. MP2MP LSPs can have multiple
ingress LSRs, P2MP LSPs have just one, and that node is often Ingress LSRs, P2MP LSPs have just one, and that node is often
referred to as the "root node". referred to as the "root node".
Egress LSR: An egress LSR for a particular LSP is an LSR that can 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 remove a data packet from that LSP for further processing. P2P
and MP2P LSPs have only a single egress node, but P2MP and MP2MP and MP2P LSPs have only a single egress node, but P2MP and MP2MP
LSPs can have multiple egress nodes. LSPs can have multiple egress nodes.
Transit LSR: An LSR that has reachability to the root of the MP LSP 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 via a directly connected upstream LSR and one or more directly
connected downstream LSRs. connected downstream LSRs.
Bud LSR: An LSR that is an egress but also has one or more directly Bud LSR: An LSR that is an egress but also has one or more directly
connected downstream LSRs. connected downstream LSRs.
Leaf node: A Leaf node can be either an Egress or Bud LSR when 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 referred to in the context of a P2MP LSP. In the context of an
LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and MP2MP LSP, a leaf is both Ingress and Egress for the same MP2MP
can also be a Bud LSR. LSP and can also be a Bud LSR.
CRC32: This contains a Cyclic Redundancy Check value of the CRC32: This contains a Cyclic Redundancy Check value of the
uncompressed data in network byte order computed according to uncompressed data in network byte order computed according to
CRC-32 algorithm used in the ISO 3309 standard and in section CRC-32 algorithm used in the ISO 3309 standard [ISO3309] and in
8.1.1.6.2 of ITU-T recommendation V.42. Section 8.1.1.6.2 of ITU-T recommendation V.42 [ITU.V42.1994].
2. Setting up P2MP LSPs with LDP FEC: Forwarding Equivalence Class
A P2MP LSP consists of a single root node, zero or more transit nodes 1.3. Manageability
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
traffic should go over the P2MP LSP is outside the scope of this
document.
2.1. Support for P2MP LSP setup with LDP MPLS LSRs can be modeled and managed using the MIB module defined in
[RFC3813]. That MIB module is fully capable of handling the one-to-
many in-segment to out-segment relationships needed to support P2MP
LSPs, and no further changes are required.
[RFC3815] defines managed objects for LDP. The MIB module allows the
modeling and management of LDP and LDP speakers for the protocol as
defined in [RFC5036]. The protocol extensions defined in this
document to support P2MP in LDP may require an additional MIB module
or extensions to the modules defined in [RFC3815]. This is for
future study, and at the time of this writing, no interest has been
expressed in this work.
Future manageability work should pay attention to the protocol
extensions defined in this document, and specifically the
configurable and variable elements, along with reporting the new
protocol fields that identify individual P2MP LSPs.
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 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 Support for the setup of P2MP LSPs is advertised using LDP
capabilities as defined in [RFC5561]. An implementation supporting capabilities as defined in [RFC5561]. An implementation supporting
the P2MP procedures specified in this document MUST implement the the P2MP procedures specified in this document MUST implement the
procedures for Capability Parameters in Initialization Messages. procedures for Capability Parameters in Initialization messages.
A new Capability Parameter TLV is defined, the P2MP Capability. A new Capability Parameter TLV is defined, the P2MP Capability.
Following is the format of the P2MP Capability Parameter. Following is the format of the P2MP Capability Parameter.
0 1 2 3 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 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|0| P2MP Capability (0x0508) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S: As specified in [RFC5561] S: As specified in [RFC5561]
The P2MP Capability TLV MUST be advertised in the LDP Initialization The P2MP Capability TLV MUST be advertised in the LDP Initialization
Message. Advertisement of the P2MP Capability indicates support of message. Advertisement of the P2MP Capability indicates support of
the procedures for P2MP LSP setup detailed in this document. If the the procedures for P2MP LSP setup detailed in this document. If the
peer has not advertised the corresponding capability, then label peer has not advertised the corresponding capability, then label
messages using the P2MP FEC Element SHOULD NOT be sent to the peer. messages using the P2MP FEC Element SHOULD NOT be sent to the peer.
2.2. The P2MP FEC Element 2.2. The P2MP FEC Element
For the setup of a P2MP LSP with LDP, we define one new protocol 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 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 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 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 view, the use of the term FEC is a misnomer. The description of the
P2MP FEC Element follows. P2MP FEC Element follows.
The P2MP FEC Element consists of the address of the root of the P2MP 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 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 LDP MP opaque value elements. The opaque value is unique within the
context of the root node. The combination of (Root Node Address context of the root node. The combination of (Root Node Address
type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP
within the MPLS network. within the MPLS network.
The P2MP FEC Element is encoded as follows: The P2MP FEC Element is encoded as follows:
0 1 2 3 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 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| |P2MP Type(0x06)| Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~ ~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... | | Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the P2MP FEC Element is to be assigned by IANA. Type: The type of the P2MP FEC Element is 0x06.
Address Family: Two octet quantity containing a value from IANA's Address Family: Two octet quantity containing a value from IANA's
"Address Family Numbers" registry that encodes the address family "Address Family Numbers" registry that encodes the address family
for the Root LSR Address. for the Root LSR Address.
Address Length: Length of the Root LSR Address in octets. Address Length: Length of the Root LSR Address in octets.
Root Node Address: A host address encoded according to the Address Root Node Address: A host address encoded according to the Address
Family field. Family field.
Opaque Length: The length of the Opaque Value, in octets. Opaque Length: The length of the opaque value, in octets.
Opaque Value: One or more MP Opaque Value elements, uniquely Opaque Value: One or more MP opaque value elements, uniquely
identifying the P2MP LSP in the context of the Root Node. This is identifying the P2MP LSP in the context of the root node. This is
described in the next section. described in the next section.
If the Address Family is IPv4, the Address Length MUST be 4; if the If the Address Family is IPv4, the Address Length MUST be 4; if the
Address Family is IPv6, the Address Length MUST be 16. No other Address Family is IPv6, the Address Length MUST be 16. No other
Address Lengths are defined at present. Address Lengths are defined at present.
If the Address Length doesn't match the defined length for the If the Address Length doesn't match the defined length for the
Address Family, the receiver SHOULD abort processing the message Address Family, the receiver SHOULD abort processing the message
containing the FEC Element, and send an "Unknown FEC" Notification containing the FEC Element, and send an "Unknown FEC" Notification
message to its LDP peer signaling an error. message to its LDP peer signaling an error.
If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST
be the only FEC Element in the FEC TLV. be the only FEC Element in the FEC TLV.
2.3. The LDP MP Opaque Value Element 2.3. The LDP MP Opaque Value Element
The LDP MP Opaque Value Element is used in the P2MP and MP2MP FEC The LDP MP opaque value element is used in the P2MP and MP2MP FEC
Elements defined in subsequent sections. It carries information that Elements defined in subsequent sections. It carries information that
is meaningful to Ingress LSRs and Leaf LSRs, but need not be is meaningful to Ingress LSRs and Leaf LSRs, but need not be
interpreted by Transit LSRs. interpreted by Transit LSRs.
The LDP MP Opaque Value Element basic type is encoded as follows: The LDP MP opaque value element basic type is encoded as follows:
0 1 2 3 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 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 < 255 | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The Type of the LDP MP Opaque Value Element. IANA maintains a Type: The Type of the LDP MP opaque value element. IANA maintains a
registry of basic types (see Section 11). registry of basic types (see Section 11).
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by Value: String of Length octets, to be interpreted as specified by
the Type field. the Type field.
The LDP MP Opaque Value Element extended type is encoded as follows: The LDP MP opaque value element extended type is encoded as follows:
0 1 2 3 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 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 | Extended Type | Length (high) | | Type = 255 | Extended Type | Length (high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Length (low) | Value | | Length (low) | Value |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type = 255. Type: Type = 255.
Extended Type: The Extended Type of the LDP MP Opaque Value Element. Extended Type: The Extended Type of the LDP MP opaque value element.
IANA maintains a registry of extended types (see Section 11). IANA maintains a registry of extended types (see Section 11).
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by Value: String of Length octets, to be interpreted as specified by
the Type field. the Type field.
2.3.1. The Generic LSP Identifier 2.3.1. The Generic LSP Identifier
The generic LSP identifier is a type of Opaque Value Element basic The generic LSP identifier is a type of opaque value element basic
type encoded as follows: type encoded as follows:
Type: 1 (to be assigned by IANA) Type: 1
Length: 4 Length: 4
Value: A 32bit integer, unique in the context of the root, as Value: A 32-bit integer, unique in the context of the root, as
identified by the root's address. identified by the root's address.
This type of Opaque Value Element is recommended when mapping of This type of opaque value element is recommended when mapping of
traffic to LSPs is non-algorithmic, and done by means outside LDP. traffic to LSPs is non-algorithmic and is done by means outside LDP.
2.4. Using the P2MP FEC Element 2.4. Using the P2MP FEC Element
This section defines the rules for the processing and propagation of This section defines the rules for the processing and propagation of
the P2MP FEC Element. The following notation is used in the the P2MP FEC Element. The following notation is used in the
processing rules: processing rules:
1. P2MP FEC Element <X, Y>: a FEC Element with Root Node Address X 1. P2MP FEC Element <X, Y>: a FEC Element with root node address X
and Opaque Value Y. and opaque value Y.
2. P2MP Label Mapping <X, Y, L>: a Label Mapping message with a FEC 2. P2MP Label Mapping <X, Y, L>: a Label Mapping message with a FEC
TLV with a single P2MP FEC Element <X, Y> and Label TLV with TLV with a single P2MP FEC Element <X, Y> and Label TLV with label
label L. Label L MUST be allocated from the per-platform label L. Label L MUST be allocated from the per-platform label space
space (see [RFC3031] section 3.14) of the LSR sending the Label (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping
Mapping Message. The use of the interface label space is outside message. The use of the interface label space is outside the
the scope of this document. scope of this document.
3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a 3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC
FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with TLV with a single P2MP FEC Element <X, Y> and Label TLV with label
label L. L.
4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with Root Node 4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with root node
Address X and Opaque Value Y. address X and opaque value Y.
5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X 5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X
means that on receiving a packet with label L', X makes n copies 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 of the packet. For copy i of the packet, X swaps L' with Li and
sends it out over interface Ii. sends it out over interface Ii.
The procedures below are organized by the role which the node plays The procedures below are organized by the role that the node plays in
in the P2MP LSP. Node Z knows that it is a leaf node by a discovery 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 process that is outside the scope of this document. During the
course of protocol operation, the root node recognizes its role course of protocol operation, the root node recognizes its role
because it owns the Root Node Address. A transit node is any node because it owns the root node address. A transit node is any node
(other than the root node) that receives a P2MP Label Mapping message (other than the root node) that receives a P2MP Label Mapping message
(i.e., one that has leaf nodes downstream of it). (i.e., one that has leaf nodes downstream of it).
Note that a transit node (and indeed the root node) may also be a Note that a transit node (and indeed the root node) may also be a
leaf node. leaf node.
2.4.1. Label Mapping 2.4.1. Label Mapping
The remainder of This section specifies the procedures for The remainder of this section specifies the procedures for
originating P2MP Label Mapping messages and for processing received originating P2MP Label Mapping messages and for processing received
P2MP Label Mapping messages for a particular LSP. The procedures for P2MP Label Mapping messages for a particular LSP. The procedures for
a particular LSR depend upon the role that LSR plays in the LSP a particular LSR depend upon the role that LSR plays in the LSP
(ingress, transit, or egress). (Ingress, Transit, or Egress).
All labels discussed here are downstream-assigned [RFC5332] except All labels discussed here are downstream-assigned [RFC5332] except
those which are assigned using the procedures of Section 6. those that are assigned using the procedures of Section 6.
2.4.1.1. Determining one's 'upstream LSR' 2.4.1.1. Determining One's 'upstream LSR'
Each node that is either an Leaf or Transit LSR of 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 use the procedures below to select an upstream LSR. A node Z that
wants to join a MP LSP <X, Y> determines the LDP peer U which is Z's wants to join an MP LSP <X, Y> determines the LDP peer U that is Z's
next-hop on the best path from Z to the root node X. If there is more next-hop on the best path from Z to the root node X. If there is
than one such LDP peer, only one of them is picked. U is Z's more than one such LDP peer, only one of them is picked. U is Z's
"Upstream LSR" for <X, Y>. "upstream LSR" for <X, Y>.
When there are several candidate upstream LSRs, the LSR MUST select When there are several candidate upstream LSRs, the LSR MUST select
one upstream LSR. The algorithm used for the LSR selection is a 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 local matter. If the LSR selection is done over a LAN interface and
the Section 6 procedures are applied, the following procedure SHOULD the Section 6 procedures are applied, the following procedure SHOULD
be applied to ensure that the same upstream LSR is elected among a be applied to ensure that the same upstream LSR is elected among a
set of candidate receivers on that LAN. set of candidate receivers on that LAN.
1. The candidate upstream LSRs are numbered from lower to higher IP 1. The candidate upstream LSRs are numbered from lower to higher IP
address address.
2. The following hash is performed: H = (CRC32(Opaque Value)) modulo 2. The following hash is performed: H = (CRC32(Opaque Value)) modulo
N, where N is the number of upstream LSRs. The 'Opaque Value' is N, where N is the number of upstream LSRs. The 'Opaque Value' is
the field identified in the FEC Element right after 'Opaque the field identified in the FEC Element right after 'Opaque
Length'. The 'Opaque Length' indicates the size of the Opaque Length'. The 'Opaque Length' indicates the size of the opaque
Value used in this calculation. value used in this calculation.
3. The selected upstream LSR U is the LSR that has the number H. 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 This procedure will ensure that there is a single forwarder over the
LAN for a particular LSP. LAN for a particular LSP.
2.4.1.2. Determining the forwarding interface to an LSR 2.4.1.2. Determining the Forwarding Interface to an LSR
Suppose LSR U receives a MP Label Mapping message from a downstream Suppose LSR U receives an MP Label Mapping message from a downstream
LSR D, specifying label L. Suppose further that U is connected to D LSR D, specifying label L. Suppose further that U is connected to D
over several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If 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 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 free to transmit the packet on any of those interfaces. The
algorithm it uses to choose a particular interface and next-hop for a algorithm it uses to choose a particular interface and next-hop for a
particular such packet is a local matter. For completeness the particular such packet is a local matter. For completeness, the
following procedure MAY be used. LSR U may do a lookup in 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 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 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. D via the LDP session, it can be used to transmit the packet to LSR
D.
2.4.1.3. Leaf Operation 2.4.1.3. Leaf Operation
A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for
<X, Y> as per Section 2.4.1.1, allocates a label L, and sends a P2MP <X, Y> as per Section 2.4.1.1, allocates a label L, and sends a P2MP
Label Mapping <X, Y, L> to U. Label Mapping <X, Y, L> to U.
2.4.1.4. Transit Node operation 2.4.1.4. Transit Node Operation
Suppose a transit node Z receives a P2MP Label Mapping <X, Y, L> from Suppose a transit node Z receives a P2MP Label Mapping <X, Y, L> from
LSR T. Z checks whether it already has state for <X, Y>. If not, Z LSR T. Z checks whether it already has state for <X, Y>. If not, Z
determines its upstream LSR U for <X, Y> as per Section 2.4.1.1. determines its upstream LSR U for <X, Y> as per Section 2.4.1.1.
Using this Label Mapping to update the label forwarding table MUST 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 NOT be done as long as LSR T is equal to LSR U. If LSR U is
from LSR T, Z will allocate a label L', and install state to swap L' different from LSR T, Z will allocate a label L', and install state
with L over interface I associated with LSR T and send a P2MP Label to swap L' with L over interface I associated with LSR T and send a
Mapping <X, Y, L'> to LSR U. Interface I is determind via the P2MP Label Mapping <X, Y, L'> to LSR U. Interface I is determined
procedures in Section 2.4.1.2. via the procedures in Section 2.4.1.2.
If Z already has state for <X, Y>, then Z does not send a Label If Z already has state for <X, Y>, then Z does not send a Label
Mapping message for P2MP LSP <X, Y>. If LSR T is not equal to the Mapping message for P2MP LSP <X, Y>. If LSR T is not equal to the
upstream LSR of <X, Y> and <I, L> does not already exist as upstream LSR of <X, Y> and <I, L> does not already exist as
forwarding state, the forwarding state updated. Assuming its old forwarding state, the forwarding state is updated. Assuming its old
forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new
forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I,
L>}. If the LSR T is equal to the installed upstream LSR, the Label L>}. If LSR T is equal to the installed upstream LSR, the Label
Mapping from LSR T MUST be retained and MUST NOT update the label Mapping from LSR T MUST be retained and MUST NOT update the label
forwarding table. forwarding table.
2.4.1.5. Root Node Operation 2.4.1.5. Root Node Operation
Suppose the root node Z receives a P2MP Label Mapping <X, Y, L> from Suppose the root node Z receives a P2MP Label Mapping <X, Y, L> from
LSR T. Z checks whether it already has forwarding state for <X, Y>. LSR T. Z checks whether it already has forwarding state for <X, Y>.
If not, Z creates forwarding state to push label L onto the traffic 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 that Z wants to forward over the P2MP LSP (how this traffic is
determined is outside the scope of this document). determined is outside the scope of this document).
If Z already has forwarding state for <X, Y>, then Z adds "push label If Z already has forwarding state for <X, Y>, then Z adds "push label
L, send over interface I" to the nexthop, where I is the interface L, send over interface I" to the next hop, where I is the interface
associated with LSR T and determined via the procedures in associated with LSR T and determined via the procedures in Section
Section 2.4.1.2. 2.4.1.2.
2.4.2. Label Withdraw 2.4.2. Label Withdraw
The following section lists procedures for generating and processing The following section lists procedures for generating and processing
P2MP Label Withdraw messages for nodes that participate in a P2MP P2MP Label Withdraw messages for nodes that participate in a P2MP
LSP. An LSR should apply those procedures that apply to it, based on LSP. An LSR should apply those procedures that apply to it, based on
its role in the P2MP LSP. its role in the P2MP LSP.
2.4.2.1. Leaf Operation 2.4.2.1. Leaf Operation
If a leaf node Z discovers that it has no downstream neighbors in 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 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 (by means outside the scope of this document), then it SHOULD send a
Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is
the label it had previously advertised to U for <X, Y>. the label it had previously advertised to U for <X, Y>.
2.4.2.2. Transit Node Operation 2.4.2.2. Transit Node Operation
If a transit node Z receives a Label Withdraw message <X, Y, L> from If a transit node Z receives a Label Withdraw message <X, Y, L> from
a node W, it deletes label L from its forwarding state, and sends a a node W, it deletes label L from its forwarding state and sends a
Label Release message with label L to W. Label Release message with label L to W.
If deleting L from Z's forwarding state for P2MP LSP <X, Y> results If deleting L from Z's forwarding state for P2MP LSP <X, Y> results
in no state remaining for <X, Y>, then Z propagates the Label in no state remaining for <X, Y>, then Z propagates the Label
Withdraw for <X, Y>, to its upstream T, by sending a Label Withdraw Withdraw for <X, Y> to its upstream T, by sending a Label Withdraw
<X, Y, L1> where L1 is the label Z had previously advertised to T for <X, Y, L1> where L1 is the label Z had previously advertised to T for
<X, Y>. <X, Y>.
2.4.2.3. Root Node Operation 2.4.2.3. Root Node Operation
The procedure when the root node of a P2MP LSP receives a Label When the root node of a P2MP LSP receives a Label Withdraw message,
Withdraw message are the same as for transit nodes, except that it the procedures are the same as those for transit nodes, except that
would not propagate the Label Withdraw upstream (as it has no it would not propagate the Label Withdraw upstream (as it has no
upstream). upstream).
2.4.3. Upstream LSR change 2.4.3. Upstream LSR Change
Suppose that for a given node Z participating in a P2MP LSP <X, Y>, Suppose that for a given node Z participating in a P2MP LSP <X, Y>,
the upstream LSR changes from U to U' as per Section 2.4.1.1. Z MUST 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, update its forwarding state as follows. It allocates a new label,
L', for <X, Y>. The forwarding state for L' is copied from the L', for <X, Y>. The forwarding state for L' is copied from the
forwarding state for L, with one exception: if U' was present in 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 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 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 forwarding state for L' is installed. In addition, Z MUST send a
Label Mapping <X, Y, L'> to U' and send a Label Withdraw <X, Y, L> to Label Mapping <X, Y, L'> to U' and send a Label Withdraw <X, Y, L> to
U. Note, if there was a downstream mapping from U that was not 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 in the forwarding due to the procedures defined in Section
installed. 2.4.1.4, it can now be installed.
While changing the upstream LSR the following must be taken into While changing the upstream LSR, the following must be taken into
consideration. If L' is added before L is removed, there is a consideration. If L' is added before L is removed, there is a
potential risk of packet duplication, and/or the creation of a potential risk of packet duplication and/or the creation of a
transient dataplane forwarding loop. If L is removed before L' is transient data-plane forwarding loop. If L is removed before L' is
added, packet loss may result. Ideally the change from L to 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 done atomically such that no packet loss or duplication occurs. If
that is not possible, the RECOMMENDED default behavior is to remove L that is not possible, the RECOMMENDED default behavior is to remove L
before adding L'. before adding L'.
3. Setting up MP2MP LSPs with LDP 3. Setting up MP2MP LSPs with LDP
An MP2MP LSP is much like a P2MP LSP in that it consists of a single An MP2MP LSP is much like a P2MP LSP in that it consists of a single
root node, zero or more transit nodes and one or more leaf LSRs root node, zero or more transit nodes, and one or more Leaf LSRs
acting equally as Ingress or Egress LSR. A leaf node participates in acting equally an as Ingress or Egress LSR. A leaf node participates
the setup of an MP2MP LSP by establishing both a downstream LSP, in the setup of an MP2MP LSP by establishing both a downstream LSP,
which is much like a P2MP LSP from the root, and an upstream LSP which is much like a P2MP LSP from the root, and an upstream LSP,
which is used to send traffic toward the root and other leaf nodes. which is used to send traffic toward the root and other leaf nodes.
Transit nodes support the setup by propagating the upstream and Transit nodes support the setup by propagating the upstream and
downstream LSP setup toward the root and installing the necessary downstream LSP setup toward the root and installing the necessary
MPLS forwarding state. The transmission of packets from the root MPLS forwarding state. The transmission of packets from the root
node of a MP2MP LSP to the receivers is identical to that for a P2MP node of an MP2MP LSP to the receivers is identical to that for a P2MP
LSP. Traffic from a downstream node follows the upstream LSP toward LSP. Traffic from a downstream node follows the upstream LSP toward
the root node and branches downward along the downstream LSP as the root node and branches downward along the downstream LSP as
required to reach other leaf nodes. A packet that is received from a required to reach other leaf nodes. A packet that is received from a
downstream node MUST never be forwarded back out to that same node. 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 Mapping traffic to the MP2MP LSP may happen at any leaf node. How
that mapping is established is outside the scope of this document. 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 Due to how an MP2MP LSP is built, a Leaf LSR that is sending packets
the MP2MP LSP does not receive its own packets. There is also no 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 additional mechanism needed on the root or Transit LSR to match
upstream traffic to the downstream forwarding state. Packets that upstream traffic to the downstream forwarding state. Packets that
are forwarded over a MP2MP LSP will not traverse a link more than are forwarded over an MP2MP LSP will not traverse a link more than
once, with the possible exception of LAN links (see Section 3.3.1), once, with the possible exception of LAN links (see Section 3.3.1),
if the procedures of [RFC5331] are not provided. if the procedures of [RFC5331] are not provided.
3.1. Support for MP2MP LSP setup with LDP 3.1. Support for MP2MP LSP Setup with LDP
Support for the setup of MP2MP LSPs is advertised using LDP Support for the setup of MP2MP LSPs is advertised using LDP
capabilities as defined in [RFC5561]. An implementation supporting capabilities as defined in [RFC5561]. An implementation supporting
the MP2MP procedures specified in this document MUST implement the the MP2MP procedures specified in this document MUST implement the
procedures for Capability Parameters in Initialization Messages. procedures for Capability Parameters in Initialization messages.
A new Capability Parameter TLV is defined, the MP2MP Capability. A new Capability Parameter TLV is defined, the MP2MP Capability.
Following is the format of the MP2MP Capability Parameter. Following is the format of the MP2MP Capability Parameter.
0 1 2 3 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 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|0| MP2MP Capability (0x0509) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S: As specified in [RFC5561] S: As specified in [RFC5561]
The MP2MP Capability TLV MUST be advertised in the LDP Initialization The MP2MP Capability TLV MUST be advertised in the LDP Initialization
Message. Advertisement of the MP2MP Capability indicates support of message. Advertisement of the MP2MP Capability indicates support of
the procedures for MP2MP LSP setup detailed in this document. If the the procedures for MP2MP LSP setup detailed in this document. If the
peer has not advertised the corresponding capability, then label peer has not advertised the corresponding capability, then label
messages using the MP2MP upstream and downstream FEC Elements SHOULD messages using the MP2MP upstream and downstream FEC Elements SHOULD
NOT be sent to the peer. NOT be sent to the peer.
3.2. The MP2MP downstream and upstream FEC Elements. 3.2. The MP2MP Downstream and Upstream FEC Elements
For the setup of a MP2MP LSP with LDP we define 2 new protocol For the setup of an MP2MP LSP with LDP, we define 2 new protocol
entities, the MP2MP downstream FEC and upstream FEC Element. Both entities, the MP2MP downstream FEC and upstream FEC Element. Both
elements will be used as FEC Elements in the FEC TLV. Note that the elements will be used as FEC Elements in the FEC TLV. Note that the
MP2MP FEC Elements do not necessarily identify the traffic that must MP2MP FEC Elements do not necessarily identify the traffic that must
be mapped to the LSP, so from that point of view, the use of the term be mapped to the LSP, so from that point of view, the use of the term
FEC is a misnomer. The description of the MP2MP FEC Elements follow. FEC is a misnomer. The description of the MP2MP FEC Elements follow.
The structure, encoding and error handling for the MP2MP downstream The structure, encoding, and error handling for the MP2MP downstream
and upstream FEC Elements are the same as for the P2MP FEC Element 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 described in Section 2.2. The difference is that two new FEC types
are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). are used: MP2MP downstream type (0x08) and MP2MP upstream type
(0x07).
If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element
MUST be the only FEC Element in the FEC TLV. MUST be the only FEC Element in the FEC TLV.
Note, except when using the procedures of [RFC5331], the MPLS labels Note, except when using the procedures of [RFC5331], the MPLS labels
used are "downstream-assigned" [RFC5332], even if they are bound to used are "downstream-assigned" [RFC5332], even if they are bound to
the "upstream FEC element". the "upstream FEC Element".
3.3. Using the MP2MP FEC Elements 3.3. Using the MP2MP FEC Elements
This section defines the rules for the processing and propagation of This section defines the rules for the processing and propagation of
the MP2MP FEC Elements. The following notation is used in the the MP2MP FEC Elements. The following notation is used in the
processing rules: processing rules:
1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an 1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an
MP2MP LSP downstream path with root node address X and opaque MP2MP LSP downstream path with root node address X and opaque
value Y. value Y.
2. MP2MP upstream LSP <X, Y, D> (or simply upstream <X, Y, D>): a 2. MP2MP upstream LSP <X, Y, D> (or simply upstream <X, Y, D>): an
MP2MP LSP upstream path for downstream node D with root node MP2MP LSP upstream path for downstream node D with root node
address X and opaque value Y. address X and opaque value Y.
3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root 3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root node
node address X and opaque value Y used for a downstream MP2MP address X and opaque value Y used for a downstream MP2MP LSP.
LSP.
4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node 4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node
address X and opaque value Y used for an upstream MP2MP LSP. address X and opaque value Y used for an upstream MP2MP LSP.
5. MP2MP-D Label Mapping <X, Y, L>: A Label Mapping message with a 5. MP2MP-D Label Mapping <X, Y, L>: a Label Mapping message with a
FEC TLV with a single MP2MP downstream FEC Element <X, Y> and FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
label TLV with label L. Label L MUST be allocated from the per- label TLV with label L. Label L MUST be allocated from the per-
platform label space (see [RFC3031] section 3.14) of the LSR platform label space (see [RFC3031], Section 3.14) of the LSR
sending the Label Mapping Message. The use of the interface sending the Label Mapping message. The use of the interface
label space is outside the scope of this document. label space is outside the scope of this document.
6. MP2MP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a 6. MP2MP-U Label Mapping <X, Y, Lu>: a Label Mapping message with a
FEC TLV with a single MP2MP upstream FEC Element <X, Y> and FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label
label TLV with label Lu. Label Lu MUST be allocated from the TLV with label Lu. Label Lu MUST be allocated from the per-
per-platform label space (see [RFC3031] section 3.14) of the LSR platform label space (see [RFC3031], Section 3.14) of the LSR
sending the Label Mapping Message. The use of the interface sending the Label Mapping message. The use of the interface
label space is outside the scope of this document. label space is outside the scope of this document.
7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with 7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a
a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
label TLV with label L. label TLV with label L.
8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with 8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with
a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and
label TLV with label Lu. label TLV with label Lu.
9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a 9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a
FEC TLV with a single MP2MP downstream FEC Element <X, Y> and FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
label TLV with label L. Label TLV with label L.
10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a 10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a
FEC TLV with a single MP2MP upstream FEC Element <X, Y> and FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label
label TLV with label Lu. TLV with label Lu.
The procedures below are organized by the role which the node plays 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 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 process that is outside the scope of this document. During the
course of the protocol operation, the root node recognizes its role course of the protocol operation, the root node recognizes its role
because it owns the root node address. A transit node is any node because it owns the root node address. A transit node is any node
(other then the root node) that receives a MP2MP Label Mapping (other then the root node) that receives an MP2MP Label Mapping
message (i.e., one that has leaf nodes downstream of it). 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 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 node and the root node does not have to be an Ingress LSR or a
leaf of the MP2MP LSP. leaf of the MP2MP LSP.
3.3.1. MP2MP Label Mapping 3.3.1. MP2MP Label Mapping
The remainder of This section specifies the procedures for The remainder of this section specifies the procedures for
originating MP2MP Label Mapping messages and for processing received originating MP2MP Label Mapping messages and for processing received
MP2MP Label Mapping messages for a particular LSP. The procedures MP2MP Label Mapping messages for a particular LSP. The procedures
for a particular LSR depend upon the role that LSR plays in the LSP for a particular LSR depend upon the role that the LSR plays in the
(ingress, transit, or egress). LSP (Ingress, Transit, or Egress).
All labels discussed here are downstream-assigned [RFC5332] except All labels discussed here are downstream-assigned [RFC5332] except
those which are assigned using the procedures of Section 6. those that are assigned using the procedures of Section 6.
3.3.1.1. Determining one's upstream MP2MP LSR 3.3.1.1. Determining one's upstream MP2MP LSR
Determining the upstream LDP peer U for a MP2MP LSP <X, Y> follows Determining the upstream LDP peer U for an MP2MP LSP <X, Y> follows
the procedure for a P2MP LSP described in Section 2.4.1.1. the procedure for a P2MP LSP described in Section 2.4.1.1.
3.3.1.2. Determining one's downstream MP2MP LSR 3.3.1.2. Determining One's Downstream MP2MP LSR
A LDP peer U which receives a MP2MP-D Label Mapping from a LDP peer D An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer
will treat D as downstream MP2MP LSR. D will treat D as downstream MP2MP LSR.
3.3.1.3. Installing the upstream path of a MP2MP LSP 3.3.1.3. Installing the Upstream Path of an MP2MP LSP
There are two methods for installing the upstream path of a MP2MP LSP There are two methods for installing the upstream path of an MP2MP
to a downstream neighbor. LSP to a downstream neighbor.
1. We can install the upstream MP2MP path (to a downstream neighbor) 1. We can install the upstream MP2MP path (to a downstream neighbor)
based on receiving a MP2MP-D Label Mapping from the downstream based on receiving an MP2MP-D Label Mapping from the downstream
neighbor. This will install the upstream path on a per hop by neighbor. This will install the upstream path on a hop-by-hop
hop basis. basis.
2. We install the upstream MP2MP path (to a downstream neighbor) 2. We install the upstream MP2MP path (to a downstream neighbor)
based on receiving a MP2MP-U Label Mapping from the upstream based on receiving an MP2MP-U Label Mapping from the upstream
neighbor. An LSR does not need to wait for the MP2MP-U Label 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 Mapping if it is the root of the MP2MP LSP or if it already
received an MP2MP-U Label Mapping from the upstream neighbor. We received an MP2MP-U Label Mapping from the upstream neighbor. We
call this method ordered mode. The typical result of this mode call this method ordered mode. The typical result of this mode is
is that the downstream path of the MP2MP is built hop by hop that the downstream path of the MP2MP is built hop by hop towards
towards the root. Once the root is reached, the root node will the root. Once the root is reached, the root node will trigger an
trigger a MP2MP-U Label Mapping to the downstream neighbor(s). MP2MP-U Label Mapping to the downstream neighbor(s).
For setting up the upstream path of a MP2MP LSP ordered mode SHOULD For setting up the upstream path of an MP2MP LSP, ordered mode SHOULD
be used. Due to ordered mode the upstream path of the MP2MP LSP is 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. installed at the leaf node once the path to the root has completed.
The advantage is that when a leaf starts sending immediately after The advantage is that when a leaf starts sending immediately after
the upstream path is installed, packets are able to reach the root 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 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 able to guarantee that the upstream path has completed before the
starts sending. leaf starts sending.
3.3.1.4. MP2MP leaf node operation 3.3.1.4. MP2MP Leaf Node Operation
A leaf node Z of a MP2MP LSP <X, Y> determines its upstream LSR U for A leaf node Z of an MP2MP LSP <X, Y> determines its upstream LSR U
<X, Y> as per Section 3.3.1.1, allocates a label L, and sends a for <X, Y> as per Section 3.3.1.1, allocates a label L, and sends an
MP2MP-D Label Mapping <X, Y, L> to U. MP2MP-D Label Mapping <X, Y, L> to U.
Leaf node Z expects an MP2MP-U Label Mapping <X, Y, Lu> from node U Leaf node Z expects an MP2MP-U Label Mapping <X, Y, Lu> from node U
in response to the MP2MP-D Label Mapping it sent to node U. Z checks in response to the MP2MP-D Label Mapping it sent to node U. Z checks
whether it already has forwarding state for upstream <X, Y>. If not, whether it already has forwarding state for upstream <X, Y>. If not,
Z creates forwarding state to push label Lu onto the traffic that Z 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 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. to forward on this MP2MP LSP is outside the scope of this document.
3.3.1.5. MP2MP transit node operation 3.3.1.5. MP2MP Transit Node Operation
Suppose node Z receives a MP2MP-D Label Mapping <X, Y, L> from LSR D. Suppose node Z receives an MP2MP-D Label Mapping <X, Y, L> from LSR
Z checks whether it has forwarding state for downstream <X, Y>. If D. Z checks whether it has forwarding state for downstream <X, Y>.
not, Z determines its upstream LSR U for <X, Y> as per If not, Z determines its upstream LSR U for <X, Y> as per Section
Section 3.3.1.1. Using this Label Mapping to update the label 3.3.1.1. Using this Label Mapping to update the label forwarding
forwarding table MUST NOT be done as long as LSR D is equal to LSR U. table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U
If LSR U is different from LSR D, Z will allocate a label L' and is different from LSR D, Z will allocate a label L' and install
install downstream forwarding state to swap label L' with label L downstream forwarding state to swap label L' with label L over
over interface I associated with LSR D and send a MP2MP-D Label interface I associated with LSR D and send an MP2MP-D Label Mapping
Mapping <X, Y, L'> to U. Interface I is determined via the procedures <X, Y, L'> to U. Interface I is determined via the procedures in
in Section 2.4.1.2. Section 2.4.1.2.
If Z already has forwarding state for downstream <X, Y>, all that Z If Z already has forwarding state for downstream <X, Y>, all that Z
needs to do in this case is check that LSR D is not equal to the needs to do in this case is check that LSR D is not equal to the
upstream LSR of <X, Y> and update its forwarding state. Assuming its upstream LSR of <X, Y> and update its forwarding state. Assuming its
old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its
new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>,
<I, L>}. If the LSR D is equal to the installed upstream LSR, the <I, L>}. If the LSR D is equal to the installed upstream LSR, the
Label Mapping from LSR D MUST be retained and MUST NOT update the Label Mapping from LSR D MUST be retained and MUST NOT update the
label forwarding table. label forwarding table.
Node Z checks if upstream LSR U already assigned a label Lu to <X, Node Z checks if upstream LSR U already assigned a label Lu to
Y>. If not, transit node Z waits until it receives a MP2MP-U Label <X, Y>. If not, transit node Z waits until it receives an MP2MP-U
Mapping <X, Y, Lu> from LSR U. See Section 3.3.1.3. Once the MP2MP-U Label Mapping <X, Y, Lu> from LSR U (see Section 3.3.1.3). Once the
Label Mapping is received from LSR U, node Z checks whether it MP2MP-U Label Mapping is received from LSR U, node Z checks whether
already has forwarding state upstream <X, Y, D>. If it does, then no it already has forwarding state upstream <X, Y, D>. If it does, then
further action needs to happen. If it does not, it allocates a label no further action needs to happen. If it does not, it allocates a
Lu' and creates a new label swap for Lu' with Label Lu over interface label Lu' and creates a new label swap for Lu' with label Lu over
Iu. Interface Iu is determined via the procedures in 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 Section 2.4.1.2. In addition, it also adds the label swap(s) from
the forwarding state downstream <X, Y>, omitting the swap on the forwarding state downstream <X, Y>, omitting the swap on
interface I for node D. The swap on interface I for node D is omitted interface I for node D. The swap on interface I for node D is
to prevent packet originated by D to be forwarded back to D. omitted to prevent a packet originated by D to be forwarded back to
D.
Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2, Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2,
and sends a MP2MP-U Label Mapping <X, Y, Lu'> to node D. and sends an MP2MP-U Label Mapping <X, Y, Lu'> to node D.
3.3.1.6. MP2MP root node operation 3.3.1.6. MP2MP Root Node Operation
3.3.1.6.1. Root node is also a leaf 3.3.1.6.1. Root Node Is Also a Leaf
Suppose root/leaf node Z receives a MP2MP-D Label Mapping <X, Y, L> Suppose root/leaf node Z receives an MP2MP-D Label Mapping <X, Y, L>
from node D. Z checks whether it already has forwarding state from node D. Z checks whether it already has forwarding state
downstream <X, Y>. If not, Z creates forwarding state for downstream downstream <X, Y>. If not, Z creates downstream forwarding state to
to push label L on traffic that Z wants to forward down the MP2MP push label L on traffic that Z wants to forward down the MP2MP LSP.
LSP. How it determines what traffic to forward on this MP2MP LSP is How it determines what traffic to forward on this MP2MP LSP is
outside the scope of this document. If Z already has forwarding outside the scope of this document. If Z already has forwarding
state for downstream <X, Y>, then Z will add the label push for L state for downstream <X, Y>, then Z will add the label push for L
over interface I to it. Interface I is determined via the procedures over interface I to it. Interface I is determined via the procedures
in Section 2.4.1.2. in Section 2.4.1.2.
Node Z checks if it has forwarding state for upstream <X, Y, D> If Node Z checks if it has forwarding state for upstream <X, Y, D>. If
not, Z allocates a label Lu' and creates upstream forwarding state to not, Z allocates a label Lu' and creates upstream forwarding state to
swap Lu' with the label swap(s) from the forwarding state downstream swap Lu' with the label swap(s) from the forwarding state downstream
<X, Y>, except the swap on interface I for node D. This allows <X, Y>, except the swap on interface I for node D. This allows
upstream traffic to go down the MP2MP to other node(s), except the upstream traffic to go down the MP2MP to other node(s), except the
node from which the traffic was received. Node Z determines 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 downstream MP2MP LSR as per section Section 3.3.1.2, and sends an
MP2MP-U Label Mapping <X, Y, Lu'> to node D. Since Z is the root of MP2MP-U Label Mapping <X, Y, Lu'> to node D. Since Z is the root of
the tree Z will not send a MP2MP-D Label Mapping and will not receive the tree, Z will not send an MP2MP-D Label Mapping and will not
a MP2MP-U Label Mapping. receive an MP2MP-U Label Mapping.
3.3.1.6.2. Root node is not a leaf 3.3.1.6.2. Root Node is Not a Leaf
Suppose the root node Z receives a MP2MP-D Label Mapping <X, Y, L> Suppose the root node Z receives an MP2MP-D Label Mapping <X, Y, L>
from node D. Z checks whether it already has forwarding state for from node D. Z checks whether it already has forwarding state for
downstream <X, Y>. If not, Z creates downstream forwarding state and downstream <X, Y>. If not, Z creates downstream forwarding state and
installs a outgoing label L over interface I. Interface I is 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 determined via the procedures in Section 2.4.1.2. If Z already has
forwarding state for downstream <X, Y>, then Z will add label L over forwarding state for downstream <X, Y>, then Z will add label L over
interface I to the existing state. interface I to the existing state.
Node Z checks if it has forwarding state for upstream <X, Y, D>. If Node Z checks if it has forwarding state for upstream <X, Y, D>. If
not, Z allocates a label Lu' and creates forwarding state to swap Lu' not, Z allocates a label Lu' and creates forwarding state to swap Lu'
with the label swap(s) from the forwarding state downstream <X, Y>, with the label swap(s) from the forwarding state downstream <X, Y>,
except the swap for node D. This allows upstream traffic to go down 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. the MP2MP to other node(s), except the node from which it was
Root node Z determines the downstream MP2MP LSR D as per received. Root node Z determines the downstream MP2MP LSR D as per
Section 3.3.1.2, and sends a MP2MP-U Label Mapping <X, Y, Lu'> to it. Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to
Since Z is the root of the tree Z will not send a MP2MP-D Label it. Since Z is the root of the tree, Z will not send an MP2MP-D
Mapping and will not receive a MP2MP-U Label Mapping. Label Mapping and will not receive an MP2MP-U Label Mapping.
3.3.2. MP2MP Label Withdraw 3.3.2. MP2MP Label Withdraw
The following section lists procedures for generating and processing The following section lists procedures for generating and processing
MP2MP Label Withdraw messages for nodes that participate in a MP2MP MP2MP Label Withdraw messages for nodes that participate in an MP2MP
LSP. An LSR should apply those procedures that apply to it, based on LSP. An LSR should apply those procedures that apply to it, based on
its role in the MP2MP LSP. its role in the MP2MP LSP.
3.3.2.1. MP2MP leaf operation 3.3.2.1. MP2MP Leaf Operation
If a leaf node Z discovers (by means outside the scope of this 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 document) that it has no downstream neighbors in that LSP and that it
it has no need to be an egress LSR for that LSP (by means outside the 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 scope of this document), then it SHOULD send an MP2MP-D Label
<X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the
had previously advertised to U for <X,Y>. Leaf node Z will also send label it had previously advertised to U for <X,Y>. Leaf node Z will
a unsolicited label release <X, Y, Lu> to U to indicate that the also send an unsolicited label release <X, Y, Lu> to U to indicate
upstream path is no longer used and that Label Lu can be removed. 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 Leaf node Z expects the upstream router U to respond by sending a
downstream label release for L. downstream label release for L.
3.3.2.2. MP2MP transit node operation 3.3.2.2. MP2MP Transit Node Operation
If a transit node Z receives a MP2MP-D Label Withdraw message <X, Y, If a transit node Z receives an MP2MP-D Label Withdraw message
L> from node D, it deletes label L from its forwarding state <X, Y, L> from node D, it deletes label L from its forwarding state
downstream <X, Y> and from all its upstream states for <X, Y>. Node downstream <X, Y> and from all its upstream states for <X, Y>. Node
Z sends a MP2MP-D Label Release message with label L to D. Since node Z sends an MP2MP-D Label Release message with label L to D. Since
D is no longer part of the downstream forwarding state, Z cleans up node D is no longer part of the downstream forwarding state, Z cleans
the forwarding state upstream <X, Y, D>. There is no need to send an up the forwarding state upstream <X, Y, D>. There is no need to send
MP2MP-U Label Withdraw <X, Y, Lu> to D because node D already removed an MP2MP-U Label Withdraw <X, Y, Lu> to D because node D already
Lu and send a label release for Lu to Z. removed Lu and sent a label release for Lu to Z.
If deleting L from Z's forwarding state for downstream <X, Y> results If deleting L from Z's forwarding state for downstream <X, Y> results
in no state remaining for <X, Y>, then Z propagates the MP2MP-D Label in no state remaining for <X, Y>, then Z propagates the MP2MP-D Label
Withdraw <X, Y, L> to its upstream node U for <X,Y> and will also Withdraw <X, Y, L> to its upstream node U for <X, Y> and will also
send a unsolicited MP2MP-U Label Release <X, Y, Lu> to U to indicate send an unsolicited MP2MP-U Label Release <X, Y, Lu> to U to indicate
that the upstream path is no longer used and that Label Lu can be that the upstream path is no longer used and that label Lu can be
removed. removed.
3.3.2.3. MP2MP root node operation 3.3.2.3. MP2MP Root Node Operation
The procedure when the root node of a MP2MP LSP receives a MP2MP-D When the root node of an MP2MP LSP receives an MP2MP-D Label Withdraw
Label Withdraw message is the same as for transit nodes, except that message, the procedure is the same as that for transit nodes, except
the root node would not propagate the Label Withdraw upstream (as it that the root node will not propagate the Label Withdraw upstream (as
has no upstream). it has no upstream).
3.3.3. MP2MP Upstream LSR change 3.3.3. MP2MP Upstream LSR Change
The procedure for changing the upstream LSR is the same as documented The procedure for changing the upstream LSR is the same as documented
in Section 2.4.3, except it is applied to MP2MP FECs, using the in Section 2.4.3, except it is applied to MP2MP FECs, using the
procedures described in Section 3.3.1 through Section 3.3.2.3. procedures described in Section 3.3.1 through Section 3.3.2.3.
4. Micro-loops in MP LSPs 4. Micro-Loops in MP LSPs
Micro-loops created by the unicast routing protocol during Micro-loops created by the unicast routing protocol during
convergence may also effect mLDP MP LSPs. Since the tree building convergence may also effect mLDP MP LSPs. Since the tree building
logic in mLDP is based on unicast routing, a unicast routing loop may 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 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 2 directly connected routers don't create a loop in mLDP. mLDP is
able to prevent this inconsistency by never allowing an upstream LDP able to prevent this inconsistency by never allowing an upstream LDP
neighbor to be added as a downstream LDP neighbor into the Label neighbor to be added as a downstream LDP neighbor into the Label
Forwarding Table (LFT) for the same FEC. Micro-loops that involve Forwarding Table (LFT) for the same FEC. Micro-loops that involve
more than 2 LSRs are not prevented. more than 2 LSRs are not prevented.
Micro-loops that involve more than 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 the downstream path of either an MP2MP LSP or P2MP LSP and the
upstream path of the MP2MP LSP. The loops are transient and will upstream path of the MP2MP LSP. The loops are transient and will
disappear as soon as the unicast routing protocol converges and mLDP disappear as soon as the unicast routing protocol converges and mLDP
has updated the forwarding state accordingly. Micro-loops that occur has updated the forwarding state accordingly. Micro-loops that occur
in the upstream path of a MP2MP LSP may be detected by including LDP in the upstream path of an MP2MP LSP may be detected by including LDP
path vector in the MP2MP-U Label Mapping messages. These procedures path vector in the MP2MP-U Label Mapping messages. These procedures
are currently under investigation and are subjected to further study. are currently under investigation and are subjected to further study.
5. The LDP MP Status TLV 5. The LDP MP Status TLV
An LDP MP capable router MAY use an LDP MP Status TLV to indicate 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 additional status for an MP LSP to its remote peers. This includes
signaling to peers that are either upstream or downstream of the LDP 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 MP capable router. The value of the LDP MP Status TLV will remain
opaque to LDP and MAY encode one or more status elements. opaque to LDP and MAY encode one or more status elements.
The LDP MP Status TLV is encoded as follows: The LDP MP Status TLV is encoded as follows:
0 1 2 3 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 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 Status Type(TBD) | Length | |1|0| LDP MP Status Type(0x096F)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
~ ~ ~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. LDP MP Status Type: The LDP MP Status (0x096F).
Length: Length of the LDP MP Status Value in octets. Length: Length of the LDP MP Status Value in octets.
Value: One or more LDP MP Status Value elements. Value: One or more LDP MP Status Value elements.
5.1. The LDP MP Status Value Element 5.1. The LDP MP Status Value Element
The LDP MP Status Value Element that is included in the LDP MP Status The LDP MP Status Value Element that is included in the LDP MP Status
TLV Value has the following encoding. TLV Value has the following encoding.
0 1 2 3 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 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 | Length | Value ... | | Type | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the LDP MP Status Value Element. IANA maintains a Type: The type of the LDP MP Status Value Element. IANA maintains a
registry of status value types (see Section 11). registry of status value types (see Section 11).
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by Value: String of Length octets, to be interpreted as specified by
the Type field. the Type field.
5.2. LDP Messages containing LDP MP Status messages 5.2. LDP Messages Containing LDP MP Status Messages
The LDP MP Status TLV may appear either in a Label Mapping message or The LDP MP Status TLV may appear either in a Label Mapping message or
a LDP Notification message. an LDP Notification message.
5.2.1. LDP MP Status sent in LDP notification messages 5.2.1. LDP MP Status Sent in LDP Notification Messages
An LDP MP status TLV sent in a notification message must be An LDP MP Status TLV sent in a notification message must be
accompanied with a Status TLV, as described in [RFC5036]. The accompanied with a Status TLV, as described in [RFC5036]. The
general format of the Notification Message with an LDP MP status TLV general format of the Notification message with an LDP MP Status TLV
is: is:
0 1 2 3 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 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 | |0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV | | Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP MP Status TLV | | LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP FEC TLV | | Optional LDP MP FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Label TLV | | Optional Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is used to indicate that LDP MP status TLV The Status TLV status code is used to indicate that LDP MP Status TLV
and any additional information follows in the Notification message's and any additional information follows in the Notification message's
"optional parameter" section. Depending on the actual contents of "optional parameter" section. Depending on the actual contents of
the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may the LDP MP Status TLV, an LDP P2MP or MP2MP FEC TLV and a Label TLV
also be present to provide context to the LDP MP Status TLV. (NOTE: may also be present to provide context to the LDP MP Status TLV.
Status Code is pending IANA assignment).
Since the notification does not refer to any particular message, the Since the notification does not refer to any particular message, the
Message Id and Message Type fields are set to 0. Message ID and Message Type fields are set to 0.
5.2.2. LDP MP Status TLV in Label Mapping Message 5.2.2. LDP MP Status TLV in Label Mapping Message
An example of the Label Mapping Message defined in RFC3036 is shown An example of the Label Mapping message defined in [RFC5036] is shown
below to illustrate the message with an Optional LDP MP Status TLV below to illustrate the message with an Optional LDP MP Status TLV
present. present.
0 1 2 3 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 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| Label Mapping (0x0400) | Message Length | |0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV | | Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP Status TLV | | Optional LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Optional Parameters | | Additional Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Upstream label allocation on a LAN 6. Upstream Label Allocation on a LAN
On a LAN, the procedures so far discussed would require the upstream 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 LSR to send a copy of the packet to each receiver individually. If
there is more than 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
of the multi-access capability of the network. We may optimize the benefit of the multi-access capability of the network. We may
bandwidth consumption on the LAN and replication overhead on the optimize the bandwidth consumption on the LAN and replication
upstream LSR by using upstream label allocation [RFC5331]. overhead on the upstream LSR by using upstream label allocation
Procedures on how to distribute upstream labels using LDP is [RFC5331]. Procedures on how to distribute upstream labels using LDP
documented in [I-D.ietf-mpls-ldp-upstream]. is documented in [RFC6389].
6.1. LDP Multipoint-to-Multipoint on a LAN 6.1. LDP Multipoint-to-Multipoint on a LAN
The procedure to allocate a context label on a LAN is defined in The procedure to allocate a context label on a LAN is defined in
[RFC5331]. That procedure results in each LSR on a given LAN having [RFC5331]. That procedure results in each LSR on a given LAN having
a context label which, on that LAN, can be used to identify itself a context label which, on that LAN, can be used to identify itself
uniquely. Each LSR advertises its context label as an upstream- uniquely. Each LSR advertises its context label as an upstream-
assigned label, following the procedures of assigned label, following the procedures of [RFC6389]. Any LSR for
[I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a which the LAN is a downstream link on some P2MP or MP2MP LSP will
downstream link on some P2MP or MP2MP LSP will allocate an upstream- allocate an upstream-assigned label identifying that LSP. When the
assigned label identifying that LSP. When the LSR forwards a packet LSR forwards a packet downstream on one of those LSPs, the packet's
downstream on one of those LSPs, the packet's top label must be the top label must be the LSR's context label, and the packet's second
LSR's context label, and the packet's second label is the label label is the label identifying the LSP. We will call the top label
identifying the LSP. We will call the top label the "upstream LSR the "upstream LSR label" and the second label the "LSP label".
label" and the second label the "LSP label".
6.1.1. MP2MP downstream forwarding 6.1.1. MP2MP Downstream Forwarding
The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so The downstream path of an MP2MP LSP is much like a normal P2MP LSP,
we will use the same procedures as defined in so we will use the same procedures as those defined in [RFC6389]. A
[I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is label request for an LSP label is sent to the upstream LSR. The
sent to the upstream LSR. The Label Mapping that is received from Label Mapping that is received from the upstream LSR contains the LSP
the upstream LSR contains the LSP label for the MP2MP FEC and the label for the MP2MP FEC and the upstream LSR context label. The
upstream LSR context label. The MP2MP downstream path (corresponding MP2MP downstream path (corresponding to the LSP label) will be
to the LSP label) will be installed in the context specific installed in the context-specific forwarding table corresponding to
forwarding table corresponding to the upstream LSR label. Packets the upstream LSR label. Packets sent by the upstream router can be
sent by the upstream router can be forwarded downstream using this forwarded downstream using this forwarding state based on a two-label
forwarding state based on a two label lookup. lookup.
6.1.2. MP2MP upstream forwarding 6.1.2. MP2MP Upstream Forwarding
A MP2MP LSP also has an upstream forwarding path. Upstream packets An MP2MP LSP also has an upstream forwarding path. Upstream packets
need to be forwarded in the direction of the root and downstream on 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 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 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 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 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 packet onto the LAN, it ensures that the packet's top label is the
context label of the upstream LSR, and that its second label is the context label of the upstream LSR, and that its second label is the
LSP label that was assigned by the upstream LSR. LSP label that was assigned by the upstream LSR.
Other LSRs receiving the packet will not be able to tell whether the Other LSRs receiving the packet will not be able to tell whether the
packet really came from the upstream router, but that makes no packet really came from the upstream router, but that makes no
difference in the processing of the packet. The upstream LSR will difference in the processing of the packet. The upstream LSR will
see its own upstream LSR in the label, and this will enable it to see its own upstream LSR in the label, and this will enable it to
determine that the packet is traveling upstream. determine that the packet is traveling upstream.
7. Root node redundancy 7. Root Node Redundancy
The root node is a single point of failure for an MP LSP, whether The root node is a single point of failure for an MP LSP, whether the
this is P2MP or MP2MP. The problem is particularly severe for MP2MP MP LSP is P2MP or MP2MP. The problem is particularly severe for
LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same MP2MP LSPs. In the case of MP2MP LSPs, all leaf nodes must use the
root node to set up the MP2MP LSP, because otherwise the traffic same root node to set up the MP2MP LSP, because otherwise the traffic
sourced by some leafs is not received by others. Because the root sourced by some leafs is not received by others. Because the root
node is the single point of failure for an MP LSP, we need a fast and node is the single point of failure for an MP LSP, we need a fast and
efficient mechanism to recover from a root node failure. efficient mechanism to recover from a root node failure.
An MP LSP is uniquely identified in the network by the opaque value An MP LSP is uniquely identified in the network by the opaque value
and the root node address. It is likely that the root node for an MP and the root node address. It is likely that the root node for an MP
LSP is defined statically. The root node address may be configured LSP will be defined statically. The root node address may be
on each leaf statically or learned using a dynamic protocol. How configured on each leaf statically or learned using a dynamic
leafs learn about the root node is out of the scope of this document. protocol. How leafs learn about the root node is out of the scope of
this document.
Suppose that for the same opaque value we define two (or more) root Suppose that for the same opaque value we define two (or more) root
node addresses and we build a tree to each root using the same opaque node addresses, and we build a tree to each root using the same
value. Effectively these will be treated as different MP LSPs in the opaque value. Effectively these will be treated as different MP LSPs
network. Once the trees are built, the procedures differ for P2MP in the network. Once the trees are built, the procedures differ for
and MP2MP LSPs. The different procedures are explained in the P2MP and MP2MP LSPs. The different procedures are explained in the
sections below. sections below.
7.1. Root node redundancy - procedures for P2MP LSPs 7.1. Root Node Redundancy - Procedures for P2MP LSPs
Since all leafs have set up P2MP LSPs to all the roots, they are Since all leafs have set up P2MP LSPs to all the roots, they are
prepared to receive packets on either one of these LSPs. However, prepared to receive packets on either one of these LSPs. However,
only one of the roots should be forwarding traffic at any given time, only one of the roots should be forwarding traffic at any given time,
for the following reasons: 1) to achieve bandwidth savings in the for the following reasons: 1) to achieve bandwidth savings in the
network and 2) to ensure that the receiving leafs don't receive network and 2) to ensure that the receiving leafs don't receive
duplicate packets (since one cannot assume that the receiving leafs duplicate packets (since one cannot assume that the receiving leafs
are able to discard duplicates). How the roots determine which one are able to discard duplicates). How the roots determine which one
is the active sender is outside the scope of this document. is the active sender is outside the scope of this document.
7.2. Root node redundancy - procedures for MP2MP LSPs 7.2. Root Node Redundancy - Procedures for MP2MP LSPs
Since all leafs have set up an MP2MP LSP to each one of the root Since all leafs have set up an MP2MP LSP to each one of the root
nodes for this opaque value, a sending leaf may pick either of the nodes for this opaque value, a sending leaf may pick either of the
two (or more) MP2MP LSPs to forward a packet on. The leaf nodes two (or more) MP2MP LSPs to forward a packet on. The leaf nodes
receive the packet on one of the MP2MP LSPs. The client of the MP2MP receive the packet on one of the MP2MP LSPs. The client of the MP2MP
LSP does not care on which MP2MP LSP the packet is received, as long LSP does not care on which MP2MP LSP the packet is received, as long
as they are for the same opaque value. The sending leaf MUST only as they are for the same opaque value. The sending leaf MUST only
forward a packet on one MP2MP LSP at a given point in time. The forward a packet on one MP2MP LSP at a given point in time. The
receiving leafs are unable to discard duplicate packets because they receiving leafs are unable to discard duplicate packets because they
accept on all LSPs. Using all the available MP2MP LSPs we can accept on all LSPs. Using all the available MP2MP LSPs, we can
implement redundancy using the following procedures. implement redundancy using the following procedures.
A sending leaf selects a single root node out of the available roots A sending leaf selects a single root node out of the available roots
for a given opaque value. A good strategy MAY be to look at the for a given opaque value. A good strategy MAY be to look at the
unicast routing table and select a root that is closest in terms of unicast routing table and select a root that is closest in terms of
the unicast metric. As soon as the root address of the active root the unicast metric. As soon as the root address of the active root
disappears from the unicast routing table (or becomes less disappears from the unicast routing table (or becomes less
attractive) due to root node or link failure, the leaf can select a attractive) due to root node or link failure, the leaf can select a
new best root address and start forwarding to it directly. If new best root address and start forwarding to it directly. If
multiple root nodes have the same unicast metric, the highest root multiple root nodes have the same unicast metric, the highest root
node addresses MAY be selected, or per session load balancing MAY be node addresses MAY be selected, or per session load balancing MAY be
done over the root nodes. done over the root nodes.
All leafs participating in a MP2MP LSP MUST join to all the available All leafs participating in an MP2MP LSP MUST join all the available
root nodes for a given opaque value. Since the sending leaf may pick root nodes for a given opaque value. Since the sending leaf may pick
any MP2MP LSP, it must be prepared to receive on it. any MP2MP LSP, it must be prepared to receive on it.
The advantage of pre-building multiple MP2MP LSPs for a single opaque 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 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 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 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 is the active root. The root selection is a local leaf policy that
does not need to be coordinated with other leafs. The disadvantage does not need to be coordinated with other leafs. The disadvantage
of pre-building multiple MP2MP LSPs is that more label resources are of pre-building multiple MP2MP LSPs is that more label resources are
used, depending on how many root nodes are defined. used, depending on how many root nodes are defined.
8. Make Before Break (MBB) 8. Make Before Break (MBB)
An LSR selects as its upstream LSR for a MP LSP the LSR that is its An LSR selects the LSR that is its next hop to the root of the LSP as
next hop to the root of the LSP. When the best path to reach the its upstream LSR for an MP LSP. When the best path to reach the root
root changes the LSR must choose a new upstream LSR. Sections changes, the LSR must choose a new upstream LSR. Sections 2.4.3 and
Section 2.4.3 and Section 3.3.3 describe these procedures. 3.3.3 describe these procedures.
When the best path to the root changes the LSP may be broken When the best path to the root changes, the LSP may be broken
temporarily resulting in packet loss until the LSP "reconverges" to a temporarily resulting in packet loss until the LSP "reconverges" to a
new upstream LSR. The goal of MBB when this happens is to keep the new upstream LSR. The goal of MBB when this happens is to keep the
duration of packet loss as short as possible. In addition, there are 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 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 the LSP continues to forward packets to the previous next hop to the
root. That may occur when a link comes up or routing metrics change. 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 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 removed to limit the duration of packet loss. The procedures
described below deal with both scenarios in a way that an LSR does 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 not need to know which of the events described above caused its
upstream router for an MBB LSP to change. upstream router for an MBB LSP to change.
The MBB procedures are an optional extension to the MP LSP building The MBB procedures are an optional extension to the MP LSP building
procedures described in this draft. The procedures in this section procedures described in this document. The procedures in this
offer a make-before-break behavior, except in cases where the new section offer a make-before-break behavior, except in cases where the
path is part of a transient routing loop involving more than 2 LSRs new path is part of a transient routing loop involving more than 2
(also see Section 4). LSRs (also see Section 4).
8.1. MBB overview 8.1. MBB Overview
The MBB procedures use additional LDP signaling. The MBB procedures use additional LDP signaling.
Suppose some event causes a downstream LSR-D to select a new upstream 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 LSR-U for FEC-A. The new LSR-U may already be forwarding packets for
FEC-A; that is, to downstream LSRs 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 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 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 itself. When LSR-D receives this MBB notification, it will change
next hop for the LSP root to LSR-U. its next hop for the LSP root to LSR-U.
The assumption is that if LSR-U has received an MBB notification from 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 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 state, the LSR is capable of forwarding packets on the LSP. At that
that point LSR-U should signal LSR-D by means of an MBB notification point LSR-U should signal LSR-D by means of an MBB notification that
that it has become part of the tree identified by FEC-A and that it has become part of the tree identified by FEC-A and that LSR-D
LSR-D should initiate its switchover to the LSP. should initiate its switchover to the LSP.
At LSR-U the LSP for FEC-A may be in 1 of 3 states. At LSR-U, the LSP for FEC-A may be in 1 of 3 states.
1. There is no state for FEC-A. 1. There is no state for FEC-A.
2. State for FEC-A exists and LSR-U is waiting for MBB notification 2. State for FEC-A exists and LSR-U is waiting for MBB notification
that the LSP from the root to it exists. 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. or it is the root node for FEC-A.
After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 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 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 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 #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 from LSR-D while waiting for an MBB notification from its upstream
LSR for the LSP. When LSR-U receives the MBB notification from LSR-U LSR for the LSP. When LSR-U receives the MBB notification from LSR-
it transitions to LSP state #3 and sends an MBB notification to U, it transitions to LSP state #3 and sends an MBB notification to
LSR-D. LSR-D.
8.2. The MBB Status code 8.2. The MBB Status Code
As noted in Section 8.1, the procedures to establish an MBB MP LSP As noted in Section 8.1, the procedures for establishing an MBB MP
are different from those to establish normal MP LSPs. LSP are different from those for establishing normal MP LSPs.
When a downstream LSR sends a Label Mapping message for MP LSP to its 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 upstream LSR, it MAY include an LDP MP Status TLV that carries an MBB
Status Code to indicate MBB procedures apply to the LSP. This new Status Code to indicate that MBB procedures apply to the LSP. This
MBB Status Code MAY also appear in an LDP Notification message used new MBB Status Code MAY also appear in an LDP Notification message
by an upstream LSR to signal LSP state #3 to the downstream LSR; that used by an upstream LSR to signal LSP state #3 to the downstream LSR;
is, that the upstream LSRs state for the LSP exists and that it has that is, that the upstream LSRs state for the LSP exists and that it
received notification from its upstream LSR that the LSP is in state has received notification from its upstream LSR that the LSP is in
#3. state #3.
The MBB Status is a type of the LDP MP Status Value Element as The MBB Status is a type of the LDP MP Status Value Element as
described in Section 5.1. It is encoded as follows: described in Section 5.1. It is encoded as follows:
0 1 2 3 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 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 | | MBB Type = 1 | Length = 1 | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBB Type: Type 1 (to be assigned by IANA) MBB Type: Type 1
Length: 1
Length: 1
Status code: 1 = MBB request Status Code: 1 = MBB request
2 = MBB ack 2 = MBB ack
8.3. The MBB capability 8.3. The MBB Capability
An LSR MAY advertise that it is capable of handling MBB LSPs using An LSR MAY advertise that it is capable of handling MBB LSPs using
the capability advertisement as defined in [RFC5561]. The LDP MP MBB the capability advertisement as defined in [RFC5561]. The LDP MP MBB
capability has the following format: capability has the following format:
0 1 2 3 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 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|0| LDP MP MBB Capability | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Note: LDP MP MBB Capability (Pending IANA assignment) LDP MP MBB Capability: The MBB Capability Parameter (0x050A)
S: As specified in [RFC5561] S: As specified in [RFC5561]
If an LSR has not advertised that it is MBB capable, its LDP peers 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 MUST NOT send it messages that include MBB parameters. If an LSR
receives a Label Mapping message with a MBB parameter from downstream receives a Label Mapping message with an MBB parameter from
LSR-D and its upstream LSR-U has not advertised that it is MBB downstream LSR-D and its upstream LSR-U has not advertised that it is
capable, the LSR MUST send an MBB notification immediatly to LSR-U MBB capable, the LSR MUST send an MBB notification immediately to
(see Section 8.4). If this happens an MBB MP LSP will not be 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. established, but a normal MP LSP will be the result.
8.4. The MBB procedures 8.4. The MBB Procedures
8.4.1. Terminology 8.4.1. Terminology
1. MBB LSP <X, Y>: A P2MP or MP2MP Make Before Break (MBB) LSP entry 1. MBB LSP <X, Y>: A P2MP or MP2MP Make Before Break (MBB) LSP entry
with Root Node Address X and Opaque Value Y. with root node address X and opaque value Y.
2. A(N, L): An Accepting element that consists of an upstream 2. A(N, L): An accepting element that consists of an upstream
Neighbor N and Local label L. This LSR assigned label L to neighbor N and Local label L. This LSR assigned label L to
neighbor N for a specific MBB LSP. For an active element the neighbor N for a specific MBB LSP. For an active element, the
corresponding Label is stored in the label forwarding database. corresponding label is stored in the label forwarding database.
3. iA(N, L): An inactive Accepting element that consists of an 3. iA(N, L): An inactive accepting element that consists of an
upstream neighbor N and local Label L. This LSR assigned label L upstream neighbor N and local label L. This LSR assigned label L
to neighbor N for a specific MBB LSP. For an inactive element to neighbor N for a specific MBB LSP. For an inactive element,
the corresponding Label is not stored in the label forwarding the corresponding label is not stored in the label forwarding
database. database.
4. F(N, L): A Forwarding state that consists of downstream Neighbor 4. F(N, L): A Forwarding state that consists of downstream neighbor N
N and Label L. This LSR is sending label packets with label L to and label L. This LSR is sending label packets with label L to
neighbor N for a specific FEC. neighbor N for a specific FEC.
5. F'(N, L): A Forwarding state that has been marked for sending a 5. F'(N, L): A Forwarding state that has been marked for sending an
MBB Notification message to Neighbor N with Label L. MBB Notification message to neighbor N with label L.
6. MBB Notification <X, Y, L>: A LDP notification message with a MP 6. MBB Notification <X, Y, L>: An LDP notification message with an MP
LSP <X, Y>, Label L and MBB Status code 2. LSP <X, Y>, label L, and MBB Status code 2.
7. MBB Label Mapping <X, Y, L>: A P2MP Label Mapping or MP2MP Label 7. MBB Label Mapping <X, Y, L>: A P2MP Label Mapping or MP2MP Label
Mapping downstream with a FEC element <X, Y>, Label L and MBB Mapping downstream with a FEC element <X, Y>, label L, and MBB
Status code 1. Status code 1.
8.4.2. Accepting elements 8.4.2. Accepting Elements
An accepting element represents a specific label value L that has An accepting element represents a specific label value L that has
been advertised to a neighbor N for a MBB LSP <X, Y> and is a been advertised to a neighbor N for an MBB LSP <X, Y> and is a
candidate for accepting labels switched packets on. An LSR can have candidate for accepting labels switched packets on. An LSR can have
two accepting elements for a specific MBB LSP <X, Y> LSP, only one of two accepting elements for a specific MBB LSP <X, Y> LSP, only one of
them MUST be active. An active element is the element for which the them MUST be active. An active element is the element for which the
label value has been installed in the label forwarding database. An label value has been installed in the label forwarding database. An
inactive accepting element is created after a new upstream LSR is inactive accepting element is created after a new upstream LSR is
chosen and is pending to replace the active element in the label chosen and replacement the active element in the label forwarding
forwarding database. Inactive elements only exist temporarily while database is pending. Inactive elements only exist temporarily while
switching to a new upstream LSR. Once the switch has been completed switching to a new upstream LSR. Once the switch has been completed,
only one active element remains. During network convergence it is only one active element remains. During network convergence, it is
possible that an inactive accepting element is created while an other possible that an inactive accepting element is created while another
inactive accepting element is pending. If that happens the older inactive accepting element is pending. If that happens, the older
inactive accepting element MUST be replaced with an newer inactive inactive accepting element MUST be replaced with a newer inactive
element. If an accepting element is removed a Label Withdraw has to element. If an accepting element is removed, a Label Withdraw has to
be send for label L to neighbor N for <X, Y>. be sent for label L to neighbor N for <X, Y>.
8.4.3. Procedures for upstream LSR change 8.4.3. Procedures for Upstream LSR Change
Suppose a node Z has a MBB LSP <X, Y> with an active accepting Suppose a node Z has an MBB LSP <X, Y> with an active accepting
element A(N1, L1). Due to a routing change it detects a new best 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 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, a new local label L2 and creates an inactive accepting element iA(N2,
L2). Node Z sends MBB Label Mapping <X, Y, L2>to N2 and waits for L2). Node Z sends MBB Label Mapping <X, Y, L2> to N2 and waits for
the new upstream LSR N2 to respond with a MBB Notification for <X, Y, the new upstream LSR N2 to respond with an MBB Notification for <X,
L2>. During this transition phase there are two accepting elements, Y, L2>. During this transition phase, there are two accepting
the element A(N1, L1) still accepting packets from N1 over label L1 elements, the element A(N1, L1) still accepting packets from N1 over
and the new inactive element iA(N2, L2). label L1 and the new inactive element iA(N2, L2).
While waiting for the MBB Notification from upstream LSR N2, it is While waiting for the MBB Notification from upstream LSR N2, it is
possible that another transition occurs due to a routing change. possible that another transition occurs due to a routing change.
Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) 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. is created and the old inactive element iA(N2, L2) MUST be removed.
A label withdraw MUST be sent to N2 for <X, Y, L2&gt. The MBB A Label Withdraw MUST be sent to N2 for <X, Y, L2>. The MBB
Notification for <X, Y, L2> from N2 will be ignored because the Notification for <X, Y, L2> from N2 will be ignored because the
inactive element is removed. inactive element is removed.
It is possible that the MBB Notification from upstream LSR is never It is possible that the MBB Notification from upstream LSR is never
received due to link or node failure. To prevent waiting received due to link or node failure. To prevent waiting
indefinitely for the MBB Notification a timeout SHOULD be applied. indefinitely for the MBB Notification, a timeout SHOULD be applied.
As soon as the timer expires, the procedures in Section 8.4.5 are As soon as the timer expires, the procedures in Section 8.4.5 are
applied as if a MBB Notification was received for the inactive applied as if an MBB Notification was received for the inactive
element. If a downstream LSR detects that the old upstream LSR went element. If a downstream LSR detects that the old upstream LSR went
down while waiting for the MBB Notification from the new upstream down while waiting for the MBB Notification from the new upstream
LSR, the downstream LSR can immediately proceed without waiting for LSR, the downstream LSR can immediately proceed without waiting for
the timer to expire. the timer to expire.
8.4.4. Receiving a Label Mapping with MBB status code 8.4.4. Receiving a Label Mapping with MBB Status Code
Suppose node Z has state for a MBB LSP <X, Y> and receives a MBB Suppose node Z has state for an MBB LSP <X, Y> and receives an MBB
Label Mapping <X, Y, L2> from N2. A new forwarding state F(N2, L2) Label Mapping <X, Y, L2> 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 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 has an active accepting element or if node Z is the root of the
LSP a MBB notification <X, Y, L2)> is sent to node N2. If node Z has MBB LSP, an MBB notification <X, Y, L2)> is sent to node N2. If node
an inactive accepting element it marks the Forwarding state as <X, Y, Z has an inactive accepting element, it marks the Forwarding state as
F'(N2, L2)>. If router Z upstream LSR for <X, Y> happens to be N2, <X, Y, F'(N2, L2)>. If the router Z upstream LSR for <X, Y> happens
then Z MUST NOT send an MBB notification to N2 at once. Sending the to be N2, then Z MUST NOT send an MBB notification to N2 at once.
MBB notification to N2 must be done only after Z upstream for <X, Y> Sending the MBB notification to N2 must be done only after Z upstream
stops being N2. for <X, Y> stops being N2.
8.4.5. Receiving a Notification with MBB status code 8.4.5. Receiving a Notification with MBB Status Code
Suppose node Z receives a MBB Notification <X, Y, L> from N. If node Suppose node Z receives an MBB Notification <X, Y, L> from N. If
Z has state for MBB LSP <X, Y> and an inactive accepting element node Z has state for MBB LSP <X, Y> and an inactive accepting element
iA(N, L) that matches with N and L, we activate this accepting 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 element and install label L in the label-forwarding database. If
other active accepting was present it will be removed from the label another active accepting element was present, it will be removed from
forwarding database. the label-forwarding database.
If this MBB LSP <X, Y> also has Forwarding states marked for sending If this MBB LSP <X, Y> also has Forwarding states marked for sending
MBB Notifications, like <X, Y, F'(N2, L2)>, MBB Notifications are MBB Notifications, like <X, Y, F'(N2, L2)>, MBB Notifications are
sent to these downstream LSRs. If node Z receives a MBB Notification sent to these downstream LSRs. If node Z receives an MBB
for an accepting element that is not inactive or does not match the Notification for an accepting element that is not inactive or does
Label value and Neighbor address, the MBB notification is ignored. not match the label value and neighbor address, the MBB notification
is ignored.
8.4.6. Node operation for MP2MP LSPs 8.4.6. Node Operation for MP2MP LSPs
The procedures described above apply to the downstream path of a The procedures described above apply to the downstream path of an
MP2MP LSP. The upstream path of the MP2MP is setup as normal without MP2MP LSP. The upstream path of the MP2MP is set up as normal
including a MBB Status code. If the MBB procedures apply to a MP2MP without including an MBB Status code. If the MBB procedures apply to
downstream FEC element, the upstream path to a node N is only an MP2MP downstream FEC element, the upstream path to a node N is
installed in the label forwarding database if node N is part of the only installed in the label-forwarding database if node N is part of
active accepting element. If node N is part of an inactive accepting the active accepting element. If node N is part of an inactive
element, the upstream path is installed when this inactive accepting accepting element, the upstream path is installed when this inactive
element is activated. accepting element is activated.
9. Typed Wildcard for mLDP FEC Element 9. Typed Wildcard for mLDP FEC Element
The format of the mLDP FEC Typed Wildcard FEC is as follows: The format of the mLDP FEC Typed Wildcard FEC is as follows:
0 1 2 3 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 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 | Len = 2 | AFI ~ | Typed Wcard | Type | Len = 2 | AFI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type Wcard: As specified in [RFC5918] Typed Wcard: As specified in [RFC5918]
Type: The type of FEC Element Type. Either the P2MP FEC Element or Type: The type of FEC Element Type. Either the P2MP FEC Element or
the MP2MP FEC Element using the values defined for those FEC the MP2MP FEC Element using the values defined for those FEC
Elements when carried in the FEC TLV as defined in this document. Elements when carried in the FEC TLV as defined in this document.
Len: Len FEC Type Info, two octets (=0x02). Len: Len FEC Type Info, two octets (=0x02).
AFI: Address Family, two octet quantity containing a value from AFI: Address Family, two-octet quantity containing a value from
IANA's "Address Family Numbers" registry. IANA's "Address Family Numbers" registry.
10. Security Considerations 10. Security Considerations
The same security considerations apply as for the base LDP The same security considerations apply as those for the base LDP
specification, as described in [RFC5036]. specification, as described in [RFC5036].
The protocol specified in this document does not provide any The protocol specified in this document does not provide any
authorization mechanism for controlling the set of LSRs that may join authorization mechanism for controlling the set of LSRs that may join
a given MP LSP. If such authorization is desirable, additional a given MP LSP. If such authorization is desirable, additional
mechanisms, outside the scope of this document, are needed. Note mechanisms, outside the scope of this document, are needed. Note
that authorization policies cannot be implemented and/or configure that authorization policies cannot be implemented and/or configured
solely at the root node of the LSP, because the root node does not solely at the root node of the LSP, because the root node does not
learn the identities of all the leaf nodes. learn the identities of all the leaf nodes.
11. IANA Considerations 11. IANA Considerations
This document creates three new registries to be managed by IANA. Per this document, IANA has created 3 new registries.
1. "LDP MP Opaque Value Element basic type" 1. "LDP MP Opaque Value Element basic type"
The range is 0-255, with the following values allocated in this The range is 0-255, with the following values allocated in this
document: document:
0: Reserved
1: Generic LSP identifier 1: Generic LSP identifier
255: Extended Type field is present in the following two bytes 255: Extended Type field is present in the following two bytes
The allocation policy for this space is 'Standards Action with The allocation policy for this space is 'Standards Action with
Early Allocation' Early Allocation'.
2. "LDP MP Opaque Value Element extended type" 2. "LDP MP Opaque Value Element extended type"
The range is 0-65335, with the following allocation policies: The range is 0-65535, with the following allocation policies:
0-32767: Standards Action with Early Allocation 0-32767: Standards Action with Early Allocation
32768-65535: First Come, First Served 32768-65535: First Come, First Served
3. "LDP MP Status Value Element type" 3. "LDP MP Status Value Element type"
The range is 0-255, with the following value allocated in this The range is 0-255, with the following values allocated in this
document: document:
0: Reserved
1: MBB Status 1: MBB Status
The allocation policy for this space is 'Standards Action with The allocation policy for this space is 'Standards Action with
Early Allocation' Early Allocation'.
The requested code point values listed below have been allocated by The code point values listed below have been allocated by IANA
IANA through early allocation. through early allocation.
This document requires allocation of three new code points from the IANA allocated three new code points from the LDP registry
IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type "Forwarding Equivalence Class (FEC) Type Name Space". The values
Name Space". The values are: are:
P2MP FEC type - requested value 0x06 P2MP FEC type - requested value 0x06
MP2MP-up FEC type - requested value 0x07 MP2MP-up FEC type - requested value 0x07
MP2MP-down FEC type - requested value 0x08 MP2MP-down FEC type - requested value 0x08
This document requires the assignment of three new code points for IANA assigned three new code points for new Capability Parameter TLVs
three new Capability Parameter TLVs from the IANA managed LDP from the LDP registry "TLV Type Name Space", corresponding to the
registry "TLV Type Name Space", corresponding to the advertisement of advertisement of the P2MP, MP2MP, and MBB capabilities. The values
the P2MP, MP2MP and MBB capabilities. The values requested are: are:
P2MP Capability Parameter - requested value 0x0508 P2MP Capability Parameter - 0x0508
MP2MP Capability Parameter - requested value 0x0509 MP2MP Capability Parameter - 0x0509
MBB Capability Parameter - requested value 0x050A MBB Capability Parameter - 0x050A
This document requires the assignment of a LDP Status Code to IANA assigned an LDP Status Code to indicate that an LDP MP Status
indicate a LDP MP Status TLV is following in the Notification TLV is following in the Notification message. The value assigned in
message. The value requested from the IANA managed LDP registry "LDP the LDP registry "LDP Status Code Name Space" is:
Status Code Name Space" is:
LDP MP status - requested value 0x00000040 LDP MP status - requested value 0x00000040
This document requires the assigment of a new code point for a LDP MP IANA assigned a new code point for an LDP MP Status TLV. The value
Status TLV. The value requested from the IANA managed LDP registry assigned in the LDP registry "LDP TLV Type Name Space" is:
"LDP TLV Type Name Space" is:
LDP MP Status TLV Type - requested value 0x096F LDP MP Status TLV Type - requested value 0x096F
12. Acknowledgments 12. Acknowledgments
The authors would like to thank the following individuals for their The authors would like to thank the following individuals for their
review and contribution: Nischal Sheth, Yakov Rekhter, Rahul review and contribution: Nischal Sheth, Yakov Rekhter, Rahul
Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert,
George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin
and Ben Niven-Jenkins. and Ben Niven-Jenkins.
13. Contributing authors 13. Contributing Authors
Below is a list of the contributing authors in alphabetical order: Below is a list of the contributing authors in alphabetical order:
Shane Amante Shane Amante
Level 3 Communications, LLC Level 3 Communications, LLC
1025 Eldorado Blvd 1025 Eldorado Blvd
Broomfield, CO 80021 Broomfield, CO 80021
US US
Email: Shane.Amante@Level3.com EMail: Shane.Amante@Level3.com
Luyuan Fang Luyuan Fang
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
US US
Email: lufang@cisco.com EMail: lufang@cisco.com
Hitoshi Fukuda Hitoshi Fukuda
NTT Communications Corporation NTT Communications Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku 1-1-6, Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019, Tokyo 100-8019,
Japan Japan
Email: hitoshi.fukuda@ntt.com EMail: hitoshi.fukuda@ntt.com
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
Tokyo Opera City Tower Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku, 3-20-2 Nishi Shinjuku, Shinjuku-ku,
Tokyo 163-1421, Tokyo 163-1421,
Japan Japan
Email: y.kamite@ntt.com EMail: y.kamite@ntt.com
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti@juniper.net EMail: kireeti@juniper.net
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
Lannion, Cedex 22307
France
EMail: jeanlouis.leroux@francetelecom.com
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: ina@juniper.net EMail: ina@juniper.net
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
Lannion, Cedex 22307
France
Email: jeanlouis.leroux@francetelecom.com
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA, 01719 Boxborough, MA, 01719
E-mail: bobthomas@alum.mit.edu EMail: bobthomas@alum.mit.edu
Lei Wang Lei Wang
Telenor Telenor
Snaroyveien 30 Snaroyveien 30
Fornebu 1331 Fornebu 1331
Norway Norway
Email: lei.wang@telenor.com EMail: lei.wang@telenor.com
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
1831 Diegem 1831 Diegem
Belgium Belgium
E-mail: ice@cisco.com EMail: ice@cisco.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [ITU.V42.1994]
Specification", RFC 5036, October 2007. International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 1994.
http://www.itu.int/rec/T-REC-V.42-200203-I
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Label Assignment and Context-Specific Label Space", "LDP Specification", RFC 5036, October 2007.
RFC 5331, August 2008.
[I-D.ietf-mpls-ldp-upstream] [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment Label Assignment and Context-Specific Label Space", RFC
for LDP", draft-ietf-mpls-ldp-upstream-10 (work in 5331, August 2008.
progress), February 2011.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, August 2010. (FEC)", RFC 5918, August 2010.
[ITU.V42.1994] [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
International Telecommunications Union, "Error-correcting Assignment for LDP", RFC 6389, September 2011.
Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 1994.
http://www.itu.int/rec/T-REC-V.42-200203-I
14.2. Informative References 14.2. Informative References
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [ISO3309] International Organization for Standardization, "ISO
"Extensions to Resource Reservation Protocol - Traffic Information Processing Systems - Data Communication -
Engineering (RSVP-TE) for Point-to-Multipoint TE Label High-Level Data Link Control Procedure - Frame Structure",
Switched Paths (LSPs)", RFC 4875, May 2007. ISO 3309, 3rd Edition, October 1984.
[I-D.ietf-mpls-mp-ldp-reqs] [L3VPN-MCAST]
Morin, T., "Requirements for Point-To-Multipoint Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
Extensions to the Label Distribution Protocol", MPLS/BGP IP VPNs", Work in Progress, January 2010.
draft-ietf-mpls-mp-ldp-reqs-06 (work in progress),
December 2010.
[I-D.ietf-l3vpn-2547bis-mcast] [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., "Multiprotocol Label Switching (MPLS) Label Switching
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in Router (LSR) Management Information Base (MIB)", RFC 3813,
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work June 2004.
in progress), January 2010.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions
Multicast Encapsulations", RFC 5332, August 2008. of Managed Objects for the Multiprotocol Label Switching
(MPLS), Label Distribution Protocol (LDP)", RFC 3815, June
2004.
Authors' Addresses [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.
Ina Minei (editor) [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
Juniper Networks "MPLS Multicast Encapsulations", RFC 5332, August 2008.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: ina@juniper.net [RFC6348] Le Roux, J., Ed., and T. Morin, Ed., "Requirements for
Point-to-Multipoint Extensions to the Label Distribution
Protocol", RFC 6348, September 2011.
Authors' Addresses
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
EMail: ice@cisco.com
Email: ice@cisco.com Ina Minei (editor)
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: ina@juniper.net
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
EMail: kireeti@juniper.net
Email: kireeti@juniper.net
Bob Thomas Bob Thomas
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough 01719 Boxborough 01719
US US
EMail: bobthomas@alum.mit.edu
Email: bobthomas@alum.mit.edu
 End of changes. 277 change blocks. 
700 lines changed or deleted 728 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/