Internet Engineering Task Force C. Zhou
Internet-Draft T. Taylor
Intended status: Informational Huawei Technologies
Expires: June 18, 2012 December 15, 2011
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-00
Abstract
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.
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 June 18, 2012.
Copyright Notice
Zhou & Taylor Expires June 18, 2012 [Page 1]
Internet-Draft Multicast AF1 Specification December 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. AF1 Role In Signalling . . . . . . . . . . . . . . . . . . . . 3
2.1. The Case Of the Customer-Located AF1 . . . . . . . . . . . 4
3. AF1 Role In Data Transfer . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Informative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Zhou & Taylor Expires June 18, 2012 [Page 2]
Internet-Draft Multicast AF1 Specification December 2011
1. Introduction
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.
1.1. Requirements Language
This document contains no requirements language.
2. AF1 Role In Signalling
If the AF1 is located at the provider edge, its role is
straightforward. It serves as a multicast router terminating IGMP as
specified in [RFC3376], or terminating MLD as specified in [RFC3810].
The one special operation performed by AF1 is to map source and group
addresses received from receivers supporting a different IP version
into the IP version used by the network before entering them into its
group management database or propagating them in messages to other
network multicast routers. It performs the reverse mapping for
outgoing messages to the receiver.
The mapping used is the same as that used to derive the source and
group addresses sent to the receiver in advance of program selection
by the user. Advance address acquisition by the receiver is
discussed in a companion document, [I-D_tsou-addr-acquisition]. The
mapping may also underly the creation of the multicast routing
tables, as discussed in another companion document,
[I-D_tsou-AF2-specification]. For the cases of immediate interest,
it is likely that a stateless mapping can be used, for example,
[I-D_boucadair-stateless-multicast] for the multicast group addresses
and [RFC6052] for source addresses.
Zhou & Taylor Expires June 18, 2012 [Page 3]
Internet-Draft Multicast AF1 Specification December 2011
2.1. The Case Of the Customer-Located AF1
If the AF1 is located on the customer premises, the situation for
signalling is slightly more complicated. The AF1 will use a
multicast signalling protocol (IGMP or MLD or possibly PIM) to send
the multicast request into the network. It terminates messages of
another protocol (MLD or IGMP) from the receiver (e.g., STB). The
multicast request sent by AF1 to the network will include the source
and group addresses converted by AF1.
If the AF1 signals PIM toward the network, the situation is as
described above for an AF1 located at the provider edge. If it
terminates IGMP from the receiver and signals MLD to the network or
vice versa, it acts as an IGMP (respectively MLD) proxy [RFC4605] to
the receiver. From the point of view of the network, the AF1 is an
MLD or IGMP receiver, respectively. In passing from one of these
roles to the other, the AF1 has to map the multicast source and group
addresses as already discussed.
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.
3. AF1 Role In Data Transfer
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 source to the version supported by the receiver or to
decapsulate these packets.
Encapsulation is clearly efficient in a scenario where the source and
receiver support one IP version and the intervening network supports
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.
4. Acknowledgements
TBD.
Zhou & Taylor Expires June 18, 2012 [Page 4]
Internet-Draft Multicast AF1 Specification December 2011
5. Contributors
Tina Tsou provided the framework within which these ideas were
developped.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
To come.
8. Informative References
[I-D_boucadair-stateless-multicast]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format",
October 2011.
[I-D_tsou-AF2-specification]
Taylor, T. and C. Zhou, "Specification of an Adaptation
Function Between Two Multicast Networks Supporting
Different IP Versions", December 2011.
[I-D_tsou-addr-acquisition]
Tsou, T., "Address Acquisition For Multicast Content When
Source and Receiver Support Differing IP Versions",
December 2011.
[I.D_jaclee-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use
Cases", October 2011.
[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.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
Zhou & Taylor Expires June 18, 2012 [Page 5]
Internet-Draft Multicast AF1 Specification December 2011
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
Authors' Addresses
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: tom.taylor.stds@gmail.com
Zhou & Taylor Expires June 18, 2012 [Page 6]