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

Versions: 00                                                            
Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Informational                                   C. Zhou
Expires: February 26, 2012                                     T. Taylor
                                                     Huawei Technologies
                                                             R. Maglione
                                                          Telecom Italia
                                                         August 25, 2011


          Use Cases For Multicast Transition From IPv4 to IPv6
                    draft-tsou-multrans-use-cases-00

Abstract

   Like other internet activities, multicast is affected by the fact
   that the transition from IPv4 to IPv6 is occurring over a period of
   years, via multiple transition paths.  As a result, mechanisms need
   to be added to the basic multicast architecture to assist in specific
   transition scenarios.  This document describes detailed use cases so
   that the requirements for the multicast transition mechanisms can be
   better understood.

   The considered opinion in discussions to date on multicast transition
   requirements has been that the two most important transition
   scenarios in the near future will be the "4-6-4" and "6-4" network
   scenarios.  These scenarios are described in detail below, in their
   several possible variants, showing the new issues that IPv6
   transition raises for multicast operation.

   There is further general agreement that Any-Source Multicast (ASM)
   (the service, not necessarily the technology) is no longer an
   important use case.  As a result, this document restricts itself to
   scenarios where the set of multicast sources is separate from the set
   of multicast receivers.  As a final restriction, it assumes a single
   administrative provider domain.

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



Tsou, et al.            Expires February 26, 2012               [Page 1]


Internet-Draft     Use Cases For Multicast Transition        August 2011


   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 February 26, 2012.

Copyright Notice

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































Tsou, et al.            Expires February 26, 2012               [Page 2]


Internet-Draft     Use Cases For Multicast Transition        August 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Stages of Multicast Channel Acquisition  . . . . . . . . . . .  5
   3.  The 4-6-4 Network Scenario . . . . . . . . . . . . . . . . . .  6
     3.1.  The 4-6-4 Network Scenario With Interworking At the
           Customer Edge  . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  The 4-6-4 Scenario Where Interworking Is Done At the
           Provider Edge  . . . . . . . . . . . . . . . . . . . . . .  9
   4.  The 6-4 Network Scenario . . . . . . . . . . . . . . . . . . . 11
     4.1.  The 6-4 Scenario With IPv6 Access Network  . . . . . . . . 11
     4.2.  The 6-4 Scenario With IPv4 Access Network  . . . . . . . . 11
   5.  The 6-4-6 Network Scenario . . . . . . . . . . . . . . . . . . 11
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14





























Tsou, et al.            Expires February 26, 2012               [Page 3]


Internet-Draft     Use Cases For Multicast Transition        August 2011


1.  Introduction

   Work on multicast transition from IPv4 to IPv6 has been in progress
   for several years, but has not yet resulted in the standardization of
   any specific transitional solutions.  For a slightly dated survey of
   this work, see [ID.Multrans-Taxonomy].  More recently,
   [ID.Multrans-Problem-Statement] was created to advance discussion of
   the topic.

   Discussion of multicast transition has concluded that at the time of
   writing, the primary multicast service of interest is Specific-Source
   Multicast (SSM).  Hence this document assumes that multicast sources
   and multicast receivers are separate entities.  Furthermore, the most
   important network scenarios for multicast transition are summarized
   by the expressions "4-6-4" and "6-4".  These scenarios are described
   in detail below.  The numbers, of course, refer to the IP versions
   supported by the multicast receiver, the intervening provider
   network, and the multicast source.  Initial interest is limited to a
   single-provider scenario, where multicast sources, the intervening
   network, and multicast receivers are all under common administrative
   control.

   The purpose of the present document is to spell out the use cases for
   multicast transition within the boundaries just described.  In this
   role, this document provides more detail than
   [ID.Multrans-Problem-Statement] on the message flows and interworking
   details involved, but stops short of the solution detail provided by,
   for instance, [ID.Multrans-DS-Lite].

   In each network scenario, it is assumed that bandwidth is a valuable
   resource, and hence that the network supports a shared tree multicast
   routing infrastructure.  [RFC5110] provides a snapshot of the
   multicast routing architecture as of three years ago.  The present
   document assumes that deployments have evolved to provide full
   support for SSM, and hence that hosts and multicast routers support
   IGMPv3 [RFC3376], MLDv2 [RFC3810], and PIM-SM [RFC4601] as
   applicable.

   It is reasonable to expect that replication of multicast content at
   Layer 2 is controlled for scalability and other reasons.  However,
   this document does not currently include descriptions of actions down
   to the Later 2 level.

1.1.  Requirements Language

   This document is purely descriptive, and contains no normative
   language.




Tsou, et al.            Expires February 26, 2012               [Page 4]


Internet-Draft     Use Cases For Multicast Transition        August 2011


2.  Stages of Multicast Channel Acquisition

   As [RFC5110] and [ID.Multrans-Problem-Statement] indicate, an SSM
   receiver acquires a given multicast channel in three stages.  In the
   first stage, it acquires the source and group addresses that specify
   the channel.  In the second stage, it indicates its interest in
   receiving the channel through multicast signalling, using IGMP
   [RFC3376] or MLD [RFC3810].  This signalling is propagated into the
   network using PIM-SM [RFC4601] between multicast routers, to add the
   receiver to the multicast distribution tree that exists for that
   source.  Once this has been completed, the third stage consists of
   delivery of the packets of content for the selected channel, from the
   source to the receiver.

   The details of operation in the second and third stages are closely
   tied to the network scenario being considered, and hence are
   described below.  However, the stage of address acquisition lends
   itself to a more general discussion and can be dealt with at this
   point.

   The goal of the address acquisition stage is for the receiver to
   acquire a unicast source address and multicast group address with
   which it may then proceed to request the desired channel.  A variety
   of means can be used to achieve this.  The receiver may simply be
   configured in advance with a listing of addresses for the channels to
   which the subscriber is allowed access.  Session signalling (SIP
   [RFC3261] plus SDP [RFC4566]) may be used.  The information may be
   provided by an announcement protocol such as SAP [RFC2974], or it may
   be accessible through a proprietary program guide over HTTP.
   Depending on the network scenario, delivery of this information to
   the receiver across IP version boundaries may be more or less
   complicated, but the details will depend very much on the particular
   deployment.

   What is important here is not those details, but the constraints that
   the address acquisition process must satisfy so that the remaining
   stages can be carried out successfully.  The first of these
   constraints is that the IP version of the source and group addresses
   that the receiver obtains must be understood by the receiver.  Thus
   in the 4-6-4 scenario these addresses must reach the receiver as IPv4
   addresses.  In the 6-4 scenario, they must reach the receiver as IPv6
   addresses, even though the source itself supports IPv4.  The
   assumption that we are operating in a single administrative domain
   simplifies this task, since AAA can supply details of the
   subscription including what IP version is supported by the customer
   site.

   The second constraint looks forward to the succeeding stages.  The



Tsou, et al.            Expires February 26, 2012               [Page 5]


Internet-Draft     Use Cases For Multicast Transition        August 2011


   source and group addresses that the receiver acquires must be valid
   for the receiver to use in requesting to join the shared distribution
   tree for the channel concerned.  That is, whenever the multicast
   signalling initiated by the receiver crosses an IP version boundary,
   these addresses must be consistently mappable to addresses in the new
   version that correspond to the same multicast channel.  In the final
   stage, the incoming multicast content must be presented to the
   receiver with the same spource and group addresses that it acquired
   in the first stage, regardless of what transformations those
   addresses underwent on the path from the source to the receiver.
   These requirements will become apparent as we walk through the
   detailed use cases in the next few sections.


3.  The 4-6-4 Network Scenario

   The 4-6-4 network scenario assumes that the multicast source and
   receivers both support IPv4.  The intervening network supports IPv6.
   There are two primary sub-cases, based on the location of the
   boundary between IPv4 and IPv6 on the receiver side.  On the source
   side, that boundary is always assumed to be at the network edge.

   o  The interworking between IPv4 and IPv6 occurs in a device at the
      customer edge.  This is described in Section 3.1.

   o  The interworking between IPv4 and IPv6 occurs at the provider
      edge.  This is described in Section 3.2.

   The following sections walk through stage 2 and stage 3 for each of
   these two sub-cases in turn.

3.1.  The 4-6-4 Network Scenario With Interworking At the Customer Edge

   This case assumes that a dual stack device exists at the customer
   edge, offering an IPv4 interface to the receiver and an IPv6
   interface to the network.  Figure 1 illustrates the signalling path
   for this case.














Tsou, et al.            Expires February 26, 2012               [Page 6]


Internet-Draft     Use Cases For Multicast Transition        August 2011


   +------+      +----+       +------+         +------+
   | Host | IGMP | DS |       |  MR  |   PIM   |  MR  |
   | Rcvr |------| CE |       |      | . . . . |      |
   |      | IPv4 |    |       | (BG) |   IPv4  | (DR) |
   +------+      +----+       +------+         +------+
                  /               \
             MLD / IPv6        PIM \ IPv4
                /                   \
         +------+      +----+       +------+
         |  MR  |  PIM |    | PIM   |  DS  |
         |      |------| MR | . . . |  MR  |
         | (DR) | IPv6 |    | IPv6  | (BG) |
         +------+      +----+       +------+

             ------------------------------------->

   Rcvr: Multicast receiver
   DS  : Dual stack
   CE  : Customer edge router (RFC 4605 compliant)
   MR  : Multicast router
   DR  : Designated router
   BG  : Border gateway

    Figure 1: Multicast Signalling When Interworking Is At the Customer
                           Edge (4-6-4 Scenario)

   The multicast signalling sequence illustrated in Figure 1 begins when
   the receiving host sends an IGMP Membership Report message toward the
   network.  The message contains the IPv4 multicast group and unicast
   source addresses that the receiver acquired in stage 1.  The
   destination address is 224.0.0.22, as specified in Section 4.2.14 of
   [RFC3376].

   The dual stack Customer Edge device, acting as an IGMP/MLD Proxy
   [RFC4605], terminates the IGMP Membership Report message.  It
   interworks it to an MLD Listener Report message.  The IPv4 source and
   group addresses from the IGMP message are mapped to IPv6 addresses
   corresponding to the same multicast channel within the IPv6 network,
   and placed into the MLD Listener Report.  The need for coordination
   with the network means that the mapping has to be provided by the
   network operator, either directly or through configuration of an
   algorithm and associated parameters.  This implies some operator
   control over the implementation of the Customer Edge device.  The
   Customer Edge device sends the MLD Listener Report over an IPv6 link
   toward the network, with a destination address of FF02::16 as
   specified by Section 5.2.14 of [RFC3810].

   At the network edge, the Designated Router [RFC4601] for the customer



Tsou, et al.            Expires February 26, 2012               [Page 7]


Internet-Draft     Use Cases For Multicast Transition        August 2011


   site terminates the MLD Listener Report.  It updates its internal
   state, then, as required, issues a PIM-SM (IPv6) Join message toward
   the next multicast router en route to the source.  Signalling is
   propagated until it joins the existing tree for the given channel, or
   reaches the dual stack border device shown as "DS MR (BG)" in the
   figure.  To make this happen, the operator must configure the
   necessary routing information in advance.

   At the dual stack border device, the IPv6 source and group addresses
   are mapped in their turn to the IPv4 source and group addresses
   corresponding to the desired channel in the IPv4 network.  The new
   IPv4 addresses do not necessarily have to be the same as those
   provided to the receiver in the address acquisition stage.  Note that
   this operation requires coordination between the IPv6 and IPv4
   networks.  The incoming PIM (IPv6) Join message is interworked to a
   PIM (IPv4) Join message directed to the multicast router at the
   border of the IPv4 network.  The PIM messaging continues to propagate
   through the IPv4 network, if necessary, until it ends up at the
   Designated Router serving the source.

   Figure 2 shows the path taken by content emitted by the source.

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

             <-------------------------------------

   Rcvr: Multicast receiver
   DS  : Dual stack
   CE  : Customer edge router (RFC 4605 compliant)
   MR  : Multicast router
   DR  : Designated router
   BG  : Border gateway
   Src : Multicast source

    Figure 2: Content Distribution When Interworking Is At the Customer
                           Edge (4-6-4 Scenario)



Tsou, et al.            Expires February 26, 2012               [Page 8]


Internet-Draft     Use Cases For Multicast Transition        August 2011


   Content distribution starts at the source, which sends an IPv4 packet
   of content with its own source address and the destination address
   equal to that of the multicast group.  The packet is routed through
   the tree previously set up in the IPv4 network, eventually reaching
   the edge of the IPv6 network.  The dual stack node at that network
   edge maps the incoming IPv4 source and group addresses to the
   corresponding IPv6 addresses used for that channel in the IPv6
   network.  These are the same addresses used in the signalling stage.

   At this point, the dual stack border element can take one of two
   actions.  Either it encapsulates the original IPv4 packet in an IPv6
   header that uses the mapped IPv6 addresses as source and destination,
   or it translates incoming IPv4 header to an IPv6 header, also using
   the mapped addresses.  The choice is a deployment decision.  The
   result in either case is an IPv6 packet which is forwarded through
   the IPv6 network along the tree set up by previous signalling.

   Eventually the packet reaches the dual stack customer edge device.
   If the packet it receives was encapsulated, it only needs to
   decapsulate the packet.  If instead the packet header was translated
   from IPv4 to IPv6, the customer edge device must now map the incoming
   IPv6 source and group addresses to the IPv4 counterparts used to
   request the channel in the signalling stage and then perform the
   reverse translation.  In either case it forwards the resulting packet
   to the receiver.

3.2.  The 4-6-4 Scenario Where Interworking Is Done At the Provider Edge

   This case assumes that the multicast router at the provider edge is a
   dual stack device offering an IPv4 interface to the customer site.
   The signalling path is shown in Figure 3.




















Tsou, et al.            Expires February 26, 2012               [Page 9]


Internet-Draft     Use Cases For Multicast Transition        August 2011


   +------+                   +------+         +------+
   | Host |                   |  MR  |   PIM   |  MR  |
   | Rcvr |                   |      | . . . . |      |
   |      |                   | (BG) |   IPv4  | (DR) |
   +------+                   +------+         +------+
       \                          \
   IGMP \ IPv4                 PIM \ IPv4
         \                          \
         +------+      +----+       +------+
         |  DS  |  PIM |    | PIM   |  DS  |
         |  MR  |------| MR | . . . |  MR  |
         | (DR) | IPv6 |    | IPv6  | (BG) |
         +------+      +----+       +------+

             ------------------------------------->

   Rcvr: Multicast receiver
   DS  : Dual stack
   MR  : Multicast router
   DR  : Designated router
   BG  : Border gateway

    Figure 3: Multicast Signalling When Interworking Is At the Provider
                           Edge (4-6-4 Scenario)

   [Signalling description -- can just give delta with respect to
   previous section]

   Figure 4 shows the path taken by content emitted by the source.






















Tsou, et al.            Expires February 26, 2012              [Page 10]


Internet-Draft     Use Cases For Multicast Transition        August 2011


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

             <-------------------------------------

   Rcvr: Multicast receiver
   DS  : Dual stack
   MR  : Multicast router
   DR  : Designated router
   BG  : Border gateway
   Src : Multicast source

    Figure 4: Content Distribution When Interworking Is At the Provider
                           Edge (4-6-4 Scenario)


4.  The 6-4 Network Scenario

4.1.  The 6-4 Scenario With IPv6 Access Network

   In this scenario, the IPv6 receiver receives multicast content from
   an IPv4 source, where signalling and content must pass through an
   IPv6 network to which the receiver is attached.

4.2.  The 6-4 Scenario With IPv4 Access Network

   In this scenario, the IPv6 receiver receives multicast content from
   an IPv4 source, where the receiver is attached to the IPv4 network.


5.  The 6-4-6 Network Scenario

   An alternative use case is the scenario where both the receivers and
   the source are IPv6 capable, but the IPv6 connectivity among them is
   provided over an IPv4-Only Network running Multiprotocol Label
   Switching (MPLS).  MPLS is a well understood and widely deployed
   protocol in Service Provider's backbone networks: being able to



Tsou, et al.            Expires February 26, 2012              [Page 11]


Internet-Draft     Use Cases For Multicast Transition        August 2011


   transport IPv6 traffic over an IPv4 MPLS network allows the Service
   Providers to provide IPv6 connectivity to the edge of the network and
   thus to offer IPv6 services, without having to upgrade to IPv6 the
   backbone network.

   RFC 4798 tackles the unicast angle of the problem and it explains how
   to interconnect IPv6 islands over a Multiprotocol Label Switching
   (MPLS)-enabled IPv4 cloud by using Multiprotocol Border Gateway
   Protocol (MP-BGP) to exchange the IPv6 reachability information
   transparently.  The devices implementing this mechanism are called
   IPv6 Provider Edge routers (6PE).  The 6PE technique is currently
   deployed for unicast traffic in several Service Provider's networks.

   A similar approach would be useful for multicast services too, in
   order to allow the Service Providers to start offering IPv6 multicast
   contents (from its own multicast sources or provided by external
   Content Providers) to new IPv6 customers.  This mechanism would allow
   the Service Providers to replicate for multicast contents, the same
   architectural model currently deployed for unicast traffic with 6PE
   method.  In addition as this model does not require any translation
   or interworking function it is expected it would be able to preserve
   the service quality and the integrity of contents.


6.  Conclusions


7.  Acknowledgements


8.  IANA Considerations

   This memo includes no request to IANA.


9.  Security Considerations

   All drafts are required to have a security considerations section.


10.  References

10.1.  Normative References

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




Tsou, et al.            Expires February 26, 2012              [Page 12]


Internet-Draft     Use Cases For Multicast Transition        August 2011


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

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

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC5110]  Savola, P., "Overview of the Internet Multicast Routing
              Architecture", RFC 5110, January 2008.

10.2.  Informative References

   [ID.Multrans-DS-Lite]
              Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y.
              Lee, "Multicast Extensions to DS-Lite Technique in
              Broadband Deployments (Work in Progress)", June 2011.

   [ID.Multrans-Problem-Statement]
              Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
              Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use
              Cases (Work in Progress)", June 2011.

   [ID.Multrans-Taxonomy]
              Tsou, T., Zhou, C., and T. Taylor, "A Classification and
              Evaluation of Approaches to Transitional Multicast (Work
              in Progress)", March 2011.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.






Tsou, et al.            Expires February 26, 2012              [Page 13]


Internet-Draft     Use Cases For Multicast Transition        August 2011


Authors' Addresses

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

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


   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: cathy.zhou@huawei.com


   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   Canada

   Email: tom111.taylor@bell.net


   Roberta Maglione
   Telecom Italia


   Email: roberta.maglione@telecomitalia.it















Tsou, et al.            Expires February 26, 2012              [Page 14]