--- 1/draft-ietf-mboned-multrans-addr-acquisition-05.txt 2015-09-02 01:14:58.650331943 -0700 +++ 2/draft-ietf-mboned-multrans-addr-acquisition-06.txt 2015-09-02 01:14:58.674332521 -0700 @@ -1,26 +1,26 @@ Internet Engineering Task Force T. Tsou Internet-Draft Huawei Technologies Intended status: Informational A. Clauberg -Expires: September 3, 2015 Deutsche Telekom +Expires: February 1, 2016 Deutsche Telekom M. Boucadair France Telecom S. Venaas Cisco Systems Q. Sun China Telecom - March 4, 2015 + September 2, 2015 Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions - draft-ietf-mboned-multrans-addr-acquisition-05 + draft-ietf-mboned-multrans-addr-acquisition-06 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 @@ -69,65 +69,64 @@ 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . 6 Appendix A. Some Background On Program Guides . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction - Discussion of the multicast transition problem has focussed on the - case of broadcast delivery of program content. Within this scenario, + 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 - transition scenarios, that the program guide contains only IPv4 + 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 transition scenarios, the source supports one IP version + 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 transition scenarios, the source and provider network may + 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 @@ -307,26 +306,26 @@ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. 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 transition problem + 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 transition. + 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