Internet DRAFT - draft-ietf-pim-multiple-upstreams-reqs

draft-ietf-pim-multiple-upstreams-reqs







PIM Working Group                                          LM. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                             CJ. Bernardos
Expires: May 13, 2019                   Universidad Carlos III de Madrid
                                                               H. Asaeda
                                                                    NICT
                                                              N. Leymann
                                                        Deutsche Telekom
                                                        November 9, 2018


 Requirements for the extension of the IGMP/MLD proxy functionality to
                  support multiple upstream interfaces
               draft-ietf-pim-multiple-upstreams-reqs-08

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.  The referred scenarios, while
   describing not sophisticated service situations, present cases that
   existing technology does not allow to solve in a simplistic manner.
   This document is then intended to serve as input for future documents
   defining the support of multiple upstream interfaces by IGMP/MLD
   proxies being compliant with the aforementioned requirements.

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 13, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Contreras, et al.         Expires May 13, 2019                  [Page 1]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


   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
   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 . . . . . . . . . . . . . . . . .   6
       4.1.1.  Multicast wholesale offer for residential services  .   6
         4.1.1.1.  Requirements  . . . . . . . . . . . . . . . . . .   6
       4.1.2.  Multicast resiliency  . . . . . . . . . . . . . . . .   7
         4.1.2.1.  Requirements  . . . . . . . . . . . . . . . . . .   7
       4.1.3.  Load balancing for multicast traffic in the metro
               segment . . . . . . . . . . . . . . . . . . . . . . .   7
         4.1.3.1.  Requirements  . . . . . . . . . . . . . . . . . .   8
       4.1.4.  Network merging with different multicast services . .   8
         4.1.4.1.  Requirements  . . . . . . . . . . . . . . . . . .   8
       4.1.5.  Multicast service migration . . . . . . . . . . . . .   9
         4.1.5.1.  Requirements  . . . . . . . . . . . . . . . . . .   9
     4.2.  Mobile network scenarios  . . . . . . . . . . . . . . . .  10
   5.  Summary of requirements . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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.  IGMP/MLD proxis are a generic solution very much deployed
   in existing carrier networks.  An extension to them in the sense of
   supporting multiple upstream interfaces can provide a more flexible
   and lightweight solution than other potential alternatives that could
   face more complexities (like multi-domain routing in the case of PIM,



Contreras, et al.         Expires May 13, 2019                  [Page 2]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


   or the need of some external elements -e.g., controllers- if the
   coordination of actions required lays outside the proxy).

   The functional behavior of an IGMP/MLD proxy with multiple upstream
   interfaces here described 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.

   For doing that, a number of scenarios are described, representing
   current deployments and needs from operator's networks.  From that
   scenarios, certain requirements are identified as needed to simplify
   operational situations, enable optimized service delivery, etc.
   Those represent functional requirements to be satisfied by IGMP/MLD
   proxies with multiple upstream interfaces.  These functional
   requirements reflect the need of coordinating actions from a single
   element in the network (i.e., the IGMP/MLD proxy), optimizing the
   delivery of the content within the network at any time.

   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
   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

   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.



Contreras, et al.         Expires May 13, 2019                  [Page 3]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


                        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

   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 identified as beneficial
   in scenarios as the ones described in [RFC6224] and [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.

















Contreras, et al.         Expires May 13, 2019                  [Page 4]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


                      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).

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 (i.e., leveraging on
   multicast group IP address) or subscriber-based (i.e., referenced to
   the subscriber IP address) 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.






Contreras, et al.         Expires May 13, 2019                  [Page 5]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


   All the exemplary scenarios here described are based on the support
   of two upstream interfaces.  However, all of them are applicable also
   to the support of more than two upstream interfaces.

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 appears as a simple and
   straightforward solution.

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.

   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,
      that is, the case in which for an (S, G) request the source S does
      not deliver a the group G.





Contreras, et al.         Expires May 13, 2019                  [Page 6]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


4.1.2.  Multicast resiliency

   In current PIM-based solutions [RFC7063], the resiliency of the
   multicast distribution relays on the routing capabilities provided by
   protocols like PIM [RFC7761] 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.  The objective is to avoid video delivery
   affection that could imply play out interruption or buffering on the
   user side.  Service parameters like the ones defined in [Y.1540]
   (such as packet loss ratio) or in [RFC4445] (like the delay factor)
   can be considered as parameters to be assesed from the service
   perspective.  For instance, [TECH.3361-1] could be considered as a
   SLA framework to be satisfied in this case.

4.1.2.1.  Requirements

   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
   [RFC4605] typically forces the distribution of all the channels on
   the same path in the last segment of the network.  The metro and
   backhaul network is usually built using ring topologies.  The devices
   in the ring implement IGMP/MLD functionality to join the content.
   Multiple upstream interfaces could naturally help to split the
   content demand, alleviating the bandwidth requirements in the overall
   metro segment by allowing some of the channels to follow the
   protection path, where spare capacity is vacant under normal
   conditions.  This will allow, for instance, to absorb traffic peaks
   when a high number of channels (more than the expected on average) is
   requested.




Contreras, et al.         Expires May 13, 2019                  [Page 7]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


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.  In any case, the criteria will follow
      the olicies defined by the network operator.  Such policies can be
      influenced by the user requesting the service, for instance
      through the subscription to some channels being offered by a third
      party (which has reached an agreement with the provider for
      delivering that content in its network).

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.



Contreras, et al.         Expires May 13, 2019                  [Page 8]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


   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).

   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, i.e., the status
      of the user with respect the platform migration as purely
      operational situation while transitioning from one platform to
      another in a smooth manner.

   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 to the service migration.






Contreras, et al.         Expires May 13, 2019                  [Page 9]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


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
   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 13, 2019                 [Page 10]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


 +---------+-----------+-----------+-----------+-----------+-----------+
 |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.

7.  IANA Considerations

   There are no IANA considerations.







Contreras, et al.         Expires May 13, 2019                 [Page 11]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


8.  Acknowledgements

   The authors would like to thank (in alphabetical order) Alvaro
   Retana, 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>.

   [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>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

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>.

   [RFC4445]  Welch, J. and J. Clark, "A Proposed Media Delivery Index
              (MDI)", RFC 4445, DOI 10.17487/RFC4445, April 2006,
              <https://www.rfc-editor.org/info/rfc4445>.






Contreras, et al.         Expires May 13, 2019                 [Page 12]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


   [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>.

   [RFC7063]  Zheng, L., Zhang, J., and R. Parekh, "Survey Report on
              Protocol Independent Multicast - Sparse Mode (PIM-SM)
              Implementations and Deployments", RFC 7063,
              DOI 10.17487/RFC7063, December 2013,
              <https://www.rfc-editor.org/info/rfc7063>.

   [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>.

   [TECH.3361-1]
              European Broadcasting Union, "Service Level Agreement for
              media transport services", EBU TECH.3361-1, September
              2014.

   [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.




Contreras, et al.         Expires May 13, 2019                 [Page 13]

Internet-Draft  Reqs for MLD proxy with multiple upstream  November 2018


   [Y.1540]   ITU-T, "Internet protocol data communication service - IP
              packet transfer and availability performance parameters",
              ITU-T Y.1540, July 2016.

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/


   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 13, 2019                 [Page 14]