draft-ietf-lisp-signal-free-multicast-02.txt   draft-ietf-lisp-signal-free-multicast-03.txt 
Network Working Group V. Moreno Network Working Group V. Moreno
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental D. Farinacci Intended status: Experimental D. Farinacci
Expires: April 20, 2017 lispers.net Expires: October 14, 2017 lispers.net
October 17, 2016 April 12, 2017
Signal-Free LISP Multicast Signal-Free LISP Multicast
draft-ietf-lisp-signal-free-multicast-02 draft-ietf-lisp-signal-free-multicast-03
Abstract Abstract
When multicast sources and receivers are active at LISP sites, the When multicast sources and receivers are active at LISP sites, the
core network is required to use native multicast so packets can be core network is required to use native multicast so packets can be
delivered from sources to group members. When multicast is not delivered from sources to group members. When multicast is not
available to connect the multicast sites together, a signal-free available to connect the multicast sites together, a signal-free
mechanism can be used to allow traffic to flow between sites. The mechanism can be used to allow traffic to flow between sites. The
mechanism within here uses unicast replication and encapsulation over mechanism within here uses unicast replication and encapsulation over
the core network for the data-plane and uses the LISP mapping the core network for the data-plane and uses the LISP mapping
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 20, 2017. This Internet-Draft will expire on October 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Receiver-site Procedures . . . . . . . . . . . . 8 4.1. General Receiver-Site Procedures . . . . . . . . . . . . 8
4.1.1. Multicast receiver detection . . . . . . . . . . . . 8 4.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8
4.1.2. Receiver-site Registration . . . . . . . . . . . . . 8 4.1.2. Receiver-Site Registration . . . . . . . . . . . . . 8
4.1.3. Consolidation of the replication-list . . . . . . . . 9 4.1.3. Consolidation of the Replication-List . . . . . . . . 9
4.2. General Source-site Procedures . . . . . . . . . . . . . 9 4.2. General Source-Site Procedures . . . . . . . . . . . . . 9
4.2.1. Multicast Tree Building at the Source-site . . . . . 10 4.2.1. Multicast Tree Building at the Source-Site . . . . . 10
4.2.2. Multicast Destination Resolution . . . . . . . . . . 10 4.2.2. Multicast Destination Resolution . . . . . . . . . . 10
4.3. General LISP Notification Procedures . . . . . . . . . . 10 4.3. General LISP Notification Procedures . . . . . . . . . . 10
5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11 5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11
5.1. Source directly connected to Source-ITRs . . . . . . . . 11 5.1. Source Directly Connected to Source-ITRs . . . . . . . . 11
5.2. Source not directly connected to Source-ITRs . . . . . . 12 5.2. Source not Directly Connected to Source-ITRs . . . . . . 12
6. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 12 6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12
7. Signal-Free Multicast for Replication Engineering . . . . . . 13 6.1. Multiple ITRs at a Source-Site . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.2. Multiple ETRs at a Receiver-Site . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.3. Multiple RLOCs for an ETR at a Receiver-Site . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Signal-Free Multicast for Replication Engineering . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
A.3. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 19
A.4. Changes to draft-farinacci-lisp-signal-free-multicast-04 18 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 20
A.5. Changes to draft-farinacci-lisp-signal-free-multicast-03 19 A.1. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 20
A.6. Changes to draft-farinacci-lisp-signal-free-multicast-02 19 A.2. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 20
A.7. Changes to draft-farinacci-lisp-signal-free-multicast-01 19 A.3. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 20
A.8. Changes to draft-farinacci-lisp-signal-free-multicast-00 19 A.4. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 A.5. Changes to draft-farinacci-lisp-signal-free-multicast-04 20
A.6. Changes to draft-farinacci-lisp-signal-free-multicast-03 21
A.7. Changes to draft-farinacci-lisp-signal-free-multicast-02 21
A.8. Changes to draft-farinacci-lisp-signal-free-multicast-01 21
A.9. Changes to draft-farinacci-lisp-signal-free-multicast-00 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
When multicast sources and receivers are active at LISP sites, and When multicast sources and receivers are active at LISP sites, and
the core network between the sites does not provide multicast the core network between the sites does not provide multicast
support, a signal-free mechanism can be used to create an overlay support, a signal-free mechanism can be used to create an overlay
that will allow multicast traffic to flow between sites and connect that will allow multicast traffic to flow between sites and connect
the multicast trees at the different sites. the multicast trees at the different sites.
The signal-free mechanism here proposed does not extend PIM over the The signal-free mechanism here proposed does not extend PIM over the
skipping to change at page 5, line 16 skipping to change at page 5, line 22
traffic to multiple RLOCs. traffic to multiple RLOCs.
Re-encapsulating Tunnel Router (RTR): An RTR is a router that Re-encapsulating Tunnel Router (RTR): An RTR is a router that
implements the re-encapsulating tunnel function detailed in Section 8 implements the re-encapsulating tunnel function detailed in Section 8
of the main LISP specification [RFC6830]. A LISP RTR performs packet of the main LISP specification [RFC6830]. A LISP RTR performs packet
re-routing by chaining ETR and ITR functions, whereby it first re-routing by chaining ETR and ITR functions, whereby it first
removes the LISP header of an ingress packet and then prepends a new removes the LISP header of an ingress packet and then prepends a new
LISP header to an egress packet. LISP header to an egress packet.
RTR Level: An RTR level is encoded in a Replication-List-Entry (RLE) RTR Level: An RTR level is encoded in a Replication-List-Entry (RLE)
LCAF Type detailed in [I-D.ietf-lisp-lcaf]. Each entry in the LCAF Type detailed in [RFC8060]. Each entry in the replication list
replication list contains an address of an xTR and a level value. contains an address of an xTR and a level value. Level values are
Level values are used to create a replication hierarchy so that ITRs used to create a replication hierarchy so that ITRs at source LISP
at source LISP sites replicate to the lowest (smaller value) level sites replicate to the lowest (smaller value) level number RTRs in a
number RTRs in a RLE entry. And then RTRs at a given level replicate RLE entry. And then RTRs at a given level replicate to the next
to the next higher level of RTRs. The number of RTRs at each level higher level of RTRs. The number of RTRs at each level are
are engineered to control the fan-out or replication factor so a engineered to control the fan-out or replication factor so a tradeoff
tradeoff between the width of the level versus the number of levels between the width of the level versus the number of levels can be
can be selected. selected.
3. Reference Model 3. Reference Model
The reference model that will be used for the discussion of the The reference model that will be used for the discussion of the
Signal-Free multicast tree interconnection is illustrated in Signal-Free multicast tree interconnection is illustrated in
Figure 1. Figure 1.
MS/MR MS/MR
+---+ +---+
| | | |
skipping to change at page 8, line 22 skipping to change at page 8, line 22
containing the replication-list for the multicast group containing the replication-list for the multicast group
requested. requested.
5. The Source-ITR caches the replication-list received in the map- 5. The Source-ITR caches the replication-list received in the map-
reply for the multicast-entry. reply for the multicast-entry.
6. Multicast traffic is rep-encapsulated. That is, the packet is 6. Multicast traffic is rep-encapsulated. That is, the packet is
replicated for each RLOC in the replication-list and then replicated for each RLOC in the replication-list and then
encapsulated to each one. encapsulated to each one.
4.1. General Receiver-site Procedures 4.1. General Receiver-Site Procedures
4.1.1. Multicast receiver detection 4.1.1. Multicast Receiver Detection
When the Receiver-ETRs are directly connected to the Receivers (e.g. When the Receiver-ETRs are directly connected to the Receivers (e.g.
Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP
Reports from the Receivers indicating which group the Receivers wish Reports from the Receivers indicating which group the Receivers wish
to subscribe to. Based on these IGMP Reports, the receiver-ETR is to subscribe to. Based on these IGMP Reports, the receiver-ETR is
made aware of the presence of Receivers as well as which group they made aware of the presence of Receivers as well as which group they
are interested in. are interested in.
When the Receiver-ETRs are several hops away from the Receivers (e.g. When the Receiver-ETRs are several hops away from the Receivers (e.g.
Receiver-site-2 in Figure 1), the Receiver-ETRs will receive PIM join Receiver-site-2 in Figure 1), the Receiver-ETRs will receive PIM join
messages which will allow the Receiver-ETR to know that there are messages which will allow the Receiver-ETR to know that there are
multicast Receivers at the site and also learn which multicast group multicast Receivers at the site and also learn which multicast group
the Receivers are for. the Receivers are for.
4.1.2. Receiver-site Registration 4.1.2. Receiver-Site Registration
Once the Receiver-ETRs detect the presence of Receivers at the Once the Receiver-ETRs detect the presence of Receivers at the
Receiver-site, the Receiver-ETRs will issue Map-Register messages to Receiver-site, the Receiver-ETRs will issue Map-Register messages to
include the Receiver-ETR RLOCs in the replication-list for the include the Receiver-ETR RLOCs in the replication-list for the
multicast-entry the Receivers joined. multicast-entry the Receivers joined.
The Map-Register message will use the multicast-entry (Source, Group) The Map-Register message will use the multicast-entry (Source, Group)
tuple as its EID record type with the Receiver-ETR RLOCs conforming tuple as its EID record type with the Receiver-ETR RLOCs conforming
the locator set. the locator set.
The EID in the Map-Register message must be encoded using the The EID in the Map-Register message must be encoded using the
Multicast Information LCAF type defined in [I-D.ietf-lisp-lcaf]. Multicast Information LCAF type defined in [RFC8060].
The RLOC in the Map-Register message must be encoded using the The RLOC in the Map-Register message must be encoded using the
Replication List Entry (RLE) LCAF type defined in Replication List Entry (RLE) LCAF type defined in [RFC8060] with the
[I-D.ietf-lisp-lcaf] with the Level Value fields for all entries set Level Value fields for all entries set to 128 (decimal).
to 128 (decimal).
The encoding described above must be used consistently for Map- The encoding described above must be used consistently for Map-
Register messages, entries in the Mapping Database, Map-reply Register messages, entries in the Mapping Database, Map-reply
messages as well as the map-cache at the Source-ITRs. messages as well as the map-cache at the Source-ITRs.
The Map-Register messages [RFC6830] sent by the receiver-ETRs should The Map-Register messages [RFC6830] sent by the receiver-ETRs should
have the following bits set as here specified: have the following bits set as here specified:
1. merge-request-bit set to 1. The Map-Register messages must be 1. merge-request-bit set to 1. The Map-Register messages must be
sent with "Merge Semantics". The Map-Server will receive sent with "Merge Semantics". The Map-Server will receive
skipping to change at page 9, line 38 skipping to change at page 9, line 37
3. proxy-reply-bit (P) set to 1. The merged replication-list is 3. proxy-reply-bit (P) set to 1. The merged replication-list is
kept in the Map-Servers. By setting the proxy-reply bit, the kept in the Map-Servers. By setting the proxy-reply bit, the
receiver-ETRs instruct the Mapping-system to proxy reply to map- receiver-ETRs instruct the Mapping-system to proxy reply to map-
requests issued for the multicast entries. requests issued for the multicast entries.
Map-Register messages for a particular multicast-entry should be sent Map-Register messages for a particular multicast-entry should be sent
for every receiver detected, even if previous receivers have been for every receiver detected, even if previous receivers have been
detected for the particular multicast-entry. This allows the detected for the particular multicast-entry. This allows the
replication-list to remain up to date. replication-list to remain up to date.
4.1.3. Consolidation of the replication-list 4.1.3. Consolidation of the Replication-List
The Map-Server will receive registrations from a multitude of The Map-Server will receive registrations from a multitude of
Receiver-ETRs. The Map-Server will merge the registrations for Receiver-ETRs. The Map-Server will merge the registrations for
common EIDs and consolidate a replication-list for each multicast- common EIDs and consolidate a replication-list for each multicast-
entry. entry.
4.2. General Source-site Procedures 4.2. General Source-Site Procedures
Source-ITRs must register the unicast EIDs of any Sources or Source-ITRs must register the unicast EIDs of any Sources or
Rendezvous Points that may be present on the Source-site. In other Rendezvous Points that may be present on the Source-site. In other
words, it is assumed that the Sources and RPs are LISP EIDs. words, it is assumed that the Sources and RPs are LISP EIDs.
The registration of the unicast EIDs for the Sources or Rendezvous The registration of the unicast EIDs for the Sources or Rendezvous
Points allows the map-server to know where to send Map-Notify Points allows the map-server to know where to send Map-Notify
messages to. Therefore, the Source-ITR must register the unicast messages to. Therefore, the Source-ITR must register the unicast
S-prefix EID with the want-map-notify-bit set in order to receive S-prefix EID with the want-map-notify-bit set in order to receive
Map-Notify messages whenever there is a change in the replication- Map-Notify messages whenever there is a change in the replication-
list. list.
4.2.1. Multicast Tree Building at the Source-site 4.2.1. Multicast Tree Building at the Source-Site
When the source site receives the Map-Notify messages from the When the source site receives the Map-Notify messages from the
mapping system as described in Section 4.3, it will initiate the mapping system as described in Section 4.3, it will initiate the
process of building a multicast distribution tree that will allow the process of building a multicast distribution tree that will allow the
multicast packets from the Source to reach the Source-ITR. multicast packets from the Source to reach the Source-ITR.
The Source-ITR will issue a PIM join for the multicast-entry for The Source-ITR will issue a PIM join for the multicast-entry for
which it received the Map-Notify message. The join will be issued in which it received the Map-Notify message. The join will be issued in
the direction of the source or in the direction of the RP for the SSM the direction of the source or in the direction of the RP for the SSM
and ASM cases respectively. and ASM cases respectively.
4.2.2. Multicast Destination Resolution 4.2.2. Multicast Destination Resolution
On reception of multicast packets, the source-ITR must obtain the On reception of multicast packets, the source-ITR must obtain the
replication-list for the (S,G) addresses in the packets. replication-list for the (S,G) addresses in the packets.
In order to obtain the replication-list, the Source-ITR must issue a In order to obtain the replication-list, the Source-ITR must issue a
Map-Request message in which the EID is the (S,G) multicast tuple Map-Request message in which the EID is the (S,G) multicast tuple
which is encoded using the Multicast Info LCAF type defined in which is encoded using the Multicast Info LCAF type defined in
[I-D.ietf-lisp-lcaf]. [RFC8060].
The Mapping System (most likely the Map-Server) will Map-reply with The Mapping System (most likely the Map-Server) will Map-reply with
the merged replication-list maintained in the Mapping System. The the merged replication-list maintained in the Mapping System. The
Map-reply message must follow the format defined in [RFC6830], its Map-reply message must follow the format defined in [RFC6830], its
EID must be encoded using the Multicast Info LCAF type and the EID must be encoded using the Multicast Info LCAF type and the
corresponding RLOC-records must be encoded using the RLE LCAF type. corresponding RLOC-records must be encoded using the RLE LCAF type.
Both LCAF types defined in [I-D.ietf-lisp-lcaf]. Both LCAF types defined in [RFC8060].
4.3. General LISP Notification Procedures 4.3. General LISP Notification Procedures
The Map-Server will issue LISP Map-Notify messages to inform the The Map-Server will issue LISP Map-Notify messages to inform the
Source-site of the presence of receivers for a particular multicast Source-site of the presence of receivers for a particular multicast
group over the overlay. group over the overlay.
Updated Map-Notify messages should be issued every time a new Updated Map-Notify messages should be issued every time a new
registration is received from a Receiver-site. This guarantees that registration is received from a Receiver-site. This guarantees that
the source-sites are aware of any potential changes in the multicast- the source-sites are aware of any potential changes in the multicast-
distribution-list membership. distribution-list membership.
The Map-Notify messages carry (S,G) multicast EIDs encoded using the The Map-Notify messages carry (S,G) multicast EIDs encoded using the
Multicast Info LCAF type defined in [I-D.ietf-lisp-lcaf]. Multicast Info LCAF type defined in [RFC8060].
Map-Notify messages will be sent by the Map-Server to the RLOCs with Map-Notify messages will be sent by the Map-Server to the RLOCs with
which the unicast S-prefix EID was registered. In the case when which the unicast S-prefix EID was registered. In the case when
sources are discovered dynamically [I-D.portoles-lisp-eid-mobility], sources are discovered dynamically [I-D.portoles-lisp-eid-mobility],
xTRs must register sources explicitly with the want-map-notify-bit xTRs must register sources explicitly with the want-map-notify-bit
set. This is so the ITR in the site the source has moved to can get set. This is so the ITR in the site the source has moved to can get
the most current replication list. the most current replication list.
When both the Receiver-sites and the Source-sites register to the When both the Receiver-sites and the Source-sites register to the
same Map-Server, the Map-Server has all the necessary information to same Map-Server, the Map-Server has all the necessary information to
skipping to change at page 11, line 39 skipping to change at page 11, line 39
5. Source Specific Multicast Trees 5. Source Specific Multicast Trees
The interconnection of Source Specific Multicast (SSM) Trees across The interconnection of Source Specific Multicast (SSM) Trees across
sites will follow the General Receiver-site Procedures described in sites will follow the General Receiver-site Procedures described in
Section 4.1 on the Receiver-sites. Section 4.1 on the Receiver-sites.
The Source-site Procedures will vary depending on the topological The Source-site Procedures will vary depending on the topological
location of the Source within the Source-site as described in location of the Source within the Source-site as described in
Section 5.1 and Section 5.2 . Section 5.1 and Section 5.2 .
5.1. Source directly connected to Source-ITRs 5.1. Source Directly Connected to Source-ITRs
When the Source is directly connected to the source-ITR, it is not When the Source is directly connected to the source-ITR, it is not
necessary to trigger signaling to build a local multicast tree at the necessary to trigger signaling to build a local multicast tree at the
Source-site. Therefore Map-Notify messages may not be required to Source-site. Therefore Map-Notify messages may not be required to
initiate building of the multicast tree at the Source-site. initiate building of the multicast tree at the Source-site.
Map-Notify messages are still required to ensure that any changes to Map-Notify messages are still required to ensure that any changes to
the replication-list are communicated to the Source-site so that the the replication-list are communicated to the Source-site so that the
map-cache at the Source-ITRs is kept updated. map-cache at the Source-ITRs is kept updated.
5.2. Source not directly connected to Source-ITRs 5.2. Source not Directly Connected to Source-ITRs
The General LISP Notification Procedures described in Section 4.3 The General LISP Notification Procedures described in Section 4.3
must be followed when the Source is not directly connected to the must be followed when the Source is not directly connected to the
source-ITR. On reception of Map-Notify messages, local multicast source-ITR. On reception of Map-Notify messages, local multicast
signaling must be initiated at the Source-site per the General Source signaling must be initiated at the Source-site per the General Source
Site Procedures for Multicast Tree building described in Site Procedures for Multicast Tree building described in
Section 4.2.1. Section 4.2.1.
In the SSM case, the IP address of the Source is known and it is also In the SSM case, the IP address of the Source is known and it is also
registered with the LISP mapping system. Thus, the mapping system registered with the LISP mapping system. Thus, the mapping system
may resolve the mapping for the Source address in order to send Map- may resolve the mapping for the Source address in order to send Map-
Notify messages to the correct source-ITR. Notify messages to the correct source-ITR.
6. PIM Any Source Multicast Trees 6. Multi-Homing Considerations
6.1. Multiple ITRs at a Source-Site
When multiple ITRs exist at a source multicast site, care should be
taken that more than one ITR does not head-end replicate packets else
receiver multicast sites will receive duplicate packets. The
following procedures will be used for each topology scenarios:
o When more than one ITR is directly connected to the source host,
either the PIM DR or the IGMP querier (when PIM is not enabled on
the ITRs) is responsible for packet replication. All other ITRs
silently drop the packet. In the IGMP querier case, it is
required to configure the source LAN to have one of the ITRs be
the IGMP querier.
o When more than one ITR is multiple hops away from the source host
and one of the ITRs is the PIM Rendezvous Point, then the PIM RP
is responsible for packet replication.
o When more than one ITR is multiple hops away from the source host
and the PIM Rendezvous Point is not one of the ITRs, then one of
the ITRs must join to the RP. When a Map-Notify is received from
the Map-Server by an ITR, only the highest RLOC addressed ITR will
join toward the PIM RP or toward the source.
6.2. Multiple ETRs at a Receiver-Site
When multiple ETRs exist in a receiver multicast site, and each
create multicast join state, they each Map-Register their RLOC
addresses to the mapping system. In this scenario, the replication
happens on the overlay causing multiple ETR entry points to replicate
to all receivers versus a single ETR entry point replicating to all
receivers. If an ETR does not create join state, because it has not
received PIM joins or IGMP reports, it will not Map-Register its RLOC
addresses to the mapping system. The same procedures in Section 4.1
should be followed.
When multiple ETRs exist on the same LAN as a receiver host, then the
PIM DR, when PIM is enabled, or the IGMP querier is responsible for
sending a Map-Register for its RLOC. In the IGMP case, it is
required that the LAN is configured with one of the ETRs as IGMP
querier.
6.3. Multiple RLOCs for an ETR at a Receiver-Site
It may be desirable to have multiple underlay paths to an ETR for
multicast packet delivery. This can be done by having multiple RLOCs
assigned to an ETR and having the ETR send Map-Registers for all its
RLOCs. By doing this, an ITR can choose a specific path based on
underlay performance and/or RLOC reachability.
It is suggested that an ETR sends a Map-Register with a single RLOC-
record that uses the ELP LCAF type [RFC8060] that is nested inside
RLE entry LCAF. For example say ETR1 has assigned RLOC1 and RLOC2
for a LISP receiver site. And there is ETR2 in another LISP receiver
site, that has RLOC3. The two receiver sites have the same (S,G)
being joined. Here is how the RLOC-record is encoded on each ETR:
ETR1: EID-record: (S,G)
RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
ETR2: EID-record: (S,G)
RLOC-record: RLE[ RLOC3 ]
And here is how the entry is merged and stored on the Map-Server
since the Map-Registers have an RLE encoded RLOC-record:
MS: EID-record: (S,G)
RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
When the ITR receives a packet from a multicast source S for group G,
it uses the merged RLOC-record, returned from the Map-Server. The
ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2).
Since it is required for the s-bit to be set for RLOC1, the ITR must
replicate to RLOC1 if it is reachable. When the required p-bit is
also set, the RLOC-reachability mechanisms from [RFC6830] are
followed. If the ITR determines that RLOC1 is unreachable, it uses
RLOC2, as long as RLOC2 is reachable.
7. PIM Any Source Multicast Trees
LISP signal-free multicast can support ASM Trees in limited but LISP signal-free multicast can support ASM Trees in limited but
acceptable topologies. It is suggested for the simplification of acceptable topologies. It is suggested for the simplification of
building ASM trees across the LISP overlay to have PIM-ASM run building ASM trees across the LISP overlay to have PIM-ASM run
independently in each LISP site. What this means, is that a PIM independently in each LISP site. What this means, is that a PIM
Rendezvous Point (RP) is configured in each LISP site so PIM Register Rendezvous Point (RP) is configured in each LISP site so PIM Register
procedures and (*,G) state maintenance is contained within the LISP procedures and (*,G) state maintenance is contained within the LISP
site. site.
The following procedure will be used to support ASM in each LISP The following procedure will be used to support ASM in each LISP
skipping to change at page 13, line 15 skipping to change at page 15, line 5
6. The ITR stores the replication-list in its map-cache for (S,G). 6. The ITR stores the replication-list in its map-cache for (S,G).
It replicates packets to all ETRs in the list. It replicates packets to all ETRs in the list.
7. ETRs decapsulate packets and forward based on (*,G) state in 7. ETRs decapsulate packets and forward based on (*,G) state in
their site. their site.
8. When last-hop PIM routers join the newly discovered (S,G), the 8. When last-hop PIM routers join the newly discovered (S,G), the
ETR will store the state and follow the procedures in ETR will store the state and follow the procedures in
Section 4.1.2. Section 4.1.2.
7. Signal-Free Multicast for Replication Engineering 8. Signal-Free Multicast for Replication Engineering
The mechanisms in this draft can be applied to the LISP Replication- The mechanisms in this draft can be applied to the LISP Replication-
Engineering [I-D.coras-lisp-re] design. Rather than having the Engineering [I-D.coras-lisp-re] design. Rather than having the
layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can
register their availability for multicast tree replication via the register their availability for multicast tree replication via the
mapping database system. As stated in [I-D.coras-lisp-re], the RTR mapping database system. As stated in [I-D.coras-lisp-re], the RTR
layered hierarchy is used to avoid head-end replication in layered hierarchy is used to avoid head-end replication in
replicating nodes closest to a multicast source. Rather than have replicating nodes closest to a multicast source. Rather than have
multicast ITRs replicate to each ETR in an RLE entry of a (S,G) multicast ITRs replicate to each ETR in an RLE entry of a (S,G)
mapping database entry, it could replicate to one or more layer-0 mapping database entry, it could replicate to one or more layer-0
skipping to change at page 15, line 48 skipping to change at page 17, line 39
used by level-n RTRs to level-n+1 RTRs. used by level-n RTRs to level-n+1 RTRs.
The following mapping would be encoded in a Map-Reply sent by a Map- The following mapping would be encoded in a Map-Reply sent by a Map-
Server and stored in the ITR. The ITR would use RTR1 until it went Server and stored in the ITR. The ITR would use RTR1 until it went
unreachable and then switch to use RTR2: unreachable and then switch to use RTR2:
EID-record: (S,G) EID-record: (S,G)
RLOC-record: RTR1, p1 RLOC-record: RTR1, p1
RLOC-record: RTR2, p2 RLOC-record: RTR2, p2
8. Security Considerations 9. Security Considerations
[I-D.ietf-lisp-sec] defines a set of security mechanisms that provide [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide
origin authentication, integrity and anti-replay protection to LISP's origin authentication, integrity and anti-replay protection to LISP's
EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-
SEC also enables verification of authorization on EID-prefix claims SEC also enables verification of authorization on EID-prefix claims
in Map-Reply messages. in Map-Reply messages.
Additional security mechanisms to protect the LISP Map-Register Additional security mechanisms to protect the LISP Map-Register
messages are defined in [RFC6833]. messages are defined in [RFC6833].
The security of the Mapping System Infrastructure depends on the The security of the Mapping System Infrastructure depends on the
particular mapping database used. The [I-D.ietf-lisp-ddt] particular mapping database used. The [I-D.ietf-lisp-ddt]
specification, as an example, defines a public-key based mechanism specification, as an example, defines a public-key based mechanism
that provides origin authentication and integrity protection to the that provides origin authentication and integrity protection to the
LISP DDT protocol. LISP DDT protocol.
Map-Replies received by the source-ITR can be signed (by the Map- Map-Replies received by the source-ITR can be signed (by the Map-
Server) so the ITR knows the replication-list is from a legit source. Server) so the ITR knows the replication-list is from a legit source.
Data-plane encryption can be used when doing unicast rep- Data-plane encryption can be used when doing unicast rep-
encapsulation as described in [I-D.ietf-lisp-crypto]. For further encapsulation as described in [RFC8061]. For further study we will
study we will look how to do multicast rep-encapsulation. look how to do multicast rep-encapsulation.
9. IANA Considerations 10. IANA Considerations
This document has no IANA implications This document has no IANA implications
10. Acknowledgements 11. Acknowledgements
The authors want to thank Greg Shepherd, Joel Halpern and Sharon The authors want to thank Greg Shepherd, Joel Halpern and Sharon
Barkai for their insightful contribution to shaping the ideas in this Barkai for their insightful contribution to shaping the ideas in this
document. Thanks also goes to Jimmy Kyriannis, Paul Vinciguerra, and document. Thanks also goes to Jimmy Kyriannis, Paul Vinciguerra,
Florin Coras for testing an implementation of this draft. Florin Coras, and Yan Filyurin for testing an implementation of this
draft.
11. References 12. References
11.1. Normative References 12.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003, DOI 10.17487/RFC3618, October 2003,
<http://www.rfc-editor.org/info/rfc3618>. <http://www.rfc-editor.org/info/rfc3618>.
skipping to change at page 17, line 15 skipping to change at page 19, line 5
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006, DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>. <http://www.rfc-editor.org/info/rfc4601>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://www.rfc-editor.org/info/rfc4607>. <http://www.rfc-editor.org/info/rfc4607>.
11.2. Informative References 12.2. Informative References
[I-D.coras-lisp-re] [I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-08 (work in progress), Engineering", draft-coras-lisp-re-08 (work in progress),
November 2015. November 2015.
[I-D.farinacci-lisp-mr-signaling] [I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06
(work in progress), February 2015. (work in progress), February 2015.
[I-D.ietf-lisp-crypto]
Farinacci, D. and B. Weis, "LISP Data-Plane
Confidentiality", draft-ietf-lisp-crypto-10 (work in
progress), October 2016.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-08 (work in progress), September 2016. ddt-09 (work in progress), January 2017.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-18 (work in
progress), October 2016.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-11 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), October 2016. (work in progress), November 2016.
[I-D.portoles-lisp-eid-mobility] [I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid- Unified Control Plane", draft-portoles-lisp-eid-
mobility-01 (work in progress), October 2016. mobility-02 (work in progress), April 2017.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <http://www.rfc-editor.org/info/rfc6831>. 2013, <http://www.rfc-editor.org/info/rfc6831>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>. <http://www.rfc-editor.org/info/rfc6833>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <http://www.rfc-editor.org/info/rfc8060>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<http://www.rfc-editor.org/info/rfc8061>.
Appendix A. Document Change Log Appendix A. Document Change Log
A.1. Changes to draft-ietf-lisp-signal-free-multicast-02 A.1. Changes to draft-ietf-lisp-signal-free-multicast-03
o Posted April 2017.
o Add "Multi-Homing Considerations" section to describe the case
where a source LISP site has multiple ITRs and the multicast
distribution tree at the source site branches to more than one
ITR. And at receiver sites where there are multiple ETRs and
multiple RLOCs per ETR.
A.2. Changes to draft-ietf-lisp-signal-free-multicast-02
o Posted October 2016. o Posted October 2016.
o Updated document expiration timer. o Updated document expiration timer.
A.2. Changes to draft-ietf-lisp-signal-free-multicast-01 A.3. Changes to draft-ietf-lisp-signal-free-multicast-01
o Posted April 2016. o Posted April 2016.
o Add text to define RTRs and indicate how RTR level number is used o Add text to define RTRs and indicate how RTR level number is used
for LISP-RE. for LISP-RE.
o Draw figure 2 that shows a LISP-RE topology. o Draw figure 2 that shows a LISP-RE topology.
o Indicate that PIM-ASM or (*,G) trees can be supported in LISP o Indicate that PIM-ASM or (*,G) trees can be supported in LISP
Signal-Free Multicast. Signal-Free Multicast.
A.3. Changes to draft-ietf-lisp-signal-free-multicast-00 A.4. Changes to draft-ietf-lisp-signal-free-multicast-00
o Posted late December 2015. o Posted late December 2015.
o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP
working group draft. working group draft.
A.4. Changes to draft-farinacci-lisp-signal-free-multicast-04 A.5. Changes to draft-farinacci-lisp-signal-free-multicast-04
o Posted early December 2015. o Posted early December 2015.
o Update references and document timer. o Update references and document timer.
A.5. Changes to draft-farinacci-lisp-signal-free-multicast-03 A.6. Changes to draft-farinacci-lisp-signal-free-multicast-03
o Posted June 2015. o Posted June 2015.
o Update references and document timer. o Update references and document timer.
A.6. Changes to draft-farinacci-lisp-signal-free-multicast-02 A.7. Changes to draft-farinacci-lisp-signal-free-multicast-02
o Posted December 2014. o Posted December 2014.
o Added section about how LISP-RE can use the mechanisms from o Added section about how LISP-RE can use the mechanisms from
signal-free-multicast so we can avoid head-end replication and signal-free-multicast so we can avoid head-end replication and
avoid signalling across a layered RE topology. avoid signalling across a layered RE topology.
A.7. Changes to draft-farinacci-lisp-signal-free-multicast-01 A.8. Changes to draft-farinacci-lisp-signal-free-multicast-01
o Posted June 2014. o Posted June 2014.
o Changes based on implementation experience of this draft. o Changes based on implementation experience of this draft.
A.8. Changes to draft-farinacci-lisp-signal-free-multicast-00 A.9. Changes to draft-farinacci-lisp-signal-free-multicast-00
o Posted initial draft February 2014. o Posted initial draft February 2014.
Authors' Addresses Authors' Addresses
Victor Moreno Victor Moreno
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
 End of changes. 43 change blocks. 
89 lines changed or deleted 183 lines changed or added

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