| Internet Engineering Task Force | C. Zhou |
| Internet-Draft | T. Taylor |
| Intended status: Informational | Huawei Technologies |
| Expires: September 12, 2012 | J. Sun |
| China Telecom | |
| March 13, 2012 |
Specification of a Provider-Managed Adaptive Function Between a Multicast Receiver and a Provider Network Supporting a Different IP Version
draft-zhou-multrans-af1-specification-01
Discussion of the problem of multicast transition has brought out a number of scenarios that are the most likely to be encountered in practice. In some of these scenarios the IP version supported by the multicast receiver differs from that supported by the provider network to which it is attached. In such cases an adaptation function is required between the receiver and the network, to mediate the signalling and data flows between them. This memo uses the term "Type 1 Adaptation Function" (AF1) for such a function. It is written for the purpose of specifying the functions performed by an AF1.
The scope of this memo is limited to the case where flows are unidirectional, from a designated set of sources to a designated (and normally much more numerous) set of receivers. The IP television (IPTV) case falls within this scope.
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 12, 2012.
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 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.
Section 3 of [I.D_jaclee-mcast-ps] describes a number of network scenarios that can arise during the transition from IPv4 to IPv6. In some cases the multicast receiver supports a different IP version from the network to which it is attached. As a result, a dual-stack adaptation function, shown as AF1 in the figures of the cited text, is needed to mediate the flow of multicast signalling and content across the IP version boundary. This document specifies in detail what the AF1 does to achieve the multicast flow transmission from the media source to the receiver in the above scenarios.
This document restricts itself to scenarios involving flows of multicast content from sources to receivers, where the set of sources is distinct from the set of receivers. It is also restricted to scenarios where the node implementing the AF1 is managed by the provider rather than the customer. Subject to this restriction, both location of the AF1 in the customer network and location of the AF1 at the provider edge are considered.
If the AF1 is located at the provider edge, its role is straightforward. It serves as a multicast router terminating IGMP as specifed in [RFC3376], or terminating MLD as specified in [RFC3810]. The special aspect of the AF1 is that the network supports a different IP version from the incoming signalling from the receiver, so IGMP interworks with PIM/IPv6, and MLD interworks with PIM/IPv4.
[ID.perreault-igmp-mld-translation] specifies interworking between IGMP and MLD. Conceptually, IGMP can be interworked with MLD as an operation interior to the AF1, and then the MLD interworks with PIM/IPv6 in the usual fashion. Similarly, MLD incoming from the receiver can be interworked to IGMP, which then is interworked in the usual fashion with PIM/IPv4.
[ID.perreault-igmp-mld-translation] specifies the address mapping procedures that are required as part of the interworking. The address mappings used must be coordinated with other aspects of the multicast subscription process. As one example, the multicast group address (and source address if applicable) that are acquired by the receiver in advance of the request for a given multicast stream must obviously correspond to the desired stream after mapping. [I-D_tsou-addr-acquisition] discusses ways in which this can be brought about. There are also implications for routing and for further translations deeper into the network, but these are better reserved for another document (see [I-D_tsou-AF2-specification]).
If the AF1 is located on the customer premises, the situation for signalling is slightly simpler. Interworking is between IGMP and MLD in one direction or the other, and [ID.perreault-igmp-mld-translation] provides a complete specification. The same considerations on address mapping that were brought forward in the previous paragraph still apply.
Note that for MLD messages incoming from the AF1 to the network, [RFC3810] Section 7.6 requires that the source address in the packet header must be a valid link-local address on that link.
The AF1 role in data transfer is also straightforward, and is independent of the location of the AF1. The AF1 is configured either to translate the headers of incoming packets of multicast content from the sourece to the version supported by the receiver or to decapsulate these packets. This process is specified in [ID.perreault-igmp-mld-translation]. The address mappings used must be the reverse of those used for translation of the outbound signalling.
Encapsulation is clearly efficient in a scenario where the source and receiver support one IP version and the intervening network suppports another. However, encapsulation becomes operationally difficult when the network evolves to a mixture of IPv4 and IPv6 receivers. In that case, since the receivers cannot, without change, perform decapsulation themselves, it is necessary to have a vestigial AF1 function in front of all receivers. This vestigial function does not have to perform address mapping for the signalling and multicast content it processes, but does have to supply the missing decapsulation capability.
TBD.
Tina Tsou provided the framework within which these ideas were developed.
This memo includes no request to IANA.
To come.