Skip to main content

IANA Registry for 6lowpan Additional Dispatch Bytes
draft-chairs-6lo-dispatch-iana-registry-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Samita Chakrabarti , Gabriel Montenegro , Ralph Droms , james woodyatt
Last updated 2015-07-06
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chairs-6lo-dispatch-iana-registry-00
6lo                                                       S. Chakrabarti
Internet-Draft                                                  Ericsson
Updates: 4944, 6282 (if approved)                          G. Montenegro
Intended status: Standards Track                               Microsoft
Expires: January 7, 2016                                        R. Droms
                                                                   Cisco
                                                             J. Woodyatt
                                                                    Nest
                                                            July 6, 2015

          IANA Registry for 6lowpan Additional Dispatch Bytes
               draft-chairs-6lo-dispatch-iana-registry-00

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 bytes has not been
   defined in RFC6282 and RFC4944.  The purpose of this document is to
   define the usage of ESC extension bytes.  It also records the initial
   values for extended dispatch values and requests 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 January 7, 2016.

Copyright Notice

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

Chakrabarti, et al.      Expires January 7, 2016                [Page 1]
Internet-Draft              IANA-6lo-dispatch                  July 2015

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Usage of ESC dispatch bytes . . . . . . . . . . . . . . . . . . 3
     3.1.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Example: ITU-T G.9903  ESC type usage . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6

Chakrabarti, et al.      Expires January 7, 2016                [Page 2]
Internet-Draft              IANA-6lo-dispatch                  July 2015

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 bytes and a co-ordination between the respective organizations
   and IETF/IANA are needed.

   The following sections describe the ITU-T specification for ESC
   dispatch byte code points for the record and propose the use of ESC
   extension bytes in the future.  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

   The ESC byte [01 000000] is modified in RFC 6282[RFC6282] and
   [RFC4944] first introduces this dispatch header type for extension of
   dispatch bytes for different usage of 6lowpan applications.

   For example, a dispatch header type (ex: LOWPAN_HC1, MESH etc.) might
   need some special handling of each packet for classification.

   This document specifies that the first octet following the ESC byte
   is 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       | Ext Type      | Extended Dispatch Payload
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Frame Format with ESC Byte

Chakrabarti, et al.      Expires January 7, 2016                [Page 3]
Internet-Draft              IANA-6lo-dispatch                  July 2015

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

   Extension Type(ET): 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 extension types
   appear in the sequence [ESC][extension type], as opposed to the
   dispatch values which appear by themselves as [dispatch value] with
   no preceding ESC.  Thus, extension types and dispatch values are
   orthogonal code spaces.

   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.

   Note that section 5.1 in RFC4944 indicates that the Extension Type
   field may contain additional dispatch values (larger than 63).  Note
   that the new dispatch type MUST NOT modify the behavior of existing
   dispatch types for the sake of interoperability.

3.1.  Open Issues

   Legacy node behavior: When a legacy 6lowpan node receives packets
   with ESC bytes or nodes receiving ESC bytes it does not understand,
   what should be its behavior?  Two alternatives: 1) discard the
   6lowpan packet 2) ignore the ESC bytes.

   Sequence Of dispatch bytes and ESC bytes: TBD

3.2.  Example: ITU-T G.9903  ESC type usage

   [G3-PLC] provides native mesh under functionalities.  The ESC
   dispatch type is used with the command frames specified in figure
   9-12 and Table 9-35 in [G3-PLC] .  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 2: G.9903 Frame Format with ESC Byte

Chakrabarti, et al.      Expires January 7, 2016                [Page 4]
Internet-Draft              IANA-6lo-dispatch                  July 2015

4.  IANA Considerations

   This document requests IANA to register the '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 dispatch 'Extension Type' fields are:

   +-------+---------------------------------+---------------+
   | Value | Description                     | Reference     |
   +-------+---------------------------------+---------------+
   |  0    | Reserved for future use         | This document |
   |       |                                 |               |
   | 1-31  | Used by ITU-T G.9903 command ID | ITU-T G.9903  |
   |       |                                 | [G3-PLC]      |
   | 32-254| Unassigned                      | This document |
   | 255   | Reserved for future use         | This document |
   +-------+---------------------------------+---------------+

                Figure 3: 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.

7.  References

Chakrabarti, et al.      Expires January 7, 2016                [Page 5]
Internet-Draft              IANA-6lo-dispatch                  July 2015

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

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,
              May 2008.

Authors' Addresses

   Samita Chakrabarti
   Ericsson
   300 Holger Way
   San Jose, CA
   US

   Phone: +1 408 750 5843
   Email: samita.chakrabarti@ericsson.com

   Gabriel Montenegro
   Microsoft
   Seattle
   US

   Email: gabriel.montenegro@microsoft.com

Chakrabarti, et al.      Expires January 7, 2016                [Page 6]
Internet-Draft              IANA-6lo-dispatch                  July 2015

   Ralph Droms
   Cisco
   USA

   Email: rdroms@cisco.com

   James Woodyatt
   Nest
   Mountain View, CA
   USA

   Email: jhw@netstlabs.com

Chakrabarti, et al.      Expires January 7, 2016                [Page 7]