idnits 2.17.1 draft-jaclee-behave-v4v6-mcast-ps-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 14, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-09) exists of draft-boucadair-mmusic-altc-02 == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group C. Jacquenet 3 Internet-Draft M. Boucadair 4 Intended status: Informational France Telecom 5 Expires: September 15, 2011 Y. Lee 6 Comcast 7 J. Qin 8 ZTE 9 T. Tsou 10 Huawei Technologies (USA) 11 March 14, 2011 13 IPv4-IPv6 Multicast: Problem Statement and Use Cases 14 draft-jaclee-behave-v4v6-mcast-ps-01 16 Abstract 18 This document discusses issues and requirements raised by IPv4-IPv6 19 multicast interconnection and co-existence scenarios. It also 20 presents the various multicast use cases which may happen during IPv6 21 transitioning. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 15, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Dual-Stack Multicast Delivery Infrastructure . . . . . . . 8 71 3.4. Mono-Stack Multicast Delivery Infrastructure . . . . . . . 9 72 3.4.1. Translation Cases . . . . . . . . . . . . . . . . . . 11 73 3.4.2. Traversal Cases . . . . . . . . . . . . . . . . . . . 12 74 4. Issues and Required Functions . . . . . . . . . . . . . . . . 15 75 4.1. Fast Zapping . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.2. Group and Source Discovery Considerations . . . . . . . . 15 77 4.3. Subscription . . . . . . . . . . . . . . . . . . . . . . . 16 78 4.4. Multicast Tree Computation . . . . . . . . . . . . . . . . 16 79 4.5. SLA Considerations . . . . . . . . . . . . . . . . . . . . 16 80 4.6. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 16 81 4.7. Bandwidth Consumption . . . . . . . . . . . . . . . . . . 17 82 4.8. ASM-SSM Considerations . . . . . . . . . . . . . . . . . . 17 83 4.9. Interconnection Functions . . . . . . . . . . . . . . . . 17 84 4.9.1. Interworking Functions for Control Flows . . . . . . . 17 85 4.9.2. Interconnection Function for Data . . . . . . . . . . 18 86 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 In current operational deployments, IP multicast forwarding scheme is 98 used by many service providers to deliver Live TV broadcasting 99 services. Numerous players intervene in the delivery of this 100 service: (1) Content providers: the content can be provided by the 101 same provider as the one providing the connectivity service or by 102 distinct providers (e.g., external paid channels); (2) Network 103 provider: is responsible for carrying multicast flows from head-ends 104 to receivers. 106 During the transition of multicast to IPv6, there will be various 107 issues encountered and requirements raised correspondingly. The 108 requirement of service continuity should be an essential one which 109 may include: the access to legacy contents (IPv4 framed) from 110 receivers is still available where if the assignment of a dedicated 111 global IPv4 address to the receiver is not possible anymore or even 112 after the receivers are migrated to IPv6 and; the delivery of new 113 contents (IPv6 framed) to legacy receivers is also possible and; in 114 cases where if underlying transport network(s) is of different 115 address family than that of the source and/or receivers, the delivery 116 of multicast data is still available (e.g., in the context of DS-Lite 117 deployment, the network has been firstly upgraded to IPv6 while the 118 source and receivers are not). 120 This document does make any assumption on the techniques used for the 121 delivery of multicast services (e.g., native IP multicast with or 122 without traffic isolation features, use of P2MP RSVP-TE, P2MP mLDP 123 LSPs, mVPN, etc. ). 125 This document further elaborates on the context and discusses 126 multicast-inferred issues and requirements. 128 1.1. Goals 130 The goal is to clarify the problem space and get a general consent of 131 the objectives. In particular, the ambition is to provide answers 132 to: 134 o What are the hurdles encountered for the delivery of multicast- 135 based service offerings when both IPv4 and IPv6 co-exist? 137 o What standardization effort is needed: is there any missing 138 function and protocol extensions? 140 o Check if both encapsulation and translation schemes are concerned. 142 1.2. Terminology 144 This document uses the following terms: 146 o Multicast Source: Source, in short 148 o Multicast Receiver: Receiver, in short, e.g.- STB 150 o Multicast Delivery Network: Network in short, covers the realm 151 from DR device (directly connected to the Source) to IGMP/MLD 152 Querier device (directly connected to the Receiver). 154 2. Discussion 156 Global IPv4 address depletion inevitably challenges service providers 157 who must guarantee IPv4 service continuity during the forthcoming 158 transition period. In particular, access to IPv4 contents that are 159 multicast to IPv4 receivers becomes an issue when the forwarding of 160 multicast data assumes the use of global IPv4 addresses. 162 The rarefaction of global IPv4 addresses may indeed affect the 163 multicast delivery of IPv4-formatted contents to IPv4 receivers. For 164 example, the observed evolution of access infrastructures from a 165 service-specific, multi-PVC scheme towards a "service-agnostic", 166 single PVC scheme, assumes the allocation of a globally unique IPv4 167 address on the WAN interface of the CPE (or to a mobile terminal), 168 whatever the number and the nature of the services the customer has 169 subscribed to. 171 During the transition period, the usage of the remaining global IPv4 172 address blocks will have to be rationalized for the sake of IPv4 173 service continuity. The current state-of-the-art suggests the 174 introduction of NAT capabilities (generally denoted as CGN, for 175 Carrier-Grade NAT) in providers networks, so that global IPv4 176 addresses will be shared between several customers. As a 177 consequence, CPE or mobile UE devices will not be assigned a 178 dedicated global IPv4 address anymore, and IPv4 traffic will be 179 privately-addressed until it reaches one of the NAT capabilities 180 deployed in the network. From a multicast delivery standpoint, this 181 situation suggests the following considerations: 183 o The current design of some multicast-based services like TV 184 broadcasting often assumes that IPv4 multicast forwarding relies 185 upon the use of a private IPv4 addressing scheme because of a 186 walled garden approach. Privately-addressed IGMP [RFC2236] 187 [RFC3376] traffic sent by IPv4 receivers is generally forwarded 188 over a specific (e.g. "IP TV") PVC towards an IGMP Querier 189 located in the access infrastructure, e.g.- in some deployments it 190 is hosted by a BRAS device that is the PPP session endpoint and 191 which may also act as a PIM DR [RFC4601] router. This design does 192 not suffer from global IPv4 address depletion by definition. But 193 it will be questioned when migrating the access infrastructure 194 towards a publicly-addressed single PVC design scheme. 196 o The progressive introduction of IPv6 as the only perennial 197 solution to global IPv4 address depletion does not necessarily 198 assume that multicast-based IPv4 services will be migrated 199 accordingly. Access to IPv4 multicast contents raises several 200 issues: (1) The completion of the IGMP-based multicast group 201 subscription procedure, (2) The computation of the IPv4 multicast 202 distribution tree, and (3) The IPv4-inferred addressing scheme to 203 be used in a networking environment which will progressively 204 become IPv6-enabled, but not necessarily IPv6 multicast enabled. 206 o In any case, contents should not be multicast twice (using both 207 versions of IP) for the sake of bandwidth optimization. Injecting 208 multicast content using both IPv4 and IPv6 raises some 209 dimensioning issues that should be carefully evaluated by service 210 providers during network planning. For instance, if only few 211 IPv6- enabled receivers are in use, it can be more convenient to 212 convey multicast traffic over IPv4 rather than doubling the 213 consumed resources for few users. 215 There are at least several options that can deal with the 216 aforementioned considerations. 218 1. Stick to a walled garden design that relies upon a private IPv4 219 addressing scheme. But this approach jeopardizes the evolution 220 of access networking infrastructures towards the use of a unique, 221 per-customer, globally-addressed, service-wise PVC design scheme. 222 And it also delays migration towards IPv6 instead of encouraging 223 it. 225 2. Use AMT (Automatic Multicast without explicit Tunnels, 226 [I-D.ietf-mboned-auto-multicast]), to encapsulate IGMP traffic 227 into UDP packets that will be sent to an AMT Relay located 228 upstream in the network. This approach may not be suitable for 229 the delivery of IP TV content in operational networks mainly due 230 to delays which may be experienced for zapping. 232 Note that unicast IP addresses are used for communicating with 233 service platforms to get control information (e.g., channel lists) 234 and, as the identification of customers for management, traffic 235 engineering, etc. 237 The following sections elaborate more on the use cases, issues and 238 requirements. 240 3. Use Cases 242 3.1. Purpose 244 This section describes a set of use cases which need to be 245 considered. 247 As mentioned above, the walled garden scheme where private IPv4 248 addresses are used for the delivery of multicast-based service 249 offerings is out of scope. 251 3.2. Context 253 During transitioning, there might be a mix of multicast receivers, 254 sources, and networks running in different address families. 255 However, the operator should continue to deliver the multicast 256 service to both IPv4 and IPv6 receivers. Since there is mis-match of 257 IP address family of sources, receiver, and delivery network, the 258 operator should plan carefully and choose the right transition 259 technique that could efficiently utilize the network resources to 260 deliver the services. 262 Both fixed (Figure 1) and mobile networks (Figure 2, which reflects 263 the current status of the IPv6 Study Item conducted within 3GPP and 264 some public plans for the LTE deployment) have been considered. 266 +------------+-----------+-------------+-----------+----------------+ 267 | Deployment | Legacy | CPE | Legacy | Underlying IP | 268 | Model | Receiver | | Source | capabilities | 269 +------------+-----------+-------------+-----------+----------------+ 270 | DS | IPv4-only | IPv4-only | IPv4-only | IPv4 and IPv6 | 271 | | | and DS | | | 272 +------------+-----------+-------------+-----------+----------------+ 273 | DS-Lite | IPv4-only | IPv4-only | IPv4-only | IPv4 and IPv6 | 274 | (*) | | and DS-Lite | | | 275 +------------+-----------+-------------+-----------+----------------+ 276 | Greenfield | -- | IPv6-only | --- | IPv6 | 277 | IPv6 | | | | | 278 +------------+-----------+-------------+-----------+----------------+ 279 | Hybrid | IPv4-only | IPv4-only, | IPv4-only | IPv4 and IPv6 | 280 | (**) | | DS and | | | 281 | | | DS-Lite | | | 282 +------------+-----------+-------------+-----------+----------------+ 283 (*) In case of Greenfield DS-Lite, there is no legacy CPE/Source 284 (**) Hybrid is used to denote a network where customers may be 285 IPv4-only DS and/or DS-Lite serviced. 287 Figure 1: IPv6 integration scenarios in fixed networks. 289 +----------------+-----------+---------------+--------------------+ 290 |Deployment Model| Legacy UE | Legacy source |Network Capabilities| 291 +----------------+-----------+---------------+--------------------+ 292 | DS PDP | IPv4-only | IPv4-only | IPv4 and IPv6 | 293 +----------------+-----------+---------------+--------------------+ 294 |IPv6-only PDP | IPv4-only | IPv4-only | IPv4 and IPv6 (*) | 295 +----------------+-----------+---------------+--------------------+ 297 (*) The underlying network is likely to be dual-stack except for 298 IPv6 greenfield deployments. 300 Figure 2: IPv6 integration scenarios in mobile networks (PDP 301 Activation). 303 There are three variables to be considered when analyzing the 304 multicast use cases, "Source", "Receiver" and the "Multicast Delivery 305 Infrastructure" (denoted for short as "Network"). 307 To simplify the analysis, one of the variables: "Network", is hold. 308 So based on the capabilities of the underlying multicast delivery 309 infrastructure. According to the above figures, two use cases can be 310 considered: 312 o Dual-Stack: Both IPv4 and IPv6 multicast delivery function are 313 wholly enabled; 315 o Mono-Stack: Not wholly dual-stack enabled but for example, is 316 either IPv4-only or IPv6-only, or may be a hybrid of IPv4 portion 317 and IPv6 portion (refer to Hybrid cases in Figure 5). 319 3.3. Dual-Stack Multicast Delivery Infrastructure 321 Dual-stack model is supposed to be the most straight forward 322 deployment model where the network is dual-stack and the same content 323 is sourced into both IPv4 and IPv6 multicast stream. Depending on 324 the receiver, it could choose to listen to either stream. 326 [NOTE: if the source is framed in single stack (i.e., IPv4-only or 327 IPv6-only) or the network is not wholly dual-stack enabled, even 328 there are both IPv4 and IPv6 receivers, it should not be regarded 329 as the Dual-Stack Model use case. 331 In this case, since the stream from source to receivers of the 332 same address family can be natively delivered without any new 333 functions, the native delivery portion is not taken into account. 334 Then this is regarded as one of Mono-Stack Model cases. For 335 example, the case where the source is IPv4 framed while the 336 network is wholly dual-stack enabled and there are both IPv4 and 337 IPv6 receivers, is simply regarded as the Case 1 in Mono-Stack 338 Model; Or for example, the case where the source and receivers are 339 dual-stack, and the network is IPv6-only, is regarded as Case 6, 340 also refer to Section 3.4.2.] 342 This model assumes the multicast content and delivery infrastructure 343 is dual-stack. This assumption may not be valid because the dual- 344 stack formatted source may not always be available since numerous 345 players intervene in the delivery of multicast-based service: content 346 providers and the network provider. The content may not be 347 controlled by the underlying network providers. 349 For this scenario, legacy IPv4 receivers will continue to access to 350 IPv4-formatted multicast content. 352 Figure 3 summarizes the issues encountered if this option is used. 354 +-----------------+----------------------------------------------+ 355 | Deployment Model| Comments | 356 +-----------------+----------------------------------------------+ 357 | DS | No issue is encountered | 358 +-----------------+----------------------------------------------+ 359 | DS-Lite | For IPv4-only receivers, extra functions are | 360 | | required to deliver the multicast service | 361 +-----------------+----------------------------------------------+ 362 | Hybrid | Idem as per DS-Lite case | 363 +-----------------+----------------------------------------------+ 365 Figure 3: Impact analysis. 367 From a bandwidth perspective, it is not viable to duplicate the same 368 content in IPv4 and IPv6. Indeed, injecting multicast content using 369 both IPv4 and IPv6 raises dimensioning issues that should be 370 carefully evaluated by service providers (in particular in the access 371 network). For instance, if only few IPv6-enabled receivers are in 372 use, it is more convenient to convey multicast traffic over IPv4 373 rather than doubling the consumed network resources for few users. 375 Figure 4 summarizes the main characteristics of this use case: 376 +--------+----------------------------------------------------------+ 377 | Pros | Limitations | 378 +--------+----------------------------------------------------------+ 379 | Simple | * CAPEX (e.g., bandwidth cost) | 380 | | * Requires coordination between the content and the | 381 | | network providers | 382 | | * Despite DS-formatted content, extensions are still | 383 | | required to deliver the content to IPv4-only receivers | 384 | | when DS-Lite is deployed. | 385 +--------+----------------------------------------------------------+ 387 Figure 4: Main Characteristics. 389 3.4. Mono-Stack Multicast Delivery Infrastructure 391 Consider now the case where the multicast content is reachable only 392 with one single address family (i.e., IPv4 or IPv6). Depending on 393 transition steps, the source could stay in IPv4 or move to IPv6. And 394 the legacy receivers are IPv4-reachable while the new receivers may 395 be IPv6-enabled. 397 +-------+------------+------------+------------+-------------+ 398 | Use | Network | Source | Receiver | Use Case | 399 | Cases |Capabilities| | | Categories | 400 +-------+------------+------------+------------+-------------+ 401 | 1 | | IPv4 | IPv6 | | 402 +-------+ +------------+------------+ Translation | 403 | 2 | IPv4 | IPv6 | IPv4 | | 404 +-------+ +------------+------------+-------------+ 405 | 3 | | IPv6 | IPv6 | Traversal | 406 +-------+------------+------------+------------+-------------+ 407 | 4 | | IPv4 | IPv6 | | 408 +-------+ +------------+------------+ Translation | 409 | 5 | IPv6 | IPv6 | IPv4 | | 410 +-------+ +------------+------------+-------------+ 411 | 6 | | IPv4 | IPv4 | Traversal | 412 +-------+------------+------------+------------+-------------+ 413 | | | IPv4, IPv6 | IPv4, IPv6 | | 414 |Hybrid*| IPv4, IPv6 +------------+------------+ Hybrid | 415 | | | IPv4, IPv6 | IPv4, IPv6 | | 416 +-------+------------+------------+------------+-------------+ 418 Figure 5: Mono-stack use cases 420 * In Hybrid cases, the network is partially IPv4 and partially IPv6. 422 See below: 424 --------------- 425 // R4 S4 \\ S6 = v6 Source 426 / +----+ | R6 = v6 Receiver 427 +----+ IPv4 | DR |----| S4 = v4 Source 428 R6 ---| QR | Network +----+ |- S6 R4 = v4 Receiver 429 +----+ / | DR = Designated Router 430 \\ // QR = IGMP/MLD Querier 431 --------------- 433 Figure 6: IPv4 Delivery Network 435 --------------- 436 // R6 S6 \\ S6 = v6 Source 437 / +----+ | R6 = v6 Receiver 438 +----+ IPv6 | DR |----| S4 = v4 Source 439 R4 ---| QR | Network +----+ |- S4 R4 = v4 Receiver 440 +----+ / | DR = Designated Router 441 \\ // QR = IGMP/MLD Querier 442 --------------- 444 Figure 7: IPv6 Delivery Network 446 --------------- -------------- 447 // R6 S6 \\ // R4 S4 \\ 448 / IPv6 +------+ IPv4 \ 449 | Network | MR | Network | 450 \ +------+ / 451 \\ // \\ // 452 -------------- --------------- 453 S6 = v6 Source 454 R6 = v6 Receiver 455 S4 = v4 Source 456 R4 = v4 Receiver 457 MR = Multicast Router, could be border router connecting 458 IPv4 and IPv6 network, or DR connecting the source, 459 or QR connecting the receiver 461 Figure 8: Hybrid Delivery Network 463 3.4.1. Translation Cases 465 If the multicast source and receiver are belonging to different 466 address families, translation happens. The locations of translation 467 functions defers according to the address family of delivery network. 469 The translation can happen either close to the source or close to the 470 receiver. Depending on the deployment model, this decision may 471 result a different transition technology being selected. Only a 472 single distribution tree is required if only one address family is 473 serviced by a given transport network. 475 The content will be delivered once which is better utilized the 476 network bandwidth. However if the application relies on the IP 477 information stored in the payload (e.g., SDP), then translation will 478 break the application. 480 +-----------------------+-------------------------------------------+ 481 | Pros | Limitations | 482 +-----------------------+-------------------------------------------+ 483 | Bandwidth utilization | * Receivers have to know the translated | 484 | | source address in the context SSM | 485 | | * Receivers would have to know the | 486 | | translated multicast group address | 487 | | * The information loss during the | 488 | | translation operations | 489 | | * The burden and necessary coordinations | 490 | | are involved if stateful translations are | 491 | | employed | 492 | | * ALGs may be required to assist the | 493 | | discovery of source address and multicast | 494 | | group address | 495 +-------------------------------------------------------------------+ 497 Figure 9: Main Characteristics of translation-based schemes. 499 [NOTE: Access to IPv6-only multicast content by legacy customers 500 is not seen as a valid scenario; especially in the context of IP 501 TV service offering. Whenever this configuration is met by an 502 operator, it MAY consider the following mitigation alternatives: 504 * Enable IPv4-IPv6 interconnection functions to allow the 505 successful delivery of IPv6-only multicast content to IPv4-only 506 receivers 508 * Or swap the receiver device (e.g., STB) with a new dual-stack 509 one if the provider controls STB and/or CPE devices.] 511 3.4.2. Traversal Cases 513 If the multicast source and receiver are belonging to the same 514 address family, while the delivery network is not. 516 A viable scenario for this use case is DS-Lite Model: Customers with 517 legacy receivers must continue to access the IPv4-enabled multicast 518 services. This means the traffic should be accessed over IPv4. The 519 following cases should be covered by any candidate solution to the 520 issue of forwarding IPv4 multicast traffic in DS-Lite environment: 521 (1) IPv4-only multicast receiver; (2) Dual-Stack multicast receiver. 522 As for the content, two scenarios are considered as valid ones: (1) 523 IPv4-only content; (2) Dual-Stack content (i.e., content reachable in 524 both IPv4 and IPv6). 526 Note that: 528 1. The legacy IPv4 receiver can access dual-stack and IPv4-only 529 content. No issue is induced by this scenario. Multicast flows 530 will be delivered using native IPv4 transfer mode. 532 2. An IPv4-only receiver behind a DS-Lite CGN: Additional functions 533 are required to deliver the content to the receiver; 535 3. A dual stack receiver should access a dual stack content using 536 IPv6. No extra function is required to implement this scenario; 538 4. Dual-Stack receiver accessing IPv4-only content: This scenario is 539 similar to the IPv4-only receiver accessing the IPv4-only content 540 (2nd bullet). Additional functions are required. 542 In order to deliver IPv4 multicast flows to DS-Lite serviced users, 543 two solution flavors can be envisaged: 545 +---------------+---------------------------------------------------+ 546 | Solution | Characteristics | 547 | Flavor | | 548 +---------------+---------------------------------------------------+ 549 | Translation | For IPv4 content, introduce an IPv4-IPv6 | 550 | | translator in the provider's network. Multicast | 551 | | streams will then be delivered to the receivers | 552 | | using IPv6 until the CPE. A second level of NAT | 553 | | can then be enforced if the receiver is | 554 | | IPv4-only | 555 | +---------------------------------------------------+ 556 | | This solution may require two | 557 | | translation levels, can impact the overall | 558 | | performance of the CPE, may alter the perceived | 559 | | quality of experience, etc. This solution may be | 560 | | the source of service disruption (especially for | 561 | | live TV broadcasting). This is not desirable | 562 | +---------------------------------------------------+ 563 | | For IPv6 content, all streams are delivered to | 564 | | the DS-Lite CPE using IPv6; an IPv4-IPv6 | 565 | | translator can be enabled in the CPE to forward | 566 | | the streams to an IPv4-only receiver. The | 567 | | IPv4-IPv6 translation function may impact the | 568 | | performance of the CPE | 569 +---------------+---------------------------------------------------+ 570 | Encapsulation | To access IPv4 content from an IPv4-only or | 571 | | dual-stack receiver: If the receiver encapsulates | 572 | | the multicast signaling, it will result packet | 573 | | replication per tunnel interface. If the | 574 | | underneath network is not aware of the multicast | 575 | | topology, it will deliver the encapsulated | 576 | | multicast packets as unicast packets. The | 577 | | replication will happen at the encapsulator | 578 | | rather than the edge multicast router. This | 579 | | would poorly utilize the network bandwidth | 580 | +---------------------------------------------------+ 581 | | This problem could be mitigated. If the | 582 | | encapsulator translates the multicast group | 583 | | address to another address family and uses it for | 584 | | the multicast signaling, the underneath network | 585 | | could build a multicast distribution tree using | 586 | | the translated multicast address. Thus, the | 587 | | network could deliver the encapsulated packets in | 588 | | the standard multicast fashion using the | 589 | | multicast delivery tree built by the translated | 590 | | multicast address group. In other words, the | 591 | | encapsulator bridges two multicast trees at the | 592 | | control plane but performs encapsulation at the | 593 | | data plane. This is a hybrid of translation and | 594 | | encapsulation mechanisms | 595 | +---------------------------------------------------+ 596 | | Since legacy IPv4-only receivers are predominant, | 597 | | it is optimal to enable the IPv4-IPv6 | 598 | | encapsulation function closer to the receivers | 599 | | (e.g., first IP node). Doing so, would lead to a | 600 | | single core multicast tree and flow replication | 601 | | to DS-Lite serviced devices will occur upon | 602 | | request. Multicast flows are not replicated in | 603 | | the core and aggregation network | 604 | +---------------------------------------------------+ 605 | | If the IPv4-IPv6 encapsulation function is | 606 | | implemented deeper in the network, and since | 607 | | legacy customers need to be serviced in IPv4, | 608 | | multicast flows are likely to be duplicated | 609 | | (native, encapsulated) which is not optimal | 610 | +---------------------------------------------------+ 611 | | The IPv4-in-IPv6 encapsulated multicast flows | 612 | | destined to IPv4-embedded IPv6 group address are | 613 | | treated as any IPv6 multicast flows, and can be | 614 | | replicated within Multicast VLANs. | 615 | | Mechanisms such as MLD Snooping or MLD Proxying | 616 | | can be introduced into the distributed | 617 | | Access Network Nodes which could behave as MLD | 618 | | Queriers and replicate multicast flows as | 619 | | appropriate | 620 | +---------------------------------------------------+ 621 | | To access IPv6 content from a dual-stack | 622 | | receiver: No new function is required since | 623 | | native multicast IPv6 functions can be used | 624 +---------------+---------------------------------------------------+ 626 Figure 10: DS-Lite Mode: Translation and Encapsulation schemes. 628 4. Issues and Required Functions 630 It is not so easy to provide a single solution which will be 631 convenient for all Service Providers. This is even complex if we 632 consider real deployments where the network is a collection of: 633 Legacy, DS, DS-Lite, PPP, DHCP, GE, ATM, PIM-SM, SSM, P2MP LSP, mVPN, 634 etc. However, the following requirements should be taken into 635 account. 637 4.1. Fast Zapping 639 The IGMP Leave latency may be an issue when considering channel 640 zapping. In current IPv4-based TV service offerings, when a user 641 changes a TV channel, an IGMP Leave message is sent followed by an 642 IGMP Report to join a new channel. This may lead to two channels to 643 be sent to the receiver and as a consequence a traffic peak which may 644 cause congestion on access links is experienced. 646 A procedure called IGMP Fast-Leave is commonly used to avoid this 647 problem and to immediately stop the multicast stream as soon as the 648 IGMP Leave is received. In some operational deployments, IGMP fast- 649 leave requires the activation of an IGMP Proxy. 651 Fast zapping functions MUST be taken into account when dealing 652 with IPv4-IPv6 multicast delivery. In particular, the multicast 653 transition technique MUST continue to support IGMP/MLD Fast-Leave. 655 4.2. Group and Source Discovery Considerations 657 An ALG is required to help an IPv6 receiver to select the appropriate 658 IP address when only the IPv4 address is advertised (e.g., using 659 SDP); otherwise the access to the IPv4 multicast content can not be 660 offered to the IPv6 receiver. 662 The ALG may be located downstream the receiver. As such, the ALG 663 does not know in advance whether the receiver is dual-stack or IPv6- 664 only. 666 The ALG may be tuned to insert both the original IPv4 address and 667 corresponding IPv6 multicast address using for instance the ALTC SDP 668 attribute [I-D.boucadair-mmusic-altc]. 670 In order to avoid involving an ALG in the path, an IPv4-only source 671 can advertise both its IPv4 address and IPv4-embedded IPv6 multicast 672 address using for instance the ALTC SDP attribute. However, a dual- 673 stack receiver may prefer to use the IPv6 address to receive the 674 multicast content. This address selection would require multicast 675 flows to cross an IPv4-IPv6 interconnection function. 677 4.3. Subscription 679 Multicast distribution trees are receiver-initiated. IPv4 receivers 680 that wish to subscribe to an IPv4 multicast group will send the 681 corresponding IGMP Report message towards the relevant IGMP Querier. 682 In case the underlying network is IPv6, the information conveyed in 683 IGMP messages should be relayed into corresponding MLD messages. 685 4.4. Multicast Tree Computation 687 Grafting to an IPv4 multicast distribution tree through an IPv6 688 multicast domain suggests that IPv4 multicast traffic will have to be 689 conveyed along an "IPv6-equivalent" multicast distribution tree. 690 That is, part of the multicast distribution tree along which IPv4 691 multicast traffic will be forwarded SHOULD be computed and maintained 692 by means of the PIMv6 machinery, so that the distribution tree can be 693 terminated as close to the IPv4 receivers as possible for the sake of 694 the multicast forwarding efficiency. This assumes a close 695 interaction between the PIM designs enforced in both domains. Such 696 interaction may be further complicated by different combinations: the 697 IPv4 multicast domain is SSM-enabled (with no RP routers), while the 698 IPv6 multicast domain may support both ASM and SSM [RFC3569] modes. 700 4.5. SLA Considerations 702 Some contract agreements may prevent a network provider to alter the 703 content as sent by the content provider, in particular for copyright, 704 confidentiality and SLA assurance reasons. 706 The streams should be delivered without alteration to requesting 707 users. Crossing a NAT or enforcing an encapsulation may lead to 708 fragmentation or extra delays and therefore impact the perceived 709 quality of service. 711 4.6. Load Balancing 713 In some operational networks, a source-based NAT function is used for 714 load-balancing purposes. Because of some operational issues induced 715 by this NAT function, plans to remove the stateful NAT function are 716 adopted by some operators. 718 Since the same concern apply for stateful IPv4-IPv6 translation 719 function, stateless interconnection function SHOULD be privileged. 721 4.7. Bandwidth Consumption 723 As a reminder, to optimize the usage of network resources, all 724 multicast streams are conveyed in the core network while only popular 725 ones are continuously conveyed in the aggregation/access network 726 (static mode). Non-popular streams are conveyed in the access 727 network upon request (dynamic mode). 729 It should be noted that the dynamic mode may have a negative impact 730 on end users experiences (i.e., a channel change takes longer for the 731 new channel because it needs to be requested from the network - in 732 worst case the requests needs to go all way to the source). 734 IPv4/IPv6 co-existence solutions should be designed to optimize 735 network resource utilization. 737 4.8. ASM-SSM Considerations 739 The ASM mode would be used to optimize the forwarding of IPv4 740 multicast data sent by different sources into the IPv6 multicast 741 domain by selecting privileged RP routers that could be located at 742 the border between the IPv6 and the IPv4 multicast domains. 744 [To be further elaborated.] 746 4.9. Interconnection Functions 748 As mentioned above, several interconnection functions are required. 749 These functions can be divided into: 751 1. Interworking functions for control messages 753 2. Interconnection function for data flows. 755 4.9.1. Interworking Functions for Control Flows 757 The following sub-sections describes some interworking functions 758 which may be required. 760 4.9.1.1. IGMP-MLD Interworking 762 IGMP-MLD Interworking Function combines the IGMP/MLD Proxying 763 function specified in [RFC4605] and the IGMP/MLD adaptation function 764 which is meant to reflect the contents of IGMP messages into MLD 765 messages, vice versa. 767 For example, when an IGMP Report message is received from a receiver 768 to subscribe to a given multicast group G (and optionally associated 769 to a source if SSM mode is used), the IGMP-MLD Interworking Function 770 MUST send an MLD Report message to subscribe to the corresponding 771 IPv6 group. 773 4.9.1.2. IPv4-IPv6 PIM Interworking 775 [RFC4601] allows the computation of PIM-based IPv4 or IPv6 776 distribution trees; PIM is IP version agnostic. There is no specific 777 IPv6 PIM machinery that would work differently than an IPv4 PIM 778 machinery. The new things needed for the IPv4-IPv6 PIM Interworking 779 Function are just to allow the PIM message received from one address 780 family to correspondingly trigger the operation of the other address 781 family per PIM machinery specified. 783 The address mapping MUST be performed similarly to that of the IGMP- 784 MLD Interworking Function. 786 4.9.1.3. MLD-IPv4 PIM Interworking 788 This function is required when the MLD Querier is connected to an 789 IPv4 PIM realm and not an IPv6 one. 791 The address mapping MUST be performed similarly to that of the IGMP- 792 MLD Interworking Function. 794 4.9.1.4. IGMP-IPv6 PIM Interworking 796 Similar to the previous sub-section. 798 The address mapping MUST be performed similarly to that of the IGMP- 799 MLD Interworking Function. 801 4.9.2. Interconnection Function for Data 803 According to different scenarios, translation or encapsulation 804 mechanism can be used for traffic flows interconnection. 806 The behavior of this interconnection function MUST be specified. 808 5. Conclusions 810 The analysis above has shown: 812 1. Operational networks are complex environments; these networks are 813 likely to be hybrid ones. 815 2. Some issues are deployment-specific (e.g., density of IPv6- 816 enabled customers attached to an access network, if only few 817 IPv6-enabled receivers are in use it is more convenient to convey 818 multicast traffic over IPv4 rather than doubling the consumed 819 network resources for few users, etc.). 821 3. For all use cases, a solution is required for the delivery of 822 multicast-based services to DS-Lite serviced customers. 824 4. For DS-Lite, encapsulation and translation solutions rely on the 825 same control functions; the only difference is in the treatment 826 of data flows. 828 5. Standardizing the algorithms for IPv4-IPv6 Interworking functions 829 should be undertaken for both encapsulation and translation. 831 6. Some performance analysis are required to assess the impact of 832 activating some extra functions on the CPEs (e.g., assess the 833 impact of de-capsulation function compared to translation 834 function, evaluate the impact on CPE when several receivers are 835 behind the same CPE, etc.). 837 6. IANA Considerations 839 This document makes no request of IANA. 841 Note to RFC Editor: this section may be removed on publication as an 842 RFC. 844 7. Security Considerations 846 Access to contents in a multicast-enabled environment raises 847 different security issues that have been already documented. This 848 draft does not introduce any specific security issue. 850 8. Acknowledgments 852 Many thanks to N. Leymann for his comments. 854 9. References 855 9.1. Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 861 Thyagarajan, "Internet Group Management Protocol, Version 862 3", RFC 3376, October 2002. 864 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 865 Multicast (SSM)", RFC 3569, July 2003. 867 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 868 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 869 Protocol Specification (Revised)", RFC 4601, August 2006. 871 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 872 "Internet Group Management Protocol (IGMP) / Multicast 873 Listener Discovery (MLD)-Based Multicast Forwarding 874 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 876 9.2. Informative References 878 [I-D.boucadair-mmusic-altc] 879 Boucadair, M., Kaplan, H., Gilman, R., and S. 880 Veikkolainen, "Session Description Protocol (SDP) 881 Alternate Connectivity (ALTC) Attribute", 882 draft-boucadair-mmusic-altc-02 (work in progress), 883 March 2011. 885 [I-D.ietf-mboned-auto-multicast] 886 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 887 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 888 (AMT)", draft-ietf-mboned-auto-multicast-10 (work in 889 progress), March 2010. 891 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 892 2", RFC 2236, November 1997. 894 Authors' Addresses 896 Christian Jacquenet 897 France Telecom 899 Email: christian.jacquenet@orange-ftgroup.com 900 Mohamed Boucadair 901 France Telecom 902 Rennes 35000 903 France 905 Email: mohamed.boucadair@orange-ftgroup.com 907 Yiu Lee 908 Comcast 909 US 911 Email: Yiu_Lee@Cable.Comcast.com 913 Jacni Qin 914 ZTE 915 China 917 Email: jacniq@gmail.com 919 Tina Tsou 920 Huawei Technologies (USA) 921 2330 Central Expressway 922 Santa Clara, CA 95050 923 USA 925 Phone: +1 408 330 4424 926 Email: tena@huawei.com