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]