Internet Engineering Task Force                                H. Asaeda
Internet-Draft                                           Keio University
Intended status: Informational                                M. Eubanks
Expires: September 13, 2012                               AmericaFree.TV
                                                                 T. Tsou
                                               Huawei Technologies (USA)
                                                               S. Venaas
                                                           Cisco Systems
                                                          March 12, 2012


                     Multicast Transition Overview
              draft-eubanks-mboned-transition-overview-04

Abstract

   IPTV providers must serve content to their customers during the
   period of transition from IPv4 to IPv6.  During this period, the
   content provider may support only one version of IP while the
   customer's receiver device supports only the other.  Likewise, the
   network between the provider and its customer may include segments
   supporting only one version of IP or another.

   This document provides an overview of the multicast transition
   problem.  It also provides an overview of the solution space.  The
   solution space is characterized by an adaptation function (AF) that
   provides an interface between IPv4 and IPv6 multicast domains.  This
   document also discusses various multicast use cases which may occur
   during IPv6 transitioning.  These use cases motivate the solution
   space discussion and the requirements that appear at the end.

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




Asaeda, et al.         Expires September 13, 2012               [Page 1]


Internet-Draft        Multicast Transition Overview           March 2012


Copyright Notice

   Copyright (c) 2012 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  A Look At the Multicast Transition Problem Space . . . . . . .  3
     2.1.  Signaling Channels using Multicast Addresses . . . . . . .  4
     2.2.  Operator View of Use Cases . . . . . . . . . . . . . . . .  5
     2.3.  Requirements From The Use Cases  . . . . . . . . . . . . .  8
   3.  A Look At the Solution Space For Multicast Transition  . . . .  9
     3.1.  AF Forwarding Plane Operation  . . . . . . . . . . . . . .  9
     3.2.  AF Control Plane Operation . . . . . . . . . . . . . . . . 10
     3.3.  Source Discovery . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Transitional Multicast Path Optimization . . . . . . . . . 10
   4.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

















Asaeda, et al.         Expires September 13, 2012               [Page 2]


Internet-Draft        Multicast Transition Overview           March 2012


1.  Introduction

   IPTV providers must serve content to their customers during the
   period of transition from IPv4 to IPv6.  During this period, the
   content provider may support only one version of IP while the
   customer supports only the other.  Likewise, the network between the
   provider and its customer may include segments supporting only one
   version of IP or another.

   In current deployments, the IP multicast forwarding scheme is used by
   many service providers to deliver services such as live TV
   broadcasting.  Multiple players intervene in the delivery of these
   services, including content and service providers.  Service providers
   are responsible for carrying multicast flows from head-ends to
   receivers.  The content can be supplied by a service provider or by
   other providers (e.g., case of externally paid channels).

   Unlike the situation for unicast addresses, the IPv4 multicast
   address space seems sufficient for most proposed uses.  Hence the key
   motivation for the work described here is to preserve the
   efficiencies of multicast distribution of content (i.e., by reducing
   total traffic on the network and minimizing the distance that
   multicast streams must travel) when both IPv4 and IPv6 segments lie
   on the path from source to receiver.

   This document provides an overview of the multicast transition
   problem.  It also provides an overview of the solution space.  The
   solution space is characterized by an adaptation function (AF) that
   provides an interface between IPv4 and IPv6 multicast segments.  The
   scope of this document is currently limited to IP transport, and
   covers both single operator and inter-operator flows.

   Section 2 describes the problem space in detail.  This section
   describes an environment that includes a content provider, a
   customer, and an intervening network.  Any component of that
   environment may support only one version of IP or the other.  At
   points where IPv4-only devices lie on one side and IPv6-only devices
   on the other, an adaptation function is required.

   Section 3 proposes a framework for the solution.  Section 4 defines
   formal requirements for any proposed solution.


2.  A Look At the Multicast Transition Problem Space

   Historically, IPTV providers have served IPv4 content to receivers
   over IPv4 multicast networks.  CPE has thus until recently supported
   IPv4 only.  As the Internet transitions to IPv6, IPv6-capable



Asaeda, et al.         Expires September 13, 2012               [Page 3]


Internet-Draft        Multicast Transition Overview           March 2012


   equipment will be deployed by content providers and receivers, as
   well as the networks that connect them to one another.  So long as
   all of the newly deployed gear supports both IPv4 and IPv6, the
   transition to IPv6 may not require new IETF protocol specifications
   in support of multicast deployment.  In this case of dual-stack
   environments, either IP address family can be used end to end for the
   multicast traffic.  However, if some of the newly deployed gear
   supports IPv6 only, incompatibilities will be introduced.  These
   IPv6-only scenarios are being planned and deployed because the
   exhaustion of IPv4 unicast address space.  Instead of running large
   NAT and IPv6 all together, some providers prefer to run a single
   address family that is future proof, which is IPv6.  This also brings
   simpler management of the network.  In this unicast case, IPv4
   traffic can be either tunneled over IPv6 (e.g. softwire, dslite, 4rd)
   or translated (NAT64).  Therefore, some access networks are IPv6
   only.

   An incompatibility occurs at a device lying along the path between
   the source and the receiver when the next device on the path on one
   side of it supports a different version of IP from the next device on
   the path on the other side of it (i.e., one device supports IPv4 only
   and the other supports IPv6 only).  For the purposes of this
   document, we will call these points of incompatibility "IP version
   transition points".  The communication path between source and
   receiver (which includes both endpoints) can include zero or more IP
   version transition points.

   IP version transition points may be introduced at any point along the
   path.  These IP version transition points may reside in the
   subscriber premises, at the CPE, in the intervening network etc.  In
   addition, the Set Top Box (STB) and Electronic Program Guides (EPG)
   may have different IP versions.

   In order to maintain multicast connectivity, one or more adaptation
   functions (AF) are required.  The AF operates in both the forwarding
   and control planes.  Because it provides an interface between the
   IPv4 and IPv6 domain, it must be both IPv4-capable and IPv6-capable.

   In most cases, the adaptation function will mediate between IPv4 and
   IPv6 on both the control and forwarding planes.  However, in
   scenarios where the path between source and receiver contains
   multiple IP version transition points, adaptation function instances
   may tunnel traffic between one another.

2.1.  Signaling Channels using Multicast Addresses

   The receiver is provided the necessary multicast addresses for
   channel reception by some means such as an Electronic Program Guide



Asaeda, et al.         Expires September 13, 2012               [Page 4]


Internet-Draft        Multicast Transition Overview           March 2012


   (EPG).  If the source uses the same address family as the receiver,
   the receiver will subscribe to a multicast address of the appropriate
   address family.  However, If the source uses the other address
   family, then the signaling must be translated in the path (or at the
   program guide).

   An early assessment of the market seems to suggest that most
   signaling is done with proprietary protocols, and that most EPG are
   also proprietary.  It remains to be seen if a standardized solution
   for this issue a need or even a possibility, given these market
   realities.

2.2.  Operator View of Use Cases

   Discussion with operators has indicated in the first place that the
   distribution of Electronic Program Guide material is done by
   proprietary means, and they have no interest in a standardized
   solution.  SSM (Specific Source Multicast) is the technically
   preferable mode of operation.  However, some operators may have to
   use ASM (Any Source Multicast) because of the limitations of existing
   receivers (i.e., limitations on the support of IGMP v3 or MLD v2).

   In what follows, this document uses the following numeric convention
   to specify a particular scenario: <receiver version>-<network
   version(s)>-<source version> (e.g., 6-4-6-4 for the second scenario
   described below).

   For a number of operators, the expected evolution path is to first
   upgrade the network to IPv6, then upgrade the receivers to IPv6
   through a gradual process of replacement, and then add IPv6 sources
   when a critical mass of IPv6 receivers is reached.  This sequence
   implies that the immediate priority is to support the 4-6-4 scenario
   shown in Figure 1.  One can immediately see that two instances of the
   AF are needed, one at each side of the IPv6 network.  The receiver
   signals using IGMP.  The AF translates the IGMP either to MLD
   [RFC3810] or to PIM [RFC4601] running on IPv6.  At the other side,
   the AF most likely interworks between PIM with IPv6 and PIM with
   IPv4.  In the reverse direction, multicast data packets can either be
   translated or tunneled between the AF instances, as noted above.












Asaeda, et al.         Expires September 13, 2012               [Page 5]


Internet-Draft        Multicast Transition Overview           March 2012


      +------+      +-----+       +----+       +------+      +-----+
      | Host |      | DS  |       |    |       |  MR  |      |     |
      | Rcvr |------| AF  |       | MR | . . . |      |------| Src |
      |      | IPv4 |     |       |    | IPv4  | (DR) | IPv4 |     |
      +------+      +-----+       +----+       +------+      +-----+
                     /               \
                    / IPv6            \ IPv4
                   /                   \
              +----+      +----+       +------+
              |    |      |    |       |  DS  |
              | MR |------| MR | . . . |  AF  |
              |    | IPv6 |    | IPv6  |      |
              +----+      +----+       +------+

       Rcvr: Multicast receiver
       DS  : Dual Stack
       AF  : Adaptation Function
       MR  : Multicast router
       DR  : Designated Router
       Src : Multicast source

    Figure 1: An Initial Scenario: IPv4 Source and Receiver Via an IPv6
                                  Network

   An alternative view of network evolution contemplates a more
   immediate rollout of IPv6 receivers, but a slow evolution of sources
   from IPv4 to IPv6.  The backbone network will be IPv6 in all cases,
   but the metro network may be either IPv4 or IPv6.  The first case
   (6-4-6-4), with an IPv4 metro network, is shown in Figure 2.  Three
   AF instances are needed, at the IP version transition points between
   the source and backbone network, between the backbone and metro
   network, and between the metro network and the receiver.



















Asaeda, et al.         Expires September 13, 2012               [Page 6]


Internet-Draft        Multicast Transition Overview           March 2012


      +------+      +-----+      +----+      +------+
      | Host |      | DS  |      |    |      |  DS  |
      | Rcvr |------| AF  |------| MR | . . .|  AF  |
      |      | IPv6 |     | IPv4 |    | IPv4 |      |
      +------+      +-----+      +----+      +------+
                                                /
                    ----------------------------
                   /         IPv6
              +----+      +----+       +------+
              |    |      |    |       |  DS  |
              | MR |------| MR | . . . |  AF  |
              |    | IPv6 |    | IPv6  |      |
              +----+      +----+       +------+
                                          /
                 -------------------------
                /        IPv4
               +----+         +------+      +-----+
               |    |         |  MR  |      |     |
               | MR | . . . . |      |------| Src |
               |    |   IPv4  | (DR) | IPv4 |     |
               +----+         +------+      +-----+

      Rcvr: Multicast receiver
      Src : Multicast source
      DS  : Dual Stack
      AF  : Adaptation function
      MR  : Multicast Router
      DR  : Designated Router

   Figure 2: Initial Scenario With IPv6 Host, IPv4 Source, and Both IPv4
                       and IPv6 Intervening Networks

   The case where the metro network has evolved to IPv6 (6-6-4) is shown
   in Figure 3.  Here, only one AF instance is needed.  It translates
   between IPv6 PIM in the receiver network and IPv4 PIM in the content
   provider network.















Asaeda, et al.         Expires September 13, 2012               [Page 7]


Internet-Draft        Multicast Transition Overview           March 2012


      +------+      +-----+      +----+      +------+
      | Host |      | MR  |      |    |      |  DS  |
      | Rcvr |------|     |------| MR | . . .|  AF  |
      |      | IPv6 |(DR) | IPv6 |    | IPv6 |      |
      +------+      +-----+      +----+      +------+
                                                /
                       -------------------------
                      /        IPv4
                     +----+         +------+      +-----+
                     |    |         |  MR  |      |     |
                     | MR | . . . . |      |------| Src |
                     |    |   IPv4  | (DR) | IPv4 |     |
                     +----+         +------+      +-----+

      Rcvr: Multicast receiver
      Src : Multicast source
      DS  : Dual Stack
      AF  : Adaptation function
      MR  : Multicast Router
      DR  : Designated Router

     Figure 3: Initial Scenario With IPv6 Host, IPv4 Source, and IPv6
                            Intervening Network

2.3.  Requirements From The Use Cases

   All three of the immediately relevant scenarios just described
   feature IPv4 sources.  This means that no solution is required in the
   short term for translation from general IPv6 addresses to IPv4
   addresses.  In the longer run operators may have the situation of
   IPv6 sources serving receivers that have remained at IPv4.  That
   presents a more difficult translation problem, but the scenario has
   low priority.

   The three cases illustrate a number of protocol interworking
   combinations.  As indicated below, some combinations can act as a
   part of others, reducing the total development effort.

   In summary, the use cases expose the following gaps for which there
   are no existing IETF standards:

   o  Translating from IPv4 to IPv6 multicast addresses and back again.

   o  Translating from IGMP downstream to MLD upstream (4-6-4 case) and
      from MLD downstream to IGMP upstream (6-4-6-4 case).

   o  Interworking between IGMP and PIM with IPv6 (4-6-4 case).  This
      could be synthesized by translating the IGMP to MLD and having MLD



Asaeda, et al.         Expires September 13, 2012               [Page 8]


Internet-Draft        Multicast Transition Overview           March 2012


      interwork with PIM as usual.

   o  Interworking between MLD and PIM with IPv4 (6-4-6-4 case).  Again,
      this could be synthesized, by translating MLD to IGMP and
      interworking the latter to PIM as usual.

   o  Operating PIM with IPv4 downstream and IPv6 upstream (6-4-6-4
      case) and with IPv6 downstream and IPv4 upstream (4-6-4 and 6-6-4
      cases).


3.  A Look At the Solution Space For Multicast Transition

   The AF operates on both the forwarding and control planes.  On the
   forwarding plane, the AF inserts itself into the forwarding path
   translating multicast packets from one IP version to the other.  On
   the control plane, the AF receives routing and signaling messages of
   one protocol and sends out routing and signaling messages of another
   protocol.[Forward reference to future high-level description of the
   AF.]

3.1.  AF Forwarding Plane Operation

   The AF accepts packets from one IP version, removes the IP header,
   and replaces it with an IP Header of the other version.  A
   significant portion of that task is address translation.  Ideally the
   address translation strategy used by an AF should be algorithmic,
   stateless and reversible.  This should be simple when addresses from
   one IP version can simply be embedded into another (IPv4 into IPv6),
   but this may not be possible in the opposite direction.  That the
   translation is reversible means that there is a stateless algorithm
   for translating back into the original address.

   [RFC6052] provides an algorithm for translating unicast addresses
   between IPv4 and IPv6.  Likewise [I-D.mboned-64-mcast-addr-fmt]
   provides an algorithm for multicast address conversion between IPv4
   and IPv6.  Note that using this algorithm, different translators
   could choose different IPv6 prefixes for embedding the IPv4
   addresses.  But the format allows for stateless translation back to
   the original IPv4 addresses.

   Other issues associated with IP version translation may arise (e.g.,
   fragmentation and checksums and will be resolved as appropriate in
   conjunction with appropriate IETF working groups.







Asaeda, et al.         Expires September 13, 2012               [Page 9]


Internet-Draft        Multicast Transition Overview           March 2012


3.2.  AF Control Plane Operation

   On the control plane, the AF mediates between:

   o  IGMPv3 [RFC3376] and MLDv2 [RFC3810];

   o  PIM(v4) [RFC4601] and PIM(v6);

   o  IGMPv3 and PIM(v6);

   o  MLD and PIM(v4);

   The IGMP-to-MLD translation may be configured to use only IGMPv2
   features.  It is defined in [draft to come].
   [I-D.perreault-mboned-igmp-mld-translation] is a candidate for this
   specification.

   The PIM-to-PIM mediation operates between PIM protocol operations of
   one IP version with operations of the other version.
   [I-D.taylor-pim-v4v6-translation] is a candidate for this
   specification.

3.3.  Source Discovery

   Source discovery is out of scope and is left for further study.
   [I-D.tsou-mboned-multrans-addr-acquisition] provides an informative
   discussion of the options open to operators.

3.4.  Transitional Multicast Path Optimization

   A mechanism to optimize the path to the multicast source for a
   combination of IPv4 and IPv6 networks is not immediately required,
   but is a topic for future work.
   [I-D.zhou-mboned-multrans-path-optimization] is a candidate for this
   specification.


4.  Contributors

   Some of the introductory text of this document was drawn from
   [I-D.jaclee-behave-v4v6-mcast-ps].  Figures from Section 3 of that
   document were the starting point for the figures in Section 2.1 of
   this document.  The strong participation of the authors of
   [I-D.jaclee-behave-v4v6-mcast-ps] in the work on multicast transition
   leading up to the creation of this document must be acknowledged.
   These authors include two co-authors of the present document, plus
   Mohamed Boucadair, Yiu Lee, Hitoshi Asaeda, and Jacni Qin, who should
   be considered honorary co-authors.



Asaeda, et al.         Expires September 13, 2012              [Page 10]


Internet-Draft        Multicast Transition Overview           March 2012


5.  Acknowledgements

   Ron Bonica inspired the writing of this memo and shaped its content.
   Michael McBride and Marc Blanchet provided useful comments on
   intermediate versions of this document.


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   To come.


8.  Informative References

   [I-D.jaclee-behave-v4v6-mcast-ps]
              Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
              Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use
              Cases", draft-jaclee-behave-v4v6-mcast-ps-03 (work in
              progress), October 2011.

   [I-D.mboned-64-mcast-addr-fmt]
              Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
              M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
              in Progress)", March 2012.

   [I-D.perreault-mboned-igmp-mld-translation]
              Perreault, S. and T. Tsou, "Internet Group Management
              Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based
              Multicast Translation ("IGMP/MLD Translation")",
              draft-perreault-mboned-igmp-mld-translation-00 (work in
              progress), February 2012.

   [I-D.taylor-pim-v4v6-translation]
              Taylor, T. and C. Zhou, "A Translator For Protocol
              Independent Multicast (PIM) Interworking Between IPv4 and
              IPv6", draft-taylor-pim-v4v6-translation-00 (work in
              progress), March 2012.

   [I-D.tsou-mboned-multrans-addr-acquisition]
              Clauberg, A., Boucadair, M., Sun, Q., Venaas, S., and T.
              Tsou, "Address Acquisition For Multicast Content When
              Source and Receiver Support Differing IP Versions",
              draft-tsou-mboned-multrans-addr-acquisition-00 (work in



Asaeda, et al.         Expires September 13, 2012              [Page 11]


Internet-Draft        Multicast Transition Overview           March 2012


              progress), February 2012.

   [I-D.zhou-mboned-multrans-path-optimization]
              Sun, Q. and C. Zhou, "Multicast transition path
              optimization in IPv4 and IPv6 networks",
              draft-zhou-mboned-multrans-path-optimization-01 (work in
              progress), March 2012.

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

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

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

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.


Authors' Addresses

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   5322 Endo
   Fujisawa, Kanagawa  252-0882
   Japan

   Email: asaeda@wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~asaeda/


   Marshall Eubanks
   AmericaFree.TV
   P.O. Box 141
   Clifton, VA  20124
   USA

   Phone:
   Email: marshall.eubanks@gmail.com






Asaeda, et al.         Expires September 13, 2012              [Page 12]


Internet-Draft        Multicast Transition Overview           March 2012


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

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com


   Stig Venaas
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Email: stig@cisco.com

































Asaeda, et al.         Expires September 13, 2012              [Page 13]