draft-ietf-lisp-multicast-02.txt   draft-ietf-lisp-multicast-03.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental J. Zwiebel Intended status: Experimental J. Zwiebel
Expires: April 2, 2010 S. Venaas Expires: October 18, 2010 S. Venaas
cisco Systems cisco Systems
September 29, 2009 April 16, 2010
LISP for Multicast Environments LISP for Multicast Environments
draft-ietf-lisp-multicast-02.txt draft-ietf-lisp-multicast-03
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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2, 2010. This Internet-Draft will expire on October 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This draft describes how inter-domain multicast routing will function described in the BSD License.
in an environment where Locator/ID Separation is deployed using the
LISP architecture.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12
6. Locator Reachability Implications on LISP-Multicast . . . . . 13 6. Locator Reachability Implications on LISP-Multicast . . . . . 13
7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16
8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 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.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19
9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19
9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 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.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.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 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.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 23 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 24
9.3. Making a Multicast Interworking Decision . . . . . . . . . 25 9.3. Making a Multicast Interworking Decision . . . . . . . . . 26
10. Considerations when RP Addresses are Embedded in Group 10. Considerations when RP Addresses are Embedded in Group
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28
12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 28 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 31 15.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 33 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 34
A.1. Changes to draft-ietf-lisp-multicsat-02.txt . . . . . . . 33 A.1. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 34
A.2. Changes to draft-ietf-lisp-multicsat-01.txt . . . . . . . 33 A.2. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 34
A.3. Changes to draft-ietf-lisp-multicsat-00.txt . . . . . . . 33 A.3. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
The Locator/ID Separation Architecture [LISP] provides a mechanism to The Locator/ID Separation Architecture [LISP] provides a mechanism to
skipping to change at page 8, line 17 skipping to change at page 8, line 17
a source locator (the IP address of a multicast ITR) of a site 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) 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 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 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. 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 uLISP Site: a unicast only LISP site according to [LISP] which has
not deployed the procedures of this specification and therefore, 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.
mPTR: this is a multicast PTR that is responsible for advertising a mPETR: this is a multicast proxy-ETR that is responsible for
very coarse EID prefix which non-LISP and uLISP sites can target advertising a very coarse EID prefix which non-LISP and uLISP
their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs
source multicast sites can send multicast packets using source are used so LISP source multicast sites can send multicast packets
addresses from the EID namespace. mPTRs act as Proxy ETRs for using source addresses from the EID namespace. mPETRs act as Proxy
supporting multicast routing in a LISP infrastructure. ETRs for supporting multicast routing in a LISP infrastructure.
It is likely an uPITR and a mPETR will be co-loacted since the
single device advertises a coarse EID-prefix in the underlying
unicast routing system.
Mixed Locator-Sets: this is a locator-set for a LISP database Mixed Locator-Sets: this is a locator-set for a LISP database
mapping entry where the RLOC addresses in the locator-set are in mapping entry where the RLOC addresses in the locator-set are in
both IPv4 and IPv6 format. both IPv4 and IPv6 format.
Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM
Join/Prune message (encapsulated in a LISP Encapsulated Control Join/Prune message (encapsulated in a LISP Encapsulated Control
Message with destination UDP port 4342) which is sent by ETRs at Message with destination UDP port 4342) which is sent by ETRs at
multicast receiver sites to an ITR at a multicast source site. multicast receiver sites to an ITR at a multicast source site.
This message is sent periodically as long as there are interfaces This message is sent periodically as long as there are interfaces
skipping to change at page 9, line 36 skipping to change at page 9, line 36
header. The inner source address is the EID of the multicast source header. The inner source address is the EID of the multicast source
host and the outer source address is the RLOC of the encapsulating host and the outer source address is the RLOC of the encapsulating
ITR. ITR.
The LISP-Multicast architecture will follow this high-level protocol The LISP-Multicast architecture will follow this high-level protocol
and operational sequence: and operational sequence:
1. Receiver hosts in multicast sites will join multicast content the 1. Receiver hosts in multicast sites will join multicast content the
way they do today, they use IGMP. When they use IGMPv3 where way they do today, they use IGMP. When they use IGMPv3 where
they specify source addresses, they use source EIDs, that is they they specify source addresses, they use source EIDs, that is they
join (S-EID,G). If the S-EID is a local multicast source host. join (S-EID,G). If the multicast source is external to this
If the multicast source is external to this receiver site, the receiver site, the PIM Join/Prune message flows toward the ETRs,
PIM Join/Prune message flows toward the ETRs, finding the finding the shortest exit (that is the closest exit for the Join/
shortest exit (that is the closest exit for the Join/Prune Prune message and the closest entrance for the multicast packet
message but it is the closest entrance for the multicast packet
to the receiver). to the receiver).
2. The ETR does a mapping database lookup for S-EID. If the mapping 2. The ETR does a mapping database lookup for S-EID. If the mapping
is cached from a previous lookup (from either a previous Join/ is cached from a previous lookup (from either a previous Join/
Prune for the source multicast site or a unicast packet that went Prune for the source multicast site or a unicast packet that went
to the site), it will use the RLOC information from the mapping. to the site), it will use the RLOC information from the mapping.
The ETR will use the same priority and weighting mechanism as for The ETR will use the same priority and weighting mechanism as for
unicast. So the source site can decide which way multicast unicast. So the source site can decide which way multicast
packets egress. packets egress.
skipping to change at page 10, line 42 skipping to change at page 10, line 42
header by copying the group address to the outer destination header by copying the group address to the outer destination
address field and insert its own locator address in the outer address field and insert its own locator address in the outer
source address field. The ITR will look at its (S-RLOC,G) state, 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 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 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 has (S-RLOC,G) so where fanout occurs to multiple sites, a core
router will do packet replication. router will do packet replication.
7. When either the source site or the core replicates the packet, 7. When either the source site or the core replicates the packet,
the ETR will receive a LISP packet with a destination group the ETR will receive a LISP packet with a destination group
address. It will also decapsulate packets because it has address. It will decapsulate packets because it has receivers
receivers for the group. Otherwise, it would have not received for the group. Otherwise, it would have not received the packets
the packets because it would not have joined. The ETR because it would not have joined. The ETR decapsulates and does
decapsulates and does a (S-EID,G) lookup in its multicast FIB to a (S-EID,G) lookup in its multicast FIB to forward packets out
forward packets out one or more interfaces to forward the packet one or more interfaces to forward the packet to internal
to internal receivers. receivers.
This architecture is consistent and scalable with the architecture This architecture is consistent and scalable with the architecture
presented in [LISP] where multicast state in the core operates on presented in [LISP] where multicast state in the core operates on
locators and multicast state at the sites operates on EIDs. locators and multicast state at the sites operates on EIDs.
Alternatively, [LISP] does present a mechanism where (S-EID,G) state Alternatively, [LISP] also has a mechanism where (S-EID,G) state can
can reside in the core through the use of RPF-vectors [RPFV] in PIM reside in the core through the use of RPF-vectors [RPFV] in PIM Join/
Join/Prune messages. However, this will require EID state in core as Prune messages. However, few PIM implementations support RPF vectors
well as the use of RPF-vector formatted Join/Prune messages which are and LISP should avoid S-EID state in the core. See Section 5 for
not the default implementation choice. So we choose a design that details.
can allow the separation of namespaces as unicast LISP provides. It
will be at the expense of creating new (S-RLOC,G) state when ITRs go
unreachable. See Section 5 for details.
However, we have some observations on the algorithm above. We can However, we have some observations on the algorithm above. We can
scale the control plane but at the expense of sending data to sites scale the control plane but at the expense of sending data to sites
which may have not joined the distribution tree where the which may have not joined the distribution tree where the
encapsulated data is being delivered. For example, one site joins 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 (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 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 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 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
skipping to change at page 17, line 14 skipping to change at page 17, line 14
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 merging action that must take place. Therefore, when a packet is
received from a site-facing interface that matches on a (S-EID,G) 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 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 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 (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 must be tagged with the RLOC address, so encapsulation uses the outer
source address for the RLOC joined. 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)
state in the core. This will not result in duplicate packets because
each ITR in the multicast source site will choose their own RLOC for
the source address for encapsulated multicast traffic. The RLOC
addresses are the ones joined by remote multicast ETRs.
8.2. ETR Forwarding Procedure 8.2. ETR Forwarding Procedure
The following procedure is used by an ETR, when it receives a The following procedure is used by an ETR, when it receives a
multicast packet from a source outside of its site: multicast packet from a source outside of its site:
1. When a multicast data packet is received by an ETR on an 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 external-facing interface, it will do an RPF lookup on the S-RLOC
state it has stored. If the RPF check succeeds, the interfaces 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 site-facing as well as interfaces that are external-facing (this
skipping to change at page 21, line 29 skipping to change at page 21, line 29
that its site's EIDs are not routable, it assumes that the multicast 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 packets from the source host are sent by a routable address. That
is, it is the responsibility of the multicast source host's system is, it is the responsibility of the multicast source host's system
administrator to ensure that the source host sends multicast traffic administrator to ensure that the source host sends multicast traffic
using a routable source address. When this happens, the ITR acts using a routable source address. When this happens, the ITR acts
simply as a router and forwards the multicast packet like an ordinary simply as a router and forwards the multicast packet like an ordinary
multicast router. multicast router.
There is an alternative to using a LISP-NAT scheme just like there is There is an alternative to using a LISP-NAT scheme just like there is
for unicast [INTWORK] forwarding by using Proxy Tunnel Routers for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
(PTRs). This can work the same way for multicast routing as well, (PxTRs). This can work the same way for multicast routing as well,
but the difference is that non-LISP and uLISP sites will send PIM 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 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). multicast PxTRs. Let's call this use of a PxTR as a "Multicast
Since the PTRs advertise very coarse EID prefixes, they draw the PIM Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID
Join/Prune control traffic making them the target of the distribution prefixes, they draw the PIM Join/Prune control traffic making them
tree. To get multicast packets from the LISP source multicast sites, the target of the distribution tree. To get multicast packets from
the tree needs to be built on the path from the mPTR to the LISP the LISP source multicast sites, the tree needs to be built on the
source multicast site. To make this happen the mPTR acts as a "Proxy path from the mPETR to the LISP source multicast site. To make this
ETR" (where in unicast it acts as a "Proxy ITR"). happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a
"Proxy ITR", or an uPITR).
The existence of mPTRs in the core allows LISP source multicast site The existence of mPETRs in the core allows source multicast site ITRs
ITRs to encapsulate multicast packets so the state built between the to encapsulate multicast packets according to (S-RLOC,G) state. The
ITRs and the mPTRs is (S-RLOC,G) state. Then the mPTRs can (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The
decapsulate packets and forward natively to the non-LISP and uLISP encapsulated multicast packets are decapsulated by mPETRs and then
receiver multicast sites. forwarded according to (S-EID,G) state. The (S-EID,G) state is built
from the non-LISP and uLISP receiver multicast sites to the mPETRs.
9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites
Clearly non-LISP multicast sites can send multicast packets to non- Clearly non-LISP multicast sites can send multicast packets to non-
LISP receiver multicast sites. That is what they do today. However, LISP receiver multicast sites. That is what they do today. However,
discussion is required to show how non-LISP multicast sites send discussion is required to show how non-LISP multicast sites send
multicast packets to uLISP receiver multicast sites. multicast packets to uLISP receiver multicast sites.
Since uLISP receiver multicast sites are not targets of any (S,G) Since uLISP receiver multicast sites are not targets of any (S,G)
state, they simply send (S,G) PIM Join/Prune messages toward the non- state, they simply send (S,G) PIM Join/Prune messages toward the non-
LISP source multicast site. Since the source multicast site, in this LISP source multicast site. Since the source multicast site, in this
case has not been upgraded to LISP, all multicast source host case has not been upgraded to LISP, all multicast source host
skipping to change at page 22, line 32 skipping to change at page 22, line 34
ETR, before it sends a PIM Join/Prune message on an external-facing 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 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 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 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 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 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 unicast encapsulated Join/Prune message because there is no ITR in
a non-LISP site and there is namespace continuity between the ETR and a non-LISP site and there is namespace continuity between the ETR and
source). source).
9.1.4. Unicast LISP Source Site to Any Receiver Sites For a non-LISP source multicast site, (S-EID,G) state could be
limited to the edges of the network with the use of multicast proxy-
ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast
packets from non-LISP source multicast and uLISP sites and
encapsulate them to ETRs in receiver multicast sites or to mPETRs
that can decapsulate for non-LISP receiver multicast or uLISP sites.
The mPITRs are responsible for sending (S-EID,G) joins to the non-
LISP source multicast site. To connect the distribution trees
together, multicast ETRs will need to be configured with the mPITR's
RLOC addresses so they can send both (S-RLOC,G) joins to build a
distribution tree to the mPITR as well as for sending unicast oins to
mPITRs so they can propogate (S-EID,G) joins into source multicast
sites. The use of mPITRs is undergoing more study and is work in
progress.
9.1.4. Unicast LISP Source Site to Any Receiver Sites
In the last section, it was explained how an ETR in a multicast In the last section, it was explained how an ETR in a multicast
receiver site can determine if a source multicast site is LISP- receiver site can determine if a source multicast site is LISP-
enabled by looking into the mapping database. When the source enabled by looking into the mapping database. When the source
multicast site is a uLISP site, it is LISP enabled but the ITR, by multicast site is a uLISP site, it is LISP enabled but the ITR, by
definition is not capable of doing multicast encapsulation. So for definition is not capable of doing multicast encapsulation. So for
the purposes of multicast routing, the uLISP source multicast site is the purposes of multicast routing, the uLISP source multicast site is
treated as non-LISP source multicast site. treated as non-LISP source multicast site.
Non-LISP receiver multicast sites can join distribution trees to a Non-LISP receiver multicast sites can join distribution trees to a
skipping to change at page 23, line 23 skipping to change at page 23, line 45
forward multicast packets. Since the receiver multicast sites are forward multicast packets. Since the receiver multicast sites are
heterogeneous in their behavior, one packet forwarding mechanism heterogeneous in their behavior, one packet forwarding mechanism
cannot satisfy both. However, if a LISP receiver multicast site acts cannot satisfy both. However, if a LISP receiver multicast site acts
like a uLISP site then it could receive packets like a non-LISP like a uLISP site then it could receive packets like a non-LISP
receiver multicast site making all receiver multicast sites have receiver multicast site making all receiver multicast sites have
homogeneous behavior. However, this poses the following issues: homogeneous behavior. However, this poses the following issues:
o LISP-NAT techniques with routable addresses would be required in o LISP-NAT techniques with routable addresses would be required in
all cases. all cases.
o Or alternatively, mPTR deployment would be required forcing coarse o Or alternatively, mPETR deployment would be required forcing
EID prefix advertisement in the core. coarse EID prefix advertisement in the core.
o But what is most disturbing is that when all sites that o But what is most disturbing is that when all sites that
participate are LISP-Multicast sites but then a non-LISP or uLISP participate are LISP-Multicast sites but then a non-LISP or uLISP
site joins the distribution tree, then the existing joined LISP site joins the distribution tree, then the existing joined LISP
receiver multicast sites would have to change their behavior. receiver multicast sites would have to change their behavior.
This would create too much dynamic tree-building churn to be a This would create too much dynamic tree-building churn to be a
viable alternative. viable alternative.
So the solution space options are: So the solution space options are:
1. Make the LISP ITR in the source multicast site send two packets, 1. Make the LISP ITR in the source multicast site send two packets,
one that is encapsulated with (S-RLOC,G) to reach LISP receiver one that is encapsulated with (S-RLOC,G) to reach LISP receiver
multicast sites and another that is not encapsulated with multicast sites and another that is not encapsulated with
(S-EID,G) to reach non-LISP and uLISP receiver multicast sites. (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.
2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
reach LISP-Multicast sites and to reach mPTRs that can reach LISP-Multicast sites and to reach mPETRs that can
decapsulate and forward (S-EID,G) packets to non-LISP and uLISP decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
receiver multicast sites. receiver multicast sites.
9.2. LISP Sites with Mixed Address Families 9.2. LISP Sites with Mixed Address Families
A LISP database mapping entry that describes the locator-set, A LISP database mapping entry that describes the locator-set,
Mpriority and Mweight per locator address (RLOC), for an EID prefix Mpriority and Mweight per locator address (RLOC), for an EID prefix
associated with a site could have RLOC addresses in either IPv4 or associated with a site could have RLOC addresses in either IPv4 or
IPv6 format. When a mapping entry has a mix of RLOC formatted 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 addresses, it is an implicit advertisement by the site that it is a
skipping to change at page 25, line 13 skipping to change at page 25, line 33
Which results in the total number of cases to be considered at 502. 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 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 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 family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
RLOCs). RLOCs).
To rationalize this combinatorial nightmare, there are some To rationalize this combinatorial nightmare, there are some
guidelines which need to be put in place: guidelines which need to be put in place:
o Each distribution tree shared among sites will either be an IPv4 o Each distribution tree shared between sites will either be an IPv4
distribution tree or an IPv6 distribution tree. Therefore, we can distribution tree or an IPv6 distribution tree. Therefore, we can
avoid head-end replication by building and sending packets on each avoid head-end replication by building and sending packets on each
address family based distribution tree. Even though there might address family based distribution tree. Even though there might
be an urge to do multicast packet translation from one address be an urge to do multicast packet translation from one address
family format to the other, it is a non-viable over-complicated family format to the other, it is a non-viable over-complicated
urge. 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 o All LISP sites on a multicast distribution tree must share a
common address family which is determined by the source site's common address family which is determined by the source site's
locator-set in its LISP database mapping entry. All receiver locator-set in its LISP database mapping entry. All receiver
multicast sites will use the best RLOC priority controlled by the multicast sites will use the best RLOC priority controlled by the
source multicast site. This is true when the source site is source multicast site. This is true when the source site is
either LISP-Multicast or uLISP capable. This means that priority- either LISP-Multicast or uLISP capable. This means that priority-
based policy modification is prohibited. 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 the source site is not LISP capable, it is up to how o When the source site is not LISP capable, it is up to how
receivers find the source and group information for a multicast receivers find the source and group information for a multicast
flow. That mechanism decides the address family for the flow. flow. That mechanism decides the address family for the flow.
9.3. Making a Multicast Interworking Decision 9.3. Making a Multicast Interworking Decision
This Multicast Interworking section has shown all combinations of This Multicast Interworking section has shown all combinations of
multicast connectivity that could occur. As you might have already multicast connectivity that could occur. As you might have already
concluded, this can be quite complicated and if the design is too concluded, this can be quite complicated and if the design is too
ambitious, the dynamics of the protocol could cause a lot of ambitious, the dynamics of the protocol could cause a lot of
instability. instability.
The trade-off decisions are hard to make and we want the same single 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 solution to work for both IPv4 and IPv6 multicast. It is imperative
to have an incrementally deployable solution for all of IPv4 unicast to have an incrementally deployable solution for all of IPv4 unicast
and multicast and IPv6 unicast and multicast while minimizing (or and multicast and IPv6 unicast and multicast while minimizing (or
eliminating) both unicast and multicast EID namespace state. eliminating) both unicast and multicast EID namespace state.
Therefore the design decision to go with PTRs for unicast routing and Therefore the design decision to go with uPITRs for unicast routing
mPTRs for multicast routing seems to be the sweet spot in the and mPETRs for multicast routing seems to be the sweet spot in the
solution space so we can optimize state requirements and avoid head- solution space so we can optimize state requirements and avoid head-
end data replication at ITRs. end data replication at ITRs.
10. Considerations when RP Addresses are Embedded in Group Addresses 10. Considerations when RP Addresses are Embedded in Group Addresses
When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a 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 technique exists to embed the unicast address of an RP in a IPv6
group address [RFC3956]. When routers in end sites process a PIM group address [RFC3956]. When routers in end sites process a PIM
Join/Prune message which contain an embedded-RP group address, they Join/Prune message which contain an embedded-RP group address, they
extract the RP address from the group address and treat it from the extract the RP address from the group address and treat it from the
skipping to change at page 31, line 45 skipping to change at page 32, line 45
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
15.2. Informative References 15.2. Informative References
[ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in Topology (LISP-ALT)", draft-ietf-lisp-alt-04.txt (work in
progress), May 2009. progress), April 2010.
[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt
(work in progress), May 2009. (work in progress), March 2010.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-05.txt (work in progress), September 2009. draft-ietf-lisp-07.txt (work in progress), April 2010.
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-farinacci-lisp-multicast-01.txt (work in progress), draft-farinacci-lisp-multicast-01.txt (work in progress),
November 2008. November 2008.
[MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a
Network Address (and port) Translator (NAT)", Network Address (and port) Translator (NAT)",
draft-ietf-behave-multicast-07.txt (work in progress), draft-ietf-behave-multicast-07.txt (work in progress),
June 2007. June 2007.
skipping to change at page 33, line 7 skipping to change at page 34, line 7
Version 2: Traceroute Facility for IP Multicast", Version 2: Traceroute Facility for IP Multicast",
draft-ietf-mboned-mtrace-v2-03.txt (work in progress), draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
March 2009. March 2009.
[RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
February 2008. February 2008.
Appendix A. Document Change Log Appendix A. Document Change Log
A.1. Changes to draft-ietf-lisp-multicsat-02.txt A.1. 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
multicast packets that are encapsulated to it by ITRs in multicast
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.2. Changes to draft-ietf-lisp-multicast-02.txt
o Posted September 2009. o Posted September 2009.
o Added Document Change Log appendix. o Added Document Change Log appendix.
o Specify that the LISP Encapsulated Control Message be used for o Specify that the LISP Encapsulated Control Message be used for
unicasting PIM Join/Prune messages from ETRs to ITRs. unicasting PIM Join/Prune messages from ETRs to ITRs.
A.2. Changes to draft-ietf-lisp-multicsat-01.txt A.3. Changes to draft-ietf-lisp-multicast-01.txt
o Posted November 2008. o Posted November 2008.
o Specified that PIM Join/Prune unicast messages that get sent from o Specified that PIM Join/Prune unicast messages that get sent from
ETRs to ITRs of a source multicast site get LISP encapsulated in ETRs to ITRs of a source multicast site get LISP encapsulated in
destination UDP port 4342. destination UDP port 4342.
o Add multiple RLOCs per ITR per Yiqun's comments. o Add multiple RLOCs per ITR per Yiqun's comments.
o Indicate how static RPs can be used when LISP is run using Bidir- o Indicate how static RPs can be used when LISP is run using Bidir-
PIM in the core. PIM in the core.
o Editorial changes per Liming comments. o Editorial changes per Liming comments.
o Add Mttrace Considersations section. o Add Mttrace Considersations section.
A.3. Changes to draft-ietf-lisp-multicsat-00.txt A.4. Changes to draft-ietf-lisp-multicast-00.txt
o Posted April 2008. o Posted April 2008.
o Renamed from draft-farinacci-lisp-multicast-01.txt. o Renamed from draft-farinacci-lisp-multicast-01.txt.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
cisco Systems cisco Systems
Tasman Drive Tasman Drive
 End of changes. 33 change blocks. 
88 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/