Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Intended status: Informational C. Zhou
Expires: February 26, 2012 T. Taylor
Huawei Technologies
R. Maglione
Telecom Italia
August 25, 2011
Use Cases For Multicast Transition From IPv4 to IPv6
draft-tsou-multrans-use-cases-00
Abstract
Like other internet activities, multicast is affected by the fact
that the transition from IPv4 to IPv6 is occurring over a period of
years, via multiple transition paths. As a result, mechanisms need
to be added to the basic multicast architecture to assist in specific
transition scenarios. This document describes detailed use cases so
that the requirements for the multicast transition mechanisms can be
better understood.
The considered opinion in discussions to date on multicast transition
requirements has been that the two most important transition
scenarios in the near future will be the "4-6-4" and "6-4" network
scenarios. These scenarios are described in detail below, in their
several possible variants, showing the new issues that IPv6
transition raises for multicast operation.
There is further general agreement that Any-Source Multicast (ASM)
(the service, not necessarily the technology) is no longer an
important use case. As a result, this document restricts itself to
scenarios where the set of multicast sources is separate from the set
of multicast receivers. As a final restriction, it assumes a single
administrative provider domain.
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
Tsou, et al. Expires February 26, 2012 [Page 1]
Internet-Draft Use Cases For Multicast Transition August 2011
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 February 26, 2012.
Copyright Notice
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.
Tsou, et al. Expires February 26, 2012 [Page 2]
Internet-Draft Use Cases For Multicast Transition August 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Stages of Multicast Channel Acquisition . . . . . . . . . . . 5
3. The 4-6-4 Network Scenario . . . . . . . . . . . . . . . . . . 6
3.1. The 4-6-4 Network Scenario With Interworking At the
Customer Edge . . . . . . . . . . . . . . . . . . . . . . 6
3.2. The 4-6-4 Scenario Where Interworking Is Done At the
Provider Edge . . . . . . . . . . . . . . . . . . . . . . 9
4. The 6-4 Network Scenario . . . . . . . . . . . . . . . . . . . 11
4.1. The 6-4 Scenario With IPv6 Access Network . . . . . . . . 11
4.2. The 6-4 Scenario With IPv4 Access Network . . . . . . . . 11
5. The 6-4-6 Network Scenario . . . . . . . . . . . . . . . . . . 11
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Tsou, et al. Expires February 26, 2012 [Page 3]
Internet-Draft Use Cases For Multicast Transition August 2011
1. Introduction
Work on multicast transition from IPv4 to IPv6 has been in progress
for several years, but has not yet resulted in the standardization of
any specific transitional solutions. For a slightly dated survey of
this work, see [ID.Multrans-Taxonomy]. More recently,
[ID.Multrans-Problem-Statement] was created to advance discussion of
the topic.
Discussion of multicast transition has concluded that at the time of
writing, the primary multicast service of interest is Specific-Source
Multicast (SSM). Hence this document assumes that multicast sources
and multicast receivers are separate entities. Furthermore, the most
important network scenarios for multicast transition are summarized
by the expressions "4-6-4" and "6-4". These scenarios are described
in detail below. The numbers, of course, refer to the IP versions
supported by the multicast receiver, the intervening provider
network, and the multicast source. Initial interest is limited to a
single-provider scenario, where multicast sources, the intervening
network, and multicast receivers are all under common administrative
control.
The purpose of the present document is to spell out the use cases for
multicast transition within the boundaries just described. In this
role, this document provides more detail than
[ID.Multrans-Problem-Statement] on the message flows and interworking
details involved, but stops short of the solution detail provided by,
for instance, [ID.Multrans-DS-Lite].
In each network scenario, it is assumed that bandwidth is a valuable
resource, and hence that the network supports a shared tree multicast
routing infrastructure. [RFC5110] provides a snapshot of the
multicast routing architecture as of three years ago. The present
document assumes that deployments have evolved to provide full
support for SSM, and hence that hosts and multicast routers support
IGMPv3 [RFC3376], MLDv2 [RFC3810], and PIM-SM [RFC4601] as
applicable.
It is reasonable to expect that replication of multicast content at
Layer 2 is controlled for scalability and other reasons. However,
this document does not currently include descriptions of actions down
to the Later 2 level.
1.1. Requirements Language
This document is purely descriptive, and contains no normative
language.
Tsou, et al. Expires February 26, 2012 [Page 4]
Internet-Draft Use Cases For Multicast Transition August 2011
2. Stages of Multicast Channel Acquisition
As [RFC5110] and [ID.Multrans-Problem-Statement] indicate, an SSM
receiver acquires a given multicast channel in three stages. In the
first stage, it acquires the source and group addresses that specify
the channel. In the second stage, it indicates its interest in
receiving the channel through multicast signalling, using IGMP
[RFC3376] or MLD [RFC3810]. This signalling is propagated into the
network using PIM-SM [RFC4601] between multicast routers, to add the
receiver to the multicast distribution tree that exists for that
source. Once this has been completed, the third stage consists of
delivery of the packets of content for the selected channel, from the
source to the receiver.
The details of operation in the second and third stages are closely
tied to the network scenario being considered, and hence are
described below. However, the stage of address acquisition lends
itself to a more general discussion and can be dealt with at this
point.
The goal of the address acquisition stage is for the receiver to
acquire a unicast source address and multicast group address with
which it may then proceed to request the desired channel. A variety
of means can be used to achieve this. The receiver may simply be
configured in advance with a listing of addresses for the channels to
which the subscriber is allowed access. Session signalling (SIP
[RFC3261] plus SDP [RFC4566]) may be used. The information may be
provided by an announcement protocol such as SAP [RFC2974], or it may
be accessible through a proprietary program guide over HTTP.
Depending on the network scenario, delivery of this information to
the receiver across IP version boundaries may be more or less
complicated, but the details will depend very much on the particular
deployment.
What is important here is not those details, but the constraints that
the address acquisition process must satisfy so that the remaining
stages can be carried out successfully. The first of these
constraints is that the IP version of the source and group addresses
that the receiver obtains must be understood by the receiver. Thus
in the 4-6-4 scenario these addresses must reach the receiver as IPv4
addresses. In the 6-4 scenario, they must reach the receiver as IPv6
addresses, even though the source itself supports IPv4. The
assumption that we are operating in a single administrative domain
simplifies this task, since AAA can supply details of the
subscription including what IP version is supported by the customer
site.
The second constraint looks forward to the succeeding stages. The
Tsou, et al. Expires February 26, 2012 [Page 5]
Internet-Draft Use Cases For Multicast Transition August 2011
source and group addresses that the receiver acquires must be valid
for the receiver to use in requesting to join the shared distribution
tree for the channel concerned. That is, whenever the multicast
signalling initiated by the receiver crosses an IP version boundary,
these addresses must be consistently mappable to addresses in the new
version that correspond to the same multicast channel. In the final
stage, the incoming multicast content must be presented to the
receiver with the same spource and group addresses that it acquired
in the first stage, regardless of what transformations those
addresses underwent on the path from the source to the receiver.
These requirements will become apparent as we walk through the
detailed use cases in the next few sections.
3. The 4-6-4 Network Scenario
The 4-6-4 network scenario assumes that the multicast source and
receivers both support IPv4. The intervening network supports IPv6.
There are two primary sub-cases, based on the location of the
boundary between IPv4 and IPv6 on the receiver side. On the source
side, that boundary is always assumed to be at the network edge.
o The interworking between IPv4 and IPv6 occurs in a device at the
customer edge. This is described in Section 3.1.
o The interworking between IPv4 and IPv6 occurs at the provider
edge. This is described in Section 3.2.
The following sections walk through stage 2 and stage 3 for each of
these two sub-cases in turn.
3.1. The 4-6-4 Network Scenario With Interworking At the Customer Edge
This case assumes that a dual stack device exists at the customer
edge, offering an IPv4 interface to the receiver and an IPv6
interface to the network. Figure 1 illustrates the signalling path
for this case.
Tsou, et al. Expires February 26, 2012 [Page 6]
Internet-Draft Use Cases For Multicast Transition August 2011
+------+ +----+ +------+ +------+
| Host | IGMP | DS | | MR | PIM | MR |
| Rcvr |------| CE | | | . . . . | |
| | IPv4 | | | (BG) | IPv4 | (DR) |
+------+ +----+ +------+ +------+
/ \
MLD / IPv6 PIM \ IPv4
/ \
+------+ +----+ +------+
| MR | PIM | | PIM | DS |
| |------| MR | . . . | MR |
| (DR) | IPv6 | | IPv6 | (BG) |
+------+ +----+ +------+
------------------------------------->
Rcvr: Multicast receiver
DS : Dual stack
CE : Customer edge router (RFC 4605 compliant)
MR : Multicast router
DR : Designated router
BG : Border gateway
Figure 1: Multicast Signalling When Interworking Is At the Customer
Edge (4-6-4 Scenario)
The multicast signalling sequence illustrated in Figure 1 begins when
the receiving host sends an IGMP Membership Report message toward the
network. The message contains the IPv4 multicast group and unicast
source addresses that the receiver acquired in stage 1. The
destination address is 224.0.0.22, as specified in Section 4.2.14 of
[RFC3376].
The dual stack Customer Edge device, acting as an IGMP/MLD Proxy
[RFC4605], terminates the IGMP Membership Report message. It
interworks it to an MLD Listener Report message. The IPv4 source and
group addresses from the IGMP message are mapped to IPv6 addresses
corresponding to the same multicast channel within the IPv6 network,
and placed into the MLD Listener Report. The need for coordination
with the network means that the mapping has to be provided by the
network operator, either directly or through configuration of an
algorithm and associated parameters. This implies some operator
control over the implementation of the Customer Edge device. The
Customer Edge device sends the MLD Listener Report over an IPv6 link
toward the network, with a destination address of FF02::16 as
specified by Section 5.2.14 of [RFC3810].
At the network edge, the Designated Router [RFC4601] for the customer
Tsou, et al. Expires February 26, 2012 [Page 7]
Internet-Draft Use Cases For Multicast Transition August 2011
site terminates the MLD Listener Report. It updates its internal
state, then, as required, issues a PIM-SM (IPv6) Join message toward
the next multicast router en route to the source. Signalling is
propagated until it joins the existing tree for the given channel, or
reaches the dual stack border device shown as "DS MR (BG)" in the
figure. To make this happen, the operator must configure the
necessary routing information in advance.
At the dual stack border device, the IPv6 source and group addresses
are mapped in their turn to the IPv4 source and group addresses
corresponding to the desired channel in the IPv4 network. The new
IPv4 addresses do not necessarily have to be the same as those
provided to the receiver in the address acquisition stage. Note that
this operation requires coordination between the IPv6 and IPv4
networks. The incoming PIM (IPv6) Join message is interworked to a
PIM (IPv4) Join message directed to the multicast router at the
border of the IPv4 network. The PIM messaging continues to propagate
through the IPv4 network, if necessary, until it ends up at the
Designated Router serving the source.
Figure 2 shows the path taken by content emitted by the source.
+------+ +----+ +------+ +------+ +-----+
| Host | | DS | | MR | | MR | | |
| Rcvr |------| CE | | | . . . | |------| Src |
| | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | |
+------+ +----+ +------+ +------+ +-----+
/ \
/ IPv6 \ IPv4
/ \
+------+ +----+ +------+
| MR | | | | DS |
| |------| MR | . . . | MR |
| (DR) | IPv6 | | IPv6 | (BG) |
+------+ +----+ +------+
<-------------------------------------
Rcvr: Multicast receiver
DS : Dual stack
CE : Customer edge router (RFC 4605 compliant)
MR : Multicast router
DR : Designated router
BG : Border gateway
Src : Multicast source
Figure 2: Content Distribution When Interworking Is At the Customer
Edge (4-6-4 Scenario)
Tsou, et al. Expires February 26, 2012 [Page 8]
Internet-Draft Use Cases For Multicast Transition August 2011
Content distribution starts at the source, which sends an IPv4 packet
of content with its own source address and the destination address
equal to that of the multicast group. The packet is routed through
the tree previously set up in the IPv4 network, eventually reaching
the edge of the IPv6 network. The dual stack node at that network
edge maps the incoming IPv4 source and group addresses to the
corresponding IPv6 addresses used for that channel in the IPv6
network. These are the same addresses used in the signalling stage.
At this point, the dual stack border element can take one of two
actions. Either it encapsulates the original IPv4 packet in an IPv6
header that uses the mapped IPv6 addresses as source and destination,
or it translates incoming IPv4 header to an IPv6 header, also using
the mapped addresses. The choice is a deployment decision. The
result in either case is an IPv6 packet which is forwarded through
the IPv6 network along the tree set up by previous signalling.
Eventually the packet reaches the dual stack customer edge device.
If the packet it receives was encapsulated, it only needs to
decapsulate the packet. If instead the packet header was translated
from IPv4 to IPv6, the customer edge device must now map the incoming
IPv6 source and group addresses to the IPv4 counterparts used to
request the channel in the signalling stage and then perform the
reverse translation. In either case it forwards the resulting packet
to the receiver.
3.2. The 4-6-4 Scenario Where Interworking Is Done At the Provider Edge
This case assumes that the multicast router at the provider edge is a
dual stack device offering an IPv4 interface to the customer site.
The signalling path is shown in Figure 3.
Tsou, et al. Expires February 26, 2012 [Page 9]
Internet-Draft Use Cases For Multicast Transition August 2011
+------+ +------+ +------+
| Host | | MR | PIM | MR |
| Rcvr | | | . . . . | |
| | | (BG) | IPv4 | (DR) |
+------+ +------+ +------+
\ \
IGMP \ IPv4 PIM \ IPv4
\ \
+------+ +----+ +------+
| DS | PIM | | PIM | DS |
| MR |------| MR | . . . | MR |
| (DR) | IPv6 | | IPv6 | (BG) |
+------+ +----+ +------+
------------------------------------->
Rcvr: Multicast receiver
DS : Dual stack
MR : Multicast router
DR : Designated router
BG : Border gateway
Figure 3: Multicast Signalling When Interworking Is At the Provider
Edge (4-6-4 Scenario)
[Signalling description -- can just give delta with respect to
previous section]
Figure 4 shows the path taken by content emitted by the source.
Tsou, et al. Expires February 26, 2012 [Page 10]
Internet-Draft Use Cases For Multicast Transition August 2011
+------+ +------+ +------+ +-----+
| Host | | MR | | MR | | |
| Rcvr | | | . . . | |------| Src |
| | | (BG) | IPv4 | (DR) | IPv4 | |
+------+ +------+ +------+ +-----+
\ \
\ IPv4 \ IPv4
\ \
+------+ +----+ +------+
| DS | | | | DS |
| MR |------| MR | . . . | MR |
| (DR) | IPv6 | | IPv6 | (BG) |
+------+ +----+ +------+
<-------------------------------------
Rcvr: Multicast receiver
DS : Dual stack
MR : Multicast router
DR : Designated router
BG : Border gateway
Src : Multicast source
Figure 4: Content Distribution When Interworking Is At the Provider
Edge (4-6-4 Scenario)
4. The 6-4 Network Scenario
4.1. The 6-4 Scenario With IPv6 Access Network
In this scenario, the IPv6 receiver receives multicast content from
an IPv4 source, where signalling and content must pass through an
IPv6 network to which the receiver is attached.
4.2. The 6-4 Scenario With IPv4 Access Network
In this scenario, the IPv6 receiver receives multicast content from
an IPv4 source, where the receiver is attached to the IPv4 network.
5. The 6-4-6 Network Scenario
An alternative use case is the scenario where both the receivers and
the source are IPv6 capable, but the IPv6 connectivity among them is
provided over an IPv4-Only Network running Multiprotocol Label
Switching (MPLS). MPLS is a well understood and widely deployed
protocol in Service Provider's backbone networks: being able to
Tsou, et al. Expires February 26, 2012 [Page 11]
Internet-Draft Use Cases For Multicast Transition August 2011
transport IPv6 traffic over an IPv4 MPLS network allows the Service
Providers to provide IPv6 connectivity to the edge of the network and
thus to offer IPv6 services, without having to upgrade to IPv6 the
backbone network.
RFC 4798 tackles the unicast angle of the problem and it explains how
to interconnect IPv6 islands over a Multiprotocol Label Switching
(MPLS)-enabled IPv4 cloud by using Multiprotocol Border Gateway
Protocol (MP-BGP) to exchange the IPv6 reachability information
transparently. The devices implementing this mechanism are called
IPv6 Provider Edge routers (6PE). The 6PE technique is currently
deployed for unicast traffic in several Service Provider's networks.
A similar approach would be useful for multicast services too, in
order to allow the Service Providers to start offering IPv6 multicast
contents (from its own multicast sources or provided by external
Content Providers) to new IPv6 customers. This mechanism would allow
the Service Providers to replicate for multicast contents, the same
architectural model currently deployed for unicast traffic with 6PE
method. In addition as this model does not require any translation
or interworking function it is expected it would be able to preserve
the service quality and the integrity of contents.
6. Conclusions
7. Acknowledgements
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
All drafts are required to have a security considerations section.
10. References
10.1. Normative References
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
Tsou, et al. Expires February 26, 2012 [Page 12]
Internet-Draft Use Cases For Multicast Transition August 2011
[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.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing
Architecture", RFC 5110, January 2008.
10.2. Informative References
[ID.Multrans-DS-Lite]
Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y.
Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments (Work in Progress)", June 2011.
[ID.Multrans-Problem-Statement]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use
Cases (Work in Progress)", June 2011.
[ID.Multrans-Taxonomy]
Tsou, T., Zhou, C., and T. Taylor, "A Classification and
Evaluation of Approaches to Transitional Multicast (Work
in Progress)", March 2011.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Tsou, et al. Expires February 26, 2012 [Page 13]
Internet-Draft Use Cases For Multicast Transition August 2011
Authors' Addresses
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: Tina.Tsou.Zouting@huawei.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathy.zhou@huawei.com
Tom Taylor
Huawei Technologies
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Email: tom111.taylor@bell.net
Roberta Maglione
Telecom Italia
Email: roberta.maglione@telecomitalia.it
Tsou, et al. Expires February 26, 2012 [Page 14]