Skip to main content

Packet expiration time in 6LoWPAN Routing Header
draft-lijo-6lo-expiration-time-03

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 Lijo Thomas , P.M. Akshay , Satish Anamalamudi , S.V.R Anand , Malati Hegde , Charles E. Perkins
Last updated 2017-06-22 (Latest revision 2017-03-13)
RFC stream (None)
Formats
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-lijo-6lo-expiration-time-03
6lo                                                          Lijo Thomas
Internet-Draft                                                     C-DAC
Intended status: Standards Track                               P. Akshay
Expires: December 23, 2017                   Indian Institute of Science
                                                      Satish Anamalamudi
                                         Huaiyin Institute of Technology
                                                             S.V.R.Anand
                                                            Malati Hegde
                                             Indian Institute of Science
                                                              C. Perkins
                                                               Futurewei
                                                           June 21, 2017

            Packet expiration time in 6LoWPAN Routing Header
                   draft-lijo-6lo-expiration-time-03

Abstract

   This document specifies a new type for the 6LoWPAN Dispatch Page 1
   for carrying the expiration time of data packets within the 6LoWPAN
   routing header.  The expiration time is useful in making forwarding
   and scheduling decisions for time critical IoT M2M applications that
   need deterministic delay guarantees over constrained networks and
   operate within time-synchronized networks.

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 December 23, 2017.

Copyright Notice

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

Lijo Thomas, et al.     Expires December 23, 2017               [Page 1]
Internet-Draft             6lo Expiration Time                 June 2017

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . .   3
   4.  Deadline-6LoRH Description  . . . . . . . . . . . . . . . . .   3
   5.  Deadline-6LoRH Format . . . . . . . . . . . . . . . . . . . .   4
   6.  Deadline-6LoRH in Three Network Scenarios . . . . . . . . . .   6
     6.1.  Scenario 1: Endpoints in the same DODAG (N1) in non-
           storing mode. . . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  Scenario 2: Endpoints in Networks with Dissimilar L2
           Technologies. . . . . . . . . . . . . . . . . . . . . . .   7
     6.3.  Scenario 3: Packet transmission across different DODAGs
           (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Low Power and Lossy Networks (LLNs) are likely to be employed for
   implementing real time industrial applications that require end-to-
   end delay guarantees [I-D.grossman-detnet-use-cases].  A
   Deterministic Network typically requires that data packets generated
   by some senders have to reach their receivers within strict time
   bounds.  Intermediate nodes use the expiration time information to
   make appropriate packet forwarding and scheduling decisions to meet
   the time bounds.

   The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN
   Routing Header (6LoRH), compression schemes for RPL routing (source
   routing) operation [RFC6554], header compression of RPL Packet
   Information [RFC6553], and IP-in-IP encapsulation.  This document
   specifies a new Deadline-6LoRH type to the 6LoWPAN Dispatch Page 1,

Lijo Thomas, et al.     Expires December 23, 2017               [Page 2]
Internet-Draft             6lo Expiration Time                 June 2017

   so that the expiration time of data packets can be included within
   the 6LoWPAN routing header.  In addition, this specification
   specifies handling of the expiration time when packets traverse
   through time-synchronized networks operating in different timezones
   or distinct reference clocks.

2.  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
   [RFC2119].

   The Terminology used in this document is consistent with and
   incorporates that described in [RFC6550] and [I-D.ietf-6tisch-
   terminology].

3.  6LoRHE Generic Format

   The generic header format of the 6LoRHE is specified in
   [I-D.ietf-roll-routing-dispatch].  Figure 1 illustrates the 6LoRHE
   generic format.  Note: this section is not normative.  It is included
   for convenience, and may be deleted in a later revision of this
   document.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
     |1|0|1| Length  |      Type     |                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
                                      <--          length           -->

                          Figure 1: 6LoRHE format

   o  Length: Length of the 6LoRHE expressed in bytes, excluding the
      first 2 bytes.  This enables a node to skip a 6LoRHE if the Type
      is not recognized/supported.

   o  Type: Type of the 6LoRHE.

   o  length: variable

4.  Deadline-6LoRH Description

   The Deadline-6LoRH (see Figure 2) is an elective 6LoRH that provides
   a compressed form of expiration time for an IPv6 datagram.  Along
   with the expiration timer, the header can include the packet

Lijo Thomas, et al.     Expires December 23, 2017               [Page 3]
Internet-Draft             6lo Expiration Time                 June 2017

   origination time, to enable a close estimate of the total delay
   incurred by a packet.

   The packet expiration time field contains the value of the packet
   expiration time.  The packet SHOULD be delivered to the Receiver
   before this time.

      packet_expiration_time = packet_origination_time + max_delay

   All nodes within the network SHOULD process the Deadline-6LoRH in
   order to support delay-sensitive deterministic applications.  In this
   specification, the packet origination time is represented in
   different time units according to a scaling parameter value in the
   routing header.  One of the time units is the Network ASN (Absolute
   Slot Number) which can be used in case of a time slotted synchronized
   network, for instance a 6TiSCH network, where a global time is
   maintained in the units of slot lengths of certain resolution.

   The delay experienced by packets in the network is a useful metric
   for network diagnostics and performance monitoring.  To support this
   feature, the specification provides an optional packet Origination
   Time (OT) field as part of the header which is initialized by the
   sender using the current clock time of the outgoing network interface
   through which the packet is forwarded.  Whenever the packets crosses
   over to a network using a different reference clock, the Origination
   Time field is updated to represent the same Origination Time as
   expressed using the reference clock of the outgoing interface into
   the new network.  This is the same as the current time when the
   packet is transmitted into the new network, minus the delay already
   experienced by the packet, say 't'.  In effect, to the newly entered
   network, the packet will appear to have originated 't' time units
   earlier with respect to the reference clock of the new network.

   Origination Time in new network = current_time_in_new_network -
                  delay_already_experienced_in_previous_network(s)

5.  Deadline-6LoRH Format

        0               1               2               3
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|0|1| Length  |  6LoRH Type   |O|D| ETL | OTL | TU| EXP | Rsv |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      ET (variable length)     | OT(variable length)(optional) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: Deadline-6LoRH format

Lijo Thomas, et al.     Expires December 23, 2017               [Page 4]
Internet-Draft             6lo Expiration Time                 June 2017

   Length (5 bits): Length represents the total length of the Expiration
   Time type measured in octets.

   6LoRH Type: TBD

   O flag (1bit): Indicates the presence of Origination Time field.  '1'
   means the Origination Time is present, and '0' means it is absent.

   D flag (1 bit): The 'D' flag, set by the Sender, indicates the action
   that needs to be taken when an 6LR detects expiration time is
   elapsed.  If 'D' bit is 1, then the 6LR SHOULD drop the packet if the
   expiration time is elapsed.  If 'D' bit is 0, then the 6LR MAY ignore
   the Expiration Time and forward it.

   ETL (3 bits): Length of Expiration Time field.

   OTL (3 bits) : Length of Origination Time field.

      For example, ETL = 000 means the expiration time in the 6LoRHE is
      1 octet (8 bits) long.  Similarly, OTL = 111 means the origination
      time is 8 octets (64 bits) long.

   TU (2 bits) : Indicates time units for packet expiration and
   origination time fields

      00 : Time represented in microseconds
      01 : Time represented in seconds
      10 : Network ASN
      11 : Reserved

   EXP (3 bits) : Multiplication factor expressed as exponent of 10.

      The value of the ET field is multiplied by 10 to this power, to
      get the actual expiration time in the units represented by TU.
      The default value of EXP is 000, so that the ET field is
      unaffected.

   Rsv (3 bits) : Reserved

   ET Value (8..64-bit) : Expiration Time value

   OT Value (8..64-bit) : Origination Time value

   Whenever the Sender initiates the IP datagram, it includes the
   Deadline-6LoRH along with other 6LoRH information.

   Example: Consider a 6TiSCH network with time-slot length of 10ms.
   Let the current ASN when the packet is originated be 54400, and the

Lijo Thomas, et al.     Expires December 23, 2017               [Page 5]
Internet-Draft             6lo Expiration Time                 June 2017

   maximum allowable delay (max_delay) for the packet delivery is 1
   second from the packet origination, then:

      expiration_time = packet_origination_time + max_delay

         = 55400 + 100 (in Network ASNs)
         = 55500(Network ASNs)

   Deadline-6LoRH encoding with 'O' flag set to 1 :

      ETL = 001, OTL = 001, TU = '10', EXP = 2, ET = 0x22B, OT = 0x22A

6.  Deadline-6LoRH in Three Network Scenarios

   In this section, Deadline-6LoRH operation is described for 3 network
   scenarios.  Figure 3 depicts a constrained time-synchronized LLN that
   has two subnets N1 and N2, connected through LBRs
   [I-D.ietf-6lo-backbone-router] with different reference clock times
   T1 and T2.

                          +-------------------+
                          | Time Synchronized |
                          |      Network      |
                          +---------+---------+
                                    |
                                    |
                                    |
                     +--------------+--------------+
                     |                             |
                  +-----+                       +-----+
                  |     | Backbone              |     | Backbone
             o    |     | router                |     | router
                  +-----+                       +-----+
             o                  o               o
                 o    o   o               o  o   o  o   o  o
            o      LLN    o                 o  LLN   o  o
               o   o    o      o             o o o     o  o
         6LoWPAN Network (subnet N1)   6LoWPAN Network (subnet N2)

                 Figure 3: Intra-network Timezone Scenario

6.1.  Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode.

   In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram
   to be routed to a Receiver 'R' within the same DODAG.  For the route
   segment from Sender to 6LBR, the Sender includes a Deadline-6LoRH by
   encoding the expiration time contained in the inband-OAM header
   extension.  Then 6LR begins hop-by-hop operation to forward the

Lijo Thomas, et al.     Expires December 23, 2017               [Page 6]
Internet-Draft             6lo Expiration Time                 June 2017

   packet towards the 6LBR.  Once 6LBR receives the IP datagram, it
   generates a IPv6-in-IPv6 encapsulated packet when sending the packet
   downwards to the Receiver [I-D.ietf-roll-useofrplinfo].  The 6LBR
   copies the Deadline-6LoRH from the Sender originated IP header to the
   outer IP header.  The Deadline-6LoRH contained in the inner IP header
   is elided.

                              +-------+
                   ^          | 6LBR  |       |
                   |          |       |       |
                   |          +-------+       |
           Default |      (F)/      /| \      | IP-in-IP
           routing |     /  \      / |  \     |      Encapsulation
                   |    /    \   (C) |  (D)   |
                   |  (A)    (B) /   | / |\   |
                   |  /|\     |\:   (E)  : R  |
                     S : :    :     / \       V

             Figure 4: End points within same DODAG(subnet N1)

   At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Deadline-
   6LoRH is copied back from the outer header to inner header, and the
   inner IP packet is delivered to 'R'.

6.2.  Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies.

   In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG
   1) has IP datagram to be routed to a Receiver 'R' over a time-
   synchronized IPv6 network.  For the route segment from 'S' to 6LBR,
   'S' includes a Deadline-6LoRH.  Subsequently, 6LR will perform hop-
   by-hop operation to forward the packet towards the 6LBR.  Once the IP
   datagram reaches 6LBR of DODAG1, it encodes the expiration time (and,
   if available, the origination time) into the In-band OAM header
   extension, [I-D.brockners-inband-oam-data] and passes the datagram to
   the IPv6 layer for further routing.

Lijo Thomas, et al.     Expires December 23, 2017               [Page 7]
Internet-Draft             6lo Expiration Time                 June 2017

                              +----------------+
                              | Time           |
                              | synchronized   |------R
                              | Network        |
                              +----------------+
                                      |
                                      |
                            ----------+-----------
                     ^                |
                     |            +---+---+
                     |            | 6LBR  |
            Default  |            |       |
             routing |            +------++
                     |        (F)/      /| \
                     |       /  \      / |  \
                     |      /    \   (C) |  (D)
                       :  (A)    (B) /   | / |\
                          /|\     |\:   (E)  :
                         S : :    :     / \
                                       :   :

      Figure 5: Packet transmission in Dissimilar L2 Technologies or
                                 Internet

   The IP datagram is routed to another time synchronized deterministic
   network following its own distinct reference clock, so the expiration
   time in In-band OAM has to be updated according to the measurement of
   the current time in the new network.

6.3.  Scenario 3: Packet transmission across different DODAGs (N1 to
      N2).

   Consider the scenario depicted in Figure 6, in which the Sender 'S'
   (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R'
   belonging to another DODAG (DODAG 2).  The operation of this scenario
   can be decomposed into combination of case 1 and case 2 scenarios.
   For the route segment from 'S' to 6LBR, 'S' includes the Deadline-
   6LoRH.  Subsequently, each 6LR will perform hop-by-hop operation to
   forward the packet towards the 6LBR.  Once the IP datagram reaches
   6LBR1 of DODAG1, it applies the same rule as described in Case 2
   while routing the packet to LBR2 over a (likely) time synchronized
   wired backhaul.  The wired side of LBR2 can be mapped to receiver of
   Case 2.  Once the packet reaches LBR2, it updates the Deadline-6LoRH
   by adding the current time of DODAG2.  Further, it generates an IPv6-
   in-IPv6 encapsulated packet when sending the packet downstream to the
   Receiver [I-D.ietf-roll-useofrplinfo].

Lijo Thomas, et al.     Expires December 23, 2017               [Page 8]
Internet-Draft             6lo Expiration Time                 June 2017

                     Time Synchronized Network
                  -+---------------------------+-
                   |                           |
      DODAG1   +---+---+                   +---+---+   DODAG2
    Instance 1 | 6LBR1  |                  | 6LBR2 | Instance 2
               |       |                   |       |     |
               +-------+                   +-------+     |
           (F)/      /| \              (F)/      /| \    |
          /  \      / |  \            /  \      / |  \   |
         /    \   (C) |  (D)         /    \   (C) |  (D) |IP-in-IP
       (A)    (B) /   | / |\       (A)    (B) /   | / |\ | Encapsulation
       /|\     |\:   (E)  : :      /|\     |\:   (E)  : :|
      S : :    :     / \          : : :    :     / \     |
                    :   :                       :   R    V
   Network N1, time zone T1      NetWork N2, time zone T2

        Figure 6: Packet transmission in different DODAGs(N1 to N2)

   Consider an example of a 6TiSCH network in which S in DODAG1
   generates the packet at ASN 20000 to R in DODAG2.  Let the maximum
   allowable delay be 1 second.  The time-slot length in DODAG1 and
   DODAG2 is assumed to be 10ms.  Once the expiration time is encoded in
   Deadline-6LoRH, the packet is forwarded to LBR of DODAG1.  Suppose
   the packet reaches LBR of DODAG1 at ASN 20050.

      current_time = ASN at LBR * slot_length_value

      remaining_time = expiration_time - current_time
      = ((packet_origination_time + max_delay) - current time)
      = (20000 + 100) - 20050
      = 50 (in Network ASNs)
      = 50 * 10^3 milliseconds.

   The remaining time is encoded in In-Band OAM (see Case 2) and
   forwarded to LBR2 over a different L2-interface, typically wired.
   Once the packet reaches LBR2, the expiration time in Deadline-6LoRH
   is adjusted by adding or subtracting the difference between the
   reference clocks of the two networks, before forwarding the packet to
   its connected 6TiSCH network.

7.  IANA Considerations

   This document defines a new 6LoWPAN Timestamp Header Type, and
   assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space.

Lijo Thomas, et al.     Expires December 23, 2017               [Page 9]
Internet-Draft             6lo Expiration Time                 June 2017

                        6LoRH Type      Value
                   +------------------+--------+
                   | Deadline-6LoRH   | TBD    |
                   +------------------+--------+

                       Figure 7: Deadline-6LoRH type

8.  Security Considerations

   The security considerations of [RFC4944], [RFC6282] and [RFC6553]
   apply.  Using a compressed format as opposed to the full in-line
   format is logically equivalent and does not create an opening for a
   new threat when compared to [RFC6550], [RFC6553] and [RFC6554].

9.  Acknowledgements

   The authors thank Pascal Thubert for suggesting the idea and
   encouraging the work.  Thanks to Shwetha Bhandari's suggestions which
   were instrumental in extending the timing information to
   heterogeneous networks.  The authors acknowledge the 6TiSCH WG
   members for their inputs on the mailing list.  Special thanks to
   Jerry Daniel,Shalu Rajendran, Seema Kumar, Avinash Mohan and Anita
   Varghese for their support and valuable feedback.

10.  References

10.1.  Normative References

   [I-D.ietf-roll-routing-dispatch]
              Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
              "6LoWPAN Routing Header", draft-ietf-roll-routing-
              dispatch-05 (work in progress), October 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              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>.

Lijo Thomas, et al.     Expires December 23, 2017              [Page 10]
Internet-Draft             6lo Expiration Time                 June 2017

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., 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,
              DOI 10.17487/RFC6550, March 2012,
              <http://www.rfc-editor.org/info/rfc6550>.

   [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,
              DOI 10.17487/RFC6553, March 2012,
              <http://www.rfc-editor.org/info/rfc6553>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <http://www.rfc-editor.org/info/rfc6554>.

10.2.  Informative References

   [I-D.brockners-inband-oam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., <>, R., and d. daniel.bernier@bell.ca, "Data Fields
              for In-situ OAM", draft-brockners-inband-oam-data-05 (work
              in progress), May 2017.

   [I-D.grossman-detnet-use-cases]
              Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
              Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y.
              Zha, "Deterministic Networking Use Cases", draft-grossman-
              detnet-use-cases-01 (work in progress), November 2015.

   [I-D.ietf-6lo-backbone-router]
              Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
              backbone-router-03 (work in progress), January 2017.

   [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", draft-ietf-6tisch-terminology-09 (work in
              progress), June 2017.

   [I-D.ietf-roll-useofrplinfo]
              Robles, I., Richardson, M., and P. Thubert, "When to use
              RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
              useofrplinfo-14 (work in progress), April 2017.

Lijo Thomas, et al.     Expires December 23, 2017              [Page 11]
Internet-Draft             6lo Expiration Time                 June 2017

   [I-D.vilajosana-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-vilajosana-6tisch-minimal-00 (work
              in progress), October 2013.

Authors' Addresses

   Lijo Thomas
   C-DAC
   Trivandrum  695033
   India

   Email: lijo@cdac.in

   P.M. Akshay
   Indian Institute of Science
   Bangalore  560012
   India

   Email: akshaypm@ece.iisc.ernet.in

   Satish Anamalamudi
   Huaiyin Institute of Technology
   No.89 North Beijing Road, Qinghe District
   Huaian
   China

   Email: satishnaidu80@gmail.com

   S.V.R Anand
   Indian Institute of Science
   Bangalore  560012
   India

   Email: anand@ece.iisc.ernet.in

   Malati Hegde
   Indian Institute of Science
   Bangalore  560012
   India

   Email: malati@ece.iisc.ernet.in

Lijo Thomas, et al.     Expires December 23, 2017              [Page 12]
Internet-Draft             6lo Expiration Time                 June 2017

   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   Unites States

   Email: charliep@computer.org

Lijo Thomas, et al.     Expires December 23, 2017              [Page 13]