draft-ietf-mpls-ldp-p2mp-07.txt   draft-ietf-mpls-ldp-p2mp-08.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: January 13, 2010 I. Wijnands (Editor) Expires: April 27, 2010 I. Wijnands (Editor)
B. Thomas B. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
July 12, 2009 October 24, 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-07 draft-ietf-mpls-ldp-p2mp-08
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 January 13, 2010. This Internet-Draft will expire on April 27, 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.
skipping to change at page 3, line 21 skipping to change at page 3, line 21
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
2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 9 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 9
2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 10 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 10
2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12
2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 13 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 13
3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 14 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 14
4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 15
4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 15 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 15
4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 16
4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 17 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 17
4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20
4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21
5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 5. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 21
5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 6. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 22
5.2. LDP Messages containing LDP MP Status messages . . . . . . 22 6.1. The LDP MP Status Value Element . . . . . . . . . . . . . 23
5.2.1. LDP MP Status sent in LDP notification messages . . . 22 6.2. LDP Messages containing LDP MP Status messages . . . . . . 23
5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 6.2.1. LDP MP Status sent in LDP notification messages . . . 23
6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 6.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 24
6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 7. Upstream label allocation on a LAN . . . . . . . . . . . . . . 25
6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 7.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 25
6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 7.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 25
7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 7.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 25
7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 8. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 26
7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 8.1. Root node redundancy - procedures for P2MP LSPs . . . . . 26
8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 8.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 27
8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27
8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28
8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29
8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29
8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30
8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30
8.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31
8.4.4. Receiving a Label Map with MBB status code . . . . . . 31 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 31
8.4.5. Receiving a Notification with MBB status code . . . . 31 9.4.4. Receiving a Label Map with MBB status code . . . . . . 32
8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 9.4.5. Receiving a Notification with MBB status code . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33
12. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 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 10, line 23 skipping to change at page 10, line 23
This section defines the rules for the processing and propagation of This section defines the rules for the processing and propagation of
the P2MP FEC Element. The following notation is used in the the P2MP FEC Element. The following notation is used in the
processing rules: processing rules:
1. P2MP FEC Element <X, Y>: a FEC Element with Root Node Address X 1. P2MP FEC Element <X, Y>: a FEC Element with Root Node Address X
and Opaque Value Y. and Opaque Value Y.
2. P2MP Label Map <X, Y, L>: a Label Map message with a FEC TLV with 2. P2MP Label Map <X, Y, L>: a Label Map message with a FEC TLV with
a single P2MP FEC Element <X, Y> and Label TLV with label L. a single P2MP FEC Element <X, Y> and Label TLV with label L.
Label L MUST be allocated from the per-platform label space (see
[RFC3031] section 3.14) of the LSR sending the Label Map Message.
3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a 3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a
FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with
label L. label L.
4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with Root Node 4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with Root Node
Address X and Opaque Value Y. Address X and Opaque Value Y.
5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X 5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X
means that on receiving a packet with label L', X makes n copies means that on receiving a packet with label L', X makes n copies
skipping to change at page 11, line 15 skipping to change at page 11, line 15
2.4.1. Label Map 2.4.1. Label Map
The remainder of this section specifies the procedures for The remainder of this section specifies the procedures for
originating P2MP Label Map messages and for processing received P2MP originating P2MP Label Map messages and for processing received P2MP
label map messages for a particular LSP. The procedures for a label map messages for a particular LSP. The procedures for a
particular LSR depend upon the role that LSR plays in the LSP particular LSR depend upon the role that LSR plays in the LSP
(ingress, transit, or egress). (ingress, transit, or egress).
All labels discussed here are downstream-assigned All labels discussed here are downstream-assigned
[I-D.ietf-mpls-multicast-encaps] except those which are assigned [I-D.ietf-mpls-multicast-encaps] except those which are assigned
using the procedures of Section 6. using the procedures of Section 7.
2.4.1.1. Determining one's 'upstream LSR' 2.4.1.1. Determining one's 'upstream LSR'
Each node that is either an Leaf or Transit LSR of MP LSP needs to Each node that is either an Leaf or Transit LSR of MP LSP needs to
use the procedures below to select an upstream LSR. A node Z that use the procedures below to select an upstream LSR. A node Z that
wants to join a MP LSP <X, Y> determines the LDP peer U which is Z's wants to join 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 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 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>.
skipping to change at page 11, line 41 skipping to change at page 11, line 41
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
3. The selected upstream LSR U is the LSR that has the number H. 3. The selected upstream LSR U is the LSR that has the number H.
This allows for load balancing of a set of LSPs among a set of This allows for load balancing of a set of LSPs among a set of
candidate upstream LSRs, while ensuring that on a LAN interface a candidate upstream LSRs, while ensuring that on a LAN interface a
single upstream LSR is selected. single upstream LSR is selected.
2.4.1.2. Leaf Operation 2.4.1.2. Determining the forwarding interface to an LSR
Suppose LSR U receives a MP Label Map message from a downstream LSR
D, specifying label L. Suppose further that U is connected to D over
several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U
needs to transmit to D a data packet whose top label is L, U is free
to transmit the packet on any of those interfaces. LSR U is able to
discover the directly connected interfaces via the LDP Discovery
messages exchanged between the LSR U and D. The algorithm it uses to
choose a particular interface for a particular such packet is a local
matter.
2.4.1.3. Leaf Operation
A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for
<X, Y> as per Section 2.4.1.1, allocates a label L, and sends a P2MP <X, Y> as per Section 2.4.1.1, allocates a label L, and sends a P2MP
Label Map <X, Y, L> to U. Label Map <X, Y, L> to U.
2.4.1.3. Transit Node operation 2.4.1.4. Transit Node operation
Suppose a transit node Z receives a P2MP Label Map <X, Y, L> from LSR Suppose a transit node Z receives a P2MP Label Map <X, Y, L> from LSR
T. Z checks whether it already has state for <X, Y>. If not, Z T. Z checks whether it already has state for <X, Y>. If not, Z
determines its upstream LSR U for <X, Y> as per Section 2.4.1.1. determines its upstream LSR U for <X, Y> as per Section 2.4.1.1.
Using this Label Map to update the label forwarding table MUST NOT be Using this Label Map to update the label forwarding table MUST NOT be
done as long as LSR T is equal to LSR U. If LSR U is different from done as long as LSR T is equal to LSR U. If LSR U is different from
LSR T, Z will allocate a label L', and install state to swap L' with LSR T, Z will allocate a label L', and install state to swap L' with
L over interface I associated with LSR T and send a P2MP Label Map L over interface I associated with LSR T and send a P2MP Label Map
<X, Y, L'> to LSR U. <X, Y, L'> to LSR U. Interface I is determind via the procedures in
Section 2.4.1.2.
If Z already has state for <X, Y>, then Z does not send a Label Map If Z already has state for <X, Y>, then Z does not send a Label Map
message for P2MP LSP <X, Y>. All that Z needs to do in this case is message for P2MP LSP <X, Y>. All that Z needs to do in this case is
check that LSR T is not equal to the upstream LSR of <X, Y> and check that LSR T is not equal to the upstream LSR of <X, Y> and
update its forwarding state. Assuming its old forwarding state was update its forwarding state. Assuming its old forwarding state was
L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state
becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If the LSR T becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If the LSR T
is equal to the installed upstream LSR, the Label Map from LSR T MUST is equal to the installed upstream LSR, the Label Map from LSR T MUST
be retained and MUST not update the label forwarding table. be retained and MUST not update the label forwarding table.
2.4.1.4. Root Node Operation 2.4.1.5. Root Node Operation
Suppose the root node Z receives a P2MP Label Map <X, Y, L> from LSR Suppose the root node Z receives a P2MP Label Map <X, Y, L> from LSR
T. Z checks whether it already has forwarding state for <X, Y>. If T. Z checks whether it already has forwarding state for <X, Y>. If
not, Z creates forwarding state to push label L onto the traffic that not, Z creates forwarding state to push label L onto the traffic that
Z wants to forward over the P2MP LSP (how this traffic is determined Z wants to forward over the P2MP LSP (how this traffic is determined
is outside the scope of this document). is outside the scope of this document).
If Z already has forwarding state for <X, Y>, then Z adds "push label If Z already has forwarding state for <X, Y>, then Z adds "push label
L, send over interface I" to the nexthop, where I is the interface L, send over interface I" to the nexthop, where I is the interface
associated with LSR T. associated with LSR T and determind via the procedures in
Section 2.4.1.2.
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
skipping to change at page 13, line 28 skipping to change at page 13, line 44
Suppose that for a given node Z participating in a P2MP LSP <X, Y>, Suppose that for a given node Z participating in a P2MP LSP <X, Y>,
the upstream LSR changes from U to U' as per Section 2.4.1.1. If U' the upstream LSR changes from U to U' as per Section 2.4.1.1. If U'
is present in the forwarding table of <X, Y> then it MUST be removed. is present in the forwarding table of <X, Y> then it MUST be removed.
Z MUST also update its forwarding state by deleting the state for Z MUST also update its forwarding state by deleting the state for
label L, allocating a new label, L', for <X, Y>, and installing the label L, allocating a new label, L', for <X, Y>, and installing the
forwarding state for L'. Installing the forwarding state for L' MUST forwarding state for L'. Installing the forwarding state for L' MUST
NOT be done before the forwarding state L is removed to avoid NOT be done before the forwarding state L is removed to avoid
microloops. In addition Z MUST send a Label Map <X, Y, L'> to U' and microloops. In addition Z MUST send a Label Map <X, Y, L'> to U' and
send a Label Withdraw <X, Y, L> to U. Note, if there was a downstream send a Label Withdraw <X, Y, L> to U. Note, if there was a downstream
mapping from U that was not installed in the forwarding due to mapping from U that was not installed in the forwarding due to
Section 2.4.1.3 it can now be installed. Section 2.4.1.4 it can now be installed.
3. Shared Trees 3. Shared Trees
The mechanism described above shows how to build a tree with a single The mechanism described above shows how to build a tree with a single
root and multiple leaves, i.e., a P2MP LSP. One can use essentially root and multiple leaves, i.e., a P2MP LSP. One can use essentially
the same mechanism to build Shared Trees with LDP. A Shared Tree can the same mechanism to build Shared Trees with LDP. A Shared Tree can
be used by a group of routers that want to multicast traffic among be used by a group of routers that want to multicast traffic among
themselves, i.e., each node is both a root node (when it sources themselves, i.e., each node is both a root node (when it sources
traffic) and a leaf node (when any other member of the group sources traffic) and a leaf node (when any other member of the group sources
traffic). A Shared Tree offers similar functionality to a MP2MP LSP, traffic). A Shared Tree offers similar functionality to a MP2MP LSP,
skipping to change at page 16, line 23 skipping to change at page 16, line 38
3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root 3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root
node address X and opaque value Y used for a downstream MP2MP node address X and opaque value Y used for a downstream MP2MP
LSP. LSP.
4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node 4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node
address X and opaque value Y used for an upstream MP2MP LSP. address X and opaque value Y used for an upstream MP2MP LSP.
5. MP2MP-D Label Map <X, Y, L>: A Label Map message with a FEC TLV 5. MP2MP-D Label Map <X, Y, L>: A Label Map message with a FEC TLV
with a single MP2MP downstream FEC Element <X, Y> and label TLV with a single MP2MP downstream FEC Element <X, Y> and label TLV
with label L. with label L. Label L MUST be allocated from the per-platform
label space (see [RFC3031] section 3.14) of the LSR sending the
Label Map Message.
6. MP2MP-U Label Map <X, Y, Lu>: A Label Map message with a FEC TLV 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 a single MP2MP upstream FEC Element <X, Y> and label TLV
with label Lu. with label Lu. Label L MUST be allocated from the per-platform
label space (see [RFC3031] section 3.14) of the LSR sending the
Label Map Message.
7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with 7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with
a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
label TLV with label L. label TLV with label L.
8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with 8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with
a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and
label TLV with label Lu. label TLV with label Lu.
9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a 9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a
skipping to change at page 17, line 28 skipping to change at page 17, line 43
4.3.1. MP2MP Label Map 4.3.1. MP2MP Label Map
The remainder of this section specifies the procedures for The remainder of this section specifies the procedures for
originating MP2MP Label Map messages and for processing received originating MP2MP Label Map messages and for processing received
MP2MP label map messages for a particular LSP. The procedures for a MP2MP label map messages for a particular LSP. The procedures for a
particular LSR depend upon the role that LSR plays in the LSP particular LSR depend upon the role that LSR plays in the LSP
(ingress, transit, or egress). (ingress, transit, or egress).
All labels discussed here are downstream-assigned All labels discussed here are downstream-assigned
[I-D.ietf-mpls-multicast-encaps] except those which are assigned [I-D.ietf-mpls-multicast-encaps] except those which are assigned
using the procedures of Section 6. using the procedures of Section 7.
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-D Label Map from a LDP peer D A LDP peer U which receives a MP2MP-D Label Map from a LDP peer D
will treat D as downstream MP2MP LSR. will treat D as downstream MP2MP LSR.
skipping to change at page 18, line 39 skipping to change at page 19, line 7
Leaf node Z expects an MP2MP-U Label Map <X, Y, Lu> from node U in Leaf node Z expects an MP2MP-U Label Map <X, Y, Lu> from node U in
response to the MP2MP-D Label Map it sent to node U. Z checks whether response to the MP2MP-D Label Map it sent to node U. Z checks whether
it already has forwarding state for upstream <X, Y>. If not, Z it already has forwarding state for upstream <X, Y>. If not, Z
creates forwarding state to push label Lu onto the traffic that Z creates forwarding state to push label Lu onto the traffic that Z
wants to forward over the MP2MP LSP. How it determines what traffic wants to forward over the MP2MP LSP. How it determines what traffic
to forward on this MP2MP LSP is outside the scope of this document. to forward on this MP2MP LSP is outside the scope of this document.
4.3.1.5. MP2MP transit node operation 4.3.1.5. MP2MP transit node operation
When node Z receives a MP2MP-D Label Map <X, Y, L> from LSR D Suppose node Z receives a MP2MP-D Label Map <X, Y, L> from LSR D. Z
associated with interface I, it checks whether it has forwarding checks whether it has forwarding state for downstream <X, Y>. If
state for downstream <X, Y>. If not, Z determines its upstream LSR U not, Z determines its upstream LSR U for <X, Y> as per
for <X, Y> as per Section 4.3.1.1. Using this Label Map to update Section 4.3.1.1. Using this Label Map to update the label forwarding
the label forwarding table MUST NOT be done as long as LSR D is equal table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U
to LSR U. If LSR U is different from LSR D, Z will allocate a label is different from LSR D, Z will allocate a label L' and install
L' and install downstream forwarding state to swap label L' with downstream forwarding state to swap label L' with label L over
label L over interface I and send a MP2MP-D Label Map <X, Y, L'> to interface I associated with LSR D and send a MP2MP-D Label Map <X, Y,
U. L'> to U. Interface I is determind via the procedures in
Section 2.4.1.2.
If Z already has forwarding state for downstream <X, Y>, all that Z If Z already has forwarding state for downstream <X, Y>, all that Z
needs to do in this case is check that LSR D is not equal to the needs to do in this case is check that LSR D is not equal to the
upstream LSR of <X, Y> and update its forwarding state. Assuming its upstream LSR of <X, Y> and update its forwarding state. Assuming its
old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its
new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>,
<I, L>}. If the LSR D is equal to the installed upstream LSR, the <I, L>}. If the LSR D is equal to the installed upstream LSR, the
Label Map from LSR D MUST be retained and MUST not update the label Label Map from LSR D MUST be retained and MUST not update the label
forwarding table. forwarding table.
Node Z checks if upstream LSR U already assigned a label Lu to <X, Node Z checks if upstream LSR U already assigned a label Lu to <X,
Y>. If not, transit node Z waits until it receives a MP2MP-U Label Y>. If not, transit node Z waits until it receives a MP2MP-U Label
Map <X, Y, Lu> from LSR U associated with interface Iu. See Map <X, Y, Lu> from LSR U. See Section 4.3.1.3. Once the MP2MP-U
Section 4.3.1.3. Once the MP2MP-U Label Map for Lu over interface Iu Label Map is received from LSR U, node Z checks whether it already
is received from LSR U, node Z checks whether it already has has forwarding state upstream <X, Y, D>. If it does, then no further
forwarding state upstream <X, Y, D>. If it does, then no further
action needs to happen. If it does not, it allocates a label Lu' and action needs to happen. If it does not, it allocates a label Lu' and
creates a new label swap for Lu' with Label Lu over interface Iu. In creates a new label swap for Lu' with Label Lu over interface Iu.
Interface Iu is determind via the procedures in Section 2.4.1.2. In
addition, it also adds the label swap(s) from the forwarding state 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 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 swap on interface I for node D is omitted to prevent packet
originated by D to be forwarded back to D. originated by D to be forwarded back to D.
Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2, Node Z determines the downstream MP2MP LSR as per Section 4.3.1.2,
and sends a MP2MP-U Label Map <X, Y, Lu'> to node D. and sends a MP2MP-U Label Map <X, Y, Lu'> to node D.
4.3.1.6. MP2MP root node operation 4.3.1.6. MP2MP root node operation
4.3.1.6.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-D Label Map <X, Y, L> from Suppose root/leaf node Z receives a MP2MP-D Label Map <X, Y, L> from
node D associated with interface I. Z checks whether it already has node D. Z checks whether it already has forwarding state downstream
forwarding state downstream <X, Y>. If not, Z creates forwarding <X, Y>. If not, Z creates forwarding state for downstream to push
state for downstream to push label L on traffic that Z wants to label L on traffic that Z wants to forward down the MP2MP LSP. How
forward down the MP2MP LSP. How it determines what traffic to it determines what traffic to forward on this MP2MP LSP is outside
forward on this MP2MP LSP is outside the scope of this document. If the scope of this document. If Z already has forwarding state for
Z already has forwarding state for downstream <X, Y>, then Z will add downstream <X, Y>, then Z will add the label push for L over
the label push for L over interface I to it. interface I to it. Interface I is determind via the procedures in
Section 2.4.1.2.
Node Z checks if it has forwarding state for upstream <X, Y, D> If Node Z checks if it has forwarding state for upstream <X, Y, D> If
not, Z allocates a label Lu' and creates upstream forwarding state to not, Z allocates a label Lu' and creates upstream forwarding state to
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-U Label Map <X, Y, Lu'> to node D. Since Z is the root of the MP2MP-U Label Map <X, Y, Lu'> to node D. Since Z is the root of the
tree Z will not send a MP2MP-D Label Map and will not receive a tree Z will not send a MP2MP-D Label Map and will not receive a
MP2MP-U Label Map. MP2MP-U Label Map.
4.3.1.6.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-D Label Map <X, Y, L> from Suppose the root node Z receives a MP2MP-D Label Map <X, Y, L> from
node D associated with interface I. Z checks whether it already has node D. Z checks whether it already has forwarding state for
forwarding state for downstream <X, Y>. If not, Z creates downstream downstream <X, Y>. If not, Z creates downstream forwarding state and
forwarding state and installs a outgoing label L over interface I. If installs a outgoing label L over interface I. Interface I is
Z already has forwarding state for downstream <X, Y>, then Z will add determind via the procedures in Section 2.4.1.2. If Z already has
label L over interface I to the existing state. forwarding state for downstream <X, Y>, then Z will add label L over
interface I to the existing state.
Node Z checks if it has forwarding state for upstream <X, Y, D>. If Node Z checks if it has forwarding state for upstream <X, Y, D>. If
not, Z allocates a label Lu' and creates forwarding state to swap Lu' not, Z allocates a label Lu' and creates forwarding state to swap Lu'
with the label swap(s) from the forwarding state downstream <X, Y>, with the label swap(s) from the forwarding state downstream <X, Y>,
except the swap for node D. This allows upstream traffic to go down except the swap for node D. This allows upstream traffic to go down
the MP2MP to other node(s), except the node is was received from. the MP2MP to other node(s), except the node 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-U Label Map <X, Y, Lu'> to it. Section 4.3.1.2, and sends a MP2MP-U Label Map <X, Y, Lu'> to it.
Since Z is the root of the tree Z will not send a MP2MP-D Label 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. and will not receive a MP2MP-U Label Map.
skipping to change at page 21, line 27 skipping to change at page 21, line 43
Label Withdraw message is the same as for transit nodes, except that Label Withdraw message is the same as for transit nodes, except that
the root node would not propagate the Label Withdraw upstream (as it the root node would not propagate the Label Withdraw upstream (as it
has no upstream). has no upstream).
4.3.3. 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.3, except it is applied to MP2MP FECs, using the in Section 2.4.3, except it is applied to MP2MP FECs, using the
procedures described in Section 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. Micro-loops in MP LSPs
Micro-loops created by the unicast routing protocol during
convergence may also effect mLDP MP LSPs. Since the tree building
logic in mLDP is based on unicast routing, a unicast routing loop may
also result in a micro-loop in the MP LSPs. Micro-loops that involve
2 directly connected routers don't create a loop in mLDP. mLDP is
able to prevent this inconsistency by never allowing an upstream LDP
neighbor to be added as a downstream LDP neighbor into the LFT for
the same FEC. Micro-loops that involve more then 2 LSRs are not
prevented.
Micro-loops that involve more then 2 LSRs may create a micro-loop in
the downstream path of either a MP2MP LSP or P2MP LSP and the
upstream path of the MP2MP LSP. The loops are transient and will
disappear as soon as the unicast routing protocol converges. Micro-
loops that occur in the upstream path of a MP2MP LSP may be detected
by including LDP path vector in the MP2MP-U Label Map messages.
These procedures are currently under investigation and are subjected
to further study.
6. The LDP MP Status TLV
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.
The LDP MP Status TLV is encoded as follows: The LDP MP Status TLV is encoded as follows:
0 1 2 3 0 1 2 3
skipping to change at page 22, line 11 skipping to change at page 23, line 5
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LDP MP Status Type: The LDP MP Status Type to be assigned by IANA. LDP MP Status Type: The LDP MP Status Type to be assigned by IANA.
Length: Length of the LDP MP Status Value in octets. Length: Length of the LDP MP Status Value in octets.
Value: One or more LDP MP Status Value elements. Value: One or more LDP MP Status Value elements.
5.1. The LDP MP Status Value Element 6.1. The LDP MP Status Value Element
The LDP MP Status Value Element that is included in the LDP MP Status The LDP MP Status Value Element that is included in the LDP MP Status
TLV Value has the following encoding. TLV Value has the following encoding.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(TBD) | Length | Value ... | | Type(TBD) | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
skipping to change at page 22, line 36 skipping to change at page 23, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the LDP MP Status Value Element is to be assigned Type: The type of the LDP MP Status Value Element is to be assigned
by IANA. by IANA.
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by Value: String of Length octets, to be interpreted as specified by
the Type field. the Type field.
5.2. LDP Messages containing LDP MP Status messages 6.2. LDP Messages containing LDP MP Status messages
The LDP MP status message may appear either in a label mapping The LDP MP status message may appear either in a label mapping
message or a LDP notification message. message or a LDP notification message.
5.2.1. LDP MP Status sent in LDP notification messages 6.2.1. LDP MP Status sent in LDP notification messages
An LDP MP status TLV sent in a notification message must be An LDP MP status TLV sent in a notification message must be
accompanied with a Status TLV. The general format of the accompanied with a Status TLV. The general format of the
Notification Message with an LDP MP status TLV is: Notification Message with an LDP MP status TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length | |0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 31 skipping to change at page 24, line 31
The Status TLV status code is used to indicate that LDP MP status TLV The Status TLV status code is used to indicate that LDP MP status TLV
and an additional information follows in the Notification message's and an additional information follows in the Notification message's
"optional parameter" section. Depending on the actual contents of "optional parameter" section. Depending on the actual contents of
the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may
also be present to provide context to the LDP MP Status TLV. (NOTE: also be present to provide context to the LDP MP Status TLV. (NOTE:
Status Code is pending IANA assignment). Status Code is pending IANA assignment).
Since the notification does not refer to any particular message, the Since the notification does not refer to any particular message, the
Message Id and Message Type fields are set to 0. Message Id and Message Type fields are set to 0.
5.2.2. LDP MP Status TLV in Label Mapping Message 6.2.2. LDP MP Status TLV in Label Mapping Message
An example of the Label Mapping Message defined in RFC3036 is shown An example of the Label Mapping Message defined in RFC3036 is shown
below to illustrate the message with an Optional LDP MP Status TLV below to illustrate the message with an Optional LDP MP Status TLV
present. present.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length | |0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 5 skipping to change at page 25, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV | | Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP Status TLV | | Optional LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Optional Parameters | | Additional Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Upstream label allocation on a LAN 7. Upstream label allocation on a LAN
On a LAN, the procedures so far discussed would require the upstream On a LAN, the procedures so far discussed would require the upstream
LSR to send a copy of the packet to each receiver individually. If LSR to send a copy of the packet to each receiver individually. If
there is more then one receiver on the LAN we don't take full benefit there is more then one receiver on the LAN we don't take full benefit
of the multi-access capability of the network. We may optimize the of the multi-access capability of the network. We may optimize the
bandwidth consumption on the LAN and replication overhead on the bandwidth consumption on the LAN and replication overhead on the
upstream LSR by using upstream label allocation upstream LSR by using upstream label allocation
[I-D.ietf-mpls-upstream-label]. Procedures on how to distribute [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute
upstream labels using LDP is documented in upstream labels using LDP is documented in
[I-D.ietf-mpls-ldp-upstream]. [I-D.ietf-mpls-ldp-upstream].
6.1. LDP Multipoint-to-Multipoint on a LAN 7.1. LDP Multipoint-to-Multipoint on a LAN
The procedure to allocate a context label on a LAN is defined in The procedure to allocate a context label on a LAN is defined in
[I-D.ietf-mpls-upstream-label]. That procedure results in each LSR [I-D.ietf-mpls-upstream-label]. That procedure results in each LSR
on a given LAN having a context label which, on that LAN, can be used on a given LAN having a context label which, on that LAN, can be used
to identify itself uniquely. Each LSR advertises its context label to identify itself uniquely. Each LSR advertises its context label
as an upstream-assigned label, following the procedures of as an upstream-assigned label, following the procedures of
[I-D.ietf-mpls-ldp-upstream]. Any LSR for which the LAN is a [I-D.ietf-mpls-ldp-upstream]. 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
downstream on one of those LSPs, the packet's top label must be the downstream on one of those LSPs, the packet's top label must be the
LSR's context label, and the packet's second label is the label LSR's context label, and the packet's second label is the label
identifying the LSP. We will call the top label the "upstream LSR identifying the LSP. We will call the top label the "upstream LSR
label" and the second label the "LSP label". label" and the second label the "LSP label".
6.1.1. MP2MP downstream forwarding 7.1.1. MP2MP downstream forwarding
The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so
we will use the same procedures as defined in we will use the same procedures as defined in
[I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is
send to the upstream LSR. The label mapping that is received from send to the upstream LSR. The label mapping that is received from
the upstream LSR contains the LSP label for the MP2MP FEC and the the upstream LSR contains the LSP label for the MP2MP FEC and the
upstream LSR context label. The MP2MP downstream path (corresponding upstream LSR context label. The MP2MP downstream path (corresponding
to the LSP label) will be installed the context specific forwarding to the LSP label) will be installed the context specific forwarding
table corresponding to the upstream LSR label. Packets sent by the table corresponding to the upstream LSR label. Packets sent by the
upstream router can be forwarded downstream using this forwarding upstream router can be forwarded downstream using this forwarding
state based on a two label lookup. state based on a two label lookup.
6.1.2. MP2MP upstream forwarding 7.1.2. MP2MP upstream forwarding
A MP2MP LSP also has an upstream forwarding path. Upstream packets A MP2MP LSP also has an upstream forwarding path. Upstream packets
need to be forwarded in the direction of the root and downstream on need to be forwarded in the direction of the root and downstream on
any node on the LAN that has a downstream interface for the LSP. For any node on the LAN that has a downstream interface for the LSP. For
a given MP2MP LSP on a given LAN, exactly one LSR is considered to be a given MP2MP LSP on a given LAN, exactly one LSR is considered to be
the upstream LSR. If an LSR on the LAN receives a packet from one of the upstream LSR. If an LSR on the LAN receives a packet from one of
its downstream interfaces for the LSP, and if it needs to forward the its downstream interfaces for the LSP, and if it needs to forward the
packet onto the LAN, it ensures that the packet's top label is the packet onto the LAN, it ensures that the packet's top label is the
context label of the upstream LSR, and that its second label is the context label of the upstream LSR, and that its second label is the
LSP label that was assigned by the upstream LSR. LSP label that was assigned by the upstream LSR.
Other LSRs receiving the packet will not be able to tell whether the Other LSRs receiving the packet will not be able to tell whether the
packet really came from the upstream router, but that makes no packet really came from the upstream router, but that makes no
difference in the processing of the packet. The upstream LSR will difference in the processing of the packet. The upstream LSR will
see its own upstream LSR in the label, and this will enable it to see its own upstream LSR in the label, and this will enable it to
determine that the packet is traveling upstream. determine that the packet is traveling upstream.
7. Root node redundancy 8. Root node redundancy
The root node is a single point of failure for an MP LSP, whether The root node is a single point of failure for an MP LSP, whether
this is P2MP or MP2MP. The problem is particularly severe for MP2MP this is P2MP or MP2MP. The problem is particularly severe for MP2MP
LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same
root node to set up the MP2MP LSP, because otherwise the traffic root node to set up the MP2MP LSP, because otherwise the traffic
sourced by some leafs is not received by others. Because the root sourced by some leafs is not received by others. Because the root
node is the single point of failure for an MP LSP, we need a fast and node is the single point of failure for an MP LSP, we need a fast and
efficient mechanism to recover from a root node failure. efficient mechanism to recover from a root node failure.
An MP LSP is uniquely identified in the network by the opaque value An MP LSP is uniquely identified in the network by the opaque value
skipping to change at page 25, line 37 skipping to change at page 26, line 37
on each leaf statically or learned using a dynamic protocol. How on each leaf statically or learned using a dynamic protocol. How
leafs learn about the root node is out of the scope of this document. leafs learn about the root node is out of the scope of this document.
Suppose that for the same opaque value we define two (or more) root Suppose that for the same opaque value we define two (or more) root
node addresses and we build a tree to each root using the same opaque node addresses and we build a tree to each root using the same opaque
value. Effectively these will be treated as different MP LSPs in the value. Effectively these will be treated as different MP LSPs in the
network. Once the trees are built, the procedures differ for P2MP network. Once the trees are built, the procedures differ for P2MP
and MP2MP LSPs. The different procedures are explained in the and MP2MP LSPs. The different procedures are explained in the
sections below. sections below.
7.1. Root node redundancy - procedures for P2MP LSPs 8.1. Root node redundancy - procedures for P2MP LSPs
Since all leafs have set up P2MP LSPs to all the roots, they are Since all leafs have set up P2MP LSPs to all the roots, they are
prepared to receive packets on either one of these LSPs. However, prepared to receive packets on either one of these LSPs. However,
only one of the roots should be forwarding traffic at any given time, only one of the roots should be forwarding traffic at any given time,
for the following reasons: 1) to achieve bandwidth savings in the for the following reasons: 1) to achieve bandwidth savings in the
network and 2) to ensure that the receiving leafs don't receive network and 2) to ensure that the receiving leafs don't receive
duplicate packets (since one cannot assume that the receiving leafs duplicate packets (since one cannot assume that the receiving leafs
are able to discard duplicates). How the roots determine which one are able to discard duplicates). How the roots determine which one
is the active sender is outside the scope of this document. is the active sender is outside the scope of this document.
7.2. Root node redundancy - procedures for MP2MP LSPs 8.2. Root node redundancy - procedures for MP2MP LSPs
Since all leafs have set up an MP2MP LSP to each one of the root Since all leafs have set up an MP2MP LSP to each one of the root
nodes for this opaque value, a sending leaf may pick either of the nodes for this opaque value, a sending leaf may pick either of the
two (or more) MP2MP LSPs to forward a packet on. The leaf nodes two (or more) MP2MP LSPs to forward a packet on. The leaf nodes
receive the packet on one of the MP2MP LSPs. The client of the MP2MP receive the packet on one of the MP2MP LSPs. The client of the MP2MP
LSP does not care on which MP2MP LSP the packet is received, as long LSP does not care on which MP2MP LSP the packet is received, as long
as they are for the same opaque value. The sending leaf MUST only as they are for the same opaque value. The sending leaf MUST only
forward a packet on one MP2MP LSP at a given point in time. The forward a packet on one MP2MP LSP at a given point in time. The
receiving leafs are unable to discard duplicate packets because they receiving leafs are unable to discard duplicate packets because they
accept on all LSPs. Using all the available MP2MP LSPs we can accept on all LSPs. Using all the available MP2MP LSPs we can
skipping to change at page 26, line 42 skipping to change at page 27, 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. Make Before Break (MBB) 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 27, line 17 skipping to change at page 28, line 17
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 28, line 7 skipping to change at page 29, 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.
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.
The MBB Status is a type of the LDP MP Status Value Element as The MBB Status is a type of the LDP MP Status Value Element as
described in Section 5.1. It is encoded as follows: described in Section 6.1. It is encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBB Type = 1 | Length = 1 | Status code | | MBB Type = 1 | Length = 1 | Status code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBB Type: Type 1 (to be assigned by IANA) MBB Type: Type 1 (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 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 29, line 28 skipping to change at page 30, 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 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 30, line 19 skipping to change at page 31, 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.
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 31, line 12 skipping to change at page 32, 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 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 [RFC5036]. specification, as described in [RFC5036].
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 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 5 skipping to change at page 34, line 5
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 from the LDP TLV Type Name Space: Status TLV. The value requested from the LDP TLV Type Name Space:
LDP MP Status TLV Type - requested value 0x096F 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.
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, Adrian Farrel and Thomas George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas
Morin. 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
skipping to change at page 34, line 45 skipping to change at page 35, 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
13. References 14. References
13.1. Normative References 14.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.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[I-D.ietf-mpls-upstream-label] [I-D.ietf-mpls-upstream-label]
Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
draft-ietf-mpls-upstream-label-05 (work in progress), draft-ietf-mpls-upstream-label-05 (work in progress),
April 2008. April 2008.
[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.
13.2. Informative References 14.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. 57 change blocks. 
107 lines changed or deleted 155 lines changed or added

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