idnits 2.17.1 draft-tsou-multrans-use-cases-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 25, 2011) is 4622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4607' is defined on line 486, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: Informational C. Zhou 5 Expires: February 26, 2012 T. Taylor 6 Huawei Technologies 7 R. Maglione 8 Telecom Italia 9 August 25, 2011 11 Use Cases For Multicast Transition From IPv4 to IPv6 12 draft-tsou-multrans-use-cases-00 14 Abstract 16 Like other internet activities, multicast is affected by the fact 17 that the transition from IPv4 to IPv6 is occurring over a period of 18 years, via multiple transition paths. As a result, mechanisms need 19 to be added to the basic multicast architecture to assist in specific 20 transition scenarios. This document describes detailed use cases so 21 that the requirements for the multicast transition mechanisms can be 22 better understood. 24 The considered opinion in discussions to date on multicast transition 25 requirements has been that the two most important transition 26 scenarios in the near future will be the "4-6-4" and "6-4" network 27 scenarios. These scenarios are described in detail below, in their 28 several possible variants, showing the new issues that IPv6 29 transition raises for multicast operation. 31 There is further general agreement that Any-Source Multicast (ASM) 32 (the service, not necessarily the technology) is no longer an 33 important use case. As a result, this document restricts itself to 34 scenarios where the set of multicast sources is separate from the set 35 of multicast receivers. As a final restriction, it assumes a single 36 administrative provider domain. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on February 26, 2012. 55 Copyright Notice 57 Copyright (c) 2011 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 74 2. Stages of Multicast Channel Acquisition . . . . . . . . . . . 5 75 3. The 4-6-4 Network Scenario . . . . . . . . . . . . . . . . . . 6 76 3.1. The 4-6-4 Network Scenario With Interworking At the 77 Customer Edge . . . . . . . . . . . . . . . . . . . . . . 6 78 3.2. The 4-6-4 Scenario Where Interworking Is Done At the 79 Provider Edge . . . . . . . . . . . . . . . . . . . . . . 9 80 4. The 6-4 Network Scenario . . . . . . . . . . . . . . . . . . . 11 81 4.1. The 6-4 Scenario With IPv6 Access Network . . . . . . . . 11 82 4.2. The 6-4 Scenario With IPv4 Access Network . . . . . . . . 11 83 5. The 6-4-6 Network Scenario . . . . . . . . . . . . . . . . . . 11 84 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 Work on multicast transition from IPv4 to IPv6 has been in progress 96 for several years, but has not yet resulted in the standardization of 97 any specific transitional solutions. For a slightly dated survey of 98 this work, see [ID.Multrans-Taxonomy]. More recently, 99 [ID.Multrans-Problem-Statement] was created to advance discussion of 100 the topic. 102 Discussion of multicast transition has concluded that at the time of 103 writing, the primary multicast service of interest is Specific-Source 104 Multicast (SSM). Hence this document assumes that multicast sources 105 and multicast receivers are separate entities. Furthermore, the most 106 important network scenarios for multicast transition are summarized 107 by the expressions "4-6-4" and "6-4". These scenarios are described 108 in detail below. The numbers, of course, refer to the IP versions 109 supported by the multicast receiver, the intervening provider 110 network, and the multicast source. Initial interest is limited to a 111 single-provider scenario, where multicast sources, the intervening 112 network, and multicast receivers are all under common administrative 113 control. 115 The purpose of the present document is to spell out the use cases for 116 multicast transition within the boundaries just described. In this 117 role, this document provides more detail than 118 [ID.Multrans-Problem-Statement] on the message flows and interworking 119 details involved, but stops short of the solution detail provided by, 120 for instance, [ID.Multrans-DS-Lite]. 122 In each network scenario, it is assumed that bandwidth is a valuable 123 resource, and hence that the network supports a shared tree multicast 124 routing infrastructure. [RFC5110] provides a snapshot of the 125 multicast routing architecture as of three years ago. The present 126 document assumes that deployments have evolved to provide full 127 support for SSM, and hence that hosts and multicast routers support 128 IGMPv3 [RFC3376], MLDv2 [RFC3810], and PIM-SM [RFC4601] as 129 applicable. 131 It is reasonable to expect that replication of multicast content at 132 Layer 2 is controlled for scalability and other reasons. However, 133 this document does not currently include descriptions of actions down 134 to the Later 2 level. 136 1.1. Requirements Language 138 This document is purely descriptive, and contains no normative 139 language. 141 2. Stages of Multicast Channel Acquisition 143 As [RFC5110] and [ID.Multrans-Problem-Statement] indicate, an SSM 144 receiver acquires a given multicast channel in three stages. In the 145 first stage, it acquires the source and group addresses that specify 146 the channel. In the second stage, it indicates its interest in 147 receiving the channel through multicast signalling, using IGMP 148 [RFC3376] or MLD [RFC3810]. This signalling is propagated into the 149 network using PIM-SM [RFC4601] between multicast routers, to add the 150 receiver to the multicast distribution tree that exists for that 151 source. Once this has been completed, the third stage consists of 152 delivery of the packets of content for the selected channel, from the 153 source to the receiver. 155 The details of operation in the second and third stages are closely 156 tied to the network scenario being considered, and hence are 157 described below. However, the stage of address acquisition lends 158 itself to a more general discussion and can be dealt with at this 159 point. 161 The goal of the address acquisition stage is for the receiver to 162 acquire a unicast source address and multicast group address with 163 which it may then proceed to request the desired channel. A variety 164 of means can be used to achieve this. The receiver may simply be 165 configured in advance with a listing of addresses for the channels to 166 which the subscriber is allowed access. Session signalling (SIP 167 [RFC3261] plus SDP [RFC4566]) may be used. The information may be 168 provided by an announcement protocol such as SAP [RFC2974], or it may 169 be accessible through a proprietary program guide over HTTP. 170 Depending on the network scenario, delivery of this information to 171 the receiver across IP version boundaries may be more or less 172 complicated, but the details will depend very much on the particular 173 deployment. 175 What is important here is not those details, but the constraints that 176 the address acquisition process must satisfy so that the remaining 177 stages can be carried out successfully. The first of these 178 constraints is that the IP version of the source and group addresses 179 that the receiver obtains must be understood by the receiver. Thus 180 in the 4-6-4 scenario these addresses must reach the receiver as IPv4 181 addresses. In the 6-4 scenario, they must reach the receiver as IPv6 182 addresses, even though the source itself supports IPv4. The 183 assumption that we are operating in a single administrative domain 184 simplifies this task, since AAA can supply details of the 185 subscription including what IP version is supported by the customer 186 site. 188 The second constraint looks forward to the succeeding stages. The 189 source and group addresses that the receiver acquires must be valid 190 for the receiver to use in requesting to join the shared distribution 191 tree for the channel concerned. That is, whenever the multicast 192 signalling initiated by the receiver crosses an IP version boundary, 193 these addresses must be consistently mappable to addresses in the new 194 version that correspond to the same multicast channel. In the final 195 stage, the incoming multicast content must be presented to the 196 receiver with the same spource and group addresses that it acquired 197 in the first stage, regardless of what transformations those 198 addresses underwent on the path from the source to the receiver. 199 These requirements will become apparent as we walk through the 200 detailed use cases in the next few sections. 202 3. The 4-6-4 Network Scenario 204 The 4-6-4 network scenario assumes that the multicast source and 205 receivers both support IPv4. The intervening network supports IPv6. 206 There are two primary sub-cases, based on the location of the 207 boundary between IPv4 and IPv6 on the receiver side. On the source 208 side, that boundary is always assumed to be at the network edge. 210 o The interworking between IPv4 and IPv6 occurs in a device at the 211 customer edge. This is described in Section 3.1. 213 o The interworking between IPv4 and IPv6 occurs at the provider 214 edge. This is described in Section 3.2. 216 The following sections walk through stage 2 and stage 3 for each of 217 these two sub-cases in turn. 219 3.1. The 4-6-4 Network Scenario With Interworking At the Customer Edge 221 This case assumes that a dual stack device exists at the customer 222 edge, offering an IPv4 interface to the receiver and an IPv6 223 interface to the network. Figure 1 illustrates the signalling path 224 for this case. 226 +------+ +----+ +------+ +------+ 227 | Host | IGMP | DS | | MR | PIM | MR | 228 | Rcvr |------| CE | | | . . . . | | 229 | | IPv4 | | | (BG) | IPv4 | (DR) | 230 +------+ +----+ +------+ +------+ 231 / \ 232 MLD / IPv6 PIM \ IPv4 233 / \ 234 +------+ +----+ +------+ 235 | MR | PIM | | PIM | DS | 236 | |------| MR | . . . | MR | 237 | (DR) | IPv6 | | IPv6 | (BG) | 238 +------+ +----+ +------+ 240 -------------------------------------> 242 Rcvr: Multicast receiver 243 DS : Dual stack 244 CE : Customer edge router (RFC 4605 compliant) 245 MR : Multicast router 246 DR : Designated router 247 BG : Border gateway 249 Figure 1: Multicast Signalling When Interworking Is At the Customer 250 Edge (4-6-4 Scenario) 252 The multicast signalling sequence illustrated in Figure 1 begins when 253 the receiving host sends an IGMP Membership Report message toward the 254 network. The message contains the IPv4 multicast group and unicast 255 source addresses that the receiver acquired in stage 1. The 256 destination address is 224.0.0.22, as specified in Section 4.2.14 of 257 [RFC3376]. 259 The dual stack Customer Edge device, acting as an IGMP/MLD Proxy 260 [RFC4605], terminates the IGMP Membership Report message. It 261 interworks it to an MLD Listener Report message. The IPv4 source and 262 group addresses from the IGMP message are mapped to IPv6 addresses 263 corresponding to the same multicast channel within the IPv6 network, 264 and placed into the MLD Listener Report. The need for coordination 265 with the network means that the mapping has to be provided by the 266 network operator, either directly or through configuration of an 267 algorithm and associated parameters. This implies some operator 268 control over the implementation of the Customer Edge device. The 269 Customer Edge device sends the MLD Listener Report over an IPv6 link 270 toward the network, with a destination address of FF02::16 as 271 specified by Section 5.2.14 of [RFC3810]. 273 At the network edge, the Designated Router [RFC4601] for the customer 274 site terminates the MLD Listener Report. It updates its internal 275 state, then, as required, issues a PIM-SM (IPv6) Join message toward 276 the next multicast router en route to the source. Signalling is 277 propagated until it joins the existing tree for the given channel, or 278 reaches the dual stack border device shown as "DS MR (BG)" in the 279 figure. To make this happen, the operator must configure the 280 necessary routing information in advance. 282 At the dual stack border device, the IPv6 source and group addresses 283 are mapped in their turn to the IPv4 source and group addresses 284 corresponding to the desired channel in the IPv4 network. The new 285 IPv4 addresses do not necessarily have to be the same as those 286 provided to the receiver in the address acquisition stage. Note that 287 this operation requires coordination between the IPv6 and IPv4 288 networks. The incoming PIM (IPv6) Join message is interworked to a 289 PIM (IPv4) Join message directed to the multicast router at the 290 border of the IPv4 network. The PIM messaging continues to propagate 291 through the IPv4 network, if necessary, until it ends up at the 292 Designated Router serving the source. 294 Figure 2 shows the path taken by content emitted by the source. 296 +------+ +----+ +------+ +------+ +-----+ 297 | Host | | DS | | MR | | MR | | | 298 | Rcvr |------| CE | | | . . . | |------| Src | 299 | | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | | 300 +------+ +----+ +------+ +------+ +-----+ 301 / \ 302 / IPv6 \ IPv4 303 / \ 304 +------+ +----+ +------+ 305 | MR | | | | DS | 306 | |------| MR | . . . | MR | 307 | (DR) | IPv6 | | IPv6 | (BG) | 308 +------+ +----+ +------+ 310 <------------------------------------- 312 Rcvr: Multicast receiver 313 DS : Dual stack 314 CE : Customer edge router (RFC 4605 compliant) 315 MR : Multicast router 316 DR : Designated router 317 BG : Border gateway 318 Src : Multicast source 320 Figure 2: Content Distribution When Interworking Is At the Customer 321 Edge (4-6-4 Scenario) 323 Content distribution starts at the source, which sends an IPv4 packet 324 of content with its own source address and the destination address 325 equal to that of the multicast group. The packet is routed through 326 the tree previously set up in the IPv4 network, eventually reaching 327 the edge of the IPv6 network. The dual stack node at that network 328 edge maps the incoming IPv4 source and group addresses to the 329 corresponding IPv6 addresses used for that channel in the IPv6 330 network. These are the same addresses used in the signalling stage. 332 At this point, the dual stack border element can take one of two 333 actions. Either it encapsulates the original IPv4 packet in an IPv6 334 header that uses the mapped IPv6 addresses as source and destination, 335 or it translates incoming IPv4 header to an IPv6 header, also using 336 the mapped addresses. The choice is a deployment decision. The 337 result in either case is an IPv6 packet which is forwarded through 338 the IPv6 network along the tree set up by previous signalling. 340 Eventually the packet reaches the dual stack customer edge device. 341 If the packet it receives was encapsulated, it only needs to 342 decapsulate the packet. If instead the packet header was translated 343 from IPv4 to IPv6, the customer edge device must now map the incoming 344 IPv6 source and group addresses to the IPv4 counterparts used to 345 request the channel in the signalling stage and then perform the 346 reverse translation. In either case it forwards the resulting packet 347 to the receiver. 349 3.2. The 4-6-4 Scenario Where Interworking Is Done At the Provider Edge 351 This case assumes that the multicast router at the provider edge is a 352 dual stack device offering an IPv4 interface to the customer site. 353 The signalling path is shown in Figure 3. 355 +------+ +------+ +------+ 356 | Host | | MR | PIM | MR | 357 | Rcvr | | | . . . . | | 358 | | | (BG) | IPv4 | (DR) | 359 +------+ +------+ +------+ 360 \ \ 361 IGMP \ IPv4 PIM \ IPv4 362 \ \ 363 +------+ +----+ +------+ 364 | DS | PIM | | PIM | DS | 365 | MR |------| MR | . . . | MR | 366 | (DR) | IPv6 | | IPv6 | (BG) | 367 +------+ +----+ +------+ 369 -------------------------------------> 371 Rcvr: Multicast receiver 372 DS : Dual stack 373 MR : Multicast router 374 DR : Designated router 375 BG : Border gateway 377 Figure 3: Multicast Signalling When Interworking Is At the Provider 378 Edge (4-6-4 Scenario) 380 [Signalling description -- can just give delta with respect to 381 previous section] 383 Figure 4 shows the path taken by content emitted by the source. 385 +------+ +------+ +------+ +-----+ 386 | Host | | MR | | MR | | | 387 | Rcvr | | | . . . | |------| Src | 388 | | | (BG) | IPv4 | (DR) | IPv4 | | 389 +------+ +------+ +------+ +-----+ 390 \ \ 391 \ IPv4 \ IPv4 392 \ \ 393 +------+ +----+ +------+ 394 | DS | | | | DS | 395 | MR |------| MR | . . . | MR | 396 | (DR) | IPv6 | | IPv6 | (BG) | 397 +------+ +----+ +------+ 399 <------------------------------------- 401 Rcvr: Multicast receiver 402 DS : Dual stack 403 MR : Multicast router 404 DR : Designated router 405 BG : Border gateway 406 Src : Multicast source 408 Figure 4: Content Distribution When Interworking Is At the Provider 409 Edge (4-6-4 Scenario) 411 4. The 6-4 Network Scenario 413 4.1. The 6-4 Scenario With IPv6 Access Network 415 In this scenario, the IPv6 receiver receives multicast content from 416 an IPv4 source, where signalling and content must pass through an 417 IPv6 network to which the receiver is attached. 419 4.2. The 6-4 Scenario With IPv4 Access Network 421 In this scenario, the IPv6 receiver receives multicast content from 422 an IPv4 source, where the receiver is attached to the IPv4 network. 424 5. The 6-4-6 Network Scenario 426 An alternative use case is the scenario where both the receivers and 427 the source are IPv6 capable, but the IPv6 connectivity among them is 428 provided over an IPv4-Only Network running Multiprotocol Label 429 Switching (MPLS). MPLS is a well understood and widely deployed 430 protocol in Service Provider's backbone networks: being able to 431 transport IPv6 traffic over an IPv4 MPLS network allows the Service 432 Providers to provide IPv6 connectivity to the edge of the network and 433 thus to offer IPv6 services, without having to upgrade to IPv6 the 434 backbone network. 436 RFC 4798 tackles the unicast angle of the problem and it explains how 437 to interconnect IPv6 islands over a Multiprotocol Label Switching 438 (MPLS)-enabled IPv4 cloud by using Multiprotocol Border Gateway 439 Protocol (MP-BGP) to exchange the IPv6 reachability information 440 transparently. The devices implementing this mechanism are called 441 IPv6 Provider Edge routers (6PE). The 6PE technique is currently 442 deployed for unicast traffic in several Service Provider's networks. 444 A similar approach would be useful for multicast services too, in 445 order to allow the Service Providers to start offering IPv6 multicast 446 contents (from its own multicast sources or provided by external 447 Content Providers) to new IPv6 customers. This mechanism would allow 448 the Service Providers to replicate for multicast contents, the same 449 architectural model currently deployed for unicast traffic with 6PE 450 method. In addition as this model does not require any translation 451 or interworking function it is expected it would be able to preserve 452 the service quality and the integrity of contents. 454 6. Conclusions 456 7. Acknowledgements 458 8. IANA Considerations 460 This memo includes no request to IANA. 462 9. Security Considerations 464 All drafts are required to have a security considerations section. 466 10. References 468 10.1. Normative References 470 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 471 Thyagarajan, "Internet Group Management Protocol, Version 472 3", RFC 3376, October 2002. 474 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 475 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 477 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 478 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 479 Protocol Specification (Revised)", RFC 4601, August 2006. 481 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 482 "Internet Group Management Protocol (IGMP) / Multicast 483 Listener Discovery (MLD)-Based Multicast Forwarding 484 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 486 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 487 IP", RFC 4607, August 2006. 489 [RFC5110] Savola, P., "Overview of the Internet Multicast Routing 490 Architecture", RFC 5110, January 2008. 492 10.2. Informative References 494 [ID.Multrans-DS-Lite] 495 Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y. 496 Lee, "Multicast Extensions to DS-Lite Technique in 497 Broadband Deployments (Work in Progress)", June 2011. 499 [ID.Multrans-Problem-Statement] 500 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 501 Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use 502 Cases (Work in Progress)", June 2011. 504 [ID.Multrans-Taxonomy] 505 Tsou, T., Zhou, C., and T. Taylor, "A Classification and 506 Evaluation of Approaches to Transitional Multicast (Work 507 in Progress)", March 2011. 509 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 510 Announcement Protocol", RFC 2974, October 2000. 512 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 513 A., Peterson, J., Sparks, R., Handley, M., and E. 514 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 515 June 2002. 517 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 518 Description Protocol", RFC 4566, July 2006. 520 Authors' Addresses 522 Tina Tsou 523 Huawei Technologies (USA) 524 2330 Central Expressway 525 Santa Clara, CA 95050 526 USA 528 Phone: +1 408 330 4424 529 Email: Tina.Tsou.Zouting@huawei.com 531 Cathy Zhou 532 Huawei Technologies 533 Bantian, Longgang District 534 Shenzhen 518129 535 P.R. China 537 Phone: 538 Email: cathy.zhou@huawei.com 540 Tom Taylor 541 Huawei Technologies 542 1852 Lorraine Ave 543 Ottawa, Ontario K1H 6Z8 544 Canada 546 Email: tom111.taylor@bell.net 548 Roberta Maglione 549 Telecom Italia 551 Email: roberta.maglione@telecomitalia.it