idnits 2.17.1 draft-ietf-6tisch-terminology-06.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 (November 2, 2015) is 3091 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 571, but not defined == Unused Reference: 'RFC5191' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC7252' is defined on line 530, 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 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-02 Summary: 2 errors (**), 0 flaws (~~), 8 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: May 5, 2016 cisco 6 T. Watteyne 7 Linear Technology / Dust Networks 8 Q. Wang 9 Univ. of Sci. and Tech. Beijing 10 November 2, 2015 12 Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e 13 draft-ietf-6tisch-terminology-06 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 May 5, 2016. 48 Copyright Notice 50 Copyright (c) 2015 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. It implements and terminates the "6top 119 Protocol" (6P), and contains a "6top Scheduling Function" 120 (SF). It is defined in [I-D.wang-6tisch-6top-sublayer]. 122 6top Data Convey Model: Model describing how the 6top adaptation 123 layer feeds the data flow coming from upper layers into 124 TSCH. It is composed by an I-MUX module, a MUX module, a 125 set of priority queues, and a PDU (Payload Data Unit). 126 See [I-D.wang-6tisch-6top-sublayer]. 128 SF: The "6top Scheduling Function" (SF) is the policy inside 129 the "6TiSCH Operation Sublayer" (6top) which decides when 130 to add/remove cells. It is defined in 131 [I-D.wang-6tisch-6top-sublayer]. 133 SFID: The "6top Scheduling Function Identifier" (SFID) is a 134 4-bit field identifying a SF. It is defined in 135 [I-D.wang-6tisch-6top-sublayer]. 137 6P: The "6top Protocol" (6P) allows neighbor nodes to 138 communicate to add/delete cells to one another in their 139 TSCH schedule. It is defined in 140 [I-D.wang-6tisch-6top-sublayer]. 142 6P Transaction: Part of the "6top Protocol" (6P), the action of two 143 neighbors exchanging a 6P request message and the 144 corresponding 6P response message. It is defined in 145 [I-D.wang-6tisch-6top-sublayer]. 147 ARO: [RFC6775] defines a number of new Neighbor Discovery 148 options including the Address Registration Option (ARO). 150 ASN: Absolute Slot Number, the total number of timeslots that 151 has elapsed since the PAN coordinator has started the 152 TSCH network. It is incremented by one at each timeslot. 153 It is wide enough to not roll over in practice. See 154 [IEEE802154e]. 156 Blacklist of Frequencies: Simply defined Blacklist in [IEEE802154e], 157 it is the set of frequencies among the 16 available ones, 158 which should not be used for communication. 160 BBR: Backbone Router. In the 6TiSCH architecture, it is an 161 LBR and also a IPv6 ND-efficiency-aware Router (NEAR) 162 [I-D.chakrabarti-nordmark-6man-efficient-nd]. It 163 performs ND proxy operations between registered devices 164 and classical ND devices that are located over the 165 backbone. 167 Broadcast Cell: A scheduled cell used for broadcast transmission. 169 Bundle: A group of equivalent scheduled cells, i.e. cells 170 identified by different [slotOffset, channelOffset], 171 which are scheduled for a same purpose, with the same 172 neighbor, with the same flags, and the same slotframe. 173 The size of the bundle refers to the number of cells it 174 contains. Given the length of the slotframe, the size of 175 the bundle translates directly into bandwidth. A bundle 176 represents a half-duplex link between nodes, one 177 transmitter and one or more receivers, with a bandwidth 178 that amount to the sum of the cells in the bundle. A 179 bundle is globally identified by (source MAC, destination 180 MAC, TrackID). At Layer 3 a pair of bundles forms a 181 link. By usining a well-known constant, NULLT, as 182 TrackId for a L3 link, the IP link between adjacent nodes 183 A and B comprises 2 bundles: (macA, macB, NULLT) and 184 (macB, macA, NULLT). At L2 a pair of bundles forms a 185 switching state. Considered a segment A-B-C along a 186 track, there are two bundles in node B, one incoming = 187 (macA, macB, trackId) and one outgoing = (macB, macC, 188 trackId). 190 Cell: A single element in the TSCH schedule, identified by a 191 slotOffset, a channelOffset, a slotframeHandle. A cell 192 can be scheduled or unscheduled. 194 Centralized Cell Reservation: A reservation of a cell done by a 195 centralized entity (e.g., a PCE) in the network. 197 Centralized Track Reservation: A reservation of a track done by a 198 centralized entity (e.g., a PCE) in the network. 200 ChannelOffset: Identifies a row in the TSCH schedule. The number of 201 available channelOffsets is equal to the number of 202 available frequencies. The channelOffset translates into 203 a frequency when the communication takes place, resulting 204 in channel hopping, as detailed in [RFC7554]. 206 Channel Distribution/Usage (CDU) matrix: : Matrix of cells (i,j) 207 representing the spectrum (channel) distribution among 208 the different nodes in the 6TiSCH network. The CDU 209 matrix has width in timeslots, equal to the period of the 210 network scheduling operation, and height equal to the 211 number of available channels. Every cell (i,j) in the 212 CDU, identified by (slotOffset, channelOffset), belongs 213 to a specific chunk. It has to be noticed that such a 214 matrix which includes all the cells grouped in chunks, 215 belonging to different slotframes, is different from the 216 TSCH schedule. 218 Chunk: A well-known list of cells, distributed in time and 219 frequency, within a CDU matrix; a chunk represents a 220 portion of a CDU matrix. The partition of the CDU in 221 chunks is globally known by all the nodes in the network 222 to support the appropriation process, which is a 223 negotiation between nodes within an interference domain. 224 A node that manages to appropriate a chunk gets to decide 225 which transmissions will occur over the cells in the 226 chunk within its interference domain (i.e., a parent node 227 will decide when the cells within the appropriated chunk 228 are used and by which node, among its children. 230 Communication Paradigm: It is Associated with the Information Model 231 [RFC3444] of the state that is exchanged, and indicates: 232 the location of that state (e.g., centralized vs. 233 distributed, RESTful, etc.), the numbers of parties 234 (e.g., point to point, P2P, vs. point to multi-point, 235 P2MP) and the relationship between parties (e.g., master/ 236 slave vs. peers) at a high level of protocol abstraction. 237 Layer 5 client/server REST is a typical communication 238 paradigm, but industrial protocols also use publish/ 239 subscribe which is P2MP and source/sink which is multi- 240 point to multi-point (MP2MP) and primarily used for 241 alarms and alerts at the application layer. At layer 3, 242 basic flooding, P2P synchronization and path-marking 243 (RSVP-like) are commonly used paradigms, whereas at layer 244 2, master/slave polling and peer-to-peer forwarding are 245 classical examples. 247 DAR/DAC: [RFC6775] defines the Duplicate Address Request (DAR) and 248 Duplicate Address Confirmation (DAC) options to turn the 249 multicast Duplicate Address Detection protocol into a 250 unicast-based multi-hop process between routers and the 251 backbone router. 253 Dedicated Cell: A cell that is reserved for a given node to transmit 254 to a specific neighbor. 256 Deterministic Network: A Deterministic Network supports traffic 257 flows with communication patterns that are known a 258 priori. Thus, routing paths and communication schedules 259 can be computed in advance, in a fashion similar to a 260 railway system, to avoid losses due to packet collisions, 261 and to perform global optimizations across multiple 262 flows. A deterministic network can allocates the 263 required resources (buffers, processors, medium access) 264 along the multi-hop routing path at the precise moment 265 the resources are needed. 267 Distributed Cell Reservation: A reservation of a cell done by one or 268 more in-network entities (typically a connection 269 endpoint). 271 Distributed Track Reservation: A reservation of a track done by one 272 or more in-network entities (typically a connection 273 endpoint). 275 EARO: [I-D.thubert-6lo-rfc6775-update-reqs] extends the ARO 276 option to include some additional fields necessary to 277 distinguish duplicate addresses from nodes that have 278 moved networks when there are mulitple LLNs linked over a 279 backbone. 281 EB: Enhanced Beacon frame used by a node to announce the 282 presence of the network. It contains useful information 283 (see [IEEE802154e] for details) that allow a new node to 284 synhronize and join the network. 286 FF: 6LoWPAN Fragment Forwarding. It is one of the three 287 forwarding models supported by 6TiSCH. The 6LoWPAN 288 Fragment is used as a label for switching at the 6LoWPAN 289 sublayer, as defined in 290 [I-D.thubert-roll-forwarding-frags]. 292 GMPLS: Generalized Multi-Protocol Label Switching, a 2.5 layer 293 service that is used to forward packets based on the 294 concept of generalized labels. 296 Hard Cell: A scheduled cell which the 6top sublayer cannot 297 reallocate. See [I-D.wang-6tisch-6top-sublayer]. 299 Hopping Sequence: Ordered sequence of frequencies, identified by a 300 Hopping_Sequence_ID, used for channel hopping, when 301 translating the channel offset value into a frequency 302 (i.e., PHY channel). See [IEEE802154e] and [RFC7554]. 304 IE: Information Elements, a list of Type-Length-Value 305 containers placed at the end of the MAC header, used to 306 pass data between layers or devices. A small number of 307 types are defined by [IEEE802154e], but a range of types 308 is available for extensions, and thus, is exploitable by 309 6TiSCH. See [IEEE802154e]. 311 I-MUX module: Inverse-Multiplexer, a classifier that receives 312 6LoWPAN frames and places them into priority queues. See 313 [I-D.wang-6tisch-6top-sublayer]. 315 Interaction Model: It is a particular way of implementing a 316 communication paradigm. Defined at a lower level of 317 abstraction, it includes protocol-specific details such 318 as a particular method (e.g., a REST GET) and a Data 319 Model for the state to be exchanged. 321 Interference Domain: The Interference Domain of a given 322 (transmitter) node A includes all the nodes in its 323 neighbourhood that can generate interference at its 324 receiver B, when transmitting on the same channel (i.e., 325 using the same frequency). 327 JCE: The Join Coordination Entity (JCE) is a central entity 328 like the Path Computation Element (PCE), that may assist 329 in several aspects of the join protocol, such as 330 authentication, authorization, and configuration. 332 JA: The Join Assistant (JA) is a one-hop neighbor of a 333 joining node that may facilitate it to become meaningful 334 part of the network (e.g., by serving as a local 335 connectivity point to the remainder of the network). 337 Join Protocol: The protocol which secures initial communication 338 between a joining node and the JCE. 340 LBR: Low-power Lossy Network (LLN) Border Router. It is an 341 LLN device, usually powered, that acts as a Border Router 342 to the outside within the 6TiSCH architecture. 344 Link: A communication facility or medium over which nodes can 345 communicate at the link layer, i.e., the layer 346 immediately below IP. Thus, the IETF parlance for the 347 term "Link" is adopted, as opposed to the IEEE802.15.4e 348 terminology. In the context of the 6TiSCH architecture, 349 which applies to Low Power Lossy Networks (LLNs), an IPv6 350 subnet is usually not congruent to a single link and 351 techniques such as IPv6 Neighbor Discovery Proxying are 352 used to achieve reachability within the multilink subnet. 353 A link is distinct from a track. In fact, link local 354 addresses are not expected to be used over a track for 355 end to end communication. Finally, from the Layer 3 356 perspective (where the inner complexities of TSCH 357 operations are hidden to enable classical IP routing and 358 forwarding), a single radio interface may be seen as a 359 number of Links with different capabilities for unicast 360 or multicast services. 362 MAC: Medium Access Control. 364 MUX Module: Multiplexer, the entity that dequeues frames from 365 priority queues and associates them to a cell for 366 transmission. See [I-D.wang-6tisch-6top-sublayer]. 368 NEAR: IPv6 ND-efficiency-aware Router, as defined in 369 [I-D.chakrabarti-nordmark-6man-efficient-nd]. 371 NME: Network Management Entity, the entity in the network 372 managing cells and other device resources. It may 373 cooperate with the PCE. It interacts with LLN nodes 374 through the backbone router. 376 Operational Network: A IEEE802.15.4e network whose encryption/ 377 authentication keys are determined by some algorithms/ 378 protocols. There may be network-wide group keys, or per- 379 link keys. 381 Operational Network Key: A Link-layer key known by all authorized 382 nodes, used for multicast messages. 384 PCE: Path Computation Element, the entity in the network which 385 is responsible for building and maintaining the TSCH 386 schedule, when centralized scheduling is used. 388 QoS: Quality of Service. 390 (to) Reallocate a Cell: The action operated by the 6top sublayer of 391 changing the slotOffset and/or channelOffset of a soft 392 cell. 394 (to) Schedule a Cell: The action of turning an unscheduled cell into 395 a scheduled cell. 397 Scheduled cell: A cell which is assigned a neighbor MAC address 398 (broadcast address is also possible), and one or more of 399 the following flags: TX, RX, shared, timeskeeping. A 400 scheduled cell can be used by the IEEE802.15.4e TSCH 401 implementation to communicate. A scheduled cell can be 402 either a hard or a soft cell. 404 Shared Cell: A cell marked with both the "TX" and "shared" flags. 405 This cell can be used by more than one transmitter node. 406 A backoff algorithm is used to resolve contention. See 407 [RFC7554]. 409 SlotOffset: Identifies a column in the TSCH schedule, i.e., the 410 number of timeslots since the beginning of the current 411 iteration of the slotframe. 413 Slotframe: A MAC-level abstraction that is internal to the node and 414 contains a series of timeslots of equal length and 415 priority. It is characterized by a slotframe_ID, and a 416 slotframe_size. Multiple slotframes can coexist in a 417 node's schedule, i.e., a node can have multiple 418 activities scheduled in different slotframes, based on 419 the priority of its packets/traffic flows. The timeslots 420 in the Slotframe are indexed by the SlotOffset; the first 421 timeslot is at SlotOffset 0. 423 Soft Cell: A scheduled cell which the 6top sublayer can reallocate, 424 as described in [I-D.wang-6tisch-6top-sublayer]. 426 TF: Track Forwarding. It is the simplest and fastest 427 forwarding model supported by 6TiSCH. It is a GMPLS-like 428 forwarding model. The incoming bundle (and thus, the 429 input cell) characterizes the flow and indicates the 430 outgoing bundle (and output cell). 432 Timeslot: A basic communication unit in TSCH which allows a 433 transmitter node to send a frame to a receiver neighbor, 434 and that receiver neighbor to optionally send back an 435 acknowledgment. 437 Time Source Neighbor: A neighbor that a node uses as its time 438 reference, and to which it needs to keep its clock 439 synchronized. A node can have one or more time source 440 neighbors. 442 Track: A determined sequence of cells along a multi-hop path. 443 It is typically the result of a track reservation. The 444 node that initializes the process for establishing a 445 track is the owner of the track. The latter assigns a 446 unique identifier to the track, called TrackID. 448 TrackID: Unique identifier of a track, assigned by the owner of 449 the track. 451 TSCH: Time Slotted Channel Hopping, a medium access mode of the 452 [IEEE802154e] standard which uses time synchronization to 453 achieve ultra low-power operation and channel hopping to 454 enable high reliability. 456 TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset 457 and a channelOffset. The TSCH schedule contains all the 458 scheduled cells from all slotframes and is sufficient to 459 qualify the communication in the TSCH network. The 460 "width of the matrix is equal to the number of scheduled 461 timeslots in all the concurrent active slotframes. The 462 number of channelOffset values (the "height" of the 463 matrix) is equal to the number of available frequencies. 465 Unscheduled Cell: A cell which is not used by the IEEE802.15.4e TSCH 466 implementation. 468 3. IANA Considerations 470 This specification does not require IANA action. 472 4. Security Considerations 474 This specification is not found to introduce new security threats. 476 5. Acknowledgments 478 Thanks to the IoT6 European Project (STREP) of the 7th Framework 479 Program (Grant 288445). 481 6. References 483 6.1. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 487 RFC2119, March 1997, 488 . 490 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 491 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 492 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 493 S., Wroclawski, J., and L. Zhang, "Recommendations on 494 Queue Management and Congestion Avoidance in the 495 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 496 . 498 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 499 Information Models and Data Models", RFC 3444, DOI 500 10.17487/RFC3444, January 2003, 501 . 503 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 504 and A. Yegin, "Protocol for Carrying Authentication for 505 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 506 May 2008, . 508 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 509 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 510 January 2012, . 512 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 513 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 514 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 515 Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/ 516 RFC6550, March 2012, 517 . 519 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 520 Protocol for Low-Power and Lossy Networks (RPL)", RFC 521 6552, DOI 10.17487/RFC6552, March 2012, 522 . 524 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 525 Bormann, "Neighbor Discovery Optimization for IPv6 over 526 Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 527 6775, DOI 10.17487/RFC6775, November 2012, 528 . 530 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 531 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 532 RFC7252, June 2014, 533 . 535 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 536 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 537 Internet of Things (IoT): Problem Statement", RFC 7554, 538 DOI 10.17487/RFC7554, May 2015, 539 . 541 6.2. Informative References 543 [I-D.chakrabarti-nordmark-6man-efficient-nd] 544 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 545 Wasserman, "IPv6 Neighbor Discovery Optimizations for 546 Wired and Wireless Networks", draft-chakrabarti-nordmark- 547 6man-efficient-nd-07 (work in progress), February 2015. 549 [I-D.ietf-roll-terminology] 550 Vasseur, J., "Terms used in Routing for Low power And 551 Lossy Networks", draft-ietf-roll-terminology-13 (work in 552 progress), October 2013. 554 [I-D.thubert-6lo-rfc6775-update-reqs] 555 Thubert, P. and P. Stok, "Requirements for an update to 556 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-reqs-06 557 (work in progress), January 2015. 559 [I-D.thubert-roll-forwarding-frags] 560 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 561 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 562 progress), September 2013. 564 [I-D.wang-6tisch-6top-sublayer] 565 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 566 (6top)", draft-wang-6tisch-6top-sublayer-02 (work in 567 progress), October 2015. 569 6.3. External Informative References 571 [IEEE802154e] 572 IEEE standard for Information Technology, "IEEE std. 573 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 574 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 575 2012. 577 Authors' Addresses 579 Maria Rita Palattella (editor) 580 University of Luxembourg 581 Interdisciplinary Centre for Security, Reliability and Trust 582 4, rue Alphonse Weicker 583 Luxembourg L-2721 584 Luxembourg 586 Phone: (+352) 46 66 44 5841 587 Email: maria-rita.palattella@uni.lu 589 Pascal Thubert 590 Cisco Systems, Inc 591 Village d'Entreprises Green Side 592 400, Avenue de Roumanille 593 Batiment T3 594 Biot - Sophia Antipolis 06410 595 France 597 Phone: +33 497 23 26 34 598 Email: pthubert@cisco.com 600 Thomas Watteyne 601 Linear Technology / Dust Networks 602 30695 Huntwood Avenue 603 Hayward, CA 94544 604 USA 606 Phone: +1 (510) 400-2978 607 Email: twatteyne@linear.com 608 Qin Wang 609 Univ. of Sci. and Tech. Beijing 610 30 Xueyuan Road 611 Beijing 100083 612 China 614 Phone: +86 (10) 6233 4781 615 Email: wangqin@ies.ustb.edu.cn