Multicast Transition Overview
draft-eubanks-mboned-transition-overview-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hitoshi Asaeda , Marshall Eubanks , Tina Tsou (Ting ZOU) , Stig Venaas | ||
| Last updated | 2012-02-29 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-eubanks-mboned-transition-overview-03
Internet Engineering Task Force H. Asaeda
Internet-Draft Keio University
Intended status: Informational M. Eubanks
Expires: September 1, 2012 AmericaFree.TV
T. Tsou
Huawei Technologies (USA)
S. Venaas
Cisco Systems
February 29, 2012
Multicast Transition Overview
draft-eubanks-mboned-transition-overview-03
Abstract
IPTV providers must serve content to their customers during the
period of transition from IPv4 to IPv6. During this period, the
content provider may support only one version of IP while the
customer supports only the other. Likewise, the network between the
provider and its customer may include segments supporting only one
version of IP or another.
This document provides an overview of the multicast transition
problem. It also provides an overview of the solution space. The
solution space is characterized by an adaptation function (AF) that
provides an interface between IPv4 and IPv6 multicast domains.
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 September 1, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Asaeda, et al. Expires September 1, 2012 [Page 1]
Internet-Draft Multicast Transition Overview February 2012
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
2. A Look At the Multicast Transition Problem Space . . . . . . . 3
3. A Look At the Solution Space For Multicast Transition . . . . . 4
3.1. AF Forwarding Plane Operation . . . . . . . . . . . . . . . 4
3.2. AF Control Plane Operation . . . . . . . . . . . . . . . . 5
3.3. Source Discovery . . . . . . . . . . . . . . . . . . . . . 5
3.4. Transitional Multicast Path Optimization . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Asaeda, et al. Expires September 1, 2012 [Page 2]
Internet-Draft Multicast Transition Overview February 2012
1. Introduction
IPTV providers must serve content to their customers during the
period of transition from IPv4 to IPv6. During this period, the
content provider may support only one version of IP while the
customer supports only the other. Likewise, the network between the
provider and its customer may include segments supporting only one
version of IP or another.
This document provides an overview of the multicast transition
problem. It also provides an overview of the solution space. The
solution space is characterized by an adaptation function (AF) that
provides an interface between IPv4 and IPv6 multicast domains.
Section 2 describes the problem space in detail. This section
describes an environment that includes a content provider, a
customer, and an intervening network. Any component of that
environment may support only one version of IP or the other. At
points where IPv4-only devices lie on one side and IPv6-only devices
on the other, an adaptation function is required.
Section 3 proposes a framework for the solution. Section 4 defines
formal requirements for any proposed solution.
2. A Look At the Multicast Transition Problem Space
Historically, IPTV providers have served IPv4 content to consumers
over IPv4 multicast networks. CPE has supported IPv4 only. As the
Internet transitions to IPv6, IPv6-capable equipment will be deployed
by content providers and consumers, as well as the networks that
connect them to one another. So long as all of the newly deployed
gear supports both IPv4 and IPv6, the transition to IPv6 may not
require new IETF protocol specifications. However, if some of the
newly deployed gear supports IPv6 only, incompatibilities will be
introduced.
An incompatibility occurs at a device lying along the path between
the source and the receiver when the next device on the path on one
side of it supports a different version of IP from the next device on
the path on the other side of it (i.e., one device supports IPv4 only
and the other supports IPv6 only). For the purposes of this
document, we will call these points of incompatibility "IP version
transition points". The communication path between provider and
consumer (which includes both endpoints) can include zero or more IP
version transition points.
IP version transition points may be introduced at any point along the
Asaeda, et al. Expires September 1, 2012 [Page 3]
Internet-Draft Multicast Transition Overview February 2012
path. These IP version transition points may reside in the
subscriber premises, at the CPE, in the intervening network etc. In
addition, the Set Top Box (STB) and Electronic Program Guides (EPG)
may have different IP versions.
In order to maintain multicast connectivity, one or more adaptation
functions (AF) are required. These adaption funtions may be deployed
at each IP version transition point. However, if for instance there
are IPv4-only and IPv6-only routers on the path, separated by dual-
stack routers (routers supporting both IPv4 and IPv6), the adaption
function may be placed anywhere along that dual-stack path. The AF
operates in both the forwarding and control planes. Because it
provides an interface between the IPv4 and IPv6 domain, it must be
both IPv4-capable and IPv6-capable.
In most cases, the adaptation function will mediate between IPv4 and
IPv6 on both the control and forwarding planes. However, in
scenarios where the path between provider and consumer contains
multiple IP version transition points, adaptation function instances
may tunnel traffic between one another.
3. A Look At the Solution Space For Multicast Transition
The AF operates on both the forwarding and control planes. On the
forwarding plane, the AF inserts itself into the forwarding path
translating multicast packets from one IP version to the other. On
the control plane, the AF receives routing and signaling messages of
one protocol and sends out routing and signaling messages of another
protocol. If the device acts as a router this may be part of the
usual message processing and generation, but it may also be done as
translation of messages, without taking part in the protocol
operations. [draft to come] provides a discussion of AF operation and
deployment.
3.1. AF Forwarding Plane Operation
The AF accepts packets from one IP version, removes the IP header,
and replaces it with an IP Header of the other version. A
significant portion of that task is address translation. Ideally the
address translation strategy used by an AF should be algorithmic,
stateless and reversible. This should be simple when addresses from
one IP version can simply be embedded into another (IPv4 into IPv6),
but this may not be possible in the opposite direction. That the
translation is reversible means that there is a stateless algorithm
for translating back into the original address.
[RFC6052] provides an algorithm for translating unicast addresses
Asaeda, et al. Expires September 1, 2012 [Page 4]
Internet-Draft Multicast Transition Overview February 2012
between IPv4 and IPv6. Likewise [I-D.mboned-64-mcast-addr-fmt]
provides an algorithm for multicast address conversion between IPv4
and IPv6. Note that using this algorithm, different translators
could choose different IPv6 prefixes for embedding the IPv4
addresses. But the format allows for stateless translation back to
the original IPv4 addresses.
Other issues associated with IP version translation may arise (e.g.,
fragmentation and checksums). The scope of these issues is wider
than that of multicast transition. As such issues are identified,
they will be resolved in conjunction with appropriate IETF working
groups.
3.2. AF Control Plane Operation
On the control plane, the AF mediates between:
o IGMPv3 [RFC3376] and MLDv2 [RFC3810];
o PIM(v4) [RFC4601] and PIM(v6);
o IGMPv3 and PIM(v6);
o MLD and PIM(v4);
The IGMP-to-MLD translation may be configured to use only IGMPv2
features. It is defined in [draft to come].
The PIM-to-PIM mediation operates between PIM protocol operations of
one IP version with operations of the other version. This mediation
is defined in [draft to come].
3.3. Source Discovery
Multicast requires a mechanism through which a receiver can associate
a multicast stream with a multicast group address. The Session
Announcement Protocol (SAP, [RFC2974]) is such a mechanism which is
still in use in academic environments and by some content providers.
AF translation rules for this protocol are also described in [draft
to come]. For commercial purposes, different standards development
organizations have specified protocols for transmission of electronic
program guides. [ID.tsou-multrans-addr-acquisition] specifies the
operation of the AF in such an environment [... in a future version
of the draft which comes to a conclusion on the best way forward].
Asaeda, et al. Expires September 1, 2012 [Page 5]
Internet-Draft Multicast Transition Overview February 2012
3.4. Transitional Multicast Path Optimization
A mechanism to optimize the path to the multicast source for a
combination of IPv4 and IPv6 networks is not immediately required,
but is a topic for future work.
4. 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.
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.
Asaeda, et al. Expires September 1, 2012 [Page 6]
Internet-Draft Multicast Transition Overview February 2012
5. Acknowledgements
Ron Bonica inspired the writing of this memo and shaped its content.
Michael McBride provided useful comments on an intermediate version
of this document.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
To come.
8. Informative References
[I-D.mboned-64-mcast-addr-fmt]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
in Progress)", February 2012.
[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.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[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.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
Asaeda, et al. Expires September 1, 2012 [Page 7]
Internet-Draft Multicast Transition Overview February 2012
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/
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 September 1, 2012 [Page 8]