Internet Engineering Task Force H. Asaeda
Internet-Draft
Intended status: Informational M. Eubanks
Expires: July 13, 2012 AmericaFree.TV
T. Tsou
Huawei Technologies (USA)
S. Venaas
Cisco Systems
January 10, 2012
Multicast Transition Overview
draft-eubanks-mboned-transition-overview-00
Abstract
The transition from IPv4 to IPv6 raises issues for multicast
signaling and multicast content distribution. This memo describes
the problem and briefly surveys the solution space.
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 July 13, 2012.
Copyright Notice
Copyright (c) 2012 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
Asaeda, et al. Expires July 13, 2012 [Page 1]
Internet-Draft Multicast Transition Overview January 2012
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. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. A Look At the Multicast Transition Problem Space . . . . . . . 3
3. A Look At the Solution Space For Multicast Transition . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Informative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Asaeda, et al. Expires July 13, 2012 [Page 2]
Internet-Draft Multicast Transition Overview January 2012
1. Introduction
The transition from IPv4 to IPv6 presents challenges for multicast
operation. It is common in practice to encounter differences between
IP versions supported along the path between the source and the
receiver, with some nodes only supporting IPv4, some IPv6, for both
multicast and unicast. [ID.jaclee-behave-v4v6-mcast-ps] illustrates
the different end-to-end configurations that can occur during
transition (and identifies the most likely ones) while exploring the
problem of multicast transition for IPTV applications in particular.
The reason that the draft concentrates on IPTV is that this
application is encountering multicast transition issues in the
present and these are likely to intensify in the near future. In
this document, "multicast transition" will specifically refer to
transitions between IPv4 and IPv6 or vice versa, including networks
with multiple transitions, say from IPv4 to IPv6 and back to IPv4,
and a "multicast domain" will refer to a network or sub-network
supporting one or both variants of Internet multicast. Note that
networks may support both versions of the Internet protocol without
supporting multicast in both versions, and so multicast transitions
may be required even in cases where end-to-end unicast transport is
supported.
The present memo provides a quick survey of the problem space and the
possible solutions, as an aid to further discussion of the topic of
multicast transition.
1.1. Requirements Language
This document contains no requirements language.
2. A Look At the Multicast Transition Problem Space
As [ID.jaclee-behave-v4v6-mcast-ps] points out, in common practice
multicast video transport actually happens in three stages. First,
the receiver has to acquire the address(es) that it needs to request
a particular multicast stream. It always needs to learn the
multicast group address or addresses. If source-specific multicast
(SSM) is deployed, it also needs to learn the associated unicast
source address for each multicast group address. Existing
arrangements to support this acquisition process will in some cases
need modification to ensure that the receiver acquires the
address(es) in the IP version that it understands.
Following address acquisition, the receiver uses multicast signaling
to request delivery of the user-selected multicast stream or streams.
The key issue at this stage is that each time the multicast signaling
Asaeda, et al. Expires July 13, 2012 [Page 3]
Internet-Draft Multicast Transition Overview January 2012
crosses a boundary between a network supporting one IP version and a
network supporting the other, the address(es) designating the
requested multicast stream need to be remapped to the new version.
This is required in all cases for the group addresses, and also for
unicast source addresses for SSM. In addition, in the particular
case where there is a transition at the receiver itself, protocol
interworking between IGMP ([RFC2236], [RFC3376]) and MLD ([RFC2710],
[RFC3810]) may be necessary. Even in the case where the receiver
shares a link with a (dual stack) multicast router, such interworking
may be considered to occur internally in the multicast router as an
intermediate step.
The creation of multicast trees in response to multicast signaling
relies on the use of reverse path forwarding (RPF) to avoid the
creation of routing loops; this is also required in networks
performing transitions between multicast domains. In the face of
address remapping, it has been suggested that each network along the
path from source to receiver needs to know the ultimate source
address for RPF to work. Thus, part of the multicast transition
problem is to make sure that this information is available at the
appropriate point in the routing process, or to devise an alternative
means for doing this that would avoid routing loops without end to
end source discovery.
The final stage of multicast acquisition is the actual delivery of
packets of multicast content, i.e., the flooding of data down the
multicast trees. Again, address mapping is required across each IP
version boundary. The source and group addresses appearing in the
one network must be replaced by corresponding source and group
addresses in the other IP version before the packet can be forwarded
for its next stage of travel.
Address remapping across IP version boundaries is required in all
three stages of acquisition of a multicast stream.
[ID.venaas-behave-v4v6mc-framework] examines the issue of translation
between IPv4 and IPv6 multicast addresses in various scenarios. In
many cases of practical interest, stateless mapping is possible.
A key point is that address mapping requires coordination both in
space and in time. To ensure that the multicast stream requested is
the one delivered, the same address(es), or a unique mapping of those
addresses, must be used to designate the stream at any given point,
whether at the stage of address acquisition, multicast signaling, or
multicast content delivery. Moreover, coordination between
successive multicast domains in the path is required to ensure that
the address(es) requested by the receiver are mapped in the source
network to the stream that the user wishes to acquire. In stateless
mapping, the network must ensure that two streams that might be
Asaeda, et al. Expires July 13, 2012 [Page 4]
Internet-Draft Multicast Transition Overview January 2012
requested by a given user are not given the same address(es) at the
same time; this is more difficult when transitioning into an IPv4
domain given the smaller range of address space available in IPv4.
3. A Look At the Solution Space For Multicast Transition
Consistently with the problem space overview, the multicast
transition problem divides naturally into three parts:
1. providing a multicast group and possibly unicast source address
to the receiver in the IP version supported by the receiver;
2. mediating the exchange of multicast signaling and content between
the receiver and its network when the two support different IP
versions;
3. mediating the exchange of multicast signaling and content between
two networks supporting different IP versions along the path
between the source and the receiver.
Problem 1 is addressed in [ID.tsou-multrans-addr-acquisition]. In
the IPTV case, the key element in the solution for address
acquisition (discovery) is the processing of the electronic program
guide (EPG) that provides the receiver with the multicast group and
possibly the unicast source addresses it needs to request specific
program instances. Three possible strategies are considered:
o recognition and conversion of unsupported-IP-version addresses at
the receiver after it receives the EPG, through a protocol
exchange with a mapping function in the network;
o interception and remapping of addresses in the EPG as necessary by
the network to which the receiver is attached, before the receiver
receives information from the EPG;
o administrative modification of the EPG in advance of acquisition,
either to provide the specific version required by each receiver
or to carry addresses in both versions in a form that allows the
receiver to select the version it supports.
Problem 2 is addressed in [ID.zhou-multrans-af1-specification]. That
draft uses the term "Type 1 Adaptation Function" (AF1) for a
mediating function between the receiver and the network. This
function has two parts: translating the multicast access signaling
(IGMP or MLD) to the signaling appropriate to the other IP version
(MLD or IGMP respectively), and modifying incoming packets of content
to the version supported by the receiver. These packets may need
Asaeda, et al. Expires July 13, 2012 [Page 5]
Internet-Draft Multicast Transition Overview January 2012
either header translation or decapsulation, depending on the
deployment. Difficulties in evolution of the decapsulation option
with the transition to all-IPv6 operation are noted.
Problem 3 is addressed in [ID.taylor-multrans-af2-specification].
Here the term "Type 2 Adaptation Function" (AF2) is used for the
function required. Again, this function operates both on multicast
signaling and multicast content. On the signaling side, the function
maps the addresses contained in PIM messages from one IP version to
the other. With respect to content, depending on deployment, the AF2
either encapsulates or translates the headers of incoming packets of
multicast content before forwarding them toward the receiver.
A basic tool required for all of these problems is a method to map
consistently between IPv4 and IPv6 versions of the source and group
addresses. [RFC6052] provides the necessary mapping for the unicast
source addresses, if present.
[ID.boucadair-behave-64-multicast-address-format] provides a
stateless solution for the mapping between IPv4 and IPv6 multicast
addresses.
[ID.softwire-dslite-multicast] is essentially an applicability
statement, showing the application of the AF1, AF2, and address
mapping to the particular case where DS-Lite is deployed. AF1 is
located in the "multicast B4" (mB4), along with the unicast DS-Lite
B4 function, at the customer edge. AF2 is located in the "multicast
AFTR" at the border between the IPv6 network to which the customer is
attached and the IPv4 network containing the source. The draft
specifies the use of encapsulation of multicast content across the
IPv6 network.
[ID.xu-softwire-mesh-multicast] deals with the particular case where
a multicast-capable network provides a transit service between other
multicast-capable networks of differing IP versions. Its interaction
with the proposed AF2 functionality requires further study.
4. Acknowledgements
Ron Bonica inspired the writing of this memo and shaped its content.
5. IANA Considerations
This memo includes no request to IANA.
Asaeda, et al. Expires July 13, 2012 [Page 6]
Internet-Draft Multicast Transition Overview January 2012
6. Security Considerations
To come.
7. Informative References
[ID.boucadair-behave-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
in progress)", October 2011.
[ID.jaclee-behave-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use
Cases (Work in progress)", November 2011.
[ID.softwire-dslite-multicast]
Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y.
Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments (Work in progress)", October 2011.
[ID.taylor-multrans-af2-specification]
Taylor, T. and C. Zhou, "Specification of an Adaptation
Function Between Two Multicast Networks Supporting
Different IP Versions (Work in progress)", December 2011.
[ID.tsou-multrans-addr-acquisition]
Tsou, T., "Address Acquisition For Multicast Content When
Source and Receiver Support Differing IP Versions (Work in
progress)", December 2011.
[ID.venaas-behave-v4v6mc-framework]
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation (Work in progress)", June 2011.
[ID.xu-softwire-mesh-multicast]
Xu, M., Cui, Y., Yang, S., Metz, C., and G. Shepherd,
"Softwire Mesh Multicast (Work in progress)", July 2011.
[ID.zhou-multrans-af1-specification]
Zhou, C. and T. Taylor, "Specification of a Provider-
Managed Adaptive Function Between a Multicast Receiver and
a Provider Network Supporting a Different IP Version (Work
in progress)", December 2011.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
Asaeda, et al. Expires July 13, 2012 [Page 7]
Internet-Draft Multicast Transition Overview January 2012
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
Authors' Addresses
Hitoshi Asaeda
Phone:
Email: asaeda@sfc.wide.ad.jp
Marshall Eubanks
AmericaFree.TV
P.O. Box 141
Clifton, VA 20124
USA
Phone:
Email: marshall.eubanks@gmail.com
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: Tina.Tsou.Zouting@huawei.com
Asaeda, et al. Expires July 13, 2012 [Page 8]
Internet-Draft Multicast Transition Overview January 2012
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Phone:
Email: stig@cisco.com
Asaeda, et al. Expires July 13, 2012 [Page 9]