Multicast Transition Overview
draft-eubanks-mboned-transition-overview-01

Abstract

The transition from IPv4 to IPv6 raises issues for multicast signaling and multicast content distribution. This memo describes the problem and briefly surveys the solution space.

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 03, 2012.

Copyright Notice

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.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. A Look At the Multicast Transition Problem Space
• 3. Requirements
• 4. A Look At the Solution Space For Multicast Transition
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• Authors' Addresses

1. Introduction

The transition from IPv4 to IPv6 presents challenges for the operation of multicast networks. In particular, different versions of IP may be available along the path between the source and the receivers. Also some nodes may support only IPv4, and some only IPv6. This may be true for both unicast and multicast. Additionally, for a given source, the desired receivers may have different requirements. [ID.jaclee-behave-v4v6-mcast-ps] illustrates the different end-to-end configurations that can occur during transition (and identifies the most likely ones) while exploring the problem of multicast transition for IPTV applications in particular. The reason that that draft concentrates on IPTV is that this application is encountering multicast transition issues in the present and these are likely to intensify in the near future.

In this document, "multicast transition" will specifically refer to transitions between IPv4 and IPv6 or vice versa, including networks with multiple transitions say from IPv4 to IPv6 and back to IPv4, and a "multicast domain" will refer to a network or sub-network supporting one or both variants of Internet multicast. Note that networks may support both versions of the Internet protocol without supporting multicast in both versions, and so multicast transitions may be required even in cases where end-to-end unicast transport is supported.

The present memo provides a quick survey of the problem space and the possible solutions, as an aid to further discussion of the topic of multicast transition.

1.1. Requirements Language

This document contains no requirements language.

2. A Look At the Multicast Transition Problem Space

As [ID.jaclee-behave-v4v6-mcast-ps] points out, in common practice multicast video transport actually happens in three stages. First, the receiver has to acquire the address(es) that it needs to request a particular multicast stream. It always needs to learn the multicast group address or addresses. Both any-source multicast (ASM) and specific-source multicast (SSM) support are necessary with these transitional mechanisms. Due to the wide deployment of IGMPv2-only CPEs and ASM-only applications, ASM support is required. If source-specific multicast (SSM) is deployed, the receiver also needs to learn the associated unicast source address for each multicast group address. Existing arrangements to support this acquisition process will in some cases need modification to ensure that the receiver acquires the address(es) in the IP version that it understands.

Following address acquisition, the receiver uses multicast signaling to request delivery of the user-selected multicast stream or streams. The key issue at this stage is that each time the multicast signaling crosses a boundary between a network supporting one IP version and a network supporting the other, the address(es) designating the requested multicast stream need to be remapped to the new version. This is required in all case for the group addresses, and also for unicast source addresses for SSM. In addition, in the particular case where there is a transition at the receiver itself, protocol interworking between IGMP ([RFC2236], [RFC3376], [RFC5790]) and MLD ([RFC2710], [RFC3810], and again [RFC5790]) may be necessary. Even in the case where the receiver shares a link with a (dual stack) multicast router, such interworking may be considered to occur internally in the multicast router as an intermediate step.

The creation of multicast trees in response to multicast signaling relies on the use of reverse path forwarding (RPF) to avoid the creation of routing loops; this is also required in networks performing transitions between multicast domains. In the face of address remapping, it has been suggested that each network along the path from source to receiver needs to know the ultimate source address for RPF to work. In any event, one of the challenges presented by multicast transition is to find a way to avoid routing loops without requiring end to end source discovery.

The final stage of multicast acquisition is the actual delivery of packets of multicast content, i.e., the flooding of data down the multicast trees. Again, address mapping is required across each IP version boundary. Both the unicast source and multicast group addresses appearing in the packet header in one network must be replaced by corresponding source and group addresses in the other IP version before the packet can be forwarded for its next stage of travel. That means that unicast mapping is always required, even in the absence of SSM. It may be advantageous to coordinate this mapping for multicast packets with the mapping used for unicast traffic.

Address remapping across IP version boundaries is required in all three stages of acquisition of a multicast stream. [ID.venaas-behave-v4v6mc-framework] examines the issue of translation between IPv4 and IPv6 multicast addresses in various scenarios. In many cases of practical interest, stateless mapping is possible.

A key point is that address mapping requires coordination both in space and in time. To ensure that the multicast stream requested is the one delivered, the same address(es), or a unique mapping of those addresses, must be used to designate the stream at any given point, whether at the stage of address acquisition, multicast signaling, or multicast content delivery. Moreover, coordination between successive multicast domains in the path is required to ensure that the address(es) requested by the receiver are mapped in the source network to the stream that the user wishes to acquire. In stateless mapping, the network must ensure that two streams that might be requested by a given user are not given the same address(es) at the same time; this is more difficult when transitioning into an IPv4 domain given the smaller range of address space available in IPv4.

In some unicast transition scenarios, part of the solution is to use dual stack networks. However, if the same stream is broadcast as both IPv4 and IPv6 packets, bandwidth consumption to carry that stream increases substantially. Some operators will thus choose to transmit multicast content through the network in just one IP version, even if the network implements dual stack for unicast traffic. Technically, the same consideration does not apply to multicast signaling, but address remapping is unavoidable even so.

3. 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.

4. A Look At the Solution Space For Multicast Transition

Consistently with the problem space overview, the multicast transition problem divides naturally into three parts:

1. providing a multicast group and possibly unicast source address to the receiver in the IP version supported by the receiver;
2. mediating the exchange of multicast signaling and content between the receiver and its network when the two support different IP versions;
3. mediating the exchange of multicast signaling and content between two networks supporting different IP versions along the path between the source and the receiver.

Problem 1 is addressed in [ID.tsou-multrans-addr-acquisition]. In the IPTV case, the key element in the solution for address acquisition (discovery or announcement) is the processing of the electronic program guide (EPG) that provides the receiver with the multicast group and possibly the unicast source addresses it needs to request specific program instances. Three possible strategies are considered:

• recognition and conversion of unsupported-IP-version addresses at the receiver after it receives the EPG, through a protocol exchange with a mapping function in the network;
• interception and remapping of addresses in the EPG as necessary by the network to which the receiver is attached, before the receiver receives information from the EPG;
• administrative modification of the EPG in advance of acquisition, either to provide the specific version required by each receiver or to carry addresses in both versions in a form that allows the receiver to select the version it supports.

Problem 2 is addressed in [ID.zhou-multrans-af1-specification]. That draft uses the term "Type 1 Adaptation Function" (AF1) for a mediating function between the receiver and the network. This function has two parts: translating the multicast access signaling (IGMP or MLD) to the signaling appropriate to the other IP version (MLD or IGMP respectively), and modifying incoming packets of content to the version supported by the receiver. These packets may need either header translation or decapsulation, depending on the deployment. Difficulties in evolution of the decapsulation option with the transition to all-IPv6 operation are noted.

Problem 3 is addressed in [ID.taylor-multrans-af2-specification]. Here the term "Type 2 Adaptation Function" (AF2) is used for the function required. Again, this function operates both on multicast signaling and multicast content. On the signaling side, the function maps the addresses contained in PIM messages from one IP version to the other. With respect to content, depending on deployment, the AF2 either encapsulates or translates the headers of incoming packets of multicast content before forwarding them toward the receiver.

A basic tool required for all of these problems is a method to map consistently between IPv4 and IPv6 versions of the source and group addresses. [RFC6052] provides the necessary mapping for the unicast source addresses, if present. [ID.boucadair-behave-64-multicast-address-format] provides a stateless solution for the mapping between IPv4 and IPv6 multicast addresses.

[ID.softwire-dslite-multicast] is essentially an applicability statement, showing the application of the AF1, AF2, and address mapping to the particular case where DS-Lite is deployed. AF1 is located in the "multicast B4" (mB4), along with the unicast DS-Lite B4 function, at the customer edge. AF2 is located in the "multicast AFTR" at the border between the IPv6 network to which the customer is attached and the IPv4 network containing the source. The draft specifies the use of encapsulation of multicast content across the IPv6 network.

[ID.xu-softwire-mesh-multicast] deals with the particular case where a multicast-capable network provides a transit service between other multicast-capable networks of differing IP versions. Its interaction with the proposed AF2 functionality requires further study.

5. Acknowledgements

Ron Bonica inspired the writing of this memo and shaped its content. Michael McBride inspired the text regarding dual stack networks and added some text regarding the need for ASM support in Section 2.

6. IANA Considerations

This memo includes no request to IANA.

7. Security Considerations

To come.

8. References

Authors' Addresses