idnits 2.17.1 draft-ietf-6tisch-terminology-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2016) is 2952 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 580, but not defined == Unused Reference: 'RFC5191' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC7252' is defined on line 534, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-07) exists of draft-thubert-6lo-rfc6775-update-reqs-06 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH MR. Palattella, Ed. 3 Internet-Draft SnT/Univ. of Luxembourg 4 Intended status: Informational P. Thubert 5 Expires: September 22, 2016 cisco 6 T. Watteyne 7 Linear Technology / Dust Networks 8 Q. Wang 9 Univ. of Sci. and Tech. Beijing 10 March 21, 2016 12 Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e 13 draft-ietf-6tisch-terminology-07 15 Abstract 17 6TiSCH proposes an architecture for an IPv6 multi-link subnet that is 18 composed of a high speed powered backbone and a number of 19 IEEE802.15.4e TSCH wireless networks attached and synchronized by 20 backbone routers. This document extends existing terminology 21 documents available for Low-power and Lossy Networks to provide 22 additional terminology elements. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in RFC 29 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 22, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 6.2. Informative References . . . . . . . . . . . . . . . . . 12 73 6.3. External Informative References . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 The IEEE802.15.4 Medium Access Control (MAC) has evolved with 79 IEEE802.15.4e which provides in particular the Time Slotted Channel 80 Hopping (TSCH) mode for industrial-type applications. It provides 81 deterministic capabilities to the point that a packet that pertains 82 to a certain flow crosses the network from node to node following a 83 very precise schedule, like a train leaves intermediate stations at 84 precise times along its path. 86 This document provides additional terminology elements to cover terms 87 that are new to the context of TSCH wireless networks and other 88 deterministic networks. 90 2. Terminology 92 The draft extends [I-D.ietf-roll-terminology] and use terms from RFC 93 6550 [RFC6550] and RFC 6552 [RFC6552], which are all included here by 94 reference. 96 The draft does not reuse terms from IEEE802.15.4e such as "path" or 97 "link" which bear a meaning that is quite different from classical 98 IETF parlance. 100 This document adds the following terms: 102 6TiSCH: IPv6 over the Timeslotted Channel Hopping (TSCH) mode of 103 IEEE802.15.4e. It defines (i)the 6top sublayer; (ii) a 104 set of protocols for setting up a TSCH schedule with a 105 centralized and/or distributed approach, for managing the 106 allocation of resources; and (iii) the architecture to 107 bind them together, for use in IPv6 TSCH based networks. 109 6F: IPv6 Forwarding. One of the three forwarding models 110 supported by 6TiSCH. Packets are routed at layer 3, 111 where Quality of Service (QoS) and Active Queue 112 Management (e.g., Random Early Detection, RED, [RFC2309]) 113 operations are expected to prioritize flows with 114 differentiated services. 116 6top: The "6TiSCH Operation Sublayer" (6top) is the next 117 highest layer of the IEEE802.15.4e TSCH medium access 118 control layer in the 6TiSCH Architecture. It implements 119 and terminates the "6top Protocol" (6P), and contains one 120 or more "6top Scheduling Function" (SF). It is defined 121 in [I-D.wang-6tisch-6top-protocol]. 123 6top Data Convey Model: Model describing how the 6top adaptation 124 layer feeds the data flow coming from upper layers into 125 TSCH. It is composed by an I-MUX module, a MUX module, a 126 set of priority queues, and a PDU (Payload Data Unit). 127 See [I-D.wang-6tisch-6top-protocol]. 129 SF: The "6top Scheduling Function" (SF) is the policy inside 130 the "6TiSCH Operation Sublayer" (6top) which decides when 131 to add/remove cells. General guidelines for designing a 132 SF are provided in [I-D.wang-6tisch-6top-protocol]. 134 SFID: The "6top Scheduling Function Identifier" (SFID) is a 135 1-byte field identifying a SF. It is defined in 136 [I-D.wang-6tisch-6top-protocol]. 138 6P: The "6top Protocol" (6P) allows neighbor nodes to 139 communicate to add/delete cells to one another in their 140 TSCH schedule. It is defined in 141 [I-D.wang-6tisch-6top-protocol]. 143 6P Transaction: Part of the "6top Protocol" (6P), it consists in a 144 complete negotiation between two neighbor nodes. A 145 transaction starts when a node wishes to add/delete one 146 or more cells to one of its neighbors; it ends when the 147 cell(s) have been added / deleted from the schedule of 148 both neighbor, or when the transaction has failed. It is 149 defined in [I-D.wang-6tisch-6top-protocol]. 151 ARO: [RFC6775] defines a number of new Neighbor Discovery 152 options including the Address Registration Option (ARO). 154 ASN: Absolute Slot Number, the total number of timeslots that 155 has elapsed since the PAN coordinator has started the 156 TSCH network. It is incremented by one at each timeslot. 157 It is wide enough to not roll over in practice. See 158 [IEEE802154e]. 160 Blacklist of Frequencies: Simply defined Blacklist in [IEEE802154e], 161 it is the set of frequencies among the 16 available ones, 162 which should not be used for communication. 164 BBR: Backbone Router. In the 6TiSCH architecture, it is an 165 LBR and also a IPv6 ND-efficiency-aware Router (NEAR) 166 [I-D.chakrabarti-nordmark-6man-efficient-nd]. It 167 performs ND proxy operations between registered devices 168 and classical ND devices that are located over the 169 backbone. 171 Broadcast Cell: A scheduled cell used for broadcast transmission. 173 Bundle: A group of equivalent scheduled cells, i.e. cells 174 identified by different [slotOffset, channelOffset], 175 which are scheduled for a same purpose, with the same 176 neighbor, with the same flags, and the same slotframe. 177 The size of the bundle refers to the number of cells it 178 contains. Given the length of the slotframe, the size of 179 the bundle translates directly into bandwidth. A bundle 180 represents a half-duplex link between nodes, one 181 transmitter and one or more receivers, with a bandwidth 182 that amount to the sum of the cells in the bundle. A 183 bundle is globally identified by (source MAC, destination 184 MAC, TrackID). At Layer 3 a pair of bundles forms a 185 link. By usining a well-known constant, NULLT, as 186 TrackId for a L3 link, the IP link between adjacent nodes 187 A and B comprises 2 bundles: (macA, macB, NULLT) and 188 (macB, macA, NULLT). At L2 a pair of bundles forms a 189 switching state. Considered a segment A-B-C along a 190 track, there are two bundles in node B, one incoming = 191 (macA, macB, trackId) and one outgoing = (macB, macC, 192 trackId). 194 Cell: A single element in the TSCH schedule, identified by a 195 slotOffset, a channelOffset, a slotframeHandle. A cell 196 can be scheduled or unscheduled. 198 Centralized Cell Reservation: A reservation of a cell done by a 199 centralized entity (e.g., a PCE) in the network. 201 Centralized Track Reservation: A reservation of a track done by a 202 centralized entity (e.g., a PCE) in the network. 204 ChannelOffset: Identifies a row in the TSCH schedule. The number of 205 available channelOffsets is equal to the number of 206 available frequencies. The channelOffset translates into 207 a frequency when the communication takes place, resulting 208 in channel hopping, as detailed in [RFC7554]. 210 Channel Distribution/Usage (CDU) matrix: : Matrix of cells (i,j) 211 representing the spectrum (channel) distribution among 212 the different nodes in the 6TiSCH network. The CDU 213 matrix has width in timeslots, equal to the period of the 214 network scheduling operation, and height equal to the 215 number of available channels. Every cell (i,j) in the 216 CDU, identified by (slotOffset, channelOffset), belongs 217 to a specific chunk. It has to be noticed that such a 218 matrix which includes all the cells grouped in chunks, 219 belonging to different slotframes, is different from the 220 TSCH schedule. 222 Chunk: A well-known list of cells, distributed in time and 223 frequency, within a CDU matrix; a chunk represents a 224 portion of a CDU matrix. The partition of the CDU in 225 chunks is globally known by all the nodes in the network 226 to support the appropriation process, which is a 227 negotiation between nodes within an interference domain. 228 A node that manages to appropriate a chunk gets to decide 229 which transmissions will occur over the cells in the 230 chunk within its interference domain (i.e., a parent node 231 will decide when the cells within the appropriated chunk 232 are used and by which node, among its children.) 234 Communication Paradigm: It is Associated with the Information Model 235 [RFC3444] of the state that is exchanged, and indicates: 236 the location of that state (e.g., centralized vs. 237 distributed, RESTful, etc.), the numbers of parties 238 (e.g., point to point, P2P, vs. point to multi-point, 239 P2MP) and the relationship between parties (e.g., master/ 240 slave vs. peers) at a high level of protocol abstraction. 241 Layer 5 client/server REST is a typical communication 242 paradigm, but industrial protocols also use publish/ 243 subscribe which is P2MP and source/sink which is multi- 244 point to multi-point (MP2MP) and primarily used for 245 alarms and alerts at the application layer. At layer 3, 246 basic flooding, P2P synchronization and path-marking 247 (RSVP-like) are commonly used paradigms, whereas at layer 248 2, master/slave polling and peer-to-peer forwarding are 249 classical examples. 251 DAR/DAC: [RFC6775] defines the Duplicate Address Request (DAR) and 252 Duplicate Address Confirmation (DAC) options to turn the 253 multicast Duplicate Address Detection protocol into a 254 unicast-based multi-hop process between routers and the 255 backbone router. 257 Dedicated Cell: A cell that is reserved for a given node to transmit 258 to a specific neighbor. 260 Deterministic Network: A Deterministic Network supports traffic 261 flows with communication patterns that are known a 262 priori. Thus, routing paths and communication schedules 263 can be computed in advance, in a fashion similar to a 264 railway system, to avoid losses due to packet collisions, 265 and to perform global optimizations across multiple 266 flows. A deterministic network can allocates the 267 required resources (buffers, processors, medium access) 268 along the multi-hop routing path at the precise moment 269 the resources are needed. 271 Distributed Cell Reservation: A reservation of a cell done by one or 272 more in-network entities (typically a connection 273 endpoint). 275 Distributed Track Reservation: A reservation of a track done by one 276 or more in-network entities (typically a connection 277 endpoint). 279 EARO: [I-D.thubert-6lo-rfc6775-update-reqs] extends the ARO 280 option to include some additional fields necessary to 281 distinguish duplicate addresses from nodes that have 282 moved networks when there are mulitple LLNs linked over a 283 backbone. 285 EB: Enhanced Beacon frame used by a node to announce the 286 presence of the network. It contains useful information 287 (see [IEEE802154e] for details) that allow a new node to 288 synhronize and join the network. 290 FF: 6LoWPAN Fragment Forwarding. It is one of the three 291 forwarding models supported by 6TiSCH. The 6LoWPAN 292 Fragment is used as a label for switching at the 6LoWPAN 293 sublayer, as defined in 294 [I-D.thubert-roll-forwarding-frags]. 296 GMPLS: Generalized Multi-Protocol Label Switching, a 2.5 layer 297 service that is used to forward packets based on the 298 concept of generalized labels. 300 Hard Cell: A scheduled cell which the 6top sublayer cannot 301 reallocate. See [I-D.wang-6tisch-6top-protocol]. 303 Hopping Sequence: Ordered sequence of frequencies, identified by a 304 Hopping_Sequence_ID, used for channel hopping, when 305 translating the channel offset value into a frequency 306 (i.e., PHY channel). See [IEEE802154e] and [RFC7554]. 308 IE: Information Elements, a list of Type-Length-Value 309 containers placed at the end of the MAC header, used to 310 pass data between layers or devices. A small number of 311 types are defined by [IEEE802154e], but a range of types 312 is available for extensions, and thus, is exploitable by 313 6TiSCH. See [IEEE802154e]. 315 I-MUX module: Inverse-Multiplexer, a classifier that receives 316 6LoWPAN frames and places them into priority queues. See 317 [I-D.wang-6tisch-6top-protocol]. 319 Interaction Model: It is a particular way of implementing a 320 communication paradigm. Defined at a lower level of 321 abstraction, it includes protocol-specific details such 322 as a particular method (e.g., a REST GET) and a Data 323 Model for the state to be exchanged. 325 Interference Domain: The Interference Domain of a given 326 (transmitter) node A includes all the nodes in its 327 neighbourhood that can generate interference at its 328 receiver B, when transmitting on the same channel (i.e., 329 using the same frequency). 331 JCE: The Join Coordination Entity (JCE) is a central entity 332 like the Path Computation Element (PCE), that may assist 333 in several aspects of the join protocol, such as 334 authentication, authorization, and configuration. 336 JA: The Join Assistant (JA) is a one-hop neighbor of a 337 joining node that may facilitate it to become meaningful 338 part of the network (e.g., by serving as a local 339 connectivity point to the remainder of the network). 341 Join Protocol: The protocol which secures initial communication 342 between a joining node and the JCE. 344 LBR: Low-power Lossy Network (LLN) Border Router. It is an 345 LLN device, usually powered, that acts as a Border Router 346 to the outside within the 6TiSCH architecture. 348 Link: A communication facility or medium over which nodes can 349 communicate at the link layer, i.e., the layer 350 immediately below IP. Thus, the IETF parlance for the 351 term "Link" is adopted, as opposed to the IEEE802.15.4e 352 terminology. In the context of the 6TiSCH architecture, 353 which applies to Low Power Lossy Networks (LLNs), an IPv6 354 subnet is usually not congruent to a single link and 355 techniques such as IPv6 Neighbor Discovery Proxying are 356 used to achieve reachability within the multilink subnet. 357 A link is distinct from a track. In fact, link local 358 addresses are not expected to be used over a track for 359 end to end communication. Finally, from the Layer 3 360 perspective (where the inner complexities of TSCH 361 operations are hidden to enable classical IP routing and 362 forwarding), a single radio interface may be seen as a 363 number of Links with different capabilities for unicast 364 or multicast services. 366 MAC: Medium Access Control. 368 MUX Module: Multiplexer, the entity that dequeues frames from 369 priority queues and associates them to a cell for 370 transmission. See [I-D.wang-6tisch-6top-sublayer]. 372 NEAR: IPv6 ND-efficiency-aware Router, as defined in 373 [I-D.chakrabarti-nordmark-6man-efficient-nd]. 375 NME: Network Management Entity, the entity in the network 376 managing cells and other device resources. It may 377 cooperate with the PCE. It interacts with LLN nodes 378 through the backbone router. 380 Operational Network: A IEEE802.15.4e network whose encryption/ 381 authentication keys are determined by some algorithms/ 382 protocols. There may be network-wide group keys, or per- 383 link keys. 385 Operational Network Key: A Link-layer key known by all authorized 386 nodes, used for multicast messages. 388 PCE: Path Computation Element, the entity in the network which 389 is responsible for building and maintaining the TSCH 390 schedule, when centralized scheduling is used. 392 QoS: Quality of Service. 394 (to) Reallocate a Cell: The action operated by the 6top sublayer of 395 changing the slotOffset and/or channelOffset of a soft 396 cell. 398 (to) Schedule a Cell: The action of turning an unscheduled cell into 399 a scheduled cell. 401 Scheduled cell: A cell which is assigned a neighbor MAC address 402 (broadcast address is also possible), and one or more of 403 the following flags: TX, RX, shared, timeskeeping. A 404 scheduled cell can be used by the IEEE802.15.4e TSCH 405 implementation to communicate. A scheduled cell can be 406 either a hard or a soft cell. 408 Shared Cell: A cell marked with both the "TX" and "shared" flags. 409 This cell can be used by more than one transmitter node. 410 A backoff algorithm is used to resolve contention. See 411 [RFC7554]. 413 SlotOffset: Identifies a column in the TSCH schedule, i.e., the 414 number of timeslots since the beginning of the current 415 iteration of the slotframe. 417 Slotframe: A MAC-level abstraction that is internal to the node and 418 contains a series of timeslots of equal length and 419 priority. It is characterized by a slotframe_ID, and a 420 slotframe_size. Multiple slotframes can coexist in a 421 node's schedule, i.e., a node can have multiple 422 activities scheduled in different slotframes, based on 423 the priority of its packets/traffic flows. The timeslots 424 in the Slotframe are indexed by the SlotOffset; the first 425 timeslot is at SlotOffset 0. 427 Soft Cell: A scheduled cell which the 6top sublayer can reallocate, 428 as described in [I-D.wang-6tisch-6top-protocol]. 430 TF: Track Forwarding. It is the simplest and fastest 431 forwarding model supported by 6TiSCH. It is a GMPLS-like 432 forwarding model. The incoming bundle (and thus, the 433 input cell) characterizes the flow and indicates the 434 outgoing bundle (and output cell). 436 Timeslot: A basic communication unit in TSCH which allows a 437 transmitter node to send a frame to a receiver neighbor, 438 and that receiver neighbor to optionally send back an 439 acknowledgment. 441 Time Source Neighbor: A neighbor that a node uses as its time 442 reference, and to which it needs to keep its clock 443 synchronized. A node can have one or more time source 444 neighbors. 446 Track: A determined sequence of cells along a multi-hop path. 447 It is typically the result of a track reservation. The 448 node that initializes the process for establishing a 449 track is the owner of the track. The latter assigns a 450 unique identifier to the track, called TrackID. 452 TrackID: Unique identifier of a track, assigned by the owner of 453 the track. 455 TSCH: Time Slotted Channel Hopping, a medium access mode of the 456 [IEEE802154e] standard which uses time synchronization to 457 achieve ultra low-power operation and channel hopping to 458 enable high reliability. 460 TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset 461 and a channelOffset. The TSCH schedule contains all the 462 scheduled cells from all slotframes and is sufficient to 463 qualify the communication in the TSCH network. The 464 "width of the matrix is equal to the number of scheduled 465 timeslots in all the concurrent active slotframes. The 466 number of channelOffset values (the "height" of the 467 matrix) is equal to the number of available frequencies. 469 Unscheduled Cell: A cell which is not used by the IEEE802.15.4e TSCH 470 implementation. 472 3. IANA Considerations 474 This specification does not require IANA action. 476 4. Security Considerations 478 This specification is not found to introduce new security threats. 480 5. Acknowledgments 482 Thanks to the IoT6 European Project (STREP) of the 7th Framework 483 Program (Grant 288445). 485 6. References 487 6.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 495 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 496 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 497 S., Wroclawski, J., and L. Zhang, "Recommendations on 498 Queue Management and Congestion Avoidance in the 499 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 500 . 502 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 503 Information Models and Data Models", RFC 3444, 504 DOI 10.17487/RFC3444, January 2003, 505 . 507 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 508 and A. Yegin, "Protocol for Carrying Authentication for 509 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 510 May 2008, . 512 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 513 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 514 January 2012, . 516 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 517 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 518 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 519 Low-Power and Lossy Networks", RFC 6550, 520 DOI 10.17487/RFC6550, March 2012, 521 . 523 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 524 Protocol for Low-Power and Lossy Networks (RPL)", 525 RFC 6552, DOI 10.17487/RFC6552, March 2012, 526 . 528 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 529 Bormann, "Neighbor Discovery Optimization for IPv6 over 530 Low-Power Wireless Personal Area Networks (6LoWPANs)", 531 RFC 6775, DOI 10.17487/RFC6775, November 2012, 532 . 534 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 535 Application Protocol (CoAP)", RFC 7252, 536 DOI 10.17487/RFC7252, June 2014, 537 . 539 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 540 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 541 Internet of Things (IoT): Problem Statement", RFC 7554, 542 DOI 10.17487/RFC7554, May 2015, 543 . 545 6.2. Informative References 547 [I-D.chakrabarti-nordmark-6man-efficient-nd] 548 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 549 Wasserman, "IPv6 Neighbor Discovery Optimizations for 550 Wired and Wireless Networks", draft-chakrabarti-nordmark- 551 6man-efficient-nd-07 (work in progress), February 2015. 553 [I-D.ietf-roll-terminology] 554 Vasseur, J., "Terms used in Routing for Low power And 555 Lossy Networks", draft-ietf-roll-terminology-13 (work in 556 progress), October 2013. 558 [I-D.thubert-6lo-rfc6775-update-reqs] 559 Thubert, P. and P. Stok, "Requirements for an update to 560 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-reqs-06 561 (work in progress), January 2015. 563 [I-D.thubert-roll-forwarding-frags] 564 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 565 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 566 progress), September 2013. 568 [I-D.wang-6tisch-6top-protocol] 569 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- 570 wang-6tisch-6top-protocol-00 (work in progress), March 571 2016. 573 [I-D.wang-6tisch-6top-sublayer] 574 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 575 (6top)", draft-wang-6tisch-6top-sublayer-04 (work in 576 progress), November 2015. 578 6.3. External Informative References 580 [IEEE802154e] 581 IEEE standard for Information Technology, "IEEE std. 582 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 583 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 584 2012. 586 Authors' Addresses 588 Maria Rita Palattella (editor) 589 University of Luxembourg 590 Interdisciplinary Centre for Security, Reliability and Trust 591 4, rue Alphonse Weicker 592 Luxembourg L-2721 593 Luxembourg 595 Phone: (+352) 46 66 44 5841 596 Email: maria-rita.palattella@uni.lu 598 Pascal Thubert 599 Cisco Systems, Inc 600 Village d'Entreprises Green Side 601 400, Avenue de Roumanille 602 Batiment T3 603 Biot - Sophia Antipolis 06410 604 France 606 Phone: +33 497 23 26 34 607 Email: pthubert@cisco.com 609 Thomas Watteyne 610 Linear Technology / Dust Networks 611 30695 Huntwood Avenue 612 Hayward, CA 94544 613 USA 615 Phone: +1 (510) 400-2978 616 Email: twatteyne@linear.com 617 Qin Wang 618 Univ. of Sci. and Tech. Beijing 619 30 Xueyuan Road 620 Beijing 100083 621 China 623 Phone: +86 (10) 6233 4781 624 Email: wangqin@ies.ustb.edu.cn