draft-ietf-mpls-ldp-p2mp-05.txt   draft-ietf-mpls-ldp-p2mp-06.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: November 2, 2008 I. Wijnands (Editor) Expires: October 22, 2009 I. Wijnands (Editor)
B. Thomas B. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
April 20, 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-05 draft-ietf-mpls-ldp-p2mp-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 November 2, 2008. This Internet-Draft will expire on October 22, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Copyright (C) The IETF Trust (2008). This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes extensions to the Label Distribution Protocol This document describes extensions to the Label Distribution Protocol
(LDP) for the setup of point to multi-point (P2MP) and multipoint-to- (LDP) for the setup of point to multi-point (P2MP) and multipoint-to-
multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol
Label Switching (MPLS) networks. LDP constructs the P2MP or MP2MP Label Switching (MPLS) networks. LDP constructs the P2MP or MP2MP
LSPs without interacting with or relying upon any other multicast LSPs without interacting with or relying upon any other multicast
tree construction protocol. Protocol elements and procedures for tree construction protocol. Protocol elements and procedures for
this solution are described for building such LSPs in a receiver- this solution are described for building such LSPs in a receiver-
initiated manner. There can be various applications for P2MP/MP2MP initiated manner. There can be various applications for P2MP/MP2MP
LSPs, for example IP multicast or support for multicast in BGP/MPLS LSPs, for example IP multicast or support for multicast in BGP/MPLS
L3VPNs. Specification of how such applications can use a LDP L3VPNs. Specification of how such applications can use a LDP
signaled P2MP/MP2MP LSP is outside the scope of this document. signaled P2MP/MP2MP LSP is outside the scope of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 5 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6
2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7
2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 6 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7
2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 8 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9
2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 8 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 9
2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 9 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 10
2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 10 2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . 13
3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 13 4. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 14
4.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 13 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. . . . . . 15
4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 14 4.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 15
4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 16 4.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 17
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. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 20 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 21
5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 20 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 22
5.2. LDP Messages containing LDP MP Status messages . . . . . . 21 5.2. LDP Messages containing LDP MP Status messages . . . . . . 22
5.2.1. LDP MP Status sent in LDP notification messages . . . 21 5.2.1. LDP MP Status sent in LDP notification messages . . . 22
5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 22 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 23
6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 22 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 24
6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 23 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 24
6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 23 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 24
6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 23 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 24
7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 23 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 25
7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 24 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 25
7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 24 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 26
8. MP LSP micro loops . . . . . . . . . . . . . . . . . . . . . . 25 8. MP2MP micro loop prevention . . . . . . . . . . . . . . . . . 26
8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 25 8.1. MP2MP upstream path . . . . . . . . . . . . . . . . . . . 27
8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 26 8.2. MP2MP micro loop prevention procedures . . . . . . . . . . 27
9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 26 9. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 27
9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 27 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . 29 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31
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 . . . . . . 30 9.4.4. Receiving a Label Map with MBB status code . . . . . . 32
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. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 32 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
The LDP protocol is described in [1]. It defines mechanisms for The LDP protocol is described in [RFC5036]. It defines mechanisms
setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs for setting up point-to-point (P2P) and multipoint-to-point (MP2P)
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
LSP allows traffic from multiple ingress nodes to be delivered to LSP allows traffic from multiple ingress nodes to be delivered to
multiple egress nodes. Only a single copy of the packet will be sent multiple egress nodes. Only a single copy of the packet will be sent
on any link traversed by the MP LSP (see note at end of on any link traversed by the MP LSP (see note at end of
Section 2.4.1). This is accomplished without the use of a multicast Section 2.4.1). This is accomplished without the use of a multicast
protocol in the network. There can be several MP LSPs rooted at a protocol in the network. There can be several MP LSPs rooted at a
given ingress node, each with its own identifier. given ingress node, each with its own identifier.
The solution assumes that the leaf nodes of the MP LSP know the root The solution assumes that the leaf nodes of the MP LSP know the root
node and identifier of the MP LSP to which they belong. The node and identifier of the MP LSP to which they belong. The
mechanisms for the distribution of this information are outside the mechanisms for the distribution of this information are outside the
scope of this document. The specification of how an application can scope of this document. The specification of how an application can
use a MP LSP signaled by LDP is also outside the scope of this use a MP LSP signaled by LDP is also outside the scope of this
document. document.
Interested readers may also wish to peruse the requirements draft [9] Interested readers may also wish to peruse the requirements draft
and other documents [8] and [10]. [I-D.ietf-mpls-mp-ldp-reqs] and other documents [RFC4875] and
[I-D.ietf-l3vpn-2547bis-mcast].
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
The following terminology is taken from [9]. The following terminology is taken from [I-D.ietf-mpls-mp-ldp-reqs].
P2P LSP: An LSP that has one Ingress LSR and one Egress LSR. P2P LSP: An LSP that has one Ingress LSR and one Egress LSR.
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
LSRs. LSRs.
MP2P LSP: An LSP that has one or more Ingress LSRs and one unique MP2P LSP: An LSP that has one or more Ingress LSRs and one unique
Egress LSR. Egress LSR.
MP2MP LSP: An LSP that connects a set of nodes, such that traffic MP2MP LSP: An LSP that connects a set of nodes, such that traffic
skipping to change at page 5, line 20 skipping to change at page 6, line 20
Ingress LSR: An ingress LSR for a particular LSP is an LSR that can Ingress LSR: An ingress LSR for a particular LSP is an LSR that can
send a data packet along the LSP. MP2MP LSPs can have multiple send a data packet along the LSP. MP2MP LSPs can have multiple
ingress LSRs, P2MP LSPs have just one, and that node is often ingress LSRs, P2MP LSPs have just one, and that node is often
referred to as the "root node". referred to as the "root node".
Egress LSR: An egress LSR for a particular LSP is an LSR that can Egress LSR: An egress LSR for a particular LSP is an LSR that can
remove a data packet from that LSP for further processing. P2P remove a data packet from that LSP for further processing. P2P
and MP2P LSPs have only a single egress node, but P2MP and MP2MP and MP2P LSPs have only a single egress node, but P2MP and MP2MP
LSPs can have multiple egress nodes. LSPs can have multiple egress nodes.
Transit LSR: An LSR that has reachability to a) the root of the MP Transit LSR: An LSR that has reachability to the root of the MP LSP
LSP via a directly connected upstream LSR and b) via one or more via a directly connected upstream LSR and one or more directly
directly connected downstream LSRs. connected downstream LSRs.
Bud LSR: An LSR that is an egress but also has one or more directly Bud LSR: An LSR that is an egress but also has one or more directly
connected downstream LSRs. connected downstream LSRs.
Leaf node: A Leaf node can be either an Egress or Bud LSR when Leaf node: A Leaf node can be either an Egress or Bud LSR when
referred in the context of a P2MP LSP. In the context of a MP2MP referred in the context of a P2MP LSP. In the context of a MP2MP
LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and
can also be a Bud LSR. can also be a Bud LSR.
2. Setting up P2MP LSPs with LDP 2. Setting up P2MP LSPs with LDP
skipping to change at page 6, line 8 skipping to change at page 7, line 8
is done is outside the scope of this document. Transit nodes install is done is outside the scope of this document. Transit nodes install
MPLS forwarding state and propagate the P2MP LSP setup (and tear- MPLS forwarding state and propagate the P2MP LSP setup (and tear-
down) toward the root. The root node installs forwarding state to down) toward the root. The root node installs forwarding state to
map traffic into the P2MP LSP; how the root node determines which map traffic into the P2MP LSP; how the root node determines which
traffic should go over the P2MP LSP is outside the scope of this traffic should go over the P2MP LSP is outside the scope of this
document. document.
2.1. Support for P2MP LSP setup with LDP 2.1. Support for P2MP LSP setup with LDP
Support for the setup of P2MP LSPs is advertised using LDP Support for the setup of P2MP LSPs is advertised using LDP
capabilities as defined in [6]. An implementation supporting the capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An
P2MP procedures specified in this document MUST implement the implementation supporting the P2MP procedures specified in this
procedures for Capability Parameters in Initialization Messages. document MUST implement the procedures for Capability Parameters in
Initialization Messages.
A new Capability Parameter TLV is defined, the P2MP Capability. A new Capability Parameter TLV is defined, the P2MP Capability.
Following is the format of the P2MP Capability Parameter. Following is the format of the P2MP Capability Parameter.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| P2MP Capability (TBD IANA) | Length (= 1) | |1|0| P2MP Capability (TBD IANA) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |1| Reserved |
skipping to change at page 7, line 25 skipping to change at page 8, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the P2MP FEC Element is to be assigned by IANA. Type: The type of the P2MP FEC Element is to be assigned by IANA.
Address Family: Two octet quantity containing a value from ADDRESS Address Family: Two octet quantity containing a value from ADDRESS
FAMILY NUMBERS in [3] that encodes the address family for the Root FAMILY NUMBERS in [RFC3232] that encodes the address family for
LSR Address. the Root LSR Address.
Address Length: Length of the Root LSR Address in octets. Address Length: Length of the Root LSR Address in octets.
Root Node Address: A host address encoded according to the Address Root Node Address: A host address encoded according to the Address
Family field. Family field.
Opaque Length: The length of the Opaque Value, in octets. Opaque Length: The length of the Opaque Value, in octets.
Opaque Value: One or more MP Opaque Value elements, uniquely Opaque Value: One or more MP Opaque Value elements, uniquely
identifying the P2MP LSP in the context of the Root Node. This is identifying the P2MP LSP in the context of the Root Node. This is
skipping to change at page 10, line 13 skipping to change at page 11, line 13
leaf node. leaf node.
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 [11] except those All labels discussed here are downstream-assigned
which are assigned using the procedures of Section 6. [I-D.ietf-mpls-multicast-encaps] except those which are assigned
using the procedures of Section 6.
2.4.1.1. Determining one's 'upstream LSR' 2.4.1.1. Determining one's 'upstream LSR'
Each node that is either a Leaf or Transit LSR of an 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 using the following procedure:
1. The candidate upstream LSRs are numbered from lower to higher IP 1. The candidate upstream LSRs are numbered from lower to higher IP
skipping to change at page 10, line 48 skipping to change at page 11, line 49
single upstream LSR is selected. single upstream LSR is selected.
2.4.1.2. Leaf Operation 2.4.1.2. 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.3. Transit Node operation
Suppose a transit node Z receives a P2MP Label Map <X, Y, L> from LDP Suppose a transit node Z receives a P2MP Label Map <X, Y, L> from LSR
peer 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
allocates a label L', and installs state to swap L' with L over determines its upstream LSR U for <X, Y> as per Section 2.4.1.1.
interface I associated with peer T. Z also determines its upstream Using this Label Map to update the label forwarding table MUST NOT be
LSR U for <X, Y> as per Section 2.4.1.1, and sends a P2MP Label Map done as long as LSR T is equal to LSR U. If LSR U is different from
<X, Y, L'> to U. 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
<X, Y, L'> to LSR U.
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
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>}. 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
be retained and MUST not update the label forwarding table.
2.4.1.4. Root Node Operation 2.4.1.4. Root Node Operation
Suppose the root node Z receives a P2MP Label Map <X, Y, L> from peer 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 peer T. associated with LSR T.
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 12, line 14 skipping to change at page 13, line 18
2.4.2.3. Root Node Operation 2.4.2.3. Root Node Operation
The procedure when the root node of a P2MP LSP receives a Label The procedure when the root node of a P2MP LSP receives a Label
Withdraw message are the same as for transit nodes, except that it Withdraw message are the same as for transit nodes, except that it
would not propagate the Label Withdraw upstream (as it has no would not propagate the Label Withdraw upstream (as it has no
upstream). upstream).
2.4.3. Upstream LSR change 2.4.3. Upstream LSR change
If, for a given node Z participating in a P2MP LSP <X, Y>, the Suppose that for a given node Z participating in a P2MP LSP <X, Y>,
upstream LSR changes, say from U to U', then Z MUST update its the upstream LSR changes from U to U' as per Section 2.4.1.1. If U'
forwarding state by deleting the state for label L, allocating a new is present in the forwarding table of <X, Y> then it MUST be removed.
label, L', for <X,Y>, and installing the forwarding state for L'. In Z MUST also update its forwarding state by deleting the state for
addition Z MUST send a Label Map <X, Y, L'> to U' and send a Label label L, allocating a new label, L', for <X, Y>, and installing the
Withdraw <X, Y, L> to U. forwarding state for L'. Installing the forwarding state for L' MUST
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
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
Section 2.4.1.3 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,
but the underlying multicasting mechanism uses a P2MP LSP. One but the underlying multicasting mechanism uses a P2MP LSP. One
example where a Shared Tree is useful is video-conferencing. Another example where a Shared Tree is useful is video-conferencing. Another
is Virtual Private LAN Service (VPLS) [7], where for some types of is Virtual Private LAN Service (VPLS) [RFC4664], where for some types
traffic, each device participating in a VPLS must send packets to of traffic, each device participating in a VPLS must send packets to
every other device in that VPLS. every other device in that VPLS.
One way to build a Shared Tree is to build an LDP P2MP LSP rooted at One way to build a Shared Tree is to build an LDP P2MP LSP rooted at
a common point, the Shared Root (SR), and whose leaves are all the a common point, the Shared Root (SR), and whose leaves are all the
members of the group. Each member of the Shared Tree unicasts members of the group. Each member of the Shared Tree unicasts
traffic to the SR (using, for example, the MP2P LSP created by the traffic to the SR (using, for example, the MP2P LSP created by the
unicast LDP FEC advertised by the SR); the SR then splices this unicast LDP FEC advertised by the SR); the SR then splices this
traffic into the LDP P2MP LSP. The SR may be (but need not be) a traffic into the LDP P2MP LSP. The SR may be (but need not be) a
member of the multicast group. member of the multicast group.
skipping to change at page 13, line 35 skipping to change at page 14, line 45
downstream node MUST never be forwarded back out to that same node. downstream node MUST never be forwarded back out to that same node.
Mapping traffic to the MP2MP LSP may happen at any leaf node. How Mapping traffic to the MP2MP LSP may happen at any leaf node. How
that mapping is established is outside the scope of this document. that mapping is established is outside the scope of this document.
Due to how a MP2MP LSP is built a leaf LSR that is sending packets on Due to how a MP2MP LSP is built a leaf LSR that is sending packets on
the MP2MP LSP does not receive its own packets. There is also no the MP2MP LSP does not receive its own packets. There is also no
additional mechanism needed on the root or transit LSR to match additional mechanism needed on the root or transit LSR to match
upstream traffic to the downstream forwarding state. Packets that upstream traffic to the downstream forwarding state. Packets that
are forwarded over a MP2MP LSP will not traverse a link more than are forwarded over a MP2MP LSP will not traverse a link more than
once, with the possible exception of LAN links (see Section 4.3.1), once, with the possible exception of LAN links (see Section 4.3.1),
if the procedures of [4] are not provided. if the procedures of [I-D.ietf-mpls-upstream-label] are not provided.
4.1. Support for MP2MP LSP setup with LDP 4.1. Support for MP2MP LSP setup with LDP
Support for the setup of MP2MP LSPs is advertised using LDP Support for the setup of MP2MP LSPs is advertised using LDP
capabilities as defined in [6]. An implementation supporting the capabilities as defined in [I-D.ietf-mpls-ldp-capabilities]. An
MP2MP procedures specified in this document MUST implement the implementation supporting the MP2MP procedures specified in this
procedures for Capability Parameters in Initialization Messages. document MUST implement the procedures for Capability Parameters in
Initialization Messages.
A new Capability Parameter TLV is defined, the MP2MP Capability. A new Capability Parameter TLV is defined, the MP2MP Capability.
Following is the format of the MP2MP Capability Parameter. Following is the format of the MP2MP Capability Parameter.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| MP2MP Capability (TBD IANA) | Length (= 1) | |1|0| MP2MP Capability (TBD IANA) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |1| Reserved |
skipping to change at page 14, line 37 skipping to change at page 15, line 43
FEC is a misnomer. The description of the MP2MP FEC Elements follow. FEC is a misnomer. The description of the MP2MP FEC Elements follow.
The structure, encoding and error handling for the MP2MP downstream The structure, encoding and error handling for the MP2MP downstream
and upstream FEC Elements are the same as for the P2MP FEC Element and upstream FEC Elements are the same as for the P2MP FEC Element
described in Section 2.2. The difference is that two new FEC types described in Section 2.2. The difference is that two new FEC types
are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD). are used: MP2MP downstream type (TBD) and MP2MP upstream type (TBD).
If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element
MUST be the only FEC Element in the FEC TLV. MUST be the only FEC Element in the FEC TLV.
Note, except when using the procedures of [4], the MPLS labels used Note, except when using the procedures of
are "downstream-assigned" [11], even if they are bound to the [I-D.ietf-mpls-upstream-label], the MPLS labels used are "downstream-
"upstream FEC element". assigned" [I-D.ietf-mpls-multicast-encaps], even if they are bound to
the "upstream FEC element".
4.3. Using the MP2MP FEC Elements 4.3. Using the MP2MP FEC Elements
This section defines the rules for the processing and propagation of This section defines the rules for the processing and propagation of
the MP2MP FEC Elements. The following notation is used in the the MP2MP FEC Elements. The following notation is used in the
processing rules: processing rules:
1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an 1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an
MP2MP LSP downstream path with root node address X and opaque MP2MP LSP downstream path with root node address X and opaque
value Y. value Y.
skipping to change at page 16, line 19 skipping to change at page 17, line 26
leaf of the MP2MP LSP. leaf of the MP2MP LSP.
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 [11] except those All labels discussed here are downstream-assigned
which are assigned using the procedures of Section 6. [I-D.ietf-mpls-multicast-encaps] except those which are assigned
using the procedures of Section 6.
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 17, line 31 skipping to change at page 18, line 41
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 When node Z receives a MP2MP-D Label Map <X, Y, L> from LSR D
associated with interface I, it checks whether it has forwarding associated with interface I, it checks whether it has forwarding
state for downstream <X, Y>. If not, Z allocates a label L' and state for downstream <X, Y>. If not, Z determines its upstream LSR U
installs downstream forwarding state to swap label L' with label L for <X, Y> as per Section 4.3.1.1. Using this Label Map to update
over interface I. Z also determines its upstream LSR U for <X, Y> as the label forwarding table MUST NOT be done as long as LSR D is equal
per Section 4.3.1.1, and sends a MP2MP-D Label Map <X, Y, L'> to U. to LSR U. If LSR U is different from LSR D, Z will allocate a label
L' and install downstream forwarding state to swap label L' with
label L over interface I and send a MP2MP-D Label Map <X, Y, L'> to
U.
If Z already has forwarding state for downstream <X, Y>, all that Z If Z already has forwarding state for downstream <X, Y>, all that Z
needs to do 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.
skipping to change at page 22, line 45 skipping to change at page 24, line 12
| Additional Optional Parameters | | Additional Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Upstream label allocation on a LAN 6. Upstream label allocation on a LAN
On a LAN, the procedures so far discussed would require the upstream On a LAN, the procedures so far discussed would require the upstream
LSR to send a copy of the packet to each receiver individually. If LSR to send a copy of the packet to each receiver individually. If
there is more 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 [4]. Procedures on upstream LSR by using upstream label allocation
how to distribute upstream labels using LDP is documented in [5]. [I-D.ietf-mpls-upstream-label]. Procedures on how to distribute
upstream labels using LDP is documented in
[I-D.ietf-mpls-ldp-upstream].
6.1. LDP Multipoint-to-Multipoint on a LAN 6.1. LDP Multipoint-to-Multipoint on a LAN
The procedure to allocate a context label on a LAN is defined in [4]. The procedure to allocate a context label on a LAN is defined in
That procedure results in each LSR on a given LAN having a context [I-D.ietf-mpls-upstream-label]. That procedure results in each LSR
label which, on that LAN, can be used to identify itself uniquely. on a given LAN having a context label which, on that LAN, can be used
Each LSR advertises its context label as an upstream-assigned label, to identify itself uniquely. Each LSR advertises its context label
following the procedures of [5]. Any LSR for which the LAN is a as an upstream-assigned label, following the procedures of
[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 6.1.1. MP2MP downstream forwarding
The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so The downstream path of a MP2MP LSP is much like a normal P2MP LSP, so
we will use the same procedures as defined in [5]. A label request we will use the same procedures as defined in
for a LSP label is send to the upstream LSR. The label mapping that [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is
is received from the upstream LSR contains the LSP label for the send to the upstream LSR. The label mapping that is received from
MP2MP FEC and the upstream LSR context label. The MP2MP downstream the upstream LSR contains the LSP label for the MP2MP FEC and the
path (corresponding to the LSP label) will be installed the context upstream LSR context label. The MP2MP downstream path (corresponding
specific forwarding table corresponding to the upstream LSR label. to the LSP label) will be installed the context specific forwarding
Packets sent by the upstream router can be forwarded downstream using table corresponding to the upstream LSR label. Packets sent by the
this forwarding state based on a two label lookup. upstream router can be forwarded downstream using this forwarding
state based on a two label lookup.
6.1.2. MP2MP upstream forwarding 6.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
skipping to change at page 25, line 24 skipping to change at page 26, line 42
The advantage of pre-building multiple MP2MP LSPs for a single opaque The advantage of pre-building multiple MP2MP LSPs for a single opaque
value is that convergence from a root node failure happens as fast as value is that convergence from a root node failure happens as fast as
the unicast routing protocol is able to notify. There is no need for the unicast routing protocol is able to notify. There is no need for
an additional protocol to advertise to the leaf nodes which root node an additional protocol to advertise to the leaf nodes which root node
is the active root. The root selection is a local leaf policy that is the active root. The root selection is a local leaf policy that
does not need to be coordinated with other leafs. The disadvantage does not need to be coordinated with other leafs. The disadvantage
of pre-building multiple MP2MP LSPs is that more label resources are of pre-building multiple MP2MP LSPs is that more label resources are
used, depending on how many root nodes are defined. used, depending on how many root nodes are defined.
8. MP LSP micro loops 8. MP2MP micro loop prevention
A MP LSP is built hop by hop following the best path to reach the A MP LSP is built hop by hop following the best path to reach the
root of the LSP. If the routing protocol used to calculate the best root of the LSP. If the routing protocol used to calculate the best
path is subjected to micro-loops, the MP LSP may contain a micro path is subjected to micro-loops, the MP LSP may contain a micro
loop. Both P2MP and MP2MP LSPs may end up containing a micro-loop. loop. Both P2MP and MP2MP LSPs may end up containing a micro-loop.
However, there is a difference between loops in P2MP and MP2MP LSP. However, there is a difference between loops in P2MP and MP2MP LSP.
In a P2MP LSP, once a loop s formed, no new packet can enter it, but In a P2MP LSP, once a loop s formed, no new packet can enter it, but
in a MP2MP LSP, packets may continue to enter the loop. This makes a in a MP2MP LSP, packets may continue to enter the loop. This makes a
loop in MP2MP LSP worse compared to loop in P2MP LSP. If the routing loop in MP2MP LSP worse compared to loop in P2MP LSP. If the routing
protocol is not subjected to micro-loops, the MP LSP will not end up protocol is not subjected to micro-loops, the MP LSP will not end up
skipping to change at page 26, line 9 skipping to change at page 27, line 24
as a P2MP LSP. Other injection point(s) are from each leaf towards as a P2MP LSP. Other injection point(s) are from each leaf towards
the root of the LSP. These procedures solve micro-loops which are the root of the LSP. These procedures solve micro-loops which are
the result of injecting packets from the leaf towards the root. It the result of injecting packets from the leaf towards the root. It
does not solve micro-loops which are the result of injecting packets does not solve micro-loops which are the result of injecting packets
from the root. This makes the MP2MP LSP as good as P2MP LSPs. from the root. This makes the MP2MP LSP as good as P2MP LSPs.
8.2. MP2MP micro loop prevention procedures 8.2. MP2MP micro loop prevention procedures
Based on the procedures defined in Section 4.3.1.3 ordered mode is Based on the procedures defined in Section 4.3.1.3 ordered mode is
used to build the upstream path from the root down to the leaves. used to build the upstream path from the root down to the leaves.
The MP2MP-U Label Map will add a path vector TLV [1] as optional The MP2MP-U Label Map will add a path vector TLV [RFC5036] as
parameter to the MP2MP-U Label Map message. Each LSR will add its optional parameter to the MP2MP-U Label Map message. Each LSR will
own router ID to the path list TLV before sending the MP2MP-U Label add its own router ID to the path list TLV before sending the MP2MP-U
Map <X, Y, D> to the downstream LSRs. Suppose node Z receives a Label Map <X, Y, D> to the downstream LSRs. Suppose node Z receives
MP2MP-U Label Map from LSR D with Label Lu. If node Z finds its own a MP2MP-U Label Map from LSR D with Label Lu. If node Z finds its
router ID in the path vector list it will complete the procedures for own router ID in the path vector list it will complete the procedures
MP2MP LSP's defined in this draft with the following exception, the for MP2MP LSP's defined in this draft with the following exception,
Label Forwarding Database for the MP2MP upstream <X, Y, D> with Lu is the Label Forwarding Database for the MP2MP upstream <X, Y, D> with
not installed, but is retained. By not installing Label Lu the loop Lu is not installed, but is retained. By not installing Label Lu the
is prevented. If node Z receives a MP2MP-U Label Map that updates loop is prevented. If node Z receives a MP2MP-U Label Map that
the path vector list such that it does not include its own router ID, updates the path vector list such that it does not include its own
Label Lu can be safely installed into forwarding. router ID, Label Lu can be safely installed into forwarding.
9. 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
skipping to change at page 28, line 25 skipping to change at page 29, line 39
Length: 1 Length: 1
Status code: 1 = MBB request Status code: 1 = MBB request
2 = MBB ack 2 = MBB ack
9.3. The MBB capability 9.3. The MBB capability
An LSR MAY advertise that it is capable of handling MBB LSPs using An LSR MAY advertise that it is capable of handling MBB LSPs using
the capability advertisement as defined in [6]. The LDP MP MBB the capability advertisement as defined in
capability has the following format: [I-D.ietf-mpls-ldp-capabilities]. The LDP MP MBB capability has the
following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP MBB Capability | Length = 1 | |1|0| LDP MP MBB Capability | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |1| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Note: LDP MP MBB Capability (Pending IANA assignment) Note: LDP MP MBB Capability (Pending IANA assignment)
skipping to change at page 31, line 34 skipping to change at page 32, line 51
including a MBB Status code. If the MBB procedures apply to a MP2MP including a MBB Status code. If the MBB procedures apply to a MP2MP
downstream FEC element, the upstream path to a node N is only downstream FEC element, the upstream path to a node N is only
installed in the label forwarding database if node N is part of the installed in the label forwarding database if node N is part of the
active accepting element. If node N is part of an inactive accepting active accepting element. If node N is part of an inactive accepting
element, the upstream path is installed when this inactive accepting element, the upstream path is installed when this inactive accepting
element is activated. element is activated.
10. Security Considerations 10. Security Considerations
The same security considerations apply as for the base LDP The same security considerations apply as for the base LDP
specification, as described in [1]. specification, as described in [RFC5036].
11. 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
skipping to change at page 34, line 28 skipping to change at page 35, line 42
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
1831 Diegem 1831 Diegem
Belgium Belgium
E-mail: ice@cisco.com E-mail: ice@cisco.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[1] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[4] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label [I-D.ietf-mpls-upstream-label]
Assignment and Context-Specific Label Space", Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
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.
[5] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for [I-D.ietf-mpls-ldp-upstream]
LDP", draft-ietf-mpls-ldp-upstream-02 (work in progress), Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment
November 2007. for LDP", draft-ietf-mpls-ldp-upstream-02 (work in
progress), November 2007.
[6] Thomas, B., "LDP Capabilities", [I-D.ietf-mpls-ldp-capabilities]
Thomas, B., "LDP Capabilities",
draft-ietf-mpls-ldp-capabilities-02 (work in progress), draft-ietf-mpls-ldp-capabilities-02 (work in progress),
March 2008. March 2008.
14.2. Informative References 14.2. Informative References
[7] 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.
[8] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
to Resource Reservation Protocol - Traffic Engineering "Extensions to Resource Reservation Protocol - Traffic
(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths Engineering (RSVP-TE) for Point-to-Multipoint TE Label
(LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[9] Roux, J., "Requirements for Point-To-Multipoint Extensions to [I-D.ietf-mpls-mp-ldp-reqs]
the Label Distribution Protocol", Roux, J., "Requirements for Point-To-Multipoint Extensions
to the Label Distribution Protocol",
draft-ietf-mpls-mp-ldp-reqs-04 (work in progress), draft-ietf-mpls-mp-ldp-reqs-04 (work in progress),
February 2008. February 2008.
[10] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., [I-D.ietf-l3vpn-2547bis-mcast]
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/ Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
progress), January 2008. MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work
in progress), January 2008.
[11] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [I-D.ietf-mpls-multicast-encaps]
Multicast Encapsulations", draft-ietf-mpls-multicast-encaps-09 Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
(work in progress), May 2008. Multicast Encapsulations",
draft-ietf-mpls-multicast-encaps-09 (work in progress),
May 2008.
Authors' Addresses Authors' Addresses
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: ina@juniper.net Email: ina@juniper.net
skipping to change at page 37, line 4 skipping to change at line 1602
Email: ice@cisco.com Email: ice@cisco.com
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough 01719 Boxborough 01719
US US
Email: bobthomas@alum.mit.edu Email: bobthomas@alum.mit.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 48 change blocks. 
168 lines changed or deleted 213 lines changed or added

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