idnits 2.17.1 draft-zhou-multrans-af1-specification-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2012) is 4417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4605' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 210, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Zhou 3 Internet-Draft T. Taylor 4 Intended status: Informational Huawei Technologies 5 Expires: September 14, 2012 J. Sun 6 China Telecom 7 March 13, 2012 9 Specification of a Provider-Managed Adaptive Function Between a 10 Multicast Receiver and a Provider Network Supporting a Different IP 11 Version 12 draft-zhou-multrans-af1-specification-01 14 Abstract 16 Discussion of the problem of multicast transition has brought out a 17 number of scenarios that are the most likely to be encountered in 18 practice. In some of these scenarios the IP version supported by the 19 multicast receiver differs from that supported by the provider 20 network to which it is attached. In such cases an adaptation 21 function is required between the receiver and the network, to mediate 22 the signalling and data flows between them. This memo uses the term 23 "Type 1 Adaptation Function" (AF1) for such a function. It is 24 written for the purpose of specifying the functions performed by an 25 AF1. 27 The scope of this memo is limited to the case where flows are 28 unidirectional, from a designated set of sources to a designated (and 29 normally much more numerous) set of receivers. The IP television 30 (IPTV) case falls within this scope. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 14, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. AF1 Role In Signalling . . . . . . . . . . . . . . . . . . . . 3 68 3. AF1 Role In Data Transfer . . . . . . . . . . . . . . . . . . . 4 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 73 8. Informative References . . . . . . . . . . . . . . . . . . . . 5 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 Section 3 of [I.D_jaclee-mcast-ps] describes a number of network 79 scenarios that can arise during the transition from IPv4 to IPv6. In 80 some cases the multicast receiver supports a different IP version 81 from the network to which it is attached. As a result, a dual-stack 82 adaptation function, shown as AF1 in the figures of the cited text, 83 is needed to mediate the flow of multicast signalling and content 84 across the IP version boundary. This document specifies in detail 85 what the AF1 does to achieve the multicast flow transmission from the 86 media source to the receiver in the above scenarios. 88 This document restricts itself to scenarios involving flows of 89 multicast content from sources to receivers, where the set of sources 90 is distinct from the set of receivers. It is also restricted to 91 scenarios where the node implementing the AF1 is managed by the 92 provider rather than the customer. Subject to this restriction, both 93 location of the AF1 in the customer network and location of the AF1 94 at the provider edge are considered. 96 2. AF1 Role In Signalling 98 If the AF1 is located at the provider edge, its role is 99 straightforward. It serves as a multicast router terminating IGMP as 100 specifed in [RFC3376], or terminating MLD as specified in [RFC3810]. 101 The special aspect of the AF1 is that the network supports a 102 different IP version from the incoming signalling from the receiver, 103 so IGMP interworks with PIM/IPv6, and MLD interworks with PIM/IPv4. 105 [ID.perreault-igmp-mld-translation] specifies interworking between 106 IGMP and MLD. Conceptually, IGMP can be interworked with MLD as an 107 operation interior to the AF1, and then the MLD interworks with PIM/ 108 IPv6 in the usual fashion. Similarly, MLD incoming from the receiver 109 can be interworked to IGMP, which then is interworked in the usual 110 fashion with PIM/IPv4. 112 [ID.perreault-igmp-mld-translation] specifies the address mapping 113 procedures that are required as part of the interworking. The 114 address mappings used must be coordinated with other aspects of the 115 multicast subscription process. As one example, the multicast group 116 address (and source address if applicable) that are acquired by the 117 receiver in advance of the request for a given multicast stream must 118 obviously correspond to the desired stream after mapping. 119 [I-D_tsou-addr-acquisition] discusses ways in which this can be 120 brought about. There are also implications for routing and for 121 further translations deeper into the network, but these are better 122 reserved for another document (see [I-D_tsou-AF2-specification]). 124 If the AF1 is located on the customer premises, the situation for 125 signalling is slightly simpler. Interworking is between IGMP and MLD 126 in one direction or the other, and 127 [ID.perreault-igmp-mld-translation] provides a complete 128 specification. The same considerations on address mapping that were 129 brought forward in the previous paragraph still apply. 131 Note that for MLD messages incoming from the AF1 to the network, 132 [RFC3810] Section 7.6 requires that the source address in the packet 133 header must be a valid link-local address on that link. 135 3. AF1 Role In Data Transfer 137 The AF1 role in data transfer is also straightforward, and is 138 independent of the location of the AF1. The AF1 is configured either 139 to translate the headers of incoming packets of multicast content 140 from the sourece to the version supported by the receiver or to 141 decapsulate these packets. This process is specified in 142 [ID.perreault-igmp-mld-translation]. The address mappings used must 143 be the reverse of those used for translation of the outbound 144 signalling. 146 Encapsulation is clearly efficient in a scenario where the source and 147 receiver support one IP version and the intervening network suppports 148 another. However, encapsulation becomes operationally difficult when 149 the network evolves to a mixture of IPv4 and IPv6 receivers. In that 150 case, since the receivers cannot, without change, perform 151 decapsulation themselves, it is necessary to have a vestigial AF1 152 function in front of all receivers. This vestigial function does not 153 have to perform address mapping for the signalling and multicast 154 content it processes, but does have to supply the missing 155 decapsulation capability. 157 4. Acknowledgements 159 TBD. 161 5. Contributors 163 Tina Tsou provided the framework within which these ideas were 164 developed. 166 6. IANA Considerations 168 This memo includes no request to IANA. 170 7. Security Considerations 172 To come. 174 8. Informative References 176 [I-D_tsou-AF2-specification] 177 Taylor, T., "Specification of an Adaptation Function 178 Between Two Multicast Networks Supporting Different IP 179 Versions", December 2011. 181 [I-D_tsou-addr-acquisition] 182 Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q. 183 Sun, "Address Acquisition For Multicast Content When 184 Source and Receiver Support Differing IP Versions (Work in 185 progress)", March 2012. 187 [I.D_jaclee-mcast-ps] 188 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 189 Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use 190 Cases", October 2011. 192 [ID.perreault-igmp-mld-translation] 193 Perrault, S. and T. Tsou, "Internet Group Management 194 Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based 195 Multicast Translation ("IGMP/MLD Translation") (Work in 196 progress)", February 2012. 198 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 199 Thyagarajan, "Internet Group Management Protocol, Version 200 3", RFC 3376, October 2002. 202 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 203 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 205 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 206 "Internet Group Management Protocol (IGMP) / Multicast 207 Listener Discovery (MLD)-Based Multicast Forwarding 208 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 210 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 211 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 212 October 2010. 214 Authors' Addresses 216 Cathy Zhou 217 Huawei Technologies 218 Bantian, Longgang District 219 Shenzhen 518129 220 P.R. China 222 Phone: 223 Email: cathy.zhou@huawei.com 225 Tom Taylor 226 Huawei Technologies 227 1852 Lorraine Ave. 228 Ottawa, Ontario K1H 6Z8 229 Canada 231 Email: tom.taylor.stds@gmail.com 233 Jianping Sun 234 China Telecom 235 P.R. China 237 Phone: +86 18918588708 238 Email: sunjp@sttri.com.cn