draft-ietf-mboned-multrans-addr-acquisition-05.txt   draft-ietf-mboned-multrans-addr-acquisition-06.txt 
Internet Engineering Task Force T. Tsou Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational A. Clauberg Intended status: Informational A. Clauberg
Expires: September 3, 2015 Deutsche Telekom Expires: February 1, 2016 Deutsche Telekom
M. Boucadair M. Boucadair
France Telecom France Telecom
S. Venaas S. Venaas
Cisco Systems Cisco Systems
Q. Sun Q. Sun
China Telecom China Telecom
March 4, 2015 September 2, 2015
Address Acquisition For Multicast Content When Source and Receiver Address Acquisition For Multicast Content When Source and Receiver
Support Differing IP Versions Support Differing IP Versions
draft-ietf-mboned-multrans-addr-acquisition-05 draft-ietf-mboned-multrans-addr-acquisition-06
Abstract Abstract
Each IPTV operator has their own arrangements for pre-provisioning Each IPTV operator has their own arrangements for pre-provisioning
program information including addresses of the multicast groups program information including addresses of the multicast groups
corresponding to broadcast programs on the subscriber receiver. corresponding to broadcast programs on the subscriber receiver.
During the transition from IPv4 to IPv6, scenarios can occur where During the transition from IPv4 to IPv6, scenarios can occur where
the IP version supported by the receiver differs from that supported 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 by the source. This memo examines what has to be done to allow the
receiver to acquire multicast address information in the version it receiver to acquire multicast address information in the version it
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . 6
Appendix A. Some Background On Program Guides . . . . . . . . . 7 Appendix A. Some Background On Program Guides . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Discussion of the multicast transition problem has focussed on the In the case of broadcast delivery of program content,
case of broadcast delivery of program content. Within this scenario,
the operation of viewing a program follows a well-defined sequence. the operation of viewing a program follows a well-defined sequence.
For the sake of reducing channel switching delay, the list of For the sake of reducing channel switching delay, the list of
multicast addresses is generally pre-provisioned to the receiver as multicast addresses is generally pre-provisioned to the receiver as
part of the program guide. Each operator has their own solution for part of the program guide. Each operator has their own solution for
achieving this delivery, despite the attempts at standardization achieving this delivery, despite the attempts at standardization
recounted in Appendix A. recounted in Appendix A.
At some later time, after the program guide is delivered, the user At some later time, after the program guide is delivered, the user
chooses to view a program, possibly by selecting it from a displayed chooses to view a program, possibly by selecting it from a displayed
program listing, or simply by selecting a channel. The receiver uses program listing, or simply by selecting a channel. The receiver uses
its pre-acquired information to signal to the network to receive the its pre-acquired information to signal to the network to receive the
desired content. In particular, the receiver initiates reception of desired content. In particular, the receiver initiates reception of
multicast content using the multicast group address and possibly a multicast content using the multicast group address and possibly a
unicast source address supplied within the program guide. unicast source address supplied within the program guide.
If the network, the source of the multicast content, and the If the network, the source of the multicast content, and the
receivers all use IPv4, it is evident that the program information receivers all use IPv4, it is evident that the program information
will only include IPv4 addresses. Suppose now, as can occur in some 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 addresses and the receiver supports IPv6 only, or vice versa. Then
there will be a mismatch: the receivers will be unable to use the there will be a mismatch: the receivers will be unable to use the
addresses that are provided in the program guide. This memo examines addresses that are provided in the program guide. This memo examines
the possible strategies for remedying this mismatch, evaluating them the possible strategies for remedying this mismatch, evaluating them
in terms of their impact on receiver implementation and network in terms of their impact on receiver implementation and network
operation. operation.
Note that the simplest solution might be to avoid mismatches by Note that the simplest solution might be to avoid mismatches by
making sure that new receivers are dual stack rather than IPv6- only. 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 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. to the problem considered here, but are more restricted in scope.
2. Which Problem Are We Solving? 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., 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 the source supports IPv4, the receiver and the network to which it is
attached support IPv6). In this case, the problem stated above can attached support IPv6). In this case, the problem stated above can
be expressed as follows: how does the receiver acquire addresses of be expressed as follows: how does the receiver acquire addresses of
the IP version it supports, possibly with the help of the provider the IP version it supports, possibly with the help of the provider
network? 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 support one IP version while the receiver supports another. In this
case there are actually two problems: how the receiver acquires case there are actually two problems: how the receiver acquires
addresses that it supports (as already stated), and how to make those addresses that it supports (as already stated), and how to make those
addresses usable in a network supporting a different version? This addresses usable in a network supporting a different version? This
second problem is the subject of a different memo and out of scope of second problem is the subject of a different memo and out of scope of
the present one. the present one.
There is also a third class of scenarios, where the source and There is also a third class of scenarios, where the source and
receiver support the same IP version but the intervening network 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 supports a different one (e.g., the 4-6-4 scenario, Section 3.1 of
skipping to change at page 7, line 41 skipping to change at page 7, line 41
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
Appendix A. Some Background On Program Guides Appendix A. Some Background On Program Guides
Numerous organizations have been involved in the development of Numerous organizations have been involved in the development of
specifications for IPTV. Those specifications and the requirements specifications for IPTV. Those specifications and the requirements
of individual providers have influenced the development of existing 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 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 only in the direct development of a new generation of receivers, but
also in evolving the specifications on which those receivers are also in evolving the specifications on which those receivers are
based. It is thus worthwhile to review the current situation as it 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 TV-Anytime forum (http://www.tv-anytime.org/) did early work in
the area, formally terminating in 2005. Their work focussed on the the area, formally terminating in 2005. Their work focussed on the
description of program content, to facilitate the creation of such description of program content, to facilitate the creation of such
descriptions and their navigation by the user. The results are descriptions and their navigation by the user. The results are
documented in the ETSI TS 102 822 series of technical specifications. documented in the ETSI TS 102 822 series of technical specifications.
The content reference identifier (CRID) is a fundamental concept in The content reference identifier (CRID) is a fundamental concept in
the TV-Anytime data model. It refers to a specific piece of content 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 or to other CRIDs, the latter thereby providing a method for grouping
 End of changes. 9 change blocks. 
10 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/