Internet Engineering Task Force T. Tsou Internet-Draft Huawei Technologies (USA) Intended status: Standards Track T. Taylor Expires: July 21, 2011 C. Zhou Huawei Technologies H. Ji China Telecom January 17, 2011 A Generic Approach to Multicast Translation In Support of IPv6 Transition draft-tsou-behave-translated-multicast-00 Abstract Consider a situation which will arise in many IPv6 transition scenarios, where Network A, to which a host is attached, supports one IP version, but the host and Network B support a different IP version. Suppose that the host wishes to access a multicast group which is rooted or sourced in Network B. This document specifies a stateful translation mechanism whereby the host can obtain its desired access using the native multicast capabilities of Network A. 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 July 21, 2011. 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 Tsou, et al. Expires July 21, 2011 [Page 1] Internet-Draft Generic Multicast Translation January 2011 (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. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. How It Works . . . . . . . . . . . . . . . . . . . . . . . 5 4. Operational Considerations . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Mapping Request Protocol . . . . . . . . . . . . . . . . . . . 7 7. Operational Considerations . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Tsou, et al. Expires July 21, 2011 [Page 2] Internet-Draft Generic Multicast Translation January 2011 1. Introduction Transition scenarios have been explored in which an IPv6 host attached to an IPv4 network wishes to access content in an IPv6 network, or conversely, an IPv4 host attached to an IPv6 network wishes to access content in an IPv4 network. A long list of tools has been put forward for passing unicast content across the network in the middle, based either on tunneling or on translation. Some work has also been done on conveying multicast streams between IPv4 and IPv6 networks, in either direction. Of particular interest is current work in [ID.venaas-mcast46], which was the original inspiration for the content of the present document. However, the present document differs from [ID.venaas-mcast46] both in point of view and in the detailed mechanism used for translation. [ID.boucadair-64-multicast] presents a different approach, relying like [ID.venaas-mcast46] on specially constructed multicast addresses. The present document presents no such restriction. Instead it makes use of the fact that for a given network, it is unnecessary to map the complete universe of IPv6 addresses into IPv4, but only those addresses actually being carried through the network. 1.1. 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]. 2. Problem Description We consider, as described in the previous section, a host supporting one IP version, say IPvx, attached to a provider network supporting a different version, say IPvy. Obviously there has to be an adaptation function between the host and the network to make this work. We distinguish between the unicast and multicast adaptation functions, where multicast adaptation by definition processes both signalling and the actual media streams. This document is not concerned with the mechanism (tunneling, translation) used for unicast adaptation, but specifies the host-side multicast adaptation mechanism as part of the proposed solution. On the other side of the provider network, border gateways connect to neighbouring networks. If a particular neighbouring network supports a different version of IP -- that is, IPvx, then the border gateway must also implement adaptation functions. This document is specifically interested in the border multicast adaptation function. Tsou, et al. Expires July 21, 2011 [Page 3] Internet-Draft Generic Multicast Translation January 2011 Note that when tunneling is used to carry IPvx traffic across the provider network, the adaptation functions on the host and border gateway sides of the provider network are complementary. As a result, the border gateway has to implement a different adaptation function for flows to and from IPvx hosts from what it implements for flows to and from IPvy (i.e., native) hosts. The basic situation just described is illustrated in Figure 1. The host-side adaptation functions MAY be implemented in the host itself, in a separate piece of equipment at the customer site (CPE-based approach), or at the provider edge (gateway initiated approach). +------------+ | | +------------+ | | Host-side | | | | Border | | +----| unicast |------------------| unicast |---- / | adaptation | | | | adaptation | | +----+ / | function | | | | functions | | |IPvx|/ +------------+ | IPvy | +------------+ | IPvx |Host|\ | Provider | | Network +----+ \ +------------+ | Network | +------------+ | \ | Host-side | | | | Border | | \ | multicast | |Signalling| | multicast | | +---| adaptation |---|----------|---| adaptation |---|- | | function | | | | function | | +---| (HMAF) |------------------| (BMAF) |---- +------------+ | Media | +------------+ | Figure 1: Adaptation Functions For Flows Crossing Two IP Version Boundaries The key assumption of this document is that when the host wishes to acquire a multicast stream rooted or sourced in the IPvx network, it knows only the IPvx address pair (where the source MAY be wild-carded, i.e., for an any-source multicast group). It learns that address pair by means outside the scope of this specification (e.g., via the web or session signalling). As a result, the host-side multicast adaptation function (HMAF) needs to obtain a mapping between this IPvx address pair and the corresponding IPvy address pair used in the IPvy network to denote the same multicast stream. Similarly, the border multicast adaptation function (BMAF) needs this mapping so it can do its job. Tsou, et al. Expires July 21, 2011 [Page 4] Internet-Draft Generic Multicast Translation January 2011 3. Proposed Solution The proposed solution consists of three elements: o a stateful mapping function within the IPvy provider network that provides mappings between IPvx address pairs and corresponding IPvy address pairs denoting the same multicast flows; o address pools of IPvy multicast and unicast addresses provisioned at the mapping function; o a protocol that allows the HMAF and BMAF to request mappings from the mapping function. PCP [ID.port-control-protocol] is a candidate for this protocol, but that decision needs further consideration. 3.1. How It Works 1. Initial discovery and Join request The IPvx host discovers the address pair of a multicast stream the user wants to receive. The IPvx Host sends an MLDv2 [RFC3810] (for IPv6) or IGMPv3 [RFC3376] (for IPv4) Join request to the HMAF to acquire the stream. 2. Address Mapping At the HMAF The HMAF checks its cache of mappings to see if it already has a mapping between the IPvx address pair received in the host request and a corresponding pair of IPvy addresses. Failing to find a mapping, it sends a request for the required mapping to the mapping function. The mapping function in turn checks whether it has already created the mapping. If not, it assigns unicast and multicast IPvy addresses from its pool and records the mapping for further use. In either case it returns the requested mapping to the HMAF, which caches it. [Editor's Note: The transaction is carried out over a protocol to be specified in a later version of this document.] 3. Propagation Of the Join Request Into the IPvy Network Using the mapping it has received, the HMAF interworks from MLDv2 to IGMPv3 or vice versa, depending on whether the host supports IPv6 or IPv4. It forwards the interworked Join request to the Provider IP Edge. Tsou, et al. Expires July 21, 2011 [Page 5] Internet-Draft Generic Multicast Translation January 2011 If the HMAF is collocated with the Provider IP Edge, this interworking step is an internal operation. The Provider IP Edge acts on the received request by interworking it to a Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] request and forwarding that request into the IPvy network, indicating the IPvy address pair it was given and ensuring that it is on the multicast tree for the stream concerned. Assuming that the multicast tree for the requested stream is not joined at an earlier point in the provider network, eventually the PIM request finds its way to the BMAF. It has been suggested that the border gateway in which the BMAF resides can be made a PIM-SM rendezvous point (RP) to ensure that requests for new groups reach it. 4. Remapping the Address Pair At the BMAF The BMAF needs to map from the IPvy address pair it received back to the corresponding IPvx address pair before propagating the PIM request into the IPvx network. It sends a request to the mapping function to provide that mapping. The mapping function already has this mapping, as a result of the original HMAF request, and returns it to the BMAF. [Editor's note: protocol again to be specified later. It can probably be the same as the one used by the HMAF. Have to work out the security considerations.] 5. Propagation Of the PIM Request Into the IPvx Network The BMAF propagates translates the PIM request from IPvy to IPvx using the mapping it received. It propagates the request into the IPvx network to complete the construction of the path for the requested multicast stream. If path construction fails, the BMAF SHOULD notify the mapping function so it can mark the IPvx address pair as bad (so it doesn't get remapped) while releasing the assigned IPvy addresses. 6. Transport of Multicast Media and Unicast RTCP Feedback If the BMAF receives a multicast packet from the IPvx network, it translates the source and group addresses to IPvy using the mapping it has retained from Step 4. It then forwards it to the next hop in the multicast tree for that stream. When the HMAF receives a multicast packet from the IPvy network, it translates the packet to IPvx using the mapping which it has retained from Step 2. Tsou, et al. Expires July 21, 2011 [Page 6] Internet-Draft Generic Multicast Translation January 2011 When the IPvx host sends unicast RTCP [RFC3550] feedback toward the source, the packets are handled like any other unicast packets. That is, they are processed by the unicast adaptation functions rather than the HMAF and BMAF. Finally, if the IPvx Host emits multicast packets destined for an any-source multicast group, the HMAF and BMAF translate the packets from IPvx to IPvy and back again using the mappings they have retained. 4. Operational Considerations Maybe in the next version. 5. Acknowledgements This draft started out as draft-tsou-softwire-6rd-multicast-00. Thanks to Joel Halpern for suggesting that it be written as a more general document, since it did not really depend on 6rd. Thanks to Yiu Lee for further comments, which have been used to improve the document. 6. Mapping Request Protocol To come. 7. Operational Considerations The proposal presented here incurs the operational expense of provisioning the multicast and unicast address pools at the mapping function. Proper functioning of the system requires that the operator estimate the total number of different IPvx multicast groups and, for source-specific multicast, the total number of individual IPvx sources it wishes to enable simultaneously. 8. IANA Considerations This memo currently includes no request to IANA. 9. Security Considerations To come. Tsou, et al. Expires July 21, 2011 [Page 7] Internet-Draft Generic Multicast Translation January 2011 10. References 10.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. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 10.2. Informative References [ID.boucadair-64-multicast] Boucadair, M., Qin, J., and Y. Lee, "IPv4-Embedded IPv6 Multicast Address Format", December 2010. [ID.port-control-protocol] Wing, D., "Port Control Protocol (PCP)", January 2011. [ID.venaas-mcast46] Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An IPv4 - IPv6 multicast translator", December 2010. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Tsou, et al. Expires July 21, 2011 [Page 8] Internet-Draft Generic Multicast Translation January 2011 Authors' Addresses Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tena@huawei.com URI: http://tinatsou.weebly.com/contact.html Tom Taylor Huawei Technologies 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Phone: +1 613 680 2675 Email: tom111.taylor@bell.net Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathyzhou@huawei.com Hui Ji China Telecom NO19.North Street Beijing, Chaoyangmen,Dongcheng District P.R. China Phone: Email: jihui@chinatelecom.com.cn Tsou, et al. Expires July 21, 2011 [Page 9]