One document matched: draft-tsou-behave-translated-multicast-01.txt
Differences from draft-tsou-behave-translated-multicast-00.txt
Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track T. Taylor
Expires: August 1, 2011 C. Zhou
Huawei Technologies
H. Ji
China Telecom
January 28, 2011
A Generic Approach to Multicast Translation In Support of IPv6
Transition
draft-tsou-behave-translated-multicast-01
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 a
stateful translation mechanism whereby the host can obtain its
desired access using the native multicast capabilities of Network A.
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 1, 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
Provisions Relating to IETF Documents
Tsou, et al. Expires August 1, 2011 [Page 1]
Internet-Draft Generic Multicast Translation January 2011
(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. Mapping Request Protocol . . . . . . . . . . . . . . . . . . . 7
5. Numerical Examples . . . . . . . . . . . . . . . . . . . . . . 7
5.1. 4-6-4 Example . . . . . . . . . . . . . . . . . . . . . . 7
5.2. 6-4-6 Example . . . . . . . . . . . . . . . . . . . . . . 8
6. Operational Considerations . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Tsou, et al. Expires August 1, 2011 [Page 2]
Internet-Draft Generic Multicast Translation 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 either on tunneling or on translation.
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.venaas-mcast46], which was the original
inspiration for the content of the present document. However, the
present document differs from [ID.venaas-mcast46] both in point of
view and in the detailed mechanism used for translation.
[ID.boucadair-64-multicast] presents a different approach, relying
like [ID.venaas-mcast46] on specially constructed multicast
addresses. The present document presents no such restriction.
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.
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. We
distinguish between the unicast and multicast adaptation functions,
where multicast adaptation by definition processes both signalling
and the actual media streams. This document is not concerned with
the mechanism (tunneling, translation) used for unicast adaptation,
but specifies the host-side multicast adaptation mechanism as part of
the proposed solution.
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. This document is
specifically interested in the border multicast adaptation function.
Tsou, et al. Expires August 1, 2011 [Page 3]
Internet-Draft Generic Multicast Translation January 2011
Note that when tunneling is used to carry IPvx traffic across the
provider network, the adaptation functions on the host and border
gateway sides of the provider network are complementary. As a
result, the border gateway has to implement a different adaptation
function for flows to and from IPvx hosts from what it implements
for flows to and from IPvy (i.e., native) hosts.
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).
+------------+ | | +------------+ |
| 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
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, 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 so it can do its job.
Tsou, et al. Expires August 1, 2011 [Page 4]
Internet-Draft Generic Multicast Translation January 2011
3. Proposed Solution
The proposed solution consists of three elements:
o a stateful mapping function (Mapper, in the rest of this document)
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 Mapper;
o a protocol that allows the HMAF and BMAF to request mappings from
the Mapper. 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
Mapper. The Mapper in turn checks whether it has 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.
Tsou, et al. Expires August 1, 2011 [Page 5]
Internet-Draft Generic Multicast Translation January 2011
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 Mapper to provide that mapping. The Mapper 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 Mapper so it can mark the IPvx address 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
translates the source and group addresses to IPvy using the mapping
it has retained from Step 4. It then forwards it to the next hop in
the multicast tree for that stream.
When the HMAF receives a multicast packet from the IPvy network, it
translates the packet to IPvx using the mapping which it has retained
from Step 2.
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
Tsou, et al. Expires August 1, 2011 [Page 6]
Internet-Draft Generic Multicast Translation January 2011
than the HMAF and BMAF.
Finally, if the IPvx Host emits multicast packets destined for an
any-source multicast group, the HMAF and BMAF translate the packets
from IPvx to IPvy and back again using the mappings they have
retained.
4. Mapping Request Protocol
To come.
5. Numerical Examples
5.1. 4-6-4 Example
This is an example for the scenario where an IPv4 host is trying to
acquire a multicast stream from an IPv4 network across an IPv6
network.
Assume that the Mapper has been assigned a pool of any-source
multicast (ASM) group addresses in the range FF38:38:2001:DB8:7F61:
1000:98FD::/112. For specific-source multicast (SSM), it has a pool
of source addresses in the range 2001:DB8:7F61:2000::/56 with
corresponding group addresses in the range FF38::98FD:/112. (In real
life the pool of source addresses would probably be smaller.)
Suppose now that the host wishes to receive the SSM multicast flow
<192.0.2.0, 234.192.0.2>. As documented in [RFC3376], the
application performs an IPMulticastListen socket operation to that
effect, which causes an IGMPv3 State-Change Report to be transmitted
carrying that information.
The HMAF intercepts the State-Change Report. Assuming it does not
already have a mapping for the SSM multicast flow <192.0.2.0,
234.192.0.2>, it sends a request to the Mapper. The Mapper checks
its set of allocated address pairs for SSM multicast flows, and
either finds that it has already mapped the requested pair or this is
a new mapping. In the first case, it returns the mapped IPv6
addresses it has already allocated. In the second case, it selects a
<Source, Group> address pair from its pool and records the mapping.
Suppose in the present example it returns the pair: <2001:DB8:7F61:
2000::7F, FF38::98FD:25>.
For comparison, the stateless mappings provided by the combination
of [RFC6052] for the source address and
[ID.boucadair-64-multicast] for the group identifier would provide
Tsou, et al. Expires August 1, 2011 [Page 7]
Internet-Draft Generic Multicast Translation January 2011
the mapping: <64:FF9B::192.0.2.0, FFB8:10::234.192.0.2>.
Continuing with our example, the HMAF interworks the IGMPv3 State-
Change Report to an MLDv2 [RFC3810] Multicast Listener Report
updating the set of multicast flows to which hosts served by the HMAF
instance are listening. The report includes the new Multicast
Address Record field with the multicast address FF38::98FD:25 and the
single multicast source 2001:DB8:7F61:2000::7F. The HMAF forwards
this message to the Provider IP Edge.
The Provider IP Edge updates its own multicast state tables, then
issues a PIM-SM [RFC4601] Join request to update the multicast tree
for the requested multicast flow. The PIM-SM Join request makes its
way through the IPv6 network, eventually reaching the BMAF. As
mentioned above, this could be because the border gateway containing
the BMAF was designated as a rendezvous point, or it could be through
some other method of routing configuration.
The BMAF recognizes that the PIM request relates to a mapped
multicast group. It first checks its own cache to see if it already
has the reverse mapping. If it does not, it sends a query to the
Mapper. The Mapper responds with the original address pair:
<192.0.2.0, 234.192.0.2>. The BMAF uses the returned reverse mapping
to update the PIM Join, then forwards it to the IPv4 network.
PIM-SM has subsequent phases in which it optimizes the distribution
tree and establishes the source filters, but these need not be
discussed. When content begins to flow from the IPv4 network, the
packets have source address 192.0.2.0 and destination address
234.192.0.2. The BMAF replaces these with source address 2001:DB8:
7F61:2000::7F and destination address FF38::98FD:25 from the mapping
that it has cached, and forwards the packets to the next hop(s) in
the multicast distribution tree for that flow.
When the packets arrive at the HMAF, it locates the corresponding
address mapping in its cache. It replaces the source address with
192.0.2.0 and the destination address with 234.192.0.2 and forwards
the packets to the host.
5.2. 6-4-6 Example
In this example, an IPv6 host is trying to access multicast content
from an IPv6 network across an IPv4 network. Given that the space of
multicast addresses permitted for examples is limited to three values
(derived from the three unicast /24s reserved for examples), we do
not specify the pools allocated to the Mapper, but assume that the
operator can provision it with an adequate number in practice.
Tsou, et al. Expires August 1, 2011 [Page 8]
Internet-Draft Generic Multicast Translation January 2011
From this point, the example proceeds as the 4-6-4 example, but (for
the example) with the numbers reversed.
1. The IPv6 host wishes to access an SSM flow with source 2001:DB8:
7F61:2000::7F and group identifier FF38::98FD:25. It sends an
MLDv2 Multicast Listener Report toward the HMAF indicating this.
2. The HMAF intercepts the MLDv2 message. If it does not already
have the mapping in its cache, it sends a request to the Mapper
indicating the IPv6 source and group. The Mapper allocates the
source address 192.0.2.0 and the SSM group address 234.192.0.2
from its pool. It retains the mapping for further use and
returns the result to the HMAF.
In the 6-4-6 case, no general stateless mapping method is
defined.
3. The HMAF interworks the MLDv2 Multicast Listener Report to an
IGMPv3 State-Change Report and forwards it to the Provider IP
Edge, including the IPv4 address pair returned by the Mapper.
4. The Provider IP Edge updates its own state tables, interworks the
IGMPv3 State-Change Request to a PIM-SM Join and forwards it.
5. Eventually the PIM request reaches the BMAF. The BMAF retrieves
the reverse mapping from its cache or from the Mapper. As a
result, it replaces the source address with
2001:DB8:7F61:2000::7F and the group identifier with
FF38::98FD:25. It converts the PIM message to IPv6 and forwards
it into the IPv6 network.
6. When packets of content arrive from the IPv6 network, they have
source address 2001:DB8:7F61:2000::7F and destination address
FF38::98FD:25. The BMAF retrieves the reverse mapping from its
cache and changes the packets to IPv4, with source address
192.0.2.0 and destination address 234.192.0.2. It forwards them
to the next hop(s) in the distribution tree.
7. When the packets reach the HMAF it retrieves the applicable
mapping from its cache and converts the packets backet to IPv6
with source address 2001:DB8:7F61:2000::7F and destination
address FF38::98FD:25. It forwards the packets toward the host.
6. Operational Considerations
The proposal presented here incurs the operational expense of
provisioning the multicast and unicast address pools at the mapping
Tsou, et al. Expires August 1, 2011 [Page 9]
Internet-Draft Generic Multicast Translation January 2011
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.
7. 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.
8. IANA Considerations
This memo currently includes no request to IANA.
9. Security Considerations
To come.
10. References
10.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.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Tsou, et al. Expires August 1, 2011 [Page 10]
Internet-Draft Generic Multicast Translation January 2011
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
10.2. Informative References
[ID.boucadair-64-multicast]
Boucadair, M., Qin, J., and Y. Lee, "IPv4-Embedded IPv6
Multicast Address Format", December 2010.
[ID.port-control-protocol]
Wing, D., "Port Control Protocol (PCP)", January 2011.
[ID.venaas-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator", December 2010.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
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
Tom Taylor
Huawei Technologies
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Phone: +1 613 680 2675
Email: tom111.taylor@bell.net
Tsou, et al. Expires August 1, 2011 [Page 11]
Internet-Draft Generic Multicast Translation January 2011
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 1, 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:04 |