Internet DRAFT - draft-tsou-multrans-addr-acquisition
draft-tsou-multrans-addr-acquisition
Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Intended status: Informational December 11, 2011
Expires: June 4, 2012
Address Acquisition For Multicast Content When Source and Receiver
Support Differing IP Versions
draft-tsou-multrans-addr-acquisition-00
Abstract
In a typical IP television (IPTV) system, the receiver acquires
information about available program content, the subscriber selects a
program to watch, and the receiver signals to the network to begin
receiving the program in the form of multicast content. The program
content information is typically XML-encoded, can be transmitted in
multiple segments, possibly over multiple channels, but includes
media stream descriptions for the individual program descriptions
that may also be XML-encoded or may use the Session Description
Protocol (SDP, RFC 4566). The media stream descriptions provide
multicast group and unicast source addresses that are used in the
subsequent signalling to the network.
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 addresses in such
scenarios in the version it supports.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2012.
Copyright Notice
Tsou Expires June 4, 2012 [Page 1]
Internet-Draft Multicast Address Acquisition December 2011
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPTV System Background . . . . . . . . . . . . . . . . . . . . 3
3. Which Problem Are We Solving? . . . . . . . . . . . . . . . . . 5
4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 5
4.1. The Reactive Strategy . . . . . . . . . . . . . . . . . . . 6
4.2. Dynamic Modification . . . . . . . . . . . . . . . . . . . 6
4.3. Administrative Preparation . . . . . . . . . . . . . . . . 7
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Tsou Expires June 4, 2012 [Page 2]
Internet-Draft Multicast Address Acquisition December 2011
1. Introduction
Discussion of the multicast transition problem has focussed on the
IPTV scenario. Within this scenario, the operation of viewing a
program follows a well-defined sequence: first the receiver acquires
program information that includes the detailed information needed to
request delivery of specific 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 source and
multicast group addresses supplied within the program information.
With an all-IPv4 system, it is evident that the program information
will include IPv4 source and group addresses only. Suppose now, as
can occur in some transition scenarios, that IPv6 receivers appear
within the system. Then there will be a mismatch: the IPv6 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.
1.1. Terminology
This memo uses no mandatory language.
The term "receiver" in this document refers to the functionality at
the user location that communicates with the network and receives
multicast content on behalf of the user.
2. IPTV System Background
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.
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
Tsou Expires June 4, 2012 [Page 3]
Internet-Draft Multicast Address Acquisition December 2011
documented in the ETSI TS 102 822 series of technical specifications.
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 [RFC4078]. Quoting from the abstract of that document:
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.
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.
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.
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 uses SIP (Session Initiation Protocol [RFC3261])
signalling to obtain authorization and resources for a session,
before signalling at the multicast level to acquire the program.
[Further research is needed to determine whether the source and
multicast group address are provided in the SDP (Session Description
Protocol [RFC4566]) in the response to the SIP request, or whether
the receiver already has this information from the electronic program
guide before it starts.]
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.
Tsou Expires June 4, 2012 [Page 4]
Internet-Draft Multicast Address Acquisition December 2011
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 definitely embedded as an SDP fragment within a larger
set of XML-encoded program metadata. [Further research needed for
the Open IPTV Forum, as already noted.] 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.
3. Which Problem Are We Solving?
The problem addressed by this memo was stated fairly clearly (the
authors trust) above, but it does not hurt to further clarify the
issue being addressed.
In some transition scenarios, the source supports one IP version
while the receiver and the provider network support the other (e.g.,
the 6-6-4 scenario). In this case, the problem stated above is
unambiguous: how are addresses of the version supported by the
receiver delivered to the receiver, possibly with the help of the
provider network?
In other transition scenarios, the source and provider network
support one IP version while the receiver supports another. In this
case there are actually two problems: how to get provided addresses
to the receiver that it understands (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.
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). In those
scenarios, delivering addresses of the right IP version to the
receiver is notionally a non-problem. The problem still can arise,
if the intervening network intercepts and modifies the access
information to be consistent with the IP version it supports. In
this case, the problem can be re-stated as: how can such modification
by avoided when it is not needed?
4. Possible Solutions
This section explores three classes of solution to the problem at
hand:
Tsou Expires June 4, 2012 [Page 5]
Internet-Draft Multicast Address Acquisition December 2011
o reactive: the receiver recognizes that addresses it has received
are in the wrong version and converts them through a request to a
mapping function;
o dynamic modification: the network intercepts the access
information and modifies it as necessary to meet the requirements
of the receiver;
o administrative: the electronic program guide is modified in
advance of acquisition to provide alternative address versions.
Two variations on this strategy are identified.
4.1. The Reactive Strategy
According to this strategy, an IPv6 receiver receiving IPv4
addresses, for example, would recognize that they were the wrong
version. 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 cited above, the mapping function could be part
of the user site or located in a dual-stack element at the provider
edge. In the 6-6-4 case it would have to be part of the provider
network, although not necessarily at its edge.
This strategy clearly 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. The mapping
function itself is probably needed to solve other aspects of the
multicast transition problem, so should not be considered a cost of
the reactive strategy in particular.
4.2. Dynamic Modification
This strategy puts the entire burden of address adaptation on the
provider network. It requires that an element in that network
intercept program guide information destined to the receiver, locate
the access information, and translate IP address versions as
necessary to suit the receiver. If the problem identified in the
last paragraph of Section 3 is to be avoided, the intercepting
element has to be aware of the version supported by each receiver.
As noted in the description of the OMA architecture, 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
Tsou Expires June 4, 2012 [Page 6]
Internet-Draft Multicast Address Acquisition December 2011
acquisition. The mitigating factor is that program metadata will
typically be retrieved rather less often than program content.
This strategy has the clear advantage that it requires no changes in
the receiver.
4.3. Administrative Preparation
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:
o 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.
o The same access information instance contains alternative IP
address versions. Where SDP is used, we can think of ICE or ICE-
lite [RFC5245] or the proposed altc mechanism
[I_D.boucadair-altc]. This requires receiver modification to
recognize the alternative syntax and potentially 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.
The administrative strategy requires that the network provider have
control over the translations used in the preparation of the
alternativ e 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.
The case where the receiver supports a different IP version from the
network to which it is attached and the adaptation between versions
occurs in the customer network (e.g., 6-4-4 case with dual stack
customer edge device) is not amenable to the administrative approach,
unless the operator is able to control the mapping used by the
customer edge device. Failing that, it appears that the reactive
strategy is the only one that would work in this particular case.
Tsou Expires June 4, 2012 [Page 7]
Internet-Draft Multicast Address Acquisition December 2011
5. Conclusions
To come.
6. Acknowledgements
TBD
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
To come.
9. Informative References
[I_D.boucadair-altc]
Boucadair, M., Kaplan, H., Gilman, R., and S.
Veikkolainen, "Session Description Protocol (SDP)
Alternate Connectivity (ALTC) Attribute", November 2011.
[MPEG-7_DDL]
ISO/IEC, "ISO/IEC 15938-2 (2002): "Information technology
- Multimedia content description interface - Part 2:
Description definition language".", 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4078] Earnshaw, N., Aoki, S., Ashley, A., and W. Kameyama, "The
TV-Anytime Content Reference Identifier (CRID)", RFC 4078,
May 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
Tsou Expires June 4, 2012 [Page 8]
Internet-Draft Multicast Address Acquisition December 2011
Author's Address
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com
Tsou Expires June 4, 2012 [Page 9]
