Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track C. Zhou
Expires: August 2, 2011 Huawei Technologies
H. Ji
China Telecom
January 29, 2011
A Generic Approach to Multicast Encapsulation In Support of IPv6
Transition
draft-tsou-softwire-encapsulated-multicast-00
Abstract
Consider a situation which will arise in many IPv6 transition
scenarios, where Network A, to which a host is attached, supports one
IP version, but the host and Network B support a different IP
version. Suppose that the host wishes to access a multicast group
which is rooted or sourced in Network B. This document specifies an
approach that combines stateful translation for signalling,
encapsulation of multicast content moving between Network B and the
host, and native multicast routing in Network A to provide the host
with its desired access.
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 2, 2011.
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
Tsou, et al. Expires August 2, 2011 [Page 1]
Internet-Draft Generic Multicast Encapsulation January 2011
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. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. How It Works . . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
5. Mapping Request Protocol . . . . . . . . . . . . . . . . . . . 7
6. Operational Considerations . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Tsou, et al. Expires August 2, 2011 [Page 2]
Internet-Draft Generic Multicast Encapsulation January 2011
1. Introduction
Transition scenarios have been explored in which an IPv6 host
attached to an IPv4 network wishes to access content in an IPv6
network, or conversely, an IPv4 host attached to an IPv6 network
wishes to access content in an IPv4 network. A long list of tools
has been put forward for passing unicast content across the network
in the middle based on tunneling.
Some work has also been done on conveying multicast streams between
IPv4 and IPv6 networks, in either direction. Of particular interest
is current work in [ID.softwire-dslite-multicast]. However, the
present document differs from [ID.softwire-dslite-multicast] both in
its degree of generality and in the detailed mechanism used for
translation between IPv4 and IPv6 multicast addresses. The present
document does not restrict operation to specially constructed IPv6
multicast addresses. Instead it makes use of the fact that for a
given network, it is unnecessary to map the complete universe of IPv6
addresses into IPv4, but only those addresses actually being carried
through the network.
This document is adapted from [ID.behave-translated-multicast] and
uses the same basic mechanism. It requires additional bandwidth
because of its use of encapsulation for the multicast content, but
thereby avoids the need to translate the addressing of that content
between IPv4 and IPv6 at the receiving end of the tunnel.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Problem Description
We consider, as described in the previous section, a host supporting
one IP version, say IPvx, attached to a provider network supporting a
different version, say IPvy. Obviously there has to be an adaptation
function between the host and the network to make this work. This
document assumes that the adaptation function for unicast packets
consists of tunneling combined with a suitable choice of destination
address to steer the packets to the right border gateways.
On the other side of the provider network, border gateways connect to
neighbouring networks. If a particular neighbouring network supports
a different version of IP -- that is, IPvx, then the border gateway
must also implement adaptation functions. In particular, the unicast
Tsou, et al. Expires August 2, 2011 [Page 3]
Internet-Draft Generic Multicast Encapsulation January 2011
adaptation function at the border gateway is complementary to the
adaptation function at the host side.
Multicast streams could simply be tunneled from the border to the
host. However, to save bandwidth, it is desirable to use the native
multicast capabilities of the IPvy network so that paths can be
shared as much as possible. This implies three requirements on the
multicast adaptation function:
o it has to enable the use of multicast signalling to build
distribution trees in the IPvy network;
o it has to route multicast content through those distribution trees
rather than directly across the network;
o by specific assumption of this document, it must encapsulate
incoming IPvx packets before forwarding them to the distribution
trees, and decapsulate outgoing packets before sending them
onwards.
The basic situation just described is illustrated in Figure 1. The
host-side adaptation functions MAY be implemented in the host itself,
in a separate piece of equipment at the customer site (CPE-based
approach), or at the provider edge (gateway initiated approach). The
border adaptation functions MUST be implemented in border gateways.
+------------+ | | +------------+ |
| Host-side | | | | Border | |
+----| unicast |------------------| unicast |----
/ | adaptation | | | | adaptation | |
+----+ / | function | | | | functions | |
|IPvx|/ +------------+ | IPvy | +------------+ | IPvx
|Host|\ | Provider | | Network
+----+ \ +------------+ | Network | +------------+ |
\ | Host-side | | | | Border | |
\ | multicast | |Signalling| | multicast | |
+---| adaptation |---|----------|---| adaptation |---|-
| | function | | | | function | |
+---| (HMAF) |------------------| (BMAF) |----
+------------+ | Media | +------------+ |
Figure 1: Adaptation Functions For Flows Crossing Two IP Version
Boundaries
The key assumption of this document is that when the host wishes to
acquire a multicast stream rooted or sourced in the IPvx network, it
knows only the IPvx address pair <Source, Group> (where the source
Tsou, et al. Expires August 2, 2011 [Page 4]
Internet-Draft Generic Multicast Encapsulation January 2011
MAY be wild-carded, i.e., for an any-source multicast group).
It learns that address pair by means outside the scope of this
specification (e.g., via the web or session signalling).
As a result, for purposes of multicast signalling, the host-side
multicast adaptation function (HMAF) needs to obtain a mapping
between this IPvx address pair and the corresponding IPvy address
pair used in the IPvy network to denote the same multicast stream.
Similarly, the border multicast adaptation function (BMAF) needs this
mapping both for purposes of multicast signalling and so that it can
assign the right IPvy source and destination addresses to incoming
IPvx multicast content.
3. Proposed Solution
The proposed solution consists of three elements:
o a stateful mapping function within the IPvy provider network that
provides mappings between IPvx <Source, Group> address pairs and
corresponding IPvy <Source, Group> address pairs denoting the same
multicast flows;
o address pools of IPvy multicast and unicast addresses provisioned
at the mapping function;
o a protocol that allows the HMAF and BMAF to request mappings from
the mapping function. PCP [ID.port-control-protocol] is a
candidate for this protocol, but that decision needs further
consideration.
3.1. How It Works
1. Initial discovery and Join request
The IPvx host discovers the <Source, Group> address pair of a
multicast stream the user wants to receive. The IPvx Host sends an
MLDv2 [RFC3810] (for IPv6) or IGMPv3 [RFC3376] (for IPv4) Join
request to the HMAF to acquire the stream.
2. <Source, Group> Address Mapping At the HMAF
The HMAF checks its cache of mappings to see if it already has a
mapping between the IPvx <Source, Group> address pair received in the
host request and a corresponding pair of IPvy addresses. Failing to
find a mapping, it sends a request for the required mapping to the
mapping function. The mapping function in turn checks whether it has
Tsou, et al. Expires August 2, 2011 [Page 5]
Internet-Draft Generic Multicast Encapsulation January 2011
already created the mapping. If not, it assigns unicast and
multicast IPvy addresses from its pool and records the mapping for
further use. In either case it returns the requested mapping to the
HMAF, which caches it. [Editor's Note: The transaction is carried
out over a protocol to be specified in a later version of this
document.]
3. Propagation Of the Join Request Into the IPvy Network
Using the mapping it has received, the HMAF interworks from MLDv2 to
IGMPv3 or vice versa, depending on whether the host supports IPv6 or
IPv4. It forwards the interworked Join request to the Provider IP
Edge.
If the HMAF is collocated with the Provider IP Edge, this
interworking step is an internal operation.
The Provider IP Edge acts on the received request by interworking it
to a Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]
request and forwarding that request into the IPvy network, indicating
the IPvy <Source, Group> address pair it was given and ensuring that
it is on the multicast tree for the stream concerned.
Assuming that the multicast tree for the requested stream is not
joined at an earlier point in the provider network, eventually the
PIM request finds its way to the BMAF. It has been suggested that
the border gateway in which the BMAF resides can be made a PIM-SM
rendezvous point (RP) to ensure that requests for new groups reach
it.
4. Remapping the <Source, Group> Address Pair At the BMAF
The BMAF needs to map from the IPvy <Source, Group> address pair it
received back to the corresponding IPvx address pair before
propagating the PIM request into the IPvx network. It sends a
request to the mapping function to provide that mapping. The mapping
function already has this mapping, as a result of the original HMAF
request, and returns it to the BMAF. [Editor's note: protocol again
to be specified later. It can probably be the same as the one used
by the HMAF. Have to work out the security considerations.]
5. Propagation Of the PIM Request Into the IPvx Network
The BMAF propagates translates the PIM request from IPvy to IPvx
using the mapping it received. It propagates the request into the
IPvx network to complete the construction of the path for the
requested multicast stream. If path construction fails, the BMAF
SHOULD notify the mapping function so it can mark the IPvx address
Tsou, et al. Expires August 2, 2011 [Page 6]
Internet-Draft Generic Multicast Encapsulation January 2011
pair as bad (so it doesn't get remapped) while releasing the assigned
IPvy addresses.
6. Transport of Multicast Media and Unicast RTCP Feedback
If the BMAF receives a multicast packet from the IPvx network, it
checks its cache of mappings to locate the IPvy source and group
addresses corresponding to the incoming IPvx packet header. It
encapsulates the packet in an IPvy header containing the mapped IPvy
source and with the destination set to the mapped IPvy group address.
It then forwards the packet to the next hop in the multicast tree for
that source and group.
When the HMAF receives a multicast packet from the IPvy network, it
decapsulates it and forwards it to the host.
When the IPvx host sends unicast RTCP [RFC3550] feedback toward the
source, the packets are handled like any other unicast packets. That
is, they are processed by the unicast adaptation functions rather
than the HMAF and BMAF.
Finally, if the IPvx Host emits multicast packets destined for an
any-source multicast group, the processing of the packet is as just
described, but with the roles of the HMAF and BMAF reversed.
4. Acknowledgements
This draft started out as draft-tsou-softwire-6rd-multicast-00.
Thanks to Joel Halpern for suggesting that it be written as a more
general document, since it did not really depend on 6rd. Thanks to
Yiu Lee for further comments, which have been used to improve the
document.
5. Mapping Request Protocol
To come.
6. Operational Considerations
The proposal presented here incurs the operational expense of
provisioning the multicast and unicast address pools at the mapping
function. Proper functioning of the system requires that the
operator estimate the total number of different IPvx multicast groups
and, for source-specific multicast, the total number of individual
IPvx sources it wishes to enable simultaneously.
Tsou, et al. Expires August 2, 2011 [Page 7]
Internet-Draft Generic Multicast Encapsulation January 2011
7. IANA Considerations
This memo currently includes no request to IANA.
8. Security Considerations
To come.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
9.2. Informative References
[ID.behave-translated-multicast]
Tsou, T., Taylor, T., Zhou, C., and H. Ji, "A Generic
Approach to Multicast Translation In Support of IPv6
Transition", January 2011.
[ID.port-control-protocol]
Wing, D., "Port Control Protocol (PCP)", January 2011.
[ID.softwire-dslite-multicast]
Wang, Q., Qin, J., Sun, P., Boucadair, M., Jacquenet, C.,
and Y. Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments", January 2011.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Tsou, et al. Expires August 2, 2011 [Page 8]
Internet-Draft Generic Multicast Encapsulation January 2011
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Authors' Addresses
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tena@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
Hui Ji
China Telecom
NO19.North Street
Beijing, Chaoyangmen,Dongcheng District
P.R. China
Phone:
Email: jihui@chinatelecom.com.cn
Tsou, et al. Expires August 2, 2011 [Page 9]