--- 1/draft-ietf-6tisch-6top-sf0-01.txt 2016-10-31 11:15:56.232160388 -0700 +++ 2/draft-ietf-6tisch-6top-sf0-02.txt 2016-10-31 11:15:56.260161088 -0700 @@ -1,35 +1,35 @@ 6TiSCH D. Dujovne, Ed. Internet-Draft Universidad Diego Portales -Intended status: Informational LA. Grieco -Expires: January 9, 2017 Politecnico di Bari +Intended status: Standards Track LA. Grieco +Expires: May 4, 2017 Politecnico di Bari MR. Palattella - University of Luxembourg + Luxembourg Institute of Science and Technology (LIST) N. Accettura - University of California Berkeley - July 8, 2016 + LAAS-CNRS + October 31, 2016 6TiSCH 6top Scheduling Function Zero (SF0) - draft-ietf-6tisch-6top-sf0-01 + draft-ietf-6tisch-6top-sf0-02 Abstract - This document defines a 6top Scheduling Function called "Scheduling - Function Zero" (SF0). SF0 dynamically adapts the number of reserved - cells between neighbor nodes, based on the currently allocated - bandwidth and the neighbour nodes' requirements. Neighbor nodes - negotiate in a distributed neighbor-to-neighbor basis the cell(s) to - be added/deleted. SF0 uses the 6P signaling messages to add/delete - cells in the schedule. Some basic rules for deciding when to add/ - delete cells and for selecting the cells to be added/deleted within - the schedule are also provided. + This document defines a Scheduling Function called "Scheduling + Function Zero" (SF0). SF0 dynamically adapts the number of allocated + cells between neighbor nodes, based on the amount of currently + allocated cells and the neighbor nodes' cell requirements. Neighbor + nodes negotiate in a distributed neighbor-to-neighbor basis the + number of cell(s) to be added/deleted. SF0 uses the 6P signaling + messages to add/delete cells in the schedule. This function selects + the candidate cells from the schedule, defines which cells will be + added/deleted and triggers the allocation/deallocation process. Requirements Language 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 RFC 2119 [RFC2119]. Status of This Memo @@ -38,151 +38,209 @@ 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 9, 2017. + This Internet-Draft will expire on May 4, 2017. 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 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. Scheduling Function Identifier . . . . . . . . . . . . . . . 3 - 3. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 3 - 3.1. SF0 Triggering Events . . . . . . . . . . . . . . . . . . 3 - 3.2. SF0 Bandwidth Estimation Algorithm . . . . . . . . . . . 3 - 3.3. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . 4 - 4. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 5 - 5. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Meaning of Metadata Information . . . . . . . . . . . . . . . 6 - 7. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 - 8. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 6 - 9. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 7 - 10. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 7 - 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 8 - 16.2. Informative References . . . . . . . . . . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 + 1. TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Scheduling Function Identifier . . . . . . . . . . . . . . . 4 + 4. SF0 Triggering Events . . . . . . . . . . . . . . . . . . . . 4 + 5. SF0 Cell Estimation Algorithm . . . . . . . . . . . . . . . . 5 + 6. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . . . 5 + 7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 6 + 8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 7 + 9. Meaning of Metadata Information . . . . . . . . . . . . . . . 7 + 10. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 7 + 11. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 7 + 12. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 8 + 13. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 + 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 + 16. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 18. 6P Compliance . . . . . . . . . . . . . . . . . . . . . . . . 9 + 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 + 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 20.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 20.2. Informative References . . . . . . . . . . . . . . . . . 10 + Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 -1. Introduction +1. TEMPORARY EDITORIAL NOTES - This document defines the Scheduling Function for the 6top sublayer - [I-D.wang-6tisch-6top-sublayer] called "Scheduling Function Zero" - (SF0). + This document is an Internet Draft, so it is work-in-progress by + nature. It contains the following work-in-progress elements: - This document addresses the requirements for a scheduling function - listed in [I-D.wang-6tisch-6top-sublayer], Section 4.2, and follows - the recommended outline from Section 4.3. This draft agrees with the - terminology defined on [I-D.ietf-6tisch-terminology] and is designed - within the context of [RFC7554] + o "TODO" statements are elements which have not yet been written by + the authors for some reason (lack of time, ongoing discussions + with no clear consensus, etc). The statement does indicate that + the text will be written at some time. + o "TEMPORARY" appendices are there to capture current ongoing + discussions, or the changelog of the document. These appendices + will be removed in the final text. + o "IANA_" identifiers are placeholders for numbers assigned by IANA. + These placeholders are to be replaced by the actual values they + represent after their assignment by IANA. + o The string "REMARK" is put before a remark (questions, suggestion, + etc) from an author, editor of contributor. These are on-going + discussions at the time to writing, NOT part of the final text. + o This section will be removed in the final text. -2. Scheduling Function Identifier +2. Introduction - The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0. + This document defines a minimal Scheduling Function for the 6top + sublayer [I-D.ietf-6tisch-6top-protocol], called "Scheduling Function + Zero" (SF0). SF0 is designed to offer the minimal set of + functionalities to be usable in a wide range of applications. SF0 + defines two algorithms: The Scheduling Algorithm defines the number + of cells to allocate/delete between two neighbours and the relocation + algorithm defines when to relocate a cell. -3. Rules for Adding/Deleting Cells + The Scheduling Algorithm: A number of TX and/or RX cells must be + allocated between neighbor nodes in order to enable data transmission + among them. From the allocated cells, a part of them can be under + effective use by the neighbours, while the rest of cells are over- + provisioned to detect an increase in cell usage without packet loss. + The Scheduling Algorithm collects the cell allocation/deletion + requests from the neighbors and the number of cells which are + currently under usage. First, a Cell Estimation Algotithm calculates + the number of required cells by adding the collected values and + second, the calculated value is given to the Allocation Policy, which + provides stability by adding hystheresis and overprovisioning by + deciding when to schedule the new number of cells, according to a + threshold. In order to reduce consumption, this algorithm is + triggered only when there is a change on the number of effectively + used cells or if there is a change on the number of requested cells + from a particular node. - A node running SF0 determines when to add/delete cells in a three- - step process: + The Relocation Algorithm: Allocated cells may experiment packet loss + from different sources, such as noise, interference or cell collision + (after the same cell is allocated by other nodes in range on the + network). In order to avoid this problem, Packet Delivery Rate (PDR) + is monitored periodically for each allocated cell. A relocation is + triggered when the PDR value drops below a certain threshold, + compared to the average PDR of the rest of allocated cells. The + destination location on the schedule is defined randomly. - 1. It waits for a triggering event (Section 3.1). - 2. It applies the Bandwidth Estimation Algorithm (BEA) for a - particular neighbor to determine how much bandwidth is required - to that neighbor (Section 3.2). + To synthesize, a node running SF0 determines when to add/delete cells + in a three-step process: + + 1. It waits for a triggering event (Section 4). + 2. It applies the Cell Estimation Algorithm (CEA) for a particular + neighbor to determine how many cells are required to that + neighbor (Section 5). 3. It applies the Allocation Policy to compare the number of required cells to the number of already scheduled cells, and - determine the number of cells to add/delete (Section 3.3). + determines the number of cells to add/delete (Section 6). -3.1. SF0 Triggering Events + We expect additional SFs, offering more functionalities for a more + specific use case, to be defined in future documents. SF0 addresses + the requirements for a scheduling function listed in Section 5.2 + [TODO: update if needed] from [I-D.ietf-6tisch-6top-protocol], and + follows the recommended outline listed in Section 5.3 [TODO: update + if needed] of [I-D.ietf-6tisch-6top-protocol]. This document follows + the terminology defined in [I-D.ietf-6tisch-terminology]. + +3. Scheduling Function Identifier + + The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0. + +4. SF0 Triggering Events We RECOMMEND SF0 to be triggered at least by the following events: - 1. If there is a change in the Current Outgoing Bandwidth Usage - (COBU) - 2. If there is any New Incoming Bandwidth Requirements from - neighbour nodes (NIBR) + 1. If there is a change in the current number of used cells + 2. If there is a successful cell allocation/deallocation process + with the neighbour. - This allows SF0 to be triggered by any change in local outgoing - bandwidth and/or incoming bandwidth. A relocation request from the - neighbour is considered as an Incoming Bandwidth Request, given that - it is expected to increase packet delivery rate on the relocated - cells, thus increasing the required bandwidth. The exact mechanism - of when SF0 is triggered is implementation-specific. + This allows SF0 to be triggered by any change in locally generated or + incoming traffic. The exact mechanism of when SF0 is triggered is + implementation-specific. -3.2. SF0 Bandwidth Estimation Algorithm +5. SF0 Cell Estimation Algorithm - The Bandwidth Estimation Algorithm takes into account the sum of the - incoming bandwidth requirements from the neighbour nodes and also the - current outgoing bandwidth value. This allows the node to estimate - the total outgoing bandwidth requirement. As a consequence, the - Bandwidth Estimation Algorithm for SF0 follows the steps described + The Cell Estimation Algorithm takes into account the new incoming + cell requirements from the neighbor node and the current outgoing + number of effectively used cells. This allows the algorithm to + estimate a new number of cells to be allocated. As a consequence, + the Cell Estimation Algorithm for SF0 follows the steps described below: - 1. Collect the New Incoming Bandwidth Requirements from neighbour - nodes (NIBR) - 2. Obtain the Current Outgoing Bandwidth Usage (COBU) - 3. Calculate the New Outgoing Bandwidth (NOB) as: NOB=COBU+NIBR - 4. Submit the request to the allocation policy + 1. Collect the new incoming cell requirements from the neighbor + 2. Collect the current number of effectively used cells + 3. Calculate the new number of cells to be allocated by adding the + current number of effectively used cells and the new incoming + cells requirement + 4. Submit the request to the allocation policy as REQUIREDCELLS 5. Return to step 1 and wait for a triggering event. -3.3. SF0 Allocation Policy + A new incoming cell requirement is the result of a successful + allocation process from the neighbor. TODO/REMARK: Add a number of + cells to the required cells as OVERPROVISION to guarantee that the + growth on the effectively used cells can be identified without packet + loss. This value is implementation specific. A value of + OVERPROVISION equal to zero leads to queue growth and possible packet + loss, since there are no overprovisioned cells to detect if there is + a growth of effectively used cells. + +6. SF0 Allocation Policy The "Allocation Policy" is the set of rules used by SF0 to decide - when to add/delete cells to a particular neighbor to satisfy the - bandwidth requirements. + when to add/delete cells to a particular neighbor to satisfy the cell + requirements. SF0 uses the following parameters: SCHEDULEDCELLS: The number of cells scheduled from the current node to a particular neighbor. - REQUIREDCELLS: The number of cells calculated by the Bandwidth - Estimation Algorithm from the current node to that neighbor. + REQUIREDCELLS: The number of cells calculated by the Cell Estimation + Algorithm from the current node to that neighbor. SF0THRESH: Threshold parameter introducing cell over-provisioning in the allocation policy. It is a non-negative value expressed as number of cells. The definition of this value is implementation- specific. A setting of SF0THRESH>0 will cause the node to - allocate at least SF0THRESH cells to each of its' neighbours. + allocate at least SF0THRESH cells to each of its' neighbors. The SF0 allocation policy compares REQUIREDCELLS with SCHEDULEDCELLS and decides to add/delete cells taking into account SF0THRESH. This is illustrated in Figure 1. SCHEDULEDCELLS <---------------------------------> +---+---+---+---+---+---+---+---+---+ | | | | | | | | | | +---+---+---+---+---+---+---+---+---+ - |<--------->| + |<----------------->| | SF0THRESH | | | REQUIREDCELLS | | +---+---+ | | DELETE | | | | | ONE/MORE +---+---+ | | CELLS | | REQUIREDCELLS | +---+---+---+---+---+---+ | DO | | | | | | | | NOTHING @@ -198,120 +256,121 @@ 1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more cells. 2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do nothing. 3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells. When SF0THRESH equals 0, any discrepancy between REQUIREDCELLS and SCHEDULEDCELLS triggers an action to add/delete cells. Positive values of SF0THRESH reduce the number of 6P Transactions. - The Allocation Policy also translates the bandwidth requirement into - cells according to their PDR. For example, if a cell with a 100% PDR - is equivalent to 1Kbps, and the required bandwith is 8Kbps, then, the - number of scheduled cells will be 8. However, if two of the - allocated cells have a 70% PDR, there number of scheduled cells will - be 9. - -4. Rules for CellList +7. Rules for CellList - When issuing a 6top ADD Request, SF0 executes the following sequence: + There are two methods to define the CellList: The Whitelist method, + which fills the CellList with the number of proposed cells to the + neighbour, and the Blacklist, which fills the CellList with the cells + which cannot be used by the neighbour. The rule to select the method + is implementation-specific. When issuing a 6top ADD Request, SF0 + executes the following sequence: Whitelist case: The Transaction Source node: Prepares the CellList field by selecting randomly the required cells, verifying that the slot offset and channel offset are not occupied and choose channelOffset randomly for each cell. The Transaction Destination node: Goes through the cells in the CellList in order, verifying whether there are no slotOffset conflicts. Blacklist case: The Transaction Source node: Prepares the CellList field by building a list of currently scheduled cells into the CellList. The Transaction Destination node: Selects randomly the required cells from the unallocated cells on the schedule, verifying that the slot offset and channel offset are not occupied from the ones on the CellList. -5. 6P Timeout Value +8. 6P Timeout Value The general timeout equals the equivalent time of the number of slots - until the next scheduled cell. + until the next scheduled cell. TODO/REMARK: The exact calculation is + currently under discussion on the Mailing List. -6. Meaning of Metadata Information +9. Meaning of Metadata Information The Metadata 16-bit field is used as follows: BITS 0-7 [SLOTFRAME] are used to identify the slotframe number BITS 8-14 are RESERVED BIT 15 [WBLIST] is used to indicate that the CellList provided is a Whitelist (value=0) or a Blacklist (value=1). - TODO: length of the SlotFrame SHOULD be an integer multiple of the - length of the minimal SlotFrame. - -7. Node Behavior at Boot +10. Node Behavior at Boot In order to define a known state after the node is restarted, a CLEAR - command is issued to each of the neighbour nodes to enable a new + command is issued to each of the neighbor nodes to enable a new allocation process. The 6P Initial Timeout Value provided by SF0 - allows the maximum number of TSCH link-layer retries. Given the TSCH - parameters for the backoff mechanism, macMinBE and macMaxBE, and the - length in seconds of the minimal Slotframe, SM, the timeout value is - computed as: timeout = (2^(macMaxBE+1)-2^macMinBE) * SM + should allow for the maximum number of TSCH link-layer retries, as + defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol]. TODO/ + REMARK: The initial timeout is currently under discussion. -8. Relocating Cells +11. Relocating Cells SF0 uses Packet Delivery Rate (PDR) statistics to monitor the - currently allocated cells for cell re-allocation (by changing their - slotOffset and/or channelOffset) when it finds out that the PDR of - one or more softcells below 20% of the average PDR. + currently allocated cells for cell relocation (by changing their + slotOffset and/or channelOffset). When the PDR of one or more + softcells is below 20% of the average PDR of the rest of the + scheduled cells, SF0 relocates the cell(s) to a number of available + cells selected randomly. REMARK: This criteria is currently under + discussion; simulation/experimentation is required to either adjust + the threshold or to change the process. -9. Forced Cell Deletion Policy +12. Forced Cell Deletion Policy TODO: When all the cells are scheduled, we need a policy to free - cells, for example, under alarm conditions or if a node dissappears - from the neighbour list. + cells, for example, under alarm conditions or if a node disappears + from the neighbor list. -10. 6P Error Handling +13. 6P Error Handling A node implementing SF0 handles a 6P Response depending on the Return Code it contains: RC_SUCCESS: If the number of elements in the CellList is the number of cells - specified in the NumCells field of the 6P ALL Request, the + specified in the NumCells field of the 6P ADD Request, the operation is complete. The node does not take further action. If the number of elements in the CellList is smaller (possibly 0) than the number of cells specified in the NumCells field of the 6P - ALL Request, the neighbor has received the request, but less than + ADD Request, the neighbor has received the request, but less than NumCells of the cells in the CellList were. In that case, the node MAY retry immediately with a different CellList if the amount of storage space permits, or build a new (random) CellList. - RC_VER_ERR: The node MUST NOT retry immediately. The node MAY add - the neighbor node on a blacklist. The node MAY retry to contact + RC_ERR_VER: The node MUST NOT retry immediately. The node MAY add + the neighbor node to a blacklist. The node MAY retry to contact this neighbor later. - RC_SFID_ERR: The node MUST NOT retry immediately. The node MAY add - the neighbor node on a blacklist. The node MAY retry to contact + RC_ERR_SFID: The node MUST NOT retry immediately. The node MAY add + the neighbor node to a blacklist. The node MAY retry to contact this neighbor later. - RC_BUSY: Wait for a timeout and restart the scheduling process. - RC_RESET: Abort 6P Transaction + RC_ERR_GEN: The node MUST issue a CLEAR command tot he neighbour. + RC_ERR_BUSY: Wait for a timeout and restart the scheduling process. + RC_ERR_NORES: Wait for a timeout and restart the scheduling process. + RC_ERR_RESET: Abort 6P Transaction RC_ERR: Abort 6P Transaction. The node MAY retry to contact this neighbor later. -11. Examples +14. Examples TODO -12. Implementation Status +15. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not @@ -326,78 +385,109 @@ It is up to the individual working groups to use this information as they see fit". OpenWSN: This specification is implemented in the OpenWSN project [OpenWSN]. The authors of this document are collaborating with the OpenWSN community to gather feedback about the status and performance of the protocols described in this document. Results from that discussion will appear in this section in future revision of this specification. -13. Security Considerations +16. Security Considerations TODO -14. IANA Considerations +17. IANA Considerations o IANA_SFID_SF0 -15. Acknowledgments +18. 6P Compliance + + o MUST specify an identifier for that SF. OK + o MUST specify the rule for a node to decide when to add/delete one + or more cells to a neighbor. OK + o MUST specify the rule for a Transaction source to select cells to + add to the CellList field in the 6P ADD Request. OK + o MUST specify the rule for a Transaction destination to select + cells from CellList to add to its schedule. OK + o MUST specify a value for the 6P Timeout, or a rule/equation to + calculate it. + o MUST specify a meaning for the "Metadata" field in the 6P ADD + Request. OK + o MUST specify the behavior of a node when it boots. OK + o MUST specify what to do after an error has occurred (either the + node sent a 6P Response with an error code, or received one). OK + o MUST specify the list of statistics to gather. An example + statistic if the number of transmitted frames to each neighbor. + In case the SF requires no statistics to be gathered, the specific + of the SF MUST explicitly state so. + + o SHOULD clearly state the application domain the SF is created for. + OK + o SHOULD contain examples which highlight normal and error + scenarios. + o SHOULD contain a list of current implementations, at least during + the I-D state of the document, per [RFC6982]. + o SHOULD contain a performance evaluation of the scheme, possibly + through references to external documents. + o MAY redefine the format of the CellList? field. + +19. Acknowledgments Thanks to Kris Pister for his contribution in designing the default Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas Watteyne for their support in defining the interaction between SF0 and the 6top sublayer. This work is partially supported by the Fondecyt 1121475 Project, the Inria-Chile "Network Design" group, and the IoT6 European Project (STREP) of the 7th Framework Program (Grant 288445). -16. References +20. References -16.1. Normative References +20.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . -16.2. Informative References - - [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using - IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the - Internet of Things (IoT): Problem Statement", RFC 7554, - DOI 10.17487/RFC7554, May 2015, - . +20.2. Informative References [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 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", draft-ietf-6tisch-terminology-07 (work in progress), March 2016. - [I-D.wang-6tisch-6top-sublayer] - Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer - (6top)", draft-wang-6tisch-6top-sublayer-04 (work in - progress), November 2015. + [I-D.ietf-6tisch-6top-protocol] + Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- + ietf-6tisch-6top-protocol-02 (work in progress), July + 2016. [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: a Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies , August 2012. +Appendix A. [TEMPORARY] Changelog + + o draft-ietf-6tisch-6top-sf0-02 + + * Editorial changes (figs, typos, ...) + Authors' Addresses Diego Dujovne (editor) Universidad Diego Portales Escuela de Informatica y Telecomunicaciones Av. Ejercito 441 Santiago, Region Metropolitana Chile Phone: +56 (2) 676-8121 @@ -406,27 +497,26 @@ Politecnico di Bari Department of Electrical and Information Engineering Via Orabona 4 Bari 70125 Italy Phone: 00390805963911 Email: a.grieco@poliba.it Maria Rita Palattella - University of Luxembourg - Interdisciplinary Centre for Security, Reliability and Trust - 4, rue Alphonse Weicker - Luxembourg L-2721 - LUXEMBOURG - - Phone: (+352) 46 66 44 5841 - Email: maria-rita.palattella@uni.lu + Luxembourg Institute of Science and Technology (LIST) + Department 'Environmental Research and Innovation' (ERIN) + 41, rue du Brill + Belvaux L-4422 + Grand-duchy of Luxembourg + Phone: +352 275 888-5055 + Email: mariarita.palattella@list.lu Nicola Accettura - University of California Berkeley - Berkeley Sensor & Actuator Center - 490 Cory Hall - Berkeley, California 94720 - USA + LAAS-CNRS + 7, avenue du Colonel Roche + Toulouse 31400 + France - Email: nicola.accettura@eecs.berkeley.edu + Phone: +33 5 61 33 69 76 + Email: nicola.accettura@laas.fr