GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7280

Internet Engineering Task Force (IETF) G. Fairhurst Request for Comments: 7280 University of Aberdeen Updates: 4326 June 2014 Category: Standards Track ISSN: 2070-1721

                     IANA Guidance for Managing

the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry

Abstract

 This document updates 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.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7280.

Copyright Notice

 Copyright (c) 2014 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.

Fairhurst Standards Track [Page 1] RFC 7280 IANA ULE Guidelines June 2014

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.1.  The ULE Next-Header Registry  . . . . . . . . . . . . . .   3
   2.2.  Informative Example of Using a Value from the Optional
         Range . . . . . . . . . . . . . . . . . . . . . . . . . .   3
 3.  Updated IANA Guidance on Allocation in the ULE Next-Header
     Registry  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.1.  ULE Next-Header Registry  . . . . . . . . . . . . . . . .   4
   3.2.  Expert Review Guidelines  . . . . . . . . . . . . . . . .   5
   3.3.  Reservation of Next-Header Values for Private Use . . . .   5
 4.  Update to Registry Information  . . . . . . . . . . . . . . .   6
 5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
 6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
 7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
 8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
   8.2.  Informative References  . . . . . . . . . . . . . . . . .   7

1. Introduction

 The Unidirectional Lightweight Encapsulation (ULE) [RFC4326]
 specifies an encapsulation for links that employ the MPEG-2 Transport
 Stream, with support over a wide variety of physical-layer bearers
 [RFC4259].  The encapsulation header includes a Type field that
 identifies payload types and Extension Headers (e.g., [RFC5163]).
 The ULE specification requested IANA to maintain the ULE Next-Header
 registry 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 [GSE].  This encapsulation
 shares many of the network properties of ULE and uses a common format
 for the Type field [RFC5163].  The ULE Next-Header registry is
 therefore also applicable to this encapsulation.
 This document updates the IANA rules and guidance defined in
 Section 11.1 of [RFC4326] in the following way:
 o  The document clarifies use of the ULE Next-Header registry by GSE
    as well as by ULE.
 o  Section 3 specifies that new allocations in the ULE Next-Header
    registry are to be assigned by IANA using the "Specification
    Required" policy and provides guidance to the expert reviewer.

Fairhurst Standards Track [Page 2] RFC 7280 IANA ULE Guidelines June 2014

 o  Section 3.3 reserves a range of allocated values.
 o  Section 4 adds an explanatory note to clarify the encoding used in
    the ULE Next-Header registry.

2. Terminology

 This document assumes familiarity with the ULE terminology used in
 [RFC4326] and [RFC5163].
 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 [RFC2119].

2.1. The ULE Next-Header Registry

 The Mandatory Extension Headers are allocated in the ULE Next-Header
 registry with integer values in the decimal range 0-255.  The
 registered value corresponds to a 16-bit Type value (converted by
 setting the most significant 8 bits of the 16-bit value to zero).
 This Type value may identify a Mandatory Extension Header or a
 specific protocol.
 The Optional Extension Headers are allocated in the ULE Next-Header
 registry with integer values in the decimal 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.

2.2. Informative Example of Using a Value from the Optional Range

 This section provides an informative example of how a registry entry
 is constructed to identify an Optional ULE Extension Header.
 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.
 For example, the decimal value 256 has been allocated to denote the
 padding Extension Header.
 o  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.

Fairhurst Standards Track [Page 3] RFC 7280 IANA ULE Guidelines June 2014

 o  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.

3. Updated IANA Guidance on Allocation in the ULE Next-Header Registry

 The rules for allocation were defined in Section 11 of [RFC4326].
 This document updates these rules by replacing them with the rules in
 this section:
 Allocations in the ULE Next-Header registry are to be assigned by
 IANA using the "Specification Required" policy defined in [RFC5226].
 Applications must include a reference to a specification of the Next-
 Header extension in a "permanent and readily available public
 specification" [RFC5226].  An IETF Standards Track RFC can provide
 such a reference.  Other specifications are also permitted.  The
 Designated Expert shall advise IANA on whether a particular
 specification constitutes a "permanent and readily available public
 specification".

3.1. ULE Next-Header Registry

 The ULE Next-Header registry allocates 0-511 decimal (0x0000-0x01FF
 hexadecimal).  IANA must not allocate values greater than 511
 (decimal).  For each allocated value, it also specifies the set of
 allowed H-LEN values (see [RFC4326], 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 integer values in the range 0-1535
 (decimal).  This forms the first part of the ULE Type space (see
 [RFC4326], Section 4.4.1).
 The registry is divided into two ranges:
 1.  0-255 (decimal) IANA-assigned values, indicating Mandatory
     Extension Headers (or link-dependent Type fields).  [RFC4326]
     made initial assignments to this range of values in the registry,
     updated by later requests.
 2.  256-511 (decimal) IANA-assigned values, indicating Optional
     Extension Headers.  The entry MUST define the need for the
     Optional Extension and the intended use.  [RFC4326] made initial
     assignments to this range of values in the registry, updated by
     later requests.

Fairhurst Standards Track [Page 4] RFC 7280 IANA ULE Guidelines June 2014

3.2. Expert Review Guidelines

 The Specification Required policy also implies use of a Designated
 Expert [RFC5226].  The Designated Expert shall review a proposed
 registration for the following REQUIRED information:
 For requests in the range 0-255 (decimal) - Mandatory Extension
 Headers:
 o  The value and the name associated with the Extension Header;
 o  The procedure for processing the Extension Header;
 o  A definition of the Extension Header and the intended use; and
 o  The size of the Extension Header (by default, the entire remaining
    payload).
 For requests in the range 256-511 (decimal) - Optional Extension
 Headers:
 o  The value and the name associated with the Optional Extension
    Header;
 o  The procedure for processing the Extension Header;
 o  A definition of the Extension Header and the intended use
    (including any extension ordering requirements); and
 o  The range of allowable H-LEN values that are permitted (in the
    range 1-5).
 If the registration information does not have any of the above
 required information, the Designated Expert shall not approve the
 registration to IANA.

3.3. Reservation of Next-Header Values for Private Use

 This document reserves the range 144-159 decimal (0x80-0x8F
 hexadecimal) for Private Use [RFC5226].
 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, insufficient operational
 experience was available to understand if a general solution is
 needed, or 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.

Fairhurst Standards Track [Page 5] RFC 7280 IANA ULE Guidelines June 2014

 Authors of specifications MUST 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.

4. Update to Registry Information

 IANA has recorded an additional explanatory note in the ULE Next-
 Header registry:
    The Mandatory Extension Header range in the ULE Next-Header
    registry is used to allocate integer 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 Header range in the ULE Next-Header
    registry is used to allocate integer 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 has been placed before the existing note.

5. Security Considerations

 This document does not present new security considerations.

6. IANA Considerations

 Section 3 specifies updated IANA allocation rules.
 Per Section 3.3, IANA has reserved the range 144-159 decimal
 (0x80-0x8F hexadecimal) marked it as Reserved for Private Use.
 Per Section 4, IANA has updated the ULE Next-Header registry
 information.

7. Acknowledgments

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

Fairhurst Standards Track [Page 6] RFC 7280 IANA ULE Guidelines June 2014

8. References

8.1. Normative References

 [GSE]      European Telecommunication Standards Institute (ETSI),
            "Digital Video Broadcasting (DVB); Generic Stream
            Encapsulation (GSE) Protocol", 2007.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC4326]  Fairhurst, G. and B. Collini-Nocker, "Unidirectional
            Lightweight Encapsulation (ULE) for Transmission of IP
            Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326,
            December 2005.
 [RFC5163]  Fairhurst, G. and B. Collini-Nocker, "Extension Formats
            for Unidirectional Lightweight Encapsulation (ULE) and the
            Generic Stream Encapsulation (GSE)", RFC 5163, April 2008.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

8.2. Informative References

 [RFC4259]  Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker,
            B., and H. Linder, "A Framework for Transmission of IP
            Datagrams over MPEG-2 Networks", RFC 4259, November 2005.

Author's Address

 Godred Fairhurst
 University of Aberdeen
 School of Engineering
 Fraser Noble Building
 Aberdeen, Scotland  AB24 3UE
 UK
 EMail: gorry@erg.abdn.ac.uk
 URI:   http://www.erg.abdn.ac.uk

Fairhurst Standards Track [Page 7]

/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc7280.txt · Last modified: 2014/06/19 20:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki