draft-ietf-lisp-signal-free-multicast-09.txt   rfc8378.txt 
Network Working Group V. Moreno Internet Engineering Task Force (IETF) V. Moreno
Internet-Draft Cisco Systems Request for Comments: 8378 Cisco Systems
Intended status: Experimental D. Farinacci Category: Experimental D. Farinacci
Expires: September 9, 2018 lispers.net ISSN: 2070-1721 lispers.net
March 8, 2018 May 2018
Signal-Free LISP Multicast Signal-Free Locator/ID Separation Protocol (LISP) Multicast
draft-ietf-lisp-signal-free-multicast-09
Abstract Abstract
When multicast sources and receivers are active at LISP sites, the When multicast sources and receivers are active at Locator/ID
core network is required to use native multicast so packets can be Separation Protocol (LISP) sites, the core network is required to use
delivered from sources to group members. When multicast is not native multicast so packets can be delivered from sources to group
available to connect the multicast sites together, a signal-free members. When multicast is not available to connect the multicast
mechanism can be used to allow traffic to flow between sites. The sites together, a signal-free mechanism can be used to allow traffic
mechanism within here uses unicast replication and encapsulation over to flow between sites. The mechanism described in this document uses
the core network for the data-plane and uses the LISP mapping unicast replication and encapsulation over the core network for the
database system so encapsulators at the source LISP multicast site data plane and uses the LISP mapping database system so encapsulators
can find decapsulators at the receiver LISP multicast sites. at the source LISP multicast site can find decapsulators at the
receiver LISP multicast sites.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on September 9, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8378.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Receiver-Site Procedures . . . . . . . . . . . . 8 5. General Procedures . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8 5.1. General Receiver-Site Procedures . . . . . . . . . . . . 8
4.1.2. Receiver-Site Registration . . . . . . . . . . . . . 8 5.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8
4.1.3. Consolidation of the Replication-List . . . . . . . . 9 5.1.2. Receiver-Site Registration . . . . . . . . . . . . . 9
4.2. General Source-Site Procedures . . . . . . . . . . . . . 10 5.1.3. Consolidation of the Replication List . . . . . . . . 10
4.2.1. Multicast Tree Building at the Source-Site . . . . . 10 5.2. General Source-Site Procedures . . . . . . . . . . . . . 10
4.2.2. Multicast Destination Resolution . . . . . . . . . . 10 5.2.1. Multicast Tree Building at the Source Site . . . . . 10
4.3. General LISP Notification Procedures . . . . . . . . . . 11 5.2.2. Multicast Destination Resolution . . . . . . . . . . 11
5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11 5.3. General LISP Notification Procedures . . . . . . . . . . 11
5.1. Source Directly Connected to Source-ITRs . . . . . . . . 12 6. Source-Specific Multicast Trees . . . . . . . . . . . . . . . 12
5.2. Source not Directly Connected to Source-ITRs . . . . . . 12 6.1. Source Directly Connected to Source-ITRs . . . . . . . . 12
6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12 6.2. Source Not Directly Connected to Source-ITRs . . . . . . 12
6.1. Multiple ITRs at a Source-Site . . . . . . . . . . . . . 12 7. Multihoming Considerations . . . . . . . . . . . . . . . . . 13
6.2. Multiple ETRs at a Receiver-Site . . . . . . . . . . . . 13 7.1. Multiple ITRs at a Source Site . . . . . . . . . . . . . 13
6.3. Multiple RLOCs for an ETR at a Receiver-Site . . . . . . 13 7.2. Multiple ETRs at a Receiver Site . . . . . . . . . . . . 13
6.4. Multicast RLOCs for an ETR at a Receiver-Site . . . . . . 14 7.3. Multiple RLOCs for an ETR at a Receiver Site . . . . . . 14
7. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 14 7.4. Multicast RLOCs for an ETR at a Receiver Site . . . . . . 14
8. Signal-Free Multicast for Replication Engineering . . . . . . 15 8. PIM Any-Source Multicast Trees . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Signal-Free Multicast for Replication Engineering . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Changes to draft-ietf-lisp-signal-free-multicast-09 . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Changes to draft-ietf-lisp-signal-free-multicast-08 . . . 21
A.3. Changes to draft-ietf-lisp-signal-free-multicast-07 . . . 21
A.4. Changes to draft-ietf-lisp-signal-free-multicast-06 . . . 21
A.5. Changes to draft-ietf-lisp-signal-free-multicast-05 . . . 21
A.6. Changes to draft-ietf-lisp-signal-free-multicast-04 . . . 22
A.7. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 22
A.8. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 22
A.9. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 22
A.10. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 23
A.11. Changes to draft-farinacci-lisp-signal-free-multicast-04 23
A.12. Changes to draft-farinacci-lisp-signal-free-multicast-03 23
A.13. Changes to draft-farinacci-lisp-signal-free-multicast-02 23
A.14. Changes to draft-farinacci-lisp-signal-free-multicast-01 23
A.15. Changes to draft-farinacci-lisp-signal-free-multicast-00 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 proposed here does not extend PIM [RFC7761] The signal-free mechanism proposed here does not extend PIM [RFC7761]
over the overlay as proposed in [RFC6831], nor does the mechanism over the overlay as proposed in [RFC6831], nor does the mechanism
utilize direct signaling between the Receiver-ETRs and Sender-ITRs as utilize direct signaling between the Receiver-ETRs and Sender-ITRs as
described in [I-D.farinacci-lisp-mr-signaling]. The signal-free described in [LISP-MULTI-SIGNALING]. The signal-free mechanism
mechanism proposed reduces the amount of signaling required between proposed reduces the amount of signaling required between sites to a
sites to a minimum and is centered around the registration of minimum and is centered around the registration of receiver sites for
Receiver-sites for a particular multicast-group or multicast-channel a particular multicast group or multicast channel with the LISP
with the LISP Mapping System. mapping system.
Registrations from the different receiver-sites will be merged at the Registrations from the different receiver sites will be merged at the
Mapping System to assemble a multicast-replication-list inclusive of mapping system to assemble a multicast-replication-list inclusive of
all RLOCs that lead to receivers for a particular multicast-group or all Routing Locators (RLOCs) that lead to receivers for a particular
multicast-channel. The replication-list for each specific multicast- multicast group or multicast channel. The replication list for each
entry is maintained as a database mapping entry in the LISP Mapping specific multicast entry is maintained as a database mapping entry in
System. the LISP mapping system.
When the ITR at the source-site receives multicast traffic from When the Ingress Tunnel Router (ITR) at the source site receives
sources at its site, the ITR can query the mapping system by issuing multicast traffic from sources at its site, the ITR can query the
Map-Request messages for the (S,G) source and destination addresses mapping system by issuing Map-Request messages for the (S,G) source
in the packets received. The Mapping System will return the RLOC and destination addresses in the packets received. The mapping
replication-list to the ITR, which the ITR will cache as per standard system will return the RLOC replication list to the ITR, which the
LISP procedure. Since the core is assumed to not support multicast, ITR will cache as per standard LISP procedure. Since the core is
the ITR will replicate the multicast traffic for each RLOC on the assumed to not support multicast, the ITR will replicate the
replication-list and will unicast encapsulate the traffic to each multicast traffic for each RLOC on the replication list and will
RLOC. The combined function or replicating and encapsulating the unicast encapsulate the traffic to each RLOC. The combined function
traffic to the RLOCs in the replication-list is referred to as "rep- or replicating and encapsulating the traffic to the RLOCs in the
encapsulation" in this document. replication list is referred to as "rep-encapsulation" in this
document.
The document describes the General Procedures (Section 4) and The document describes general procedures (Section 5) and information
information encoding that are required at the Receiver-sites and encoding that are required at the receiver sites and source sites to
Source-sites to achieve signal-free multicast interconnectivity. The achieve signal-free multicast interconnectivity. The general
General Procedures for Mapping System Notifications to different procedures for mapping system notifications to different sites are
sites are also described. A section dedicated to the specific case also described. A section dedicated to the specific case of Source-
of SSM trees discusses the implications to the General Procedures for Specific Multicast (SSM) trees discusses the implications to the
SSM multicast trees over different topological scenarios. A section general procedures for SSM multicast trees over different topological
on ASM support is included to identify the constraints that come scenarios. A section on Any-Source Multicast (ASM) support is
along with supporting it using LISP Signal-Free multicast. included to identify the constraints that come along with supporting
it using LISP signal-free multicast.
There is a section dedicated to Replication Engineering. A mechanism There is a section dedicated to Replication Engineering, which is a
to reduce the impact of head-end replication. The mapping system, mechanism to reduce the impact of head-end replication. The mapping
via LISP Signal-Free mechanisms, can be used to build a layer of system, via LISP signal-free mechanisms, can be used to build a layer
RTRs. of Re-encapsulating Tunnel Routers (RTRs).
2. Definition of Terms 2. Definition of Terms
LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel LISP-related terms, notably Map-Request, Map-Reply, Ingress Tunnel
Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and
Resolver (MR) are defined in the LISP specification [RFC6830]. Map-Resolver (MR) are defined in the LISP specification [RFC6830].
Extensions to the definitions in [RFC6830] for their application to Extensions to the definitions in [RFC6830] for their application to
multicast routing are documented in [RFC6831]. multicast routing are documented in [RFC6831].
Terms defining interactions with the LISP Mapping System are defined Terms defining interactions with the LISP mapping system are defined
in [RFC6833]. in [RFC6833].
The following terms are consistent with the definitions in [RFC6830] The following terms are consistent with the definitions in [RFC6830]
and [RFC6831]. The terms are specific cases of the general terms and and [RFC6831]. The terms are specific cases of the general terms and
are here defined to facilitate the descriptions and discussions are defined here to facilitate the descriptions and discussions
within this particular document. within this particular document.
Source: Multicast source end-point. Host originating multicast Source: Multicast source endpoint. The host that originates
packets. multicast packets.
Receiver: Multicast group member end-point. Host joins multicast Receiver: Multicast group member endpoint. The host joins a
group as a receiver of multicast packets sent to the group. multicast group as a receiver of multicast packets sent to the group.
Receiver-site: LISP site where multicast receivers are located. Receiver site: LISP site where multicast receivers are located.
Source-site: LISP site where multicast sources are located. Source site: LISP site where multicast sources are located.
RP-site: LISP site where an ASM PIM Rendezvous Point [RFC7761] is RP site: LISP site where an ASM PIM Rendezvous Point (RP) [RFC7761]
located. The RP-site and the Source-site MAY be the same in some is located. The RP site and the source site MAY be the same in some
situations. situations.
Receiver-ETR: LISP decapsulating xTR at the Receiver-site. This is a Receiver-ETR: LISP decapsulating the Tunnel Router (xTR) at the
multicast ETR. receiver site. This is a multicast ETR.
Source-ITR: LISP encapsulating xTR at the Source-site. This is a Source-ITR: LISP encapsulating xTR at the source site. This is a
multicast ITR. multicast ITR.
RP-xTR: LISP xTR at the RP-site. This is typically a multicast ITR. RP-xTR: LISP xTR at the RP site. This is typically a multicast ITR.
Replication-list: Mapping-entry containing the list of RLOCs that Replication list: Mapping-entry containing the list of RLOCs that
have registered Receivers for a particular multicast-entry. have registered receivers for a particular multicast entry.
Multicast-entry: A tuple identifying a multicast tree. Multicast- Multicast entry: A tuple identifying a multicast tree. Multicast
entries are in the form of (S-prefix, G-prefix). entries are in the form of (S-prefix, G-prefix).
Rep-encapsulation: The process of replicating and then encapsulating Rep-encapsulation: The process of replicating and then encapsulating
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 [RFC8060]. Each entry in the replication list LISP Canonical Address Format (LCAF) Type detailed in [RFC8060].
contains an address of an xTR and a level value. Level values are Each entry in the replication list contains an address of an xTR and
used to create a replication hierarchy so that ITRs at source LISP a level value. Level values are used to create a replication
sites replicate to the lowest (smaller value) level number RTRs in a hierarchy so that ITRs at source LISP sites replicate to the lowest
RLE entry. And then RTRs at a given level replicate to the next (smaller value) level number RTRs in an RLE. And then RTRs at a
higher level of RTRs. The number of RTRs at each level are given level replicate to the next higher level of RTRs. The number
engineered to control the fan-out or replication factor so a tradeoff of RTRs at each level are engineered to control the fan-out or
between the width of the level versus the number of levels can be replication factor, so a trade-off between the width of the level
selected. versus the number of levels can be selected.
ASM: Any-Source Multicast as defined in [RFC3569] and [RFC7761] where ASM: Any-Source Multicast as defined in [RFC3569] where multicast
multicast distribution trees are built with a Rendezvous Point. distribution trees are built with a Rendezvous Point [RFC7761].
SSM: Source Specific Multicast as defined in [RFC3569] where SSM: Source-Specific Multicast as defined in [RFC3569] where
multicast distribution trees are built and rooted at the multicast multicast distribution trees are built and rooted at the multicast
router(s) directly connected to the multicast source. router(s) directly connected to the multicast source.
3. Reference Model 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. 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
+---+ +---+
| | | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Src-1 ----| R1|-----|ITR| | |ETR|------| R2|------ Rcv-2 Src-1 ----| R1|-----|ITR| | |ETR|------| R2|----- Rcv-2
+---+ +---+ | +---+ +---+ +---+ +---+ | +---+ +---+
\ | / \ | /
Source-site-1 \ | / Receiver-site-2 Source-site-1 \ | / Receiver-site-2
\ | / \ | /
\ | / \ | /
\ | / \ | /
Core Core
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
Src-3 --------------|ITR| |ETR|----------------- Rcv-4 Src-3 --------------|ITR| |ETR|---------------- Rcv-4
+---+ +---+ +---+ +---+
Source-site-3 Receiver-site-4 Source-site-3 Receiver-site-4
Figure 1: LISP Multicast Generic Reference Model Figure 1: LISP Multicast Generic Reference Model
Sites 1 and 3 are Source-sites. Sites 1 and 3 are source sites.
Source-site-3 presents a Source (Src-3) that is directly connected to Source-site-3 presents a source (Src-3) that is directly connected to
the Source-ITR the Source-ITR.
Source-site-1 presents a Source (Src-1) that is one hop or more away Source-site-1 presents a source (Src-1) that is one hop or more away
from the Source-ITR from the Source-ITR.
Receiver-site-2 and 4 are receiver sites with not-directly connected Receiver-site-2 and -4 are receiver sites with not-directly connected
and directly connected Receiver end-points respectively and directly connected receiver endpoints, respectively.
R1 is a multicast router in Source-site-1. R1 is a multicast router in Source-site-1.
R2 is a multicast router at the Receiver-site. R2 is a multicast router at the receiver site.
The Map-Servers and Resolvers are reachable in the RLOC space in the Map-Servers and Map-Resolvers are reachable in the RLOC space in the
Core, only one is shown for illustration purposes, but these can be core; only one is shown for illustration purposes, but these can be
many or even part of a Distributed Mapping System, such as a DDT many or even part of a distributed mapping system, such as a
Tree. Delegated Database Tree (DDT).
The procedures for interconnecting multicast Trees over an overlay The procedures for interconnecting multicast trees over an overlay
can be broken down into three functional areas: can be broken down into three functional areas:
o Receiver-site procedures o Receiver-site procedures
o Source-site procedures o Source-site procedures
o LISP notification procedures o LISP notification procedures
The receiver site procedures will be common for most tree types and The receiver-site procedures will be common for most tree types and
topologies. topologies.
The procedures at the source site can vary depending on the type of The procedures at the source site can vary depending on the type of
trees being interconnected as well as based on the topological trees being interconnected as well as the topological relation
relation between sources and source-site xTRs. For ASM trees, a between sources and source-site xTRs. For ASM trees, a special case
special case of the Source-site is the RP-site for which a variation of the source site is the RP site for which a variation of the
of the Source-site procedures MAY be necessary if ASM trees are to be source-site procedures MAY be necessary if ASM trees are to be
supported in future specifications of LISP Signal-Free multicast. supported in future specifications of LISP signal-free multicast.
The LISP notification procedures between sites are normalized for the The LISP notification procedures between sites are normalized for the
different possible scenarios. Certain scenarios MAY benefit from a different possible scenarios. Certain scenarios MAY benefit from a
simplified notification mechanism or no notification requirement at simplified notification mechanism or no notification requirement at
all. all.
4. General Procedures 5. General Procedures
The interconnection of multicast trees across different LISP sites The interconnection of multicast trees across different LISP sites
involves the following procedures to build the necessary multicast involves the following procedures to build the necessary multicast
distribution trees across sites. distribution trees across sites.
1. The presence of multicast Receiver end-points is detected by the 1. The presence of multicast receiver endpoints is detected by the
Receiver-ETRs at the Receiver-sites. Receiver-ETRs at the receiver sites.
2. Receiver-ETRs register their RLOCs as part of the replication- 2. Receiver-ETRs register their RLOCs as part of the replication
list for the multicast-entry the detected Receivers subscribe to. list for the multicast entry the detected receivers subscribe to.
3. The Mapping-system merges all receiver-ETR or delivery-group 3. The mapping system merges all Receiver-ETR or delivery-group
RLOCs to build a comprehensive replication-list inclusive of all RLOCs to build a comprehensive replication list inclusive of all
Receiver-sites for each multicast-entry. receiver sites for each multicast entry.
4. LISP Map-Notify messages MUST be sent to the Source-ITR informing 4. LISP Map-Notify messages MUST be sent to the Source-ITR informing
of any changes in the replication-list. of any changes in the replication list.
5. Multicast-tree building at the Source-site is initiated when the 5. Multicast tree building at the source site is initiated when the
Source-ITR receives the LISP Notification. Source-ITR receives the LISP notification.
Once the multicast distribution trees are built, the following Once the multicast distribution trees are built, the following
forwarding procedures may take place: forwarding procedures may take place:
1. The Source sends multicast packets to the multicast group 1. The source sends multicast packets to the multicast group
destination address. destination address.
2. Multicast traffic follows the multicast tree built at the Source- 2. Multicast traffic follows the multicast tree built at the source
site and makes its way to the Source-ITRs. site and makes its way to the Source-ITRs.
3. The Source-ITR will issue a map-request to resolve the 3. The Source-ITR will issue a Map-Request to resolve the
replication-list for the multicast-entry. replication list for the multicast entry.
4. The Mapping System responds to the Source-ITR with a map-reply 4. The mapping system responds to the Source-ITR with a Map-Reply
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
reply for the multicast-entry. map-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 5.1. General Receiver-Site Procedures
4.1.1. Multicast Receiver Detection 5.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
Receiver-site-2 in Figure 1), the Receiver-ETRs will receive PIM join (e.g., Receiver-site-2 in Figure 1), the Receiver-ETRs will receive
messages which will allow the Receiver-ETR to know that there are PIM join messages, which will allow the Receiver-ETR to know that
multicast Receivers at the site and also learn which multicast group there are multicast receivers at the site and also to learn which
the Receivers are for. multicast group the receivers are for.
4.1.2. Receiver-Site Registration 5.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 MUST issue Map-Register messages to receiver site, the Receiver-ETRs MUST 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 MUST use the multicast-entry (Source, Group) The Map-Register message MUST use the multicast entry (Source, Group)
tuple as its EID record type with the Receiver-ETR RLOCs conforming tuple as its Endpoint ID (EID) record type with the Receiver-ETR
the locator set. RLOCs conforming 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 [RFC8060]. Multicast Info 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 RLE
Replication List Entry (RLE) LCAF type defined in [RFC8060] with the LCAF Type defined in [RFC8060] with the Level Value fields for all
Level Value fields for all entries set to 128 (decimal). entries set 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 System, Map-reply messages Register messages, entries in the mapping system, Map-Reply messages,
as well as the map-cache at the Source-ITRs. as well as the map-cache at the Source-ITRs.
The Map-Register messages [RFC6830] sent by the receiver-ETRs MUST The Map-Register messages [RFC6830] sent by the Receiver-ETRs MUST
have the following bits set as here specified: have the following bits set as specified here:
1. merge-request-bit set to 1. The Map-Register messages are sent 1. merge-request bit set to 1. The Map-Register messages are sent
with "Merge Semantics". The Map-Server will receive with "Merge Semantics". The Map-Server will receive
registrations from a multitude of Receiver-ETRs. The Map-Server registrations from a multitude of Receiver-ETRs. The Map-Server
will merge the registrations for common EIDs and maintain a will merge the registrations for common EIDs and maintain a
consolidated replication-list for each multicast-entry. consolidated replication list for each multicast entry.
2. want-map-notify-bit (M) set to 0. This tells the Mapping System 2. want-map-notify bit (M) set to 0. This tells the mapping system
that the receiver-ETR does not expect to receive Map-Notify that the Receiver-ETR does not expect to receive Map-Notify
messages as it does not need to be notified of all changes to the messages as it does not need to be notified of all changes to the
replication-list. replication list.
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 MAY be sent Map-Register messages for a particular multicast entry MAY 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.
Receiver-ETRs MUST be configured to know what Map-Servers Map- Receiver-ETRs MUST be configured to know what Map-Servers Map-
Register messages are sent to. The configuration is likely to be Register messages are sent to. The configuration is likely to be
associated with an S-prefix that multiple (S,G) entries match to and associated with an S-prefix that multiple (S,G) entries match to and
are more specific for. Therefore, the S-prefix determines the Map- are more specific for. Therefore, the S-prefix determines the Map-
Server set in the least number of configuration statements. Server set in the least number of configuration statements.
4.1.3. Consolidation of the Replication-List 5.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.
When an ETR sends an RLE RLOC-record in a Map-Register and the RLE When an ETR sends an RLE RLOC-record in a Map-Register and the RLE
entry already exists in the Map-Server's RLE merged list, the Map- already exists in the Map-Server's RLE-merged list, the Map-Server
Server will replace the single RLE entry with the information from will replace the single RLE with the information from the Map-
the Map-Register RLOC-record. The Map-Server MUST NOT merge Register RLOC-record. The Map-Server MUST NOT merge duplicate RLOCs
duplicate RLOCs in the consolidated replication-list. in the consolidated replication list.
4.2. General Source-Site Procedures 5.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 5.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 5.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 MUST issue a PIM join for the multicast-entry for The Source-ITR MUST 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 5.2.2. Multicast Destination Resolution
On reception of multicast packets, the source-ITR obtains the On reception of multicast packets, the Source-ITR obtains 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
[RFC8060]. [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 is encoded using the Multicast Info LCAF type and the EID is encoded using the Multicast Info LCAF Type, and the
corresponding RLOC-records are encoded using the RLE LCAF type. Both corresponding RLOC-records are encoded using the RLE LCAF Type. Both
LCAF types defined in [RFC8060]. LCAF Types are defined in [RFC8060].
4.3. General LISP Notification Procedures 5.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 [RFC8060]. 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.ietf-lisp-eid-mobility], xTRs sources are discovered dynamically [LISP-EID-MOBILITY], xTRs MUST
MUST register sources explicitly with the want-map-notify-bit set. register sources explicitly with the want-map-notify bit set. This
This is so the ITR in the site the source has moved to can get the is so the ITR in the site the source has moved to can get the most
most current replication list. 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
send the Map-Notify messages to the Source-site. send the Map-Notify messages to the source site.
When the Map-Servers are distributed (when using LISP-DDT [RFC8111]), When the Map-Servers are distributed (when using LISP-DDT [RFC8111]),
the Receiver-sites MAY register to one Map-Server while the Source- the receiver sites MAY register to one Map-Server while the source
site registers to a different Map-Server. In this scenario, the Map- site registers to a different Map-Server. In this scenario, the Map-
Server for the receiver sites MUST resolve the unicast S-prefix EID Server for the receiver sites MUST resolve the unicast S-prefix EID
across a distributed mapping transport system, per standard LISP across a distributed mapping transport system, per standard LISP
lookup procedures and obtain the necessary information to send the lookup procedures, and obtain the necessary information to send the
Map-Notify messages to the Source-site. The Map-Notify messages are Map-Notify messages to the source site. The Map-Notify messages are
sent with an authentication length of 0 as they would not be sent with an authentication length of 0 as they would not be
authenticated. authenticated.
When the Map-Servers are distributed, different Receiver-sites MAY When the Map-Servers are distributed, different receiver sites MAY
register to different Map-Servers. However, this is not supported register to different Map-Servers. However, this is not supported
with the currently defined mechanisms. with the currently defined mechanisms.
5. Source Specific Multicast Trees 6. Source-Specific Multicast Trees
The interconnection of Source Specific Multicast (SSM) Trees across The interconnection of SSM trees across sites will follow the general
sites will follow the General Receiver-site Procedures described in receiver-site procedures described in Section 5.1 on the receiver
Section 4.1 on the Receiver-sites. 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 . Sections 6.1 and 6.2 .
5.1. Source Directly Connected to Source-ITRs 6.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 are not required to source site. Therefore Map-Notify messages are not 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 6.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 5.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
Site Procedures for Multicast Tree building described in source-site procedures for multicast tree building described in
Section 4.2.1. Section 5.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
registered with the LISP mapping system. Thus, the mapping system also registered with the LISP mapping system. Thus, the mapping
MAY resolve the mapping for the Source address in order to send Map- system MAY resolve the mapping for the source address in order to
Notify messages to the correct source-ITR. send Map-Notify messages to the correct Source-ITR.
6. Multi-Homing Considerations 7. Multihoming Considerations
6.1. Multiple ITRs at a Source-Site 7.1. Multiple ITRs at a Source Site
When multiple ITRs exist at a source multicast site, care MUST be When multiple ITRs exist at a source multicast site, care MUST be
taken that more than one ITR does not head-end replicate packets else taken that more than one ITR does not head-end replicate packets;
receiver multicast sites will receive duplicate packets. The otherwise, receiver multicast sites will receive duplicate packets.
following procedures will be used for each topology scenarios: The following procedures will be used for each topology scenario:
o When more than one ITR is directly connected to the source host, 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 either the PIM DR or the IGMP querier (when PIM is not enabled on
the ITRs) is responsible for packet replication. All other ITRs the ITRs) is responsible for packet replication. All other ITRs
silently drop the packet. In the IGMP querier case, one or more silently drop the packet. In the IGMP querier case, one or more
ITRs on the source LAN MUST be IGMP querier candidates. ITRs on the source LAN MUST be IGMP querier candidates.
Therefore, it is required they are configured as such. Therefore, it is required that they be configured as such.
o When more than one ITR is multiple hops away from the source host 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 and one of the ITRs is the PIM Rendezvous Point, then the PIM RP
is responsible for packet replication. is responsible for packet replication.
o When more than one ITR is multiple hops away from the source host 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 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 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 the Map-Server by an ITR, only the highest RLOC addressed ITR will
join toward the PIM RP or toward the source. join toward the PIM RP or toward the source.
6.2. Multiple ETRs at a Receiver-Site 7.2. Multiple ETRs at a Receiver Site
When multiple ETRs exist in a receiver multicast site, and each When multiple ETRs exist in a receiver multicast site and each one
create multicast join state, they each Map-Register their RLOC creates a multicast join state, each Map-Registers its RLOC address
addresses to the mapping system. In this scenario, the replication to the mapping system. In this scenario, the replication happens on
happens on the overlay causing multiple ETR entry points to replicate the overlay causing multiple ETR entry points to replicate to all
to all receivers versus a single ETR entry point replicating to all receivers instead of a single ETR entry point replicating to all
receivers. If an ETR does not create join state, because it has not 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 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 addresses to the mapping system. The same procedures in Section 5.1
are followed. are followed.
When multiple ETRs exist on the same LAN as a receiver host, then the 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 PIM DR (when PIM is enabled) or the IGMP querier is responsible for
sending a Map-Register for its RLOC. In the IGMP case, one or more sending a Map-Register for its RLOC. In the IGMP case, one or more
ETRs on LAN MUST be IGMP querier candidates. Therefore, it is ETRs on a LAN MUST be IGMP querier candidates. Therefore, it is
required they are configured as such. required that they are configured as such.
6.3. Multiple RLOCs for an ETR at a Receiver-Site 7.3. Multiple RLOCs for an ETR at a Receiver Site
It MAY be desirable to have multiple underlay paths to an ETR for It MAY be desirable to have multiple underlay paths to an ETR for
multicast packet delivery. This can be done by having multiple RLOCs 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 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 RLOCs. By doing this, an ITR can choose a specific path based on
underlay performance and/or RLOC reachability. underlay performance and/or RLOC reachability.
It is recommended that an ETR sends a Map-Register with a single It is recommended that an ETR send a Map-Register with a single RLOC-
RLOC-record that uses the ELP LCAF type [RFC8060] that is nested record that uses the Explicit Locator Path (ELP) LCAF Type [RFC8060]
inside RLE entry LCAF. For example say ETR1 has assigned RLOC1 and that is nested inside the RLE LCAF. For example, say ETR1 has
RLOC2 for a LISP receiver site. And there is ETR2 in another LISP assigned RLOC1 and RLOC2 for a LISP receiver site. Also, there is
receiver site, that has RLOC3. The two receiver sites have the same ETR2 in another LISP receiver site that has RLOC3. The two receiver
(S,G) being joined. Here is how the RLOC-record is encoded on each sites have the same (S,G) being joined. Here is how the RLOC-record
ETR: is encoded on each ETR:
ETR1: EID-record: (S,G) ETR1: EID-record: (S,G)
RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ] RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
ETR2: EID-record: (S,G) ETR2: EID-record: (S,G)
RLOC-record: RLE[ RLOC3 ] RLOC-record: RLE[ RLOC3 ]
And here is how the entry is merged and stored on the Map-Server And here is how the entry is merged and stored on the Map-Server
since the Map-Registers have an RLE encoded RLOC-record: since the Map-Registers have an RLE-encoded RLOC-record:
MS: EID-record: (S,G) MS: EID-record: (S,G)
RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ] 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, 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 it uses the merged RLOC-record returned from the Map-Server. The ITR
ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2). 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 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 replicate to RLOC1 if it is reachable. When the required p-bit is
also set, the RLOC-reachability mechanisms from [RFC6830] are also set, the RLOC-reachability mechanisms from [RFC6830] are
followed. If the ITR determines that RLOC1 is unreachable, it uses followed. If the ITR determines that RLOC1 is unreachable, it uses
RLOC2, as long as RLOC2 is reachable. RLOC2, as long as RLOC2 is reachable.
6.4. Multicast RLOCs for an ETR at a Receiver-Site 7.4. Multicast RLOCs for an ETR at a Receiver Site
This specification is focused on underlays without multicast support, This specification is focused on underlays without multicast support,
but does not preclude the use of multicast RLOCs in RLE entries. but it does not preclude the use of multicast RLOCs in RLEs. ETRs
ETRs MAY register multicast EID entries using multicast RLOCs. In MAY register multicast EID entries using multicast RLOCs. In such
such cases the ETRs will get joined to underlay multicast cases, the ETRs will be joined to underlay multicast distribution
distribution trees by using IGMP as a multicast host using mechanisms trees by using IGMP as a multicast host using mechanisms in [RFC2236]
in [RFC2236] and [RFC3376]. and [RFC3376].
7. PIM Any Source Multicast Trees 8. 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 RP is
Rendezvous Point (RP) is configured in each LISP site so PIM Register configured in each LISP site so PIM Register procedures and (*,G)
procedures and (*,G) state maintenance is contained within the LISP 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
site: site:
1. In a Receiver-site, the RP is colocated with the ETR. RPs for 1. In a receiver site, the RP is co-located with the ETR. RPs for
different groups can be spread across each ETR, but is not different groups can be spread across each ETR, but is not
required. required.
2. When (*,G) state is created in an ETR, the procedures in 2. When (*,G) state is created in an ETR, the procedures in
Section 4.1.2 are followed. In addition, the ETR registers Section 5.1.2 are followed. In addition, the ETR registers
(S-prefix,G), where S-prefix is 0/0 (the respective unicast (S-prefix,G), where S-prefix is 0/0 (the respective unicast
default route for the address-family) to the mapping system. default route for the address-family) to the mapping system.
3. In a Source-site, the RP is colocated with the ITR. RPs for 3. In a source site, the RP is co-located with the ITR. RPs for
different groups can be spread across each ITR, but is not different groups can be spread across each ITR, but is not
required. required.
4. When a multicast source sends a packet, a PIM Register message is 4. When a multicast source sends a packet, a PIM Register message is
delivered to the ITR and the procedures in Section 4.2 are delivered to the ITR, and the procedures in Section 5.2 are
followed. followed.
5. When the ITR sends a Map-Request for (S,G) and no Receiver-site 5. When the ITR sends a Map-Request for (S,G) and no receiver site
has registered for (S,G), the mapping system will return the has registered for (S,G), the mapping system will return the
(0/0,G) entry to the ITR so it has a replication list of all the (0/0,G) entry to the ITR so it has a replication list of all the
ETRs that have received (*,G) state. ETRs that have received (*,G) state.
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 5.1.2.
8. Signal-Free Multicast for Replication Engineering 9. Signal-Free Multicast for Replication Engineering
The mechanisms in this draft can be applied to the LISP Replication- The mechanisms in this specification can be applied to the "LISP
Engineering [I-D.coras-lisp-re] design. Rather than having the Replication Engineering" [LISP-RE] design. Rather than have 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. mapping database system.
As stated in [I-D.coras-lisp-re], the RTR layered hierarchy is used As stated in [LISP-RE], the RTR-layered hierarchy is used to avoid
to avoid head-end replication in replicating nodes closest to a head-end replication in replicating nodes closest to a multicast
multicast source. Rather than have multicast ITRs replicate to each source. Rather than have multicast ITRs replicate to each ETR in an
ETR in an RLE entry of a (S,G) mapping database entry, it could RLE of an (S,G) mapping database entry, it could replicate to one or
replicate to one or more layer-0 RTRs in the LISP-RE hierarchy. more layer 0 RTRs in the LISP-RE hierarchy.
This draft documents how the RTR hierarchy is determined but not what This document specifies how the RTR hierarchy is determined but not
are the optimal layers of RTRs to use. Methods for determining the optimal layers of RTRs to be used. Methods for determining
optimal paths or RTR topological closeness are out of scope for his optimal paths or RTR topological closeness are out of scope for this
document. document.
There are two formats an (S,G) mapping database entry could have. There are two formats an (S,G) mapping database entry could have.
One format is a 'complete-format' and the other is a 'filtered- One format is a 'complete-format', and the other is a 'filtered-
format'. A 'complete-format' entails an (S,G) entry having multiple format'. A 'complete-format' entails an (S,G) entry having multiple
RLOC records which contain both ETRs that have registered as well as RLOC-records that contain both ETRs that have registered as well as
the RTRs at the first level of the LISP-RE hierarchy for the ITR to the RTRs at the first level of the LISP-RE hierarchy for the ITR to
replicate to. When using 'complete-format', the ITR has the ability replicate to. When using 'complete-format', the ITR has the ability
to select if it replicates to RTRs or to the registered ETRs at the to select if it replicates to RTRs or to the registered ETRs at the
receiver sites. A 'filtered-format' (S,G) entry is one where the receiver sites. A 'filtered-format' (S,G) entry is one where the
Map-Server returns the RLOC-records that it decides the ITR SHOULD Map-Server returns the RLOC-records that it decides the ITR SHOULD
use. So replication policy is shifted from the ITRs to the mapping use. So replication policy is shifted from the ITRs to the mapping
system. The Map-Servers can also decide for a given ITR, if it uses system. The Map-Servers can also decide for a given ITR if it uses a
a different set of replication targets per (S,G) entry for which the different set of replication targets per (S,G) entry for which the
ITR is replicating for. ITR is replicating for.
The procedure for the LISP-RE RTRs to make themselves available for The procedure for the LISP-RE RTRs to make themselves available for
replication can occur before or after any receivers join an (S,G) replication can occur before or after any receivers join an (S,G)
entry or any sources send for a particular (S,G) entry. Therefore, entry or any sources send for a particular (S,G) entry. Therefore,
newly configured RTR state will be used to create new (S,G) state and newly configured RTR state will be used to create new (S,G) state and
inherited into existing (S,G) state. A set of RTRs can register will be inherited into existing (S,G) state. A set of RTRs can
themselves to the mapping system or a third-party can do so on their register themselves to the mapping system or a third party can do so
behalf. When RTR registration occurs, it is done with an (S-prefix, on their behalf. When RTR registration occurs, it is done with an
G-prefix) entry so it can advertise its replication services for a (S-prefix, G-prefix) entry so it can advertise its replication
wide-range of source/group combinations. services for a wide range of source/group combinations.
When a Map-Server receives (S,G) registrations from ETRs and When a Map-Server receives (S,G) registrations from ETRs and
(S-prefix, G-prefix) registrations from RTRs, it has the option of (S-prefix, G-prefix) registrations from RTRs, it has the option of
merging the RTR RLOC-records for each (S,G) that is more-specific for merging the RTR RLOC-records for each (S,G) that is more specific for
the (S-prefix, G-prefix) entry or keep them separate. When merging, the (S-prefix, G-prefix) entry or keeping them separate. When
a Map-Server is ready to return a 'complete-format' Map-Reply. When merging, a Map-Server is ready to return a 'complete-format' Map-
keeping the entries separate, the Map-Server can decide what to Reply. When keeping the entries separate, the Map-Server can decide
include in a Map-Reply when a Map-Request is received. It can what to include in a Map-Reply when a Map-Request is received. It
include a combination of RLOC-records from each entry or decide to can include a combination of RLOC-records from each entry or decide
use one or the other depending on policy configured. to use one or the other depending on policy configured.
+---+ +----+ +---+ +----+
Src-1 --------------|ITR| |ETR1|---------------- Rcv-1 Src-1 --------------|ITR| |ETR1|--------------- Rcv-1
+---+ +----+ +---+ +----+
\ / \ /
Source-site-1 \ / Receiver-site-1 Source-site-1 \ / Receiver-site-1
\ / \ /
\ / \ /
+----+ \ / +----+ +----+ \ / +----+
|RTR1| \ / |RTR2| Level-0 |RTR1| \ / |RTR2| Level-0
+----+ \ / +----+ +----+ \ / +----+
\ <^^^^^^^^^^^^^^> / \ <^^^^^^^^^^^^^^> /
\ < > / \ < > /
< Core-Network > < Core Network >
< > < >
<vvvvvvvvvvvvvv> <vvvvvvvvvvvvvv>
/ / \ \ / / \ \
/ / \ \ / / \ \
+----+ / / \ \ +----+ +----+ / / \ \ +----+
|RTR3| / \ |RTR4| Level-1 |RTR3| / \ |RTR4| Level-1
+----+ / \ +----+ +----+ / \ +----+
/ \ / \
/ \ / \
+----+ +----+ +----+ +----+
Rcv-2 --------------|ETR2| |ETR3|---------------- Rcv-3 Rcv-2 --------------|ETR2| |ETR3|--------------- Rcv-3
+----+ +----+ +----+ +----+
Receiver-site-2 Receiver-site-3 Receiver-site-2 Receiver-site-3
Figure 2: LISP-RE Reference Model Figure 2: LISP-RE Reference Model
Here is a specific example, illustrated in Figure 2, of (S,G) and Here is a specific example, illustrated in Figure 2, of (S,G) and
(S-prefix, G-prefix) mapping database entries when a source S is (S-prefix, G-prefix) mapping database entries when a source S is
behind an ITR and there are receiver sites joined to (S,G) via ETR1, behind an ITR, and there are receiver sites joined to (S,G) via ETR1,
ETR2, and ETR3. And there exists a LISP-RE hierarchy of RTR1 and ETR2, and ETR3. And there exists a LISP-RE hierarchy of RTR1 and
RTR2 at level-0 and RTR3 and RTR4 at level-1: RTR2 at level-0 and RTR3 and RTR4 at level-1:
EID-record: (S,G) EID-record: (S,G)
RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
EID-record: (S-prefix, G-prefix) EID-record: (S-prefix, G-prefix)
RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1 RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1
The above entries are in the form of how they were registered and The above entries are in the form in which they were registered and
stored in a Map-Server. When a Map-Server uses 'complete-format', a are stored in a Map-Server. When a Map-Server uses 'complete-
Map-Reply it originates has the mapping record encoded as: format', the Map-Reply it originates has the mapping record encoded
as:
EID-record: (S,G) EID-record: (S,G)
RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
The above Map-Reply allows the ITR to decide if it replicates to the The above Map-Reply allows the ITR to decide if it replicates to the
ETRs or if it SHOULD replicate only to level-0 RTR1. This decision ETRs or if it SHOULD replicate only to level-0 RTR1. This decision
is left to the ITR since both RLOC-records have priority 1. If the is left to the ITR since both RLOC-records have priority 1. If the
Map-Server wanted to force the ITR to replicate to RTR1, it would set Map-Server wanted to force the ITR to replicate to RTR1, it would set
the ETRs RLOC-record to priority greater than 1. the ETRs RLOC-record to a priority greater than 1.
When a Map_server uses "filtered-format', a Map-Reply it originates When a Map_server uses 'filtered-format', the Map-Reply it originates
has the mapping record encoded as: has the mapping record encoded as:
EID-record: (S,G) EID-record: (S,G)
RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
An (S,G) entry can contain alternate RTRs. So rather than An (S,G) entry can contain alternate RTRs. So rather than
replicating to multiple RTRs, one of a RTR set MAY be used based on replicating to multiple RTRs, one RTR set MAY be used based on the
the RTR reachability status. An ITR can test reachability status to RTR reachability status. An ITR can test reachability status to any
any layer-0 RTR using RLOC-probing so it can choose one RTR from a layer 0 RTR using RLOC-probing, so it can choose one RTR from a set
set to replicate to. When this is done the RTRs are encoded in to replicate to. When this is done, the RTRs are encoded in
different RLOC-records versus together in one RLE RLOC-record. This different RLOC-records instead of together in one RLE RLOC-record.
moves the replication load off the ITRs at the source site to the This moves the replication load off the ITRs at the source site to
RTRs inside the network infrastructure. This mechanism can also be the RTRs inside the network infrastructure. This mechanism can also
used by level-n RTRs to level-n+1 RTRs. be 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
9. Security Considerations 10. Security Considerations
[I-D.ietf-lisp-sec] defines a set of security mechanisms that provide [LISP-SEC] defines a set of security mechanisms that provide origin
origin authentication, integrity and anti-replay protection to LISP's authentication, integrity, and anti-replay protection to LISP's EID-
EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- to-RLOC mapping data conveyed via the 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 [RFC8111] specification, as an particular mapping database used. As an example, [RFC8111] defines a
example, defines a public-key based mechanism that provides origin public-key-based mechanism that provides origin authentication and
authentication and integrity protection to the LISP DDT protocol. integrity protection to the 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 legitimate
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 [RFC8061]. encapsulation as described in [RFC8061].
10. IANA Considerations 11. IANA Considerations
This document has no IANA implications
11. Acknowledgements
The authors want to thank Greg Shepherd, Joel Halpern and Sharon This document has no IANA actions.
Barkai for their insightful contribution to shaping the ideas in this
document. A special thanks to Luigi Iannone, LISP WG co-chair, for
shepherding this working group document. Thanks also goes to Jimmy
Kyriannis, Paul Vinciguerra, Florin Coras, and Yan Filyurin for
testing an implementation of this draft.
12. References 12. References
12.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>. February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.coras-lisp-re] [LISP-EID-MOBILITY]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
Maino, F., and D. Farinacci, "LISP Replication F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Engineering", draft-coras-lisp-re-08 (work in progress), Unified Control Plane", Work in Progress, draft-ietf-lisp-
November 2015. eid-mobility-01, November 2017.
[I-D.farinacci-lisp-mr-signaling] [LISP-MULTI-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", Work in Progress, draft-farinacci-
(work in progress), February 2015. lisp-mr-signaling-06, February 2015.
[I-D.ietf-lisp-eid-mobility] [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Maino, F., and D. Farinacci, "LISP Replication
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Engineering", Work in Progress, draft-coras-lisp-re-08,
Unified Control Plane", draft-ietf-lisp-eid-mobility-01 November 2015.
(work in progress), November 2017.
[I-D.ietf-lisp-sec] [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)", Work in Progress,
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 draft-ietf-lisp-sec-15, April 2018.
(work in progress), October 2017.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017, DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>. <https://www.rfc-editor.org/info/rfc8061>.
Appendix A. Document Change Log Acknowledgements
[RFC Editor: Please delete this section on publication as RFC.]
A.1. Changes to draft-ietf-lisp-signal-free-multicast-09
o Posted March 2018.
o Fixed idnits in draft.
A.2. Changes to draft-ietf-lisp-signal-free-multicast-08
o Posted February 2018.
o Fixed last call editorial comments.
A.3. Changes to draft-ietf-lisp-signal-free-multicast-07
o Posted November 2017.
o Changes after shepherd review and RFC1918 terminology compliant.
A.4. Changes to draft-ietf-lisp-signal-free-multicast-06
o Posted July 2017.
o Stig made a comment about referencing RFC6831 when an RLOC is a
multicast address. It opens up a lot of assumptions on what parts
of RFC6831 is performed and which parts should not be performed.
In the case of signal-free-multicast, join the underlay trees as a
multicast host by using IGMP.
A.5. Changes to draft-ietf-lisp-signal-free-multicast-05
o Posted July 2017.
o Make it clear that when a RLE is sent by an ETR and it is already
in the merged RLE list on the Map-Server, that the Map-Server
replaces the RLE entry (versus adding a duplicate RLE entry to the
list).
o Make it clear that an RLOC can be a unicast or multicast address.
Then make a reference to RFC6831 about mechanisms to support
multicast RLOCs.
o Fix some typos.
A.6. Changes to draft-ietf-lisp-signal-free-multicast-04
o Posted May 2017.
o Make it clear that recieiver-ETRs need configuraiton information
for what Map-Servers (S,G) entries are registered to.
o Make it clear this document indicates what RTR layered hierarchy
to use and not if its the best hierarchy to use.
A.7. 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.8. Changes to draft-ietf-lisp-signal-free-multicast-02
o Posted October 2016.
o Updated document expiration timer.
A.9. Changes to draft-ietf-lisp-signal-free-multicast-01
o Posted April 2016.
o Add text to define RTRs and indicate how RTR level number is used
for LISP-RE.
o Draw figure 2 that shows a LISP-RE topology.
o Indicate that PIM-ASM or (*,G) trees can be supported in LISP
Signal-Free Multicast.
A.10. Changes to draft-ietf-lisp-signal-free-multicast-00
o Posted late December 2015.
o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP
working group draft.
A.11. Changes to draft-farinacci-lisp-signal-free-multicast-04
o Posted early December 2015.
o Update references and document timer.
A.12. Changes to draft-farinacci-lisp-signal-free-multicast-03
o Posted June 2015.
o Update references and document timer.
A.13. Changes to draft-farinacci-lisp-signal-free-multicast-02
o Posted December 2014.
o Added section about how LISP-RE can use the mechanisms from
signal-free-multicast so we can avoid head-end replication and
avoid signalling across a layered RE topology.
A.14. Changes to draft-farinacci-lisp-signal-free-multicast-01
o Posted June 2014.
o Changes based on implementation experience of this draft.
A.15. Changes to draft-farinacci-lisp-signal-free-multicast-00
o Posted initial draft February 2014. The authors want to thank Greg Shepherd, Joel Halpern, and Sharon
Barkai for their insightful contribution to shaping the ideas in this
document. A special thanks to Luigi Iannone, LISP WG co-chair, for
shepherding this working group document. Thanks also goes to Jimmy
Kyriannis, Paul Vinciguerra, Florin Coras, and Yan Filyurin for
testing an implementation of this document.
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 United States of America
Email: vimoreno@cisco.com Email: vimoreno@cisco.com
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA 95120 San Jose, CA 95120
USA United States of America
Email: farinacci@gmail.com Email: farinacci@gmail.com
 End of changes. 167 change blocks. 
584 lines changed or deleted 456 lines changed or added

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