--- 1/draft-ietf-lisp-multicast-07.txt 2011-09-13 08:16:23.000000000 +0200 +++ 2/draft-ietf-lisp-multicast-08.txt 2011-09-13 08:16:23.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel -Expires: January 10, 2012 S. Venaas +Expires: March 12, 2012 S. Venaas cisco Systems - July 9, 2011 + September 9, 2011 LISP for Multicast Environments - draft-ietf-lisp-multicast-07 + draft-ietf-lisp-multicast-08 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 in full conformance with the @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." - This Internet-Draft will expire on January 10, 2012. + This Internet-Draft will expire on March 12, 2012. 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 @@ -49,96 +49,98 @@ Table of Contents 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.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 - 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 17 - 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 - 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 18 - 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 . . . . 23 - 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 - 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 24 - 9.3. Making a Multicast Interworking Decision . . . . . . . . . 26 + 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28 - 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 29 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 - 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 - 16.2. Informative References . . . . . . . . . . . . . . . . . . 34 - Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 - A.1. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 35 - A.2. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35 - A.3. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 - A.4. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 - A.5. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 - A.6. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36 - A.7. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 - A.8. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 + Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29 + 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 + 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 + 16.2. Informative References . . . . . . . . . . . . . . . . . . 35 + Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 36 + A.1. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 36 + A.2. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 36 + A.3. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 36 + A.4. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 36 + A.5. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 36 + A.6. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 36 + A.7. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 37 + A.8. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 37 + A.9. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 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 separate out Identification and Location semantics from the current - definition of an IP address. By creating two namespaces, an EID - namespace used by sites and a Locator (RLOC) namespace used by core - routing, the core routing infrastructure can scale by doing - topological aggregation of routing information. + definition of an IP address. By creating two namespaces, an Endpoint + ID (EID) namespace used by sites and a Routing Locator (RLOC) + namespace used by core routing, the core routing infrastructure can + scale by doing topological aggregation of routing information. Since LISP creates a new namespace, a mapping function must exist to map a site's EID prefixes to its associated locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in - nature and not topology-dependent. Therefore, this specifications + nature and not topology-dependent. Therefore, this specification focuses on to map a source EID address of a multicast flow during distribution tree setup and packet delivery. This specification will address the following scenarios: 1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled. 2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed. 3. What protocols are affected and what changes are required to such multicast protocols. - 4. How ASM-mode, SSM-mode, and Bidir-mode service models will - operate. + 4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source + Multicast), and Bidir-mode (Bidirectional Shared Trees) service + models will operate. 5. How multicast packet flow will occur for multiple combinations of LISP and non-LISP capable source and receiver sites, for example: A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites. B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP @@ -149,35 +151,44 @@ enabled sites. D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this - specification requires no changes to the multicast infrastructure + specification requires no packet format changes to the protocol and + no operational procedural changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not run in an inter-domain environment is not addressed in depth in this version of the specification. Also, the current version of this specification does not describe - multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR - descriptions in [LISP]. + multicast-based Traffic Engineering relative to the TE-ITR (Traffic + Engineering based Ingress Tunnel Router) and TE-ETR (Traffic + Engineering based Egress Tunnel Router) descriptions in [LISP]. + Futher work is also needed to determine the detailed behavior for + multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), + and locator reachability (Section 6). Finally, further deployment + and experimentation would be useful to understand the real-life + performance of the LISP-Multicast solution. For instance, the design + optimizes for minimal state and control traffic in the core, but can + in some cases cause extra multicast traffic to be sent Section 8.1.2. 3. Definition of Terms The terminology in this section is consistent with the definitions in [LISP] but is extended specifically to deal with the application of the terminology to multicast routing. LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation @@ -316,22 +327,22 @@ 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. 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 + a 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. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they @@ -519,40 +530,42 @@ and MLD come out of the source site's allocated addresses which are therefore from the EID namespace. MBGP: Even though MBGP is not a multicast routing protocol, it is used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes which are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the - RLOC namespace. + RLOC namespace. There are no MBGP protocol changes required to + support LISP-Multicast. MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out - of by looking in the mapping database service. + of by looking in the mapping database service. There are no MSDP + protocol changes required to support LISP-Multicast. PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode, a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to the operation of the PIM protocol (but not to any message format) to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [RFC5135]. @@ -599,22 +612,22 @@ changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets. 8. LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [LISP]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination - address. And to have the ITR use its own IP address (its RLOC), and - as the source address. The process is simpler for multicast because + address. And to have the ITR use its own IP address (its RLOC) as + the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding. In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts. There is no Data-Probe logic for ETRs as there can be in the unicast @@ -1052,24 +1065,25 @@ o All LISP sites on a multicast distribution tree must share a 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- - set can exist (for unicast use), but the multicast priorities MUST - be the set for the same address family locators. + o When a multicast locator-set has more than one locator, only + locators from the same address-family MUST be set to the same best + priority value. 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 multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too @@ -1145,37 +1159,41 @@ 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, Lenny Guardino, Alia Atlas, and Jesus Arango. + Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko. 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. IANA Considerations This document makes no request of the IANA. 16. References 16.1. Normative References + [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP + with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt + (work in progress). + [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15.txt (work in progress). [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. @@ -1206,68 +1224,69 @@ [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 16.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative - Topology (LISP-ALT)", draft-ietf-lisp-alt-07.txt (work in + Topology (LISP-ALT)", draft-ietf-lisp-alt-08.txt (work in progress). - [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP - with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt - (work in progress). - [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress). [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-08.txt (work in progress). Appendix A. Document Change Log -A.1. Changes to draft-ietf-lisp-multicast-07.txt +A.1. Changes to draft-ietf-lisp-multicast-08.txt + + o Posted September 2011. Minor editorial changes from Jari's + commentary. + +A.2. Changes to draft-ietf-lisp-multicast-07.txt o Posted July 2011. Fixing IDnits errors. -A.2. Changes to draft-ietf-lisp-multicast-06.txt +A.3. 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.3. Changes to draft-ietf-lisp-multicast-05.txt +A.4. Changes to draft-ietf-lisp-multicast-05.txt o Posted April 2011 to reset expiration timer. o Updated references. -A.4. Changes to draft-ietf-lisp-multicast-04.txt +A.5. Changes to draft-ietf-lisp-multicast-04.txt o Posted October 2010 to reset expiration timer. o Updated references. -A.5. Changes to draft-ietf-lisp-multicast-03.txt +A.6. 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 @@ -1275,47 +1294,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.6. Changes to draft-ietf-lisp-multicast-02.txt +A.7. 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.7. Changes to draft-ietf-lisp-multicast-01.txt +A.8. 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.8. Changes to draft-ietf-lisp-multicast-00.txt +A.9. 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