--- 1/draft-ietf-mpls-ldp-p2mp-09.txt 2010-07-11 09:12:29.000000000 +0200 +++ 2/draft-ietf-mpls-ldp-p2mp-10.txt 2010-07-11 09:12:29.000000000 +0200 @@ -1,22 +1,22 @@ Network Working Group I. Minei (Editor) Internet-Draft K. Kompella Intended status: Standards Track Juniper Networks -Expires: November 1, 2010 I. Wijnands (Editor) +Expires: January 12, 2011 I. Wijnands (Editor) B. Thomas Cisco Systems, Inc. - April 30, 2010 + July 11, 2010 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths - draft-ietf-mpls-ldp-p2mp-09 + draft-ietf-mpls-ldp-p2mp-10 Abstract This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. These extensions are also referred to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this @@ -40,21 +40,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -115,27 +115,28 @@ 9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28 9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28 9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29 9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29 9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30 9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30 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.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 - 13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 - 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 + 10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 + 14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 35 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction The LDP protocol is described in [RFC5036]. It defines mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document describes extensions to LDP for setting up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs. These are collectively referred to as multipoint LSPs (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) @@ -402,22 +403,22 @@ 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 "Upstream LSR" for . When there are several candidate upstream LSRs, the LSR MAY select one upstream LSR using the following procedure: 1. The candidate upstream LSRs are numbered from lower to higher IP address - 2. The following hash is performed: H = (Sum Opaque value) modulo N, - where N is the number of candidate upstream LSRs + 2. The following hash is performed: H = (CRC32(Opaque value)) modulo + N, where N is the number of upstream LSRs. 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 candidate upstream LSRs, while ensuring that on a LAN interface a single upstream LSR is selected. 2.4.1.2. Determining the forwarding interface to an LSR Suppose LSR U receives a MP Label Map message from a downstream LSR @@ -1384,26 +1385,47 @@ The procedures described above apply to the downstream path of a 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 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 active accepting element. If node N is part of an inactive accepting element, the upstream path is installed when this inactive accepting 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 specification, as described in [RFC5036]. -11. IANA considerations +12. IANA considerations 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 the value 1 for the type of Generic LSP Identifier. This document requires allocation of three new LDP FEC Element types: 1. the P2MP FEC type - requested value 0x06 2. the MP2MP-up FEC type - requested value 0x07 @@ -1429,39 +1451,41 @@ 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: LDP MP Status TLV Type - requested value 0x096F 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 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 review and contribution: Nischal Sheth, Yakov Rekhter, Rahul Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas Morin. -13. Contributing authors +14. Contributing authors Below is a list of the contributing authors in alphabetical order: Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 US Email: Shane.Amante@Level3.com - Luyuan Fang Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US Email: lufang@cisco.com Hitoshi Fukuda NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku @@ -1510,22 +1534,23 @@ Norway Email: lei.wang@telenor.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium E-mail: ice@cisco.com -14. References -14.1. Normative References +15. References + +15.1. Normative References [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. @@ -1541,21 +1566,27 @@ [I-D.ietf-mpls-ldp-upstream] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for LDP", draft-ietf-mpls-ldp-upstream-02 (work in progress), November 2007. [I-D.ietf-mpls-ldp-capabilities] Thomas, B., "LDP Capabilities", draft-ietf-mpls-ldp-capabilities-02 (work in progress), 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 Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [I-D.ietf-mpls-mp-ldp-reqs]