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