--- 1/draft-ietf-lisp-multicast-08.txt 2011-10-06 05:14:05.070132089 +0200 +++ 2/draft-ietf-lisp-multicast-09.txt 2011-10-06 05:14:05.130132014 +0200 @@ -1,20 +1,20 @@ Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel -Expires: March 12, 2012 S. Venaas +Expires: April 7, 2012 S. Venaas cisco Systems - September 9, 2011 + October 5, 2011 LISP for Multicast Environments - draft-ietf-lisp-multicast-08 + draft-ietf-lisp-multicast-09 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 March 12, 2012. + This Internet-Draft will expire on April 7, 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 @@ -75,29 +75,30 @@ 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 + A.1. Changes to draft-ietf-lisp-multicast-09.txt . . . . . . . 36 + A.2. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 36 + A.3. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 36 + A.4. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 36 + A.5. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 36 + A.6. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 36 + A.7. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 36 + A.8. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 37 + A.9. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 37 + A.10. 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 @@ -283,60 +284,68 @@ (S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) entry by doing a mapping database lookup for the EID prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message when it travels from an ETR to an ITR over the Internet core. 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. + for multicast purposes, follows the procedures from Section 9. A + uLISP site can be a traditional multicast site. + + LISP Site: a unicast LISP site (uLISP Site) that is also multicast + capable according to the procedures in this specification. 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 [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 - in the oif-list for the (S-EID,G) entry the ETR is joining for. + in the OIF-list for the (S-EID,G) entry the ETR is joining for. + + OIF-list: this is notation to describe the outgoing interface list + a multicast router stores per multicast routing table entry so it + knows what interfaces to replicate multicast packets on. 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 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. 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. + At this point in time, there is no requirement for different locator- + sets, priority, and weight policies for multicast than there is 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 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. @@ -379,87 +388,87 @@ site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site). 6. When a packet is originated by the multicast host in the source - site, it will flow to one or more ITRs which will prepend a LISP - header by copying the group address to the outer destination - address field and insert its own locator address in the outer - source address field. The ITR will look at its (S-RLOC,G) state, - where S-RLOC is its own locator address, and replicate the packet - on each interface a (S-RLOC,G) joined was received on. The core - has (S-RLOC,G) so where fanout occurs to multiple sites, a core - router will do packet replication. + site, the packet will flow to one or more ITRs which will prepend + a LISP header. By copying the group address to the outer + destination address field, the ITR insert its own locator address + in the outer source address field. The ITR will look at its + (S-RLOC,G) state, where S-RLOC is its own locator address, and + replicate the packet on each interface a (S-RLOC,G) joined was + received on. The core has (S-RLOC,G) so where fanout occurs to + multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will decapsulate packets because it has receivers for the group. Otherwise, it would have not received the packets because it would not have joined. The ETR decapsulates and does a (S-EID,G) lookup in its multicast FIB to forward packets out one or more interfaces to forward the packet to internal receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. Alternatively, [LISP] also has a mechanism where (S-EID,G) state can reside in the core through the use of RPF-vectors [RFC5496] in PIM Join/Prune messages. However, few PIM implementations support RPF vectors and LISP should avoid S-EID state in the core. See Section 5 for details. - However, we have some observations on the algorithm above. We can - scale the control plane but at the expense of sending data to sites + However, some observations can be made on the algorithm above. The + control plane can scale but at the expense of sending data to sites which may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the - site. The ITR receives (S-RLOC,G) joins and populates the oif-list + site. The ITR receives (S-RLOC,G) joins and populates the OIF-list state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G) packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source - site and the number of RLOCs assigned to all ITRs at the site, but we - can reduce the "n" to a smaller number in the "n-to-1" relationship. - And in turn, reduce the opportunity for data packets to be delivered - to sites for groups not joined. + site and the number of RLOCs assigned to all ITRs at the site, but + "n" can reduce to a smaller number in the "n-to-1" relationship. And + in turn, reduce the opportunity for data packets to be delivered to + sites for groups not joined. 5. Source Addresses versus Group Addresses Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental 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 originated from hosts using their allocated EIDs. EID 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 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 @@ -514,21 +523,21 @@ 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 + local and not used over site boundaries and second, they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and MLDv2 messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP 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 @@ -556,58 +565,58 @@ 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. 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]. + modification to the operation of the PIM protocol. No + modifications to any message format, but 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]. PIM-Bidir: Bidirectional PIM is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would 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. 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. + use staticly configured RPs. Allowing core routers to associate a + Bidir group's RP address with an ITR's RLOC address. And site + routers to associate the Bidir group's RP address as 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 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. 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. + PIM-SSM techniques described above, multicast connectivity can + occur 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. 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 @@ -619,21 +628,21 @@ 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) 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 + (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 forwarding case. 8.1. ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site: @@ -641,40 +650,40 @@ 1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the group address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow. 2. When the ITR receives a multicast packet, it will have both S-EID 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 + 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 + 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 + 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 + 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.1.2. Multiple ITRs for a LISP Source Site 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) @@ -695,21 +704,21 @@ 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 + from the OIF-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header are not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped. 2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site. @@ -749,39 +758,39 @@ 9.1. LISP and non-LISP Mixed Sites Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same regardless of whether or not the site is LISP enabled or not. So most of the implications are in the core with respect to storing routable EID prefixes from either PA or PI blocks. - Before we enumerate the multicast interworking scenarios, we must - define 3 deployment states of a site: + Before enumerating the multicast interworking scenarios, let's define + 3 deployment states of a site: o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable. o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site. o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site. - We will not consider a LISP site enabled for multicast purposes only - but do consider a uLISP site as documented in [INTWORK]. In this - section we don't discuss how a LISP site sends multicast packets when - all receiver sites are LISP-Multicast enabled; that has been - discussed in previous sections. + What will not be considered is a LISP site enabled for multicast + purposes only but do consider a uLISP site as documented in + [INTWORK]. In this section there is no discussion how a LISP site + sends multicast packets when all receiver sites are LISP-Multicast + enabled; that has been discussed in previous sections. The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites: 1. A LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 2. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. @@ -811,32 +820,32 @@ 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 - process a received PIM Join/Prune message from an external-facing + be the same as an RLOC for the site because it is desirable for 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 - we have a conflict of behavior between the two types of sites. + there is a conflict of behavior between the two types of sites. The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing @@ -893,34 +902,34 @@ LISP source multicast site. Since the source multicast site, in this case has not been upgraded to LISP, all multicast source host addresses are routable. So this case is simplified to where a uLISP receiver multicast site looks to the source multicast site as a non- LISP receiver multicast site. 9.1.3. Non-LISP Source Site to Any Receiver Site When a non-LISP source multicast site has receivers in either a non- LISP/uLISP site or a LISP site, one needs to decide how the LISP - receiver multicast site will attach to the distribution tree. We - know from Section 9.1.2 that non-LISP and uLISP receiver multicast + receiver multicast site will attach to the distribution tree. It is + known 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 encapsulated Join/Prune message because there is no ITR in - a non-LISP site and there is namespace continuity between the ETR and - source). + source host is routable or not. It has been shown 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 encapsulated Join/Prune message because there + is no ITR in a non-LISP site and there is namespace continuity + between the ETR and source). 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 @@ -1000,27 +1009,27 @@ IPv6 format. When a mapping entry has a mix of RLOC formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets. To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format details. - If you consider the combinations of LISP, non-LISP, and uLISP sites + If one considers the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension. - Using some combinatorial math, we have the following profiles of a - site and the combinations that can occur: + Using some combinatorial math, the following profiles of a site and + the combinations that can occur: 1. LISP-Multicast IPv4 Site 2. LISP-Multicast IPv6 Site 3. LISP-Multicast Dual-Stack Site 4. uLISP IPv4 Site 5. uLISP IPv6 Site @@ -1030,44 +1039,45 @@ 8. non-LISP IPv6 Site 9. non-LISP Dual-Stack Site Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below. When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If sum - this up to (9 9), we have: + this up to (9 9), then: (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 Which results in the total number of cases to be considered at 502. - This combinatorial gets even worse when you consider a site using one - address family inside of the site and the xTRs use the other address - family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 - RLOCs). + This combinatorial gets even worse when one considers a site using + one address family inside of the site and the xTRs use the other + address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs + with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: o Each distribution tree shared between sites will either be an IPv4 - distribution tree or an IPv6 distribution tree. Therefore, we can - avoid head-end replication by building and sending packets on each - address family based distribution tree. Even though there might - be an urge to do multicast packet translation from one address - family format to the other, it is a non-viable over-complicated - urge. Multicast ITRs will only encapsulate packets where the - inner and outer headers are from the same address family. + distribution tree or an IPv6 distribution tree. Therefore, head- + end replication can be avoided by building and sending packets on + each address family based distribution tree. Even though there + might be an urge to do multicast packet translation from one + address family format to the other, it is a non-viable over- + complicated urge. Multicast ITRs will only encapsulate packets + where the inner and outer headers are from the same address + family. 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. @@ -1078,35 +1088,35 @@ 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 - ambitious, the dynamics of the protocol could cause a lot of - instability. + multicast connectivity that could occur. As already 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. + The trade-off decisions are hard to make and so the same single + solution is desirable 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 [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. + in the solution space so state requirements can be optimized 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. @@ -1120,63 +1130,65 @@ 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 [RFC5496], then we can - pass EID specific data through the core without, possibly, having to - store the state in the core. + If the core routers are upgraded to support [RFC5496], then the EID + specific data can be passed 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. + By doing this one 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 due to slow convergence properties, it is not being recommended for LISP-Multicast. 12. Mtrace Considerations - Mtrace functionality must be consistent with unicast traceroute + 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. + This document introduces no additional security concerns beyond those + specified in the base LISP specification [LISP]. 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, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko. + The authors 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, 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. + Liming Wei. The authors 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 @@ -1237,56 +1249,61 @@ [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-08.txt +A.1. Changes to draft-ietf-lisp-multicast-09.txt + + o Posted October 2011. Changes to reflect IESG review comments from + Ralph Droms and Kathleen Moriarty. + +A.2. 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 +A.3. Changes to draft-ietf-lisp-multicast-07.txt o Posted July 2011. Fixing IDnits errors. -A.3. Changes to draft-ietf-lisp-multicast-06.txt +A.4. 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.4. Changes to draft-ietf-lisp-multicast-05.txt +A.5. Changes to draft-ietf-lisp-multicast-05.txt o Posted April 2011 to reset expiration timer. o Updated references. -A.5. Changes to draft-ietf-lisp-multicast-04.txt +A.6. Changes to draft-ietf-lisp-multicast-04.txt o Posted October 2010 to reset expiration timer. o Updated references. -A.6. Changes to draft-ietf-lisp-multicast-03.txt +A.7. 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 @@ -1294,47 +1311,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.7. Changes to draft-ietf-lisp-multicast-02.txt +A.8. 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.8. Changes to draft-ietf-lisp-multicast-01.txt +A.9. 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.9. Changes to draft-ietf-lisp-multicast-00.txt +A.10. 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