One document matched: draft-ietf-mboned-multrans-addr-acquisition-02.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-ietf-mboned-multrans-addr-acquisition-02" 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>
<!-- Authors -->
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="T." surname="Tsou" fullname="Tina 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>
<city>Bonn</city>
<code>53227</code>
<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>
<code>35000</code>
<country>France</country>
</postal>
<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>
<email>stig@cisco.com</email>
</address>
</author>
<author initials="Q." surname="Sun" fullname="Qiong Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street>Room 708</street>
<street>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="2013" />
<!-- 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. -->
<keyword>TBD</keyword>
<!-- 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> 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.</t>
</abstract>
</front>
<!-- *****End of FRONT MATTER ***** -->
<!-- *****BODY ***** -->
<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref target="bkgd"/>.</t>
<t>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.</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 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.</t>
<t>Note that the simplest solution might be to avoid mismatches by
making sure that new receivers are dual stack rather than IPv6-
only.</t>
<t>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.</t>
</section> <!-- intro -->
<section anchor="prob" 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
[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?</t>
</section> <!-- prob -->
<section anchor="sol" 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, 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.</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 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
<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.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.</t>
</section> <!-- react -->
<section anchor="dynam" 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="prob"/> 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="bkgd"/>, 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> <!-- dynam -->
<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> <!-- sol -->
<section anchor="concl" title="Conclusions">
<t>To come.</t>
</section> <!-- concl -->
<section anchor="ack" title="Acknowledgements">
<t>TBD</t>
</section> <!-- ack -->
<section anchor="iana" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section> <!-- iana -->
<section anchor="sec" title="Security Considerations">
<t>To come.</t>
</section> <!-- sec -->
</middle>
<!-- *****BODY ***** -->
<!-- *****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></organization>
</author>
<author initials="S." surname="Veikkolainen" fullname="S. Veikkolainen">
<organization>Nokia</organization>
</author>
<date month="April" year="2012"/>
</front>
</reference>
<reference anchor="ID.mboned-v4v6-mcast-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</organization>
</author>
<author initials="Q." surname="Sun" fullname="Q. Sun">
<organization>China Telecom</organization>
</author>
<date month="May" year="2012"/>
</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>Cisco Technologies</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<author initials="S." surname="Venaas" fullname="S. Venaas">
<organization>Cisco Technologies</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="May" year="2012"/>
</front>
</reference>
<reference anchor="ID.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>Cisco Technologies</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="T" surname="Tsou" fullname="T. Tsou">
<organization></organization>
</author>
<author initials="X." surname="Deng" fullname="X. Deng">
<organization>France Telecom</organization>
</author>
<date month="March" year="2012"/>
</front>
</reference>
<reference anchor="MPEG-7_DDL">
<front>
<title>Information technology - Multimedia content description interface - Part 2: Description definition language</title>
<author initials="" surname="" fullname="">
<organization></organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISI/IEC" value="15938-2 (2002)"/>
</reference>
</references>
<section anchor="bkgd" 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 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.</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>
</back>
<!-- *****BACK MATTER ***** -->
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 05:19:54 |