draft-ietf-mpls-ldp-p2mp-10.txt   draft-ietf-mpls-ldp-p2mp-11.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 12, 2011 I. Wijnands (Editor) Expires: April 11, 2011 I. Wijnands (Editor)
B. Thomas B. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
July 11, 2010 October 8, 2010
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-10 draft-ietf-mpls-ldp-p2mp-11
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. These extensions are also referred Label Switching (MPLS) networks. These extensions are also referred
to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs
without interacting with or relying upon any other multicast tree without interacting with or relying upon any other multicast tree
construction protocol. Protocol elements and procedures for this construction protocol. Protocol elements and procedures for this
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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 12, 2011. This Internet-Draft will expire on April 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5
2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6
2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6
2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8
2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8
2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 9 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 9
2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 11 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 12
2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 12
3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13
4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14 4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 14
4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 14 4.2. The MP2MP downstream and upstream FEC Elements. . . . . . 14
4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15
4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16
4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 19 4.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 20
4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 20 4.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 21
5. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 20 5. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 21
6. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21 6. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21
6.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22 6.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22
6.2. LDP Messages containing LDP MP Status messages . . . . . . 22 6.2. LDP Messages containing LDP MP Status messages . . . . . . 23
6.2.1. LDP MP Status sent in LDP notification messages . . . 22 6.2.1. LDP MP Status sent in LDP notification messages . . . 23
6.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23 6.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23
7. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24 7. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24
7.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24 7.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24
7.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24 7.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 25
7.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24 7.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 25
8. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25 8. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25
8.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25 8.1. Root node redundancy - procedures for P2MP LSPs . . . . . 26
8.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26 8.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26
9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27
9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28
9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 29
9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30
9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30
9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30
9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 31
9.4.4. Receiving a Label Map with MBB status code . . . . . . 31 9.4.4. Receiving a Label Map with MBB status code . . . . . . 31
9.4.5. Receiving a Notification with MBB status code . . . . 31 9.4.5. Receiving a Notification with MBB status code . . . . 32
9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 32
10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32 10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32
11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.1. Normative References . . . . . . . . . . . . . . . . . . . 35 15.1. Normative References . . . . . . . . . . . . . . . . . . . 36
15.2. Informative References . . . . . . . . . . . . . . . . . . 36 15.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 11, line 27 skipping to change at page 11, line 27
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>.
When there are several candidate upstream LSRs, the LSR MAY select When there are several candidate upstream LSRs, the LSR MAY select
one upstream LSR using the following procedure: one upstream LSR. The algorithm used for the LSR selection is a
local matter. If the LSR selection is done over a LAN interface and
the Section 7 procedures are applied, the following procedure SHOULD
be applied to ensure that the same upstream LSR is elected amoung a
set of candidate receivers on that LAN.
1. The candidate upstream LSRs are numbered from lower to higher IP 1. The candidate upstream LSRs are numbered from lower to higher IP
address address
2. The following hash is performed: H = (CRC32(Opaque value)) modulo 2. The following hash is performed: H = (CRC32(Opaque value)) modulo
N, where N is the number of upstream LSRs. N, where N is the number of 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 procedure will ensure that there is a single forwarder over the
candidate upstream LSRs, while ensuring that on a LAN interface a LAN for a particular LSP.
single upstream LSR is selected.
2.4.1.2. Determining the forwarding interface to an LSR 2.4.1.2. Determining the forwarding interface to an LSR
Suppose LSR U receives a MP Label Map message from a downstream 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 D, specifying label L. Suppose further that U is connected to D over
several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U 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 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 to transmit the packet on any of those interfaces. The algorithm it
discover the directly connected interfaces via the LDP Discovery uses to choose a particular interface and next-hop for a particular
messages exchanged between the LSR U and D. The algorithm it uses to such packet is a local matter. For completeness the following
choose a particular interface for a particular such packet is a local procedure MAY be used. LSR U may do a lookup in the unicast routing
matter. table to find the best interface and next-hop to reach LSR D. If the
next-hop and interface are also advertised by LSR D via the LDP
session it can be used to transmit the packet to LSR D.
2.4.1.3. Leaf Operation 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.4. 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
skipping to change at page 12, line 42 skipping to change at page 12, line 46
2.4.1.5. 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 and determind via the procedures in associated with LSR T and determined via the procedures in
Section 2.4.1.2. 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 39 skipping to change at page 13, line 46
would not propagate the Label Withdraw upstream (as it has no would not propagate the Label Withdraw upstream (as it has no
upstream). upstream).
2.4.3. Upstream LSR change 2.4.3. Upstream LSR change
Suppose that for a given node Z participating in a P2MP LSP <X, Y>, Suppose that for a given node Z participating in a P2MP LSP <X, Y>,
the upstream LSR changes from U to U' as per Section 2.4.1.1. 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'. In addition Z MUST send a Label Map <X, Y,
NOT be done before the forwarding state L is removed to avoid L'> to U' and send a Label Withdraw <X, Y, L> to U. Note, if there
microloops. In addition Z MUST send a Label Map <X, Y, L'> to U' and was a downstream mapping from U that was not installed in the
send a Label Withdraw <X, Y, L> to U. Note, if there was a downstream forwarding due to Section 2.4.1.4 it can now be installed.
mapping from U that was not installed in the forwarding due to
Section 2.4.1.4 it can now be installed.
3. Shared Trees 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 19, line 15 skipping to change at page 19, line 22
4.3.1.5. MP2MP transit node operation 4.3.1.5. MP2MP transit node operation
Suppose node Z receives a MP2MP-D Label Map <X, Y, L> from LSR D. Z Suppose node Z receives a MP2MP-D Label Map <X, Y, L> from LSR D. Z
checks whether it has forwarding state for downstream <X, Y>. If checks whether it has forwarding state for downstream <X, Y>. If
not, Z determines its upstream LSR U for <X, Y> as per not, Z determines its upstream LSR U for <X, Y> as per
Section 4.3.1.1. Using this Label Map to update the label forwarding Section 4.3.1.1. Using this Label Map to update the label forwarding
table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U
is different from LSR D, Z will allocate a label L' and install is different from LSR D, Z will allocate a label L' and install
downstream forwarding state to swap label L' with label L over downstream forwarding state to swap label L' with label L over
interface I associated with LSR D and send a MP2MP-D Label Map <X, Y, interface I associated with LSR D and send a MP2MP-D Label Map <X, Y,
L'> to U. Interface I is determind via the procedures in L'> to U. Interface I is determined via the procedures in
Section 2.4.1.2. 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. See Section 4.3.1.3. Once the MP2MP-U Map <X, Y, Lu> from LSR U. See Section 4.3.1.3. Once the MP2MP-U
Label Map is received from LSR U, node Z checks whether it already Label Map is received from LSR U, node Z checks whether it already
has forwarding state upstream <X, Y, D>. If it does, then no further has 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. creates a new label swap for Lu' with Label Lu over interface Iu.
Interface Iu is determind via the procedures in Section 2.4.1.2. In Interface Iu is determined via the procedures in Section 2.4.1.2. In
addition, it also adds the label swap(s) from the forwarding state 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. Z checks whether it already has forwarding state downstream node D. Z checks whether it already has forwarding state downstream
<X, Y>. If not, Z creates forwarding state for downstream to push <X, Y>. If not, Z creates forwarding state for downstream to push
label L on traffic that Z wants to forward down the MP2MP LSP. How label L on traffic that Z wants to forward down the MP2MP LSP. How
it determines what traffic to forward on this MP2MP LSP is outside it determines what traffic to forward on this MP2MP LSP is outside
the scope of this document. If Z already has forwarding state for the scope of this document. If Z already has forwarding state for
downstream <X, Y>, then Z will add the label push for L over downstream <X, Y>, then Z will add the label push for L over
interface I to it. Interface I is determind via the procedures in interface I to it. Interface I is determined via the procedures in
Section 2.4.1.2. 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 swap Lu' with the label swap(s) from the forwarding state downstream
<X, Y>, except the push on interface I for node D. This allows <X, Y>, except the swap on interface I for node D. This allows
upstream traffic to go down the MP2MP to other node(s), except the upstream traffic to go down the MP2MP to other node(s), except the
node from which the traffic was received. Node Z determines the node from which the traffic was received. Node Z determines the
downstream MP2MP LSR as per section Section 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. Z checks whether it already has forwarding state for node D. Z checks whether it already has forwarding state for
downstream <X, Y>. If not, Z creates downstream forwarding state and downstream <X, Y>. If not, Z creates downstream forwarding state and
installs a outgoing label L over interface I. Interface I is installs a outgoing label L over interface I. Interface I is
determind via the procedures in Section 2.4.1.2. If Z already has determined via the procedures in Section 2.4.1.2. If Z already has
forwarding state for downstream <X, Y>, then Z will add label L over forwarding state for downstream <X, Y>, then Z will add label L over
interface I to the existing state. interface I to the existing state.
Node Z checks if it has forwarding state for upstream <X, Y, D>. If Node Z checks if it has forwarding state for upstream <X, Y, D>. If
not, Z allocates a label Lu' and creates forwarding state to swap Lu' not, Z allocates a label Lu' and creates forwarding state to swap Lu'
with the label swap(s) from the forwarding state downstream <X, Y>, with the label swap(s) from the forwarding state downstream <X, Y>,
except the swap for node D. This allows upstream traffic to go down except the swap for node D. This allows upstream traffic to go down
the MP2MP to other node(s), except the node is was received from. the MP2MP to other node(s), except the node 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.
skipping to change at page 22, line 5 skipping to change at page 22, line 20
5. Micro-loops in MP LSPs 5. Micro-loops in MP LSPs
Micro-loops created by the unicast routing protocol during Micro-loops created by the unicast routing protocol during
convergence may also effect mLDP MP LSPs. Since the tree building convergence may also effect mLDP MP LSPs. Since the tree building
logic in mLDP is based on unicast routing, a unicast routing loop may logic in mLDP is based on unicast routing, a unicast routing loop may
also result in a micro-loop in the MP LSPs. Micro-loops that involve also result in a micro-loop in the MP LSPs. Micro-loops that involve
2 directly connected routers don't create a loop in mLDP. mLDP is 2 directly connected routers don't create a loop in mLDP. mLDP is
able to prevent this inconsistency by never allowing an upstream LDP able to prevent this inconsistency by never allowing an upstream LDP
neighbor to be added as a downstream LDP neighbor into the LFT for neighbor to be added as a downstream LDP neighbor into the LFT for
the same FEC. Micro-loops that involve more then 2 LSRs are not the same FEC. Micro-loops that involve more than 2 LSRs are not
prevented. prevented.
Micro-loops that involve more then 2 LSRs may create a micro-loop in Micro-loops that involve more than 2 LSRs may create a micro-loop in
the downstream path of either a MP2MP LSP or P2MP LSP and the 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 upstream path of the MP2MP LSP. The loops are transient and will
disappear as soon as the unicast routing protocol converges. Micro- disappear as soon as the unicast routing protocol converges. Micro-
loops that occur in the upstream path of a MP2MP LSP may be detected 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. by including LDP path vector in the MP2MP-U Label Map messages.
These procedures are currently under investigation and are subjected These procedures are currently under investigation and are subjected
to further study. to further study.
6. The LDP MP Status TLV 6. The LDP MP Status TLV
skipping to change at page 25, line 9 skipping to change at page 25, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP Status TLV | | Optional LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Optional Parameters | | Additional Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. 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 than 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].
7.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
skipping to change at page 28, line 14 skipping to change at page 28, line 31
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 The MBB procedures are an optional extension to the MP LSP building
procedures described in this draft. procedures described in this draft. The procedures in this section
offer a make-before-break behavior, except in cases where the new
path is part of a transient routing loop involving more than 2 LSRs
(also see Section 5).
9.1. MBB overview 9.1. MBB overview
The MBB procedues use additional LDP signaling. The MBB procedures use additional LDP signaling.
Suppose some event causes a downstream LSR-D to select a new upstream 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 LSRs other than LSR-D. After LSR-U
receives a label for FEC-A from LSR-D, it will notify LSR-D when it receives a label for FEC-A from LSR-D, it will notify LSR-D when it
knows that the LSP for FEC-A has been established from the root to knows that the LSP for FEC-A has been established from the root to
itself. When LSR-D receives this MBB notification it will change its itself. When LSR-D receives this MBB notification it will change its
next hop for the LSP root to LSR-U. next hop for the LSP root to LSR-U.
The assumption is that if LSR-U has received an MBB notification from The assumption is that if LSR-U has received an MBB notification from
its upstream router for the FEC-A LSP and has installed forwarding its upstream router for the FEC-A LSP and has installed forwarding
state the LSP it is capable of forwarding packets on the LSP. At state the LSP it is capable of forwarding packets on the LSP. At
that point LSR-U should signal LSR-D by means of an MBB notification that point LSR-U should signal LSR-D by means of an MBB notification
that it has become part of the tree identified by FEC-A and that that it has become part of the tree identified by FEC-A and that
LSR-D should initiate its switchover to the LSP. LSR-D should initiate its switchover to the LSP.
At LSR-U the LSP for FEC-A may be in 1 of 3 states. At LSR-U the LSP for FEC-A may be in 1 of 3 states.
1. There is no state for FEC-A. 1. There is no state for FEC-A.
2. State for FEC-A exists and LSR-U is waiting for MBB notification 2. State for FEC-A exists and LSR-U is waiting for MBB notification
that the LSP from the root to it exists. that the LSP from the root to it exists.
3. State for FEC-A exists and the MBB notification has been 3. State for FEC-A exists and the MBB notification has been received
received. or it is the Root node for FEC-A.
After LSR-U receives LSR-D's Label Mapping message for FEC-A LSR-U 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 LSR-U
upstream LSR it transitions to LSP state #3 and sends an MBB it transitions to LSP state #3 and sends an MBB notification to
notification to LSR-D. LSR-D.
9.2. The MBB Status code 9.2. The MBB Status code
As noted in Section 9.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 LSRs 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 6.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 |
skipping to change at page 32, line 14 skipping to change at page 32, line 32
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 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. If a downstream LSR detects that the old upstream LSR went
down while waiting for the MBB Notification from the new upstream
LSR, the downstream LSR can immediately proceed without waiting for
the timer to expire.
9.4.4. Receiving a Label Map with MBB status code 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)>. If router Z upstream LSR for <X, Y> happens to be N2,
then Z MUST not send an MBB notification to N2 at once. Sending the
MBB notification to N2 must be done only after Z upstream for <X, Y>
stops being N2.
9.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.
 End of changes. 36 change blocks. 
66 lines changed or deleted 78 lines changed or added

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