draft-ietf-lisp-multicast-00.txt | draft-ietf-lisp-multicast-01.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: November 27, 2009 S. Venaas | Expires: November 29, 2009 S. Venaas | |||
cisco Systems | cisco Systems | |||
May 26, 2009 | May 28, 2009 | |||
LISP for Multicast Environments | LISP for Multicast Environments | |||
draft-ietf-lisp-multicast-00.txt | draft-ietf-lisp-multicast-01.txt | |||
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 34 | |||
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 November 27, 2009. | This Internet-Draft will expire on November 29, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 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 in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 22 | skipping to change at page 2, line 22 | |||
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.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 | 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 | |||
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 | ||||
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 | 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 | |||
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 18 | 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 | |||
9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 18 | 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 | |||
9.1.1. LISP Source Site to non-LISP Receiver 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 . . . 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 . . . . . . 21 | 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 | |||
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 21 | 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 22 | |||
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 22 | 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 | |||
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22 | 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 23 | |||
9.3. Making a Multicast Interworking Decision . . . . . . . . . 24 | 9.3. Making a Multicast Interworking Decision . . . . . . . . . 25 | |||
10. Considerations when RP Addresses are Embedded in Group | 10. Considerations when RP Addresses are Embedded in Group | |||
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 26 | 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 | |||
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 28 | |||
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . . 29 | 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 | 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
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 28 | skipping to change at page 8, line 28 | |||
very coarse EID prefix which non-LISP and uLISP sites can target | very coarse EID prefix which non-LISP and uLISP sites can target | |||
their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP | their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP | |||
source multicast sites can send multicast packets using source | source multicast sites can send multicast packets using source | |||
addresses from the EID namespace. mPTRs act as Proxy ETRs for | addresses from the EID namespace. mPTRs act as Proxy ETRs for | |||
supporting multicast routing in a LISP infrastructure. | supporting multicast routing in a LISP infrastructure. | |||
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 PIM Join/Prune Message: this is a standard PIM Join/Prune | Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM | |||
message (encapsulated in an IP header with protocol number 103) | Join/Prune message (LISP encapsulated with destination UDP port | |||
which is sent by ETRs at multicast receiver sites to an ITR at a | 4341) which is sent by ETRs at multicast receiver sites to an ITR | |||
multicast source site. This message is sent periodically as long | at a multicast source site. This message is sent periodically as | |||
as there are interfaces in the oif-list for the (S-EID,G) entry | long as there are interfaces in the oif-list for the (S-EID,G) | |||
the ETR is joining for. | entry the ETR is joining for. | |||
4. Basic Overview | 4. Basic Overview | |||
LISP, when used for unicast routing, increases the site's ability to | LISP, when used for unicast routing, increases the site's ability to | |||
control ingress traffic flows. Egress traffic flows are controlled | control ingress traffic flows. Egress traffic flows are controlled | |||
by the IGP in the source site. For multicast, the IGP coupled with | by the IGP in the source site. For multicast, the IGP coupled with | |||
PIM can decide which path multicast packets ingress. By using the | PIM can decide which path multicast packets ingress. By using the | |||
traffic engineering features of LISP, a multicast source site can | traffic engineering features of LISP, a multicast source site can | |||
control the egress of its multicast traffic. By controlling the | control the egress of its multicast traffic. By controlling the | |||
priorities of locators from a mapping database entry, a source | priorities of locators from a mapping database entry, a source | |||
skipping to change at page 12, line 21 | skipping to change at page 12, line 21 | |||
deployment of LISP-Multicast. | deployment of LISP-Multicast. | |||
As for source addresses, as in the unicast LISP scenario, there is a | As for source addresses, as in the unicast LISP scenario, there is a | |||
decoupling of identification from location. In a LISP site, packets | 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, those addresses | |||
are used to identify the host as well as where in the site's topology | 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 | the host resides but not how and where it is attached to the | |||
Internet. | Internet. | |||
Therefore, when multicast distribution tree state is created anywhere | Therefore, when multicast distribution tree state is created anywhere | |||
in the network on the path from the any multicast receiver to a | in the network on the path from any multicast receiver to a multicast | |||
multicast source, EID state is maintained at the source and receiver | source, EID state is maintained at the source and receiver multicast | |||
multicast sites, and RLOC state is maintained in the core. That is, | sites, and RLOC state is maintained in the core. That is, a | |||
a multicast distribution tree will be represented as a 3-tuple of | 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 | {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the | |||
3-tuple is the state stored in routers from the source to one or more | 3-tuple is the state stored in routers from the source to one or more | |||
ITRs in the source multicast site, the second element of the 3-tuple | ITRs in the source multicast site, the second element of the 3-tuple | |||
is the state stored in routers downstream of the ITR, in the core, to | is the state stored in routers downstream of the ITR, in the core, to | |||
all LISP receiver multicast sites, and the third element in the | all LISP receiver multicast sites, and the third element in the | |||
3-tuple is the state stored in the routers downstream of each ETR, in | 3-tuple is the state stored in the routers downstream of each ETR, in | |||
each receiver multicast site, reaching each receiver. Note that | each receiver multicast site, reaching each receiver. Note that | |||
(S-EID,G) is the same in both the source and receiver multicast | (S-EID,G) is the same in both the source and receiver multicast | |||
sites. | sites. | |||
skipping to change at page 13, line 32 | skipping to change at page 13, line 32 | |||
the reachability of the ETR. So an ITR can change relatively easily | the reachability of the ETR. So an ITR can change relatively easily | |||
using local reachability state. However, in the multicast case, when | using local reachability state. However, in the multicast case, when | |||
an ITR goes unreachable, new distribution tree state must be built | an ITR goes unreachable, new distribution tree state must be built | |||
because the encapsulating root has changed. This is more significant | because the encapsulating root has changed. This is more significant | |||
than an RPF-change event, where any router would typically locally | than an RPF-change event, where any router would typically locally | |||
change its RPF-interface for its existing tree state. But when an | change its RPF-interface for its existing tree state. But when an | |||
encapsulating LISP-Multicast ITR goes unreachable, new distribution | encapsulating LISP-Multicast ITR goes unreachable, new distribution | |||
state must be rebuilt and reflect the new encapsulator. Therefore, | state must be rebuilt and reflect the new encapsulator. Therefore, | |||
when an ITR goes unreachable, all ETRs that are currently joined to | when an ITR goes unreachable, all ETRs that are currently joined to | |||
that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) | that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) | |||
to the new ITR as well as send a unicast Join/Prune message telling | to the new ITR as well as send a unicast encapsulated Join/Prune | |||
the new ITR which (S-EID,G) is being joined. | message telling the new ITR which (S-EID,G) is being joined. | |||
This issue can be mitigated by using anycast addressing for the ITRs | This issue can be mitigated by using anycast addressing for the ITRs | |||
so the problem does reduce to an RPF change in the core, but still | so the problem does reduce to an RPF change in the core, but still | |||
requires a unicast Join/Prune message to tell the new ITR about | requires a unicast encapsulated Join/Prune message to tell the new | |||
(S-EID,G). The problem with this approach is that the ETR really | ITR about (S-EID,G). The problem with this approach is that the ETR | |||
doesn't know when the ITR has changed so the new anycast ITR will get | really doesn't know when the ITR has changed so the new anycast ITR | |||
the (S-EID,G) state only when the ETR sends it the next time during | will get the (S-EID,G) state only when the ETR sends it the next time | |||
its periodic sending procedures. | during its periodic sending procedures. | |||
7. Multicast Protocol Changes | 7. Multicast Protocol Changes | |||
A number of protocols are used today for inter-domain multicast | A number of protocols are used today for inter-domain multicast | |||
routing: | routing: | |||
IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for | IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for | |||
LISP-Multicast for two reasons. One being that they are link- | 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 | group addresses that don't need translation. Where source | |||
skipping to change at page 15, line 22 | skipping to change at page 15, line 22 | |||
have to decide if the RP address of the shared-tree would be from | 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 | 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. | site-based router, then the RP address is from the EID namespace. | |||
If the RP resides in the core where RLOC addresses are routed, | If the RP resides in the core where RLOC addresses are routed, | |||
then the RP address is from the RLOC namespace. This could be | then the RP address is from the RLOC namespace. This could be | |||
easily distinguishable if the EID address were well-known address | easily distinguishable if the EID address were well-known address | |||
allocation block from the RLOC namespace. Also, when using | allocation block from the RLOC namespace. Also, when using | |||
Embedded-RP for RP determination [RFC3956], the format of the | Embedded-RP for RP determination [RFC3956], the format of the | |||
group address could indicate the namespace the RP address is from. | group address could indicate the namespace the RP address is from. | |||
However, refer to Section 10 for considerations core routers need | However, refer to Section 10 for considerations core routers need | |||
to make when using Embedded-RP IPv6 group addresses. With respect | to make when using Embedded-RP IPv6 group addresses. When using | |||
to DF-election in Bidir PIM, no changes are required since all | Bidir-PIM for inter-domain multicast routing, it is recommended to | |||
messaging and addressing is link-local. | use staticly configured RPs so core routers think the Bidir group | |||
is associated with an ITR's RLOC as the RP address and site | ||||
routers think the Bidir group is associated with the site resident | ||||
RP with an EID address. With respect to DF-election in Bidir PIM, | ||||
no changes are required since all messaging and addressing is | ||||
link-local. | ||||
PIM-ASM: The way ASM mode PIM, the most popular form of PIM, is | PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is | |||
deployed in the Internet today is by having shared-trees within a | 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 | site and using source-trees across sites. By the use of MSDP and | |||
PIM-SSM techniques described above, we can get multicast | PIM-SSM techniques described above, we can get multicast | |||
connectivity across LISP sites. Having said that, that means | connectivity across LISP sites. Having said that, that means | |||
there are no special actions required for processing (*,G) or | there are no special actions required for processing (*,G) or | |||
(S,G,R) Join/Prune messages since they all operate against the | (S,G,R) Join/Prune messages since they all operate against the | |||
shared-tree which is site resident. This is also true for the RP- | shared-tree which is site resident. Just like with ASM, there is | |||
mapping mechanisms Auto-RP and BSR. | 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 | Based on the protocol description above, the conclusion is that there | |||
are no protocol message format changes, just a translation function | are no protocol message format changes, just a translation function | |||
performed at the control-plane. This will make for an easier and | performed at the control-plane. This will make for an easier and | |||
faster transition for LISP since fewer components in the network have | faster transition for LISP since fewer components in the network have | |||
to change. | to change. | |||
It should also be stated just like it is in [LISP] that no host | It should also be stated just like it is in [LISP] that no host | |||
changes, whatsoever, are required to have a multicast source host | changes, whatsoever, are required to have a multicast source host | |||
send multicast packets and for a multicast receiver host to receive | send multicast packets and for a multicast receiver host to receive | |||
skipping to change at page 16, line 48 | skipping to change at page 16, line 48 | |||
state and S-RLOC state stored. Since the packet was received on | 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 | 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 | interfaces that are site-facing and external-facing. For the | |||
site-facing interfaces, no LISP header is prepended. For the | site-facing interfaces, no LISP header is prepended. For the | |||
external-facing interfaces a LISP header is prepended. When the | external-facing interfaces a LISP header is prepended. When the | |||
ITR prepends a LISP header, it uses its own RLOC address as 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 | source address and copies the group address supplied by the IP | |||
header the host built as the outer destination address. | header the host built as the outer destination address. | |||
8.1.1. Multiple RLOCs for an ITR | ||||
Typically, an ITR will have a single RLOC address but in some cases | ||||
there could be multiple RLOC addresses assigned from either the same | ||||
or different service providers. In this case when (S-RLOC,G) Join/ | ||||
Prune messages are received for each RLOC, there is a oif-list | ||||
merging action that must take place. Therefore, when a packet is | ||||
received from a site-facing interface that matches on a (S-EID,G) | ||||
entry, the interfaces of the oif-list from all (RLOC,G) entries | ||||
joined to the ITR as well as the site-facing oif-list joined for | ||||
(S-EID,G) must be part be included in packet replication. In | ||||
addition to replicating for all types of oif-lists, each oif entry | ||||
must be tagged with the RLOC address, so encapsulation uses the outer | ||||
source address for the RLOC joined. | ||||
8.2. ETR Forwarding Procedure | 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 20, line 15 | skipping to change at page 21, line 15 | |||
routable address and not an EID prefix address. So the ETR knows to | routable address and not an EID prefix address. So the ETR knows to | |||
simply propagate the PIM Join/Prune message to a external-facing | simply propagate the PIM Join/Prune message to a external-facing | |||
interface without converting the (S-EID,G) because it is an (S,G) | interface without converting the (S-EID,G) because it is an (S,G) | |||
where S is routable and reachable via core routing tables. | where S is routable and reachable via core routing tables. | |||
Now that the multicast distribution tree is built and maintained from | Now that the multicast distribution tree is built and maintained from | |||
any non-LISP or uLISP receiver multicast site, the way packet | any non-LISP or uLISP receiver multicast site, the way packet | |||
forwarding model is performed can be explained. | forwarding model is performed can be explained. | |||
Since the ITR in the source multicast site has never received a | Since the ITR in the source multicast site has never received a | |||
unicast PIM Join/Prune message from any ETR in a receiver multicast | unicast encapsulated PIM Join/Prune message from any ETR in a | |||
site, it knows there are no LISP-Multicast receiver sites. | receiver multicast site, it knows there are no LISP-Multicast | |||
Therefore, there is no need for the ITR to encapsulate data. Since | receiver sites. Therefore, there is no need for the ITR to | |||
it will know a priori (via configuration) that its site's EIDs are | encapsulate data. Since it will know a priori (via configuration) | |||
not routable, it assumes that the multicast packets from the source | that its site's EIDs are not routable, it assumes that the multicast | |||
host are sent by a routable address. That is, it is the | packets from the source host are sent by a routable address. That | |||
responsibility of the multicast source host's system administrator to | is, it is the responsibility of the multicast source host's system | |||
ensure that the source host sends multicast traffic using a routable | administrator to ensure that the source host sends multicast traffic | |||
source address. When this happens, the ITR acts simply as a router | using a routable source address. When this happens, the ITR acts | |||
and forwards the multicast packet like an ordinary multicast router. | simply as a router and forwards the multicast packet like an ordinary | |||
multicast router. | ||||
There is an alternative to using a LISP-NAT scheme just like there is | 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, | (PTRs). This can work the same way for multicast routing as well, | |||
but the difference is that non-LISP and uLISP sites will send PIM | 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). | PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). | |||
Since the PTRs advertise very coarse EID prefixes, they draw the PIM | Since the PTRs advertise very coarse EID prefixes, they draw the PIM | |||
Join/Prune control traffic making them the target of the distribution | Join/Prune control traffic making them the target of the distribution | |||
tree. To get multicast packets from the LISP source multicast sites, | tree. To get multicast packets from the LISP source multicast sites, | |||
skipping to change at page 21, line 28 | skipping to change at page 22, line 28 | |||
know from Section 9.1.2 that non-LISP and uLISP receiver multicast | know from Section 9.1.2 that non-LISP and uLISP receiver multicast | |||
sites can join the distribution tree, but a LISP 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 | 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 | 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 | 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 Join/Prune message because there is no ITR in a non-LISP | a unicast encapsulated Join/Prune message because there is no ITR in | |||
site and there is namespace continuity between the ETR and source). | a non-LISP site and there is namespace continuity between the ETR and | |||
source). | ||||
9.1.4. Unicast LISP Source Site to Any Receiver Sites | 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. | |||
skipping to change at page 26, line 7 | skipping to change at page 27, line 7 | |||
to the ITR is created. | to the ITR is created. | |||
This technique is no different than the techniques described in this | This technique is no different than the techniques described in this | |||
specification for translating (S,G) state and propagating Join/Prune | specification for translating (S,G) state and propagating Join/Prune | |||
messages into the core. The only difference is that the (*,G) state | messages into the core. The only difference is that the (*,G) state | |||
in Join/Prune messages are mapped because they contain unicast | in Join/Prune messages are mapped because they contain unicast | |||
addresses encoded in an Embedded-RP group address. | addresses encoded in an Embedded-RP group address. | |||
11. Taking Advantage of Upgrades in the Core | 11. Taking Advantage of Upgrades in the Core | |||
If the core routers are upgraded to support [RPFV] and [JOIN-ATTR], | If the core routers are upgraded to support [RPFV] and [RFC5496], | |||
then we can pass EID specific data through the core without, | then we can pass EID specific data through the core without, | |||
possibly, having to store the state in the core. | possibly, having to store the state in the core. | |||
By doing this we can eliminate the ETR from unicasting PIM Join/Prune | By doing this we can eliminate the ETR from unicast encapsulating PIM | |||
messages to the source site's ITR. | Join/Prune messages to the source site's ITR. | |||
12. Security Considerations | However, this solution is restricted to a small set of workable cases | |||
which would not be good for general use of LISP-Multicast. In | ||||
addition to slow convergence properties, it is not being recommended | ||||
for LISP-Multicast. | ||||
12. Mtrace Considerations | ||||
Mtrace functionality must be consistent with unicast traceroute | ||||
functionality where all hops from multicast receiver to multicast | ||||
source are visible. | ||||
The design for mtrace for use in LISP-Multicast environments is to be | ||||
determined but should build upon the mtrace version 2 specified in | ||||
[MTRACE]. | ||||
13. Security Considerations | ||||
Refer to the [LISP] specification. | Refer to the [LISP] specification. | |||
13. Acknowledgments | 14. Acknowledgments | |||
The authors would like to gratefully acknowledge the people who have | The authors would like to gratefully acknowledge the people who have | |||
contributed discussion, ideas, and commentary to the making of this | contributed discussion, ideas, and commentary to the making of this | |||
proposal and specification. People who provided expert review were | proposal and specification. People who provided expert review were | |||
Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from | Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from | |||
discussions at Summer 2008 Dublin IETF were Toerless Eckert and | discussions at Summer 2008 Dublin IETF were Toerless Eckert and | |||
Ijsbrand Wijnands. | Ijsbrand Wijnands. | |||
We would also like to thank the MBONED working group for constructive | We would also like to thank the MBONED working group for constructive | |||
and civil verbal feedback when this draft was presented at the Fall | and civil verbal feedback when this draft was presented at the Fall | |||
2008 IETF in Minneapolis. In particular, good commentary came from | 2008 IETF in Minneapolis. In particular, good commentary came from | |||
Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, | Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, | |||
Ron Bonica, and Lenny Guardino. | Ron Bonica, and Lenny Guardino. | |||
An expert review of this specification was done by Yiqun Cai and | ||||
Liming Wei. We thank them for their detailed comments. | ||||
This work originated in the Routing Research Group (RRG) of the IRTF. | This work originated in the Routing Research Group (RRG) of the IRTF. | |||
The individual submission [MLISP] was converted into this IETF LISP | The individual submission [MLISP] was converted into this IETF LISP | |||
working group draft. | working group draft. | |||
14. References | 15. References | |||
14.1. Normative References | 15.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery | [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery | |||
Protocol (MSDP)", RFC 3618, October 2003. | Protocol (MSDP)", RFC 3618, October 2003. | |||
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous | [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous | |||
Point (RP) Address in an IPv6 Multicast Address", | Point (RP) Address in an IPv6 Multicast Address", | |||
RFC 3956, November 2004. | RFC 3956, November 2004. | |||
skipping to change at page 29, line 39 | skipping to change at page 31, line 39 | |||
IP", RFC 4607, August 2006. | IP", RFC 4607, August 2006. | |||
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | |||
"Multiprotocol Extensions for BGP-4", RFC 4760, | "Multiprotocol Extensions for BGP-4", RFC 4760, | |||
January 2007. | January 2007. | |||
[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. | |||
14.2. Informative References | [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path | |||
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. | ||||
15.2. Informative References | ||||
[ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative | [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative | |||
Topology (LISP-ALT)", draft-fuller-lisp-alt-02.txt (work | Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in | |||
in progress), April 2008. | progress), May 2009. | |||
[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-lewis-lisp-interworking-00.txt | with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt | |||
(work in progress), December 2007. | (work in progress), May 2009. | |||
[JOIN-ATTR] | ||||
Wijnands, IJ. and A. Boers, "Format for using TLVs in PIM | ||||
messages", draft-ietf-pim-join-attributes-03.txt (work in | ||||
progress), May 2007. | ||||
[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-00.txt (work in progress), May 2009. | draft-ietf-lisp-01.txt (work in progress), May 2009. | |||
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, | [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. | |||
[MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace | ||||
Version 2: Traceroute Facility for IP Multicast", | ||||
draft-ietf-mboned-mtrace-v2-03.txt (work in progress), | ||||
March 2009. | ||||
[RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector | [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. | |||
Authors' Addresses | Authors' Addresses | |||
Dino Farinacci | Dino Farinacci | |||
cisco Systems | cisco Systems | |||
Tasman Drive | Tasman Drive | |||
San Jose, CA | San Jose, CA | |||
End of changes. 29 change blocks. | ||||
75 lines changed or deleted | 121 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |