Skip to main content

IANA Registry for 6lowpan ESC Dispatch Code points
draft-ietf-6lo-dispatch-iana-registry-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8066.
Authors Samita Chakrabarti , Gabriel Montenegro , Ralph Droms , james woodyatt
Last updated 2016-03-31 (Latest revision 2016-03-21)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Jonathan Hui
IESG IESG state Became RFC 8066 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to "Jonathan Hui" <jonhui@nestlabs.com>
draft-ietf-6lo-dispatch-iana-registry-02
6lo                                                       S. Chakrabarti
Internet-Draft                                                  Ericsson
Updates: 4944, 6282 (if approved)                          G. Montenegro
Intended status: Standards Track                               Microsoft
Expires: September 22, 2016                                     R. Droms
                                                                   Cisco
                                                             J. Woodyatt
                                                                    Nest
                                                          March 21, 2016

           IANA Registry for 6lowpan ESC Dispatch Code points
                draft-ietf-6lo-dispatch-iana-registry-02

Abstract

   RFC4944 defines ESC dispatch type for additional dispatch bytes in
   the 6lowpan header.  The value of ESC byte has been updated by
   RFC6282.  However, the usage of ESC extension byte has not been
   defined in RFC6282 and RFC4944.  The purpose of this document is to
   define the ESC extension byte code points and to request
   corresponding IANA actions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 22, 2016.

Copyright Notice

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

Chakrabarti, et al.    Expires September 22, 2016               [Page 1]

Internet-Draft              IANA-6lo-dispatch                 March 2016

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Usage of ESC dispatch bytes . . . . . . . . . . . . . . . . . . 3
     3.1.  Interaction with other RFC4944 implementations  . . . . . . 4
     3.2.  ESC Extension Bytes Typical Sequence  . . . . . . . . . . . 5
     3.3.  ITU-T G.9903  ESC type usage  . . . . . . . . . . . . . . . 5
     3.4.  NALP and ESC bytes  . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Chakrabarti, et al.    Expires September 22, 2016               [Page 2]

Internet-Draft              IANA-6lo-dispatch                 March 2016

1.  Introduction

   [RFC4944] section 5.1 defines the dispatch header and types.  The ESC
   type is defined for using additional dispatch bytes in the 6lowpan
   header.  RFC 6282 modifies the value of the ESC dispatch type and it
   is recorded in IANA registry [6LOWPAN-IANA].  However, the bytes and
   usage following the ESC byte are not defined in either [RFC4944] and
   [RFC6282].  However, in recent years with 6lowpan deployments, the
   implementations and Standards organizations have started using the
   ESC extension bytes and a co-ordination between the respective
   organizations and IETF/IANA are needed.

   The following sections record the ITU-T specification for ESC
   dispatch byte code points as an existing known usage and propose the
   definition of ESC extension bytes for future applications.  The
   document also requests IANA actions for the first extension byte
   following the ESC byte.

2.  Terminology

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

3.  Usage of ESC dispatch bytes

   RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type
   for extension of dispatch bytes.  RFC 6282 [RFC6282] subsequently
   modified its value to [01 000000].

   This document specifies that the first octet following the ESC byte
   be used for extension type (extended dispatch values).  Subsequent
   octets are left unstructured for the specific use of the extension
   type:

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1| ESC       | ESC EXT Type  | Extended Dispatch Payload
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Frame Format with ESC Byte

   ESC: The left-most byte is the ESC dispatch type containing '0100000'

Chakrabarti, et al.    Expires September 22, 2016               [Page 3]

Internet-Draft              IANA-6lo-dispatch                 March 2016

   ESC Extension Type (EET): It is the first byte following the ESC
   byte.  Extension type defines the payload for the additional dispatch
   bytes.  The values are from 0 to 255.  Value 0 and 255 are reserved
   for future use.  These values are assigned by IANA.  The EET values
   are similar to dispatch values in the 6lowpan header except they are
   preceeded by the ESC byte.  Thus, ESC extension types and dispatch
   values are using orthogonal code spaces.  Though not desirable,
   multiple ESC bytes MAY appear in a 6lowpan header.  Section 3.1
   describes how to handle unknown ESC dispatch type.

   Extended Dispatch Payload(EDP): This part of frame format must be
   defined by the corresponding extension type.  A specification is
   required to define each usage of extension type and its corresponding
   Extension Payload.  For the sake of interoperability, specifications
   of extension bytes MUST NOT redefine the existing ESC Extension Type
   codes.

   Section 5.1 in RFC4944 indicates that the Extension Type field may
   contain additional dispatch values larger than 63, as corrected by
   [4944-ERRATA].  For the sake of interoperability, the new dispatch
   type (EET) MUST NOT modify the behavior of existing dispatch types
   [RFC4944].

3.1.  Interaction with other RFC4944 implementations

   It is expected that RFC4944 existing implementations are not capable
   of processing ESC extension data bytes as defined in this document.
   However, implementors have to assume that existing implementation
   that attempt to process an EET unknown to them will simply drop the
   packet or ignore the ESC dispatch bytes.

   If an implementation following this document, during processing of
   the received packet reaches the ESC byte for which it does not
   understand the extension bytes (EET), it MUST drop that packet.
   However, it is important to clarify that a router node SHOULD forward
   a 6lowpan packet with the EET bytes as long as it does not attempt to
   process any unknown ESC extension bytes.

   Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension
   bytes may appear in a packet.  The ESC bytes can appear as the first,
   last or middle dispatch bytes.  However, a packet will get dropped by
   any node that does not understand the EET at the beginning of the
   packet.  The closer to the end of the packet are the EET's, the
   higher chance there is that a legacy node will recognize and
   successfully process some dispatch type [RFC4944] before the EET and
   then ignore the EET instead of dropping the entire packet.

Chakrabarti, et al.    Expires September 22, 2016               [Page 4]

Internet-Draft              IANA-6lo-dispatch                 March 2016

3.2.  ESC Extension Bytes Typical Sequence

   ESC Extension bytes sequence and order with respect to 6LoWPAN Mesh
   header and LoWPAN_IPHC header are described below.  When LOWPAN_IPHC
   dispatch type is present, ESC bytes MUST appear before the
   LOWPAN_IPHC dispatch type in order to maintain backward compatibility
   with RFC 8262 section 3.2.  The following diagrams provide examples
   of ESC extension byte usages:

   A LoWPAN encapsulated IPv6 Header compressed packet:

   +-------+------+--------+--------+-----------------+--------+
   |   ESC | EET  | EDP    |Dispatch| LOWPAN_IPHC hdr | Payld  |
   +-------+------+--------+--------+-----------------+--------+

   A LoWPAN_IPHC Header, Mesh header and an ESC extenstion byte:

   +-----+-----+-----+----+------+-------+---------------+------+
   |M typ| Mhdr| ESC | EET|EDP   |Disptch|LOWPAN_IPHC hdr| Payld|
   +-----+-----+-----+----+------+-------+---------------+------+

   A Mesh header with ESC bytes
   +-------+-------+-----+-----+-------+
   | M Typ | M Hdr | ESC | EET |EDP    |
   +-------+-------+-----+-----+-------+

   With Fragment header

   +-------+-------+--------+------+-----+-----+-------+
   | M Typ | M Hdr | F Typ  | F hdr|ESC  | EET |  EDP  |
   +-------+-------+--------+------+-----+-----+-------+

   ESC byte as a LowPAN encapsulation

   +--------+--------+--------+
   | ESC    | EET    | EDP    |
   +--------+--------+--------+

                 Figure 2: A 6lowpan packet with ESC Bytes

3.3.  ITU-T G.9903  ESC type usage

   The ESC dispatch type is used in [G3-PLC] to provide native mesh
   header and bootstrapping functionalities.  The ITU-T recommendation
   defines command IDs in the [G3-PLC] section 9.4.2.3 which operates

Chakrabarti, et al.    Expires September 22, 2016               [Page 5]
Internet-Draft              IANA-6lo-dispatch                 March 2016

   like ESC Extension type field.  The command ID values are 0x01 to
   0x1F.

   The frame format is defined as follows:

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1| ESC       |  Command ID   | Command Payload
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: G.9903 Frame Format with ESC Byte

3.4.  NALP and ESC bytes

   According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are
   reserved for use as a kind of escape code for identification of non-
   6lowpan payloads.  Since ESC bytes are part of 6lowpan dispatch types
   (extended), they are orthogonal to NALP bytes.

   This document clarifies that NALP dispatch codes only provide an
   escape method for non-6LoWPAN payloads when they appear as the
   initial byte of a LoWPAN encapsulation, and that the potential
   meaning of their appearance in any other location is reserved for
   future use.

4.  IANA Considerations

   This document requests IANA to register the 'ESC Extension Type'
   values as per the policy 'Specification Required'[RFC5226] as
   specified in this document which follows the same policy as in the
   IANA section of [RFC4944].  For each Extension Type (except the
   Reserved values) the specification MUST define corresponding Extended
   Dispatch Payload frame bytes for the receiver implementation to read
   the ESC bytes with interoperability.

   The initial values for the 'ESC Extension Type' fields are:

Chakrabarti, et al.    Expires September 22, 2016               [Page 6]
Internet-Draft              IANA-6lo-dispatch                 March 2016

   +-------+---------------------------------+---------------+
   | Value | Description                     | Reference     |
   +-------+---------------------------------+---------------+
   |  0    | Reserved for future use         | This document |
   |       |                                 |               |
   | 1-31  | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &|
   |       |     Command IDs                 | ITU-T G.9905  |
   |       |                                 |               |
   | 32-254| Unassigned                      | This document |
   |       |(Reserved for future IANA        |               |
   |       | Assignment-- Spec Required)     |               |
   |       |                                 |               |
   | 255   | Reserved for future use         | This document |
   +-------+---------------------------------+---------------+

                Figure 4: Initial Values for IANA Registry

5.  Security Considerations

   There is no additional security threats due to the assignments of ESC
   byte usage described in this document.  However, this document
   forbids defining any extended dispatch values or extension types that
   modifies the behavior of existing Dispatch types.

6.  Acknowledgements

   The authors would like to thank the members of the 6lo WG members for
   the comments in the mailing list.  Many thanks to Carsten Bormann,
   Ralph Droms, Thierry Lys, Cedric Lavenu, Pascal Thubert for their
   discussions regarding resolving the bits allocation issues which led
   to this document.  Jonathan Hui and Robert Cregie provided extensive
   reviews and guidance for interoperability.  The authors acknowledges
   the comments from the following people for shaping this document:
   Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana and
   Scott Mansfield.

7.  References

7.1.  Normative References

   [4944-ERRATA]
              "https://www.rfc-editor.org/errata_search.php?rfc=4944".

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

Chakrabarti, et al.    Expires September 22, 2016               [Page 7]
Internet-Draft              IANA-6lo-dispatch                 March 2016

              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <http://www.rfc-editor.org/info/rfc4944>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <http://www.rfc-editor.org/info/rfc6282>.

7.2.  Informative References

   [6LOWPAN-IANA]
              "https://www.iana.org/assignments/_6lowpan-parameters/
              _6lowpan-parameters.xhtml".

   [G3-PLC]   "http://www.itu.int/rec/T-REC-G.9903-201402-I".

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

Authors' Addresses

   Samita Chakrabarti
   Ericsson
   300 Holger Way
   San Jose, CA
   US

   Email: samita.chakrabarti@ericsson.com

   Gabriel Montenegro
   Microsoft
   Seattle
   US

   Email: gabriel.montenegro@microsoft.com

Chakrabarti, et al.    Expires September 22, 2016               [Page 8]
Internet-Draft              IANA-6lo-dispatch                 March 2016

   Ralph Droms
   Cisco
   USA

   Email: rdroms@cisco.com

   James Woodyatt
   Nest
   Mountain View, CA
   USA

   Email: jhw@netstlabs.com

Chakrabarti, et al.    Expires September 22, 2016               [Page 9]