Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Intended status: Informational A. Clauberg
Expires: July 07, 2013 Deutsche Telekom
M. Boucadair
France Telecom
S. Venaas
Cisco Systems
Q. Sun
China Telecom
January 03, 2013

Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions


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 supports in such scenarios.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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:/⁠/⁠⁠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 July 07, 2013.

Copyright Notice

Copyright (c) 2013 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:/⁠/⁠⁠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 described in the Simplified BSD License.

Table of Contents

1. Introduction

Discussion of the multicast transition problem has focussed on the case of broadcast delivery of program content. Within this scenario, 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 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 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 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 when it is not needed?

3. Possible Solutions

This section explores three classes of solutions to the problem just described:

3.1. The Reactive Strategy

According to this strategy, a receiver recognizes that it has received multicast group addresses, even when they are the wrong version. As one possibility, it invokes an external mapping function to convert them to the version it supports. The mapping function could be located in another node at the user site or at a node in the provider network.

This approach involves a fair amount of work to implement. Not only does the receiver need to recognize that addresses are the wrong version; it also has to implement a new protocol to the mapping function. It also has to discover that function.

As an alternative, the receiver can implement an algorithm to perform the mapping itself, for example, synthesizing an IPv6 address given the IPv4 address of the source using the approach described by [ID.mboned-64-multicast-address-format] for multicast group addresses or [RFC6052] for unicast source addresses. In this case, the receiver must be configured with the IPv6 prefixes allocated for that purpose in the network to which the receiver is attached (e.g., using [ID.softwire-multicast-prefix-option]). When applicable, this approach clearly has advantages over an approach using an external mapping function. It still requires implementation effort in the receiver, but at a more limited level.

3.2. Dynamic Modification

This strategy puts the entire burden of address adaptation on the provider network. It requires that an element in that network must intercept program guide information destined to the receiver, locate the access information, and map IP addresses to an alternate version as necessary to suit the receiver. If the problem identified in the last paragraph of Section 2 is to be avoided, the intercepting element has to be aware of the version supported by each receiver.

As noted in the description of the OMA architecture in Appendix A, it is possible that such an adaptive function is present, but not clear that its scope would extend to IP version changes. The need to include IP version along with other receiver- related information might or might not prove to be administratively demanding. With the dynamic modification strategy the workload on the adaptation function might be large enough to make it a bottleneck in the process of program acquisition. The mitigating factor is that program metadata will typically be retrieved rather less often than program content.

This strategy has the clear advantage that it requires no changes in the receiver.

3.3. Administrative Preparation

The basic idea with this strategy is that the access information in the program metadata is set up to provide the right address version in advance of acquisition by any receiver. There are two basic approaches:

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


6. IANA Considerations

This memo includes no request to IANA.

7. Security Considerations

To come.

8. Informative References

[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.
[RFC4078] Earnshaw, N., Aoki, S., Ashley, A. and W. Kameyama, "The TV-Anytime Content Reference Identifier (CRID)", RFC 4078, May 2005.
[RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, 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.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M. and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[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.
[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.
[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.softwire-multicast-prefix-option] Qin, J., Boucadair, M., Tsou, T and X. Deng, "DHCPv6 Options for IPv6 DS-Lite Multicast Prefix (Work in Progress)", March 2012.
[MPEG-7_DDL] , , "Information technology - Multimedia content description interface - Part 2: Description definition language", ISI/IEC 15938-2 (2002), 2002.

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 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.

The TV-Anytime forum ( 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 related pieces of content. TV-Anytime registered the CRID: URL schema in [RFC4078]. Quoting from the abstract of that document:

The process of location resolution for the CRID: URL for an individual piece of content locates the content itself so that the user can access it. TV-Anywhere left the details of that process unspecified.

The Open IPTV Forum ( has focussed on defining the user-to-network interface, particularly for fixed broadband access. The architecture is based on the ETSI NGN (Next Generation Networks) model. The receiver obtains the actual access information for a given program, including the multicast group address and possibly a unicast source address, from XML-encoded program information following the Open IPTV Forum schema. The receiver uses SIP (Session Initiation Protocol [RFC3261]) signalling to obtain authorization and resources for a session, before signalling at the multicast level to acquire the program. The SIP signalling conveys the multicast group address and the unicast source address, if available, in the form of an SDP (Session Description Protocol [RFC4566]) session description.

Finally, the Open Mobile Alliance (OMA, has defined a series of specifications relating to broadcast services over wireless networks. The source and multicast group addresses used to acquire a given program instance are provided in SDP fragments either directly embedded in the primary electronic program guide or pointed to by it. The OMA architecture provides functionality to adapt access information within the program guide to the requirements of the transport network to which the user is attached, but this functionality appears to be primarily directed toward overcoming differences in technology rather than a general capability for modification.

In conclusion, it appears that there are at least two extant sources of specifications for the receiver interface, each providing its own data model, XML data schema, and detailed architecture. In the OMA case, the access information including the source and multicast group addresses is embedded as an SDP fragment within a larger set of XML-encoded program metadata. The OMA metadata can be supplied to the receiver in multiple segments, through multiple channels. This complicates the task of intercepting that metadata and modifying it in a particular transport network.

Authors' Addresses

Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 EMail:
Axel Clauberg Deutsche Telekom Deutsche Telekom AG, GTN-FM4 Landgrabenweg 151 Bonn, 53227 Germany Phone: +4922893618546 EMail:
Mohamed Boucadair France Telecom Rennes, 35000 France EMail:
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail:
Qiong Sun China Telecom Room 708 No.118, Xizhimennei Street Beijing, 100035 P.R.China Phone: +86-10-58552936 EMail: