One document matched: draft-zhou-multrans-af1-specification-00.txt

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]