draft-ietf-mboned-multrans-addr-acquisition-06.txt   draft-ietf-mboned-multrans-addr-acquisition-07.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: February 1, 2016 Deutsche Telekom Expires: June 2, 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
September 2, 2015 November 30, 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-06 draft-ietf-mboned-multrans-addr-acquisition-07
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 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Which Problem Are We Solving? . . . . . . . . . . . . . . . . 3 2. Which Problem Are We Solving? . . . . . . . . . . . . . . . . 3
3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . 4 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . 4
3.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . 4 3.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . 4
3.2. Dynamic Modification . . . . . . . . . . . . . . . . . . 5 3.2. Dynamic Modification . . . . . . . . . . . . . . . . . . 5
3.3. Administrative Preparation . . . . . . . . . . . . . . . 5 3.3. Administrative Preparation . . . . . . . . . . . . . . . 5
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. 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
In the case of broadcast delivery of program content, In the case of broadcast delivery of program content, the operation
the operation of viewing a program follows a well-defined sequence. of viewing a program follows a well-defined sequence. For the sake
For the sake of reducing channel switching delay, the list of of reducing channel switching delay, the list of multicast addresses
multicast addresses is generally pre-provisioned to the receiver as is generally pre-provisioned to the receiver as part of the program
part of the program guide. Each operator has their own solution for guide. Each operator has their own solution for achieving this
achieving this delivery, despite the attempts at standardization delivery, despite the attempts at standardization recounted in
recounted in Appendix A. 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
scenarios, that the program guide contains only IPv4 scenarios, that the program guide contains only IPv4 addresses and
addresses and the receiver supports IPv6 only, or vice versa. Then the receiver supports IPv6 only, or vice versa. Then there will be a
there will be a mismatch: the receivers will be unable to use the mismatch: the receivers will be unable to use the addresses that are
addresses that are provided in the program guide. This memo examines provided in the program guide. This memo examines the possible
the possible strategies for remedying this mismatch, evaluating them strategies for remedying this mismatch, evaluating them in terms of
in terms of their impact on receiver implementation and network 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 scenarios, the source supports one IP version In some scenarios, the source supports one IP version while the
while the receiver and the provider network support the other (e.g., receiver and the provider network support the other (e.g., the source
the source supports IPv4, the receiver and the network to which it is supports IPv4, the receiver and the network to which it is attached
attached support IPv6). In this case, the problem stated above can support IPv6). In this case, the problem stated above can be
be expressed as follows: how does the receiver acquire addresses of expressed as follows: how does the receiver acquire addresses of the
the IP version it supports, possibly with the help of the provider IP version it supports, possibly with the help of the provider
network? network?
In other scenarios, the source and provider network may In other scenarios, the source and provider network may support one
support one IP version while the receiver supports another. In this IP version while the receiver supports another. In this case there
case there are actually two problems: how the receiver acquires are actually two problems: how the receiver acquires addresses that
addresses that it supports (as already stated), and how to make those it supports (as already stated), and how to make those addresses
addresses usable in a network supporting a different version? This usable in a network supporting a different version? This second
second problem is the subject of a different memo and out of scope of problem is the subject of a different memo and out of scope of the
the present one. 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
[ID.mboned-v4v6-mcast-ps]). In those scenarios, delivering addresses [ID.mboned-v4v6-mcast-ps]). In those scenarios, delivering addresses
of the right IP version to the receiver within the program guide is of the right IP version to the receiver within the program guide is
notionally a non-problem. The problem still can arise, if the notionally a non-problem. The problem still can arise, if the
intervening network intercepts and modifies the program guide to be intervening network intercepts and modifies the program guide to be
consistent with the IP version it supports. In this case, the consistent with the IP version it supports. In this case, the
problem can be re-stated as: how can such modification be avoided problem can be re-stated as: how can such modification be avoided
skipping to change at page 5, line 48 skipping to change at page 5, line 48
approach assumes that it is administratively feasible for the approach assumes that it is administratively feasible for the
program guide server to know the IP version of the requesting program guide server to know the IP version of the requesting
receiver. That may or may not be true in a given operator's receiver. That may or may not be true in a given operator's
context. Also as with the dynamic modification approach, no context. Also as with the dynamic modification approach, no
change is required in the receiver. The big advantage over change is required in the receiver. The big advantage over
dynamic modification is that there is no need for the dynamic modification is that there is no need for the
complications of an intercepting adapting element. complications of an intercepting adapting element.
o The same access information instance contains alternative IP o The same access information instance contains alternative IP
address versions. Where SDP is used, we can think of ICE or ICE- address versions. Where SDP is used, we can think of ICE or ICE-
lite [RFC5245] or the proposed 'altc' mechanism lite [RFC5245] or the proposed 'altc' mechanism [RFC6947]. This
[ID.boucadair-altc]. This requires receiver modification to requires receiver modification to recognize the alternative syntax
recognize the alternative syntax and (in the case of ICE and and (in the case of ICE and potentially in the case of ICE-Lite)
potentially in the case of ICE-Lite) to take part in STUN to take part in STUN exchanges. However, it means that the same
exchanges. However, it means that the same access information can access information can be served up to all receivers in a
be served up to all receivers in a backward-compatible manner. backward-compatible manner.
The administrative strategy requires that the network provider have The administrative strategy requires that the network provider have
control over the translations used in the preparation of the control over the translations used in the preparation of the
alternative versions of the access information. The network has to alternative versions of the access information. The network has to
be aware of the translations used, so it can reuse them at other be aware of the translations used, so it can reuse them at other
stages of the multicast acquisition process. Note networks owned by stages of the multicast acquisition process. Note networks owned by
different operators are likely to have different mappings between different operators are likely to have different mappings between
IPv4 and IPv6 addresses, so if multiple receiving networks are IPv4 and IPv6 addresses, so if multiple receiving networks are
downstream of the same source network, each of them may have to downstream of the same source network, each of them may have to
prepare and make available its own IPv6 version of the electronic prepare and make available its own IPv6 version of the electronic
program guide. program guide.
4. Conclusions 4. Conclusions
To come. From the perspective of the receiver, the first and the third
solutions clearly require modifications and implementation effort,
5. Acknowledgements while the second solution requires no. From the perspective of the
provider network, the dynamic modification requires the network to
TBD 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. This memo includes no request to IANA.
7. Security Considerations 6. Security Considerations
To come.
8. Informative References
[ID.boucadair-altc] 7. Informative References
Boucadair, M., Kaplan, H., Gilman, R., and S.
Veikkolainen, "Session Description Protocol (SDP)
Alternate Connectivity (ALTC) Attribute (Work in
Progress)", April 2012.
[ID.mboned-64-multicast-address-format] [ID.mboned-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
in Progress)", May 2012. in Progress)", May 2012.
[ID.mboned-v4v6-mcast-ps] [ID.mboned-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and
Use Cases (Work in Progress)", May 2012. Use Cases (Work in Progress)", May 2012.
skipping to change at page 7, line 18 skipping to change at page 7, line 13
Progress)", March 2012. Progress)", March 2012.
[MPEG-7_DDL] [MPEG-7_DDL]
"Information technology - Multimedia content description "Information technology - Multimedia content description
interface - Part 2: Description definition language", ISI/ interface - Part 2: Description definition language", ISI/
IEC 15938-2 (2002), 2002. IEC 15938-2 (2002), 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The [RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The
TV-Anytime Content Reference Identifier (CRID)", RFC 4078, TV-Anytime Content Reference Identifier (CRID)", RFC 4078,
May 2005. DOI 10.17487/RFC4078, May 2005,
<http://www.rfc-editor.org/info/rfc4078>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [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, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[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. DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[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,
<http://www.rfc-editor.org/info/rfc6947>.
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 problem receivers. Any solution to the multicast problem described in
described in Section 1 has to take account of the effort involved not Section 1 has to take account of the effort involved not only in the
only in the direct development of a new generation of receivers, but direct development of a new generation of receivers, but also in
also in evolving the specifications on which those receivers are evolving the specifications on which those receivers are based. It
based. It is thus worthwhile to review the current situation as it is thus worthwhile to review the current situation as it affects
affects multicast procedures. 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. 21 change blocks. 
70 lines changed or deleted 73 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/