idnits 2.17.1 draft-eubanks-mboned-transition-overview-04.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 12, 2012) is 4400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-mboned-64-mcast-addr-fmt - is the name correct? == Outdated reference: A later version (-01) exists of draft-perreault-mboned-igmp-mld-translation-00 == Outdated reference: A later version (-02) exists of draft-taylor-pim-v4v6-translation-00 == Outdated reference: A later version (-01) exists of draft-tsou-mboned-multrans-addr-acquisition-00 == Outdated reference: A later version (-03) exists of draft-zhou-mboned-multrans-path-optimization-01 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Asaeda 3 Internet-Draft Keio University 4 Intended status: Informational M. Eubanks 5 Expires: September 13, 2012 AmericaFree.TV 6 T. Tsou 7 Huawei Technologies (USA) 8 S. Venaas 9 Cisco Systems 10 March 12, 2012 12 Multicast Transition Overview 13 draft-eubanks-mboned-transition-overview-04 15 Abstract 17 IPTV providers must serve content to their customers during the 18 period of transition from IPv4 to IPv6. During this period, the 19 content provider may support only one version of IP while the 20 customer's receiver device supports only the other. Likewise, the 21 network between the provider and its customer may include segments 22 supporting only one version of IP or another. 24 This document provides an overview of the multicast transition 25 problem. It also provides an overview of the solution space. The 26 solution space is characterized by an adaptation function (AF) that 27 provides an interface between IPv4 and IPv6 multicast domains. This 28 document also discusses various multicast use cases which may occur 29 during IPv6 transitioning. These use cases motivate the solution 30 space discussion and the requirements that appear at the end. 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 13, 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. A Look At the Multicast Transition Problem Space . . . . . . . 3 68 2.1. Signaling Channels using Multicast Addresses . . . . . . . 4 69 2.2. Operator View of Use Cases . . . . . . . . . . . . . . . . 5 70 2.3. Requirements From The Use Cases . . . . . . . . . . . . . 8 71 3. A Look At the Solution Space For Multicast Transition . . . . 9 72 3.1. AF Forwarding Plane Operation . . . . . . . . . . . . . . 9 73 3.2. AF Control Plane Operation . . . . . . . . . . . . . . . . 10 74 3.3. Source Discovery . . . . . . . . . . . . . . . . . . . . . 10 75 3.4. Transitional Multicast Path Optimization . . . . . . . . . 10 76 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 IPTV providers must serve content to their customers during the 86 period of transition from IPv4 to IPv6. During this period, the 87 content provider may support only one version of IP while the 88 customer supports only the other. Likewise, the network between the 89 provider and its customer may include segments supporting only one 90 version of IP or another. 92 In current deployments, the IP multicast forwarding scheme is used by 93 many service providers to deliver services such as live TV 94 broadcasting. Multiple players intervene in the delivery of these 95 services, including content and service providers. Service providers 96 are responsible for carrying multicast flows from head-ends to 97 receivers. The content can be supplied by a service provider or by 98 other providers (e.g., case of externally paid channels). 100 Unlike the situation for unicast addresses, the IPv4 multicast 101 address space seems sufficient for most proposed uses. Hence the key 102 motivation for the work described here is to preserve the 103 efficiencies of multicast distribution of content (i.e., by reducing 104 total traffic on the network and minimizing the distance that 105 multicast streams must travel) when both IPv4 and IPv6 segments lie 106 on the path from source to receiver. 108 This document provides an overview of the multicast transition 109 problem. It also provides an overview of the solution space. The 110 solution space is characterized by an adaptation function (AF) that 111 provides an interface between IPv4 and IPv6 multicast segments. The 112 scope of this document is currently limited to IP transport, and 113 covers both single operator and inter-operator flows. 115 Section 2 describes the problem space in detail. This section 116 describes an environment that includes a content provider, a 117 customer, and an intervening network. Any component of that 118 environment may support only one version of IP or the other. At 119 points where IPv4-only devices lie on one side and IPv6-only devices 120 on the other, an adaptation function is required. 122 Section 3 proposes a framework for the solution. Section 4 defines 123 formal requirements for any proposed solution. 125 2. A Look At the Multicast Transition Problem Space 127 Historically, IPTV providers have served IPv4 content to receivers 128 over IPv4 multicast networks. CPE has thus until recently supported 129 IPv4 only. As the Internet transitions to IPv6, IPv6-capable 130 equipment will be deployed by content providers and receivers, as 131 well as the networks that connect them to one another. So long as 132 all of the newly deployed gear supports both IPv4 and IPv6, the 133 transition to IPv6 may not require new IETF protocol specifications 134 in support of multicast deployment. In this case of dual-stack 135 environments, either IP address family can be used end to end for the 136 multicast traffic. However, if some of the newly deployed gear 137 supports IPv6 only, incompatibilities will be introduced. These 138 IPv6-only scenarios are being planned and deployed because the 139 exhaustion of IPv4 unicast address space. Instead of running large 140 NAT and IPv6 all together, some providers prefer to run a single 141 address family that is future proof, which is IPv6. This also brings 142 simpler management of the network. In this unicast case, IPv4 143 traffic can be either tunneled over IPv6 (e.g. softwire, dslite, 4rd) 144 or translated (NAT64). Therefore, some access networks are IPv6 145 only. 147 An incompatibility occurs at a device lying along the path between 148 the source and the receiver when the next device on the path on one 149 side of it supports a different version of IP from the next device on 150 the path on the other side of it (i.e., one device supports IPv4 only 151 and the other supports IPv6 only). For the purposes of this 152 document, we will call these points of incompatibility "IP version 153 transition points". The communication path between source and 154 receiver (which includes both endpoints) can include zero or more IP 155 version transition points. 157 IP version transition points may be introduced at any point along the 158 path. These IP version transition points may reside in the 159 subscriber premises, at the CPE, in the intervening network etc. In 160 addition, the Set Top Box (STB) and Electronic Program Guides (EPG) 161 may have different IP versions. 163 In order to maintain multicast connectivity, one or more adaptation 164 functions (AF) are required. The AF operates in both the forwarding 165 and control planes. Because it provides an interface between the 166 IPv4 and IPv6 domain, it must be both IPv4-capable and IPv6-capable. 168 In most cases, the adaptation function will mediate between IPv4 and 169 IPv6 on both the control and forwarding planes. However, in 170 scenarios where the path between source and receiver contains 171 multiple IP version transition points, adaptation function instances 172 may tunnel traffic between one another. 174 2.1. Signaling Channels using Multicast Addresses 176 The receiver is provided the necessary multicast addresses for 177 channel reception by some means such as an Electronic Program Guide 178 (EPG). If the source uses the same address family as the receiver, 179 the receiver will subscribe to a multicast address of the appropriate 180 address family. However, If the source uses the other address 181 family, then the signaling must be translated in the path (or at the 182 program guide). 184 An early assessment of the market seems to suggest that most 185 signaling is done with proprietary protocols, and that most EPG are 186 also proprietary. It remains to be seen if a standardized solution 187 for this issue a need or even a possibility, given these market 188 realities. 190 2.2. Operator View of Use Cases 192 Discussion with operators has indicated in the first place that the 193 distribution of Electronic Program Guide material is done by 194 proprietary means, and they have no interest in a standardized 195 solution. SSM (Specific Source Multicast) is the technically 196 preferable mode of operation. However, some operators may have to 197 use ASM (Any Source Multicast) because of the limitations of existing 198 receivers (i.e., limitations on the support of IGMP v3 or MLD v2). 200 In what follows, this document uses the following numeric convention 201 to specify a particular scenario: -- (e.g., 6-4-6-4 for the second scenario 203 described below). 205 For a number of operators, the expected evolution path is to first 206 upgrade the network to IPv6, then upgrade the receivers to IPv6 207 through a gradual process of replacement, and then add IPv6 sources 208 when a critical mass of IPv6 receivers is reached. This sequence 209 implies that the immediate priority is to support the 4-6-4 scenario 210 shown in Figure 1. One can immediately see that two instances of the 211 AF are needed, one at each side of the IPv6 network. The receiver 212 signals using IGMP. The AF translates the IGMP either to MLD 213 [RFC3810] or to PIM [RFC4601] running on IPv6. At the other side, 214 the AF most likely interworks between PIM with IPv6 and PIM with 215 IPv4. In the reverse direction, multicast data packets can either be 216 translated or tunneled between the AF instances, as noted above. 218 +------+ +-----+ +----+ +------+ +-----+ 219 | Host | | DS | | | | MR | | | 220 | Rcvr |------| AF | | MR | . . . | |------| Src | 221 | | IPv4 | | | | IPv4 | (DR) | IPv4 | | 222 +------+ +-----+ +----+ +------+ +-----+ 223 / \ 224 / IPv6 \ IPv4 225 / \ 226 +----+ +----+ +------+ 227 | | | | | DS | 228 | MR |------| MR | . . . | AF | 229 | | IPv6 | | IPv6 | | 230 +----+ +----+ +------+ 232 Rcvr: Multicast receiver 233 DS : Dual Stack 234 AF : Adaptation Function 235 MR : Multicast router 236 DR : Designated Router 237 Src : Multicast source 239 Figure 1: An Initial Scenario: IPv4 Source and Receiver Via an IPv6 240 Network 242 An alternative view of network evolution contemplates a more 243 immediate rollout of IPv6 receivers, but a slow evolution of sources 244 from IPv4 to IPv6. The backbone network will be IPv6 in all cases, 245 but the metro network may be either IPv4 or IPv6. The first case 246 (6-4-6-4), with an IPv4 metro network, is shown in Figure 2. Three 247 AF instances are needed, at the IP version transition points between 248 the source and backbone network, between the backbone and metro 249 network, and between the metro network and the receiver. 251 +------+ +-----+ +----+ +------+ 252 | Host | | DS | | | | DS | 253 | Rcvr |------| AF |------| MR | . . .| AF | 254 | | IPv6 | | IPv4 | | IPv4 | | 255 +------+ +-----+ +----+ +------+ 256 / 257 ---------------------------- 258 / IPv6 259 +----+ +----+ +------+ 260 | | | | | DS | 261 | MR |------| MR | . . . | AF | 262 | | IPv6 | | IPv6 | | 263 +----+ +----+ +------+ 264 / 265 ------------------------- 266 / IPv4 267 +----+ +------+ +-----+ 268 | | | MR | | | 269 | MR | . . . . | |------| Src | 270 | | IPv4 | (DR) | IPv4 | | 271 +----+ +------+ +-----+ 273 Rcvr: Multicast receiver 274 Src : Multicast source 275 DS : Dual Stack 276 AF : Adaptation function 277 MR : Multicast Router 278 DR : Designated Router 280 Figure 2: Initial Scenario With IPv6 Host, IPv4 Source, and Both IPv4 281 and IPv6 Intervening Networks 283 The case where the metro network has evolved to IPv6 (6-6-4) is shown 284 in Figure 3. Here, only one AF instance is needed. It translates 285 between IPv6 PIM in the receiver network and IPv4 PIM in the content 286 provider network. 288 +------+ +-----+ +----+ +------+ 289 | Host | | MR | | | | DS | 290 | Rcvr |------| |------| MR | . . .| AF | 291 | | IPv6 |(DR) | IPv6 | | IPv6 | | 292 +------+ +-----+ +----+ +------+ 293 / 294 ------------------------- 295 / IPv4 296 +----+ +------+ +-----+ 297 | | | MR | | | 298 | MR | . . . . | |------| Src | 299 | | IPv4 | (DR) | IPv4 | | 300 +----+ +------+ +-----+ 302 Rcvr: Multicast receiver 303 Src : Multicast source 304 DS : Dual Stack 305 AF : Adaptation function 306 MR : Multicast Router 307 DR : Designated Router 309 Figure 3: Initial Scenario With IPv6 Host, IPv4 Source, and IPv6 310 Intervening Network 312 2.3. Requirements From The Use Cases 314 All three of the immediately relevant scenarios just described 315 feature IPv4 sources. This means that no solution is required in the 316 short term for translation from general IPv6 addresses to IPv4 317 addresses. In the longer run operators may have the situation of 318 IPv6 sources serving receivers that have remained at IPv4. That 319 presents a more difficult translation problem, but the scenario has 320 low priority. 322 The three cases illustrate a number of protocol interworking 323 combinations. As indicated below, some combinations can act as a 324 part of others, reducing the total development effort. 326 In summary, the use cases expose the following gaps for which there 327 are no existing IETF standards: 329 o Translating from IPv4 to IPv6 multicast addresses and back again. 331 o Translating from IGMP downstream to MLD upstream (4-6-4 case) and 332 from MLD downstream to IGMP upstream (6-4-6-4 case). 334 o Interworking between IGMP and PIM with IPv6 (4-6-4 case). This 335 could be synthesized by translating the IGMP to MLD and having MLD 336 interwork with PIM as usual. 338 o Interworking between MLD and PIM with IPv4 (6-4-6-4 case). Again, 339 this could be synthesized, by translating MLD to IGMP and 340 interworking the latter to PIM as usual. 342 o Operating PIM with IPv4 downstream and IPv6 upstream (6-4-6-4 343 case) and with IPv6 downstream and IPv4 upstream (4-6-4 and 6-6-4 344 cases). 346 3. A Look At the Solution Space For Multicast Transition 348 The AF operates on both the forwarding and control planes. On the 349 forwarding plane, the AF inserts itself into the forwarding path 350 translating multicast packets from one IP version to the other. On 351 the control plane, the AF receives routing and signaling messages of 352 one protocol and sends out routing and signaling messages of another 353 protocol.[Forward reference to future high-level description of the 354 AF.] 356 3.1. AF Forwarding Plane Operation 358 The AF accepts packets from one IP version, removes the IP header, 359 and replaces it with an IP Header of the other version. A 360 significant portion of that task is address translation. Ideally the 361 address translation strategy used by an AF should be algorithmic, 362 stateless and reversible. This should be simple when addresses from 363 one IP version can simply be embedded into another (IPv4 into IPv6), 364 but this may not be possible in the opposite direction. That the 365 translation is reversible means that there is a stateless algorithm 366 for translating back into the original address. 368 [RFC6052] provides an algorithm for translating unicast addresses 369 between IPv4 and IPv6. Likewise [I-D.mboned-64-mcast-addr-fmt] 370 provides an algorithm for multicast address conversion between IPv4 371 and IPv6. Note that using this algorithm, different translators 372 could choose different IPv6 prefixes for embedding the IPv4 373 addresses. But the format allows for stateless translation back to 374 the original IPv4 addresses. 376 Other issues associated with IP version translation may arise (e.g., 377 fragmentation and checksums and will be resolved as appropriate in 378 conjunction with appropriate IETF working groups. 380 3.2. AF Control Plane Operation 382 On the control plane, the AF mediates between: 384 o IGMPv3 [RFC3376] and MLDv2 [RFC3810]; 386 o PIM(v4) [RFC4601] and PIM(v6); 388 o IGMPv3 and PIM(v6); 390 o MLD and PIM(v4); 392 The IGMP-to-MLD translation may be configured to use only IGMPv2 393 features. It is defined in [draft to come]. 394 [I-D.perreault-mboned-igmp-mld-translation] is a candidate for this 395 specification. 397 The PIM-to-PIM mediation operates between PIM protocol operations of 398 one IP version with operations of the other version. 399 [I-D.taylor-pim-v4v6-translation] is a candidate for this 400 specification. 402 3.3. Source Discovery 404 Source discovery is out of scope and is left for further study. 405 [I-D.tsou-mboned-multrans-addr-acquisition] provides an informative 406 discussion of the options open to operators. 408 3.4. Transitional Multicast Path Optimization 410 A mechanism to optimize the path to the multicast source for a 411 combination of IPv4 and IPv6 networks is not immediately required, 412 but is a topic for future work. 413 [I-D.zhou-mboned-multrans-path-optimization] is a candidate for this 414 specification. 416 4. Contributors 418 Some of the introductory text of this document was drawn from 419 [I-D.jaclee-behave-v4v6-mcast-ps]. Figures from Section 3 of that 420 document were the starting point for the figures in Section 2.1 of 421 this document. The strong participation of the authors of 422 [I-D.jaclee-behave-v4v6-mcast-ps] in the work on multicast transition 423 leading up to the creation of this document must be acknowledged. 424 These authors include two co-authors of the present document, plus 425 Mohamed Boucadair, Yiu Lee, Hitoshi Asaeda, and Jacni Qin, who should 426 be considered honorary co-authors. 428 5. Acknowledgements 430 Ron Bonica inspired the writing of this memo and shaped its content. 431 Michael McBride and Marc Blanchet provided useful comments on 432 intermediate versions of this document. 434 6. IANA Considerations 436 This memo includes no request to IANA. 438 7. Security Considerations 440 To come. 442 8. Informative References 444 [I-D.jaclee-behave-v4v6-mcast-ps] 445 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 446 Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use 447 Cases", draft-jaclee-behave-v4v6-mcast-ps-03 (work in 448 progress), October 2011. 450 [I-D.mboned-64-mcast-addr-fmt] 451 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 452 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work 453 in Progress)", March 2012. 455 [I-D.perreault-mboned-igmp-mld-translation] 456 Perreault, S. and T. Tsou, "Internet Group Management 457 Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based 458 Multicast Translation ("IGMP/MLD Translation")", 459 draft-perreault-mboned-igmp-mld-translation-00 (work in 460 progress), February 2012. 462 [I-D.taylor-pim-v4v6-translation] 463 Taylor, T. and C. Zhou, "A Translator For Protocol 464 Independent Multicast (PIM) Interworking Between IPv4 and 465 IPv6", draft-taylor-pim-v4v6-translation-00 (work in 466 progress), March 2012. 468 [I-D.tsou-mboned-multrans-addr-acquisition] 469 Clauberg, A., Boucadair, M., Sun, Q., Venaas, S., and T. 470 Tsou, "Address Acquisition For Multicast Content When 471 Source and Receiver Support Differing IP Versions", 472 draft-tsou-mboned-multrans-addr-acquisition-00 (work in 473 progress), February 2012. 475 [I-D.zhou-mboned-multrans-path-optimization] 476 Sun, Q. and C. Zhou, "Multicast transition path 477 optimization in IPv4 and IPv6 networks", 478 draft-zhou-mboned-multrans-path-optimization-01 (work in 479 progress), March 2012. 481 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 482 Thyagarajan, "Internet Group Management Protocol, Version 483 3", RFC 3376, October 2002. 485 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 486 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 488 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 489 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 490 Protocol Specification (Revised)", RFC 4601, August 2006. 492 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 493 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 494 October 2010. 496 Authors' Addresses 498 Hitoshi Asaeda 499 Keio University 500 Graduate School of Media and Governance 501 5322 Endo 502 Fujisawa, Kanagawa 252-0882 503 Japan 505 Email: asaeda@wide.ad.jp 506 URI: http://www.sfc.wide.ad.jp/~asaeda/ 508 Marshall Eubanks 509 AmericaFree.TV 510 P.O. Box 141 511 Clifton, VA 20124 512 USA 514 Phone: 515 Email: marshall.eubanks@gmail.com 516 Tina Tsou 517 Huawei Technologies (USA) 518 2330 Central Expressway 519 Santa Clara, CA 95050 520 USA 522 Phone: +1 408 330 4424 523 Email: Tina.Tsou.Zouting@huawei.com 525 Stig Venaas 526 Cisco Systems 527 Tasman Drive 528 San Jose, CA 95134 529 USA 531 Phone: 532 Email: stig@cisco.com