--- 1/draft-ietf-mboned-multrans-addr-acquisition-06.txt 2015-12-09 15:15:03.180716607 -0800 +++ 2/draft-ietf-mboned-multrans-addr-acquisition-07.txt 2015-12-09 15:15:03.208717289 -0800 @@ -1,26 +1,26 @@ Internet Engineering Task Force T. Tsou Internet-Draft Huawei Technologies Intended status: Informational A. Clauberg -Expires: February 1, 2016 Deutsche Telekom +Expires: June 2, 2016 Deutsche Telekom M. Boucadair France Telecom S. Venaas Cisco Systems Q. Sun China Telecom - September 2, 2015 + November 30, 2015 Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions - draft-ietf-mboned-multrans-addr-acquisition-06 + draft-ietf-mboned-multrans-addr-acquisition-07 Abstract Each IPTV operator has their own arrangements for pre-provisioning program information including addresses of the multicast groups corresponding to broadcast programs on the subscriber receiver. During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines what has to be done to allow the receiver to acquire multicast address information in the version it @@ -34,25 +34,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 3, 2015. + This Internet-Draft will expire on June 2, 2016. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -60,79 +60,77 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Which Problem Are We Solving? . . . . . . . . . . . . . . . . 3 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . 4 3.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . 4 3.2. Dynamic Modification . . . . . . . . . . . . . . . . . . 5 3.3. Administrative Preparation . . . . . . . . . . . . . . . 5 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 8. Informative References . . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 7. Informative References . . . . . . . . . . . . . . . . . . . 6 Appendix A. Some Background On Program Guides . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction - In the case of broadcast delivery of program content, - the operation of viewing a program follows a well-defined sequence. - For the sake of reducing channel switching delay, the list of - multicast addresses is generally pre-provisioned to the receiver as - part of the program guide. Each operator has their own solution for - achieving this delivery, despite the attempts at standardization - recounted in Appendix A. + In the case of broadcast delivery of program content, the operation + of viewing a program follows a well-defined sequence. For the sake + of reducing channel switching delay, the list of multicast addresses + is generally pre-provisioned to the receiver as part of the program + guide. Each operator has their own solution for achieving this + delivery, despite the attempts at standardization recounted in + Appendix A. At some later time, after the program guide is delivered, the user chooses to view a program, possibly by selecting it from a displayed program listing, or simply by selecting a channel. The receiver uses its pre-acquired information to signal to the network to receive the desired content. In particular, the receiver initiates reception of multicast content using the multicast group address and possibly a unicast source address supplied within the program guide. If the network, the source of the multicast content, and the receivers all use IPv4, it is evident that the program information will only include IPv4 addresses. Suppose now, as can occur in some - scenarios, that the program guide contains only IPv4 - addresses and the receiver supports IPv6 only, or vice versa. Then - there will be a mismatch: the receivers will be unable to use the - addresses that are provided in the program guide. This memo examines - the possible strategies for remedying this mismatch, evaluating them - in terms of their impact on receiver implementation and network - operation. + scenarios, that the program guide contains only IPv4 addresses and + the receiver supports IPv6 only, or vice versa. Then there will be a + mismatch: the receivers will be unable to use the addresses that are + provided in the program guide. This memo examines the possible + strategies for remedying this mismatch, evaluating them in terms of + their impact on receiver implementation and network operation. Note that the simplest solution might be to avoid mismatches by making sure that new receivers are dual stack rather than IPv6- only. The remarks in Section 4.1 of [ID.mboned-v4v6-mcast-ps] are relevant to the problem considered here, but are more restricted in scope. 2. Which Problem Are We Solving? - In some scenarios, the source supports one IP version - while the receiver and the provider network support the other (e.g., - the source supports IPv4, the receiver and the network to which it is - attached support IPv6). In this case, the problem stated above can - be expressed as follows: how does the receiver acquire addresses of - the IP version it supports, possibly with the help of the provider + In some scenarios, the source supports one IP version while the + receiver and the provider network support the other (e.g., the source + supports IPv4, the receiver and the network to which it is attached + support IPv6). In this case, the problem stated above can be + expressed as follows: how does the receiver acquire addresses of the + IP version it supports, possibly with the help of the provider network? - In other scenarios, the source and provider network may - support one IP version while the receiver supports another. In this - case there are actually two problems: how the receiver acquires - addresses that it supports (as already stated), and how to make those - addresses usable in a network supporting a different version? This - second problem is the subject of a different memo and out of scope of - the present one. + In other scenarios, the source and provider network may support one + IP version while the receiver supports another. In this case there + are actually two problems: how the receiver acquires addresses that + it supports (as already stated), and how to make those addresses + usable in a network supporting a different version? This second + problem is the subject of a different memo and out of scope of the + present one. There is also a third class of scenarios, where the source and receiver support the same IP version but the intervening network supports a different one (e.g., the 4-6-4 scenario, Section 3.1 of [ID.mboned-v4v6-mcast-ps]). In those scenarios, delivering addresses of the right IP version to the receiver within the program guide is notionally a non-problem. The problem still can arise, if the intervening network intercepts and modifies the program guide to be consistent with the IP version it supports. In this case, the problem can be re-stated as: how can such modification be avoided @@ -218,61 +216,55 @@ approach assumes that it is administratively feasible for the program guide server to know the IP version of the requesting receiver. That may or may not be true in a given operator's context. Also as with the dynamic modification approach, no change is required in the receiver. The big advantage over dynamic modification is that there is no need for the complications of an intercepting adapting element. o The same access information instance contains alternative IP address versions. Where SDP is used, we can think of ICE or ICE- - lite [RFC5245] or the proposed 'altc' mechanism - [ID.boucadair-altc]. This requires receiver modification to - recognize the alternative syntax and (in the case of ICE and - potentially in the case of ICE-Lite) to take part in STUN - exchanges. However, it means that the same access information can - be served up to all receivers in a backward-compatible manner. + lite [RFC5245] or the proposed 'altc' mechanism [RFC6947]. This + requires receiver modification to recognize the alternative syntax + and (in the case of ICE and potentially in the case of ICE-Lite) + to take part in STUN exchanges. However, it means that the same + access information can be served up to all receivers in a + backward-compatible manner. The administrative strategy requires that the network provider have control over the translations used in the preparation of the alternative versions of the access information. The network has to be aware of the translations used, so it can reuse them at other stages of the multicast acquisition process. Note networks owned by different operators are likely to have different mappings between IPv4 and IPv6 addresses, so if multiple receiving networks are downstream of the same source network, each of them may have to prepare and make available its own IPv6 version of the electronic program guide. 4. Conclusions - To come. - -5. Acknowledgements - - TBD + From the perspective of the receiver, the first and the third + solutions clearly require modifications and implementation effort, + while the second solution requires no. From the perspective of the + provider network, the dynamic modification requires the network to + intercept the program guide information destined to the receiver and + the administrative strategy requires the network to have control and + access over the translations used. -6. IANA Considerations +5. IANA Considerations This memo includes no request to IANA. -7. Security Considerations - - To come. - -8. Informative References +6. Security Considerations - [ID.boucadair-altc] - Boucadair, M., Kaplan, H., Gilman, R., and S. - Veikkolainen, "Session Description Protocol (SDP) - Alternate Connectivity (ALTC) Attribute (Work in - Progress)", April 2012. +7. Informative References [ID.mboned-64-multicast-address-format] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work in Progress)", May 2012. [ID.mboned-v4v6-mcast-ps] Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and Use Cases (Work in Progress)", May 2012. @@ -283,49 +275,60 @@ Progress)", March 2012. [MPEG-7_DDL] "Information technology - Multimedia content description interface - Part 2: Description definition language", ISI/ IEC 15938-2 (2002), 2002. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, - June 2002. + DOI 10.17487/RFC3261, June 2002, + . [RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The TV-Anytime Content Reference Identifier (CRID)", RFC 4078, - May 2005. + DOI 10.17487/RFC4078, May 2005, + . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session - Description Protocol", RFC 4566, July 2006. + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", RFC 5245, April - 2010. + Traversal for Offer/Answer Protocols", RFC 5245, + DOI 10.17487/RFC5245, April 2010, + . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, - October 2010. + DOI 10.17487/RFC6052, October 2010, + . + + [RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. + Veikkolainen, "The Session Description Protocol (SDP) + Alternate Connectivity (ALTC) Attribute", RFC 6947, + DOI 10.17487/RFC6947, May 2013, + . Appendix A. Some Background On Program Guides Numerous organizations have been involved in the development of specifications for IPTV. Those specifications and the requirements of individual providers have influenced the development of existing - receivers. Any solution to the multicast problem - described in Section 1 has to take account of the effort involved not - only in the direct development of a new generation of receivers, but - also in evolving the specifications on which those receivers are - based. It is thus worthwhile to review the current situation as it - affects multicast procedures. + receivers. Any solution to the multicast problem described in + Section 1 has to take account of the effort involved not only in the + direct development of a new generation of receivers, but also in + evolving the specifications on which those receivers are based. It + is thus worthwhile to review the current situation as it affects + multicast procedures. The TV-Anytime forum (http://www.tv-anytime.org/) did early work in the area, formally terminating in 2005. Their work focussed on the description of program content, to facilitate the creation of such descriptions and their navigation by the user. The results are documented in the ETSI TS 102 822 series of technical specifications. The content reference identifier (CRID) is a fundamental concept in the TV-Anytime data model. It refers to a specific piece of content or to other CRIDs, the latter thereby providing a method for grouping