[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
BEHAVE Working Group                                        C. Jacquenet
Internet-Draft                                              M. Boucadair
Intended status: Informational                            France Telecom
Expires: September 15, 2011                                       Y. Lee
                                                                 Comcast
                                                                  J. Qin
                                                                     ZTE
                                                                 T. Tsou
                                               Huawei Technologies (USA)
                                                          March 14, 2011


          IPv4-IPv6 Multicast: Problem Statement and Use Cases
                  draft-jaclee-behave-v4v6-mcast-ps-01

Abstract

   This document discusses issues and requirements raised by IPv4-IPv6
   multicast interconnection and co-existence scenarios.  It also
   presents the various multicast use cases which may happen during IPv6
   transitioning.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 15, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Jacquenet, et al.      Expires September 15, 2011               [Page 1]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   document authors.  All rights reserved.

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Dual-Stack Multicast Delivery Infrastructure . . . . . . .  8
     3.4.  Mono-Stack Multicast Delivery Infrastructure . . . . . . .  9
       3.4.1.  Translation Cases  . . . . . . . . . . . . . . . . . . 11
       3.4.2.  Traversal Cases  . . . . . . . . . . . . . . . . . . . 12
   4.  Issues and Required Functions  . . . . . . . . . . . . . . . . 15
     4.1.  Fast Zapping . . . . . . . . . . . . . . . . . . . . . . . 15
     4.2.  Group and Source Discovery Considerations  . . . . . . . . 15
     4.3.  Subscription . . . . . . . . . . . . . . . . . . . . . . . 16
     4.4.  Multicast Tree Computation . . . . . . . . . . . . . . . . 16
     4.5.  SLA Considerations . . . . . . . . . . . . . . . . . . . . 16
     4.6.  Load Balancing . . . . . . . . . . . . . . . . . . . . . . 16
     4.7.  Bandwidth Consumption  . . . . . . . . . . . . . . . . . . 17
     4.8.  ASM-SSM Considerations . . . . . . . . . . . . . . . . . . 17
     4.9.  Interconnection Functions  . . . . . . . . . . . . . . . . 17
       4.9.1.  Interworking Functions for Control Flows . . . . . . . 17
       4.9.2.  Interconnection Function for Data  . . . . . . . . . . 18
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20





Jacquenet, et al.      Expires September 15, 2011               [Page 2]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


1.  Introduction

   In current operational deployments, IP multicast forwarding scheme is
   used by many service providers to deliver Live TV broadcasting
   services.  Numerous players intervene in the delivery of this
   service: (1) Content providers: the content can be provided by the
   same provider as the one providing the connectivity service or by
   distinct providers (e.g., external paid channels); (2) Network
   provider: is responsible for carrying multicast flows from head-ends
   to receivers.

   During the transition of multicast to IPv6, there will be various
   issues encountered and requirements raised correspondingly.  The
   requirement of service continuity should be an essential one which
   may include: the access to legacy contents (IPv4 framed) from
   receivers is still available where if the assignment of a dedicated
   global IPv4 address to the receiver is not possible anymore or even
   after the receivers are migrated to IPv6 and; the delivery of new
   contents (IPv6 framed) to legacy receivers is also possible and; in
   cases where if underlying transport network(s) is of different
   address family than that of the source and/or receivers, the delivery
   of multicast data is still available (e.g., in the context of DS-Lite
   deployment, the network has been firstly upgraded to IPv6 while the
   source and receivers are not).

   This document does make any assumption on the techniques used for the
   delivery of multicast services (e.g., native IP multicast with or
   without traffic isolation features, use of P2MP RSVP-TE, P2MP mLDP
   LSPs, mVPN, etc. ).

   This document further elaborates on the context and discusses
   multicast-inferred issues and requirements.

1.1.  Goals

   The goal is to clarify the problem space and get a general consent of
   the objectives.  In particular, the ambition is to provide answers
   to:

   o  What are the hurdles encountered for the delivery of multicast-
      based service offerings when both IPv4 and IPv6 co-exist?

   o  What standardization effort is needed: is there any missing
      function and protocol extensions?

   o  Check if both encapsulation and translation schemes are concerned.





Jacquenet, et al.      Expires September 15, 2011               [Page 3]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


1.2.  Terminology

   This document uses the following terms:

   o  Multicast Source: Source, in short

   o  Multicast Receiver: Receiver, in short, e.g.- STB

   o  Multicast Delivery Network: Network in short, covers the realm
      from DR device (directly connected to the Source) to IGMP/MLD
      Querier device (directly connected to the Receiver).


2.  Discussion

   Global IPv4 address depletion inevitably challenges service providers
   who must guarantee IPv4 service continuity during the forthcoming
   transition period.  In particular, access to IPv4 contents that are
   multicast to IPv4 receivers becomes an issue when the forwarding of
   multicast data assumes the use of global IPv4 addresses.

   The rarefaction of global IPv4 addresses may indeed affect the
   multicast delivery of IPv4-formatted contents to IPv4 receivers.  For
   example, the observed evolution of access infrastructures from a
   service-specific, multi-PVC scheme towards a "service-agnostic",
   single PVC scheme, assumes the allocation of a globally unique IPv4
   address on the WAN interface of the CPE (or to a mobile terminal),
   whatever the number and the nature of the services the customer has
   subscribed to.

   During the transition period, the usage of the remaining global IPv4
   address blocks will have to be rationalized for the sake of IPv4
   service continuity.  The current state-of-the-art suggests the
   introduction of NAT capabilities (generally denoted as CGN, for
   Carrier-Grade NAT) in providers networks, so that global IPv4
   addresses will be shared between several customers.  As a
   consequence, CPE or mobile UE devices will not be assigned a
   dedicated global IPv4 address anymore, and IPv4 traffic will be
   privately-addressed until it reaches one of the NAT capabilities
   deployed in the network.  From a multicast delivery standpoint, this
   situation suggests the following considerations:

   o  The current design of some multicast-based services like TV
      broadcasting often assumes that IPv4 multicast forwarding relies
      upon the use of a private IPv4 addressing scheme because of a
      walled garden approach.  Privately-addressed IGMP [RFC2236]
      [RFC3376] traffic sent by IPv4 receivers is generally forwarded
      over a specific (e.g.  "IP TV") PVC towards an IGMP Querier



Jacquenet, et al.      Expires September 15, 2011               [Page 4]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


      located in the access infrastructure, e.g.- in some deployments it
      is hosted by a BRAS device that is the PPP session endpoint and
      which may also act as a PIM DR [RFC4601] router.  This design does
      not suffer from global IPv4 address depletion by definition.  But
      it will be questioned when migrating the access infrastructure
      towards a publicly-addressed single PVC design scheme.

   o  The progressive introduction of IPv6 as the only perennial
      solution to global IPv4 address depletion does not necessarily
      assume that multicast-based IPv4 services will be migrated
      accordingly.  Access to IPv4 multicast contents raises several
      issues: (1) The completion of the IGMP-based multicast group
      subscription procedure, (2) The computation of the IPv4 multicast
      distribution tree, and (3) The IPv4-inferred addressing scheme to
      be used in a networking environment which will progressively
      become IPv6-enabled, but not necessarily IPv6 multicast enabled.

   o  In any case, contents should not be multicast twice (using both
      versions of IP) for the sake of bandwidth optimization.  Injecting
      multicast content using both IPv4 and IPv6 raises some
      dimensioning issues that should be carefully evaluated by service
      providers during network planning.  For instance, if only few
      IPv6- enabled receivers are in use, it can be more convenient to
      convey multicast traffic over IPv4 rather than doubling the
      consumed resources for few users.

   There are at least several options that can deal with the
   aforementioned considerations.

   1.  Stick to a walled garden design that relies upon a private IPv4
       addressing scheme.  But this approach jeopardizes the evolution
       of access networking infrastructures towards the use of a unique,
       per-customer, globally-addressed, service-wise PVC design scheme.
       And it also delays migration towards IPv6 instead of encouraging
       it.

   2.  Use AMT (Automatic Multicast without explicit Tunnels,
       [I-D.ietf-mboned-auto-multicast]), to encapsulate IGMP traffic
       into UDP packets that will be sent to an AMT Relay located
       upstream in the network.  This approach may not be suitable for
       the delivery of IP TV content in operational networks mainly due
       to delays which may be experienced for zapping.

   Note that unicast IP addresses are used for communicating with
   service platforms to get control information (e.g., channel lists)
   and, as the identification of customers for management, traffic
   engineering, etc.




Jacquenet, et al.      Expires September 15, 2011               [Page 5]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   The following sections elaborate more on the use cases, issues and
   requirements.


3.  Use Cases

3.1.  Purpose

   This section describes a set of use cases which need to be
   considered.

   As mentioned above, the walled garden scheme where private IPv4
   addresses are used for the delivery of multicast-based service
   offerings is out of scope.

3.2.  Context

   During transitioning, there might be a mix of multicast receivers,
   sources, and networks running in different address families.
   However, the operator should continue to deliver the multicast
   service to both IPv4 and IPv6 receivers.  Since there is mis-match of
   IP address family of sources, receiver, and delivery network, the
   operator should plan carefully and choose the right transition
   technique that could efficiently utilize the network resources to
   deliver the services.

   Both fixed (Figure 1) and mobile networks (Figure 2, which reflects
   the current status of the IPv6 Study Item conducted within 3GPP and
   some public plans for the LTE deployment) have been considered.






















Jacquenet, et al.      Expires September 15, 2011               [Page 6]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   +------------+-----------+-------------+-----------+----------------+
   | Deployment |   Legacy  |     CPE     |   Legacy  |  Underlying IP |
   |   Model    |  Receiver |             |   Source  |  capabilities  |
   +------------+-----------+-------------+-----------+----------------+
   |     DS     | IPv4-only |  IPv4-only  | IPv4-only |  IPv4 and IPv6 |
   |            |           |    and DS   |           |                |
   +------------+-----------+-------------+-----------+----------------+
   |   DS-Lite  | IPv4-only |  IPv4-only  | IPv4-only |  IPv4 and IPv6 |
   |     (*)    |           | and DS-Lite |           |                |
   +------------+-----------+-------------+-----------+----------------+
   | Greenfield |     --    |  IPv6-only  |    ---    |      IPv6      |
   |    IPv6    |           |             |           |                |
   +------------+-----------+-------------+-----------+----------------+
   |   Hybrid   | IPv4-only |  IPv4-only, | IPv4-only |  IPv4 and IPv6 |
   |    (**)    |           |    DS and   |           |                |
   |            |           |   DS-Lite   |           |                |
   +------------+-----------+-------------+-----------+----------------+
   (*) In case of Greenfield DS-Lite, there is no legacy CPE/Source
   (**) Hybrid is used to denote a network where customers may be
   IPv4-only DS and/or DS-Lite serviced.

          Figure 1: IPv6 integration scenarios in fixed networks.

    +----------------+-----------+---------------+--------------------+
    |Deployment Model| Legacy UE | Legacy source |Network Capabilities|
    +----------------+-----------+---------------+--------------------+
    |    DS PDP      | IPv4-only |   IPv4-only   |  IPv4 and IPv6     |
    +----------------+-----------+---------------+--------------------+
    |IPv6-only PDP   | IPv4-only |   IPv4-only   |  IPv4 and IPv6 (*) |
    +----------------+-----------+---------------+--------------------+

    (*) The underlying network is likely to be dual-stack except for
    IPv6 greenfield deployments.


       Figure 2: IPv6 integration scenarios in mobile networks (PDP
                               Activation).

   There are three variables to be considered when analyzing the
   multicast use cases, "Source", "Receiver" and the "Multicast Delivery
   Infrastructure" (denoted for short as "Network").

   To simplify the analysis, one of the variables: "Network", is hold.
   So based on the capabilities of the underlying multicast delivery
   infrastructure.  According to the above figures, two use cases can be
   considered:





Jacquenet, et al.      Expires September 15, 2011               [Page 7]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   o  Dual-Stack: Both IPv4 and IPv6 multicast delivery function are
      wholly enabled;

   o  Mono-Stack: Not wholly dual-stack enabled but for example, is
      either IPv4-only or IPv6-only, or may be a hybrid of IPv4 portion
      and IPv6 portion (refer to Hybrid cases in Figure 5).

3.3.  Dual-Stack Multicast Delivery Infrastructure

   Dual-stack model is supposed to be the most straight forward
   deployment model where the network is dual-stack and the same content
   is sourced into both IPv4 and IPv6 multicast stream.  Depending on
   the receiver, it could choose to listen to either stream.

      [NOTE: if the source is framed in single stack (i.e., IPv4-only or
      IPv6-only) or the network is not wholly dual-stack enabled, even
      there are both IPv4 and IPv6 receivers, it should not be regarded
      as the Dual-Stack Model use case.

      In this case, since the stream from source to receivers of the
      same address family can be natively delivered without any new
      functions, the native delivery portion is not taken into account.
      Then this is regarded as one of Mono-Stack Model cases.  For
      example, the case where the source is IPv4 framed while the
      network is wholly dual-stack enabled and there are both IPv4 and
      IPv6 receivers, is simply regarded as the Case 1 in Mono-Stack
      Model; Or for example, the case where the source and receivers are
      dual-stack, and the network is IPv6-only, is regarded as Case 6,
      also refer to Section 3.4.2.]

   This model assumes the multicast content and delivery infrastructure
   is dual-stack.  This assumption may not be valid because the dual-
   stack formatted source may not always be available since numerous
   players intervene in the delivery of multicast-based service: content
   providers and the network provider.  The content may not be
   controlled by the underlying network providers.

   For this scenario, legacy IPv4 receivers will continue to access to
   IPv4-formatted multicast content.

   Figure 3 summarizes the issues encountered if this option is used.










Jacquenet, et al.      Expires September 15, 2011               [Page 8]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


      +-----------------+----------------------------------------------+
      | Deployment Model| Comments                                     |
      +-----------------+----------------------------------------------+
      |     DS          | No issue is encountered                      |
      +-----------------+----------------------------------------------+
      |   DS-Lite       | For IPv4-only receivers, extra functions are |
      |                 | required to deliver the multicast service    |
      +-----------------+----------------------------------------------+
      |   Hybrid        | Idem as per DS-Lite case                     |
      +-----------------+----------------------------------------------+

                        Figure 3: Impact analysis.

   From a bandwidth perspective, it is not viable to duplicate the same
   content in IPv4 and IPv6.  Indeed, injecting multicast content using
   both IPv4 and IPv6 raises dimensioning issues that should be
   carefully evaluated by service providers (in particular in the access
   network).  For instance, if only few IPv6-enabled receivers are in
   use, it is more convenient to convey multicast traffic over IPv4
   rather than doubling the consumed network resources for few users.

   Figure 4 summarizes the main characteristics of this use case:
   +--------+----------------------------------------------------------+
   |  Pros  | Limitations                                              |
   +--------+----------------------------------------------------------+
   | Simple | * CAPEX (e.g., bandwidth cost)                           |
   |        | * Requires coordination between the content and the      |
   |        | network providers                                        |
   |        | * Despite DS-formatted content, extensions are still     |
   |        | required to deliver the content to IPv4-only receivers   |
   |        | when DS-Lite is deployed.                                |
   +--------+----------------------------------------------------------+

                      Figure 4: Main Characteristics.

3.4.  Mono-Stack Multicast Delivery Infrastructure

   Consider now the case where the multicast content is reachable only
   with one single address family (i.e., IPv4 or IPv6).  Depending on
   transition steps, the source could stay in IPv4 or move to IPv6.  And
   the legacy receivers are IPv4-reachable while the new receivers may
   be IPv6-enabled.









Jacquenet, et al.      Expires September 15, 2011               [Page 9]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


      +-------+------------+------------+------------+-------------+
      |  Use  |  Network   |   Source   |  Receiver  |   Use Case  |
      | Cases |Capabilities|            |            |  Categories |
      +-------+------------+------------+------------+-------------+
      |   1   |            |    IPv4    |    IPv6    |             |
      +-------+            +------------+------------+ Translation |
      |   2   |    IPv4    |    IPv6    |    IPv4    |             |
      +-------+            +------------+------------+-------------+
      |   3   |            |    IPv6    |    IPv6    |  Traversal  |
      +-------+------------+------------+------------+-------------+
      |   4   |            |    IPv4    |    IPv6    |             |
      +-------+            +------------+------------+ Translation |
      |   5   |    IPv6    |    IPv6    |    IPv4    |             |
      +-------+            +------------+------------+-------------+
      |   6   |            |    IPv4    |    IPv4    |  Traversal  |
      +-------+------------+------------+------------+-------------+
      |       |            | IPv4, IPv6 | IPv4, IPv6 |             |
      |Hybrid*| IPv4, IPv6 +------------+------------+    Hybrid   |
      |       |            | IPv4, IPv6 | IPv4, IPv6 |             |
      +-------+------------+------------+------------+-------------+

                      Figure 5: Mono-stack use cases

   * In Hybrid cases, the network is partially IPv4 and partially IPv6.

   See below:


              ---------------
            // R4        S4  \\                 S6 = v6 Source
           /                 +----+    |        R6 = v6 Receiver
         +----+    IPv4      | DR |----|        S4 = v4 Source
   R6 ---| QR |   Network    +----+    |- S6    R4 = v4 Receiver
         +----+                /       |        DR = Designated Router
            \\               //                 QR = IGMP/MLD Querier
              ---------------

                      Figure 6: IPv4 Delivery Network













Jacquenet, et al.      Expires September 15, 2011              [Page 10]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


              ---------------
            // R6        S6  \\                 S6 = v6 Source
           /                 +----+    |        R6 = v6 Receiver
         +----+    IPv6      | DR |----|        S4 = v4 Source
   R4 ---| QR |   Network    +----+    |- S4    R4 = v4 Receiver
         +----+                /       |        DR = Designated Router
            \\               //                 QR = IGMP/MLD Querier
              ---------------

                     Figure 7: IPv6  Delivery Network


              ---------------         --------------
            // R6        S6  \\     // R4        S4  \\
           /       IPv6      +------+      IPv4        \
          |       Network    |  MR  |     Network       |
           \                 +------+                  /
            \\              //      \\               //
              --------------          ---------------
           S6 = v6 Source
           R6 = v6 Receiver
           S4 = v4 Source
           R4 = v4 Receiver
           MR = Multicast Router, could be border router connecting
                IPv4 and IPv6 network, or DR connecting the source,
                or QR connecting the receiver

                    Figure 8: Hybrid  Delivery Network

3.4.1.  Translation Cases

   If the multicast source and receiver are belonging to different
   address families, translation happens.  The locations of translation
   functions defers according to the address family of delivery network.

   The translation can happen either close to the source or close to the
   receiver.  Depending on the deployment model, this decision may
   result a different transition technology being selected.  Only a
   single distribution tree is required if only one address family is
   serviced by a given transport network.

   The content will be delivered once which is better utilized the
   network bandwidth.  However if the application relies on the IP
   information stored in the payload (e.g., SDP), then translation will
   break the application.






Jacquenet, et al.      Expires September 15, 2011              [Page 11]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   +-----------------------+-------------------------------------------+
   |  Pros                 | Limitations                               |
   +-----------------------+-------------------------------------------+
   | Bandwidth utilization | * Receivers have to know the translated   |
   |                       |  source address in the context SSM        |
   |                       | * Receivers would have to know the        |
   |                       | translated multicast group address        |
   |                       | * The information loss during the         |
   |                       | translation operations                    |
   |                       | * The burden and necessary coordinations  |
   |                       | are involved if stateful translations are |
   |                       |  employed                                 |
   |                       | * ALGs may be required to assist the      |
   |                       | discovery of source address and multicast |
   |                       | group address                             |
   +-------------------------------------------------------------------+

       Figure 9: Main Characteristics of translation-based schemes.

      [NOTE: Access to IPv6-only multicast content by legacy customers
      is not seen as a valid scenario; especially in the context of IP
      TV service offering.  Whenever this configuration is met by an
      operator, it MAY consider the following mitigation alternatives:

      *  Enable IPv4-IPv6 interconnection functions to allow the
         successful delivery of IPv6-only multicast content to IPv4-only
         receivers

      *  Or swap the receiver device (e.g., STB) with a new dual-stack
         one if the provider controls STB and/or CPE devices.]

3.4.2.  Traversal Cases

   If the multicast source and receiver are belonging to the same
   address family, while the delivery network is not.

   A viable scenario for this use case is DS-Lite Model: Customers with
   legacy receivers must continue to access the IPv4-enabled multicast
   services.  This means the traffic should be accessed over IPv4.  The
   following cases should be covered by any candidate solution to the
   issue of forwarding IPv4 multicast traffic in DS-Lite environment:
   (1) IPv4-only multicast receiver; (2) Dual-Stack multicast receiver.
   As for the content, two scenarios are considered as valid ones: (1)
   IPv4-only content; (2) Dual-Stack content (i.e., content reachable in
   both IPv4 and IPv6).

   Note that:




Jacquenet, et al.      Expires September 15, 2011              [Page 12]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   1.  The legacy IPv4 receiver can access dual-stack and IPv4-only
       content.  No issue is induced by this scenario.  Multicast flows
       will be delivered using native IPv4 transfer mode.

   2.  An IPv4-only receiver behind a DS-Lite CGN: Additional functions
       are required to deliver the content to the receiver;

   3.  A dual stack receiver should access a dual stack content using
       IPv6.  No extra function is required to implement this scenario;

   4.  Dual-Stack receiver accessing IPv4-only content: This scenario is
       similar to the IPv4-only receiver accessing the IPv4-only content
       (2nd bullet).  Additional functions are required.

   In order to deliver IPv4 multicast flows to DS-Lite serviced users,
   two solution flavors can be envisaged:

   +---------------+---------------------------------------------------+
   | Solution      | Characteristics                                   |
   | Flavor        |                                                   |
   +---------------+---------------------------------------------------+
   | Translation   | For IPv4 content, introduce an IPv4-IPv6          |
   |               | translator in the provider's network.  Multicast  |
   |               | streams will then be delivered to the receivers   |
   |               | using IPv6 until the CPE.  A second level of NAT  |
   |               | can then be enforced if the receiver is           |
   |               | IPv4-only                                         |
   |               +---------------------------------------------------+
   |               | This solution may require two                     |
   |               | translation levels, can impact the overall        |
   |               | performance of the CPE, may alter the perceived   |
   |               | quality of experience, etc.  This solution may be |
   |               | the source of service disruption (especially for  |
   |               | live TV broadcasting).  This is not desirable     |
   |               +---------------------------------------------------+
   |               | For IPv6 content, all streams are delivered to    |
   |               | the DS-Lite CPE using IPv6; an IPv4-IPv6          |
   |               | translator can be enabled in the CPE to forward   |
   |               | the streams to an IPv4-only receiver.  The        |
   |               | IPv4-IPv6 translation function may impact the     |
   |               | performance of the CPE                            |
   +---------------+---------------------------------------------------+
   | Encapsulation | To access IPv4 content from an IPv4-only or       |
   |               | dual-stack receiver: If the receiver encapsulates |
   |               | the multicast signaling, it will result packet    |
   |               | replication per tunnel interface.  If the         |
   |               | underneath network is not aware of the multicast  |
   |               | topology, it will deliver the encapsulated        |



Jacquenet, et al.      Expires September 15, 2011              [Page 13]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   |               | multicast packets as unicast packets.  The        |
   |               | replication will happen at the encapsulator       |
   |               | rather than the edge multicast router.  This      |
   |               | would poorly utilize the network bandwidth        |
   |               +---------------------------------------------------+
   |               | This problem could be mitigated.  If the          |
   |               | encapsulator translates the multicast group       |
   |               | address to another address family and uses it for |
   |               | the multicast signaling, the underneath network   |
   |               | could build a multicast distribution tree using   |
   |               | the translated multicast address.  Thus, the      |
   |               | network could deliver the encapsulated packets in |
   |               | the standard multicast fashion using the          |
   |               | multicast delivery tree built by the translated   |
   |               | multicast address group.  In other words, the     |
   |               | encapsulator bridges two multicast trees at the   |
   |               | control plane but performs encapsulation at the   |
   |               | data plane.  This is a hybrid of translation and  |
   |               | encapsulation mechanisms                          |
   |               +---------------------------------------------------+
   |               | Since legacy IPv4-only receivers are predominant, |
   |               | it is optimal to enable the IPv4-IPv6             |
   |               | encapsulation function closer to the receivers    |
   |               | (e.g., first IP node).  Doing so, would lead to a |
   |               | single core multicast tree and flow replication   |
   |               | to DS-Lite serviced devices will occur upon       |
   |               | request.  Multicast flows are not replicated in   |
   |               | the core and aggregation network                  |
   |               +---------------------------------------------------+
   |               | If the IPv4-IPv6 encapsulation function is        |
   |               | implemented deeper in the network, and since      |
   |               | legacy customers need to be serviced in IPv4,     |
   |               | multicast flows are likely to be duplicated       |
   |               | (native, encapsulated) which is not optimal       |
   |               +---------------------------------------------------+
   |               | The IPv4-in-IPv6 encapsulated multicast flows     |
   |               | destined to IPv4-embedded IPv6 group address are  |
   |               | treated as any IPv6 multicast flows, and can be   |
   |               | replicated within Multicast VLANs.                |
   |               | Mechanisms such as MLD Snooping or MLD Proxying   |
   |               | can be introduced into the distributed            |
   |               | Access Network Nodes which could behave as MLD    |
   |               | Queriers and replicate multicast flows as         |
   |               | appropriate                                       |
   |               +---------------------------------------------------+
   |               | To access IPv6 content from a dual-stack          |
   |               | receiver: No new function is required since       |
   |               | native multicast IPv6 functions can be used       |



Jacquenet, et al.      Expires September 15, 2011              [Page 14]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   +---------------+---------------------------------------------------+

      Figure 10: DS-Lite Mode: Translation and Encapsulation schemes.


4.  Issues and Required Functions

   It is not so easy to provide a single solution which will be
   convenient for all Service Providers.  This is even complex if we
   consider real deployments where the network is a collection of:
   Legacy, DS, DS-Lite, PPP, DHCP, GE, ATM, PIM-SM, SSM, P2MP LSP, mVPN,
   etc.  However, the following requirements should be taken into
   account.

4.1.  Fast Zapping

   The IGMP Leave latency may be an issue when considering channel
   zapping.  In current IPv4-based TV service offerings, when a user
   changes a TV channel, an IGMP Leave message is sent followed by an
   IGMP Report to join a new channel.  This may lead to two channels to
   be sent to the receiver and as a consequence a traffic peak which may
   cause congestion on access links is experienced.

   A procedure called IGMP Fast-Leave is commonly used to avoid this
   problem and to immediately stop the multicast stream as soon as the
   IGMP Leave is received.  In some operational deployments, IGMP fast-
   leave requires the activation of an IGMP Proxy.

      Fast zapping functions MUST be taken into account when dealing
      with IPv4-IPv6 multicast delivery.  In particular, the multicast
      transition technique MUST continue to support IGMP/MLD Fast-Leave.

4.2.  Group and Source Discovery Considerations

   An ALG is required to help an IPv6 receiver to select the appropriate
   IP address when only the IPv4 address is advertised (e.g., using
   SDP); otherwise the access to the IPv4 multicast content can not be
   offered to the IPv6 receiver.

   The ALG may be located downstream the receiver.  As such, the ALG
   does not know in advance whether the receiver is dual-stack or IPv6-
   only.

   The ALG may be tuned to insert both the original IPv4 address and
   corresponding IPv6 multicast address using for instance the ALTC SDP
   attribute [I-D.boucadair-mmusic-altc].

   In order to avoid involving an ALG in the path, an IPv4-only source



Jacquenet, et al.      Expires September 15, 2011              [Page 15]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   can advertise both its IPv4 address and IPv4-embedded IPv6 multicast
   address using for instance the ALTC SDP attribute.  However, a dual-
   stack receiver may prefer to use the IPv6 address to receive the
   multicast content.  This address selection would require multicast
   flows to cross an IPv4-IPv6 interconnection function.

4.3.  Subscription

   Multicast distribution trees are receiver-initiated.  IPv4 receivers
   that wish to subscribe to an IPv4 multicast group will send the
   corresponding IGMP Report message towards the relevant IGMP Querier.
   In case the underlying network is IPv6, the information conveyed in
   IGMP messages should be relayed into corresponding MLD messages.

4.4.  Multicast Tree Computation

   Grafting to an IPv4 multicast distribution tree through an IPv6
   multicast domain suggests that IPv4 multicast traffic will have to be
   conveyed along an "IPv6-equivalent" multicast distribution tree.
   That is, part of the multicast distribution tree along which IPv4
   multicast traffic will be forwarded SHOULD be computed and maintained
   by means of the PIMv6 machinery, so that the distribution tree can be
   terminated as close to the IPv4 receivers as possible for the sake of
   the multicast forwarding efficiency.  This assumes a close
   interaction between the PIM designs enforced in both domains.  Such
   interaction may be further complicated by different combinations: the
   IPv4 multicast domain is SSM-enabled (with no RP routers), while the
   IPv6 multicast domain may support both ASM and SSM [RFC3569] modes.

4.5.  SLA Considerations

   Some contract agreements may prevent a network provider to alter the
   content as sent by the content provider, in particular for copyright,
   confidentiality and SLA assurance reasons.

   The streams should be delivered without alteration to requesting
   users.  Crossing a NAT or enforcing an encapsulation may lead to
   fragmentation or extra delays and therefore impact the perceived
   quality of service.

4.6.  Load Balancing

   In some operational networks, a source-based NAT function is used for
   load-balancing purposes.  Because of some operational issues induced
   by this NAT function, plans to remove the stateful NAT function are
   adopted by some operators.

   Since the same concern apply for stateful IPv4-IPv6 translation



Jacquenet, et al.      Expires September 15, 2011              [Page 16]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   function, stateless interconnection function SHOULD be privileged.

4.7.  Bandwidth Consumption

   As a reminder, to optimize the usage of network resources, all
   multicast streams are conveyed in the core network while only popular
   ones are continuously conveyed in the aggregation/access network
   (static mode).  Non-popular streams are conveyed in the access
   network upon request (dynamic mode).

   It should be noted that the dynamic mode may have a negative impact
   on end users experiences (i.e., a channel change takes longer for the
   new channel because it needs to be requested from the network - in
   worst case the requests needs to go all way to the source).

      IPv4/IPv6 co-existence solutions should be designed to optimize
      network resource utilization.

4.8.  ASM-SSM Considerations

   The ASM mode would be used to optimize the forwarding of IPv4
   multicast data sent by different sources into the IPv6 multicast
   domain by selecting privileged RP routers that could be located at
   the border between the IPv6 and the IPv4 multicast domains.

   [To be further elaborated.]

4.9.  Interconnection Functions

   As mentioned above, several interconnection functions are required.
   These functions can be divided into:

   1.  Interworking functions for control messages

   2.  Interconnection function for data flows.

4.9.1.  Interworking Functions for Control Flows

   The following sub-sections describes some interworking functions
   which may be required.

4.9.1.1.  IGMP-MLD Interworking

   IGMP-MLD Interworking Function combines the IGMP/MLD Proxying
   function specified in [RFC4605] and the IGMP/MLD adaptation function
   which is meant to reflect the contents of IGMP messages into MLD
   messages, vice versa.




Jacquenet, et al.      Expires September 15, 2011              [Page 17]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   For example, when an IGMP Report message is received from a receiver
   to subscribe to a given multicast group G (and optionally associated
   to a source if SSM mode is used), the IGMP-MLD Interworking Function
   MUST send an MLD Report message to subscribe to the corresponding
   IPv6 group.

4.9.1.2.  IPv4-IPv6 PIM Interworking

   [RFC4601] allows the computation of PIM-based IPv4 or IPv6
   distribution trees; PIM is IP version agnostic.  There is no specific
   IPv6 PIM machinery that would work differently than an IPv4 PIM
   machinery.  The new things needed for the IPv4-IPv6 PIM Interworking
   Function are just to allow the PIM message received from one address
   family to correspondingly trigger the operation of the other address
   family per PIM machinery specified.

   The address mapping MUST be performed similarly to that of the IGMP-
   MLD Interworking Function.

4.9.1.3.  MLD-IPv4 PIM Interworking

   This function is required when the MLD Querier is connected to an
   IPv4 PIM realm and not an IPv6 one.

   The address mapping MUST be performed similarly to that of the IGMP-
   MLD Interworking Function.

4.9.1.4.  IGMP-IPv6 PIM Interworking

   Similar to the previous sub-section.

   The address mapping MUST be performed similarly to that of the IGMP-
   MLD Interworking Function.

4.9.2.  Interconnection Function for Data

   According to different scenarios, translation or encapsulation
   mechanism can be used for traffic flows interconnection.

   The behavior of this interconnection function MUST be specified.


5.  Conclusions

   The analysis above has shown:






Jacquenet, et al.      Expires September 15, 2011              [Page 18]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   1.  Operational networks are complex environments; these networks are
       likely to be hybrid ones.

   2.  Some issues are deployment-specific (e.g., density of IPv6-
       enabled customers attached to an access network, if only few
       IPv6-enabled receivers are in use it is more convenient to convey
       multicast traffic over IPv4 rather than doubling the consumed
       network resources for few users, etc.).

   3.  For all use cases, a solution is required for the delivery of
       multicast-based services to DS-Lite serviced customers.

   4.  For DS-Lite, encapsulation and translation solutions rely on the
       same control functions; the only difference is in the treatment
       of data flows.

   5.  Standardizing the algorithms for IPv4-IPv6 Interworking functions
       should be undertaken for both encapsulation and translation.

   6.  Some performance analysis are required to assess the impact of
       activating some extra functions on the CPEs (e.g., assess the
       impact of de-capsulation function compared to translation
       function, evaluate the impact on CPE when several receivers are
       behind the same CPE, etc.).


6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


7.  Security Considerations

   Access to contents in a multicast-enabled environment raises
   different security issues that have been already documented.  This
   draft does not introduce any specific security issue.


8.  Acknowledgments

   Many thanks to N. Leymann for his comments.


9.  References




Jacquenet, et al.      Expires September 15, 2011              [Page 19]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


9.1.  Normative References

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

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3569]  Bhattacharyya, S., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, July 2003.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

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

9.2.  Informative References

   [I-D.boucadair-mmusic-altc]
              Boucadair, M., Kaplan, H., Gilman, R., and S.
              Veikkolainen, "Session Description Protocol (SDP)
              Alternate Connectivity (ALTC) Attribute",
              draft-boucadair-mmusic-altc-02 (work in progress),
              March 2011.

   [I-D.ietf-mboned-auto-multicast]
              Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
              Pusateri, "Automatic IP Multicast Without Explicit Tunnels
              (AMT)", draft-ietf-mboned-auto-multicast-10 (work in
              progress), March 2010.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.


Authors' Addresses

   Christian Jacquenet
   France Telecom

   Email: christian.jacquenet@orange-ftgroup.com





Jacquenet, et al.      Expires September 15, 2011              [Page 20]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement       March 2011


   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Yiu Lee
   Comcast
   US

   Email: Yiu_Lee@Cable.Comcast.com


   Jacni Qin
   ZTE
   China

   Email: jacniq@gmail.com


   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1 408 330 4424
   Email: tena@huawei.com





















Jacquenet, et al.      Expires September 15, 2011              [Page 21]