One document matched: draft-fairhurst-ipdvb-ule-iana-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-fairhurst-ipdvb-ule-iana-01a"
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
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="9" month="May" year="2013" />
<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 codepoints 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 construct 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>
</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>
<t></t>
<section title="The ULE Next Header Registries">
<t>The Mandatory Extension Headers registry allocates values in the
range 0-255. 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 Headers registry allocates values in the
range 256-512. 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 length
(H-LEN) of 1.</t>
</section>
</section>
<section title="Updated IANA guidance on allocation in the ULE Next Header Registry"
toc="include">
<t>The rules for allocation are defined in section 11 of <xref
target="RFC4326"></xref>. This document updates these rules by replacing
these, replacing these 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 for registration are expected to
include a reference to a published 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).
In combination, these define a set of allowed values in the range
0-1535 for 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 values 0-511 decimal
(0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater than
0x01FF (decimal). It</t>
<t>The Next-Header registry is divided into two areas: </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 area 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 registry
updated by later requests.</t>
<t>256-511 (decimal) IANA-assigned values, indicating Optional
Extension Headers. Requests for assignment in this area 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 registry
updated by later requests. </t>
</list></t>
</section>
<section title="Reservation of Next Header values">
<t>This document reserves the range decimal 144-159 (0x80-0x8F). These
reserved values are presently not available for general assignment,
and will not be allocated until the registry is exhausted.</t>
</section>
</section>
<section title="Update to registry information" toc="default">
<t>This section requests IANA to record additional explanatory note in
the registry:</t>
<t>"The Mandatory Extension Headers registry allocates values in the
range 0-255. 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 Headers registry allocates values in the range
256-512. 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 length (H-LEN) of 1."</t>
</section>
<section title="Security Considerations" toc="include">
<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 4 requests IANA to update the registry information.</t>
</section>
<section title="Acknowledgments">
<t>The author acknowledges feedback from IANA, Alexander Adolf and
Hans-Peter Lexow on usage of this registry.</t>
<t><!----></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>
</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>
| PAFTECH AB 2003-2026 | 2026-04-23 21:43:43 |