idnits 2.17.1 draft-tsou-mboned-multrans-addr-acquisition-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 (February 17, 2012) is 4445 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 A. Clauberg 5 Expires: August 20, 2012 Deutsche Telekom 6 M. Boucadair 7 France Telecom 8 S. Venaas 9 Cisco Systems 10 Q. Sun 11 China Telecom 12 February 17, 2012 14 Address Acquisition For Multicast Content When Source and Receiver 15 Support Differing IP Versions 16 draft-tsou-mboned-multrans-addr-acquisition-00 18 Abstract 20 During the transition from IPv4 to IPv6, scenarios can occur where 21 the IP version supported by the receiver differs from that supported 22 by the source. This memo examines and evaluates alternative 23 strategies for allowing the receiver to acquire multicast address 24 information in such scenarios in the version it supports. 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 20, 2012. 43 Copyright Notice 45 Copyright (c) 2012 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 2. Which Problem Are We Solving? . . . . . . . . . . . . . . . . . 3 62 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . . 4 64 3.2. Dynamic Modification . . . . . . . . . . . . . . . . . . . 5 65 3.3. Administrative Preparation . . . . . . . . . . . . . . . . 5 66 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 71 Appendix A. Some Background On Program Guides . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Discussion of the multicast transition problem has focussed on the 77 case of unidirectional delivery of multicast content. Within this 78 scenario, the operation of viewing a program follows a well-defined 79 sequence. For the sake of reducing the zapping delay, the list of 80 multicast addresses is generally pre-provisioned to the receiver as 81 part of the program guide prior to requesting access to the multicast 82 content. At some subsequent time the user chooses to view a program, 83 possibly by selecting it from a displayed program guide, or simply by 84 selecting a channel. The receiver uses its pre-acquired information 85 to signal to the network to receive the desired content. In 86 particular, the receiver initiates reception of multicast content 87 using the multicast group address and possibly a unicast source 88 address supplied within the program information. 90 If the network, the source of the multicast content, and the 91 receivers all use IPv4, it is evident that the program information 92 will only include IPv4 multicast group addresses (and optionally, 93 IPv4 unicast source addresses). Suppose now, as can occur in some 94 transition scenarios, that IPv6-only receivers acquire program 95 information containing these IPv4 addresses. Then there will be a 96 mismatch: the IPv6-only receivers will be unable to use the addresses 97 that are provided in the program information. This memo examines the 98 possible strategies for remedying this mismatch, evaluating them in 99 terms of their impact on receiver implementation and network 100 operation. 102 This document makes reference to some of the scenarios described in 103 Section 3 of [ID.jaclee-behave-v4v6-multicast-ps]. The remarks in 104 Section 4.1 of [ID.jaclee-behave-v4v6-multicast-ps] are relevant to 105 the problem considered here, but are more restricted in scope. 107 2. Which Problem Are We Solving? 109 In some transition scenarios, the source supports one IP version 110 while the receiver and the provider network support the other (e.g., 111 the source supports IPv4, the receiver and the network to which it is 112 attached support IPv6). In this case, the problem stated above can 113 be expressed as follows: how does the receiver acquire addresses of 114 the IP version it supports, possibly with the help of the provider 115 network? 117 In other transition scenarios, the source and provider network may 118 support one IP version while the receiver supports another. In this 119 case there are actually two problems: how the receiver acquires 120 addresses that it supports (as already stated), and how to make those 121 addresses usable in a network supporting a different version? This 122 second problem is the subject of a different memo and out of scope of 123 the present one. 125 There is also a third class of scenarios, where the source and 126 receiver support the same IP version but the intervening network 127 supports a different one (e.g., the 4-6-4 scenario, Section 3.1 of 128 [ID.jaclee-behave-v4v6-multicast-ps]). In those scenarios, 129 delivering addresses of the right IP version to the receiver within 130 the program guide is notionally a non-problem. The problem still can 131 arise, if the intervening network intercepts and modifies the program 132 guide to be consistent with the IP version it supports. In this 133 case, the problem can be re-stated as: how can such modification be 134 avoided when it is not needed? 136 3. Possible Solutions 138 This section explores three classes of solutions to the problem just 139 described: 141 o reactive: the receiver recognizes that addresses it has received 142 are in the wrong version and converts them through a request to a 143 mapping function or using an in-built algorithm and accompanying 144 configuration; 146 o dynamic modification: the network intercepts the access 147 information and modifies it as necessary to meet the requirements 148 of the receiver; 150 o administrative: the electronic program guide is modified in 151 advance of its acquisition by the receiver to provide alternative 152 address versions. Two variations on this strategy are identified. 154 3.1. The Reactive Strategy 156 According to this strategy, an IPv6 receiver receiving IPv4 157 addresses, for example, would recognize that they were the wrong 158 version. As one possibility, it would package the addresses into one 159 or two requests to a mapping function, which would return 160 corresponding IPv6 addresses. In the 6-4-4 scenario (IPv6 receiver, 161 IPv4 network and source), the mapping function could be located in 162 another node at the user site or located in a dual-stack element at 163 the provider edge. In the 6-6-4 case (IPv6 receiver and network, 164 IPv4 source) it would have to be part of the provider network, 165 although not necessarily at its edge. 167 This approach involves a fair amount of work to implement. Not only 168 does the receiver need to recognize that addresses are the wrong 169 version; it also has to implement a new protocol to the mapping 170 function. It also has to discover that function. 172 As an alternative, the receiver could implement an algorithm to 173 perform the mapping itself, for example, synthesizing an IPv6 address 174 given the IPv4 address of the source using the approach described by 175 [ID.mboned-64-multicast-address-format] for multicast group addresses 176 or [RFC6052] for unicast source addresses. In this case, the 177 receiver must be configured with the IPv6 prefixes allocated for that 178 purpose in the network to which the receiver is attached (e.g., using 179 [ID.qin-softwire-multicast-prefix-option]). When applicable, this 180 approach clearly has advantages over an approach using an external 181 mapping function. It still requires implementation effort in the 182 receiver, but at more limited level. 184 3.2. Dynamic Modification 186 This strategy puts the entire burden of address adaptation on the 187 provider network. It requires that an element in that network must 188 intercept program guide information destined to the receiver, locate 189 the access information, and map IP addresses to an alternate version 190 as necessary to suit the receiver. If the problem identified in the 191 last paragraph of Section 2 is to be avoided, the intercepting 192 element has to be aware of the version supported by each receiver. 194 As noted in the description of the OMA architecture in Appendix A, it 195 is possible that such an adaptive function is present, but not clear 196 that its scope would extend to IP version changes. The need to 197 include IP version along with other receiver-related information 198 might or might not prove to be administratively demanding. With the 199 dynamic modification strategy the workload on the adaptation function 200 might be large enough to make it a bottleneck in the process of 201 program acquisition. The mitigating factor is that program metadata 202 will typically be retrieved rather less often than program content. 204 This strategy has the clear advantage that it requires no changes in 205 the receiver. 207 3.3. Administrative Preparation 209 The basic idea with this strategy is that the access information in 210 the program metadata is set up to provide the right address version 211 in advance of acquisition by any receiver. There are two basic 212 approaches: 214 o separate alternative versions of the access information are 215 prepared. The correct version is served up to the receiver when 216 it requests it. Like the dynamic modification strategy, this 217 approach assumes that it is administratively feasible for the 218 program guide server to know the IP version of the requesting 219 receiver. That may or may not be true in a given operator's 220 context. Also as with the dynamic modification approach, no 221 change is required in the receiver. The big advantage over 222 dynamic modification is that there is no need for the 223 complications of an intercepting adapting element. 225 o The same access information instance contains alternative IP 226 address versions. Where SDP is used, we can think of ICE or ICE- 227 lite [RFC5245] or the proposed 'altc' mechanism 228 [ID.boucadair-altc]. This requires receiver modification to 229 recognize the alternative syntax and (in the case of ICE and 230 potentially in the case of ICE-Lite) to take part in STUN 231 exchanges. However, it means that the same access information can 232 be served up to all receivers in a backward-compatible manner. 234 The administrative strategy requires that the network provider have 235 control over the translations used in the preparation of the 236 alternative versions of the access information. The network has to 237 be aware of the translations used, so it can reuse them at other 238 stages of the multicast acquisition process. Note networks owned by 239 different operators are likely to have different mappings between 240 IPv4 and IPv6 addresses, so if multiple receiving networks are 241 downstream of the same source network, each of them may have to 242 prepare and make available its own IPv6 version of the electronic 243 program guide. 245 4. Conclusions 247 To come. 249 5. Acknowledgements 251 TBD 253 6. IANA Considerations 255 This memo includes no request to IANA. 257 7. Security Considerations 259 To come. 261 8. Informative References 263 [ID.boucadair-altc] 264 Boucadair, M., Kaplan, H., Gilman, R., and S. 265 Veikkolainen, "Session Description Protocol (SDP) 266 Alternate Connectivity (ALTC) Attribute (Work in 267 Progress)", November 2011. 269 [ID.jaclee-behave-v4v6-multicast-ps] 270 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 271 Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use 272 Cases (Work in Progress)", November 2011. 274 [ID.mboned-64-multicast-address-format] 275 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 276 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work 277 in Progress)", February 2012. 279 [ID.qin-softwire-multicast-prefix-option] 280 Qin, J., Boucadair, M., and T. Tsou, "DHCPv6 Options for 281 IPv6 DS-Lite Multicast Prefix (Work in Progress)", 282 October 2011. 284 [MPEG-7_DDL] 285 ISO/IEC, "ISO/IEC 15938-2 (2002): "Information technology 286 - Multimedia content description interface - Part 2: 287 Description definition language".", 2002. 289 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 290 A., Peterson, J., Sparks, R., Handley, M., and E. 291 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 292 June 2002. 294 [RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The 295 TV-Anytime Content Reference Identifier (CRID)", RFC 4078, 296 May 2005. 298 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 299 Description Protocol", RFC 4566, July 2006. 301 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 302 (ICE): A Protocol for Network Address Translator (NAT) 303 Traversal for Offer/Answer Protocols", RFC 5245, 304 April 2010. 306 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 307 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 308 October 2010. 310 Appendix A. Some Background On Program Guides 312 Numerous organizations have been involved in the development of 313 specifications for IPTV. Those specifications and the requirements 314 of individual providers have influenced the development of existing 315 receivers. Any solution to the multicast transition problem 316 described in Section 1 has to take account of the effort involved not 317 only in the direct development of a new generation of receivers, but 318 also in evolving the specifications on which those receivers are 319 based. It is thus worthwhile to review the current situation as it 320 affects multicast transition. 322 The TV-Anytime forum (http://www.tv-anytime.org/) did early work in 323 the area, formally terminating in 2005. Their work focussed on the 324 description of program content, to facilitate the creation of such 325 descriptions and their navigation by the user. The results are 326 documented in the ETSI TS 102 822 series of technical specifications. 328 The content reference identifier (CRID) is a fundamental concept in 329 the TV-Anytime data model. It refers to a specific piece of content 330 or to other CRIDs, the latter thereby providing a method for grouping 331 related pieces of content. TV-Anytime registered the CRID: URL 332 schema in [RFC4078]. Quoting from the abstract of that document: 334 The Uniform Resource Locator (URL) scheme "CRID:" has been devised 335 to allow references to current or future scheduled publications of 336 broadcast media content over television distribution platforms and 337 the Internet. 339 The initial intended application is as an embedded link within 340 scheduled programme description metadata that can be used by the 341 home user or agent to associate a programme selection with the 342 corresponding programme location information for subsequent 343 automatic acquisition. 345 The process of location resolution for the CRID: URL for an 346 individual piece of content locates the content itself so that the 347 user can access it. TV-Anywhere left the details of that process 348 unspecified. 350 The Open IPTV Forum (http://www.oipf.tv) has focussed on defining the 351 user-to-network interface, particularly for fixed broadband access. 352 The architecture is based on the ETSI NGN (Next Generation Networks) 353 model. The receiver obtains the actual access information for a 354 given program, including the multicast group address and possibly a 355 unicast source address, from XML-encoded program information 356 following the Open IPTV Forum schema. The receiver uses SIP (Session 357 Initiation Protocol [RFC3261]) signalling to obtain authorization and 358 resources for a session, before signalling at the multicast level to 359 acquire the program. The SIP signalling conveys the multicast group 360 address and the unicast source address, if available, in the form of 361 an SDP (Session Description Protocol [RFC4566]) session description. 363 Finally, the Open Mobile Alliance (OMA, 364 http://www.openmobilealliance.org/) has defined a series of 365 specifications relating to broadcast services over wireless networks. 366 The source and multicast group addresses used to acquire a given 367 program instance are provided in SDP fragments either directly 368 embedded in the primary electronic program guide or pointed to by it. 369 The OMA architecture provides functionality to adapt access 370 information within the program guide to the requirements of the 371 transport network to which the user is attached, but this 372 functionality appears to be primarily directed toward overcoming 373 differences in technology rather than a general capability for 374 modification. 376 In conclusion, it appears that there are at least two extant sources 377 of specifications for the receiver interface, each providing its own 378 data model, XML data schema, and detailed architecture. In the OMA 379 case, the access information including the source and multicast group 380 addresses is embedded as an SDP fragment within a larger set of XML- 381 encoded program metadata. The OMA metadata can be supplied to the 382 receiver in multiple segments, through multiple channels. This 383 complicates the task of intercepting that metadata and modifying it 384 in a particular transport network. 386 Authors' Addresses 388 Tina Tsou 389 Huawei Technologies (USA) 390 2330 Central Expressway 391 Santa Clara, CA 95050 392 USA 394 Phone: +1 408 330 4424 395 Email: Tina.Tsou.Zouting@huawei.com 396 Axel Clauberg 397 Deutsche Telekom 398 Deutsche Telekom AG, GTN-FM4 399 Landgrabenweg 151 400 Bonn, 53227 401 Germany 403 Phone: +4922893618546 404 Email: axel.clauberg@telekom.de 406 Mohamed Boucadair 407 France Telecom 408 Rennes, 35000 409 France 411 Phone: 412 Email: mohamed.boucadair@orange.com 414 Stig Venaas 415 Cisco Systems 416 Tasman Drive 417 San Jose, CA 95134 418 USA 420 Phone: 421 Email: stig@cisco.com 423 Qiong Sun 424 China Telecom 425 Room 708, No.118, Xizhimennei Street 426 Beijing, 100035 427 P.R.China 429 Phone: +86-10-58552936 430 Email: sunqiong@ctbri.com.cn