[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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


   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

   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

   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


5.  Contributors

   Tina Tsou provided the framework within which these ideas were

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

              Taylor, T., "Specification of an Adaptation Function
              Between Two Multicast Networks Supporting Different IP
              Versions", December 2011.

              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.

              Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
              Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use
              Cases", October 2011.

              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

   Email: cathy.zhou@huawei.com

   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave.
   Ottawa, Ontario  K1H 6Z8

   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]