[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

PIM Working Group                                          LM. Contreras
Internet-Draft                                            Telefonica I+D
Intended status: Experimental                              CJ. Bernardos
Expires: January 4, 2014                                            UC3M
                                                              JC. Zuniga
                                                            InterDigital
                                                            July 3, 2013


 Extension of the MLD proxy functionality to support multiple upstream
                               interfaces
               draft-contreras-pim-multiple-upstreams-00

Abstract

   This document presents different scenarios of applicability for an
   MLD proxy running more than one upstream interface.  Since those
   scenarios impose different requirements on the MLD proxy with
   multiple upstream interfaces, it is important to ensure that the
   proxy functionality addresses all of them for compatibility.

   The purpose of this document is to define the requirements in an MLD
   proxy with multiple interfaces covering a variety of applicability
   scenarios, and to specify the proxy functionality to satisfy all of
   them.

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 January 4, 2014.

Copyright Notice

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




Contreras, et al.        Expires January 4, 2014                [Page 1]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   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.










































Contreras, et al.        Expires January 4, 2014                [Page 2]


Internet-Draft      MLD proxy with multiple upstream           July 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Scenarios of applicability . . . . . . . . . . . . . . . . . .  7
     4.1.  Fixed network scenarios  . . . . . . . . . . . . . . . . .  7
       4.1.1.  Multicast wholesale offer for residential services . .  8
         4.1.1.1.  Requirements . . . . . . . . . . . . . . . . . . .  8
       4.1.2.  Multicast resiliency . . . . . . . . . . . . . . . . .  8
         4.1.2.1.  Requirements . . . . . . . . . . . . . . . . . . .  8
       4.1.3.  Load balancing for multicast traffic in the metro
               segment  . . . . . . . . . . . . . . . . . . . . . . .  9
         4.1.3.1.  Requirements . . . . . . . . . . . . . . . . . . .  9
       4.1.4.  Summary of the requirements needed for mobile
               network scenarios  . . . . . . . . . . . . . . . . . .  9
     4.2.  Mobile network scenarios . . . . . . . . . . . . . . . . . 10
       4.2.1.  Applicability to multicast listener mobility . . . . . 10
         4.2.1.1.  Single MLD proxy instance on MAG . . . . . . . . . 11
           4.2.1.1.1.  Requirements . . . . . . . . . . . . . . . . . 11
         4.2.1.2.  Remote and local multicast subscription  . . . . . 11
           4.2.1.2.1.  Requirements . . . . . . . . . . . . . . . . . 12
         4.2.1.3.  Dual subscription to multicast groups during
                   handover . . . . . . . . . . . . . . . . . . . . . 12
           4.2.1.3.1.  Requirements . . . . . . . . . . . . . . . . . 13
       4.2.2.  Applicability to multicast source mobility . . . . . . 13
         4.2.2.1.  Support of remote and direct subscription in
                   basic source mobility  . . . . . . . . . . . . . . 13
           4.2.2.1.1.  Requirements . . . . . . . . . . . . . . . . . 14
         4.2.2.2.  Direct communication between source and
                   listener associated with distinct LMAs but on
                   the same MAG . . . . . . . . . . . . . . . . . . . 14
           4.2.2.2.1.  Requirements . . . . . . . . . . . . . . . . . 15
         4.2.2.3.  Route optimization support in source mobility
                   for remote subscribers . . . . . . . . . . . . . . 15
           4.2.2.3.1.  Requirements . . . . . . . . . . . . . . . . . 15
       4.2.3.  Summary of the requirements needed for mobile
               network scenarios  . . . . . . . . . . . . . . . . . . 16
   5.  Functional specification of an MLD proxy with multiple
       interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Basic support for multicast listener with PMIPv6  . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21



Contreras, et al.        Expires January 4, 2014                [Page 3]


Internet-Draft      MLD proxy with multiple upstream           July 2013


1.  Introduction

   The aim of this document is to define the functionality that an MLD
   proxy with multiple upstream interfaces should have in order to
   support different scenarios of applicability in both fixed and mobile
   networks.  This compatibility 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.


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

   This document uses the terminology defined in RFC4605 [RFC4605].
   Specifically, the definition of Upstream and Downstream interfaces,
   which are reproduced 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 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 January 4, 2014                [Page 4]


Internet-Draft      MLD proxy with multiple upstream           July 2013


                     downstream        upstream
                     interface       interface A
                          |               |
                          |               |     _______________
                          |   +-------+   v    /               \
                          |   |       O-------( Multicast Set 1 )
            +----------+  v   |  MLD  |        \_______________/
            | Listener |------|       |         _______________
            +----------+      | Proxy |        /               \
                              |       O-------( Multicast Set 2 )
                              +-------+   ^    \_______________/
                                          |
                                          |
                                       upstream
                                     interface B

     Figure 1: Concept of MLD proxy with multiple upstream interfaces

   For illustrative purposes, two applications for fixed and mobile
   networks are here introduced.  They will be elaborated later on the
   document.

   In the case of fixed networks, multicast wholesale services in a
   competitive residential market require an efficient distribution of
   multicast traffic from different operators, i.e. the incumbent
   operator and a number of alternative ones, on the network
   infrastructure of the former.  Existing proposals are based on the
   use of PIM routing from the metro network, and multicast traffic
   aggregation on the same tree.  A different approach could be achieved
   with the use of an MLD proxy with multiple upstream interfaces, each
   of them pointing to a distinct multicast router in the metro border
   which is part of separated multicast trees deep in the network.
   Figure 2 graphically describes this scenario.

   In the case of mobile networks, IP mobility services guarantee the
   continuity of the IP session while a Mobile Node (MN) changes its
   point of attachment.  Proxy Mobile IPv6 (PMIPv6) RFC5213 [RFC5213]
   standardized a protocol that allows the network to manage the MN
   mobility without requiring specific support from the mobile terminal.
   The traffic to the MN is tunneled from the Home Network making use of
   two entities, one acting as mobility anchor, and the other as
   Mobility Access Gateway (MAG).  Multicast support in PMIPv6 RFC6224
   [RFC6224] implies the delivery of all the multicast traffic from the
   Home Network, via the mobility anchor.  However, multicast routing
   optimization [I-D.ietf-multimob-pmipv6-ropt] could take advantage of
   an MLD proxy with multiple upstream interfaces by supporting the
   decision of subscribing a multicast content from the Home Network or
   from the local PMIPv6 domain if it is locally available.  Figure 3



Contreras, et al.        Expires January 4, 2014                [Page 5]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   presents this scenario.

   Informational text is provided in Appendix A summarizing how the
   basic solution for deploying multicast listener mobility with Proxy
   Mobile IPv6 works.


                    downstream       upstream
                    interface       interface A
                       |                |
                       |                |     _______________
                       |   +--------+   v    /               \
                       |   |        O-------( Multicast Set 1 )
                       |   |  Aggr. |        \_______________/
              +----+   v   | Switch |     (e.g. from the Incumbent
              | AN |-------|        |             Operator)
              +----+       |  (MLD  |         _______________
              (e.g.        | Proxy) |        /               \
              DSLAM)       |        O-------( Multicast Set 2 )
                           +--------+   ^    \_______________/
                                        | (e.g. from an Alternative
                                        |         Operator)
                                        |
                                     upstream
                                    interface B

     Figure 2: Example of usage of an MLD proxy with multiple upstream
                  interfaces in a fixed network scenario























Contreras, et al.        Expires January 4, 2014                [Page 6]


Internet-Draft      MLD proxy with multiple upstream           July 2013


                    downstream       upstream
                    interface       interface A
                       |                |
                       |                |     _______________
                       |   +--------+   v    /               \
                       |   |        O-------( Multicast Set 1 )
                       |   |        |        \_______________/
              +----+   v   |   MAG  |    e.g. from the Home Network
              | MN |-------|        |     via the mobility anchor)
              +----+       |  (MLD  |         _______________
                           | Proxy) |        /               \
                           |        O-------( Multicast Set 2 )
                           +--------+   ^    \_______________/
                                        | (e.g. from the local PMIPv6
                                        |  domain via direct routing)
                                        |
                                     upstream
                                    interface B


     Figure 3: Example of usage of an MLD proxy with multiple upstream
                  interfaces in a mobile network scenario

   Since those scenarios can motivate distinct needs in terms of 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 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

   This section describes in detail a number of scenarios of
   applicability of an MLD proxy with multiple upstream interfaces in
   place.  A number of requirements for the 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 MLD proxy with multiple



Contreras, et al.        Expires January 4, 2014                [Page 7]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   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 MLD proxy should be able to deliver multicast control messages
      sent by the end user to the corresponding provider's multicast
      router.

   o  The MLD proxy should be able to deliver multicast control messages
      sent by each of the providers to the corresponding end user.

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.  A simpler scheme could be achieved by
   implementing different upstream interfaces on 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
   for fast switching.

4.1.2.1.  Requirements

   o  The MLD proxy should be able to deliver multicast control messages
      sent by the end user to the corresponding active upstream
      interface.





Contreras, et al.        Expires January 4, 2014                [Page 8]


Internet-Draft      MLD proxy with multiple upstream           July 2013


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

4.1.3.  Load balancing for multicast traffic in the metro segment

   A single upstream interface in existing 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.

4.1.3.1.  Requirements

   o  The 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 MLD proxy should be able to deliver multicast control messages
      sent by each of the multicast routers to the corresponding end
      user.

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

4.1.4.  Summary of the requirements needed for mobile network scenarios

   Following the analysis above, a number of different requirements can
   be identified by the MLD proxy to support multiple upstream
   interfaces in fixed network scenarios.  The following table
   summarizes these requirements.















Contreras, et al.        Expires January 4, 2014                [Page 9]


Internet-Draft      MLD proxy with multiple upstream           July 2013


                         +-----------------------------------+
                         |       Fixed Network Scenarios     |
               +---------+-----------+-----------+-----------+
               |Functio- | Multicast | Multicast |   Load    |
               |nality   | Wholesale | Resiliency| Balancing |
               +---------+-----------+-----------+-----------+
               |Upstream |           |           |           |
               |Control  |     X     |     X     |     X     |
               |Delivery |           |           |           |
               +---------+-----------+-----------+-----------+
               |Downstr. |           |           |           |
               |Control  |     X     |     X     |     X     |
               |Delivery |           |           |           |
               +---------+-----------+-----------+-----------+
               |Active / |           |           |           |
               |Standby  |           |     X     |           |
               |Upstream |           |           |           |
               +---------+-----------+-----------+-----------+
               |Upstr i/f|           |           |           |
               |selection|           |           |     X     |
               |per group|           |           |           |
               +---------+-----------+-----------+-----------+
               |Upstr i/f|           |           |           |
               |selection|           |     X     |           |
               |all group|           |           |           |
               +---------+-----------+-----------+-----------+


    Figure 4: Functionality needed on MLD proxy with multiple upstream
           interfaces per application scenario in fixed networks

4.2.  Mobile network scenarios

   The mobile networks considered in this document are supposed to run
   PMIPv6 protocol for IP mobility management.  A brief description of
   multicast provision in PMIPv6-based networks can be found in Appendix
   A.

   The use of an MLD proxy supporting multiple upstream interfaces can
   improve the performance and the scalability of multicast-capable
   PMIPv6 domains.

4.2.1.  Applicability to multicast listener mobility

   Three sub-cases can be identified for the multicast listener
   mobility.





Contreras, et al.        Expires January 4, 2014               [Page 10]


Internet-Draft      MLD proxy with multiple upstream           July 2013


4.2.1.1.  Single MLD proxy instance on MAG

   The base solution for multicast service in PMIPv6 RFC6224 [RFC6224]
   assumes that any MN subscribed to multicast services receive the
   multicast traffic through the associated LMA, as in the unicast case.
   As standard MLD proxy functionality only supports one upstream
   interface, the MAG should implement several separated MLD proxy
   instances, one per LMA, in order to serve the multicast traffic to
   the MNs, according to any particular LMA-MN association.

   A way of avoiding the multiplicity of MLD proxy instance in a MAG is
   to deploy a unique MLD proxy instance with multiple upstream
   interfaces, one per LMA, without any change in the multicast traffic
   distribution.

4.2.1.1.1.  Requirements

   o  The MLD proxy should be able of delivering the multicast control
      messages sent by the MNs to the associated LMA.

   o  The MLD proxy should be able of delivering the multicast control
      messages sent by each of the connected LMAs to the corresponding
      MN.

   o  The MLD proxy should be able of routing the multicast data coming
      from different LMAs to the corresponding MNs according to the MN
      to LMA association.

   o  The MLD proxy should be able of maintaining a 1:1 association
      between an MN and LMA (or downstream to upstream).

4.2.1.2.  Remote and local multicast subscription

   This scenario has been already introduced in the previous section,
   and can be seen in Figure 3.  Standard MLD proxy definition, with a
   unique upstream interface per proxy, does not allow the reception of
   multicast traffic from distinct upstream multicast routers.  In other
   words, all the multicast traffic being sent to the MLD proxy in
   downstream traverses a concrete, unique router before reaching the
   MAG.  There are, however, situations where different multicast
   content could reach the MLD proxy through distinct next-hop routers.

   For instance, the solution adopted to avoid the tunnel convergence
   problem in basic multicast PMIPv6 deployments
   [I-D.ietf-multimob-pmipv6-ropt] considers the possibility of
   subscription to a multicast source local to the PMIPv6 domain.  In
   that situation, some multicast content will be accesses remotely,
   through the home network via the multicast tree mobility anchor,



Contreras, et al.        Expires January 4, 2014               [Page 11]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   while some other multicast content will reach the proxy directly, via
   a local router in the domain.

4.2.1.2.1.  Requirements

   o  The MLD proxy should be able of delivering the multicast control
      messages sent by the MNs to the associated upstream interface
      based on the location of the source, remote or local, for a
      certain multicast group.

   o  The MLD proxy should be able of delivering the multicast control
      messages sent either local or remotely to the corresponding MNs.

   o  The MLD proxy should be able of routing the multicast data coming
      from different upstream interfaces to a certain MN according to
      the MN subscription, either local or remote.  Note that it is
      assumed that a multicast group can be subscribed either locally or
      remotely, but not simultaneously.  However more than one
      subscription could happen, being local or remote independently.

   o  The MLD proxy should be able of maintaining a 1:N association
      between an MN and the remote and local multicast router (or
      downstream to upstream).

   o  The MLD proxy should be able of switching between local or remote
      subscription for per multicast group according to specific
      configuration parameters (out of the scope of this document).

4.2.1.3.  Dual subscription to multicast groups during handover

   In the event of an MN handover, once an MN moves from a previous MAG
   (pMAG) to a new MAG (nMAG), the nMAG needs to set up the multicast
   status for the incoming MN, and subscribe the multicast channels it
   was receiving before the handover event.  The MN will then experience
   a certain delay until it receives again the subscribed content.

   A generic solution is being defined in
   [I-D.ietf-multimob-handover-optimization] to speed up the knowledge
   of the ongoing subscription by the nMAG.  However, for the particular
   case that the underlying radio access technology supports layer-2
   triggers (thus requiring extra capabilities on the mobile node),
   there could be inter-MAG cooperation for handover support if pMAG and
   nMAG are known in advance.

   This could be the case, for instance for those contents not already
   arriving to the nMAG, where the nMAG temporally subscribes the
   multicast groups of the ongoing MN's subscription via the pMAG, while
   the multicast delivery tree among the nMAG and the mobility anchor is



Contreras, et al.        Expires January 4, 2014               [Page 12]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   being established.

   A similar approach is followed in
   [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast] despite the solution
   proposed there differs from this approach (i.e., there is no
   consideration of an MLD proxy with multiple interfaces).

4.2.1.3.1.  Requirements

   o  The MLD proxy should be able of delivering the multicast control
      messages sent by the MNs to the associated upstream interface
      based on the handover specific moment, for a certain multicast
      group.

   o  The MLD proxy should be able of delivering the multicast control
      messages sent either from pMAG or the multicast anchor to the
      corresponding MNs, based on the handover specific moment.

   o  The MLD proxy should be able of handle the incoming packet flows
      from the two simultaneous upstream interfaces, in order to not
      duplicate traffic delivered on the point-to-point link to the MN.

   o  The MLD proxy should be able of maintaining a 1:N association
      between an MN and both the remote multicast router and the pMAG
      (or downstream to upstream).

   o  The MLD proxy should be able of switching between local or remote
      subscription for all the multicast groups (from pMAG to multicast
      anchor) according to specific configuration parameters (out of the
      scope of this document).

4.2.2.  Applicability to multicast source mobility

   A couple of sub-cases can be identified for the multicast source
   mobility.

4.2.2.1.  Support of remote and direct subscription in basic source
          mobility

   In the basic case of source mobility, the multicast source is
   connected to one of the downstream interfaces of an MLD proxy.
   According to the standard specification RFC4605 [RFC4605] every
   packet sent by the multicast source will be forwarded towards the
   root of the multicast tree.

   However, linked to the mobility listener problem, there could be the
   case of simultaneous remote subscribers, subscribing to the multicast
   content through the home network, and local subscribers, requesting



Contreras, et al.        Expires January 4, 2014               [Page 13]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   the contents directly via a multicast router residing on the same
   PMIPv6 domain where the source is attached to.

   Then, in order to provide the co-existence of both types of
   subscribers, an MLD proxy with two upstream interfaces could
   simultaneously serve all kind of multicast subscribers.

   Basic source mobility is being defined in RFC4605 [RFC4605] but the
   solution proposed there does not allow simultaneous co-existence of
   remote and local subscribers (i.e., the content sent by the source is
   either distributed locally to a multicast router in the PMIPv6
   domain, or remotely by using the bi-directional tunnel towards the
   mobility anchor, but not both simultaneously).

4.2.2.1.1.  Requirements

   o  The MLD proxy should be able of forwarding (replicating) the
      multicast content to both upstream interfaces, in case of
      simultaneous remote and local distribution.

   o  The MLD proxy should be able of handling control information
      incoming through any of the two upstream interfaces, providing the
      expected behavior for each of the multicast trees.

   o  The MLD proxy should be able of routing the multicast data towards
      different upstream interfaces for both remote and local
      subscriptions that could happen simultaneously.

   o  The MLD proxy should be able of maintaining a 1:N association
      between an MN and both the remote and local multicast router (or
      downstream to upstream).

4.2.2.2.  Direct communication between source and listener associated
          with distinct LMAs but on the same MAG

   In a certain PMIPv6 domain can be MNs associated to distinct LMAs
   using the same MAG to get access to their corresponding home
   networks.  For multicast communication, according to the base
   solution RFC6224 [RFC6224], each MN - LMA association implies a
   distinct MLD proxy instance to be invoked in the MAG.

   In these conditions, when a mobile source is serving multicast
   content to a mobile listener, both attached to the same MAG but each
   of them associated to different LMAs, the multicast flow must
   traverse the PMIPv6 domain from the MAG to the LMA where the source
   maintains an association, then from that LMA to the LMA where the
   listener is associated to, and finally come back to the same MAG from
   where the flow departed.  This routing is extremely inefficient.



Contreras, et al.        Expires January 4, 2014               [Page 14]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   An MLD proxy with multiple upstream interfaces avoids this behavior
   since it allows to invoke a unique MLD proxy instance in the MAG.  In
   this case, the multicast source can directly communicate with the
   multicast listener, without need for delivering the multicast traffic
   to the LMAs.

4.2.2.2.1.  Requirements

   o  The MLD proxy should be able of forwarding (replicating) the
      multicast content to different upstream or downstream interfaces
      where subscribers are present.

   o  The MLD proxy should be able of handling control information
      incoming through any of the upstream or downstream interfaces
      requesting a multicast flow being injected in another downstream
      interface.

   o  The MLD proxy should be able of maintaining a 1:N association
      between an MN and any of the upstream or downstream interfaces
      demanding the multicast content.

4.2.2.3.  Route optimization support in source mobility for remote
          subscribers

   Even in a scenario of remote subscription, there could be the case
   where both the source and the listener are attached to the same
   PMIPv6-Domain (for instance, no possibility of direct routing within
   the PMIPv6, or source and listener pertaining to distinct home
   networks).  In this situation there is a possibility of route
   optimization if inter-MAG communication is enabled, in such a way
   that the listeners in the PMIPv6 domain are served through the
   tunnels between MAGs, while the rest of remote listeners are served
   through the mobility anchor.

   A multi-upstream MLD proxy would allow the simultaneous delivery of
   traffic to such kind of remote listeners.

   A similar route optimization approach is proposed in
   [I-D.liu-multimob-pmipv6-multicast-ro].

4.2.2.3.1.  Requirements

   o  The MLD proxy should be able of forwarding (replicating) the
      multicast content to both kinds of upstream interfaces, inter-MAG
      tunnel interfaces and MAG to mobility anchor tunnel interface.

   o  The MLD proxy should be able of handling control information
      incoming through any of the two types of upstream interfaces,



Contreras, et al.        Expires January 4, 2014               [Page 15]


Internet-Draft      MLD proxy with multiple upstream           July 2013


      providing the expected behavior for each of the multicast trees
      (e.g., no forwarding traffic on one inter-MAG link once there are
      not more listeners requesting the content).

   o  The MLD proxy should be able of routing the multicast data towards
      different upstream interfaces for both remote and route optimized
      subscriptions that could happen simultaneously.

   o  The MLD proxy should be able of maintaining a 1:N association
      between an MN and both the remote and local MAGs (or downstream to
      upstream).

4.2.3.  Summary of the requirements needed for mobile network scenarios

   After the previous analysis, a number of different requirements can
   be identified by the MLD proxy to support multiple upstream
   interfaces in mobile network scenarios.  The following table
   summarizes these requirements.

































Contreras, et al.        Expires January 4, 2014               [Page 16]


Internet-Draft      MLD proxy with multiple upstream           July 2013


                 +----------------------------------------------------+
                 |               Mobile Network Scenarios             |
                 +--------------------------+-------------------------+
                 |    Mulicast Listener     |      Mulicast Source    |
       +---------+--------+--------+--------+--------+--------+-------+
       |         |  Single| Remote |  Dual  | Direct |Listener| Route |
       |Functio- |   MLD  |& local | subscr.|& remote|& source|optimi.|
       |nality   |  Proxy | subscr.|  in HO | subscr.| on MAG |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |Upstream |        |        |        |        |        |       |
       |Control  |    X   |    X   |    X   |    X   |    X   |   X   |
       |Delivery |        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |Downstr. |        |        |        |        |        |       |
       |Control  |    X   |    X   |    X   |        |    X   |       |
       |Delivery |        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |Upstream |        |        |        |        |        |       |
       |Data     |        |        |        |    X   |        |   X   |
       |Delivery |        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |Downstr. |        |        |        |        |        |       |
       |Data     |    X   |    X   |    X   |        |    X   |       |
       |Delivery |        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |1:1 MN to|        |        |        |        |        |       |
       |upstream |    X   |        |        |        |        |       |
       |assoc.   |        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |1:N MN to|        |        |        |        |        |       |
       |upstream |        |    X   |    X   |    X   |    X   |   X   |
       |assoc.   |        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |Upstr i/f|        |        |        |        |        |       |
       |selection|        |    X   |        |        |        |       |
       |per group|        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |Upstr i/f|        |        |        |        |        |       |
       |selection|        |        |    X   |        |        |       |
       |all group|        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+
       |Upstream |        |        |        |        |        |       |
       |traffic  |        |        |        |    X   |        |   X   |
       |replicat.|        |        |        |        |        |       |
       +---------+--------+--------+--------+--------+--------+-------+


    Figure 5: Functionality needed on MLD proxy with multiple upstream



Contreras, et al.        Expires January 4, 2014               [Page 17]


Internet-Draft      MLD proxy with multiple upstream           July 2013


          interfaces per application scenario in mobile networks


5.  Functional specification of an MLD proxy with multiple interfaces

   To be completed


6.  Security Considerations

   To be completed


7.  IANA Considerations

   To be completed


8.  Acknowledgments

   The authors thank Stig Venaas for his valuable comments and
   suggestions.

   The research of Carlos J. Bernardos leading to these results has
   received funding from the European Community's Seventh Framework
   Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL
   project), being also partially supported by the Ministry of Science
   and Innovation (MICINN) of Spain under the QUARTET project (TIN2009-
   13992-C02-01).


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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, August 2006.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.






Contreras, et al.        Expires January 4, 2014               [Page 18]


Internet-Draft      MLD proxy with multiple upstream           July 2013


9.2.  Informative References

   [I-D.ietf-multimob-handover-optimization]
              Contreras, L., Bernardos, C., and I. Soto, "PMIPv6
              multicast handover optimization by the Subscription
              Information Acquisition through the LMA (SIAL)",
              draft-ietf-multimob-handover-optimization-02 (work in
              progress), February 2013.

   [I-D.ietf-multimob-pmipv6-ropt]
              Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y.
              Kim, "Multicast Mobility Routing Optimizations for Proxy
              Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-06 (work in
              progress), June 2013.

   [I-D.liu-multimob-pmipv6-multicast-ro]
              Liu, J. and W. Luo, "Routes Optimization for Multicast
              Sender in Proxy Mobile IPv6 Domain",
              draft-liu-multimob-pmipv6-multicast-ro-02 (work in
              progress), July 2012.

   [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast]
              Schmidt, T., Waehlisch, M., Koodli, R., and G. Fairhurst,
              "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast
              Handovers",
              draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07 (work
              in progress), October 2012.

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.


Appendix A.  Basic support for multicast listener with PMIPv6

   This section briefly summarizes the operation of Proxy Mobile IPv6
   RFC5213 [RFC5213] and how multicast listener support works with
   PMIPv6 as specified in RFC6224 [RFC6224].

   Proxy Mobile IPv6 (PMIPv6) RFC5213 [RFC5213] is a network-based
   mobility management protocol which enables the network to provide
   mobility support to standard IP terminals residing in the network.
   These terminals enjoy this mobility service without being required to
   implement any mobility-specific IP operations.  Namely, 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.




Contreras, et al.        Expires January 4, 2014               [Page 19]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   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.  IP-in-IP encapsulation is used within the tunnel to
   forward traffic between the LMA and the MAG.  Figure 4 (taken from
   RFC5213 [RFC5213]) shows the architecture of a PMIPv6 domain.

           +----+                +----+
           |LMA1|                |LMA2|
           +----+                +----+
    LMAA1 -> |                      | <-- LMAA2
             |                      |
             \\                    //\\
              \\                  //  \\
               \\                //    \\
            +---\\------------- //------\\----+
           (     \\  IPv4/IPv6 //        \\    )
           (      \\  Network //          \\   )
            +------\\--------//------------\\-+
                    \\      //              \\
                     \\    //                \\
                      \\  //                  \\
          Proxy-CoA1--> |                      | <-- Proxy-CoA2
                     +----+                 +----+
                     |MAG1|-----{MN2}       |MAG2|
                     +----+    |            +----+
                       |       |               |
          MN-HNP1 -->  |     MN-HNP2           | <-- MN-HNP3, MN-HNP4
                     {MN1}                   {MN3}

                    Figure 6: Proxy Mobile IPv6 Domain

   The basic solution for the distribution of multicast traffic within a
   PMIPv6 domain RFC6224 [RFC6224] makes use of the bi-directional LMA-
   MAG tunnels.  The base solution follows the so-called remote
   subscription model, in which the subscribed multicast content is
   delivered from the Home Network.  By doing so, an individual copy of
   every multicast flow is delivered through the tunnel connecting the
   mobility anchor to any of the access gateways in the domain.  In many
   cases, these individual copies traverse the same routers in the path
   towards the access gateways, incurring in an inefficient
   distribution, equivalent to the unicast distribution of the multicast
   content in the domain.

   The reference scenario for multicast deployment in Proxy Mobile IPv6
   domains is illustrated in Figure 5 (taken from RFC6224 [RFC6224]).



Contreras, et al.        Expires January 4, 2014               [Page 20]


Internet-Draft      MLD proxy with multiple upstream           July 2013


   This fact leads to distribution inefficiencies and higher per-bit
   delivery costs, incurred by the PMIPv6 domain operator offering
   transport capabilities to the Home Network operator for serving their
   MNs when attached to the PMIPv6 domain.  As long as the remotely
   subscribed multicast service is not affected, it seems worthy to
   explore more optimal ways of distributing such content within the
   PIMPv6 domain.

                +-------------+
                | Content     |
                | Source      |
                +-------------+
                       |
              ***  ***  ***  ***
             *   **   **   **   *
            *                    *
             *  Fixed Internet  *
            *                    *
             *   **   **   **   *
              ***  ***  ***  ***
               /
           +----+         +----+
           |LMA1|         |LMA2|                 Multicast Anchor
           +----+         +----+
      LMAA1  |              |  LMAA2
             |              |
             \\           //\\
              \\         //  \\
               \\       //    \\                 Unicast Tunnel
                \\     //      \\
                 \\   //        \\
                  \\ //          \\
        Proxy-CoA1 ||            ||  Proxy-CoA2
                +----+          +----+
                |MAG1|          |MAG2|           MLD Proxy
                +----+          +----+
                 |  |             |
         MN-HNP1 |  | MN-HNP2     | MN-HNP3
               MN1 MN2          MN3

      Figure 7: Reference Network for Multicast Deployment in PMIPv6










Contreras, et al.        Expires January 4, 2014               [Page 21]


Internet-Draft      MLD proxy with multiple upstream           July 2013


Authors' Addresses

   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid  28050
   Spain

   Email: lmcm@tid.es


   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/


   Juan Carlos
   InterDigital Communications, LLC
   1000 Sherbrooke Street West, 10th floor
   Montreal, Quebec  H3A 3G4
   Canada

   Email: JuanCarlos.Zuniga@InterDigital.com





















Contreras, et al.        Expires January 4, 2014               [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/