draft-ietf-mpls-ldp-p2mp-06.txt   draft-ietf-mpls-ldp-p2mp-07.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: October 22, 2009 I. Wijnands (Editor) Expires: January 13, 2010 I. Wijnands (Editor)
B. Thomas B. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
April 20, 2009 July 12, 2009
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-06 draft-ietf-mpls-ldp-p2mp-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 October 22, 2009. This Internet-Draft will expire on January 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
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. LDP constructs the P2MP or MP2MP Label Switching (MPLS) networks. These extensions are also referred
LSPs without interacting with or relying upon any other multicast to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs
tree construction protocol. Protocol elements and procedures for without interacting with or relying upon any other multicast tree
this solution are described for building such LSPs in a receiver- construction protocol. Protocol elements and procedures for this
initiated manner. There can be various applications for P2MP/MP2MP solution are described for building such LSPs in a receiver-initiated
LSPs, for example IP multicast or support for multicast in BGP/MPLS manner. There can be various applications for P2MP/MP2MP LSPs, for
L3VPNs. Specification of how such applications can use a LDP example IP multicast or support for multicast in BGP/MPLS L3VPNs.
signaled P2MP/MP2MP LSP is outside the scope of this document. Specification of how such applications can use a LDP signaled P2MP/
MP2MP LSP is outside the scope of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions used in this document . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6
2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7
2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7
2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9
skipping to change at page 3, line 39 skipping to change at page 3, line 39
5.2. LDP Messages containing LDP MP Status messages . . . . . . 22 5.2. LDP Messages containing LDP MP Status messages . . . . . . 22
5.2.1. LDP MP Status sent in LDP notification messages . . . 22 5.2.1. LDP MP Status sent in LDP notification messages . . . 22
5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23
6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24
6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24
6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24
6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24
7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25
7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25
7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26
8. MP2MP micro loop prevention . . . . . . . . . . . . . . . . . 26 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26
8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 27 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 27 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28
9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28
9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29
9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29
9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30
9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 30
9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 8.4.4. Receiving a Label Map with MBB status code . . . . . . 31
9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31 8.4.5. Receiving a Notification with MBB status code . . . . 31
9.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31
9.4.4. Receiving a Label Map with MBB status code . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9.4.5. Receiving a Notification with MBB status code . . . . 32 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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. A MP2MP
skipping to change at page 26, line 42 skipping to change at page 26, line 42
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. MP2MP micro loop prevention 8. Make Before Break (MBB)
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 [RFC5036] as
optional parameter to the MP2MP-U Label Map message. Each LSR will
add its own router ID to the path list TLV before sending the MP2MP-U
Label Map <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.3 and Section 4.3.3 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
skipping to change at page 28, line 4 skipping to change at page 27, line 8
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.3 and Section 4.3.3 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.
9.1. MBB overview 8.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 29, line 5 skipping to change at page 28, line 7
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.
9.2. The MBB Status code 8.2. The MBB Status code
As noted in Section 9.1, the procedures to establish an MBB MP LSP As noted in Section 8.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 29, line 36 skipping to change at page 28, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
9.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 the capability advertisement as defined in
[I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the [I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the
following format: 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 30, line 22 skipping to change at page 29, line 28
|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 9.4). If this happens an MBB MP LSP will not be (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 normal a MP LSP will be the result.
9.4. The MBB procedures 8.4. The MBB procedures
9.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
skipping to change at page 31, line 15 skipping to change at page 30, line 19
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.
9.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 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>.
9.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 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 32, line 8 skipping to change at page 31, line 12
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 9.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 a MBB Notification was received for the inactive
element. element.
9.4.4. Receiving a Label Map with MBB status code 8.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)>.
9.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 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.
9.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 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.
10. Security Considerations 9. 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 [RFC5036]. specification, as described in [RFC5036].
11. IANA considerations 10. 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 0x06 1. the P2MP FEC type - requested value 0x06
2. the MP2MP-up FEC type - requested value 0x07 2. the MP2MP-up FEC type - requested value 0x07
skipping to change at page 33, line 30 skipping to change at page 32, line 35
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 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 from the LDP Status Code Name Space:
LDP MP status - requested value 0x0000002D LDP MP status - requested value 0x00000040
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 from the LDP TLV Type Name Space:
LDP MP Status TLV Type - requested value 0x096D LDP MP Status TLV Type - requested value 0x096F
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.
12. Acknowledgments 11. 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 and Thomas George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas
Morin. Morin.
13. Contributing authors 12. 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
skipping to change at page 35, line 38 skipping to change at page 34, line 45
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
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[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.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
skipping to change at page 36, line 24 skipping to change at page 35, line 32
[I-D.ietf-mpls-ldp-upstream] [I-D.ietf-mpls-ldp-upstream]
Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment
for LDP", draft-ietf-mpls-ldp-upstream-02 (work in for LDP", draft-ietf-mpls-ldp-upstream-02 (work in
progress), November 2007. progress), November 2007.
[I-D.ietf-mpls-ldp-capabilities] [I-D.ietf-mpls-ldp-capabilities]
Thomas, B., "LDP Capabilities", Thomas, B., "LDP Capabilities",
draft-ietf-mpls-ldp-capabilities-02 (work in progress), draft-ietf-mpls-ldp-capabilities-02 (work in progress),
March 2008. March 2008.
14.2. Informative References 13.2. Informative References
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[I-D.ietf-mpls-mp-ldp-reqs] [I-D.ietf-mpls-mp-ldp-reqs]
 End of changes. 33 change blocks. 
104 lines changed or deleted 58 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/