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

Versions: 00 draft-ietf-pim-multiple-upstreams-reqs

PIM Working Group                                          LM. Contreras
Internet-Draft                                                Telefonica
Intended status: Experimental                              CJ. Bernardos
Expires: September 8, 2015              Universidad Carlos III de Madrid
                                                           March 7, 2015


Requiremnets for the extension of the MLD proxy functionality to support
                      multiple upstream interfaces
             draft-contreras-pim-multiple-upstreams-reqs-00

Abstract

   The purpose of this document is to define the requirements for a MLD
   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 http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 8, 2015.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Contreras & Bernardos   Expires September 8, 2015               [Page 1]


Internet-Draft  Reqs for MLD proxy with multiple upstream     March 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Scenarios of applicability  . . . . . . . . . . . . . . . . .   4
     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  . . . . . . . . . . . . . . . .   5
         4.1.2.1.  Requirements  . . . . . . . . . . . . . . . . . .   6
       4.1.3.  Load balancing for multicast traffic in the metro
               segment . . . . . . . . . . . . . . . . . . . . . . .   6
         4.1.3.1.  Requirements  . . . . . . . . . . . . . . . . . .   6
       4.1.4.  Summary of the requirements needed for fixed network
               scenarios . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Mobile network scenarios  . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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




Contreras & Bernardos   Expires September 8, 2015               [Page 2]


Internet-Draft  Reqs for MLD proxy with multiple upstream     March 2015


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.


                     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

   The current version of the document is focused on fixed network
   scenarios.  Mobile network scenarios will be covered in future
   versions.

   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 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 & Bernardos   Expires September 8, 2015               [Page 3]


Internet-Draft  Reqs for MLD proxy with multiple upstream     March 2015


                   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 )
              /OLT)        +--------+   ^    \_______________/
                                        | (e.g. from an Alternative
                                        |          Provider)
                                        |
                                     upstream
                                    interface B

     Figure 2: Example of usage of an MLD proxy with multiple upstream
                  interfaces in a fixed 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

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

   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.








Contreras & Bernardos   Expires September 8, 2015               [Page 4]


Internet-Draft  Reqs for MLD proxy with multiple upstream     March 2015


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
   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
   mode for fast switching.



Contreras & Bernardos   Expires September 8, 2015               [Page 5]


Internet-Draft  Reqs for MLD proxy with multiple upstream     March 2015


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.

   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 fixed 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 & Bernardos   Expires September 8, 2015               [Page 6]


Internet-Draft  Reqs for MLD proxy with multiple upstream     March 2015


                         +-----------------------------------+
                         |       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 3: Functionality needed on MLD proxy with multiple upstream
           interfaces per application scenario in fixed networks

4.2.  Mobile network scenarios

   To be done.

5.  Security Considerations

   To be completed

6.  IANA Considerations

   To be completed

7.  Normative References

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




Contreras & Bernardos   Expires September 8, 2015               [Page 7]


Internet-Draft  Reqs for MLD proxy with multiple upstream     March 2015


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

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://people.tid.es/LuisM.Contreras/


   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/
























Contreras & Bernardos   Expires September 8, 2015               [Page 8]


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