Requirements for the extension of the IGMP/MLD proxy functionality to support multiple upstream interfaces
draft-ietf-pim-multiple-upstreams-reqs-05
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (pim WG) | |
|---|---|---|---|
| Authors | Luis M. Contreras , Carlos J. Bernardos , Hitoshi Asaeda , Nicolai Leymann | ||
| Last updated | 2017-10-30 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-pim-multiple-upstreams-reqs-05
PIM Working Group LM. Contreras
Internet-Draft Telefonica
Intended status: Experimental CJ. Bernardos
Expires: May 3, 2018 Universidad Carlos III de Madrid
H. Asaeda
NICT
N. Leymann
Deutsche Telekom
October 30, 2017
Requirements for the extension of the IGMP/MLD proxy functionality to
support multiple upstream interfaces
draft-ietf-pim-multiple-upstreams-reqs-05
Abstract
The purpose of this document is to define the requirements for a MLD
(for IPv6) or IGMP (for IPv4) proxy with multiple interfaces covering
a variety of applicability scenarios.
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 https://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 May 3, 2018.
Copyright Notice
Copyright (c) 2017 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
(https://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
Contreras, et al. Expires May 3, 2018 [Page 1]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Scenarios of applicability . . . . . . . . . . . . . . . . . 5
4.1. Fixed network scenarios . . . . . . . . . . . . . . . . . 5
4.1.1. Multicast wholesale offer for residential services . 5
4.1.1.1. Requirements . . . . . . . . . . . . . . . . . . 5
4.1.2. Multicast resiliency . . . . . . . . . . . . . . . . 6
4.1.2.1. Requirements . . . . . . . . . . . . . . . . . . 6
4.1.3. Load balancing for multicast traffic in the metro
segment . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.3.1. Requirements . . . . . . . . . . . . . . . . . . 7
4.1.4. Network merging with different multicast services . . 7
4.1.4.1. Requirements . . . . . . . . . . . . . . . . . . 7
4.1.5. Multicast service migration . . . . . . . . . . . . . 8
4.1.5.1. Requirements . . . . . . . . . . . . . . . . . . 8
4.2. Mobile network scenarios . . . . . . . . . . . . . . . . 8
5. Summary of requirements . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The aim of this document is to define the functionality that an IGMP/
MLD proxy with multiple upstream interfaces should have in order to
support different scenarios of applicability in both fixed and mobile
networks. This functionality is needed in order to simplify node
functionality and to ensure an easier deployment of multicast
capabilities in all the use cases described in this document.
Any Source Multicast (ASM) [RFC1112] and Source-Specific Multicast
(SSM) [RFC4607] represent different service models at the time of
subscribing to multicast groups by means of IGMPv3 [RFC3376],
[RFC5790] and MLDv2 [RFC3810]. When using ASM a receiver joins a
group indicating only the desired group address to be received. In
the case of SSM, a receiver indicates the specific source address as
Contreras, et al. Expires May 3, 2018 [Page 2]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
well as a group address from where the multicast content is received.
Both service models are taken into account along this document, and
the specific requirements are derived from them.
2. Terminology
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].
This document uses the terminology defined in [RFC4605].
Specifically, the definition of Upstream and Downstream interfaces,
which are repeated here for completeness.
Upstream interface: A proxy device's interface in the direction of
the root of the tree. Also called the "Host interface".
Downstream interface: Each of a proxy device's interfaces that is
not in the direction of the root of the tree. Also called the
"Router interfaces".
3. Problem statement
The concept of IGMP/MLD proxy with several upstream interfaces has
emerged as a way of optimizing (and in some cases enabling) service
delivery scenarios where separate multicast service providers are
reachable through the same access network infrastructure. Figure 1
presents the conceptual model under consideration.
downstream upstream
interface interface A
| |
| | _______________
| +-------+ v / \
| | O-------( Multicast Set 1 )
+----------+ v | IGMP/ | \_______________/
| Listener |------| MLD | _______________
+----------+ | Proxy | / \
| O-------( Multicast Set 2 )
+-------+ ^ \_______________/
|
|
upstream
interface B
Figure 1: Concept of IGMP/MLD proxy with multiple upstream interfaces
Contreras, et al. Expires May 3, 2018 [Page 3]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
This document is focused on both fixed and mobile network scenarios.
Applicability of IGMP/MLD proxies with multiple upstream interfaces
in mobile environments has been previously described in [RFC7287].
In the case of fixed networks, multicast wholesale services in a
competitive residential market require an efficient distribution of
multicast traffic from different operators or content providers, i.e.
the incumbent operator and a number of alternative providers, on the
network infrastructure of the former. Existing proposals are based
on the use of PIM routing from the metro/core network, and multicast
traffic aggregation on the same tree. A different approach could be
achieved with the use of an IGMP/MLD proxy with multiple upstream
interfaces, each of them pointing to a distinct multicast router in
the metro/core border which is part of separated multicast trees deep
in the network. Figure 2 graphically describes this scenario.
downstream upstream
interface interface A
| |
| | _______________
| +--------+ v / \
| | Aggr. O-------( Multicast Set 1 )
| | Switch | \_______________/
+----+ v | | (e.g. from the Incumbent
| AN |-------| (IGMP | Operator)
+----+ | /MLD | _______________
(e.g. | Proxy) | / \
DSLAM | O-------( Multicast Set 2 )
/OLT) +--------+ ^ \_______________/
| (e.g. from an Alternative
| Provider)
|
upstream
interface B
Figure 2: Example of usage of an IGMP/MLD proxy with multiple
upstream interfaces in a fixed network scenario
Since those scenarios can motivate distinct needs in terms of IGMP/
MLD proxy functionality, it is necessary to consider a comprehensive
approach, looking at the possible scenarios, and establishing a
minimum set of requirements which can allow the operation of a
versatile IGMP/MLD proxy with multiple upstream interfaces as a
common entity to all of them (i.e., no different kinds of proxies
depending on the scenario, but a common proxy applicable to all the
potential scenarios).
Contreras, et al. Expires May 3, 2018 [Page 4]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
4. Scenarios of applicability
Having multiple upstream interfaces creates a new decision space for
delivering the proper multicast content to the subscriber. Basically
it is now possible to implement channel-based or subscriber-based
upstream selection, according to mechanisms or policies that could be
defined for the multicast service provisioning.
This section describes in detail a number of scenarios of
applicability of an IGMP/MLD proxy with multiple upstream interfaces
in place. A number of requirements for the IGMP/MLD proxy
functionality are identified from those scenarios.
4.1. Fixed network scenarios
Residential broadband users get access to multiple IP services
through fixed network infrastructures. End user's equipment is
connected to an access node, and the traffic of a number of access
nodes is collected in aggregation switches.
For the multicast service, the use of an IGMP/MLD proxy with multiple
upstream interfaces in those switches can provide service flexibility
in a lightweight and simpler manner if compared with PIM-routing
based alternatives.
4.1.1. Multicast wholesale offer for residential services
This scenario has been already introduced in the previous section,
and can be seen in Figure 2. There are two different operators, the
one operating the fixed network where the end user is connected
(e.g., typically an incumbent operator), and the one providing the
Internet service to the end user (e.g., an alternative Internet
service provider). Both can offer multicast streams that can be
subscribed by the end user, independently of which provider
contributes with the content.
Note that it is assumed that both providers offer distinct multicast
groups. However, more than one subscription to multicast channels of
different providers could take place simultaneously.
4.1.1.1. Requirements
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by the end user to the corresponding provider's
multicast router.
Contreras, et al. Expires May 3, 2018 [Page 5]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by each of the providers to the corresponding end
user.
o The IGMP/MLD proxy should be able to support ASM and SSM at the
time of requesting the content. Since the use case assumes that
each provider offers distinct multicast groups, the IGMP/MLD proxy
should be able to identify inconsistencies in the SSM requests
when a source S does not deliver a certain group G.
4.1.2. Multicast resiliency
In current PIM-based solutions, the resiliency of the multicast
distribution relays on the routing capabilities provided by protocols
like PIM and VRRP [RFC5798]. A simpler scheme could be achieved by
implementing different upstream interfaces on IGMP/MLD proxies,
providing path diversity through the connection to distinct leaves of
a given multicast tree.
It is assumed that only one of the upstream interfaces is active in
receiving the multicast content, while the other is up and in standby
mode for fast switching.
4.1.2.1. Requirements
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by the end user to the corresponding active upstream
interface.
o The IGMP/MLD proxy should be able to deliver multicast control
messages received in the active upstream to the end users, while
ignoring the control messages of the standby upstream interface.
o The IGMP/MLD proxy should be able of rapidly switching from the
active to the standby upstream interface in case of network
failure, transparently to the end user.
o The IGMP/MLD proxy should be able to deliver IGMP/MLD messages
sent by the end user (for both ASM and SSM modes) to the
corresponding active upstream interface.
4.1.3. Load balancing for multicast traffic in the metro segment
A single upstream interface in existing IGMP/MLD proxy functionality
typically forces the distribution of all the channels on the same
path in the last segment of the network. Multiple upstream
interfaces could naturally split the demand, alleviating the
bandwidth requirements in the metro segment.
Contreras, et al. Expires May 3, 2018 [Page 6]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
4.1.3.1. Requirements
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by the end user to the corresponding multicast
router which provides the channel of interest.
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by each of the multicast routers to the
corresponding end user.
o The IGMP/MLD proxy should be able to decide which upstream
interface is selected for any new channel request according to
defined criteria (e.g., load balancing).
o In the case of ASM, the IGMP/MLD proxy should be able to balance
the traffic as a function of the group G requested. In the case
of SSM, the load balancing mechanism could also consider the
source S for the decision.
4.1.4. Network merging with different multicast services
In some network merging situations, the multicast services provided
before in each of the merged networks are maintained for the
respective customer base (usually in a temporal fashion until the
multicast service is redefined in a new single offer, but not
necessarily, or not in short term, e.g. because of commercial
agreements for each of the previous service offers).
In order to assist that network merging situations, IGMP/MLD proxies
with multiple upstream interfaces can help in the transition
simplifying the service provisioning and facilitating service
continuity.
4.1.4.1. Requirements
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by the end user to the corresponding multicast
router which provides the channel of interest, according to the
service subscription.
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by each of the multicast routers to the
corresponding end user, according to the service subscription.
o The IGMP/MLD proxy should be able to decide which upstream
interface is selected for any new channel request according to
defined criteria (e.g., service subscription).
Contreras, et al. Expires May 3, 2018 [Page 7]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
o For this use case, the usage of SSM can simplify the decision of
the IGMP/MLD proxy. For ASM the decision should be assisted by
further information like the service to which the end user is
subscribed (e.g., taking into account what is the original network
from where the end user was part previous to the network merge
situation).
4.1.5. Multicast service migration
This scenario considers the situation where a multicast service needs
to be migrated from one upstream interface to another upstream
interface (e.g. because of changes inside the service provider's
network). The migration should be "smooth" and without any service
interruption. In this case the multicast content is initially
offered in both upstream interfaces and the proxy dynamically
switches from the first to the second upstream interface, according
to certain policies, and enabling to shut down the first upstream
interface once the migration is completed.
4.1.5.1. Requirements
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by the end user to the corresponding multicast
router before and after the service migration.
o The IGMP/MLD proxy should be able to deliver multicast control
messages sent by each of the multicast routers to the
corresponding end user, according to the situation of the user
with respect to the service migration.
o The IGMP/MLD proxy should be able to decide which upstream
interface corresponds to each user, according to the situation of
the user with respect to the service migration.
o The IGMP/MLD proxy should be able to decide which upstream
interface corresponds to each ASM or SSM request, according to the
situation of the group and source included in the request with
respect tto he service migration.
4.2. Mobile network scenarios
Mobile networks offer different alternatives for multicast
distribution.
One of them is defined by 3GPP [TS23.246] for the Multimedia
Broadcast Multicast Service (MBMS). In this case, a MBMS gateway
(MBMS GW) is connected to multiple evolved Node B (eNodeB) -- which
are the base stations connecting the mobile handsets with the network
Contreras, et al. Expires May 3, 2018 [Page 8]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
wirelessly [TS36.300] -- for data distribution by means of IP
multicast. The MBMS GW delivers the IP multicast groups. The eNodeB
joins the appropriate group multicast address allocated by the MBMS
GW to receive the content data. At this distribution level, an IGMP/
MLD proxy could be part of the transport infrastructure providing
connectivity to several distributed eNodeBs. The potential scenarios
from this case do not essentially differentiate from the ones
described for the fixed network scenarios, so the same situations and
requirements apply.
Another alternative is given by Proxy Mobile IPv6 (PMIPv6) protocol
for IP mobility management [RFC5213]. PMIPv6 is one of the
mechanisms adopted by the 3GPP to support the mobility management of
non-3GPP terminals in future Evolved Packet System (EPS) networks.
PMIPv6 allows a Media Access Gateway (MAG) to establish a distinct
bi-directional tunnel with different Local Mobility Anchors (LMAs),
being each tunnel shared by the attached Mobile Nodes (MNs). Each
mobile node is associated with a corresponding LMA, which keeps track
of its current location, that is, the MAG where the mobile node is
attached. As the basic solution for the distribution of multicast
traffic within a PMIPv6 domain, [RFC6224] makes use of the bi-
directional LMA-MAG tunnels. The use of an MLD proxy supporting
multiple upstream interfaces can improve the performance and the
scalability of multicast-capable PMIPv6 domains, for both multicast
listener and multicast source mobility. Once again, the potential
scenarios in this case are contained into the ones described for the
fixed network scenarios, so the same situations and requirements
apply.
5. Summary of requirements
Following the analysis above, a number of different requirements can
be identified by the IGMP/MLD proxy to support multiple upstream
interfaces. The following table summarizes these requirements.
Contreras, et al. Expires May 3, 2018 [Page 9]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
+---------+-----------+-----------+-----------+-----------+-----------+
|Functio- | Multicast | Multicast | Load | Network | Network |
|nality | Wholesale | Resiliency| Balancing | Merging | Migration |
+---------+-----------+-----------+-----------+-----------+-----------+
|Upstream | | | | | |
|Control | X | X | X | X | X |
|Delivery | | | | | |
+---------+-----------+-----------+-----------+-----------+-----------+
|Downstr. | | | | | |
|Control | X | X | X | X | X |
|Delivery | | | | | |
+---------+-----------+-----------+-----------+-----------+-----------+
|Active / | | | | | |
|Standby | | X | | | |
|Upstream | | | | | |
+---------+-----------+-----------+-----------+-----------+-----------+
|Upstr i/f| | | | | |
|selection| | | X | X | |
|per group| | | | | |
+---------+-----------+-----------+-----------+-----------+-----------+
|Upstr i/f| | | | | |
|selection| | X | | | X |
|all group| | | | | |
+---------+-----------+-----------+-----------+-----------+-----------+
| | | | | | |
| ASM | X | X | X | X | X |
| | | | | | |
+---------+-----------+-----------+-----------+-----------+-----------+
| | | | | | |
| SSM | X | X | X | | X |
| | | | | | |
+---------+-----------+-----------+-----------+-----------+-----------+
Figure 3: Functionality needed on IGMP/MLD proxy with multiple
upstream interfaces per application scenario
6. Security Considerations
All the security considerations in [RFC4605] are directly applicable
to this proposal. Apart from that, if proper mechanisms (i.e.,
implementation practices) are in place for channel-based or
subscriber-based upstream interface selection, Denial of Service
attacks can be prevented.
Contreras, et al. Expires May 3, 2018 [Page 10]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
7. IANA Considerations
There are no IANA considerations.
8. Acknowledgements
The authors would like to thank (in alphabetical order) Thomas C.
Schmidt, Stig Venaas and Dirk von Hugo for their comments and
suggestions.
9. References
9.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
August 2006, <https://www.rfc-editor.org/info/rfc4605>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
9.2. Informative References
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
Contreras, et al. Expires May 3, 2018 [Page 11]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
DOI 10.17487/RFC5790, February 2010,
<https://www.rfc-editor.org/info/rfc5790>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798,
DOI 10.17487/RFC5798, March 2010,
<https://www.rfc-editor.org/info/rfc5798>.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, DOI 10.17487/RFC6224,
April 2011, <https://www.rfc-editor.org/info/rfc6224>.
[RFC7287] Schmidt, T., Ed., Gao, S., Zhang, H., and M. Waehlisch,
"Mobile Multicast Sender Support in Proxy Mobile IPv6
(PMIPv6) Domains", RFC 7287, DOI 10.17487/RFC7287, June
2014, <https://www.rfc-editor.org/info/rfc7287>.
[TS23.246]
"TS 23.246 Multimedia Broadcast/Multicast Service (MBMS);
Architecture and functional description (Release 14)
V14.1.0.", 3GPP TS 23.246 V14.1.0 , December 2016.
[TS36.300]
3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300
10.11.0, September 2013.
Authors' Addresses
Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com/
Contreras, et al. Expires May 3, 2018 [Page 12]
Internet-Draft Reqs for MLD proxy with multiple upstream October 2017
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Hitoshi Asaeda
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: asaeda@nict.go.jp
Nic Leymann
Deutsche Telekom
Germany
Email: n.leymann@telekom.de
Contreras, et al. Expires May 3, 2018 [Page 13]