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