Signal-Free LISP Multicast
draft-farinacci-lisp-signal-free-multicast-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Victor Moreno , Dino Farinacci | ||
| Last updated | 2014-03-03 | ||
| Replaced by | draft-ietf-lisp-signal-free-multicast, draft-ietf-lisp-signal-free-multicast | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-farinacci-lisp-signal-free-multicast-00
Network Working Group V. Moreno
Internet-Draft Cisco Systems
Intended status: Experimental D. Farinacci
Expires: September 1, 2014 lispers.net
February 28, 2014
Signal-Free LISP Multicast
draft-farinacci-lisp-signal-free-multicast-00
Abstract
When multicast sources and receivers are active at LISP sites, the
core network is required to use native multicast so packets can be
delivered from sources to group members. When multicast is not
available to connect the multicast sites together, a signal-free
mechanism can be used to allow traffic to flow between sites. The
mechanism within here uses unicast replication and encapsulation over
the core network for the data-plane and uses the LISP mapping
database system so encapsulators 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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 1, 2014.
Moreno & Farinacci Expires September 1, 2014 [Page 1]
Internet-Draft Signal free LISP Multicast February 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. General Procedures . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Receiver-site Procedures . . . . . . . . . . . . 7
4.1.1. Multicast receiver detection . . . . . . . . . . . . 7
4.1.2. Receiver-site Registration . . . . . . . . . . . . . 7
4.1.3. Consolidation of the replication-list . . . . . . . . 8
4.2. General Source-site Procedures . . . . . . . . . . . . . 8
4.2.1. Multicast Tree Building at the Source-site . . . . . 9
4.2.2. Multicast Destination Resolution . . . . . . . . . . 9
4.3. General LISP Notification Procedures . . . . . . . . . . 9
5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 10
5.1. Source directly connected to Source-ITRs . . . . . . . . 10
5.2. Source not directly connected to Source-ITRs . . . . . . 10
6. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
When multicast sources and receivers are active at LISP sites, and
the core network between the sites does not provide multicast
support, a signal-free mechanism can be used to create an overlay
that will allow multicast traffic to flow between sites and connect
the multicast trees at the different sites.
Moreno & Farinacci Expires September 1, 2014 [Page 2]
Internet-Draft Signal free LISP Multicast February 2014
The signal-free mechanism here proposed does not extend PIM over the
overlay as proposed in [RFC6831], nor does the mechanism utilize
direct signaling between the Receiver-ETRs and Sender-ITRs as
described in [I-D.farinacci-lisp-mr-signaling]. The signal-free
mechanism proposed reduces the amount of signaling required between
sites to a minimum and is centered around the registration of
Receiver-sites for a particular multicast-group or multicast-channel
with the LISP Mapping System.
Registrations from the different receiver-sites will be merged at the
Mapping System to assemble a multicast-replication-list inclusive of
all RLOCs that lead to receivers for a particular multicast-group or
multicast-channel. The replication-list for each specific multicast-
entry is maintained as a LISP database mapping entry in the Mapping
Database.
When the ITR at the source-site receives multicast traffic from
sources at its site, the ITR can query the mapping system by issuing
Map-Request messages for the (S,G) source and destination addresses
in the packets received. The Mapping System will return the RLOC
replication-list to the ITR, which the ITR will cache as per standard
LISP procedure. Since the core is assumed to not support multicast,
the ITR will replicate the multicast traffic for each RLOC on the
replication-list and will unicast encapsulate the traffic to each
RLOC. The combined function or replicating and encapsulating the
traffic to the RLOCs in the replication-list is referred to as
"rep-encapsulation" in this document.
The document describes the General Procedures and information
encoding that are required at the Receiver-sites and Source-sites to
achieve signal-free multicast interconnectivity. The General
Procedures for Mapping System Notifications to different sites are
also described. A section dedicated to the specific case of SSM trees
discusses the implications to the General Procedures for SSM multicast
trees over different topological scenarios. At this stage ASM trees
are not supported with LISP Signal-Free multicast.
2. Definition of Terms
LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-
Resolver (MR) are defined in the LISP specification [RFC6830].
Extensions to the definitions in [RFC6830] for their application to
multicast routing are documented in [RFC6831].
Terms defining interactions with the LISP Mapping System are defined
in [RFC6833].
Moreno & Farinacci Expires September 1, 2014 [Page 3]
Internet-Draft Signal free LISP Multicast February 2014
The following terms are consistent with the definitions in [RFC6830]
and [RFC6831]. The terms are specific cases of the general terms and
are here defined to facilitate the descriptions and discussions
within this particular document.
Source: Multicast source end-point. Host originating multicast
packets.
Receiver: Multicast group member end-point. Host joins multicast
group as a receiver of multicast packets sent to the group.
Receiver-site: LISP site where multicast receivers are located.
Source-site: LISP site where multicast sources are located.
RP-site: LISP site where an ASM PIM Rendezvous Point is located. The
RP-site and the Source-site may be the same in some situations.
Receiver-ETR: LISP xTR at the Receiver-site. This is a multicast
ETR.
Source-ITR: LISP xTR at the Source-site. This is 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
have registered Receivers for a particular multicast-entry.
Multicast-entry: A tuple identifying a multicast tree. Multicast-
entries are in the form of (S-prefix, G-prefix).
Rep-encapsulation: The process of replicating and then encapsulating
traffic to multiple RLOCs.
3. Reference Model
The reference model that will be used for the discussion of the
signal free multicast tree interconnection is illustrated in
Figure 1.
Moreno & Farinacci Expires September 1, 2014 [Page 4]
Internet-Draft Signal free LISP Multicast February 2014
MS/MR
+---+
| |
+---+ +---+ +---+ +---+ +---+
Src-1-----| R1|-----|ITR| | |ETR|------| R2|-------Rcv-2
+---+ +---+ | +---+ +---+
\ | /
Source-site-1 \ | / Receiver-site-2
\ | /
\ | /
\ | /
Core
/ \
/ \
/ \
/ \
/ \
+---+ +---+
Src-3 --------------|ITR| |ETR|------------------Rcv-4
+---+ +---+
Source-site-3 Receiver-site-4
Figure 1: LISP Multicast Generic Reference Model
Sites 1 and 3 are Source-sites.
Source-site-3 presents a Source (Src-3) that is directly connected to
the Source-ITR
Source-site-1 presents a Source (Src-1) that is one hop or more away
from the Source-ITR
Receiver-site-2 and 4 are receiver sites with not-directly connected
and directly connected Receiver end-points respectively
R1 is a router in Source-site-1.
R2 is a PIM router at the Receiver-site.
The Map-Servers and Resolvers are reachable in the RLOC space in the
Core, only one is shown for illustration purposes, but these can be
many or even part of a DDT tree.
The procedures for interconnecting multicast Trees over an overlay
can be broken down into three functional areas:
Moreno & Farinacci Expires September 1, 2014 [Page 5]
Internet-Draft Signal free LISP Multicast February 2014
o Receiver-site procedures
o Source-site procedures
o LISP notification procedures
The receiver site procedures will be common for most tree types and
topologies.
The procedures at the source site will vary depending on the type of
trees being interconnected as well as based on the topological
relation between sources and source-site xTRs. For ASM trees, a
special case of the Source-site is the RP-site for which a variation
of the Source-site procedures may be necessary if ASM trees are to
be supported in future specifications of LISP Signal-Free multicast.
The LISP notification procedures between sites are normalized for the
different possible scenarios. Certain scenarios may benefit from a
simplified notification mechanism or no notification requirement at
all.
4. General Procedures
The interconnection of multicast trees across different LISP sites
involves the following procedures to build the necessary multicast
distribution trees across sites.
1. The presence of multicast Receiver end-points is detected by the
Receiver-ETRs at the Receiver-sites.
2. Receiver-ETRs register their RLOCs as part of the replication-
list for the multicast-entry the detected Receivers subscribe to.
3. The Mapping-system merges all receiver-ETR or delivery-group
RLOCs to build a comprehensive replication-list inclusive of all
Receiver-sites for each multicast-entry.
4. LISP Map-Notify messages should be sent to the Source-ITR
informing of any changes in the replication-list.
5. Multicast-tree building at the Source-site is initiated when the
Source-ITR receives the LISP Notification.
Once the multicast distribution trees are built, the following
forwarding procedures may take place:
1. The Source sends multicast packets to the multicast group
destination address.
Moreno & Farinacci Expires September 1, 2014 [Page 6]
Internet-Draft Signal free LISP Multicast February 2014
2. Multicast traffic follows the multicast tree built at the Source-
site and makes its way to the Source-ITRs.
3. The Source-ITR will issue a map-request to resolve the
replication-list for the multicast-entry.
4. The Mapping System responds to the Source-ITR with a map-reply
containing the replication-list for the multicast group
requested.
5. The Source-ITR caches the replication-list received in the map-
reply for the multicast-entry.
6. Multicast traffic is rep-encapsulated. That is, the packet is
replicated for each RLOC in the replication-list and then
encapsulated to each one.
4.1. General Receiver-site Procedures
4.1.1. Multicast receiver detection
When the Receiver-ETRs are directly connected to the Receivers (e.g.
Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP
Reports from the Receivers indicating which group the Receivers wish
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
are interested in.
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
messages which will allow the Receiver-ETR to know that there are
multicast Receivers at the site and also learn which multicast group
the Receivers are for.
4.1.2. Receiver-site Registration
Once the Receiver-ETRs detect the presence of Receivers at the
Receiver-site, the Receiver-ETRs will issue Map-Register messages to
include the Receiver-ETR RLOCs in the replication-list for the
multicast-entry the Receivers joined.
The Map-Register message will use the multicast-entry (Source, Group)
tuple as its EID record type with the Receiver-ETR RLOCs conforming
the locator set.
The EID in the Map-Register message must be encoded using the
Multicast Information LCAF type defined in [I-D.ietf-lisp-lcaf]. The
Moreno & Farinacci Expires September 1, 2014 [Page 7]
Internet-Draft Signal free LISP Multicast February 2014
R, L and J bits in the Multicast-info LCAF frame are not used and
should be set to zero.
The RLOC in the Map-Register message must be encoded using the
Replication List Entry (RLE) LCAF type defined in
[I-D.ietf-lisp-lcaf] with the Level Value fields for all entries set
to 128 (decimal).
The encoding described above must be used consistently for Map-
Register messages, entries in the Mapping Database, Map-reply
messages as well as the map-cache at the Source-ITRs.
The Map-Register messages [RFC6830] sent by the receiver-ETRs should
have the following bits set as here specified:
1. merge-request-bit set to 1. The Map-Register messages must be
sent with "Merge Semantics". The Map-Server will receive
registrations from a multitude of Receiver-ETRs. The Map-Server
will merge the registrations for common EIDs and maintain a
consolidated replication-list for each multicast-entry.
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
messages as it does not need to be notified of all changes to the
replication-list.
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
receiver-ETRs instruct the Mapping-system to proxy reply to map-
requests issued for the multicast entries.
Map-Register messages for a particular multicast-entry should be sent
for every receiver detected, even if previous receivers have been
detected for the particular multicast-entry. This allows the
replication-list to remain up to date.
4.1.3. Consolidation of the replication-list
The Map-Server will receive registrations from a multitude of
Receiver-ETRs. The Map-Server will merge the registrations for
common EIDs and consolidate a replication-list for each multicast-
entry.
4.2. General Source-site Procedures
Source-ITRs must register the unicast EIDs of any Sources or
Rendezvous Points that may be present on the Source-site. In other
words, it is assumed that the Sources and RPs are LISP EIDs.
Moreno & Farinacci Expires September 1, 2014 [Page 8]
Internet-Draft Signal free LISP Multicast February 2014
The Source-ITR must register the (S-prefix, *) EID so the map-server
knows who to send Map-Notify messages to.
The Source-ITR must register the (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-list.
The Source-ITR must register the (S-prefix, *) EID encoded using the
Multicast-info LCAF type defined in [I-D.ietf-lisp-lcaf], the
corresponding RLOCs must be encoded using the RLE LCAF type also
defined in [I-D.ietf-lisp-lcaf].
4.2.1. Multicast Tree Building at the Source-site
When the source site receives the Map-Notify messages from the
mapping system as described in Section 4.3, it will initiate the
process of building a multicast distribution tree that will allow the
multicast packets from the Source to reach the Source-ITR.
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
the direction of the source or in the direction of the RP for the SSM
and ASM cases respectively.
4.2.2. Multicast Destination Resolution
On reception of multicast packets, the source-ITR must obtain the
replication-list for the (S,G) addresses in the packets.
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
which is encoded using the Multicast Info LCAF type defined in
[I-D.ietf-lisp-lcaf].
The Mapping System (most likely the Map-Server) will Map-reply with
the merged replication-list maintained in the Mapping System. The
Map-reply message must follow the format defined in [RFC6830], its
EID must be encoded using the Multicast Info LCAF type and the
corresponding RLOC-records must be encoded using the RLE LCAF type.
Both LCAF types defined in [I-D.ietf-lisp-lcaf].
4.3. General LISP Notification Procedures
The Map-Server will issue LISP Map-Notify messages to inform the
Source-site of the presence of receivers for a particular multicast
group over the overlay.
Moreno & Farinacci Expires September 1, 2014 [Page 9]
Internet-Draft Signal free LISP Multicast February 2014
Updated Map-Notify messages should be issued every time a new
registration is received from a Receiver-site. This guarantees that
the source-sites are aware of any potential changes in the multicast-
distribution-list membership.
The Map-Notify messages carry (S,G) multicast EIDs encoded using the
Multicast Info LCAF type defined in [I-D.ietf-lisp-lcaf].
5. Source Specific Multicast Trees
The interconnection of Source Specific Multicast (SSM) Trees across
sites will follow the General Receiver-site Procedures described in
Section 4.1 on the Receiver-sites.
The Source-site Procedures will vary depending on the topological
location of the Source within the Source-site as described in
Section 5.1 and Section 5.2 .
5.1. Source directly connected to Source-ITRs
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
Source-site. Therefore Map-Notify messages may not be required to
initiate building of the multicast tree at the Source-site.
Map-Notify messages are still required to ensure that any changes to
the replication-list are communicated to the Source-site so that the
map-cache at the Source-ITRs is kept updated.
5.2. Source not directly connected to Source-ITRs
The General LISP Notification Procedures described in Section 4.3
must be followed when the Source is not directly connected to the
source-ITR.
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
may resolve the mapping for the Source address in order to send Map-
Notify messages to the correct source-ITR.
6. PIM Any Source Multicast Trees
LISP signal-free multicast will not support ASM Trees at this time.
A future revision of this specification may include procedures for
PIM ASM support.
Moreno & Farinacci Expires September 1, 2014 [Page 10]
Internet-Draft Signal free LISP Multicast February 2014
PIM ASM in shared-tree only mode could be supported in the scenario
where the root of the shared tree (the PIM RP) is placed at the
source site.
7. Security Considerations
[I-D.ietf-lisp-sec] defines a set of security mechanisms that provide
origin authentication, integrity and anti-replay protection to LISP's
EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-
SEC also enables verification of authorization on EID-prefix claims
in Map-Reply messages.
Additional security mechanisms to protect the LISP Map-Register
messages are defined in [RFC6833].
The security of the Mapping System Infrastructure depends on the
particular mapping database used. The [I-D.ietf-lisp-ddt]
specification, as an example, defines a public-key based mechanism
that provides origin authentication and integrity protection to the
LISP DDT protocol.
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.
Data-plane encryption can be used when doing unicast rep-
encapsulation as described in [I-D.farinacci-lisp-crypto]. For
further study we will look how to do multicast rep-encapsulation.
8. IANA Considerations
This document has no IANA implications
9. Acknowledgements
The authors want to thank Greg Shepherd, Joel Halpern and Sharon
Barkai for their insightful contribution to shaping the ideas in this
document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
Moreno & Farinacci Expires September 1, 2014 [Page 11]
Internet-Draft Signal free LISP Multicast February 2014
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
10.2. Informative References
[I-D.farinacci-lisp-crypto]
Farinacci, D., "LISP Data-Plane Confidentiality", draft-
farinacci-lisp-crypto-00 (work in progress), February
2014.
[I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", draft-farinacci-lisp-mr-signaling-03
(work in progress), September 2013.
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-04 (work in
progress), January 2014.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-
ietf-lisp-sec-05 (work in progress), October 2013.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January
2013.
Moreno & Farinacci Expires September 1, 2014 [Page 12]
Internet-Draft Signal free LISP Multicast February 2014
Authors' Addresses
Victor Moreno
Cisco Systems
170 Tasman Drive
San Jose, California 95134
USA
Email: vimoreno@cisco.com
Dino Farinacci
lispers.net
San Jose, CA 95120
USA
Email: farinacci@gmail.com
Moreno & Farinacci Expires September 1, 2014 [Page 13]