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/