draft-ietf-mpls-ldp-p2mp-04.txt   draft-ietf-mpls-ldp-p2mp-05.txt 
Network Working Group I. Minei (Editor) Network Working Group I. Minei (Editor)
Internet-Draft K. Kompella Internet-Draft K. Kompella
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: August 25, 2008 I. Wijnands (Editor) Expires: November 2, 2008 I. Wijnands (Editor)
B. Thomas B. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
February 22, 2008
Label Distribution Protocol Extensions for Point-to-Multipoint and Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-ldp-p2mp-04 draft-ietf-mpls-ldp-p2mp-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2008. This Internet-Draft will expire on November 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes extensions to the Label Distribution Protocol This document describes extensions to the Label Distribution Protocol
(LDP) for the setup of point to multi-point (P2MP) and multipoint-to- (LDP) for the setup of point to multi-point (P2MP) and multipoint-to-
multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol
Label Switching (MPLS) networks. The solution relies on LDP without Label Switching (MPLS) networks. LDP constructs the P2MP or MP2MP
requiring a multicast routing protocol in the network. Protocol LSPs without interacting with or relying upon any other multicast
elements and procedures for this solution are described for building tree construction protocol. Protocol elements and procedures for
such LSPs in a receiver-initiated manner. There can be various this solution are described for building such LSPs in a receiver-
applications for P2MP/MP2MP LSPs, for example IP multicast or support initiated manner. There can be various applications for P2MP/MP2MP
for multicast in BGP/MPLS L3VPNs. Specification of how such LSPs, for example IP multicast or support for multicast in BGP/MPLS
applications can use a LDP signaled P2MP/MP2MP LSP is outside the L3VPNs. Specification of how such applications can use a LDP
scope of this document. signaled P2MP/MP2MP LSP is outside the scope of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5
2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 5 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6
2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6
2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 7 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8
2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8
2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 8 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 9
2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 11 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 11
3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12
4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 12 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13
4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 13 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 13
4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 13 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 14
4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 14 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 14
4.3.1. MP2MP Label Map upstream and downstream . . . . . . . 15 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16
4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 17 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 19
5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 18 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 20
5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 19 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 20
5.2. LDP Messages containing LDP MP Status messages . . . . . . 20 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 20
5.2.1. LDP MP Status sent in LDP notification messages . . . 20 5.2. LDP Messages containing LDP MP Status messages . . . . . . 21
5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 20 5.2.1. LDP MP Status sent in LDP notification messages . . . 21
6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 21 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 22
6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 21 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 22
6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 21 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 23
6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 22 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 23
7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 22 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 23
7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 23 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 23
7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 23 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 24
8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 24 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 24
8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 24 8. MP LSP micro loops . . . . . . . . . . . . . . . . . . . . . . 25
8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 25 8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 25
8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 26 8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 26
8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 26 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26
8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 26 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 26
8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 27 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 27
8.4.3. Procedures for upstream LSR change . . . . . . . . . . 27 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28
8.4.4. Receiving a Label Map with MBB status code . . . . . . 28 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29
8.4.5. Receiving a Notification with MBB status code . . . . 28 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29
8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 29 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 9.4.4. Receiving a Label Map with MBB status code . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9.4.5. Receiving a Notification with MBB status code . . . . 31
12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 30 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . . 32 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
The LDP protocol is described in [1]. It defines mechanisms for The LDP protocol is described in [1]. It defines mechanisms for
setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs
in the network. This document describes extensions to LDP for 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. A MP2MP
skipping to change at page 5, line 5 skipping to change at page 5, line 5
The following terminology is taken from [9]. The following terminology is taken from [9].
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 that connects a set of leaf nodes, acting MP2MP LSP: An LSP that connects a set of nodes, such that traffic
indifferently as ingress or egress. sent by any node in the LSP is 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: Source of the P2MP LSP, also referred to as root node. Ingress LSR: An ingress LSR for a particular LSP is an LSR that can
send a data packet along the LSP. MP2MP LSPs can have multiple
ingress LSRs, P2MP LSPs have just one, and that node is often
referred to as the "root node".
Egress LSR: One of potentially many destinations of an LSP, also Egress LSR: An egress LSR for a particular LSP is an LSR that can
referred to as leaf node in the case of P2MP and MP2MP LSPs. remove a data packet from that LSP for further processing. P2P
and MP2P LSPs have only a single egress node, but P2MP and MP2MP
LSPs can have multiple egress nodes.
Transit LSR: An LSR that has one or more directly connected Transit LSR: An LSR that has reachability to a) the root of the MP
downstream LSRs. LSP via a directly connected upstream LSR and b) via one or more
directly 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
referred in the context of a P2MP LSP. In the context of a MP2MP
LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and
can also be a Bud LSR.
2. Setting up P2MP LSPs with LDP 2. Setting up P2MP LSPs with LDP
A P2MP LSP consists of a single root node, zero or more transit nodes 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 and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and
tear-down. Leaf nodes also install forwarding state to deliver the 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 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 is done is outside the scope of this document. Transit nodes install
MPLS forwarding state and propagate the P2MP LSP setup (and tear- MPLS forwarding state and propagate the P2MP LSP setup (and tear-
down) toward the root. The root node installs forwarding state to down) toward the root. The root node installs forwarding state to
map traffic into the P2MP LSP; how the root node determines which map traffic into the P2MP LSP; how the root node determines which
skipping to change at page 7, line 37 skipping to change at page 8, line 13
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 leaf (and bud) LSRs, but need not be interpreted by is meaningful to Ingress LSRs and Leaf LSRs, but need not be
non-leaf LSRs. interpreted by Transit LSRs.
The LDP MP Opaque Value Element is encoded as follows: The LDP MP Opaque Value 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(TBD) | Length | Value ... | | Type(TBD) | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| | | |
skipping to change at page 9, line 36 skipping to change at page 10, line 7
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 Map message (other than the root node) that receives a P2MP Label Map 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 Map 2.4.1. Label Map
The following lists procedures for generating and processing P2MP The remainder of this section specifies the procedures for
Label Map messages for nodes that participate in a P2MP LSP. An LSR originating P2MP Label Map messages and for processing received P2MP
should apply those procedures that apply to it, based on its role in label map messages for a particular LSP. The procedures for a
the P2MP LSP. particular LSR depend upon the role that LSR plays in the LSP
(ingress, transit, or egress).
For the approach described here we use downstream assigned labels. All labels discussed here are downstream-assigned [11] except those
On Ethernet networks this may be less optimal, see Section 6. which 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'
A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U Each node that is either a Leaf or Transit LSR of an MP LSP needs to
which lies on the best path from Z to the root node X. If there are use the procedures below to select an upstream LSR. A node Z that
more than one such LDP peers, only one of them is picked. U is Z's wants to join a MP LSP <X, Y> determines the LDP peer U which is Z's
next-hop on the best path from Z to the root node X. If there is more
than one such LDP peer, only one of them is picked. U is Z's
"Upstream LSR" for <X, Y>. "Upstream LSR" for <X, Y>.
When there are several candidate upstream LSRs, the LSR MAY select When there are several candidate upstream LSRs, the LSR MAY select
one upstream LSR using the following procedure: one upstream LSR using the following procedure:
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 = (Sum Opaque value) modulo N, 2. The following hash is performed: H = (Sum Opaque value) modulo N,
where N is the number of candidate upstream LSRs where N is the number of candidate upstream LSRs
skipping to change at page 11, line 15 skipping to change at page 11, line 34
2.4.2. Label Withdraw 2.4.2. Label Withdraw
The following lists procedures for generating and processing P2MP The following lists procedures for generating and processing P2MP
Label Withdraw messages for nodes that participate in a P2MP LSP. An Label Withdraw messages for nodes that participate in a P2MP LSP. An
LSR should apply those procedures that apply to it, based on its role LSR should apply those procedures that apply to it, based on its role
in the P2MP LSP. in the P2MP LSP.
2.4.2.1. Leaf Operation 2.4.2.1. 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 is no longer a leaf of the P2MP LSP, it SHOULD send document) that it has no downstream neighbors in that LSP, and that
it has no need to be an egress LSR for that LSP, then it SHOULD send
a Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L a 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>. is 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
skipping to change at page 11, line 38 skipping to change at page 12, line 12
<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 The procedure when the root node of a P2MP LSP receives a Label
Withdraw message are the same as for transit nodes, except that it Withdraw message are the same as for transit nodes, except that it
would not propagate the Label Withdraw upstream (as it has no would not propagate the Label Withdraw upstream (as it has no
upstream). upstream).
2.4.2.4. Upstream LSR change 2.4.3. Upstream LSR change
If, for a given node Z participating in a P2MP LSP <X, Y>, the If, for a given node Z participating in a P2MP LSP <X, Y>, the
upstream LSR changes, say from U to U', then Z MUST update its upstream LSR changes, say from U to U', then Z MUST update its
forwarding state by deleting the state for label L, allocating a new forwarding state by deleting the state for label L, allocating a new
label, L', for <X,Y>, and installing the forwarding state for L'. In label, L', for <X,Y>, and installing the forwarding state for L'. In
addition Z MUST send a Label Map <X, Y, L'> to U' and send a Label addition Z MUST send a Label Map <X, Y, L'> to U' and send a Label
Withdraw <X, Y, L> to U. Withdraw <X, Y, L> to U.
3. Shared Trees 3. Shared Trees
skipping to change at page 12, line 48 skipping to change at page 13, line 22
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 as Ingress or Egress LSR. A leaf node participates in
the setup of an MP2MP LSP by establishing both a downstream LSP, 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 a MP2MP LSP to the receivers is identical to that for a P2MP
LSP. Traffic from a leaf node follows the upstream LSP toward the LSP. Traffic from a downstream node follows the upstream LSP toward
root node and branches downward along the downstream LSP as required the root node and branches downward along the downstream LSP as
to reach other leaf nodes. Mapping traffic to the MP2MP LSP may required to reach other leaf nodes. A packet that is received from a
happen at any leaf node. How that mapping is established is outside downstream node MUST never be forwarded back out to that same node.
the scope of this document. Mapping traffic to the MP2MP LSP may happen at any leaf node. How
that mapping is established is outside the scope of this document.
Due to how a MP2MP LSP is built a leaf LSR that is sending packets on Due to how a MP2MP LSP is built a leaf LSR that is sending packets on
the MP2MP LSP does not receive its own packets. There is also no 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 a MP2MP LSP will not traverse a link more than
once, with the exception of LAN links which are discussed in once, with the possible exception of LAN links (see Section 4.3.1),
Section 4.3.1 if the procedures of [4] are not provided.
4.1. Support for MP2MP LSP setup with LDP 4.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 [6]. An implementation supporting the capabilities as defined in [6]. An implementation supporting the
MP2MP procedures specified in this document MUST implement 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.
skipping to change at page 14, line 9 skipping to change at page 14, line 37
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 (TBD) and MP2MP upstream type (TBD).
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 [4], the MPLS labels used
are "downstream-assigned" [11], even if they are bound to the
"upstream FEC element".
4.3. Using the MP2MP FEC Elements 4.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>): a
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 node 3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root
address X and opaque value Y used for a downstream MP2MP LSP. node address X and opaque value Y used for a downstream MP2MP
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 Label Map downstream <X, Y, L>: A Label Map message with a 5. MP2MP-D Label Map <X, Y, L>: A Label Map message with a FEC TLV
FEC TLV with a single MP2MP downstream FEC Element <X, Y> and with a single MP2MP downstream FEC Element <X, Y> and label TLV
with label L.
6. MP2MP-U Label Map <X, Y, Lu>: A Label Map message with a FEC TLV
with a single MP2MP upstream FEC Element <X, Y> and label TLV
with label Lu.
7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with
a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
label TLV with label L. label TLV with label L.
6. MP2MP Label Map upstream <X, Y, Lu>: A Label Map message with a 8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with
FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and
TLV with label Lu. label TLV with label Lu.
7. MP2MP Label Withdraw downstream <X, Y, L>: a Label Withdraw 9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a
message with a FEC TLV with a single MP2MP downstream FEC Element FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
<X, Y> and label TLV with label L. label TLV with label L.
8. MP2MP Label Withdraw upstream <X, Y, Lu>: a Label Withdraw 10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a
message with a FEC TLV with a single MP2MP upstream FEC Element FEC TLV with a single MP2MP upstream FEC Element <X, Y> and
<X, Y> and label TLV with label Lu. label 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 which 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 Map message (other then the root node) that receives a MP2MP Label Map 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 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
leaf of the MP2MP LSP. leaf of the MP2MP LSP.
4.3.1. MP2MP Label Map upstream and downstream 4.3.1. MP2MP Label Map
The following lists procedures for generating and processing MP2MP The remainder of this section specifies the procedures for
Label Map messages for nodes that participate in a MP2MP LSP. An LSR originating MP2MP Label Map messages and for processing received
should apply those procedures that apply to it, based on its role in MP2MP label map messages for a particular LSP. The procedures for a
the MP2MP LSP. particular LSR depend upon the role that LSR plays in the LSP
(ingress, transit, or egress).
For the approach described here if there are several receivers for a All labels discussed here are downstream-assigned [11] except those
MP2MP LSP on a LAN, packets are replicated over the LAN. This may which are assigned using the procedures of Section 6.
not be optimal; optimizing this case is for further study, see [4].
4.3.1.1. Determining one's upstream MP2MP LSR 4.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 a 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.
4.3.1.2. Determining one's downstream MP2MP LSR 4.3.1.2. Determining one's downstream MP2MP LSR
A LDP peer U which receives a MP2MP Label Map downstream from a LDP A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D
peer D will treat D as downstream MP2MP LSR. will treat D as downstream MP2MP LSR.
4.3.1.3. MP2MP leaf node operation 4.3.1.3. Installing the upstream path of a MP2MP LSP
There are two methods for installing the upstream path of a MP2MP LSP
to a downstream neighbor.
1. We can install the upstream MP2MP path (to a downstream neighbor)
based on receiving a MP2MP-D Label Map from the downstream
neighbor. This will install the upstream path on a per hop by
hop bases.
2. We install the upstream MP2MP path (to a downstream neighbor)
based on receiving a MP2MP-U Label Map from the upstream
neighbor. An LSR does not need to wait for the MP2MP-U Label Map
if it is the root of the MP2MP LSP or already has received an
MP2MP-U Label Map from the upstream neighbor. We call this
method ordered mode. The typical result of this mode is that the
downstream path of the MP2MP is build hop by hop towards the
root. Once the root is reached, the root node will trigger a
MP2MP-U Label Map to the downstream neighbor(s).
For setting up the upstream path of a MP2MP LSP ordered mode MUST be
used. Due to ordered mode the upstream path of the MP2MP LSP is
installed at the leaf node once the path to the root is completed.
The advantage is that when a leaf starts sending immediately after
the upstream path is installed, packets are able to reach the root
node without being dropped due to an incomplete LSP. Method 1 is not
able to guarantee that the upstream path is completed before the leaf
starts sending.
4.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 a MP2MP LSP <X, Y> determines its upstream LSR U for
<X, Y> as per Section 4.3.1.1, allocates a label L, and sends a MP2MP <X, Y> as per Section 4.3.1.1, allocates a label L, and sends a
Label Map downstream <X, Y, L> to U. MP2MP-D Label Map <X, Y, L> to U.
Leaf node Z expects an MP2MP Label Map upstream <X, Y, Lu> from node Leaf node Z expects an MP2MP-U Label Map <X, Y, Lu> from node U in
U in response to the MP2MP Label Map downstream it sent to node U. Z response to the MP2MP-D Label Map it sent to node U. Z checks whether
checks whether it already has forwarding state for upstream <X, Y>. it already has forwarding state for upstream <X, Y>. If not, Z
If not, Z creates forwarding state to push label Lu onto the traffic creates forwarding state to push label Lu onto the traffic that Z
that Z wants to forward over the MP2MP LSP. How it determines what wants to forward over the MP2MP LSP. How it determines what traffic
traffic to forward on this MP2MP LSP is outside the scope of this to forward on this MP2MP LSP is outside the scope of this document.
document.
4.3.1.4. MP2MP transit node operation 4.3.1.5. MP2MP transit node operation
When node Z receives a MP2MP Label Map downstream <X, Y, L> from peer When node Z receives a MP2MP-D Label Map <X, Y, L> from LSR D
D associated with interface I, it checks whether it has forwarding associated with interface I, it checks whether it has forwarding
state for downstream <X, Y>. If not, Z allocates a label L' and state for downstream <X, Y>. If not, Z allocates a label L' and
installs downstream forwarding state to swap label L' with label L installs downstream forwarding state to swap label L' with label L
over interface I. Z also determines its upstream LSR U for <X, Y> as over interface I. Z also determines its upstream LSR U for <X, Y> as
per Section 4.3.1.1, and sends a MP2MP Label Map downstream <X, Y, per Section 4.3.1.1, and sends a MP2MP-D Label Map <X, Y, L'> to U.
L'> to U.
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 is update its forwarding state. Assuming its old needs to do in this case is check that LSR D is not equal to the
forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new upstream LSR of <X, Y> and update its forwarding state. Assuming its
forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its
L>}. 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
Label Map from LSR D MUST be retained and MUST not update the label
forwarding table.
Node Z checks whether it already has forwarding state upstream <X, Y, Node Z checks if upstream LSR U already assigned a label Lu to <X,
D>. If it does, then no further action needs to happen. If it does Y>. If not, transit node Z waits until it receives a MP2MP-U Label
not, it allocates a label Lu and creates a new label swap for Lu from Map <X, Y, Lu> from LSR U associated with interface Iu. See
the label swap(s) from the forwarding state downstream <X, Y>, Section 4.3.1.3. Once the MP2MP-U Label Map for Lu over interface Iu
omitting the swap on interface I for node D. This allows upstream is received from LSR U, node Z checks whether it already has
traffic to follow the MP2MP tree down to other node(s) except the forwarding state upstream <X, Y, D>. If it does, then no further
node from which Z received the MP2MP Label Map downstream <X, Y, L>. action needs to happen. If it does not, it allocates a label Lu' and
Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, creates a new label swap for Lu' with Label Lu over interface Iu. In
and sends a MP2MP Label Map upstream <X, Y, Lu> to node D. addition, it also adds the label swap(s) from 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 to prevent packet
originated by D to be forwarded back to D.
Transit node Z will also receive a MP2MP Label Map upstream <X, Y, Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2,
Lu> in response to the MP2MP Label Map downstream sent to node U and sends a MP2MP-U Label Map <X, Y, Lu'> to node D.
associated with interface Iu. Node Z will add label swap Lu over
interface Iu to the forwarding state upstream <X, Y, D>. This allows
packets to go up the tree towards the root node.
4.3.1.5. MP2MP root node operation 4.3.1.6. MP2MP root node operation
4.3.1.5.1. Root node is also a leaf 4.3.1.6.1. Root node is also a leaf
Suppose root/leaf node Z receives a MP2MP Label Map downstream <X, Y, Suppose root/leaf node Z receives a MP2MP-D Label Map <X, Y, L> from
L> from node D associated with interface I. Z checks whether it node D associated with interface I. Z checks whether it already has
already has forwarding state downstream <X, Y>. If not, Z creates forwarding state downstream <X, Y>. If not, Z creates forwarding
forwarding state for downstream to push label L on traffic that Z state for downstream to push label L on traffic that Z wants to
wants to forward down the MP2MP LSP. How it determines what traffic forward down the MP2MP LSP. How it determines what traffic to
to forward on this MP2MP LSP is outside the scope of this document. forward on this MP2MP LSP is outside the scope of this document. If
If Z already has forwarding state for downstream <X, Y>, then Z will Z already has forwarding state for downstream <X, Y>, then Z will add
add the label push for L over interface I to it. the label push for L over interface I to it.
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
push Lu with the label push(s) from the forwarding state downstream push Lu' with the label push(s) from the forwarding state downstream
<X, Y>, except the push on interface I for node D. This allows <X, Y>, except the push 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 4.3.1.2, and sends a downstream MP2MP LSR as per section Section 4.3.1.2, and sends a
MP2MP Label Map upstream <X, Y, Lu> to node D. Since Z is the root of MP2MP-U Label Map <X, Y, Lu'> to node D. Since Z is the root of the
the tree Z will not send a MP2MP downstream map and will not receive tree Z will not send a MP2MP-D Label Map and will not receive a
a MP2MP upstream map. MP2MP-U Label Map.
4.3.1.5.2. Root node is not a leaf 4.3.1.6.2. Root node is not a leaf
Suppose the root node Z receives a MP2MP Label Map downstream <X, Y, Suppose the root node Z receives a MP2MP-D Label Map <X, Y, L> from
L> from node D associated with interface I. Z checks whether it node D associated with interface I. Z checks whether it already has
already has forwarding state for downstream <X, Y>. If not, Z forwarding state for downstream <X, Y>. If not, Z creates downstream
creates downstream forwarding state and installs a outgoing label L forwarding state and installs a outgoing label L over interface I. If
over interface I. If Z already has forwarding state for downstream Z already has forwarding state for downstream <X, Y>, then Z will add
<X, Y>, then Z will add label L over interface I to the existing label L over interface I to the existing state.
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 is was received from.
Root node Z determines the downstream MP2MP LSR D as per Root node Z determines the downstream MP2MP LSR D as per
Section 4.3.1.2, and sends a MP2MP Label Map upstream <X, Y, Lu> to Section 4.3.1.2, and sends a MP2MP-U Label Map <X, Y, Lu'> to it.
it. Since Z is the root of the tree Z will not send a MP2MP
downstream map and will not receive a MP2MP upstream map. Since Z is the root of the tree Z will not send a MP2MP-D Label Map
and will not receive a MP2MP-U Label Map.
4.3.2. MP2MP Label Withdraw 4.3.2. MP2MP Label Withdraw
The following lists procedures for generating and processing MP2MP The following lists procedures for generating and processing MP2MP
Label Withdraw messages for nodes that participate in a MP2MP LSP. Label Withdraw messages for nodes that participate in a MP2MP LSP.
An LSR should apply those procedures that apply to it, based on its An LSR should apply those procedures that apply to it, based on its
role in the MP2MP LSP. role in the MP2MP LSP.
4.3.2.1. MP2MP leaf operation 4.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 is no longer a leaf of the MP2MP LSP, it SHOULD document) that it has no downstream neighbors in that LSP, and that
send a downstream Label Withdraw <X, Y, L> to its upstream LSR U for it has no need to be an egress LSR for that LSP, then it SHOULD send
<X, Y>, where L is the label it had previously advertised to U for a MP2MP-D Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>,
<X,Y>. where L is the label it had previously advertised to U for <X,Y>.
Leaf node Z will also send a unsolicited label release <X, Y, Lu> to
U to indicate that the upstream path is no longer used and that Label
Lu can be removed.
Leaf node Z expects the upstream router U to respond by sending a Leaf node Z expects the upstream router U to respond by sending a
downstream label release for L and a upstream Label Withdraw for <X, downstream label release for L.
Y, Lu> to remove Lu from the upstream state. Node Z will remove
label Lu from its upstream state and send a label release message
with label Lu to U.
4.3.2.2. MP2MP transit node operation 4.3.2.2. MP2MP transit node operation
If a transit node Z receives a downstream label withdraw message <X, If a transit node Z receives a MP2MP-D Label Withdraw message <X, Y,
Y, L> from node D, it deletes label L from its forwarding state 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 label release message with label L to D. Since node D is no Z sends a MP2MP-D Label Release message with label L to D. Since node
longer part of the downstream forwarding state, Z cleans up the D is no longer part of the downstream forwarding state, Z cleans up
forwarding state upstream <X, Y, D> and sends a upstream Label the forwarding state upstream <X, Y, D>. There is no need to send an
Withdraw for <X, Y, Lu> to D. MP2MP-U Label Withdraw <X, Y, Lu> to D because node D already removed
Lu and send 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 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>. 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
that the upstream path is no longer used and that Label Lu can be
removed.
4.3.2.3. MP2MP root node operation 4.3.2.3. MP2MP root node operation
The procedure when the root node of a MP2MP LSP receives a label The procedure when the root node of a MP2MP LSP receives a MP2MP-D
withdraw message is the same as for transit nodes, except that the Label Withdraw message is the same as for transit nodes, except that
root node would not propagate the Label Withdraw upstream (as it has the root node would not propagate the Label Withdraw upstream (as it
no upstream). has no upstream).
4.3.2.4. MP2MP Upstream LSR change 4.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.2.4, 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 4.3.1 through Section 4.3.2.3. procedures described in Section 4.3.1 through Section 4.3.2.3.
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 a 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.
skipping to change at page 21, line 23 skipping to change at page 22, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 upstream LSR will send a copy of the packet to each On a LAN, the procedures so far discussed would require the upstream
receiver individually. If there is more then one receiver on the LAN LSR to send a copy of the packet to each receiver individually. If
we don't take full benefit of the multi-access capability of the there is more then one receiver on the LAN we don't take full benefit
network. We may optimize the bandwidth consumption on the LAN and of the multi-access capability of the network. We may optimize the
replication overhead on the upstream LSR by using upstream label bandwidth consumption on the LAN and replication overhead on the
allocation [4]. Procedures on how to distribute upstream labels upstream LSR by using upstream label allocation [4]. Procedures on
using LDP is documented in [5]. how to distribute upstream labels using LDP is documented in [5].
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 [4]. The procedure to allocate a context label on a LAN is defined in [4].
That procedure results in each LSR on a given LAN having a context That procedure results in each LSR on a given LAN having a context
label which, on that LAN, can be used to identify itself uniquely. label which, on that LAN, can be used to identify itself uniquely.
Each LSR advertises its context label as an upstream-assigned label, Each LSR advertises its context label as an upstream-assigned label,
following the procedures of [5]. Any LSR for which the LAN is a following the procedures of [5]. Any LSR for which the LAN is a
downstream link on some P2MP or MP2MP LSP will allocate an upstream- downstream link on some P2MP or MP2MP LSP will allocate an upstream-
assigned label identifying that LSP. When the LSR forwards a packet assigned label identifying that LSP. When the LSR forwards a packet
skipping to change at page 24, line 5 skipping to change at page 25, line 24
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. MP LSP micro loops
A MP LSP is built hop by hop following the best path to reach the
root of the LSP. If the routing protocol used to calculate the best
path is subjected to micro-loops, the MP LSP may contain a micro
loop. Both P2MP and MP2MP LSPs may end up containing a micro-loop.
However, there is a difference between loops in P2MP and MP2MP LSP.
In a P2MP LSP, once a loop s formed, no new packet can enter it, but
in a MP2MP LSP, packets may continue to enter the loop. This makes a
loop in MP2MP LSP worse compared to loop in P2MP LSP. If the routing
protocol is not subjected to micro-loops, the MP LSP will not end up
in a micro-loop and no additional procedures are necessary. The
following section describes procedures that MAY be applied to prevent
micro-loops in MP2MP LSPs in case the routing protocol is not able to
guarantee a loop-free best path selection.
8.1. MP2MP upstream path
A MP2MP LSP has multiple injection points, there is one injection
point from the root down the LSP towards the leafs, which is the same
as a P2MP LSP. Other injection point(s) are from each leaf towards
the root of the LSP. These procedures solve micro-loops which are
the result of injecting packets from the leaf towards the root. It
does not solve micro-loops which are the result of injecting packets
from the root. This makes the MP2MP LSP as good as P2MP LSPs.
8.2. MP2MP micro loop prevention procedures
Based on the procedures defined in Section 4.3.1.3 ordered mode is
used to build the upstream path from the root down to the leaves.
The MP2MP-U Label Map will add a path vector TLV [1] as optional
parameter to the MP2MP-U Label Map message. Each LSR will add its
own router ID to the path list TLV before sending the MP2MP-U Label
Map <X, Y, D> to the downstream LSRs. Suppose node Z receives a
MP2MP-U Label Map from LSR D with Label Lu. If node Z finds its own
router ID in the path vector list it will complete the procedures for
MP2MP LSP's defined in this draft with the following exception, the
Label Forwarding Database for the MP2MP upstream <X, Y, D> with Lu is
not installed, but is retained. By not installing Label Lu the loop
is prevented. If node Z receives a MP2MP-U Label Map that updates
the path vector list such that it does not include its own router ID,
Label Lu can be safely installed into forwarding.
9. Make Before Break (MBB)
An LSR selects as its upstream LSR for a MP LSP the LSR that is its An LSR selects as its upstream LSR for a MP LSP the LSR that is its
next hop to the root of the LSP. When the best path to reach the next hop to the root of the LSP. When the best path to reach the
root changes the LSR must choose a new upstream LSR. Sections root changes the LSR must choose a new upstream LSR. Sections
Section 2.4.2.4 and Section 4.3.2.4 describe these procedures. Section 2.4.3 and Section 4.3.3 describe these procedures.
When the best path to the root changes the LSP may be broken 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 prevous 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.
This MBB procedures are an optional extension to the MP LSP building This MBB procedures are an optional extension to the MP LSP building
procedures described in this draft. procedures described in this draft.
8.1. MBB overview 9.1. MBB overview
The MBB procedues use additional LDP signaling. The MBB procedues 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 LSR's other than LSR-D. After LSR-U FEC-A; that is, to downstream LSR's other than LSR-D. After LSR-U
receives a label for FEC-A from LSR-D, it will notify LSR-D when it 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 its
next hop for the LSP root to LSR-U. next hop for the LSP root to LSR-U.
skipping to change at page 25, line 17 skipping to change at page 27, line 35
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 its LSR for the LSP. When LSR-U receives the MBB notification from its
upstream LSR it transitions to LSP state #3 and sends an MBB upstream LSR it transitions to LSP state #3 and sends an MBB
notification to LSR-D. notification to LSR-D.
8.2. The MBB Status code 9.2. The MBB Status code
As noted in Section 8.1, the procedures to establish an MBB MP LSP As noted in Section 9.1, the procedures to establish an MBB MP LSP
are different from those to establish normal MP LSPs. are different from those to establish 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 a MBB
Status Code to indicate MBB procedures apply to the LSP. This new Status Code to indicate MBB procedures apply to the LSP. This new
MBB Status Code MAY also appear in an LDP Notification message used MBB Status Code MAY also appear in an LDP Notification message used
by an upstream LSR to signal LSP state #3 to the downstream LSR; that by an upstream LSR to signal LSP state #3 to the downstream LSR; that
is, that the upstream LSR's state for the LSP exists and that it has is, that the upstream LSR's state for the LSP exists and that it has
received notification from its upstream LSR that the LSP is in state received notification from its upstream LSR that the LSP is in state
#3. #3.
skipping to change at page 26, line 4 skipping to change at page 28, line 19
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 (to be assigned by IANA)
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 9.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 [6]. The LDP MP MBB the capability advertisement as defined in [6]. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 29 skipping to change at page 29, line 4
Note: LDP MP MBB Capability (Pending IANA assignment) Note: LDP MP MBB Capability (Pending IANA assignment)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |1| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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 which include MBB parameters. If an LSR
receives a Label Mapping message with a MBB parameter from downstream receives a Label Mapping message with a MBB parameter from downstream
LSR-D and its upstream LSR-U has not advertised that it is MBB LSR-D and its upstream LSR-U has not advertised that it is MBB
capable, the LSR MUST send an MBB notification immediatly to LSR-U capable, the LSR MUST send an MBB notification immediatly to LSR-U
(see Section 8.4). If this happens an MBB MP LSP will not be (see Section 9.4). If this happens an MBB MP LSP will not be
established, but normal a MP LSP will be the result. established, but normal a MP LSP will be the result.
8.4. The MBB procedures 9.4. The MBB procedures
8.4.1. Terminology 9.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
skipping to change at page 27, line 27 skipping to change at page 29, line 44
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 a
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>: A LDP notification message with a MP
LSP <X, Y>, Label L and MBB Status code 2. LSP <X, Y>, Label L and MBB Status code 2.
7. MBB Label Map <X, Y, L>: A P2MP Label Map or MP2MP Label Map 7. MBB Label Map <X, Y, L>: A P2MP Label Map or MP2MP Label Map
downstream with a FEC element <X, Y>, Label L and MBB Status code downstream with a FEC element <X, Y>, Label L and MBB Status code
1. 1.
8.4.2. Accepting elements 9.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 a 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 is pending to replace the active element in the label
forwarding database. Inactive elements only exist temporarily while forwarding database. 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 an other
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 an 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 send for label L to neighbor N for <X, Y>.
8.4.3. Procedures for upstream LSR change 9.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 a 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 Map <X, Y, L2>to N2 and waits for the L2). Node Z sends MBB Label Map <X, Y, L2>to N2 and waits for the
new upstream LSR N2 to respond with a MBB Notification for <X, Y, new upstream LSR N2 to respond with a MBB Notification for <X, Y,
L2>. During this transition phase there are two accepting elements, L2>. During this transition phase there are two accepting elements,
the element A(N1, L1) still accepting packets from N1 over label L1 the element A(N1, L1) still accepting packets from N1 over label L1
and the new inactive element iA(N2, L2). and the new inactive element iA(N2, L2).
skipping to change at page 28, line 21 skipping to change at page 30, line 38
possible that an other transition occurs due to a routing change. possible that an other 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&gt. 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 9.4.5 are
applied as if a MBB Notification was received for the inactive applied as if a MBB Notification was received for the inactive
element. element.
8.4.4. Receiving a Label Map with MBB status code 9.4.4. Receiving a Label Map 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 a MBB LSP <X, Y> and receives a MBB
Label Map <X, Y, L2> from N2. A new forwarding state F(N2, L2) will Label Map <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 LSP 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 node Z is the root of the MBB LSP
a MBB notification <X, Y, L2)> is send to node N2. If node Z has an a MBB notification <X, Y, L2)> is send to node N2. If node Z has an
inactive accepting element it marks the Forwarding state as <X, Y, inactive accepting element it marks the Forwarding state as <X, Y,
F'(N2, L2)>. F'(N2, L2)>.
8.4.5. Receiving a Notification with MBB status code 9.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 a MBB Notification <X, Y, L> from N. If node
Z has state for MBB LSP <X, Y> and an inactive accepting element 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 an
other active accepting was present it will be removed from the label other active accepting was present it will be removed from the label
forwarding database. 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
send to these downstream LSRs. If node Z receives a MBB Notification send to these downstream LSRs. If node Z receives a MBB Notification
for an accepting element that is not inactive or does not match the for an accepting element that is not inactive or does not match the
Label value and Neighbor address, the MBB notification is ignored. Label value and Neighbor address, the MBB notification is ignored.
8.4.6. Node operation for MP2MP LSPs 9.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 a
MP2MP LSP. The upstream path of the MP2MP is setup as normal without MP2MP LSP. The upstream path of the MP2MP is setup as normal without
including a MBB Status code. If the MBB procedures apply to a MP2MP including a MBB Status code. If the MBB procedures apply to a MP2MP
downstream FEC element, the upstream path to a node N is only downstream FEC element, the upstream path to a node N is only
installed in the label forwarding database if node N is part of the installed in the label forwarding database if node N is part of the
active accepting element. If node N is part of an inactive accepting active accepting element. If node N is part of an inactive accepting
element, the upstream path is installed when this inactive accepting element, the upstream path is installed when this inactive accepting
element is activated. element is activated.
9. Security Considerations 10. Security Considerations
The same security considerations apply as for the base LDP The same security considerations apply as for the base LDP
specification, as described in [1]. specification, as described in [1].
10. IANA considerations 11. IANA considerations
This document creates a new name space (the LDP MP Opaque Value This document creates a new name space (the LDP MP Opaque Value
Element type) that is to be managed by IANA, and the allocation of Element type) that is to be managed by IANA, and the allocation of
the value 1 for the type of Generic LSP Identifier. the value 1 for the type of Generic LSP Identifier.
This document requires allocation of three new LDP FEC Element types: This document requires allocation of three new LDP FEC Element types:
1. the P2MP FEC type - requested value 0x04 1. the P2MP FEC type - requested value 0x06
2. the MP2MP-up FEC type - requested value 0x05 2. the MP2MP-up FEC type - requested value 0x07
3. the MP2MP-down FEC type - requested value 0x06 3. the MP2MP-down FEC type - requested value 0x08
This document requires the assignment of three new code points for This document requires the assignment of three new code points for
three new Capability Parameter TLVs, corresponding to the three new Capability Parameter TLVs, corresponding to the
advertisement of the P2MP, MP2MP and MBB capabilities. The values advertisement of the P2MP, MP2MP and MBB capabilities. The values
requested are: requested are:
P2MP Capability Parameter - requested value 0x0508 P2MP Capability Parameter - requested value 0x0508
MP2MP Capability Parameter - requested value 0x0509 MP2MP Capability Parameter - requested value 0x0509
MBB Capability Parameter - requested value 0x050A MBB Capability Parameter - requested value 0x050A
This document requires the assignment of a LDP Status TLV code to This document requires the assignment of a LDP Status TLV code to
indicate a LDP MP Status TLV is following in the Notification indicate a LDP MP Status TLV is following in the Notification
message. The value requested is: message. The value requested is:
LDP MP status - requested value 0x0000002C LDP MP status - requested value 0x0000002D
This document requires the assigment of a new code point for a LDP MP This document requires the assigment of a new code point for a LDP MP
Status TLV. The value requested is: Status TLV. The value requested is:
LDP MP Status TLV Type - requested value 0x096D LDP MP Status TLV Type - requested value 0x096D
This document creates a new name space (the LDP MP Status Value This document creates a new name space (the LDP MP Status Value
Element type) that is to be managed by IANA, and the allocation of Element type) that is to be managed by IANA, and the allocation of
the value 1 for the type of MBB Status. the value 1 for the type of MBB Status.
11. 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 and Adrian Farrel. George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas
Morin.
12. 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
skipping to change at page 31, line 32 skipping to change at page 34, line 4
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: ina@juniper.net Email: ina@juniper.net
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
Lannion, Cedex 22307 Lannion, Cedex 22307
France France
Email: jeanlouis.leroux@francetelecom.com 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: rhthomas@cisco.com E-mail: 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 E-mail: ice@cisco.com
13. References 14. References
13.1. Normative References 14.1. Normative References
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. [1] Andersson, L., Minei, I., and B. Thomas, "LDP Specification",
Thomas, "LDP Specification", RFC 3036, January 2001. RFC 5036, October 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [3] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002. line Database", RFC 3232, January 2002.
[4] Aggarwal, R., "MPLS Upstream Label Assignment and Context [4] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label
Specific Label Space", draft-ietf-mpls-upstream-label-02 (work Assignment and Context-Specific Label Space",
in progress), March 2007. draft-ietf-mpls-upstream-label-05 (work in progress),
April 2008.
[5] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for [5] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for
LDP", draft-ietf-mpls-ldp-upstream-01 (work in progress), LDP", draft-ietf-mpls-ldp-upstream-02 (work in progress),
March 2007. November 2007.
[6] Thomas, B., "LDP Capabilities", [6] Thomas, B., "LDP Capabilities",
draft-ietf-mpls-ldp-capabilities-00 (work in progress), draft-ietf-mpls-ldp-capabilities-02 (work in progress),
May 2007. March 2008.
13.2. Informative References 14.2. Informative References
[7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [7] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[8] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions [8] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions
to Resource Reservation Protocol - Traffic Engineering to Resource Reservation Protocol - Traffic Engineering
(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 4875, May 2007. (LSPs)", RFC 4875, May 2007.
[9] Roux, J., "Requirements for Point-To-Multipoint Extensions to [9] Roux, J., "Requirements for Point-To-Multipoint Extensions to
the Label Distribution Protocol", the Label Distribution Protocol",
draft-ietf-mpls-mp-ldp-reqs-02 (work in progress), March 2007. draft-ietf-mpls-mp-ldp-reqs-04 (work in progress),
February 2008.
[10] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", [10] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
draft-ietf-l3vpn-2547bis-mcast-00 (work in progress), Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/
June 2005. BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in
progress), January 2008.
[11] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", draft-ietf-mpls-multicast-encaps-09
(work in progress), May 2008.
Authors' Addresses Authors' Addresses
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
skipping to change at page 33, line 39 skipping to change at page 36, line 18
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough 01719 Boxborough 01719
US US
Email: rhthomas@cisco.com Email: bobthomas@alum.mit.edu
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 101 change blocks. 
238 lines changed or deleted 355 lines changed or added

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