Internet Engineering Task Force H. Asaeda
Internet-Draft Keio University
Intended status: Informational M. Eubanks
Expires: August 5, 2012 AmericaFree.TV
T. Tsou
Huawei Technologies (USA)
S. Venaas
Cisco Systems
February 2, 2012
Multicast Transition Overview
draft-eubanks-mboned-transition-overview-01
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 August 5, 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 August 5, 2012 [Page 1]
Internet-Draft Multicast Transition Overview February 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. A Look At the Solution Space For Multicast Transition . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Asaeda, et al. Expires August 5, 2012 [Page 2]
Internet-Draft Multicast Transition Overview February 2012
1. Introduction
The transition from IPv4 to IPv6 presents challenges for the
operation of multicast networks. In particular, different versions
of IP may be available along the path between the source and the
receivers. Also some nodes may support only IPv4, and some only
IPv6. This may be true for both unicast and multicast.
Additionally, for a given source, the desired receivers may have
different requirements. [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 that 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. Both any-source multicast
(ASM) and specific-source multicast (SSM) support are necessary with
these transitional mechanisms. Due to the wide deployment of IGMPv2-
only CPEs and ASM-only applications, ASM support is required. If
source-specific multicast (SSM) is deployed, the receiver also needs
to learn the associated unicast source address for each multicast
group address. Existing arrangements to support this acquisition
Asaeda, et al. Expires August 5, 2012 [Page 3]
Internet-Draft Multicast Transition Overview February 2012
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
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 case 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], [RFC5790]) and MLD
([RFC2710], [RFC3810], and again [RFC5790]) 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. In any event, one of the challenges
presented by multicast transition is to find a way to avoid routing
loops without requiring 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. Both the unicast source and multicast group
addresses appearing in the packet header in 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. That means that unicast mapping is always required, even in
the absence of SSM. It may be advantageous to coordinate this
mapping for multicast packets with the mapping used for unicast
traffic.
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
Asaeda, et al. Expires August 5, 2012 [Page 4]
Internet-Draft Multicast Transition Overview February 2012
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
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.
In some unicast transition scenarios, part of the solution is to use
dual stack networks. However, if the same stream is broadcast as
both IPv4 and IPv6 packets, bandwidth consumption to carry that
stream increases substantially. Some operators will thus choose to
transmit multicast content through the network in just one IP
version, even if the network implements dual stack for unicast
traffic. Technically, the same consideration does not apply to
multicast signaling, but address remapping is unavoidable even so.
3. Requirements
From the description above, we can distill the following
requirements:
REQ 1: It must be possible for the receiver to acquire the
multicast group address and, where applicable, the unicast source
address of the target stream in the IP version that the receiver
supports.
REQ 2: It must be possible for the receiver to join the multicast
distribution tree for the target stream even if the IP version
used in the interior of the network to which the receiver is
attached is different from the version supported by the receiver.
REQ 3: Where local policy permits, it must be possible to extend
the multicast distribution tree for a given stream across a
network boundary where different IP versions are supported in the
two networks separated by that boundary.
REQ 4: When the multicast distribution tree for a given stream is
extended across multiple network boundaries across one or more of
which the IP version changes, it must be possible to avoid
multicast routing loops.
Asaeda, et al. Expires August 5, 2012 [Page 5]
Internet-Draft Multicast Transition Overview February 2012
REQ 5: It must be possible to pass packets belonging to a given
multicast stream to all joined receivers, regardless of changes in
IP version encountered along the way.
REQ 6: Both ASM and SSM technology must be supported.
REQ 7: The solution(s) should allow operators to minimize the
total incremental cost (investment plus operations during the
transitional period)) due to multicast transition.
REQ 8: The solution(s) should provide a clear evolutionary path to
all-IPv6 operation.
4. 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 or announcement) 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
Asaeda, et al. Expires August 5, 2012 [Page 6]
Internet-Draft Multicast Transition Overview February 2012
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
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.
Asaeda, et al. Expires August 5, 2012 [Page 7]
Internet-Draft Multicast Transition Overview February 2012
5. Acknowledgements
Ron Bonica inspired the writing of this memo and shaped its content.
Michael McBride inspired the text regarding dual stack networks and
added some text regarding the need for ASM support in Section 2.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
To come.
8. 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.
Asaeda, et al. Expires August 5, 2012 [Page 8]
Internet-Draft Multicast Transition Overview February 2012
[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.
[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.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010.
[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
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-0882
Japan
Email: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
Asaeda, et al. Expires August 5, 2012 [Page 9]
Internet-Draft Multicast Transition Overview February 2012
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
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Phone:
Email: stig@cisco.com
Asaeda, et al. Expires August 5, 2012 [Page 10]