Internet DRAFT - draft-zhou-multrans-af1-specification
draft-zhou-multrans-af1-specification
Internet Engineering Task Force C. Zhou
Internet-Draft T. Taylor
Intended status: Informational Huawei Technologies
Expires: September 14, 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
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 September 14, 2012.
Zhou, et al. Expires September 14, 2012 [Page 1]
Internet-Draft Multicast AF1 Specification March 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AF1 Role In Signalling . . . . . . . . . . . . . . . . . . . . 3
3. AF1 Role In Data Transfer . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Informative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Zhou, et al. Expires September 14, 2012 [Page 2]
Internet-Draft Multicast AF1 Specification March 2012
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.
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
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]).
Zhou, et al. Expires September 14, 2012 [Page 3]
Internet-Draft Multicast AF1 Specification March 2012
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.
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 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.
4. Acknowledgements
TBD.
5. Contributors
Tina Tsou provided the framework within which these ideas were
developed.
Zhou, et al. Expires September 14, 2012 [Page 4]
Internet-Draft Multicast AF1 Specification March 2012
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
To come.
8. Informative References
[I-D_tsou-AF2-specification]
Taylor, T., "Specification of an Adaptation Function
Between Two Multicast Networks Supporting Different IP
Versions", December 2011.
[I-D_tsou-addr-acquisition]
Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q.
Sun, "Address Acquisition For Multicast Content When
Source and Receiver Support Differing IP Versions (Work in
progress)", March 2012.
[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.
[ID.perreault-igmp-mld-translation]
Perrault, S. and T. Tsou, "Internet Group Management
Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based
Multicast Translation ("IGMP/MLD Translation") (Work in
progress)", February 2012.
[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
("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,
Zhou, et al. Expires September 14, 2012 [Page 5]
Internet-Draft Multicast AF1 Specification March 2012
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
Jianping Sun
China Telecom
P.R. China
Phone: +86 18918588708
Email: sunjp@sttri.com.cn
Zhou, et al. Expires September 14, 2012 [Page 6]
