--- 1/draft-ietf-lisp-multicast-00.txt 2009-05-29 08:12:11.000000000 +0200 +++ 2/draft-ietf-lisp-multicast-01.txt 2009-05-29 08:12:11.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel -Expires: November 27, 2009 S. Venaas +Expires: November 29, 2009 S. Venaas cisco Systems - May 26, 2009 + May 28, 2009 LISP for Multicast Environments - draft-ietf-lisp-multicast-00.txt + draft-ietf-lisp-multicast-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,21 +23,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 27, 2009. + This Internet-Draft will expire on November 29, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -53,40 +53,42 @@ 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 - 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 + 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 + 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 - 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 18 - 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 18 - 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 19 - 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 20 - 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 21 - 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 21 - 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 22 - 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22 - 9.3. Making a Multicast Interworking Decision . . . . . . . . . 24 + 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 + 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 + 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 + 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21 + 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 + 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 22 + 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 + 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 23 + 9.3. Making a Multicast Interworking Decision . . . . . . . . . 25 10. Considerations when RP Addresses are Embedded in Group - Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 26 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 - 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 + Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 + 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 28 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 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 The Locator/ID Separation Architecture [LISP] provides a mechanism to @@ -274,26 +276,26 @@ very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPTRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. 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 PIM Join/Prune Message: this is a standard PIM Join/Prune - message (encapsulated in an IP header with protocol number 103) - 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 in the oif-list for the (S-EID,G) entry - the ETR is joining for. + Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM + Join/Prune message (LISP encapsulated with destination UDP port + 4341) 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 in the oif-list for the (S-EID,G) + entry the ETR is joining for. 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled 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 @@ -428,24 +430,24 @@ deployment of LISP-Multicast. As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs, those addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet. Therefore, when multicast distribution tree state is created anywhere - in the network on the path from the any multicast receiver to a - multicast source, EID state is maintained at the source and receiver - multicast sites, and RLOC state is maintained in the core. That is, - a multicast distribution tree will be represented as a 3-tuple of + in the network on the path from any multicast receiver to a multicast + source, EID state is maintained at the source and receiver multicast + sites, and RLOC state is maintained in the core. That is, a + multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site, the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites, and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites. @@ -473,30 +475,30 @@ the reachability of the ETR. So an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR goes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be rebuilt and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) - to the new ITR as well as send a unicast Join/Prune message telling - the new ITR which (S-EID,G) is being joined. + to the new ITR as well as send a unicast encapsulated Join/Prune + message telling the new ITR which (S-EID,G) is being joined. This issue can be mitigated by using anycast addressing for the ITRs so the problem does reduce to an RPF change in the core, but still - requires a unicast Join/Prune message to tell the new ITR about - (S-EID,G). The problem with this approach is that the ETR really - doesn't know when the ITR has changed so the new anycast ITR will get - the (S-EID,G) state only when the ETR sends it the next time during - its periodic sending procedures. + requires a unicast encapsulated Join/Prune message to tell the new + ITR about (S-EID,G). The problem with this approach is that the ETR + really doesn't know when the ITR has changed so the new anycast ITR + will get the (S-EID,G) state only when the ETR sends it the next time + during its periodic sending procedures. 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for LISP-Multicast for two reasons. One being that they are link- local and not used over site boundaries and second they advertise group addresses that don't need translation. Where source @@ -550,33 +552,39 @@ have to decide if the RP address of the shared-tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need - to make when using Embedded-RP IPv6 group addresses. With respect - to DF-election in Bidir PIM, no changes are required since all - messaging and addressing is link-local. + to make when using Embedded-RP IPv6 group addresses. When using + Bidir-PIM for inter-domain multicast routing, it is recommended to + use staticly configured RPs so core routers think the Bidir group + is associated with an ITR's RLOC as the RP address and site + routers think the Bidir group is associated with the site resident + RP with an EID address. With respect to DF-election in Bidir PIM, + no changes are required since all messaging and addressing is + link-local. - PIM-ASM: The way ASM mode PIM, the most popular form of PIM, is + PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites. By the use of MSDP and PIM-SSM techniques described above, we can get multicast connectivity across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the - shared-tree which is site resident. This is also true for the RP- - mapping mechanisms Auto-RP and BSR. + shared-tree which is site resident. Just like with ASM, there is + no (*,G) in the core when LISP-Multicast is in use. This is also + true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive @@ -618,20 +626,35 @@ state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the oif-list contains interfaces that are site-facing and external-facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header the host built as the outer destination address. +8.1.1. Multiple RLOCs for an ITR + + Typically, an ITR will have a single RLOC address but in some cases + there could be multiple RLOC addresses assigned from either the same + or different service providers. In this case when (S-RLOC,G) Join/ + Prune messages are received for each RLOC, there is a oif-list + merging action that must take place. Therefore, when a packet is + received from a site-facing interface that matches on a (S-EID,G) + entry, the interfaces of the oif-list from all (RLOC,G) entries + joined to the ITR as well as the site-facing oif-list joined for + (S-EID,G) must be part be included in packet replication. In + addition to replicating for all types of oif-lists, each oif entry + must be tagged with the RLOC address, so encapsulation uses the outer + source address for the RLOC joined. + 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 @@ -772,30 +795,31 @@ routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. 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 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. + 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. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PTRs). 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 PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). Since the PTRs 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, @@ -832,22 +856,23 @@ know from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. We showed in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send - a unicast Join/Prune message because there is no ITR in a non-LISP - site and there is namespace continuity between the ETR and source). + a unicast encapsulated Join/Prune message because there is no ITR in + a non-LISP site and there is namespace continuity between the ETR and + source). 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 the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. @@ -1024,53 +1049,71 @@ to the ITR is created. This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address. 11. Taking Advantage of Upgrades in the Core - If the core routers are upgraded to support [RPFV] and [JOIN-ATTR], + 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 unicasting PIM Join/Prune - messages to the source site's ITR. + By doing this we can eliminate the ETR from unicast encapsulating PIM + Join/Prune messages to the source site's ITR. -12. Security Considerations + 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. + +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]. + +13. Security Considerations Refer to the [LISP] specification. -13. Acknowledgments +14. Acknowledgments The authors would like to gratefully acknowledge the people who have 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. + 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. -14. References +15. References -14.1. Normative References +15.1. Normative References [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. @@ -1088,49 +1131,52 @@ IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. -14.2. Informative References + [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-fuller-lisp-alt-02.txt (work - in progress), April 2008. + Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in + progress), May 2009. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP - with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt - (work in progress), December 2007. - - [JOIN-ATTR] - Wijnands, IJ. and A. Boers, "Format for using TLVs in PIM - messages", draft-ietf-pim-join-attributes-03.txt (work in - progress), May 2007. + with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt + (work in progress), May 2009. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-00.txt (work in progress), May 2009. + draft-ietf-lisp-01.txt (work in progress), May 2009. [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. + [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace + 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. Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA