One document matched: draft-fairhurst-ipdvb-ule-iana-06.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-fairhurst-ipdvb-ule-iana-06"
     ipr="trust200902" obsoletes="" updates="4326">
  <!-- Updates SDP -->

  <?rfc toc="yes"?>

  <!-- generate a table of contents -->

  <?rfc symrefs="yes"?>

  <!-- use anchors instead of numbers for references -->

  <?rfc sortrefs="yes" ?>

  <!-- alphabetize the references -->

  <?rfc compact="yes" ?>

  <!-- conserve vertical whitespace -->

  <?rfc subcompact="no" ?>

  <!-- but keep a blank line between list items -->

  <front>
    <title abbrev="IANA ULE guidelines">IANA Guidance for Managing the ULE
    Next-Header Registry</title>

    <author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
      <organization>University of Aberdeen</organization>

      <address>
        <postal>
          <street>School of Engineering</street>

          <street>Fraser Noble Building</street>

          <city>Aberdeen</city>

          <region>Scotland</region>

          <code>AB24 3UE</code>

          <country>UK</country>
        </postal>

        <email>gorry@erg.abdn.ac.uk</email>

        <uri>http://www.erg.abdn.ac.uk</uri>
      </address>
    </author>

    <date day="6" month="March" year="2014" />

    <area>Transport</area>

    <workgroup>IPDVB Working Group</workgroup>

    <keyword>ULE</keyword>

    <keyword>IANA</keyword>

    <abstract>
      <t>This document proposes an update to RFC 4326 to clarify and update
      the allocation rules for the Unidirectional Lightweight Encapsulation
      (ULE) Next-Header registry. This registry is used by ULE and Generic
      Stream Encapsulation (GSE) to record the code points of extension
      headers and protocols supported by these encapsulation protocols.</t>
    </abstract>
  </front>

  <middle>
    <!-- text starts here -->

    <section title="Introduction" toc="include">
      <t>The Unidirectional Lightweight Encapsulation (ULE) <xref
      target="RFC4326"></xref> specifies an encapsulation for links that
      employ the MPEG-2 Transport Stream, with support over a wide variety of
      physical-layer bearers <xref target="RFC4259"></xref>. The encapsulation
      header includes a Type field that identifies payload types and extension
      headers (e.g.<xref target="RFC5163"> </xref>). The ULE specification
      requested IANA to maintain the ULE next header registries to record the
      allocation of the values used to derive this Type field.</t>

      <t>The Digital Video Broadcast (DVB) Project has published an
      encapsulation for second-generation DVB physical layers. This specifies
      the Generic Stream Encapsulation <xref target="GSE"></xref>. This
      encapsulation shares many of the network properties of ULE and uses a
      common format for the Type field <xref target="RFC5163"></xref>. The ULE
      Next Header registries are therefore also applicable to this
      encapsulation.</t>

      <t>This document updates the IANA rules and guidance defined in section
      11.1 of <xref target="RFC4326"></xref> in the following way:</t>

      <t><list style="symbols">
          <t>The document clarifies use of the ULE Next-Header registry by GSE
          as well as for ULE.</t>

          <t>Section 3 specifies that new allocations in the ULE Next-Header
          registry are to be assigned by IANA using the "Expert Review" policy
          and provides guidance to the expert reviewer.</t>

          <t>Section 3.3 reserves a range of allocated values.</t>

          <t>Section 4 adds an explanatory note to clarify the encoding used
          in the ULE Next-Header registry.</t>
        </list></t>
    </section>

    <section title="Terminology" toc="include">
      <t>This document assumes familiarity with the terminology of ULE <xref
      target="RFC4326"></xref> and <xref target="RFC5163"></xref>.</t>

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"></xref>.</t>

      <section title="The ULE Next Header Registries">
        <t>The mandatory extension headers are allocated in the ULE Next
        Header registry with decimal values in the range 0-255. The registered
        value corresponds to the 16-bit Type value for the mandatory extension
        header or to identify a specific protocol.</t>

        <t>The optional extension headers are allocated in the ULE Next Header
        registry with decimal values in the range 256-511. The registered
        value corresponds to the 16-bit Type value that would be used for an
        optional extension header with a length (H-LEN) of 1.</t>
      </section>

      <section title="Informative example of using a value from the optional range">
        <t>This section provides an informative example of how a registry
        entry is constructed to identify an optional ULE extension header.</t>

        <t>Values registered by IANA in the optional ULE extension header
        range correspond to a 16-bit Type value with the H-LEN field (in bits
        5 to 7) set to a decimal value of 1. This registration format is used
        irrespective of the H-LEN value to be used. Bits 8 to 15 of the value
        in the registry are combined with the actual required H-LEN value
        (bits 5 to 7) to form the 16-bit Type field.</t>

        <t>For example, the decimal value 256 has been allocated to denote the
        padding extension header.</t>

        <t><list style="symbols">
            <t>Type value 256: When a 2-byte padding extension header is used,
            the H-LEN is 1, resulting in a Type value with a decimal value of
            256 (as allocated), corresponding to a hexadecimal value of
            0x100.</t>

            <t>Type value 768: When a 6-byte padding extension header is used,
            the H-LEN is 3, resulting in a Type value with a decimal value of
            768, corresponding to a hexadecimal value of 0x300.</t>
          </list></t>
      </section>
    </section>

    <section title="Updated IANA guidance on allocation in the ULE Next Header Registry"
             toc="include">
      <t>The rules for allocation were defined in section 11 of <xref
      target="RFC4326"></xref>. This document updates these rules by replacing
      them with the rules in this section:</t>

      <t>Allocations in the ULE Next-Header Registry are to be assigned by
      IANA using the "Expert Review" policy defined in <xref
      target="RFC5226"></xref>. Applications must include a reference to a
      specification of the next header extension in a standards document. An
      IETF standards-track RFC can provide such a reference. Other
      specifications are also permitted. The expert shall advise IANA on
      whether a particular specification constitutes a standards document.</t>

      <section title="ULE Next-Header Registry ">
        <t>This registry allocates Next-Header values within the range 0-511
        (decimal). For each allocated value, it also specifies the set of
        allowed H-LEN values (see <xref target="RFC4326"></xref> section 5).
        The combination of the IANA-registered value and the H-LEN are used by
        ULE and GSE to derive a set of allowed 16-bit values in the decimal
        range 0-1535. This forms the first part of the ULE Type space (see
        <xref target="RFC4326"></xref> section 4.4.1).</t>
      </section>

      <section title="IANA Guidelines">
        <t>The following contains the IANA guidelines for management of the
        ULE Next-Header registry. This registry allocates decimal values 0-511
        (0x0000-0x01FF, hexadecimal). IANA MUST NOT allocate values greater
        than 511 (decimal).</t>

        <t>The ULE Next-Header registry is divided into two ranges:</t>

        <t><list style="numbers">
            <t>0-255 (decimal) IANA-assigned values, indicating Mandatory
            Extension Headers (or link-dependent Type fields). Requests for
            assignment in this range MUST define the value and the name
            associated with the Extension Header, together with the procedure
            for processing the Extension Header. This MUST also define the
            need for the Mandatory Extension and the intended use. <xref
            target="RFC4326"></xref> made initial assignments to this range of
            values in the registry, updated by later requests. The size of the
            Extension Header MUST be specified (by default the entire
            remaining payload).</t>

            <t>256-511 (decimal) IANA-assigned values, indicating Optional
            Extension Headers. Requests for assignment in this range MUST
            define the value and the name associated with the Extension
            Header, together with the procedure for processing the Extension
            Header. The entry MUST specify the range of allowable H-LEN values
            that are permitted (in the range 1-5). It MUST also define the
            need for the Optional Extension and the intended use. <xref
            target="RFC4326"></xref> made initial assignments to this range of
            values in the registry, updated by later requests.</t>
          </list></t>
      </section>

      <section title="Reservation of Next Header values for Private Use">
        <t>This document reserves the range decimal 144-159 (0x80-0x8F,
        hexadecimal) for Private Use.</t>

        <t>These values are not available for allocation by IANA. Appropriate
        use includes development of experimental options for which either no
        general-purpose solution was planned, where insufficient operational
        experience was available to understand if a general solution is
        needed, or where a more general solution is not yet mature. This use
        is not coordinated between users of these values, so the uniqueness of
        a particular value can not be guaranteed.</t>

        <t>Authors of specifications (see Section 3.0) SHOULD contact IANA to
        request a new value to be allocated in the ULE Next-Header registry.
        An IANA-allocated value uniquely identifies the method. Such an
        allocation is REQUIRED for any method that is to be standardised.</t>
      </section>
    </section>

    <section title="Update to registry information" toc="default">
      <t>This section requests IANA to record an additional explanatory note
      in the ULE Next-Header registry:</t>

      <t>"The Mandatory Extension Header range in the ULE Next-Header registry
      is used to allocate values in the range 0-255 (decimal). These values
      are used to identify mandatory extension headers. The registered value
      corresponds to the 16-bit Type value for the mandatory extension header
      or the specified protocol.</t>

      <t>The Optional Extension Header range in the ULE Next-Header registry
      is used to allocate values in the range 256-511 (decimal). These values
      are used to identify optional extension headers. The registered value
      corresponds to the 16-bit Type value that would be used for an optional
      extension header with a header length (H-LEN) of 1."</t>

      <t>This additional note should be placed before the current note.</t>
    </section>

    <section title="Security Considerations" toc="default">
      <t>This document does not present new security considerations.</t>
    </section>

    <section title="IANA Considerations" toc="include">
      <t>Section 3 specifies updated IANA allocation rules</t>

      <t>Section 3.3 requests IANA to reserve the range decimal 144-159
      (0x80-0x8F, hexadecimal) and to mark this as Reserved for Private
      Use.</t>

      <t>Section 4 requests IANA to update the ULE Next-Header registry
      information.</t>
    </section>

    <section title="Acknowledgments">
      <t>The author acknowledges feedback from IANA, Thomas Narten, Margaret
      Wasserman, and Wes Eddy and the IETF Gen-ART team. Helpful reviews and
      comments were also received from Alexander Adolf and Hans-Peter Lexow on
      usage of this registry.</t>
    </section>

    <section title="Revision Notes">
      <t>RFC-Editor: Please remove this section prior to publication</t>

      <t>Draft 00</t>

      <t>This was the first revision - it proposed the requested update.</t>

      <t>Draft 01</t>

      <t>This revision is thought complete and replaces the entire IANA
      section with the new text.</t>

      <t>Draft 02</t>

      <t>Section 1 includes an overview of the changes from RFC 4326,
      requested by Margaret Wasserman.</t>

      <t>Draft 03</t>

      <t>Reworded section 3.1 to clarify difference between registered value
      and derived Type field value, requested by Michelle Cotton.</t>

      <t>Clarified each value as being decimal or hexadecimal.</t>

      <t>Draft 04</t>

      <t>No changes made, this draft was updated ready for submission to the
      Area Director.</t>

      <t>Draft 05</t>

      <t>Updated discussion of the private address range, and how this should
      be used. Fixed NiT in intro, now correctly indicating range:
      256-511.</t>

      <t>Draft 06</t>

      <t>Update to incorporate Gen-ART review feedback and LC comments from
      Alexander Adolf with a suggested informative example.</t>
    </section>
  </middle>

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

  <back>
    <!-- -->

    <references title="Normative References">
      <?rfc sortrefs="yes"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4326.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5163.xml"
?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"?>

      <reference anchor="GSE">
        <front>
          <title>Digital Video Broadcasting (DVB); Generic Stream
          Encapsulation (GSE) Protocol</title>

          <author fullname="TS 102 606">
            <organization>European Telecommunication Standards, Institute
            (ETSI)</organization>
          </author>

          <date year="2007" />
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4259.xml"?>
    </references>
  </back>
</rfc>