One document matched: draft-tsou-mboned-multrans-addr-acquisition-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC4078 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4078.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-mboned-multrans-addr-acquisition-00"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Multicast Address Acquisition">Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>Tina.Tsou.Zouting@huawei.com</email>
</address>
</author>
<author initials="A." surname="Clauberg" fullname="Axel Clauberg">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Deutsche Telekom AG, GTN-FM4</street>
<street>Landgrabenweg 151</street>
<code>53227</code>
<city>Bonn</city>
<region></region>
<country>Germany</country>
</postal>
<phone>+4922893618546</phone>
<email>axel.clauberg@telekom.de</email>
</address>
</author>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<phone></phone>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author initials="S." surname="Venaas" fullname="Stig Venaas">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<email>stig@cisco.com</email>
</address>
</author>
<author initials="Q." surname="Sun" fullname="Qiong Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street>Room 708, No.118, Xizhimennei Street</street>
<city>Beijing</city>
<region></region>
<code>100035</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-58552936</phone>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the
year is not the current one, it is necessary to specify at least a month
(xml2rfc assumes day="1" if not specified for the purpose of calculating
the expiry date). With drafts it is normally sufficient to specify just
the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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 and evaluates alternative strategies for allowing
the receiver to acquire multicast address information in such scenarios in
the version it supports. </t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>Discussion of the multicast transition problem has focussed on the case
of unidirectional delivery of multicast content. Within this scenario, the
operation of viewing a program follows a well-defined sequence. For the
sake of reducing the zapping delay, the list of multicast addresses is
generally pre-provisioned to the receiver as part of the program guide
prior to requesting access to the multicast content. At some subsequent
time the user chooses to view a program, possibly by selecting it from a
displayed program guide, 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 information.</t>
<t>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 multicast group addresses (and optionally, IPv4 unicast source
addresses). Suppose now, as can occur in some transition scenarios, that
IPv6-only receivers acquire program information containing these IPv4
addresses. Then there will be a mismatch: the IPv6-only receivers will
be unable to use the addresses that are provided in the program information.
This memo examines the possible strategies for remedying this mismatch,
evaluating them in terms of their impact on receiver implementation and
network operation. </t>
<t>This document makes reference to some of the scenarios described in
Section 3 of <xref target="ID.jaclee-behave-v4v6-multicast-ps"/>. The remarks
in Section 4.1 of <xref target="ID.jaclee-behave-v4v6-multicast-ps"/> are
relevant to the problem considered here, but are more restricted in scope.</t>
</section><!-- intro -->
<section anchor="whichProb" title="Which Problem Are We Solving?">
<t>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?</t>
<t>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.</t>
<t>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
<xref target="ID.jaclee-behave-v4v6-multicast-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?</t>
</section><!-- whichProb -->
<section anchor="solutions" title="Possible Solutions">
<t>This section explores three classes of solutions to the problem just
described:
<list style="symbols">
<t>reactive: the receiver recognizes that addresses it has received are
in the wrong version and converts them through a request to a mapping
function or using an in-built algorithm and accompanying configuration;</t>
<t>dynamic modification: the network intercepts the access information
and modifies it as necessary to meet the requirements of the receiver;</t>
<t>administrative: the electronic program guide is modified in advance of
its acquisition by the receiver to provide alternative address versions.
Two variations on this strategy are identified.</t>
</list>
</t>
<section anchor="react" title="The Reactive Strategy">
<t>According to this strategy, an IPv6 receiver receiving IPv4 addresses,
for example, would recognize that they were the wrong version. As one
possibility, it would package the addresses into one or two requests to
a mapping function, which would return corresponding IPv6 addresses. In
the 6-4-4 scenario (IPv6 receiver, IPv4 network and source), the mapping
function could be located in another node at the user site or located in
a dual-stack element at the provider edge. In the 6-6-4 case (IPv6
receiver and network, IPv4 source) it would have to be part of the
provider network, although not necessarily at its edge. </t>
<t>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. </t>
<t>As an alternative, the receiver could 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
<xref target="ID.mboned-64-multicast-address-format"/> for multicast group
addresses or <xref target="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
<xref target="ID.qin-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 more limited level.</t>
</section><!-- react -->
<section anchor="dynamic" title="Dynamic Modification">
<t>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
<xref target="whichProb"/> is to be avoided, the intercepting element
has to be aware of the version supported by each receiver.</t>
<t>As noted in the description of the OMA architecture in
<xref target="rcvrArt"/>, 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. </t>
<t>This strategy has the clear advantage that it requires no changes
in the receiver.</t>
</section><!-- dynamic -->
<section anchor="admin" title="Administrative Preparation">
<t>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:
<list style="symbols">
<t>separate alternative versions of the access information are
prepared. The correct version is served up to the receiver when it
requests it. Like the dynamic modification strategy, this approach
assumes that it is administratively feasible for the program guide
server to know the IP version of the requesting receiver. That may
or may not be true in a given operator's context. Also as with the
dynamic modification approach, no change is required in the receiver.
The big advantage over dynamic modification is that there is no need
for the complications of an intercepting adapting element.</t>
<t>The same access information instance contains alternative IP
address versions. Where SDP is used, we can think of ICE or ICE-lite
<xref target="RFC5245"/> or the proposed 'altc' mechanism
<xref target="ID.boucadair-altc"/>. This requires receiver
modification to recognize the alternative syntax and (in the case of
ICE and potentially in the case of ICE-Lite) to take part in STUN
exchanges. However, it means that the same access information can be
served up to all receivers in a backward-compatible manner.</t>
</list>
</t>
<t>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.</t>
</section><!-- admin -->
</section><!-- solutions -->
<section anchor="conclusion" title="Conclusions">
<t>To come.</t>
</section><!-- conclusion -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To come.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Informative References">
&RFC3261;
&RFC4078;
&RFC4566;
&RFC5245;
&RFC6052;
<reference anchor="ID.boucadair-altc">
<front>
<title>Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute (Work in Progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="H." surname="Kaplan" fullname="H. Kaplan">
<organization>Acme Packet</organization>
</author>
<author initials="R." surname="Gilman" fullname="R. Gilman">
<organization>Independent</organization>
</author>
<author initials="S." surname="Veikkolainen" fullname="S. Veikkolainen">
<organization>Nokia</organization>
</author>
<date month="November" year="2011"/>
</front>
</reference>
<reference anchor="ID.jaclee-behave-v4v6-multicast-ps">
<front>
<title>IPv4-IPv6 Multicast: Problem Statement and Use Cases (Work in Progress)</title>
<author initials="C." surname="Jacquenet" fullname="C. Jacquenet">
<organization>France Telecom</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<author initials="J." surname="Qin" fullname="J. Qin">
<organization>ZTE</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<date month="November" year="2011"/>
</front>
</reference>
<reference anchor="ID.qin-softwire-multicast-prefix-option">
<front>
<title>DHCPv6 Options for IPv6 DS-Lite Multicast Prefix (Work in Progress)</title>
<author initials="J." surname="Qin" fullname="J. Qin">
<organization>ZTE</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<date month="October" year="2011"/>
</front>
</reference>
<reference anchor="ID.mboned-64-multicast-address-format">
<front>
<title>IPv4-Embedded IPv6 Multicast Address Format (Work in Progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="J." surname="Qin" fullname="J. Qin">
<organization>ZTE</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<author initials="S." surname="Venaas" fullname="S. Venaas">
<organization>Cisco Systems</organization>
</author>
<author initials="X." surname="Li" fullname="X. Li">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="M." surname="Xu" fullname="M. Xu">
<organization>Tsinghua University</organization>
</author>
<date month="February" year="2012"/>
</front>
</reference>
<reference anchor="MPEG-7_DDL">
<front>
<title>ISO/IEC 15938-2 (2002): "Information technology - Multimedia content description interface - Part 2: Description definition language".</title>
<author initials="" surname="" fullname="">
<organization>ISO/IEC</organization>
</author>
<date year="2002"/>
</front>
</reference>
</references>
<section anchor="rcvrArt" title="Some Background On Program Guides">
<t>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 <xref target="intro"/> 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.</t>
<t>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.</t>
<t>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 <xref target="RFC4078"/>. Quoting from the abstract of that document:
<list style="empty">
<t>The Uniform Resource Locator (URL) scheme "CRID:" has been devised to
allow references to current or future scheduled publications of
broadcast media content over television distribution platforms and
the Internet.</t>
<t>The initial intended application is as an embedded link within
scheduled programme description metadata that can be used by the home
user or agent to associate a programme selection with the
corresponding programme location information for subsequent automatic
acquisition.</t>
</list>
</t>
<t>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.</t>
<t>The Open IPTV Forum (http://www.oipf.tv) 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
<xref target="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 <xref target="RFC4566"/>) session description.</t>
<t>Finally, the Open Mobile Alliance (OMA, http://www.openmobilealliance.org/)
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. </t>
<t>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. </t>
</section><!-- rcvrArt -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:23 |