Internet Engineering Task Force C. Zhou Internet-Draft T. Taylor Intended status: Informational Huawei Technologies Expires: June 18, 2012 December 15, 2011 Specification of a Provider-Managed Adaptive Function Between a Multicast Receiver and a Provider Network Supporting a Different IP Version draft-zhou-multrans-af1-specification-00 Abstract Discussion of the problem of multicast transition has brought out a number of scenarios that are the most likely to be encountered in practice. In some of these scenarios the IP version supported by the multicast receiver differs from that supported by the provider network to which it is attached. In such cases an adaptation function is required between the receiver and the network, to mediate the signalling and data flows between them. This memo uses the term "Type 1 Adaptation Function" (AF1) for such a function. It is written for the purpose of specifying the functions performed by an AF1. The scope of this memo is limited to the case where flows are unidirectional, from a designated set of sources to a designated (and normally much more numerous) set of receivers. The IP television (IPTV) case falls within this scope. 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 June 18, 2012. Copyright Notice Zhou & Taylor Expires June 18, 2012 [Page 1] Internet-Draft Multicast AF1 Specification December 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. AF1 Role In Signalling . . . . . . . . . . . . . . . . . . . . 3 2.1. The Case Of the Customer-Located AF1 . . . . . . . . . . . 4 3. AF1 Role In Data Transfer . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Informative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Zhou & Taylor Expires June 18, 2012 [Page 2] Internet-Draft Multicast AF1 Specification December 2011 1. Introduction Section 3 of [I.D_jaclee-mcast-ps] describes a number of network scenarios that can arise during the transition from IPv4 to IPv6. In some cases the multicast receiver supports a different IP version from the network to which it is attached. As a result, a dual-stack adaptation function, shown as AF1 in the figures of the cited text, is needed to mediate the flow of multicast signalling and content across the IP version boundary. This document specifies in detail what the AF1 does to achieve the multicast flow transmission from the media source to the receiver in the above scenarios. This document restricts itself to scenarios involving flows of multicast content from sources to receivers, where the set of sources is distinct from the set of receivers. It is also restricted to scenarios where the node implementing the AF1 is managed by the provider rather than the customer. Subject to this restriction, both location of the AF1 in the customer network and location of the AF1 at the provider edge are considered. 1.1. Requirements Language This document contains no requirements language. 2. AF1 Role In Signalling If the AF1 is located at the provider edge, its role is straightforward. It serves as a multicast router terminating IGMP as specified in [RFC3376], or terminating MLD as specified in [RFC3810]. The one special operation performed by AF1 is to map source and group addresses received from receivers supporting a different IP version into the IP version used by the network before entering them into its group management database or propagating them in messages to other network multicast routers. It performs the reverse mapping for outgoing messages to the receiver. The mapping used is the same as that used to derive the source and group addresses sent to the receiver in advance of program selection by the user. Advance address acquisition by the receiver is discussed in a companion document, [I-D_tsou-addr-acquisition]. The mapping may also underly the creation of the multicast routing tables, as discussed in another companion document, [I-D_tsou-AF2-specification]. For the cases of immediate interest, it is likely that a stateless mapping can be used, for example, [I-D_boucadair-stateless-multicast] for the multicast group addresses and [RFC6052] for source addresses. Zhou & Taylor Expires June 18, 2012 [Page 3] Internet-Draft Multicast AF1 Specification December 2011 2.1. The Case Of the Customer-Located AF1 If the AF1 is located on the customer premises, the situation for signalling is slightly more complicated. The AF1 will use a multicast signalling protocol (IGMP or MLD or possibly PIM) to send the multicast request into the network. It terminates messages of another protocol (MLD or IGMP) from the receiver (e.g., STB). The multicast request sent by AF1 to the network will include the source and group addresses converted by AF1. If the AF1 signals PIM toward the network, the situation is as described above for an AF1 located at the provider edge. If it terminates IGMP from the receiver and signals MLD to the network or vice versa, it acts as an IGMP (respectively MLD) proxy [RFC4605] to the receiver. From the point of view of the network, the AF1 is an MLD or IGMP receiver, respectively. In passing from one of these roles to the other, the AF1 has to map the multicast source and group addresses as already discussed. Note that for MLD messages incoming from the AF1 to the network, [RFC3810] Section 7.6 requires that the source address in the packet header must be a valid link-local address on that link. 3. AF1 Role In Data Transfer The AF1 role in data transfer is also straightforward, and is independent of the location of the AF1. The AF1 is configured either to translate the headers of incoming packets of multicast content from the source to the version supported by the receiver or to decapsulate these packets. Encapsulation is clearly efficient in a scenario where the source and receiver support one IP version and the intervening network supports another. However, encapsulation becomes operationally difficult when the network evolves to a mixture of IPv4 and IPv6 receivers. In that case, since the receivers cannot, without change, perform decapsulation themselves, it is necessary to have a vestigial AF1 function in front of all receivers. This vestigial function does not have to perform address mapping for the signalling and multicast content it processes, but does have to supply the missing decapsulation capability. 4. Acknowledgements TBD. Zhou & Taylor Expires June 18, 2012 [Page 4] Internet-Draft Multicast AF1 Specification December 2011 5. Contributors Tina Tsou provided the framework within which these ideas were developped. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations To come. 8. Informative References [I-D_boucadair-stateless-multicast] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", October 2011. [I-D_tsou-AF2-specification] Taylor, T. and C. Zhou, "Specification of an Adaptation Function Between Two Multicast Networks Supporting Different IP Versions", December 2011. [I-D_tsou-addr-acquisition] Tsou, T., "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", December 2011. [I.D_jaclee-mcast-ps] Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use Cases", October 2011. [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. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding Zhou & Taylor Expires June 18, 2012 [Page 5] Internet-Draft Multicast AF1 Specification December 2011 ("IGMP/MLD Proxying")", RFC 4605, 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 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: tom.taylor.stds@gmail.com Zhou & Taylor Expires June 18, 2012 [Page 6]