idnits 2.17.1 draft-tsou-mboned-multrans-addr-acquisition-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 12, 2012) is 4422 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: September 13, 2012 Deutsche Telekom 6 M. Boucadair 7 France Telecom 8 S. Venaas 9 Cisco Systems 10 Q. Sun 11 China Telecom 12 March 12, 2012 14 Address Acquisition For Multicast Content When Source and Receiver 15 Support Differing IP Versions 16 draft-tsou-mboned-multrans-addr-acquisition-01 18 Abstract 20 Each IPTV operator has their own arrangements for pre-provisioning 21 program information including addresses of the multicast groups 22 corresponding to broadcast programs on the subscriber receiver. 23 During the transition from IPv4 to IPv6, scenarios can occur where 24 the IP version supported by the receiver differs from that supported 25 by the source. This memo examines and evaluates alternative 26 strategies for allowing the receiver to acquire multicast address 27 information in the version it supports in such scenarios. Operators 28 may find this review useful when planning their own transition 29 strategy. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 13, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Which Problem Are We Solving? . . . . . . . . . . . . . . . . . 3 66 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . . 4 68 3.2. Dynamic Modification . . . . . . . . . . . . . . . . . . . 5 69 3.3. Administrative Preparation . . . . . . . . . . . . . . . . 5 70 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 74 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 75 Appendix A. Some Background On Program Guides . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 Discussion of the multicast transition problem has focussed on the 81 case of broadcast delivery of program content. Within this scenario, 82 the operation of viewing a program follows a well-defined sequence. 83 For the sake of reducing channel switching delay, the list of 84 multicast addresses is generally pre-provisioned to the receiver as 85 part of the program guide. Each operator has their own solution for 86 achieving this delivery, despite the attempts at standardization 87 recounted in Appendix A. 89 At some later time, after the program guide is delivered, the user 90 chooses to view a program, possibly by selecting it from a displayed 91 program listing, or simply by selecting a channel. The receiver uses 92 its pre-acquired information to signal to the network to receive the 93 desired content. In particular, the receiver initiates reception of 94 multicast content using the multicast group address and possibly a 95 unicast source address supplied within the program guide. 97 If the network, the source of the multicast content, and the 98 receivers all use IPv4, it is evident that the program information 99 will only include IPv4 addresses. Suppose now, as can occur in some 100 transition scenarios, that the program guide contains only IPv4 101 addresses and the receiver supports IPv6 only, or vice versa. Then 102 there will be a mismatch: the receivers will be unable to use the 103 addresses that are provided in the program guide. This memo examines 104 the possible strategies for remedying this mismatch, evaluating them 105 in terms of their impact on receiver implementation and network 106 operation. 108 Note that the simplest solution might be to avoid mismatches by 109 making sure that new receivers are dual stack rather than IPv6-only. 111 The remarks in Section 4.1 of [ID.jaclee-behave-v4v6-multicast-ps] 112 are relevant to the problem considered here, but are more restricted 113 in scope. 115 2. Which Problem Are We Solving? 117 In some transition scenarios, the source supports one IP version 118 while the receiver and the provider network support the other (e.g., 119 the source supports IPv4, the receiver and the network to which it is 120 attached support IPv6). In this case, the problem stated above can 121 be expressed as follows: how does the receiver acquire addresses of 122 the IP version it supports, possibly with the help of the provider 123 network? 124 In other transition scenarios, the source and provider network may 125 support one IP version while the receiver supports another. In this 126 case there are actually two problems: how the receiver acquires 127 addresses that it supports (as already stated), and how to make those 128 addresses usable in a network supporting a different version? This 129 second problem is the subject of a different memo and out of scope of 130 the present one. 132 There is also a third class of scenarios, where the source and 133 receiver support the same IP version but the intervening network 134 supports a different one (e.g., the 4-6-4 scenario, Section 3.1 of 135 [ID.jaclee-behave-v4v6-multicast-ps]). In those scenarios, 136 delivering addresses of the right IP version to the receiver within 137 the program guide is notionally a non-problem. The problem still can 138 arise, if the intervening network intercepts and modifies the program 139 guide to be consistent with the IP version it supports. In this 140 case, the problem can be re-stated as: how can such modification be 141 avoided when it is not needed? 143 3. Possible Solutions 145 This section explores three classes of solutions to the problem just 146 described: 148 o reactive: the receiver recognizes that addresses it has received 149 are in the wrong version and converts them through a request to a 150 mapping function or using an in-built algorithm and accompanying 151 configuration; 153 o dynamic modification: the network intercepts the access 154 information and modifies it as necessary to meet the requirements 155 of the receiver; 157 o administrative: the electronic program guide is modified in 158 advance of its acquisition by the receiver to provide alternative 159 address versions. Two variations on this strategy are identified. 161 3.1. The Reactive Strategy 163 According to this strategy, a receiver recognizes that it has 164 received multicast group addresses, even when they are the wrong 165 version. As one possibility, it invokes an external mapping function 166 to convert them to the version it supports. The mapping function 167 could be located in another node at the user site or at a node in the 168 provider network. 170 This approach involves a fair amount of work to implement. Not only 171 does the receiver need to recognize that addresses are the wrong 172 version; it also has to implement a new protocol to the mapping 173 function. It also has to discover that function. 175 As an alternative, the receiver can implement an algorithm to perform 176 the mapping itself, for example, synthesizing an IPv6 address given 177 the IPv4 address of the source using the approach described by 178 [ID.mboned-64-multicast-address-format] for multicast group addresses 179 or [RFC6052] for unicast source addresses. In this case, the 180 receiver must be configured with the IPv6 prefixes allocated for that 181 purpose in the network to which the receiver is attached (e.g., using 182 [ID.qin-softwire-multicast-prefix-option]). When applicable, this 183 approach clearly has advantages over an approach using an external 184 mapping function. It still requires implementation effort in the 185 receiver, but at a more limited level. 187 3.2. Dynamic Modification 189 This strategy puts the entire burden of address adaptation on the 190 provider network. It requires that an element in that network must 191 intercept program guide information destined to the receiver, locate 192 the access information, and map IP addresses to an alternate version 193 as necessary to suit the receiver. If the problem identified in the 194 last paragraph of Section 2 is to be avoided, the intercepting 195 element has to be aware of the version supported by each receiver. 197 As noted in the description of the OMA architecture in Appendix A, it 198 is possible that such an adaptive function is present, but not clear 199 that its scope would extend to IP version changes. The need to 200 include IP version along with other receiver-related information 201 might or might not prove to be administratively demanding. With the 202 dynamic modification strategy the workload on the adaptation function 203 might be large enough to make it a bottleneck in the process of 204 program acquisition. The mitigating factor is that program metadata 205 will typically be retrieved rather less often than program content. 207 This strategy has the clear advantage that it requires no changes in 208 the receiver. 210 3.3. Administrative Preparation 212 The basic idea with this strategy is that the access information in 213 the program metadata is set up to provide the right address version 214 in advance of acquisition by any receiver. There are two basic 215 approaches: 217 o separate alternative versions of the access information are 218 prepared. The correct version is served up to the receiver when 219 it requests it. Like the dynamic modification strategy, this 220 approach assumes that it is administratively feasible for the 221 program guide server to know the IP version of the requesting 222 receiver. That may or may not be true in a given operator's 223 context. Also as with the dynamic modification approach, no 224 change is required in the receiver. The big advantage over 225 dynamic modification is that there is no need for the 226 complications of an intercepting adapting element. 228 o The same access information instance contains alternative IP 229 address versions. Where SDP is used, we can think of ICE or ICE- 230 lite [RFC5245] or the proposed 'altc' mechanism 231 [ID.boucadair-altc]. This requires receiver modification to 232 recognize the alternative syntax and (in the case of ICE and 233 potentially in the case of ICE-Lite) to take part in STUN 234 exchanges. However, it means that the same access information can 235 be served up to all receivers in a backward-compatible manner. 237 The administrative strategy requires that the network provider have 238 control over the translations used in the preparation of the 239 alternative versions of the access information. The network has to 240 be aware of the translations used, so it can reuse them at other 241 stages of the multicast acquisition process. Note networks owned by 242 different operators are likely to have different mappings between 243 IPv4 and IPv6 addresses, so if multiple receiving networks are 244 downstream of the same source network, each of them may have to 245 prepare and make available its own IPv6 version of the electronic 246 program guide. 248 4. Conclusions 250 To come. 252 5. Acknowledgements 254 TBD 256 6. IANA Considerations 258 This memo includes no request to IANA. 260 7. Security Considerations 262 To come. 264 8. Informative References 266 [ID.boucadair-altc] 267 Boucadair, M., Kaplan, H., Gilman, R., and S. 268 Veikkolainen, "Session Description Protocol (SDP) 269 Alternate Connectivity (ALTC) Attribute (Work in 270 Progress)", November 2011. 272 [ID.jaclee-behave-v4v6-multicast-ps] 273 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 274 Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use 275 Cases (Work in Progress)", November 2011. 277 [ID.mboned-64-multicast-address-format] 278 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 279 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work 280 in Progress)", February 2012. 282 [ID.qin-softwire-multicast-prefix-option] 283 Qin, J., Boucadair, M., and T. Tsou, "DHCPv6 Options for 284 IPv6 DS-Lite Multicast Prefix (Work in Progress)", 285 October 2011. 287 [MPEG-7_DDL] 288 ISO/IEC, "ISO/IEC 15938-2 (2002): "Information technology 289 - Multimedia content description interface - Part 2: 290 Description definition language".", 2002. 292 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 293 A., Peterson, J., Sparks, R., Handley, M., and E. 294 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 295 June 2002. 297 [RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The 298 TV-Anytime Content Reference Identifier (CRID)", RFC 4078, 299 May 2005. 301 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 302 Description Protocol", RFC 4566, July 2006. 304 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 305 (ICE): A Protocol for Network Address Translator (NAT) 306 Traversal for Offer/Answer Protocols", RFC 5245, 307 April 2010. 309 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 310 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 311 October 2010. 313 Appendix A. Some Background On Program Guides 315 Numerous organizations have been involved in the development of 316 specifications for IPTV. Those specifications and the requirements 317 of individual providers have influenced the development of existing 318 receivers. Any solution to the multicast transition problem 319 described in Section 1 has to take account of the effort involved not 320 only in the direct development of a new generation of receivers, but 321 also in evolving the specifications on which those receivers are 322 based. It is thus worthwhile to review the current situation as it 323 affects multicast transition. 325 The TV-Anytime forum (http://www.tv-anytime.org/) did early work in 326 the area, formally terminating in 2005. Their work focussed on the 327 description of program content, to facilitate the creation of such 328 descriptions and their navigation by the user. The results are 329 documented in the ETSI TS 102 822 series of technical specifications. 331 The content reference identifier (CRID) is a fundamental concept in 332 the TV-Anytime data model. It refers to a specific piece of content 333 or to other CRIDs, the latter thereby providing a method for grouping 334 related pieces of content. TV-Anytime registered the CRID: URL 335 schema in [RFC4078]. Quoting from the abstract of that document: 337 The Uniform Resource Locator (URL) scheme "CRID:" has been devised 338 to allow references to current or future scheduled publications of 339 broadcast media content over television distribution platforms and 340 the Internet. 342 The initial intended application is as an embedded link within 343 scheduled programme description metadata that can be used by the 344 home user or agent to associate a programme selection with the 345 corresponding programme location information for subsequent 346 automatic acquisition. 348 The process of location resolution for the CRID: URL for an 349 individual piece of content locates the content itself so that the 350 user can access it. TV-Anywhere left the details of that process 351 unspecified. 353 The Open IPTV Forum (http://www.oipf.tv) has focussed on defining the 354 user-to-network interface, particularly for fixed broadband access. 355 The architecture is based on the ETSI NGN (Next Generation Networks) 356 model. The receiver obtains the actual access information for a 357 given program, including the multicast group address and possibly a 358 unicast source address, from XML-encoded program information 359 following the Open IPTV Forum schema. The receiver uses SIP (Session 360 Initiation Protocol [RFC3261]) signalling to obtain authorization and 361 resources for a session, before signalling at the multicast level to 362 acquire the program. The SIP signalling conveys the multicast group 363 address and the unicast source address, if available, in the form of 364 an SDP (Session Description Protocol [RFC4566]) session description. 366 Finally, the Open Mobile Alliance (OMA, 367 http://www.openmobilealliance.org/) has defined a series of 368 specifications relating to broadcast services over wireless networks. 369 The source and multicast group addresses used to acquire a given 370 program instance are provided in SDP fragments either directly 371 embedded in the primary electronic program guide or pointed to by it. 372 The OMA architecture provides functionality to adapt access 373 information within the program guide to the requirements of the 374 transport network to which the user is attached, but this 375 functionality appears to be primarily directed toward overcoming 376 differences in technology rather than a general capability for 377 modification. 379 In conclusion, it appears that there are at least two extant sources 380 of specifications for the receiver interface, each providing its own 381 data model, XML data schema, and detailed architecture. In the OMA 382 case, the access information including the source and multicast group 383 addresses is embedded as an SDP fragment within a larger set of XML- 384 encoded program metadata. The OMA metadata can be supplied to the 385 receiver in multiple segments, through multiple channels. This 386 complicates the task of intercepting that metadata and modifying it 387 in a particular transport network. 389 Authors' Addresses 391 Tina Tsou 392 Huawei Technologies (USA) 393 2330 Central Expressway 394 Santa Clara, CA 95050 395 USA 397 Phone: +1 408 330 4424 398 Email: Tina.Tsou.Zouting@huawei.com 399 Axel Clauberg 400 Deutsche Telekom 401 Deutsche Telekom AG, GTN-FM4 402 Landgrabenweg 151 403 Bonn, 53227 404 Germany 406 Phone: +4922893618546 407 Email: axel.clauberg@telekom.de 409 Mohamed Boucadair 410 France Telecom 411 Rennes, 35000 412 France 414 Phone: 415 Email: mohamed.boucadair@orange.com 417 Stig Venaas 418 Cisco Systems 419 Tasman Drive 420 San Jose, CA 95134 421 USA 423 Phone: 424 Email: stig@cisco.com 426 Qiong Sun 427 China Telecom 428 Room 708, No.118, Xizhimennei Street 429 Beijing, 100035 430 P.R.China 432 Phone: +86-10-58552936 433 Email: sunqiong@ctbri.com.cn