draft-ietf-mpls-ldp-p2mp-14.txt   draft-ietf-mpls-ldp-p2mp-15.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: December 18, 2011 Cisco Systems, Inc. Expires: February 5, 2012 Cisco Systems, Inc.
K. Kompella K. Kompella
Juniper Networks Juniper Networks
B. Thomas B. Thomas
June 16, 2011 August 4, 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-14 draft-ietf-mpls-ldp-p2mp-15
Abstract Abstract
This document describes extensions to the Label Distribution Protocol This document describes extensions to the Label Distribution Protocol
for the setup of Point-to-Multipoint and Multipoint-to-Multipoint for the setup of Point-to-Multipoint and Multipoint-to-Multipoint
Label Switched Paths in Multi-Protocol Label Switching networks. Label Switched Paths in Multi-Protocol Label Switching networks.
These extensions are also referred to as Multipoint LDP. Multipoint These extensions are also referred to as Multipoint LDP. Multipoint
LDP constructs the P2MP or MP2MP Label Switched Paths without LDP constructs the P2MP or MP2MP Label Switched Paths 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
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 December 18, 2011. This Internet-Draft will expire on February 5, 2012.
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 6, line 8 skipping to change at page 6, line 8
mLDP: Multipoint extensions for LDP. mLDP: Multipoint extensions for LDP.
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 with a distinguished root node that connects a set
sent by any node in the LSP is delivered to all others. of nodes, such that traffic sent by any node in the LSP is
delivered to all others.
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
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
skipping to change at page 6, line 36 skipping to change at page 6, line 37
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, a leaf 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 CRC32: This contains a Cyclic Redundancy Check value of the
uncompressed data computed according to CRC-32 algorithm used in uncompressed data in network byte order computed according to
the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T CRC-32 algorithm used in the ISO 3309 standard and in section
recommendation V.42. (See http://www.iso.ch for ordering ISO 8.1.1.6.2 of ITU-T recommendation V.42.
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
skipping to change at page 7, line 27 skipping to change at page 7, line 26
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S: As specified in [RFC5561] S: As specified in [RFC5561]
The P2MP Capability TLV MUST be supported in the LDP Initialization The P2MP Capability TLV MUST be advertised 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
skipping to change at page 16, line 15 skipping to change at page 16, line 15
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S: As specified in [RFC5561] S: As specified in [RFC5561]
The MP2MP Capability TLV MUST be supported in the LDP Initialization The MP2MP Capability TLV MUST be advertised 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
entities, the MP2MP downstream FEC and upstream FEC Element. Both entities, the MP2MP downstream FEC and upstream FEC Element. Both
skipping to change at page 19, line 10 skipping to change at page 19, line 10
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 Mapping 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 neighbor. An LSR does not need to wait for the MP2MP-U Label
Mapping if it is the root of the MP2MP LSP or already has Mapping if it is the root of the MP2MP LSP or already has
received an MP2MP-U Label Mapping from the upstream neighbor. We received an MP2MP-U Label Mapping from the upstream neighbor. We
call this method ordered mode. The typical result of this mode call this method ordered mode. The typical result of this mode
is that the downstream path of the MP2MP is built hop by hop is that the downstream path of the MP2MP is built hop by hop
towards the root. Once the root is reached, the root node will towards the root. Once the root is reached, the root node will
trigger a MP2MP-U Label Mapping 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 SHOULD
used. Due to ordered mode the upstream path of the MP2MP LSP is be 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
skipping to change at page 22, line 40 skipping to change at page 22, line 40
also result in a micro-loop in the MP LSPs. Micro-loops that involve also result in a micro-loop in the MP LSPs. Micro-loops that involve
2 directly connected routers don't create a loop in mLDP. mLDP is 2 directly connected routers don't create a loop in mLDP. mLDP is
able to prevent this inconsistency by never allowing an upstream LDP able to prevent this inconsistency by never allowing an upstream LDP
neighbor to be added as a downstream LDP neighbor into the 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 and mLDP
loops that occur in the upstream path of a MP2MP LSP may be detected has updated the forwarding state accordingly. Micro-loops that occur
by including LDP path vector in the MP2MP-U Label Mapping messages. in the upstream path of a MP2MP LSP may be detected by including LDP
These procedures are currently under investigation and are subjected path vector in the MP2MP-U Label Mapping messages. These procedures
to further study. are currently under investigation and are subjected 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.
The LDP MP Status TLV is encoded as follows: The LDP MP Status TLV is encoded as follows:
skipping to change at page 38, line 17 skipping to change at page 38, line 17
for LDP", draft-ietf-mpls-ldp-upstream-10 (work in for LDP", draft-ietf-mpls-ldp-upstream-10 (work in
progress), February 2011. progress), February 2011.
[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.
[ITU.V42.1994]
International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 1994.
http://www.itu.int/rec/T-REC-V.42-200203-I
14.2. Informative References 14.2. Informative References
[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",
skipping to change at page 38, line 39 skipping to change at page 39, line 5
[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
 End of changes. 12 change blocks. 
25 lines changed or deleted 25 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/