--- 1/draft-ietf-lisp-multicast-05.txt 2011-06-20 23:16:45.000000000 +0200 +++ 2/draft-ietf-lisp-multicast-06.txt 2011-06-20 23:16:45.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel -Expires: October 7, 2011 S. Venaas +Expires: December 22, 2011 S. Venaas cisco Systems - April 5, 2011 + June 20, 2011 LISP for Multicast Environments - draft-ietf-lisp-multicast-05 + draft-ietf-lisp-multicast-06 Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the @@ -29,21 +29,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 October 7, 2011. + This Internet-Draft will expire on December 22, 2011. Copyright Notice Copyright (c) 2011 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 @@ -60,47 +60,47 @@ 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Source Addresses versus Group Addresses . . . . . . . . . . . 13 6. Locator Reachability Implications on LISP-Multicast . . . . . 14 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18 - 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 18 + 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25 9.3. Making a Multicast Interworking Decision . . . . . . . . . 27 10. Considerations when RP Addresses are Embedded in Group Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 - A.1. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 - A.2. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 - A.3. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 - A.4. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 35 - A.5. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 - A.6. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 - + A.1. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35 + A.2. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 + A.3. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 + A.4. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 + A.5. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36 + A.6. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 + A.7. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction @@ -284,23 +284,23 @@ uLISP Site: a unicast only LISP site according to [LISP] which has not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. - It is likely an uPITR and a mPETR will be co-loacted since the - single device advertises a coarse EID-prefix in the underlying - unicast routing system. + It is likely an uPITR [INTWORK] and a mPETR will be co-located + since the single device advertises a coarse EID-prefix in the + underlying unicast routing system. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces @@ -313,21 +313,23 @@ by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the traffic engineering features of LISP, a multicast source site can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we - have for unicast. + have for unicast. However, when traffic engineering policies are + different for unicast versus multicast flows, it will be desirable to + use multicast-based priority and weight values in Map-Reply messages. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in another LISP multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. @@ -665,20 +667,31 @@ Note when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs. + When different (S-EID,G) traffic is combined into a single (RLOC,G) + core distribution tree, this may cause traffic to go to a receiver + multicast site when it does not need to. This happens when one + receiver multicast site joins (S1-EID,Gi) through a core distribution + tree of (RLOC1,Gi) and another multicast receiver site joins (S2- + EID,Gi) through the same core distribution tree of (RLOC1,Gi). When + ETRs decapsulate such traffic, they should know from their local + (S-EID,G) state if the packet should be forwarded. If there is no + (S-EID,G) state that matches the inner packet header, the packet is + discarded. + 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this @@ -789,21 +802,21 @@ LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non- LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot - be the same as an RLOC for the site. Because we want the ITRs to + be the same as an RLOC for the site because we want the ITRs to process a received PIM Join/Prune message from an external-facing interface to be propagated inside of the site so the site-part of the distribution tree is built. Using a globally routable source address allows non-LISP and uLISP multicast receiver to join, create, and maintain a multicast distribution tree. However, the LISP multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find a (S-RLOC,G) entry to Join in the core. So @@ -823,41 +836,41 @@ Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way packet forwarding model is performed can be explained. Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) - that its site's EIDs are not routable, it assumes that the multicast - packets from the source host are sent by a routable address. That - is, it is the responsibility of the multicast source host's system - administrator to ensure that the source host sends multicast traffic - using a routable source address. When this happens, the ITR acts - simply as a router and forwards the multicast packet like an ordinary - multicast router. + that its site's EIDs are not routable (and not registered to the + mapping database system), it assumes that the multicast packets from + the source host are sent by a routable address. That is, it is the + responsibility of the multicast source host's system administrator to + ensure that the source host sends multicast traffic using a routable + source address. When this happens, the ITR acts simply as a router + and forwards the multicast packet like an ordinary multicast router. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) which make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a - "Proxy ITR", or an uPITR). + "Proxy ITR", or an uPITR [INTWORK]). The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites @@ -896,22 +909,22 @@ For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy- ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non- LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a - distribution tree to the mPITR as well as for sending unicast oins to - mPITRs so they can propogate (S-EID,G) joins into source multicast + distribution tree to the mPITR as well as for sending unicast joins + to mPITRs so they can propogate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is work in progress. 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for @@ -1044,21 +1057,21 @@ common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- based policy modification is prohibited. When a receiver multicast site ETR receives a (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID. o A mixed multicast locator-set with the best multicast priority - values MUST not be configured on multicast ITRs. A mixed locator- + values MUST NOT be configured on multicast ITRs. A mixed locator- set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of @@ -1066,24 +1079,24 @@ concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. The trade-off decisions are hard to make and we want the same single solution to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. - Therefore the design decision to go with uPITRs for unicast routing - and mPETRs for multicast routing seems to be the sweet spot in the - solution space so we can optimize state requirements and avoid head- - end data replication at ITRs. + Therefore the design decision to go with uPITRs [INTWORK] for unicast + routing and mPETRs for multicast routing seems to be the sweet spot + in the solution space so we can optimize state requirements and avoid + head-end data replication at ITRs. 10. Considerations when RP Addresses are Embedded in Group Addresses When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in a IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace, need to extract an RP address from the RLOC namespace. @@ -1106,22 +1119,22 @@ If the core routers are upgraded to support [RPFV] and [RFC5496], then we can pass EID specific data through the core without, possibly, having to store the state in the core. By doing this we can eliminate the ETR from unicast encapsulating PIM Join/Prune messages to the source site's ITR. However, this solution is restricted to a small set of workable cases which would not be good for general use of LISP-Multicast. In - addition to slow convergence properties, it is not being recommended - for LISP-Multicast. + addition due to slow convergence properties, it is not being + recommended for LISP-Multicast. 12. Mtrace Considerations Mtrace functionality must be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible. The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon the mtrace version 2 specified in [MTRACE]. @@ -1136,33 +1149,37 @@ contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at Summer 2008 Dublin IETF were Toerless Eckert and Ijsbrand Wijnands. We would also like to thank the MBONED working group for constructive and civil verbal feedback when this draft was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, - Ron Bonica, and Lenny Guardino. + Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango. An expert review of this specification was done by Yiqun Cai and Liming Wei. We thank them for their detailed comments. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [MLISP] was converted into this IETF LISP working group draft. 15. References 15.1. Normative References + [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, + "Locator/ID Separation Protocol (LISP)", + draft-ietf-lisp-13.txt (work in progress), June 2011. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. @@ -1189,26 +1206,22 @@ [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 15.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in progress), March 2011. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP - with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt - (work in progress), March 2010. - - [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, - "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-12.txt (work in progress), April 2011. + with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt + (work in progress), March 2011. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress), November 2008. [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a Network Address (and port) Translator (NAT)", draft-ietf-behave-multicast-07.txt (work in progress), June 2007. @@ -1217,33 +1230,47 @@ Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-03.txt (work in progress), March 2009. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), February 2008. Appendix A. Document Change Log -A.1. Changes to draft-ietf-lisp-multicast-05.txt +A.1. Changes to draft-ietf-lisp-multicast-06.txt + + o Posted June 2011 to complete working group last call. + + o Added paragraph to section 8.1.2 based on Jesus comment about + making it more clear what happens when two (S-EID,G) trees use the + same (RLOC,G) tree. + + o Make more references to [INTWORK] when mentioning uPITRs and + uPETRs. + + o Made many changes based on editorial and wordsmithing comments + from Alia. + +A.2. Changes to draft-ietf-lisp-multicast-05.txt o Posted April 2011 to reset expiration timer. o Updated references. -A.2. Changes to draft-ietf-lisp-multicast-04.txt +A.3. Changes to draft-ietf-lisp-multicast-04.txt o Posted October 2010 to reset expiration timer. o Updated references. -A.3. Changes to draft-ietf-lisp-multicast-03.txt +A.4. Changes to draft-ietf-lisp-multicast-03.txt o Posted April 2010. o Added section 8.1.2 to address Joel Halpern's comment about receiver sites joining the same source site via 2 different RLOCs, each being a separate ITR. o Change all occurences of "mPTR" to "mPETR" to become more consistent with uPITRs and uPETRs described in [INTWORK]. That is, an mPETR is a LISP multicast router that decapsulates @@ -1251,47 +1278,47 @@ source sites. o Add clarifications in section 9 about how homogeneous multicast encapsulation should occur. As well as describing in this section, how to deal with mixed-locator sets to avoid heterogeneous encapsulation. o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges of LISP global multicast network. -A.4. Changes to draft-ietf-lisp-multicast-02.txt +A.5. Changes to draft-ietf-lisp-multicast-02.txt o Posted September 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. -A.5. Changes to draft-ietf-lisp-multicast-01.txt +A.6. Changes to draft-ietf-lisp-multicast-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. o Add Mttrace Considersations section. -A.6. Changes to draft-ietf-lisp-multicast-00.txt +A.7. Changes to draft-ietf-lisp-multicast-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Authors' Addresses Dino Farinacci cisco Systems Tasman Drive