draft-ietf-mpls-ldp-p2mp-09.txt   draft-ietf-mpls-ldp-p2mp-10.txt 
Network Working Group I. Minei (Editor) Network Working Group I. Minei (Editor)
Internet-Draft K. Kompella Internet-Draft K. Kompella
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: November 1, 2010 I. Wijnands (Editor) Expires: January 12, 2011 I. Wijnands (Editor)
B. Thomas B. Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
April 30, 2010 July 11, 2010
Label Distribution Protocol Extensions for Point-to-Multipoint and Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-ldp-p2mp-09 draft-ietf-mpls-ldp-p2mp-10
Abstract Abstract
This document describes extensions to the Label Distribution Protocol This document describes extensions to the Label Distribution Protocol
(LDP) for the setup of point to multi-point (P2MP) and multipoint-to- (LDP) for the setup of point to multi-point (P2MP) and multipoint-to-
multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol
Label Switching (MPLS) networks. These extensions are also referred Label Switching (MPLS) networks. These extensions are also referred
to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs
without interacting with or relying upon any other multicast tree without interacting with or relying upon any other multicast tree
construction protocol. Protocol elements and procedures for this construction protocol. Protocol elements and procedures for this
skipping to change at page 2, line 5 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 1, 2010. This Internet-Draft will expire on January 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 51 skipping to change at page 3, line 51
9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28
9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28
9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29
9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29
9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30
9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30
9.4.4. Receiving a Label Map with MBB status code . . . . . . 31 9.4.4. Receiving a Label Map with MBB status code . . . . . . 31
9.4.5. Receiving a Notification with MBB status code . . . . 31 9.4.5. Receiving a Notification with MBB status code . . . . 31
9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 35 15.1. Normative References . . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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)
skipping to change at page 11, line 32 skipping to change at page 11, line 32
next-hop on the best path from Z to the root node X. If there is more next-hop on the best path from Z to the root node X. If there is more
than one such LDP peer, only one of them is picked. U is Z's than one such LDP peer, only one of them is picked. U is Z's
"Upstream LSR" for <X, Y>. "Upstream LSR" for <X, Y>.
When there are several candidate upstream LSRs, the LSR MAY select When there are several candidate upstream LSRs, the LSR MAY select
one upstream LSR using the following procedure: one upstream LSR using the following procedure:
1. The candidate upstream LSRs are numbered from lower to higher IP 1. The candidate upstream LSRs are numbered from lower to higher IP
address address
2. The following hash is performed: H = (Sum Opaque value) modulo N, 2. The following hash is performed: H = (CRC32(Opaque value)) modulo
where N is the number of candidate upstream LSRs N, where N is the number of upstream LSRs.
3. The selected upstream LSR U is the LSR that has the number H. 3. The selected upstream LSR U is the LSR that has the number H.
This allows for load balancing of a set of LSPs among a set of This allows for load balancing of a set of LSPs among a set of
candidate upstream LSRs, while ensuring that on a LAN interface a candidate upstream LSRs, while ensuring that on a LAN interface a
single upstream LSR is selected. single upstream LSR is selected.
2.4.1.2. Determining the forwarding interface to an LSR 2.4.1.2. Determining the forwarding interface to an LSR
Suppose LSR U receives a MP Label Map message from a downstream LSR Suppose LSR U receives a MP Label Map message from a downstream LSR
skipping to change at page 33, line 5 skipping to change at page 33, line 5
The procedures described above apply to the downstream path of a The procedures described above apply to the downstream path of a
MP2MP LSP. The upstream path of the MP2MP is setup as normal without MP2MP LSP. The upstream path of the MP2MP is setup as normal without
including a MBB Status code. If the MBB procedures apply to a MP2MP including a MBB Status code. If the MBB procedures apply to a MP2MP
downstream FEC element, the upstream path to a node N is only downstream FEC element, the upstream path to a node N is only
installed in the label forwarding database if node N is part of the installed in the label forwarding database if node N is part of the
active accepting element. If node N is part of an inactive accepting active accepting element. If node N is part of an inactive accepting
element, the upstream path is installed when this inactive accepting element, the upstream path is installed when this inactive accepting
element is activated. element is activated.
10. Security Considerations 10. Typed Wildcard for mLDP FEC Element
The format of the mLDP FEC Typed Wildcard FEC is as follows:
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type = mLDP | Len = 2 | AFI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
Type Wcard: As specified in [I-D.ietf-mpls-ldp-typed-wildcard]
Type: mLDP FEC Element Type as documented in this draft.
Len: Len FEC Type Info, two octets (=0x02).
AFI: Address Family, two octet quantity containing a value from
ADDRESS FAMILY NUMBERS in [IANA-AF].
11. 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].
11. IANA considerations 12. IANA considerations
This document creates a new name space (the LDP MP Opaque Value This document creates a new name space (the LDP MP Opaque Value
Element type) that is to be managed by IANA, and the allocation of Element type) that is to be managed by IANA, and the allocation of
the value 1 for the type of Generic LSP Identifier. the value 1 for the type of Generic LSP Identifier.
This document requires allocation of three new LDP FEC Element types: This document requires allocation of three new LDP FEC Element types:
1. the P2MP FEC type - requested value 0x06 1. the P2MP FEC type - requested value 0x06
2. the MP2MP-up FEC type - requested value 0x07 2. the MP2MP-up FEC type - requested value 0x07
skipping to change at page 34, line 5 skipping to change at page 34, line 28
This document requires the assigment of a new code point for a LDP MP This document requires the assigment of a new code point for a LDP MP
Status TLV. The value requested from the LDP TLV Type Name Space: Status TLV. The value requested from the LDP TLV Type Name Space:
LDP MP Status TLV Type - requested value 0x096F LDP MP Status TLV Type - requested value 0x096F
This document creates a new name space (the LDP MP Status Value This document creates a new name space (the LDP MP Status Value
Element type) that is to be managed by IANA, and the allocation of Element type) that is to be managed by IANA, and the allocation of
the value 1 for the type of MBB Status. the value 1 for the type of MBB Status.
12. Acknowledgments This document creates a new name space (the LDP MP Opaque Value
Element type) that is to be managed by IANA.
13. Acknowledgments
The authors would like to thank the following individuals for their The authors would like to thank the following individuals for their
review and contribution: Nischal Sheth, Yakov Rekhter, Rahul review and contribution: Nischal Sheth, Yakov Rekhter, Rahul
Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert,
George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas
Morin. Morin.
13. Contributing authors 14. Contributing authors
Below is a list of the contributing authors in alphabetical order: Below is a list of the contributing authors in alphabetical order:
Shane Amante Shane Amante
Level 3 Communications, LLC Level 3 Communications, LLC
1025 Eldorado Blvd 1025 Eldorado Blvd
Broomfield, CO 80021 Broomfield, CO 80021
US US
Email: Shane.Amante@Level3.com Email: Shane.Amante@Level3.com
Luyuan Fang Luyuan Fang
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
US US
Email: lufang@cisco.com Email: lufang@cisco.com
Hitoshi Fukuda Hitoshi Fukuda
NTT Communications Corporation NTT Communications Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku 1-1-6, Uchisaiwai-cho, Chiyoda-ku
skipping to change at page 35, line 45 skipping to change at page 36, line 24
Norway Norway
Email: lei.wang@telenor.com Email: lei.wang@telenor.com
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
1831 Diegem 1831 Diegem
Belgium Belgium
E-mail: ice@cisco.com E-mail: ice@cisco.com
14. References 15. References
14.1. Normative References
15.1. Normative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
skipping to change at page 36, line 34 skipping to change at page 37, line 11
[I-D.ietf-mpls-ldp-upstream] [I-D.ietf-mpls-ldp-upstream]
Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment
for LDP", draft-ietf-mpls-ldp-upstream-02 (work in for LDP", draft-ietf-mpls-ldp-upstream-02 (work in
progress), November 2007. progress), November 2007.
[I-D.ietf-mpls-ldp-capabilities] [I-D.ietf-mpls-ldp-capabilities]
Thomas, B., "LDP Capabilities", Thomas, B., "LDP Capabilities",
draft-ietf-mpls-ldp-capabilities-02 (work in progress), draft-ietf-mpls-ldp-capabilities-02 (work in progress),
March 2008. March 2008.
14.2. Informative References [I-D.ietf-mpls-ldp-typed-wildcard]
Minei, I., Thomas, B., and R. Asati, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", draft-ietf-mpls-ldp-typed-wildcard-07 (work in
progress), March 2010.
15.2. Informative References
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[I-D.ietf-mpls-mp-ldp-reqs] [I-D.ietf-mpls-mp-ldp-reqs]
 End of changes. 13 change blocks. 
21 lines changed or deleted 52 lines changed or added

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