An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e
draft-ietf-6tisch-architecture-04

ACE Working Group                                              S. Gerdes
Internet-Draft                                               O. Bergmann
Intended status: Standards Track                              C. Bormann
Expires: 12 November 2021                         Universität Bremen TZI
                                                             G. Selander
                                                             Ericsson AB
                                                                L. Seitz
                                                               Combitech
                                                             11 May 2021

Datagram Transport Layer Security (DTLS) Profile for Authentication and
            Authorization for Constrained Environments (ACE)
                    draft-ietf-ace-dtls-authorize-17

Abstract

   This specification defines a profile of the ACE framework that allows
   constrained servers to delegate client authentication and
   authorization.  The protocol relies on DTLS version 1.2 for
   communication security between entities in a constrained network
   using either raw public keys or pre-shared keys.  A resource-
   constrained server can use this protocol to delegate management of
   authorization information to a trusted host with less severe
   limitations regarding processing power and memory.

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 https://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 12 November 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Gerdes, et al.          Expires 12 November 2021                [Page 1]
Internet-Draft                  CoAP-DTLS                       May 2021Internet-Draft            6TiSCH-architecture               October 2014

   In tunnel mode, the frames originate from an arbitrary protocol over
   a compatible MAC that may or may not be synchronized with the 6TiSCH
   network.  An example of this would be a router with a dual radio that
   is capable of receiving and sending WirelessHART or ISA100.11a frames
   with the second radio, by presenting itself as an access Point or a
   Backbone Router, respectively.

   In that mode, some entity (e.g.  PCE) can coordinate with a
   WirelessHART Network Manager or an ISA100.11a System Manager to
   specify the flows that are to be transported transparently over the
   Track.

   +--------------+
   |     IPv6     |
   +--------------+
   |  6LoWPAN HC  |
   +--------------+             set            restore
   |     6top     |            +dmac+          +dmac+
   +--------------+            |    |          |    |
   |   TSCH MAC   |            |    |          |    |
   +--------------+            |    |          |    |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+    |   ingress                 egress   |
                       |                                    |
   +--------------+    |                                    |
   |   LLN PHY    |    |                                    |
   +--------------+    |                                    |
   |   TSCH MAC   |    |                                    |
   +--------------+    |                                    |
   |ISA100/WiHART |    |                                    v
   +--------------+

   In that case, the flow information that identifies the Track at the
   ingress 6TiSCH router is derived from the RX-cell.  The dmac is set
   to this node but the flow information indicates that the frame must
   be tunnelled over a particular Track so the frame is not passed to
   the upper layer.  Instead, the dmac is forced to broadcast and the
   frame is passed to the 6top sublayer for switching.

   At the egress 6TiSCH router, the reverse operation occurs.  Based on
   metadata associated to the Track, the frame is passed to the
   appropriate link layer with the destination MAC restored.

9.1.3.  Tunnel Metadata

   Metadata coming with the Track configuration is expected to provide
   the destination MAC address of the egress endpoint as well as the
   tunnel mode and specific data depending on the mode, for instance a
   service access point for frame delivery at egress.  If the tunnel
   egress point does not have a MAC address that matches the
   configuration, the Track installation fails.

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 23]
Internet-Draft            6TiSCH-architecture               October 2014

   In transport mode, if the final layer-3 destination is the tunnel
   termination, then it is possible that the IPv6 address of the
   destination is compressed at the 6LoWPAN sublayer based on the MAC
   address.  It is thus mandatory at the ingress point to validate that
   the MAC address that was used at the 6LoWPAN sublayer for compression
   matches that of the tunnel egress point.  For that reason, the node
   that injects a packet on a Track checks that the destination is
   effectively that of the tunnel egress point before it overwrites it
   to broadcast.  The 6top sublayer at the tunnel egress point reverts
   that operation to the MAC address obtained from the tunnel metadata.

9.2.  Fragment Forwarding

   Considering that 6LoWPAN packets can be as large as 1280 bytes (the
   IPv6 MTU), and that the non-storing mode of RPL implies Source
   Routing that requires space for routing headers, and that a
   IEEE802.15.4 frame with security may carry in the order of 80 bytes
   of effective payload, an IPv6 packet might be fragmented into more
   than 16 fragments at the 6LoWPAN sublayer.

   This level of fragmentation is much higher than that traditionally
   experienced over the Internet with IPv4 fragments, where
   fragmentation is already known as harmful.

   In the case to a multihop route within a 6TiSCH network, Hop-by-Hop
   recomposition occurs at each hop in order to reform the packet and
   route it.  This creates additional latency and forces intermediate
   nodes to store a portion of a packet for an undetermined time, thus
   impacting critical resources such as memory and battery.

   [I-D.thubert-roll-forwarding-frags] describes a mechanism whereby the
   datagram tag in the 6LoWPAN Fragment is used as a label for switching
   at the 6LoWPAN sublayer.  The draft allows for a degree of flow
   control base on an Explicit Congestion Notification, as well as end-
   to-end individual fragment recovery.

                       |                                    ^
   +--------------+    |                                    |
   |     IPv6     |    |       +----+          +----+       |
   +--------------+    |       |    |          |    |       |
   |  6LoWPAN HC  |    |       learn           learn        |
   +--------------+    |       |    |          |    |       |
   |     6top     |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |   TSCH MAC   |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 24]
Internet-Draft            6TiSCH-architecture               October 2014

   In that model, the first fragment is routed based on the IPv6 header
   that is present in that fragment.  The 6LoWPAN sublayer learns the
   next hop selection, generates a new datagram tag for transmission to
   the next hop, and stores that information indexed by the incoming MAC
   address and datagram tag.  The next fragments are then switched based
   on that stored state.

                       |                                    ^
   +--------------+    |                                    |
   |     IPv6     |    |                                    |
   +--------------+    |                                    |
   |  6LoWPAN HC  |    |       replay          replay       |
   +--------------+    |       |    |          |    |       |
   |     6top     |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |   TSCH MAC   |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+

   A bitmap and an ECN echo in the end-to-end acknowledgement enable the
   source to resend the missing fragments selectively.  The first
   fragment may be resent to carve a new path in case of a path failure.
   The ECN echo set indicates that the number of outstanding fragments
   should be reduced.

9.3.  IPv6 Forwarding

   As the packets are routed at layer 3, traditional QoS and RED
   operations are expected to prioritize flows; the application of
   Differentiated Services is further discussed in [I-D.svshah-tsvwg-
   lln-diffserv-recommendations].

                       |                                    ^
   +--------------+    |                                    |
   |     IPv6     |    |       +-QoS+          +-QoS+       |
   +--------------+    |       |    |          |    |       |
   |  6LoWPAN HC  |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |     6top     |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |   TSCH MAC   |    |       |    |          |    |       |
   +--------------+    |       |    |          |    |       |
   |   LLN PHY    |    +-------+    +--...-----+    +-------+
   +--------------+

10.  Centralized vs.  Distributed Routing

   6TiSCH supports a mixed model of centralized routes and distributed
   routes.  Centralized routes can for example computed by a entity such
   as a PCE.  Distributed routes are computed by RPL.

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 25]
Internet-Draft            6TiSCH-architecture               October 2014

   Both methods may inject routes in the Routing Tables of the 6TiSCH
   routers.  In either case, each route is associated with a 6TiSCH
   topology that can be a RPL Instance topology or a track.  The 6TiSCH
   topology is indexed by a Instance ID, in a format that reuses the
   RPLInstanceID as defined in RPL [RFC6550].

   Both RPL and PCE rely on shared sources such as policies to define
   Global and Local RPLInstanceIDs that can be used by either method.
   It is possible for centralized and distributed routing to share a
   same topology.  Generally they will operate in different slotFrames,
   and centralized routes will be used for scheduled traffic and will
   have precedence over distributed routes in case of conflict between
   the slotFrames.

10.1.  Packet Marking and Handling

   All packets inside a 6TiSCH domain MUST carry the Instance ID that
   identifies the 6TiSCH topology that is to be used for routing and
   forwarding that packet.  The location of that information MUST be the
   same for all packets forwarded inside the domain.

   For packets that are routed by a PCE along a Track, the tuple formed
   by the IPv6 source address and a local RPLInstanceID in the packet
   identify uniquely the Track and associated transmit bundle.
   Additionally, an IP packet that is sent along a Track uses the
   Differentiated Services Per-Hop-Behavior Group called Deterministic
   Forwarding, as described in [I-D.svshah-tsvwg-deterministic-
   forwarding].

   For packets that are routed by RPL, that information is the
   RPLInstanceID which is carried in the RPL Packet Information, as
   discussed in section 11.2 of [RFC6550], "Loop Avoidance and
   Detection".

   The RPL Packet Information (RPI) is carried in IPv6 packets as a RPL
   option in the IPv6 Hop-By-Hop Header [RFC6553].  6LoWPAN provides a
   Next Header Compression (NHC) for the RPI (RPI-NHC).  The RPI-NHC is
   specified in [I-D.thubert-6lo-rpl-nhc], and is the compressed
   equivalent to the whole HbH header with the RPL option.  In a 6LoWPAN
   network, the RPI-NHC is the recommended encoding the RPL Packet
   Information.

   Either way, the method and format used for encoding the RPLInstanceID
   is generalized to all 6TiSCH topological Instances, which include
   both RPL Instances and Tracks.

11.  IANA Considerations

   This specification does not require IANA action.

12.  Security Considerations

   This specification is not found to introduce new security threat.

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 26]
Internet-Draft            6TiSCH-architecture               October 2014

13.  Contributors

   The editors and authors wish to recognize the contribution of

   Xavier Vilajosana who lead the design of the minimal support with RPL
         and contributed deeply to the 6top design.

   Qin Wang who lead the design of the 6top sublayer and contributed
         related text that was moved and/or adapted in this document.

14.  Acknowledgements

   This specification is the result interactions in particular during
   the 6TiSCH (bi)Weekly call.  The authors wish to thank: Alaeddine
   Weslati, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Diego
   Dujovne, Dominique Barthel, Elvis Vogli, Geraldine Texier, Giuseppe
   Piro, Guillaume Gaillard, Herman Storey, Ines Robles, Jonathan Simon,
   Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain,
   Maik Seewald, Maria Rita Palattella, Michael Behringer, Michael
   Richardson, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont,
   Oleg Hahm, Pat Kinney, Patrick Wetterwald, Paul Duffy, Peter van der
   Stock, Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-
   Lopez, Raghuram Sudhaakar, Rene Struik, Sedat Gormus, Shitanshu Shah,
   Steve Simlo, Subir Das, Tengfei Chang, Tina Tsou, Tom Phinney, Xavier
   Lagrange and Yoshihiro Ohba for their various participation.

15.  References

15.1.  Normative References

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

   [RFC2460]  Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
              6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444, January
              2003.

   [RFC3610]  Whiting, D., Housley, R. and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3610, September 2003.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J. and S. Van den
              Bosch, "Next Steps in Signaling (NSIS): Framework", RFC
              4080, June 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 27]
Internet-Draft            6TiSCH-architecture               October 2014

   [RFC4389]  Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, April 2006.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
              2007.

   [RFC4919]  Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals", RFC
              4919, August 2007.

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [RFC5889]  Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
              Hoc Networks", RFC 5889, September 2010.

   [RFC5974]  Manner, J., Karagiannis, G. and A. McDonald, "NSIS
              Signaling Layer Protocol (NSLP) for Quality-of-Service
              Signaling", RFC 5974, October 2010.

   [RFC6275]  Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

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

   [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
              Levis, P., Pister, K., Struik, R., Vasseur, JP. and R.
              Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
              Lossy Networks", RFC 6550, March 2012.

   [RFC6552]  Thubert, P., "Objective Function Zero for the Routing
              Protocol for Low-Power and Lossy Networks (RPL)", RFC
              6552, March 2012.

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553, March
              2012.



   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Communication Between the Client and the Authorization
           Server  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Raw Public Key Mode . . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Access Token Retrieval from the Authorization
               Server  . . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.2.  DTLS Channel Setup Between Client and Resource
               Server  . . . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  PreSharedKey Mode . . . . . . . . . . . . . . . . . . . .  10
       3.3.1.  Access Token Retrieval from the Authorization
               Server  . . . . . . . . . . . . . . . . . . . . . . .  11
       3.3.2.  DTLS Channel Setup Between Client and Resource
               Server  . . . . . . . . . . . . . . . . . . . . . . .  15
     3.4.  Resource Access . . . . . . . . . . . . . . . . . . . . .  17
   4.  Dynamic Update of Authorization Information . . . . . . . . .  18
   5.  Token Expiration  . . . . . . . . . . . . . . . . . . . . . .  20
   6.  Secure Communication with an Authorization Server . . . . . .  20
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     7.1.  Reuse of Existing Sessions  . . . . . . . . . . . . . . .  22
     7.2.  Multiple Access Tokens  . . . . . . . . . . . . . . . . .  22
     7.3.  Out-of-Band Configuration . . . . . . . . . . . . . . . .  23
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  23
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     11.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

Gerdes, et al.          Expires 12 November 2021                [Page 2]
Internet-Draft                  CoAP-DTLS                       May 2021

1.  Introduction

   This specification defines a profile of the ACE framework
   [I-D.ietf-ace-oauth-authz].  In this profile, a client and a resource
   server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to
   communicate.  This specification uses DTLS 1.2 terminology, but later
   versions such as DTLS 1.3 can be used instead.  The client obtains an
   access token, bound to a key (the proof-of-possession key), from an
   authorization server to prove its authorization to access protected
   resources hosted by the resource server.  Also, the client and the
   resource server are provided by the authorization server with the
   necessary keying material to establish a DTLS session.  The
   communication between client and authorization server may also be
   secured with DTLS.  This specification supports DTLS with Raw Public
   Keys (RPK) [RFC7250] and with Pre-Shared Keys (PSK) [RFC4279].  How
   token introspection [RFC7662] is performed between RS and AS is out
   of scope for this specification.

   The ACE framework requires that client and server mutually
   authenticate each other before any application data is exchanged.
   DTLS enables mutual authentication if both client and server prove
   their ability to use certain keying material in the DTLS handshake.
   The authorization server assists in this process on the server side
   by incorporating keying material (or information about keying
   material) into the access token, which is considered a "proof of
   possession" token.

   In the RPK mode, the client proves that it can use the RPK bound to
   the token and the server shows that it can use a certain RPK.

   The resource server needs access to the token in order to complete
   this exchange.  For the RPK mode, the client must upload the access
   token to the resource server before initiating the handshake, as
   described in Section 5.10.1 of the ACE framework
   [I-D.ietf-ace-oauth-authz].

   In the PSK mode, client and server show with the DTLS handshake that
   they can use the keying material that is bound to the access token.
   To transfer the access token from the client to the resource server,
   the "psk_identity" parameter in the DTLS PSK handshake may be used
   instead of uploading the token prior to the handshake.

   As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this
   specification uses CBOR web tokens to convey claims within an access
   token issued by the server.  While other formats could be used as
   well, those are out of scope for this document.

Gerdes, et al.          Expires 12 November 2021                [Page 3]
Internet-Draft                  CoAP-DTLS                       May 2021

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Readers are expected to be familiar with the terms and concepts
   described in [I-D.ietf-ace-oauth-authz] and in
   [I-D.ietf-ace-oauth-params].

   The authorization information (authz-info) resource refers to the
   authorization information endpoint as specified in
   [I-D.ietf-ace-oauth-authz].  The term "claim" is used in this
   document with the same semantics as in [I-D.ietf-ace-oauth-authz],
   i.e., it denotes information carried in the access token or returned
   from introspection.

2.  Protocol Overview

   The CoAP-DTLS profile for ACE specifies the transfer of
   authentication information and, if necessary, authorization
   information between the client (C) and the resource server (RS)
   during setup of a DTLS session for CoAP messaging.  It also specifies
   how the client can use CoAP over DTLS to retrieve an access token
   from the authorization server (AS) for a protected resource hosted on
   the resource server.  As specified in Section 6.7 of
   [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these
   interactions is completely independent.

   This profile requires the client to retrieve an access token for
   protected resource(s) it wants to access on the resource server as
   specified in [I-D.ietf-ace-oauth-authz].  Figure 1 shows the typical
   message flow in this scenario (messages in square brackets are
   optional):

      C                                RS                   AS
      | [---- Resource Request ------>]|                     |
      |                                |                     |
      | [<-AS Request Creation Hints-] |                     |
      |                                |                     |
      | ------- Token Request  ----------------------------> |
      |                                |                     |
      | <---------------------------- Access Token --------- |
      |                               + Access Information   |

                    Figure 1: Retrieving an Access Token

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 28]
Internet-Draft            6TiSCH-architecture               October 2014

   [RFC6620]  Nordmark, E., Bagnulo, M. and E. Levy-Abegnoli, "FCFS
              SAVI: First-Come, First-Served Source Address Validation
              Improvement for Locally Assigned IPv6 Addresses", RFC
              6620, May 2012.

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
              Transport Layer Security (TLS)", RFC 6655, July 2012.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, January
              2013.

15.2.  Informative References

   [I-D.chakrabarti-nordmark-6man-efficient-nd]
              Chakrabarti, S., Nordmark, E., Thubert, P. and M.
              Wasserman, "Wired and Wireless IPv6 Neighbor Discovery
              Optimizations", Internet-Draft draft-chakrabarti-nordmark-
              6man-efficient-nd-04, October 2013.

   [I-D.finn-detnet-problem-statement]
              Finn, N. and P. Thubert, "Deterministic Networking Problem
              Statement", Internet-Draft draft-finn-detnet-problem-
              statement-01, October 2014.

   [I-D.ietf-6tisch-6top-interface]
              Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH
              Operation Sublayer (6top) Interface", Internet-Draft
              draft-ietf-6tisch-6top-interface-00, March 2014.

   [I-D.ietf-6tisch-coap]
              Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
              Interaction using CoAP", Internet-Draft draft-ietf-6tisch-
              coap-00, May 2014.

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", Internet-Draft draft-ietf-6tisch-
              minimal-00, November 2013.

   [I-D.ietf-6tisch-terminology]
              Palattella, M., Thubert, P., Watteyne, T. and Q. Wang,
              "Terminology in IPv6 over the TSCH mode of IEEE
              802.15.4e", Internet-Draft draft-ietf-6tisch-
              terminology-00, November 2013.

   [I-D.ietf-6tisch-tsch]

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 29]
Internet-Draft            6TiSCH-architecture               October 2014

              Watteyne, T., Palattella, M. and L. Grieco, "Using
              IEEE802.15.4e TSCH in an LLN context: Overview, Problem
              Statement and Goals", Internet-Draft draft-ietf-6tisch-
              tsch-00, November 2013.

   [I-D.ietf-ipv6-multilink-subnets]
              Thaler, D. and C. Huitema, "Multi-link Subnet Support in
              IPv6", Internet-Draft draft-ietf-ipv6-multilink-
              subnets-00, July 2002.

   [I-D.ietf-roll-rpl-industrial-applicability]
              Phinney, T., Thubert, P. and R. Assimiti, "RPL
              applicability in industrial networks", Internet-Draft
              draft-ietf-roll-rpl-industrial-applicability-02, October
              2013.

   [I-D.svshah-tsvwg-deterministic-forwarding]
              Shah, S. and P. Thubert, "Deterministic Forwarding PHB",
              Internet-Draft draft-svshah-tsvwg-deterministic-
              forwarding-01, March 2014.

   [I-D.svshah-tsvwg-lln-diffserv-recommendations]
              Shah, S. and P. Thubert, "Differentiated Service Class
              Recommendations for LLN Traffic", Internet-Draft draft-
              svshah-tsvwg-lln-diffserv-recommendations-01, August 2013.

   [I-D.thubert-6lo-rpl-nhc]
              Thubert, P. and C. Bormann, "A compression mechanism for
              the RPL option", Internet-Draft draft-thubert-6lo-rpl-
              nhc-02, October 2014.

   [I-D.thubert-6lowpan-backbone-router]
              Thubert, P., "6LoWPAN Backbone Router", Internet-Draft
              draft-thubert-6lowpan-backbone-router-03, February 2013.

   [I-D.thubert-roll-forwarding-frags]
              Thubert, P. and J. Hui, "LLN Fragment Forwarding and
              Recovery", Internet-Draft draft-thubert-roll-forwarding-
              frags-02, September 2013.

   [I-D.wang-6tisch-6top-sublayer]
              Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH
              Operation Sublayer (6top)", Internet-Draft draft-wang-
              6tisch-6top-00, October 2013.

15.3.  External Informative References

   [HART]     www.hartcomm.org, "Highway Addressable Remote Transducer,
              a group of specifications for industrial process and
              control devices administered by the HART Foundation", .

   [IEEE802.1TSNTG]

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 30]
Internet-Draft            6TiSCH-architecture               October 2014

              IEEE Standards Association, "IEEE 802.1 Time-Sensitive
              Networks Task Group", March 2013, <http://www.ieee802.org/
              1/pages/avbridges.html>.

   [IEEE802154e]
              IEEE standard for Information Technology, "IEEE std.
              802.15.4e, Part.  15.4: Low-Rate Wireless Personal Area
              Networks (LR-WPANs) Amendament 1: MAC sublayer", April
              2012.

   [ISA100.11a]
              ISA/ANSI, "Wireless Systems for Industrial Automation:
              Process Control and Related Applications - ISA100.11a-2011
              - IEC 62734", 2011, <http://www.isa.org/Community/
              SP100WirelessSystemsforAutomation>.

   [WirelessHART]
              www.hartcomm.org, "Industrial Communication Networks -
              Wireless Communication Network and Communication Profiles
              - WirelessHART - IEC 62591", 2010.

Authors' Addresses

   Pascal Thubert, editor
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis, 06254
   FRANCE
   
   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com

   Thomas Watteyne
   Linear Technology, Dust Networks Product Group
   30695 Huntwood Avenue
   Hayward, CA 94544
   USA
   
   Phone: +1 (510) 400-2978
   Email: twatteyne@linear.com

   Robert Assimiti
   Centero
   961 Indian Hills Parkway
   Marietta, GA 30068
   USA
   
   Phone: +1 404 461 9614
   Email: robert.assimiti@centerotech.com

Thubert, Watteyne & AssimExpires April 28, 2015                [Page 31]