IANA Guidance for Managing the ULE
Registry
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
Scotland
AB24 3UE
UK
gorry@erg.abdn.ac.uk
http://www.erg.abdn.ac.uk
Transport
IPDVB Working Group
ULE
IANA
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.
The Unidirectional Lightweight Encapsulation (ULE) specifies an encapsulation for links that
employ the MPEG-2 Transport Stream, with support over a wide variety of
physical-layer bearers . The encapsulation
header includes a Type field that identifies payload types and extension
headers (e.g. ). 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.
The Digital Video Broadcast (DVB) Project has published an
encapsulation for second-generation DVB physical layers. This specifies
the Generic Stream Encapsulation . This
encapsulation shares many of the network properties of ULE and uses a
common format for the Type field . The ULE
Next Header registries are therefore also applicable to this
encapsulation.
This document updates the IANA rules and guidance defined in section
11.1 of in the following way:
The document clarifies use of the registry by GSE as well as for
ULE.
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.
Section 3.3 reserves a range of allocated values.
Section 4 adds an explanatory note to clarify the encoding used
in the registry.
This document assumes familiarity with the terminology of ULE and .
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 .
The Mandatory Extension Headers registry allocates decimal 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.
The Optional Extension Headers registry allocates decimal 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.
The rules for allocation were defined in section 11 of . This document updates these rules by replacing
these with the rules in this section:
Allocations in the ULE Next Header Registry are to be assigned by
IANA using the "Expert Review" policy defined in . 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.
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 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
section 4.4.1).
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).
The Next-Header registry is divided into two areas:
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. made initial assignments to this registry
updated by later requests. The size of the Extension Header MUST
be specified (by default the entire remaining payload).
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. made initial assignments to this registry
updated by later requests.
This document reserves the range decimal 144-159 (0x80-0x8F,
hexadecimal). These reserved values are presently not available for
general assignment, and will not be allocated until the registry is
exhausted.
This section requests IANA to record additional explanatory note in
the registry:
"The Mandatory Extension Headers registry allocates 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.
The Optional Extension Headers registry allocates 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."
This additional note should be placed before the current note.
This document does not present new security considerations.
Section 3 specifies updated IANA allocation rules
Section 4 requests IANA to update the registry information.
The author acknowledges feedback from IANA, Alexander Adolf and
Hans-Peter Lexow on usage of this registry.
RFC-Editor: Please remove this section prior to publication
Draft 00
This was the first revision - it proposed the requested update.
Draft 01
This revision is thought complete and replaces the entire IANA
section with the new text.
Draft 02
Section 1 includes an overview of the changes from RFC 4326,
requested by Margaret Wasserman.
Draft 03
Reworded section 3.1 to calrify difference between registered value
and derived Type field value, requested by Michelle Cotton.
Clarified each value as being decimal or hexadecimal.
Draft 04
No changes made, this draft was updated ready for submission to the
Area Director.
Digital Video Broadcasting (DVB); Generic Stream
Encapsulation (GSE) Protocol
European Telecommunication Standards, Institute
(ETSI)