One document matched: draft-zhou-multrans-af1-specification-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC3376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml">
<!ENTITY RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC4605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4605.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="info" docName="draft-zhou-multrans-af1-specification-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
     pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Multicast AF1 Specification">Specification of a Provider-Managed Adaptive Function Between a Multicast Receiver and a Provider Network Supporting a Different IP Version</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Cathy Zhou" initials="C."  surname="Zhou">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <code>518129</code>
          <country>P.R. China</country>
        </postal>
        <phone></phone>
        <email>cathy.zhou@huawei.com</email>
      </address>
    </author>
    
  <author initials="T." surname="Taylor" fullname="Tom Taylor">
  <organization>Huawei Technologies</organization>
  <address>
    <postal>
      <street>1852 Lorraine Ave.</street>
      <city>Ottawa</city>
      <region>Ontario</region>
      <country>Canada</country>
      <code>K1H 6Z8</code>
    </postal>
    <email>tom.taylor.stds@gmail.com</email>
  </address>
</author>

<author initials="J." surname="Sun" fullname="Jianping Sun">
	<organization>China Telecom</organization>
  <address>
	  <postal>
	    <street></street>
      <city></city>
      <region></region>
      <code></code>
      <country>P.R. China</country>
    </postal>
    <phone>+86 18918588708</phone>
    <email> sunjp@sttri.com.cn</email>
  </address>
</author>

    
    <date year="2012" />

    <!-- If the month and year are both specified and are the current ones,
    xml2rfc will fill in the current day for you. If only the current year is
    specified, xml2rfc will fill in the current day and month for you. If the
    year is not the current one, it is necessary to specify at least a month
    (xml2rfc assumes day="1" if not specified for the purpose of calculating
    the expiry date).  With drafts it is normally sufficient to specify just
    the year. -->

    <!-- Meta-data Declarations -->

    <area>Operations and Administration</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
   If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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.</t>
      
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Section 3 of <xref target="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.</t>
      
      <t>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.</t>

    </section>
    
  
     <section anchor="sigFnc" title="AF1 Role In Signalling">
 
       <t>If the AF1 is located at the provider edge, its role is straightforward.
       It serves as a multicast router terminating IGMP as specifed in 
       <xref target="RFC3376"/>, or terminating MLD as specified in 
       <xref target="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.</t>
       
       <t><xref target="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.</t>
       
       <t><xref target="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. 
       <xref target="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 <xref target="I-D_tsou-AF2-specification"/>).</t>
       
       <t>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 
       <xref target="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.</t>
         
       <t>Note that for MLD messages incoming from the AF1 to the network,
       <xref target="RFC3810"/> Section 7.6 requires that the source
       address in the packet header must be a valid link-local address on that
       link.</t>
       
     </section><!-- sigFnc -->
   
     
    <section anchor="dataFnc" title="AF1 Role In Data Transfer">
    
      <t>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 <xref target="ID.perreault-igmp-mld-translation"/>.
      The address mappings used must be the reverse of those used for translation
      of the outbound signalling. </t>
      
      <t>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.</t>
    
    </section><!-- dataFnc -->
    

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD.</t>
    </section>

    <section anchor="contrib" title="Contributors">
      <t>Tina Tsou provided the framework within which these ideas were developed.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
    
      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>To come.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Informative References">
    
      <reference anchor="I.D_jaclee-mcast-ps">
         <front>
          <title>IPv4-IPv6 Multicast: Problem Statement and Use Cases</title>
          <author initials="C." surname="Jacquenet" fullname="C. Jacquenet">
            <organization>France Telecom</organization>
          </author>
          <author initials="M." surname="Boucadair" fullname="M. Boucadair">
            <organization>France Telecom</organization>
          </author>
          <author initials="Y." surname="Lee" fullname="Y. Lee">
            <organization>Comcast</organization>
          </author>
          <author initials="J." surname="Qin" fullname="J. Qin">
            <organization>ZTE</organization>
          </author>
          <author initials="T." surname="Tsou" fullname="T. Tsou">
            <organization>Huawei Technologies (USA)</organization>
          </author>
          <date month="October" year="2011"/>
        </front>
      </reference>
     
      <reference anchor="ID.perreault-igmp-mld-translation">
         <front>
          <title>Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation ("IGMP/MLD Translation") (Work in progress)</title>
           <author initials="S." surname="Perrault" fullname="S. Perrault">
             <organization>Viagenie</organization>
           </author>
           <author initials="T." surname="Tsou" fullname="T. Tsou">
             <organization>Huawei Technologies (USA)</organization>
           </author>
           <date month="February" year="2012"/>
         </front>
       </reference>
     
     
     <reference anchor="I-D_tsou-addr-acquisition">
      <front>
         <title>Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions (Work in progress)</title>
        <author initials="T." surname="Tsou" fullname="T. Tsou">
          <organization>Huawei Technologies (USA)</organization>
        </author>
        <author initials="A." surname="Clauberg" fullname="A. Clauberg">
          <organization>Deutsche Telekom</organization>
        </author>
        <author initials="M." surname="Boucadair" fullname="M. Boucadair">
          <organization>France Telecom</organization>
        </author>
        <author initials="S." surname="Venaas" fullname="S. Venaas">
          <organization>Cisco Technologies</organization>
        </author>
        <author initials="Q." surname="Sun" fullname="Q. Sun">
          <organization>China Telecom</organization>
        </author>
        <date month="March" year="2012"/>
      </front>
    </reference>
    
     <reference anchor="I-D_tsou-AF2-specification">
      <front>
         <title>Specification of an Adaptation Function Between Two Multicast Networks Supporting Different IP Versions</title>
        <author initials="T." surname="Taylor" fullname="T. Taylor">
          <organization>Huawei Technologies</organization>
        </author>
        <date month="December" year="2011"/>
      </front>
    </reference>
    
     &RFC3376;
     &RFC3810;
     &RFC4605;
     &RFC6052;
     
    </references>

  </back>
</rfc>