idnits 2.17.1 draft-tsou-softwire-encapsulated-multicast-00.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 (January 29, 2011) is 4836 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3973' is defined on line 332, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 3973 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Standards Track C. Zhou 5 Expires: August 2, 2011 Huawei Technologies 6 H. Ji 7 China Telecom 8 January 29, 2011 10 A Generic Approach to Multicast Encapsulation In Support of IPv6 11 Transition 12 draft-tsou-softwire-encapsulated-multicast-00 14 Abstract 16 Consider a situation which will arise in many IPv6 transition 17 scenarios, where Network A, to which a host is attached, supports one 18 IP version, but the host and Network B support a different IP 19 version. Suppose that the host wishes to access a multicast group 20 which is rooted or sourced in Network B. This document specifies an 21 approach that combines stateful translation for signalling, 22 encapsulation of multicast content moving between Network B and the 23 host, and native multicast routing in Network A to provide the host 24 with its desired access. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 2, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 62 2. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. How It Works . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Mapping Request Protocol . . . . . . . . . . . . . . . . . . . 7 67 6. Operational Considerations . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Transition scenarios have been explored in which an IPv6 host 78 attached to an IPv4 network wishes to access content in an IPv6 79 network, or conversely, an IPv4 host attached to an IPv6 network 80 wishes to access content in an IPv4 network. A long list of tools 81 has been put forward for passing unicast content across the network 82 in the middle based on tunneling. 84 Some work has also been done on conveying multicast streams between 85 IPv4 and IPv6 networks, in either direction. Of particular interest 86 is current work in [ID.softwire-dslite-multicast]. However, the 87 present document differs from [ID.softwire-dslite-multicast] both in 88 its degree of generality and in the detailed mechanism used for 89 translation between IPv4 and IPv6 multicast addresses. The present 90 document does not restrict operation to specially constructed IPv6 91 multicast addresses. Instead it makes use of the fact that for a 92 given network, it is unnecessary to map the complete universe of IPv6 93 addresses into IPv4, but only those addresses actually being carried 94 through the network. 96 This document is adapted from [ID.behave-translated-multicast] and 97 uses the same basic mechanism. It requires additional bandwidth 98 because of its use of encapsulation for the multicast content, but 99 thereby avoids the need to translate the addressing of that content 100 between IPv4 and IPv6 at the receiving end of the tunnel. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Problem Description 110 We consider, as described in the previous section, a host supporting 111 one IP version, say IPvx, attached to a provider network supporting a 112 different version, say IPvy. Obviously there has to be an adaptation 113 function between the host and the network to make this work. This 114 document assumes that the adaptation function for unicast packets 115 consists of tunneling combined with a suitable choice of destination 116 address to steer the packets to the right border gateways. 118 On the other side of the provider network, border gateways connect to 119 neighbouring networks. If a particular neighbouring network supports 120 a different version of IP -- that is, IPvx, then the border gateway 121 must also implement adaptation functions. In particular, the unicast 122 adaptation function at the border gateway is complementary to the 123 adaptation function at the host side. 125 Multicast streams could simply be tunneled from the border to the 126 host. However, to save bandwidth, it is desirable to use the native 127 multicast capabilities of the IPvy network so that paths can be 128 shared as much as possible. This implies three requirements on the 129 multicast adaptation function: 131 o it has to enable the use of multicast signalling to build 132 distribution trees in the IPvy network; 134 o it has to route multicast content through those distribution trees 135 rather than directly across the network; 137 o by specific assumption of this document, it must encapsulate 138 incoming IPvx packets before forwarding them to the distribution 139 trees, and decapsulate outgoing packets before sending them 140 onwards. 142 The basic situation just described is illustrated in Figure 1. The 143 host-side adaptation functions MAY be implemented in the host itself, 144 in a separate piece of equipment at the customer site (CPE-based 145 approach), or at the provider edge (gateway initiated approach). The 146 border adaptation functions MUST be implemented in border gateways. 148 +------------+ | | +------------+ | 149 | Host-side | | | | Border | | 150 +----| unicast |------------------| unicast |---- 151 / | adaptation | | | | adaptation | | 152 +----+ / | function | | | | functions | | 153 |IPvx|/ +------------+ | IPvy | +------------+ | IPvx 154 |Host|\ | Provider | | Network 155 +----+ \ +------------+ | Network | +------------+ | 156 \ | Host-side | | | | Border | | 157 \ | multicast | |Signalling| | multicast | | 158 +---| adaptation |---|----------|---| adaptation |---|- 159 | | function | | | | function | | 160 +---| (HMAF) |------------------| (BMAF) |---- 161 +------------+ | Media | +------------+ | 163 Figure 1: Adaptation Functions For Flows Crossing Two IP Version 164 Boundaries 166 The key assumption of this document is that when the host wishes to 167 acquire a multicast stream rooted or sourced in the IPvx network, it 168 knows only the IPvx address pair (where the source 169 MAY be wild-carded, i.e., for an any-source multicast group). 171 It learns that address pair by means outside the scope of this 172 specification (e.g., via the web or session signalling). 174 As a result, for purposes of multicast signalling, the host-side 175 multicast adaptation function (HMAF) needs to obtain a mapping 176 between this IPvx address pair and the corresponding IPvy address 177 pair used in the IPvy network to denote the same multicast stream. 178 Similarly, the border multicast adaptation function (BMAF) needs this 179 mapping both for purposes of multicast signalling and so that it can 180 assign the right IPvy source and destination addresses to incoming 181 IPvx multicast content. 183 3. Proposed Solution 185 The proposed solution consists of three elements: 187 o a stateful mapping function within the IPvy provider network that 188 provides mappings between IPvx address pairs and 189 corresponding IPvy address pairs denoting the same 190 multicast flows; 192 o address pools of IPvy multicast and unicast addresses provisioned 193 at the mapping function; 195 o a protocol that allows the HMAF and BMAF to request mappings from 196 the mapping function. PCP [ID.port-control-protocol] is a 197 candidate for this protocol, but that decision needs further 198 consideration. 200 3.1. How It Works 202 1. Initial discovery and Join request 204 The IPvx host discovers the address pair of a 205 multicast stream the user wants to receive. The IPvx Host sends an 206 MLDv2 [RFC3810] (for IPv6) or IGMPv3 [RFC3376] (for IPv4) Join 207 request to the HMAF to acquire the stream. 209 2. Address Mapping At the HMAF 211 The HMAF checks its cache of mappings to see if it already has a 212 mapping between the IPvx address pair received in the 213 host request and a corresponding pair of IPvy addresses. Failing to 214 find a mapping, it sends a request for the required mapping to the 215 mapping function. The mapping function in turn checks whether it has 216 already created the mapping. If not, it assigns unicast and 217 multicast IPvy addresses from its pool and records the mapping for 218 further use. In either case it returns the requested mapping to the 219 HMAF, which caches it. [Editor's Note: The transaction is carried 220 out over a protocol to be specified in a later version of this 221 document.] 223 3. Propagation Of the Join Request Into the IPvy Network 225 Using the mapping it has received, the HMAF interworks from MLDv2 to 226 IGMPv3 or vice versa, depending on whether the host supports IPv6 or 227 IPv4. It forwards the interworked Join request to the Provider IP 228 Edge. 230 If the HMAF is collocated with the Provider IP Edge, this 231 interworking step is an internal operation. 233 The Provider IP Edge acts on the received request by interworking it 234 to a Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] 235 request and forwarding that request into the IPvy network, indicating 236 the IPvy address pair it was given and ensuring that 237 it is on the multicast tree for the stream concerned. 239 Assuming that the multicast tree for the requested stream is not 240 joined at an earlier point in the provider network, eventually the 241 PIM request finds its way to the BMAF. It has been suggested that 242 the border gateway in which the BMAF resides can be made a PIM-SM 243 rendezvous point (RP) to ensure that requests for new groups reach 244 it. 246 4. Remapping the Address Pair At the BMAF 248 The BMAF needs to map from the IPvy address pair it 249 received back to the corresponding IPvx address pair before 250 propagating the PIM request into the IPvx network. It sends a 251 request to the mapping function to provide that mapping. The mapping 252 function already has this mapping, as a result of the original HMAF 253 request, and returns it to the BMAF. [Editor's note: protocol again 254 to be specified later. It can probably be the same as the one used 255 by the HMAF. Have to work out the security considerations.] 257 5. Propagation Of the PIM Request Into the IPvx Network 259 The BMAF propagates translates the PIM request from IPvy to IPvx 260 using the mapping it received. It propagates the request into the 261 IPvx network to complete the construction of the path for the 262 requested multicast stream. If path construction fails, the BMAF 263 SHOULD notify the mapping function so it can mark the IPvx address 264 pair as bad (so it doesn't get remapped) while releasing the assigned 265 IPvy addresses. 267 6. Transport of Multicast Media and Unicast RTCP Feedback 269 If the BMAF receives a multicast packet from the IPvx network, it 270 checks its cache of mappings to locate the IPvy source and group 271 addresses corresponding to the incoming IPvx packet header. It 272 encapsulates the packet in an IPvy header containing the mapped IPvy 273 source and with the destination set to the mapped IPvy group address. 274 It then forwards the packet to the next hop in the multicast tree for 275 that source and group. 277 When the HMAF receives a multicast packet from the IPvy network, it 278 decapsulates it and forwards it to the host. 280 When the IPvx host sends unicast RTCP [RFC3550] feedback toward the 281 source, the packets are handled like any other unicast packets. That 282 is, they are processed by the unicast adaptation functions rather 283 than the HMAF and BMAF. 285 Finally, if the IPvx Host emits multicast packets destined for an 286 any-source multicast group, the processing of the packet is as just 287 described, but with the roles of the HMAF and BMAF reversed. 289 4. Acknowledgements 291 This draft started out as draft-tsou-softwire-6rd-multicast-00. 292 Thanks to Joel Halpern for suggesting that it be written as a more 293 general document, since it did not really depend on 6rd. Thanks to 294 Yiu Lee for further comments, which have been used to improve the 295 document. 297 5. Mapping Request Protocol 299 To come. 301 6. Operational Considerations 303 The proposal presented here incurs the operational expense of 304 provisioning the multicast and unicast address pools at the mapping 305 function. Proper functioning of the system requires that the 306 operator estimate the total number of different IPvx multicast groups 307 and, for source-specific multicast, the total number of individual 308 IPvx sources it wishes to enable simultaneously. 310 7. IANA Considerations 312 This memo currently includes no request to IANA. 314 8. Security Considerations 316 To come. 318 9. References 320 9.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 326 Thyagarajan, "Internet Group Management Protocol, Version 327 3", RFC 3376, October 2002. 329 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 330 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 332 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 333 Independent Multicast - Dense Mode (PIM-DM): Protocol 334 Specification (Revised)", RFC 3973, January 2005. 336 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 337 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 338 Protocol Specification (Revised)", RFC 4601, August 2006. 340 9.2. Informative References 342 [ID.behave-translated-multicast] 343 Tsou, T., Taylor, T., Zhou, C., and H. Ji, "A Generic 344 Approach to Multicast Translation In Support of IPv6 345 Transition", January 2011. 347 [ID.port-control-protocol] 348 Wing, D., "Port Control Protocol (PCP)", January 2011. 350 [ID.softwire-dslite-multicast] 351 Wang, Q., Qin, J., Sun, P., Boucadair, M., Jacquenet, C., 352 and Y. Lee, "Multicast Extensions to DS-Lite Technique in 353 Broadband Deployments", January 2011. 355 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 357 Jacobson, "RTP: A Transport Protocol for Real-Time 358 Applications", STD 64, RFC 3550, July 2003. 360 Authors' Addresses 362 Tina Tsou 363 Huawei Technologies (USA) 364 2330 Central Expressway 365 Santa Clara, CA 95050 366 USA 368 Phone: +1 408 330 4424 369 Email: tena@huawei.com 370 URI: http://tinatsou.weebly.com/contact.html 372 Cathy Zhou 373 Huawei Technologies 374 Bantian, Longgang District 375 Shenzhen 518129 376 P.R. China 378 Phone: 379 Email: cathyzhou@huawei.com 381 Hui Ji 382 China Telecom 383 NO19.North Street 384 Beijing, Chaoyangmen,Dongcheng District 385 P.R. China 387 Phone: 388 Email: jihui@chinatelecom.com.cn