draft-ietf-mpls-ldp-p2mp-13.txt   draft-ietf-mpls-ldp-p2mp-14.txt 
Network Working Group I. Minei, Ed. Network Working Group I. Minei, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track IJ. Wijnands, Ed. Intended status: Standards Track IJ. Wijnands, Ed.
Expires: October 24, 2011 Cisco Systems, Inc. Expires: December 18, 2011 Cisco Systems, Inc.
K. Kompella K. Kompella
Juniper Networks Juniper Networks
B. Thomas B. Thomas
Cisco Systems, Inc. June 16, 2011
April 22, 2011
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-13 draft-ietf-mpls-ldp-p2mp-14
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- for the setup of Point-to-Multipoint and Multipoint-to-Multipoint
multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switched Paths in Multi-Protocol Label Switching networks.
Label Switching (MPLS) networks. These extensions are also referred These extensions are also referred to as Multipoint LDP. Multipoint
to as Multipoint LDP (mLDP). mLDP constructs the P2MP or MP2MP LSPs LDP constructs the P2MP or MP2MP Label Switched Paths without
without interacting with or relying upon any other multicast tree 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
solution are described for building such LSPs in a receiver-initiated solution are described for building such Label Switched Paths in a
manner. There can be various applications for P2MP/MP2MP LSPs, for receiver-initiated manner. There can be various applications for
example IP multicast or support for multicast in BGP/MPLS L3VPNs. Multipoint Label Switched Paths, for example IP multicast or support
Specification of how such applications can use a LDP signaled P2MP/ for multicast in BGP/MPLS L3VPNs. Specification of how such
MP2MP LSPs is outside the scope of this document. applications can use a LDP signaled Multipoint Label Switched Path is
outside the scope of this document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 24, 2011. This Internet-Draft will expire on December 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions used in this document . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6 2. Setting up P2MP LSPs with LDP . . . . . . . . . . . . . . . . 6
2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 6 2.1. Support for P2MP LSP setup with LDP . . . . . . . . . . . 7
2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7 2.2. The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 7
2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9 2.3. The LDP MP Opaque Value Element . . . . . . . . . . . . . 9
2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 10 2.3.1. The Generic LSP Identifier . . . . . . . . . . . . . . 10
2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 11 2.4. Using the P2MP FEC Element . . . . . . . . . . . . . . . . 11
2.4.1. Label Map . . . . . . . . . . . . . . . . . . . . . . 11 2.4.1. Label Mapping . . . . . . . . . . . . . . . . . . . . 11
2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Label Withdraw . . . . . . . . . . . . . . . . . . . . 13
2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 14 2.4.3. Upstream LSR change . . . . . . . . . . . . . . . . . 14
3. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 15 3. Setting up MP2MP LSPs with LDP . . . . . . . . . . . . . . . . 15
3.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 15 3.1. Support for MP2MP LSP setup with LDP . . . . . . . . . . . 15
3.2. The MP2MP downstream and upstream FEC Elements. . . . . . 16 3.2. The MP2MP downstream and upstream FEC Elements. . . . . . 16
3.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 16 3.3. Using the MP2MP FEC Elements . . . . . . . . . . . . . . . 16
3.3.1. MP2MP Label Map . . . . . . . . . . . . . . . . . . . 18 3.3.1. MP2MP Label Mapping . . . . . . . . . . . . . . . . . 18
3.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 21 3.3.2. MP2MP Label Withdraw . . . . . . . . . . . . . . . . . 21
3.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 22 3.3.3. MP2MP Upstream LSR change . . . . . . . . . . . . . . 22
4. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 22 4. Micro-loops in MP LSPs . . . . . . . . . . . . . . . . . . . . 22
5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 22 5. The LDP MP Status TLV . . . . . . . . . . . . . . . . . . . . 22
5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 23 5.1. The LDP MP Status Value Element . . . . . . . . . . . . . 23
5.2. LDP Messages containing LDP MP Status messages . . . . . . 24 5.2. LDP Messages containing LDP MP Status messages . . . . . . 24
5.2.1. LDP MP Status sent in LDP notification messages . . . 24 5.2.1. LDP MP Status sent in LDP notification messages . . . 24
5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 24 5.2.2. LDP MP Status TLV in Label Mapping Message . . . . . . 24
6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 25 6. Upstream label allocation on a LAN . . . . . . . . . . . . . . 25
6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 25 6.1. LDP Multipoint-to-Multipoint on a LAN . . . . . . . . . . 25
6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 25 6.1.1. MP2MP downstream forwarding . . . . . . . . . . . . . 26
6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 26 6.1.2. MP2MP upstream forwarding . . . . . . . . . . . . . . 26
7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 26 7. Root node redundancy . . . . . . . . . . . . . . . . . . . . . 26
7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 27 7.1. Root node redundancy - procedures for P2MP LSPs . . . . . 27
7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 27 7.2. Root node redundancy - procedures for MP2MP LSPs . . . . . 27
8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 28 8. Make Before Break (MBB) . . . . . . . . . . . . . . . . . . . 28
8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29 8.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 29
8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 30 8.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 30
8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30 8.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 30
8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30 8.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 30
8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31 8.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 31
8.4.3. Procedures for upstream LSR change . . . . . . . . . . 31 8.4.3. Procedures for upstream LSR change . . . . . . . . . . 31
8.4.4. Receiving a Label Map with MBB status code . . . . . . 32 8.4.4. Receiving a Label Mapping with MBB status code . . . . 32
8.4.5. Receiving a Notification with MBB status code . . . . 32 8.4.5. Receiving a Notification with MBB status code . . . . 32
8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 33 8.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 33
9. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 33 9. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 35 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . . 38 14.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
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
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 to a LDP neighbor 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.
skipping to change at page 6, line 32 skipping to change at page 6, line 32
Transit LSR: An LSR that has reachability to the root of the MP LSP Transit LSR: An LSR that has reachability to the root of the MP LSP
via a directly connected upstream LSR and one or more directly via a directly connected upstream LSR and one or more 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, a leaf is both Ingress and Egress for the same MP2MP LSP and
can also be a Bud LSR. can also be a Bud LSR.
CRC32: This contains a Cyclic Redundancy Check value of the
uncompressed data computed according to CRC-32 algorithm used in
the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T
recommendation V.42. (See http://www.iso.ch for ordering ISO
documents. See gopher://info.itu.ch for an online version of
ITU-T V.42.)
2. Setting up P2MP LSPs with LDP 2. Setting up P2MP LSPs with LDP
A P2MP LSP consists of a single root node, zero or more transit nodes A P2MP LSP consists of a single root node, zero or more transit nodes
and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and
tear-down. Leaf nodes also install forwarding state to deliver the tear-down. Leaf nodes also install forwarding state to deliver the
traffic received on a P2MP LSP to wherever it needs to go; how this traffic received on a P2MP LSP to wherever it needs to go; how this
is done is outside the scope of this document. Transit nodes install is done is outside the scope of this document. Transit nodes install
MPLS forwarding state and propagate the P2MP LSP setup (and tear- MPLS forwarding state and propagate the P2MP LSP setup (and tear-
down) toward the root. The root node installs forwarding state to down) toward the root. The root node installs forwarding state to
map traffic into the P2MP LSP; how the root node determines which map traffic into the P2MP LSP; how the root node determines which
skipping to change at page 7, line 15 skipping to change at page 7, line 22
procedures for Capability Parameters in Initialization Messages. 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 | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S: As specified in [RFC5561]
The P2MP Capability TLV MUST be supported in the LDP Initialization The P2MP Capability TLV MUST be supported in the LDP Initialization
Message. Advertisement of the P2MP Capability indicates support of Message. Advertisement of the P2MP Capability indicates support of
the procedures for P2MP LSP setup detailed in this document. If the the procedures for P2MP LSP setup detailed in this document. If the
peer has not advertised the corresponding capability, then label peer has not advertised the corresponding capability, then label
messages using the P2MP FEC Element SHOULD NOT be sent to the peer. messages using the P2MP FEC Element SHOULD NOT be sent to the peer.
2.2. The P2MP FEC Element 2.2. The P2MP FEC Element
For the setup of a P2MP LSP with LDP, we define one new protocol For the setup of a P2MP LSP with LDP, we define one new protocol
entity, the P2MP FEC Element to be used as a FEC Element in the FEC entity, the P2MP FEC Element to be used as a FEC Element in the FEC
TLV. Note that the P2MP FEC Element does not necessarily identify TLV. Note that the P2MP FEC Element does not necessarily identify
the traffic that must be mapped to the LSP, so from that point of the traffic that must be mapped to the LSP, so from that point of
view, the use of the term FEC is a misnomer. The description of the view, the use of the term FEC is a misnomer. The description of the
P2MP FEC Element follows. P2MP FEC Element follows.
The P2MP FEC Element consists of the address of the root of the P2MP The P2MP FEC Element consists of the address of the root of the P2MP
LSP and an opaque value. The opaque value consists of one or more LSP and an opaque value. The opaque value consists of one or more
LDP MP Opaque Value Elements. The opaque value is unique within the LDP MP Opaque Value Elements. The opaque value is unique within the
context of the root node. The combination of (Root Node Address, context of the root node. The combination of (Root Node Address
Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP
within the MPLS network.
The P2MP FEC Element is encoded as follows: The P2MP FEC Element is encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type (TBD)| Address Family | Address Length| |P2MP Type (TBD)| Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~ ~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 29 skipping to change at page 9, line 29
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type < 255 | Length | Value ... | | Type < 255 | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The Type of the LDP MP Opaque Value Element basic type is to Type: The Type of the LDP MP Opaque Value Element. IANA maintains a
be assigned by IANA. registry of basic types (see Section 11).
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by Value: String of Length octets, to be interpreted as specified by
the Type field. the Type field.
The LDP MP Opaque Value Element extended type is encoded as follows: The LDP MP Opaque Value Element extended type 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
skipping to change at page 10, line 22 skipping to change at page 10, line 22
| Length (low) | Value | | Length (low) | Value |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type = 255. Type: Type = 255.
Extended Type: The Extended Type of the LDP MP Opaque Value Element Extended Type: The Extended Type of the LDP MP Opaque Value Element.
extended type is to be assigned by IANA. IANA maintains a registry of extended types (see Section 11).
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by Value: String of Length octets, to be interpreted as specified by
the Type field. the Type field.
2.3.1. The Generic LSP Identifier 2.3.1. The Generic LSP Identifier
The generic LSP identifier is a type of Opaque Value Element basic The generic LSP identifier is a type of Opaque Value Element basic
type encoded as follows: type encoded as follows:
skipping to change at page 11, line 14 skipping to change at page 11, line 14
2.4. Using the P2MP FEC Element 2.4. Using the P2MP FEC Element
This section defines the rules for the processing and propagation of This section defines the rules for the processing and propagation of
the P2MP FEC Element. The following notation is used in the the P2MP FEC Element. The following notation is used in the
processing rules: processing rules:
1. P2MP FEC Element <X, Y>: a FEC Element with Root Node Address X 1. P2MP FEC Element <X, Y>: a FEC Element with Root Node Address X
and Opaque Value Y. and Opaque Value Y.
2. P2MP Label Map <X, Y, L>: a Label Map message with a FEC TLV with 2. P2MP Label Mapping <X, Y, L>: a Label Mapping message with a FEC
a single P2MP FEC Element <X, Y> and Label TLV with label L. TLV with a single P2MP FEC Element <X, Y> and Label TLV with
Label L MUST be allocated from the per-platform label space (see label L. Label L MUST be allocated from the per-platform label
[RFC3031] section 3.14) of the LSR sending the Label Map Message. space (see [RFC3031] section 3.14) of the LSR sending the Label
Mapping Message. The use of the interface label space is outside
the scope of this document.
3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a 3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a
FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with
label L. label L.
4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with Root Node 4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with Root Node
Address X and Opaque Value Y. Address X and Opaque Value Y.
5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X 5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X
means that on receiving a packet with label L', X makes n copies means that on receiving a packet with label L', X makes n copies
of the packet. For copy i of the packet, X swaps L' with Li and of the packet. For copy i of the packet, X swaps L' with Li and
sends it out over interface Ii. sends it out over interface Ii.
The procedures below are organized by the role which the node plays The procedures below are organized by the role which the node plays
in the P2MP LSP. Node Z knows that it is a leaf node by a discovery in the P2MP LSP. Node Z knows that it is a leaf node by a discovery
process which is outside the scope of this document. During the process which is outside the scope of this document. During the
course of protocol operation, the root node recognizes its role course of protocol operation, the root node recognizes its role
because it owns the Root Node Address. A transit node is any node because it owns the Root Node Address. A transit node is any node
(other than the root node) that receives a P2MP Label Map message (other than the root node) that receives a P2MP Label Mapping message
(i.e., one that has leaf nodes downstream of it). (i.e., one that has leaf nodes downstream of it).
Note that a transit node (and indeed the root node) may also be a Note that a transit node (and indeed the root node) may also be a
leaf node. leaf node.
2.4.1. Label Map 2.4.1. Label Mapping
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 Mapping messages and for processing received
label map messages for a particular LSP. The procedures for a P2MP Label Mapping messages for a particular LSP. The procedures for
particular LSR depend upon the role that LSR plays in the LSP a 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 [RFC5332] except All labels discussed here are downstream-assigned [RFC5332] except
those which are assigned using the procedures of Section 6. 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 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 MUST select
one upstream LSR. The algorithm used for the LSR selection is a 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 local matter. If the LSR selection is done over a LAN interface and
the Section 6 procedures are applied, the following procedure SHOULD the Section 6 procedures are applied, the following procedure SHOULD
be applied to ensure that the same upstream LSR is elected among a be applied to ensure that the same upstream LSR is elected among a
set of candidate receivers on that LAN. 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. The 'Opaque Value' is
the field identified in the FEC Element right after 'Opaque
Length'. The 'Opaque Length' indicates the size of the Opaque
Value used in this calculation.
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 procedure will ensure that there is a single forwarder over the This procedure will ensure that there is a single forwarder over the
LAN for a particular LSP. LAN for a particular LSP.
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 Mapping message from a downstream
D, specifying label L. Suppose further that U is connected to D over LSR D, specifying label L. Suppose further that U is connected to D
several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U over several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If
needs to transmit to D a data packet whose top label is L, U is free U needs to transmit to D a data packet whose top label is L, U is
to transmit the packet on any of those interfaces. The algorithm it free to transmit the packet on any of those interfaces. The
uses to choose a particular interface and next-hop for a particular algorithm it uses to choose a particular interface and next-hop for a
such packet is a local matter. For completeness the following particular such packet is a local matter. For completeness the
procedure MAY be used. LSR U may do a lookup in the unicast routing following procedure MAY be used. LSR U may do a lookup in the
table to find the best interface and next-hop to reach LSR D. If the unicast routing table to find the best interface and next-hop to
next-hop and interface are also advertised by LSR D via the LDP reach LSR D. If the next-hop and interface are also advertised by LSR
session it can be used to transmit the packet to LSR D. 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 Mapping <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 Mapping <X, Y, L> from
T. Z checks whether it already has state for <X, Y>. If not, Z LSR T. Z checks whether it already has state for <X, Y>. If not, Z
determines its upstream LSR U for <X, Y> as per Section 2.4.1.1. determines its upstream LSR U for <X, Y> as per Section 2.4.1.1.
Using this Label Map to update the label forwarding table MUST NOT be Using this Label Mapping to update the label forwarding table MUST
done as long as LSR T is equal to LSR U. If LSR U is different from NOT be done as long as LSR T is equal to LSR U. If LSR U is different
LSR T, Z will allocate a label L', and install state to swap L' with from LSR T, Z will allocate a label L', and install state to swap L'
L over interface I associated with LSR T and send a P2MP Label Map with L over interface I associated with LSR T and send a P2MP Label
<X, Y, L'> to LSR U. Interface I is determind via the procedures in Mapping <X, Y, L'> to LSR U. Interface I is determind via the
Section 2.4.1.2. procedures in Section 2.4.1.2.
If Z already has state for <X, Y>, then Z does not send a Label Map If Z already has state for <X, Y>, then Z does not send a Label
message for P2MP LSP <X, Y>. All that Z needs to do in this case is Mapping message for P2MP LSP <X, Y>. If LSR T is not equal to the
check that LSR T is not equal to the upstream LSR of <X, Y> and upstream LSR of <X, Y> and <I, L> does not already exist as
update its forwarding state. Assuming its old forwarding state was forwarding state, the forwarding state updated. Assuming its old
L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new
becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If the LSR T forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I,
is equal to the installed upstream LSR, the Label Map from LSR T MUST L>}. If the LSR T is equal to the installed upstream LSR, the Label
be retained and MUST NOT update the label forwarding table. Mapping from LSR T MUST be retained and MUST NOT update the label
forwarding table.
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 Mapping <X, Y, L> from
T. Z checks whether it already has forwarding state for <X, Y>. If LSR T. Z checks whether it already has forwarding state for <X, Y>.
not, Z creates forwarding state to push label L onto the traffic that If not, Z creates forwarding state to push label L onto the traffic
Z wants to forward over the P2MP LSP (how this traffic is determined that Z wants to forward over the P2MP LSP (how this traffic is
is outside the scope of this document). determined 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 determined 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 section lists procedures for generating and processing The following section lists procedures for generating and processing
P2MP Label Withdraw messages for nodes that participate in a P2MP P2MP Label Withdraw messages for nodes that participate in a P2MP
LSP. An LSR should apply those procedures that apply to it, based on LSP. An LSR should apply those procedures that apply to it, based on
its role in the P2MP LSP. its role in the P2MP LSP.
2.4.2.1. Leaf Operation 2.4.2.1. Leaf Operation
If a leaf node Z discovers (by means outside the scope of this If a leaf node Z discovers that it has no downstream neighbors in
document) that it has no downstream neighbors in that LSP, and that that LSP, and that it has no need to be an egress LSR for that LSP
it has no need to be an egress LSR for that LSP, then it SHOULD send (by means outside the scope of this document), then it SHOULD send a
a Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is
is the label it had previously advertised to U for <X, Y>. the label it had previously advertised to U for <X, Y>.
2.4.2.2. Transit Node Operation 2.4.2.2. Transit Node Operation
If a transit node Z receives a Label Withdraw message <X, Y, L> from If a transit node Z receives a Label Withdraw message <X, Y, L> from
a node W, it deletes label L from its forwarding state, and sends a a node W, it deletes label L from its forwarding state, and sends a
Label Release message with label L to W. Label Release message with label L to W.
If deleting L from Z's forwarding state for P2MP LSP <X, Y> results If deleting L from Z's forwarding state for P2MP LSP <X, Y> results
in no state remaining for <X, Y>, then Z propagates the Label in no state remaining for <X, Y>, then Z propagates the Label
Withdraw for <X, Y>, to its upstream T, by sending a Label Withdraw Withdraw for <X, Y>, to its upstream T, by sending a Label Withdraw
skipping to change at page 14, line 36 skipping to change at page 14, line 42
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. Z MUST the upstream LSR changes from U to U' as per Section 2.4.1.1. Z MUST
update its forwarding state as follows. It allocates a new label, update its forwarding state as follows. It allocates a new label,
L', for <X, Y>. The forwarding state for L' is copied from the L', for <X, Y>. The forwarding state for L' is copied from the
forwarding state for L, with one exception: if U' was present in the forwarding state for L, with one exception: if U' was present in the
forwarding state of L, it MUST NOT be installed in the forwarding forwarding state of L, it MUST NOT be installed in the forwarding
state of L'. Then the forwarding state for L is deleted and the state of L'. Then the forwarding state for L is deleted and the
forwarding state for L' is installed. In addition Z MUST send a forwarding state for L' is installed. In addition Z MUST send a
Label Map <X, Y, L'> to U' and send a Label Withdraw <X, Y, L> to U. Label Mapping <X, Y, L'> to U' and send a Label Withdraw <X, Y, L> to
Note, if there was a downstream mapping from U that was not installed U. Note, if there was a downstream mapping from U that was not
in the forwarding due to Section 2.4.1.4 it can now be installed. installed in the forwarding due to Section 2.4.1.4 it can now be
installed.
While changing the upstream LSR the following must be taken into While changing the upstream LSR the following must be taken into
consideration. If L' is added before L is removed, there is a consideration. If L' is added before L is removed, there is a
potential risk of packet duplication, and/or the creation of a potential risk of packet duplication, and/or the creation of a
transient dataplane forwarding loop. If L is removed before L' is transient dataplane forwarding loop. If L is removed before L' is
added, packet loss may result. Ideally the change from L to L' is added, packet loss may result. Ideally the change from L to L' is
done atomically such that no packet loss or duplication occurs. If done atomically such that no packet loss or duplication occurs. If
that is not possible, the RECOMMENDED default behavior is to remove L that is not possible, the RECOMMENDED default behavior is to remove L
before adding L'. before adding L'.
skipping to change at page 15, line 47 skipping to change at page 16, line 10
procedures for Capability Parameters in Initialization Messages. procedures for Capability Parameters in Initialization Messages.
A new Capability Parameter TLV is defined, the MP2MP Capability. A new Capability Parameter TLV is defined, the MP2MP Capability.
Following is the format of the MP2MP Capability Parameter. Following is the format of the MP2MP Capability Parameter.
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 | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S: As specified in [RFC5561]
The MP2MP Capability TLV MUST be supported in the LDP Initialization The MP2MP Capability TLV MUST be supported in the LDP Initialization
Message. Advertisement of the MP2MP Capability indicates support of Message. Advertisement of the MP2MP Capability indicates support of
the procedures for MP2MP LSP setup detailed in this document. If the the procedures for MP2MP LSP setup detailed in this document. If the
peer has not advertised the corresponding capability, then label peer has not advertised the corresponding capability, then label
messages using the MP2MP upstream and downstream FEC Elements SHOULD messages using the MP2MP upstream and downstream FEC Elements SHOULD
NOT be sent to the peer. NOT be sent to the peer.
3.2. The MP2MP downstream and upstream FEC Elements. 3.2. The MP2MP downstream and upstream FEC Elements.
For the setup of a MP2MP LSP with LDP we define 2 new protocol For the setup of a MP2MP LSP with LDP we define 2 new protocol
skipping to change at page 17, line 5 skipping to change at page 17, line 16
MP2MP LSP upstream path for downstream node D with root node MP2MP LSP upstream path for downstream node D with root node
address X and opaque value Y. address X and opaque value Y.
3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root 3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root
node address X and opaque value Y used for a downstream MP2MP node address X and opaque value Y used for a downstream MP2MP
LSP. LSP.
4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node 4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node
address X and opaque value Y used for an upstream MP2MP LSP. address X and opaque value Y used for an upstream MP2MP LSP.
5. MP2MP-D Label Map <X, Y, L>: A Label Map message with a FEC TLV 5. MP2MP-D Label Mapping <X, Y, L>: A Label Mapping message with a
with a single MP2MP downstream FEC Element <X, Y> and label TLV FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
with label L. Label L MUST be allocated from the per-platform label TLV with label L. Label L MUST be allocated from the per-
label space (see [RFC3031] section 3.14) of the LSR sending the platform label space (see [RFC3031] section 3.14) of the LSR
Label Map Message. sending the Label Mapping Message. The use of the interface
label space is outside the scope of this document.
6. MP2MP-U Label Map <X, Y, Lu>: A Label Map message with a FEC TLV 6. MP2MP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a
with a single MP2MP upstream FEC Element <X, Y> and label TLV FEC TLV with a single MP2MP upstream FEC Element <X, Y> and
with label Lu. Label Lu MUST be allocated from the per-platform label TLV with label Lu. Label Lu MUST be allocated from the
label space (see [RFC3031] section 3.14) of the LSR sending the per-platform label space (see [RFC3031] section 3.14) of the LSR
Label Map Message. sending the Label Mapping Message. The use of the interface
label space is outside the scope of this document.
7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with 7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with
a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and
label TLV with label L. label TLV with label L.
8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with 8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with
a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and
label TLV with label Lu. label TLV with label Lu.
9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a 9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a
skipping to change at page 17, line 38 skipping to change at page 18, line 10
10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a 10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a
FEC TLV with a single MP2MP upstream FEC Element <X, Y> and FEC TLV with a single MP2MP upstream FEC Element <X, Y> and
label TLV with label Lu. label TLV with label Lu.
The procedures below are organized by the role which the node plays The procedures below are organized by the role which the node plays
in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery
process which is outside the scope of this document. During the process which is outside the scope of this document. During the
course of the protocol operation, the root node recognizes its role course of the protocol operation, the root node recognizes its role
because it owns the root node address. A transit node is any node because it owns the root node address. A transit node is any node
(other then the root node) that receives a MP2MP Label Map message (other then the root node) that receives a MP2MP Label Mapping
(i.e., one that has leaf nodes downstream of it). message (i.e., one that has leaf nodes downstream of it).
Note that a transit node (and indeed the root node) may also be a Note that a transit node (and indeed the root node) may also be a
leaf node and the root node does not have to be an ingress LSR or leaf node and the root node does not have to be an ingress LSR or
leaf of the MP2MP LSP. leaf of the MP2MP LSP.
3.3.1. MP2MP Label Map 3.3.1. MP2MP Label Mapping
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 Mapping messages and for processing received
MP2MP label map messages for a particular LSP. The procedures for a MP2MP Label Mapping messages for a particular LSP. The procedures
particular LSR depend upon the role that LSR plays in the LSP for a 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 [RFC5332] except All labels discussed here are downstream-assigned [RFC5332] except
those which are assigned using the procedures of Section 6. those which are assigned using the procedures of Section 6.
3.3.1.1. Determining one's upstream MP2MP LSR 3.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.
3.3.1.2. Determining one's downstream MP2MP LSR 3.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 Mapping from a LDP peer D
will treat D as downstream MP2MP LSR. will treat D as downstream MP2MP LSR.
3.3.1.3. Installing the upstream path of a MP2MP LSP 3.3.1.3. Installing the upstream path of a MP2MP LSP
There are two methods for installing the upstream path of a MP2MP LSP There are two methods for installing the upstream path of a MP2MP LSP
to a downstream neighbor. to a downstream neighbor.
1. We can install the upstream MP2MP path (to a downstream neighbor) 1. We can install the upstream MP2MP path (to a downstream neighbor)
based on receiving a MP2MP-D Label Map from the downstream based on receiving a MP2MP-D Label Mapping from the downstream
neighbor. This will install the upstream path on a per hop by neighbor. This will install the upstream path on a per hop by
hop basis. hop basis.
2. We install the upstream MP2MP path (to a downstream neighbor) 2. We install the upstream MP2MP path (to a downstream neighbor)
based on receiving a MP2MP-U Label Map from the upstream based on receiving a MP2MP-U Label Mapping from the upstream
neighbor. An LSR does not need to wait for the MP2MP-U Label Map neighbor. An LSR does not need to wait for the MP2MP-U Label
if it is the root of the MP2MP LSP or already has received an Mapping if it is the root of the MP2MP LSP or already has
MP2MP-U Label Map from the upstream neighbor. We call this received an MP2MP-U Label Mapping from the upstream neighbor. We
method ordered mode. The typical result of this mode is that the call this method ordered mode. The typical result of this mode
downstream path of the MP2MP is built hop by hop towards the is that the downstream path of the MP2MP is built hop by hop
root. Once the root is reached, the root node will trigger a towards the root. Once the root is reached, the root node will
MP2MP-U Label Map to the downstream neighbor(s). trigger a MP2MP-U Label Mapping to the downstream neighbor(s).
For setting up the upstream path of a MP2MP LSP ordered mode MUST be For setting up the upstream path of a MP2MP LSP ordered mode MUST be
used. Due to ordered mode the upstream path of the MP2MP LSP is used. Due to ordered mode the upstream path of the MP2MP LSP is
installed at the leaf node once the path to the root is completed. installed at the leaf node once the path to the root is completed.
The advantage is that when a leaf starts sending immediately after The advantage is that when a leaf starts sending immediately after
the upstream path is installed, packets are able to reach the root the upstream path is installed, packets are able to reach the root
node without being dropped due to an incomplete LSP. Method 1 is not node without being dropped due to an incomplete LSP. Method 1 is not
able to guarantee that the upstream path is completed before the leaf able to guarantee that the upstream path is completed before the leaf
starts sending. starts sending.
3.3.1.4. MP2MP leaf node operation 3.3.1.4. MP2MP leaf node operation
A leaf node Z of a MP2MP LSP <X, Y> determines its upstream LSR U for A leaf node Z of a MP2MP LSP <X, Y> determines its upstream LSR U for
<X, Y> as per Section 3.3.1.1, allocates a label L, and sends a <X, Y> as per Section 3.3.1.1, allocates a label L, and sends a
MP2MP-D Label Map <X, Y, L> to U. MP2MP-D Label Mapping <X, Y, L> to U.
Leaf node Z expects an MP2MP-U Label Map <X, Y, Lu> from node U in Leaf node Z expects an MP2MP-U Label Mapping <X, Y, Lu> from node U
response to the MP2MP-D Label Map it sent to node U. Z checks whether in response to the MP2MP-D Label Mapping it sent to node U. Z checks
it already has forwarding state for upstream <X, Y>. If not, Z whether it already has forwarding state for upstream <X, Y>. If not,
creates forwarding state to push label Lu onto the traffic that Z 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.
3.3.1.5. MP2MP transit node operation 3.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 Mapping <X, Y, L> from LSR D.
checks whether it has forwarding state for downstream <X, Y>. If Z 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 3.3.1.1. Using this Label Map to update the label forwarding Section 3.3.1.1. Using this Label Mapping to update the label
table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U forwarding table MUST NOT be done as long as LSR D is equal to LSR U.
is different from LSR D, Z will allocate a label L' and install If LSR U is different from LSR D, Z will allocate a label L' and
downstream forwarding state to swap label L' with label L over install downstream forwarding state to swap label L' with label L
interface I associated with LSR D and send a MP2MP-D Label Map <X, Y, over interface I associated with LSR D and send a MP2MP-D Label
L'> to U. Interface I is determined via the procedures in Mapping <X, Y, L'> to U. Interface I is determined via the procedures
Section 2.4.1.2. in Section 2.4.1.2.
If Z already has forwarding state for downstream <X, Y>, all that Z If Z already has forwarding state for downstream <X, Y>, all that Z
needs to do in this case is check that LSR D is not equal to the needs to do in this case is check that LSR D is not equal to the
upstream LSR of <X, Y> and update its forwarding state. Assuming its upstream LSR of <X, Y> and update its forwarding state. Assuming its
old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its
new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>,
<I, L>}. If the LSR D is equal to the installed upstream LSR, the <I, L>}. If the LSR D is equal to the installed upstream LSR, the
Label Map from LSR D MUST be retained and MUST NOT update the label Label Mapping from LSR D MUST be retained and MUST NOT update the
forwarding table. label 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 3.3.1.3. Once the MP2MP-U Mapping <X, Y, Lu> from LSR U. See Section 3.3.1.3. Once the MP2MP-U
Label Map is received from LSR U, node Z checks whether it already Label Mapping is received from LSR U, node Z checks whether it
has forwarding state upstream <X, Y, D>. If it does, then no further already has forwarding state upstream <X, Y, D>. If it does, then no
action needs to happen. If it does not, it allocates a label Lu' and further action needs to happen. If it does not, it allocates a label
creates a new label swap for Lu' with Label Lu over interface Iu. Lu' and creates a new label swap for Lu' with Label Lu over interface
Interface Iu is determined via the procedures in Section 2.4.1.2. In Iu. Interface Iu is determined via the procedures in
addition, it also adds the label swap(s) from the forwarding state Section 2.4.1.2. In addition, it also adds the label swap(s) from
downstream <X, Y>, omitting the swap on interface I for node D. The the forwarding state downstream <X, Y>, omitting the swap on
swap on interface I for node D is omitted to prevent packet interface I for node D. The swap on interface I for node D is omitted
originated by D to be forwarded back to D. to prevent packet originated by D to be forwarded back to D.
Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2, Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2,
and sends a MP2MP-U Label Map <X, Y, Lu'> to node D. and sends a MP2MP-U Label Mapping <X, Y, Lu'> to node D.
3.3.1.6. MP2MP root node operation 3.3.1.6. MP2MP root node operation
3.3.1.6.1. Root node is also a leaf 3.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 Mapping <X, Y, L>
node D. Z checks whether it already has forwarding state downstream from node D. Z checks whether it already has forwarding state
<X, Y>. If not, Z creates forwarding state for downstream to push downstream <X, Y>. If not, Z creates forwarding state for downstream
label L on traffic that Z wants to forward down the MP2MP LSP. How to push label L on traffic that Z wants to forward down the MP2MP
it determines what traffic to forward on this MP2MP LSP is outside LSP. How it determines what traffic to forward on this MP2MP LSP is
the scope of this document. If Z already has forwarding state for outside the scope of this document. If Z already has forwarding
downstream <X, Y>, then Z will add the label push for L over state for downstream <X, Y>, then Z will add the label push for L
interface I to it. Interface I is determined via the procedures in over interface I to it. Interface I is determined via the procedures
Section 2.4.1.2. in Section 2.4.1.2.
Node Z checks if it has forwarding state for upstream <X, Y, D> If Node Z checks if it has forwarding state for upstream <X, Y, D> If
not, Z allocates a label Lu' and creates upstream forwarding state to not, Z allocates a label Lu' and creates upstream forwarding state to
swap Lu' with the label swap(s) from the forwarding state downstream swap Lu' with the label swap(s) from the forwarding state downstream
<X, Y>, except the swap 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 3.3.1.2, and sends a downstream MP2MP LSR as per section Section 3.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 Mapping <X, Y, Lu'> to node D. Since Z is the root of
tree Z will not send a MP2MP-D Label Map and will not receive a the tree Z will not send a MP2MP-D Label Mapping and will not receive
MP2MP-U Label Map. a MP2MP-U Label Mapping.
3.3.1.6.2. Root node is not a leaf 3.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 Mapping <X, Y, L>
node D. Z checks whether it already has forwarding state for from 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
determined 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 3.3.1.2, and sends a MP2MP-U Label Map <X, Y, Lu'> to it. Section 3.3.1.2, and sends a MP2MP-U Label Mapping <X, Y, Lu'> to it.
Since Z is the root of the tree Z will not send a MP2MP-D Label Map Since Z is the root of the tree Z will not send a MP2MP-D Label
and will not receive a MP2MP-U Label Map. Mapping and will not receive a MP2MP-U Label Mapping.
3.3.2. MP2MP Label Withdraw 3.3.2. MP2MP Label Withdraw
The following section lists procedures for generating and processing The following section lists procedures for generating and processing
MP2MP Label Withdraw messages for nodes that participate in a MP2MP MP2MP Label Withdraw messages for nodes that participate in a MP2MP
LSP. An LSR should apply those procedures that apply to it, based on LSP. An LSR should apply those procedures that apply to it, based on
its role in the MP2MP LSP. its role in the MP2MP LSP.
3.3.2.1. MP2MP leaf operation 3.3.2.1. MP2MP leaf operation
If a leaf node Z discovers (by means outside the scope of this If a leaf node Z discovers (by means outside the scope of this
document) that it has no downstream neighbors in that LSP, and that document) that it has no downstream neighbors in that LSP, and that
it has no need to be an egress LSR for that LSP, then it SHOULD send it has no need to be an egress LSR for that LSP (by means outside the
a MP2MP-D Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, scope of this document), then it SHOULD send a MP2MP-D Label Withdraw
where L is the label it had previously advertised to U for <X,Y>. <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it
Leaf node Z will also send a unsolicited label release <X, Y, Lu> to had previously advertised to U for <X,Y>. Leaf node Z will also send
U to indicate that the upstream path is no longer used and that Label a unsolicited label release <X, Y, Lu> to U to indicate that the
Lu can be removed. upstream path is no longer used and that Label Lu can be removed.
Leaf node Z expects the upstream router U to respond by sending a Leaf node Z expects the upstream router U to respond by sending a
downstream label release for L. downstream label release for L.
3.3.2.2. MP2MP transit node operation 3.3.2.2. MP2MP transit node operation
If a transit node Z receives a MP2MP-D Label Withdraw message <X, Y, If a transit node Z receives a MP2MP-D Label Withdraw message <X, Y,
L> from node D, it deletes label L from its forwarding state L> from node D, it deletes label L from its forwarding state
downstream <X, Y> and from all its upstream states for <X, Y>. Node downstream <X, Y> and from all its upstream states for <X, Y>. Node
Z sends a MP2MP-D Label Release message with label L to D. Since node Z sends a MP2MP-D Label Release message with label L to D. Since node
skipping to change at page 22, line 29 skipping to change at page 22, line 42
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 Label neighbor to be added as a downstream LDP neighbor into the Label
Forwarding Table (LFT) for the same FEC. Micro-loops that involve Forwarding Table (LFT) for the same FEC. Micro-loops that involve
more than 2 LSRs are not prevented. more than 2 LSRs are not prevented.
Micro-loops that involve more than 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 Mapping 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.
5. The LDP MP Status TLV 5. The LDP MP Status TLV
An LDP MP capable router MAY use an LDP MP Status TLV to indicate An LDP MP capable router MAY use an LDP MP Status TLV to indicate
additional status for a MP LSP to its remote peers. This includes additional status for a MP LSP to its remote peers. This includes
signaling to peers that are either upstream or downstream of the LDP signaling to peers that are either upstream or downstream of the LDP
MP capable router. The value of the LDP MP status TLV will remain MP capable router. The value of the LDP MP status TLV will remain
opaque to LDP and MAY encode one or more status elements. opaque to LDP and MAY encode one or more status elements.
skipping to change at page 23, line 32 skipping to change at page 23, line 34
Value: One or more LDP MP Status Value elements. Value: One or more LDP MP Status Value elements.
5.1. The LDP MP Status Value Element 5.1. The LDP MP Status Value Element
The LDP MP Status Value Element that is included in the LDP MP Status The LDP MP Status Value Element that is included in the LDP MP Status
TLV Value has the following encoding. TLV Value has the following encoding.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(TBD) | Length | Value ... | | Type | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the LDP MP Status Value Element is to be assigned Type: The type of the LDP MP Status Value Element. IANA maintains a
by IANA. registry of status value types (see Section 11).
Length: The length of the Value field, in octets. Length: The length of the Value field, in octets.
Value: String of Length octets, to be interpreted as specified by Value: String of Length octets, to be interpreted as specified by
the Type field. the Type field.
5.2. LDP Messages containing LDP MP Status messages 5.2. LDP Messages containing LDP MP Status messages
The LDP MP status message may appear either in a label mapping The LDP MP Status TLV may appear either in a Label Mapping message or
message or a LDP notification message. a LDP Notification message.
5.2.1. LDP MP Status sent in LDP notification messages 5.2.1. LDP MP Status sent in LDP notification messages
An LDP MP status TLV sent in a notification message must be An LDP MP status TLV sent in a notification message must be
accompanied with a Status TLV. The general format of the accompanied with a Status TLV, as described in [RFC5036]. The
Notification Message with an LDP MP status TLV is: general format of the Notification Message with an LDP MP status TLV
is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length | |0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV | | Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 4 skipping to change at page 26, line 9
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 we will use the same procedures as defined in
[I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is [I-D.ietf-mpls-ldp-upstream]. A label request for a LSP label is
sent to the upstream LSR. The label mapping that is received from sent to the upstream LSR. The Label Mapping that is received from
the upstream LSR contains the LSP label for the MP2MP FEC and the the upstream LSR contains the LSP label for the MP2MP FEC and the
upstream LSR context label. The MP2MP downstream path (corresponding upstream LSR context label. The MP2MP downstream path (corresponding
to the LSP label) will be installed in the context specific to the LSP label) will be installed in the context specific
forwarding table corresponding to the upstream LSR label. Packets forwarding table corresponding to the upstream LSR label. Packets
sent by the upstream router can be forwarded downstream using this sent by the upstream router can be forwarded downstream using this
forwarding state based on a two label lookup. 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
skipping to change at page 30, line 24 skipping to change at page 30, line 24
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 [RFC5561]. The LDP MP MBB the capability advertisement as defined in [RFC5561]. The LDP MP MBB
capability has the following format: capability has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP MBB Capability | Length = 1 | |1|0| LDP MP MBB Capability | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Note: LDP MP MBB Capability (Pending IANA assignment) Note: LDP MP MBB Capability (Pending IANA assignment)
S: As specified in [RFC5561]
If an LSR has not advertised that it is MBB capable, its LDP peers If an LSR has not advertised that it is MBB capable, its LDP peers
MUST NOT send it messages which include MBB parameters. If an LSR MUST NOT send it messages which include MBB parameters. If an LSR
receives a Label Mapping message with a MBB parameter from downstream receives a Label Mapping message with a MBB parameter from downstream
LSR-D and its upstream LSR-U has not advertised that it is MBB LSR-D and its upstream LSR-U has not advertised that it is MBB
capable, the LSR MUST send an MBB notification immediatly to LSR-U capable, the LSR MUST send an MBB notification immediatly to LSR-U
(see Section 8.4). If this happens an MBB MP LSP will not be (see Section 8.4). If this happens an MBB MP LSP will not be
established, but normal a MP LSP will be the result. established, but normal a MP LSP will be the result.
8.4. The MBB procedures 8.4. The MBB procedures
skipping to change at page 31, line 21 skipping to change at page 31, line 21
4. F(N, L): A Forwarding state that consists of downstream Neighbor 4. F(N, L): A Forwarding state that consists of downstream Neighbor
N and Label L. This LSR is sending label packets with label L to N and Label L. This LSR is sending label packets with label L to
neighbor N for a specific FEC. neighbor N for a specific FEC.
5. F'(N, L): A Forwarding state that has been marked for sending a 5. F'(N, L): A Forwarding state that has been marked for sending a
MBB Notification message to Neighbor N with Label L. MBB Notification message to Neighbor N with Label L.
6. MBB Notification <X, Y, L>: A LDP notification message with a MP 6. MBB Notification <X, Y, L>: A LDP notification message with a MP
LSP <X, Y>, Label L and MBB Status code 2. LSP <X, Y>, Label L and MBB Status code 2.
7. MBB Label Map <X, Y, L>: A P2MP Label Map or MP2MP Label Map 7. MBB Label Mapping <X, Y, L>: A P2MP Label Mapping or MP2MP Label
downstream with a FEC element <X, Y>, Label L and MBB Status code Mapping downstream with a FEC element <X, Y>, Label L and MBB
1. Status code 1.
8.4.2. Accepting elements 8.4.2. Accepting elements
An accepting element represents a specific label value L that has An accepting element represents a specific label value L that has
been advertised to a neighbor N for a MBB LSP <X, Y> and is a been advertised to a neighbor N for a MBB LSP <X, Y> and is a
candidate for accepting labels switched packets on. An LSR can have candidate for accepting labels switched packets on. An LSR can have
two accepting elements for a specific MBB LSP <X, Y> LSP, only one of two accepting elements for a specific MBB LSP <X, Y> LSP, only one of
them MUST be active. An active element is the element for which the them MUST be active. An active element is the element for which the
label value has been installed in the label forwarding database. An label value has been installed in the label forwarding database. An
inactive accepting element is created after a new upstream LSR is inactive accepting element is created after a new upstream LSR is
skipping to change at page 31, line 50 skipping to change at page 31, line 50
inactive accepting element MUST be replaced with an newer inactive inactive accepting element MUST be replaced with an newer inactive
element. If an accepting element is removed a Label Withdraw has to element. If an accepting element is removed a Label Withdraw has to
be send for label L to neighbor N for <X, Y>. be send for label L to neighbor N for <X, Y>.
8.4.3. Procedures for upstream LSR change 8.4.3. Procedures for upstream LSR change
Suppose a node Z has a MBB LSP <X, Y> with an active accepting Suppose a node Z has a MBB LSP <X, Y> with an active accepting
element A(N1, L1). Due to a routing change it detects a new best element A(N1, L1). Due to a routing change it detects a new best
path for root X and selects a new upstream LSR N2. Node Z allocates path for root X and selects a new upstream LSR N2. Node Z allocates
a new local label L2 and creates an inactive accepting element iA(N2, a new local label L2 and creates an inactive accepting element iA(N2,
L2). Node Z sends MBB Label Map <X, Y, L2>to N2 and waits for the L2). Node Z sends MBB Label Mapping <X, Y, L2>to N2 and waits for
new upstream LSR N2 to respond with a MBB Notification for <X, Y, the new upstream LSR N2 to respond with a MBB Notification for <X, Y,
L2>. During this transition phase there are two accepting elements, L2>. During this transition phase there are two accepting elements,
the element A(N1, L1) still accepting packets from N1 over label L1 the element A(N1, L1) still accepting packets from N1 over label L1
and the new inactive element iA(N2, L2). and the new inactive element iA(N2, L2).
While waiting for the MBB Notification from upstream LSR N2, it is While waiting for the MBB Notification from upstream LSR N2, it is
possible that another transition occurs due to a routing change. possible that another transition occurs due to a routing change.
Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) Suppose the new upstream LSR is N3. An inactive element iA(N3, L3)
is created and the old inactive element iA(N2, L2) MUST be removed. is created and the old inactive element iA(N2, L2) MUST be removed.
A label withdraw MUST be sent to N2 for <X, Y, L2&gt. The MBB A label withdraw MUST be sent to N2 for <X, Y, L2&gt. The MBB
Notification for <X, Y, L2> from N2 will be ignored because the Notification for <X, Y, L2> from N2 will be ignored because the
skipping to change at page 32, line 25 skipping to change at page 32, line 25
It is possible that the MBB Notification from upstream LSR is never It is possible that the MBB Notification from upstream LSR is never
received due to link or node failure. To prevent waiting received due to link or node failure. To prevent waiting
indefinitely for the MBB Notification a timeout SHOULD be applied. indefinitely for the MBB Notification a timeout SHOULD be applied.
As soon as the timer expires, the procedures in Section 8.4.5 are As soon as the timer expires, the procedures in Section 8.4.5 are
applied as if a MBB Notification was received for the inactive applied as if a MBB Notification was received for the inactive
element. If a downstream LSR detects that the old upstream LSR went element. If a downstream LSR detects that the old upstream LSR went
down while waiting for the MBB Notification from the new upstream down while waiting for the MBB Notification from the new upstream
LSR, the downstream LSR can immediately proceed without waiting for LSR, the downstream LSR can immediately proceed without waiting for
the timer to expire. the timer to expire.
8.4.4. Receiving a Label Map with MBB status code 8.4.4. Receiving a Label Mapping 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 Mapping <X, Y, L2> from N2. A new forwarding state F(N2, L2)
be added to the MP LSP if it did not already exist. If this MBB LSP will be added to the MP LSP if it did not already exist. If this MBB
has an active accepting element or node Z is the root of the MBB LSP LSP has an active accepting element or node Z is the root of the MBB
a MBB notification <X, Y, L2)> is sent to node N2. If node Z has an LSP a MBB notification <X, Y, L2)> is sent to node N2. If node Z has
inactive accepting element it marks the Forwarding state as <X, Y, an inactive accepting element it marks the Forwarding state as <X, Y,
F'(N2, L2)>. If router Z upstream LSR for <X, Y> happens to be N2, 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 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> MBB notification to N2 must be done only after Z upstream for <X, Y>
stops being N2. stops being N2.
8.4.5. Receiving a Notification with MBB status code 8.4.5. Receiving a Notification with MBB status code
Suppose node Z receives a MBB Notification <X, Y, L> from N. If node Suppose node Z receives a MBB Notification <X, Y, L> from N. If node
Z has state for MBB LSP <X, Y> and an inactive accepting element Z has state for MBB LSP <X, Y> and an inactive accepting element
iA(N, L) that matches with N and L, we activate this accepting iA(N, L) that matches with N and L, we activate this accepting
skipping to change at page 33, line 23 skipping to change at page 33, line 23
element, the upstream path is installed when this inactive accepting element, the upstream path is installed when this inactive accepting
element is activated. element is activated.
9. Typed Wildcard for mLDP FEC Element 9. Typed Wildcard for mLDP FEC Element
The format of the mLDP FEC Typed Wildcard FEC is as follows: The format of the mLDP FEC Typed Wildcard FEC is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type = mLDP | Len = 2 | AFI ~ | Typed Wcard | Type | Len = 2 | AFI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type Wcard: As specified in [RFC5918] Type Wcard: As specified in [RFC5918]
Type: mLDP FEC Element Type as documented in this draft. Type: The type of FEC Element Type. Either the P2MP FEC Element or
the MP2MP FEC Element using the values defined for those FEC
Elements when carried in the FEC TLV as defined in this document.
Len: Len FEC Type Info, two octets (=0x02). Len: Len FEC Type Info, two octets (=0x02).
AFI: Address Family, two octet quantity containing a value from AFI: Address Family, two octet quantity containing a value from
IANA's "Address Family Numbers" registry. IANA's "Address Family Numbers" registry.
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 [RFC5036]. specification, as described in [RFC5036].
The protocol specified in this document does not provide any
authorization mechanism for controlling the set of LSRs that may join
a given MP LSP. If such authorization is desirable, additional
mechanisms, outside the scope of this document, are needed. Note
that authorization policies cannot be implemented and/or configure
solely at the root node of the LSP, because the root node does not
learn the identities of all the leaf nodes.
11. IANA Considerations 11. IANA Considerations
This document creates three new registries to be managed by IANA. This document creates three new registries to be managed by IANA.
1. "LDP MP Opaque Value Element basic type" 1. "LDP MP Opaque Value Element basic type"
The range is 0-255, with the following values allocated in this The range is 0-255, with the following values allocated in this
document: document:
1: Generic LSP identifier 1: Generic LSP identifier
skipping to change at page 34, line 35 skipping to change at page 34, line 43
3. "LDP MP Status Value Element type" 3. "LDP MP Status Value Element type"
The range is 0-255, with the following value allocated in this The range is 0-255, with the following value allocated in this
document: document:
1: MBB Status 1: MBB Status
The allocation policy for this space is 'Standards Action with The allocation policy for this space is 'Standards Action with
Early Allocation' Early Allocation'
The requested code point values listed below have been allocated by
IANA through early allocation.
This document requires allocation of three new code points from the This document requires allocation of three new code points from the
IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type
Name Space". The values are: Name Space". The values are:
P2MP FEC type - requested value 0x06 P2MP FEC type - requested value 0x06
MP2MP-up FEC type - requested value 0x07 MP2MP-up FEC type - requested value 0x07
MP2MP-down FEC type - requested value 0x08 MP2MP-down FEC type - requested value 0x08
skipping to change at page 38, line 7 skipping to change at page 38, line 19
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, August 2010. (FEC)", RFC 5918, August 2010.
14.2. Informative References 14.2. Informative References
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[I-D.ietf-mpls-mp-ldp-reqs] [I-D.ietf-mpls-mp-ldp-reqs]
Morin, T., "Requirements for Point-To-Multipoint Morin, T., "Requirements for Point-To-Multipoint
Extensions to the Label Distribution Protocol", Extensions to the Label Distribution Protocol",
draft-ietf-mpls-mp-ldp-reqs-06 (work in progress), draft-ietf-mpls-mp-ldp-reqs-06 (work in progress),
December 2010. December 2010.
[I-D.ietf-l3vpn-2547bis-mcast] [I-D.ietf-l3vpn-2547bis-mcast]
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work
in progress), January 2010. in progress), January 2010.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[ITU.V42.1994]
International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 1994.
Authors' Addresses Authors' Addresses
Ina Minei (editor) Ina Minei (editor)
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 39, line 4 skipping to change at page 39, line 22
Email: ina@juniper.net Email: ina@juniper.net
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti@juniper.net Email: kireeti@juniper.net
Bob Thomas Bob Thomas
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
 End of changes. 79 change blocks. 
192 lines changed or deleted 230 lines changed or added

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