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