idnits 2.17.1 draft-ietf-6tisch-terminology-03.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 (January 8, 2015) is 3396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 572, but not defined == Missing Reference: 'IEEE.802.1AR' is mentioned on line 567, but not defined == Unused Reference: 'I-D.thubert-6lo-rfc6775-update-reqs' is defined on line 550, 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-chakrabarti-nordmark-6man-efficient-nd-06 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-04 == Outdated reference: A later version (-07) exists of draft-thubert-6lo-rfc6775-update-reqs-05 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-01 Summary: 2 errors (**), 0 flaws (~~), 9 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: July 12, 2015 cisco 6 T. Watteyne 7 Linear Technology / Dust Networks 8 Q. Wang 9 Univ. of Sci. and Tech. Beijing 10 January 8, 2015 12 Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e 13 draft-ietf-6tisch-terminology-03 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 July 12, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 A new breed of Time Sensitive Networks is being developed to enable 79 traffic that is highly sensitive to jitter and quite sensitive to 80 latency. Such traffic is not limited to voice and video, but also 81 includes command and control operations such as in industrial 82 automation or in-vehicle sensors and actuators. 84 At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time 85 Sensitive Networking. The IEEE802.15.4 Medium Access Control (MAC) 86 has evolved with IEEE802.15.4e which provides in particular the Time 87 Slotted Channel Hopping (TSCH) mode for industrial-type applications. 88 Both provide deterministic capabilities to the point that a packet 89 that pertains to a certain flow crosses the network from node to node 90 following a very precise schedule, like a train leaves intermediate 91 stations at precise times along its path. 93 This document provides additional terminology elements to cover terms 94 that are new to the context of TSCH wireless networks and other 95 deterministic networks. 97 2. Terminology 99 The draft extends [I-D.ietf-roll-terminology] and use terms from RFC 100 6550 [RFC6550] and RFC 6552 [RFC6552], which are all included here by 101 reference. 103 The draft does not reuse terms from IEEE802.15.4e such as "path" or 104 "link" which bear a meaning that is quite different from classical 105 IETF parlance. 107 This document adds the following terms: 109 6TiSCH: IPv6 over the Timeslotted Channel Hopping (TSCH) mode of 110 IEEE 802.15.4e. It defines the 6top sublayer and a set 111 of protocols (in particular, for setting up a schedule 112 with a centralized or distributed approach, managing the 113 resource allocation), as well as the architecture to bind 114 them together, for use in IPv6 TSCH based networks. 116 6F: IPv6 Forwarding. One of the three forwarding models 117 supported by 6TiSCH. Packets are routed at layer 3, 118 where Quality of Service (QoS) and Random Early Detection 119 (RED) [RFC2309] operations are expected to prioritize 120 flows with differentiated services. 122 6top: 6top is the adaptation sublayer between TSCH and upper 123 layers like 6LoWPAN and RPL. It is defined in 124 [I-D.wang-6tisch-6top-sublayer]. 126 6top Data Convey Model: Model describing how the 6top adaptation 127 layer feeds the data flow coming from upper layers into 128 TSCH. It is composed by an I-MUX module, a MUX module, a 129 set of priority queues, and a PDU (Payload Data Unit).See 130 [I-D.wang-6tisch-6top-sublayer]. 132 ARO: [RFC6775] defines a number of new Neighbor Discovery 133 options including the Address Registration Option (ARO). 135 ASN: Absolute Slot Number, the total number of timeslots that 136 has elapsed since the start of the network or an 137 arbitrary start time (i.e., a timeslot counter, 138 incremented by one at each timeslot). It is wide enough 139 to not roll over in practice. See [IEEE802154e]. 141 Blacklist: Set of frequencies which should not be used for 142 communication. 144 BBR: Backbone Router. In the 6TiSCH architecture, it is an 145 LBR and also a IPv6 ND-efficiency-aware Router (NEAR) 146 [I-D.chakrabarti-nordmark-6man-efficient-nd]. It 147 performs ND proxy operations between registered devices 148 and classical ND devices that are located over the 149 backbone. 151 Broadcast cell: A scheduled cell used for broadcast transmission. 153 Bundle: A group of equivalent scheduled cells, i.e. cells 154 identified by different [slotOffset, channelOffset], 155 which are scheduled for a same purpose, with the same 156 neighbor, with the same flags, and the same slotframe. 157 The size of the bundle refers to the number of cells it 158 contains. Given the length of the slotframe, the size of 159 the bundle translates directly into bandwidth. 161 Cell: A single element in the TSCH schedule, identified by a 162 slotOffset, a channelOffset, a slotframeHandle. A cell 163 can be scheduled or unscheduled. 165 ChannelOffset: Identifies a row in the TSCH schedule. The number of 166 available channelOffsets is equal to the number of 167 available frequencies. The channelOffset translates into 168 a frequency when the communication takes place, resulting 169 in channel hopping, as detailed in 170 [I-D.ietf-6tisch-tsch]. 172 Channel distribution/usage (CDU) matrix: : Matrix of height equal to 173 the number of available channels (i.e, ChannelOffsets), 174 representing the spectrum (channel) distribution among 175 the different (RPL parent) nodes in the networks. Every 176 single element of the matrix belongs to a specific chunk. 177 It has to be noticed that such matrix, even though it 178 includes all the cells grouped in chunks, belonging to 179 different slotframes, is different from the TSCH 180 schedule. 182 Chunk: A well-known list of cells, well-distributed in time and 183 frequency, within a CDU matrix; a chunk represents a 184 portion of a CDU matrix that is globally known by all the 185 nodes in the network, with typically at most one cell per 186 slotOffset for single radio devices. Once appropriated, 187 a chunk can be managed separately by a single node within 188 its interference domain. A node may appropriate multiple 189 chunks, and use them according to a specific policy. 190 Chunks may overlap. They can be pre-programmed, or can 191 be computed by an external entity at the network 192 bootstrap. 194 Chunk ownership appropriation: The process by which an individual 195 node obtains a chunk to manage based on peer-to-peer 196 interaction with its neighbors. 198 Chunk ownership delegation: The process by which an individual node 199 obtains a chunk to manage based on point-to-point 200 interaction with an external entity. 202 CoAP: The Constrained Application Protocol (CoAP), defined in 203 [RFC7252] is an HTTP-like resource access protocol. CoAP 204 runs over UDP. 206 Communication Paradigm: It is Associated with the Information Model 207 [RFC3444] of the state that is exchanged, and indicates: 208 the location of that state (e.g., centralized vs. 209 distributed, RESTful, etc.), the numbers of parties 210 (e.g., P2P vs. P2MP) and the relationship between parties 211 (e.g., master/slave vs. peers) at a high level of 212 protocol abstraction. Layer 5 client/server REST is a 213 typical communication paradigm, but industrial protocols 214 also use publish/subscribe which is P2MP and source/sink 215 which is MP2MP and primarily used for alarms and alerts 216 at the application layer. At layer 3, basic flooding, 217 P2P synchronization and path-marking (RSVP-like) are 218 commonly used paradigms, whereas at layer 2, master/slave 219 polling and peer-to-peer forwarding are classical 220 examples. 222 DAR/DAC: [RFC6775] defines the Duplicate Address Request (DAR) and 223 Duplicate Address Confirmation (DAC) options to turn the 224 multicast Duplicate Address Detection protocol into a 225 client/server process. 227 Dedicated Cell: A cell that is reserved for a given node to transmit 228 to a specific neighbor. 230 DevID: The secure DEVice IDentifier (DevID) defined in 231 [IEEE.802.1AR] is a device identifier that is 232 cryptographically bound to the device. It is composed of 233 the Secure Device Identifier Secret and the Secure Device 234 Identifier Credential. 236 Distributed cell reservation: A reservation of a cell done by one or 237 more in-network entities (typically a connection 238 endpoint). 240 Distributed track reservation: A reservation of a track done by one 241 or more in-network entities (typically a connection 242 endpoint). 244 DTLS: The datagram version of the Transport Layer Security 245 (TLS) Protocol, defined in [RFC6347], and which can be 246 used to secure CoAP in the same way that TLS secures 247 HTTP. 249 EARO: [I-D.thubert-6lo-rfc6775-update-reqs]extends the ARO 250 option to include some additional fields necessary to 251 distinguish duplicate addresses from nodes that have 252 moved networks when there are mulitple LLNs linked over a 253 backbone. 255 EB: Enhanced Beacon frame used by a node to announce the 256 presence of the network. It contains information about 257 the timeslot length, the current ASN value, the 258 slotframes and timeslots the beaconing mote is listening 259 on, and a 1-byte join priority (i.e., number of hops 260 separating the node sending the EB, and the PAN 261 coordinator). 263 FF: 6LoWPAN Fragment Forwarding. It is one of the three 264 forwarding models supported by 6TiSCH. The 6LoWPAN 265 Fragment is used as a label for switching at the 6LoWPAN 266 sublayer, as defined in 267 [I-D.thubert-roll-forwarding-frags]. 269 GMPLS: Generalized Multi-Protocol Label Switching, a 2.5 layer 270 service that is used to forward packets based on the 271 concept of generalized labels. 273 Hard Cell: A scheduled cell which the 6top sublayer cannot 274 reallocate. See [I-D.wang-6tisch-6top-sublayer]. 276 Hopping Sequence: Ordered sequence of frequencies, identified by a 277 Hopping_Sequence_ID, used for channel hopping, when 278 translating the channel offset value into a frequency 279 (i.e., PHY channel). See [IEEE802154e] and 280 [I-D.ietf-6tisch-tsch]. 282 IDevID: The Initial secure DEVice IDentifier (IDevID) is the 283 Device Identifier which was installed on the device by 284 the manufacturer. 286 IE: Information Elements, a list of Type-Length-Value 287 containers placed at the end of the MAC header, used to 288 pass data between layers or devices. A small number of 289 types are defined by [IEEE802154e], but a range of types 290 is available for extensions, and thus, is exploitable by 291 6TiSCH. See [IEEE802154e]. 293 I-MUX module: Inverse-Multiplexer, a classifier that receives 294 6LoWPAN frames and places them into priority queues. See 295 [I-D.wang-6tisch-6top-sublayer]. 297 Interaction Model: It is a particular way of implementing a 298 communication paradigm. Defined at a lower level of 299 abstraction, it includes protocol-specific details such 300 as a particular method (e.g., a REST GET) and a Data 301 Model for the state to be exchanged. 303 JCE: The Join Coordination Entity (JCE) is a central entity 304 like the Path Computation Engine (PCE), that is in charge 305 of authorization to join a network. The JCE provides 306 security credentials to joining devices. 308 JA: The Join Assistant (JA) is a constrained node near the 309 joining node that will act as its first 6LR, and will 310 relay traffic to/from the joining node. 312 JN: The Joining Node (JN) leverages the JA and the JCE to 313 learn or refresh its knowledge of the network operational 314 state and to obtain security material to participate to 315 the production network. 317 Join Protocol: The protocol which secures initial communication 318 between the JN and the JCE. 320 KMP: Key Management Protocol. 322 LBR: LLN Border Router. It is an LLN device, usually powered, 323 that acts as a Border Router to the outside within the 324 6TiSCH architecture. 326 LDevID: A Locally significant secure DEVice IDentifiers (LDevID) 327 is a Secure Device Identifier credential that is unique 328 in the local administrative domain in which the device is 329 used. The LDevID is usually a new certificate 330 provisioned by some local means, such as the 6top 331 sublayer [I-D.wang-6tisch-6top-sublayer]. 333 Link: A communication facility or medium over which nodes can 334 communicate at the link layer, i.e., the layer 335 immediately below IP. Thus, the IETF parlance for the 336 term "Link" is adopted, as opposed to the IEEE802.15.4e 337 terminology. In the context of the 6TiSCH architecture, 338 which applies to Low Power Lossy Networks (LLNs), an IPv6 339 subnet is usually not congruent to a single link and 340 techniques such as IPv6 Neighbor Discovery Proxying are 341 used to achieve reachability within the multilink subnet. 342 A link is distinct from a track. In fact, link local 343 addresses are not expected to be used over a track for 344 end to end communication. Finally, from the Layer 3 345 perspective (where the inner complexities of TSCH 346 operations are hidden to enable classical IP routing and 347 Forwarding), a single radio interface may be seen as a 348 number of Links with different capabilities for unicast 349 or multicast services. 351 Logical Cell: A cell that corresponds to granted bandwidth but is 352 only lazily associated to a physical cell, based on 353 usage. 355 MAC: Medium Access Control. 357 MUX module: Multiplexer, the entity that dequeues frames from 358 priority queues and associates them to a cell for 359 transmission. See [I-D.wang-6tisch-6top-sublayer]. 361 NEAR: Energy Aware Default Router, as defined in 362 [I-D.chakrabarti-nordmark-6man-efficient-nd]. 364 NME: Network Management Entity, the entity in the network 365 managing cells and other device resources. It may 366 cooperate with the PCE. It interacts with LLN nodes 367 through the backbone router. 369 Operational Network: A IEEE802.15.4e network whose encryption/ 370 authentication keys are determined by some algorithms/ 371 protocols. There may be network-wide group keys, or per- 372 link keys. 374 Operational Network Key: A Link-layer key known by all authorized 375 nodes, used for multicast messages. 377 PANA: Protocol for carrying Authentication for Network Access, 378 as defined in [RFC5191] . 380 PCE: Path Computation Element, the entity in the network which 381 is responsible for building and maintaining the TSCH 382 schedule, when centralized scheduling is used. 384 PCE cell reservation: The reservation of a cell done by the PCE. 386 PCE track reservation: The reservation of a track done by the PCE. 388 Per-Peer L2 Key: A key that results from an exchange (such as MLE) 389 that creates a pair-wise link-layer key which is known 390 only to the two nodes involved. 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 SA: Security Association. 400 (to) Schedule a cell: The action of turning an unscheduled cell into 401 a scheduled cell. 403 Scheduled cell: A cell which is assigned a neighbor MAC address 404 (broadcast address is also possible), and one or more of 405 the following flags: TX, RX, shared, timeskeeping. A 406 scheduled cell can be used by the IEEE802.15.4e TSCH 407 implementation to communicate. A scheduled cell can be a 408 hard cell or a soft cell. 410 Shared Cell: A cell marked with both the "TX" and "shared" flags. 411 This cell can be used by more than one transmitter node. 412 A backoff algorithm is used to resolve contention. See 413 [I-D.ietf-6tisch-tsch]. 415 SlotOffset: Identifies a column in the TSCH schedule, i.e., the 416 number of timeslots since the beginning of the current 417 iteration of the slotframe. 419 Slotframe: A MAC-level abstraction that is internal to the node and 420 contains a series of timeslots of equal length and 421 priority. It is characterized by a slotframe_ID, and a 422 slotframe_size. Multiple slotframes can coexist in a 423 node's schedule, i.e., a node can have multiple 424 activities scheduled in different slotframes, based on 425 the priority of its packets/traffic flows. The timeslots 426 in the Slotframe are indexed by the SlotOffset; the first 427 timeslot is at SlotOffset 0. 429 Soft Cell: A scheduled cell which the 6top sublayer can reallocate, 430 as described in [I-D.wang-6tisch-6top-sublayer]. 432 TF: Track Forwarding. It is the simplest and fastest 433 forwarding model supported by 6TiSCH. It is a G-MPLS- 434 like forwarding model. The input cell characterizes the 435 flow and indicates the output cell. 437 Timeslot: A basic communication unit in TSCH which allows a 438 transmitter node to send a frame to a receiver neighbor, 439 and that receiver neighbor to optionally send back an 440 acknowledgment. 442 Time Source Neighbor: A neighbor a node uses as its time reference, 443 and to which it needs to keep its clock synchronized. A 444 node can have one or more time source neighbors. 446 Track: A determined sequence of cells along a multi-hop path. 447 It is typically the result of a reservation. The node 448 that initializes the process for establishing a track is 449 the owner of the track. The latter assigns a unique 450 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 unique join key: A key shared between a JN and the JCE. This key 470 supports smaller installations for which asymmetric 471 methods are considered too large. 473 unscheduled cell: A cell which is not used by the IEEE802.15.4e TSCH 474 implementation. 476 3. IANA Considerations 478 This specification does not require IANA action. 480 4. Security Considerations 482 This specification is not found to introduce new security threats. 484 5. Acknowledgments 486 Thanks to the IoT6 European Project (STREP) of the 7th Framework 487 Program (Grant 288445). 489 6. References 491 6.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 497 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 498 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 499 S., Wroclawski, J., and L. Zhang, "Recommendations on 500 Queue Management and Congestion Avoidance in the 501 Internet", RFC 2309, April 1998. 503 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 504 Information Models and Data Models", RFC 3444, January 505 2003. 507 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 508 Yegin, "Protocol for Carrying Authentication for Network 509 Access (PANA)", RFC 5191, May 2008. 511 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 512 Security Version 1.2", RFC 6347, January 2012. 514 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 515 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 516 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 517 Lossy Networks", RFC 6550, March 2012. 519 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 520 Protocol for Low-Power and Lossy Networks (RPL)", RFC 521 6552, March 2012. 523 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 524 "Neighbor Discovery Optimization for IPv6 over Low-Power 525 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 526 November 2012. 528 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 529 Application Protocol (CoAP)", RFC 7252, June 2014. 531 6.2. Informative References 533 [I-D.chakrabarti-nordmark-6man-efficient-nd] 534 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 535 Wasserman, "IPv6 Neighbor Discovery Optimizations for 536 Wired and Wireless Networks", draft-chakrabarti-nordmark- 537 6man-efficient-nd-06 (work in progress), July 2014. 539 [I-D.ietf-6tisch-tsch] 540 Watteyne, T., Palattella, M., and L. Grieco, "Using 541 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 542 Statement and Goals", draft-ietf-6tisch-tsch-04 (work in 543 progress), December 2014. 545 [I-D.ietf-roll-terminology] 546 Vasseur, J., "Terms used in Routing for Low power And 547 Lossy Networks", draft-ietf-roll-terminology-13 (work in 548 progress), October 2013. 550 [I-D.thubert-6lo-rfc6775-update-reqs] 551 Thubert, P., "Requirements for an update to 6LoWPAN ND", 552 draft-thubert-6lo-rfc6775-update-reqs-05 (work in 553 progress), October 2014. 555 [I-D.thubert-roll-forwarding-frags] 556 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 557 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 558 progress), September 2013. 560 [I-D.wang-6tisch-6top-sublayer] 561 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 562 Operation Sublayer (6top)", draft-wang-6tisch-6top- 563 sublayer-01 (work in progress), July 2014. 565 6.3. External Informative References 567 [IEEE.802.1AR] 568 IEEE standard for Information Technology, "802.1AR-2009 - 569 IEEE Standard for Local and metropolitan area networks - 570 Secure Device Identity", 2009. 572 [IEEE802154e] 573 IEEE standard for Information Technology, "IEEE std. 574 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 575 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 576 2012. 578 Authors' Addresses 580 Maria Rita Palattella (editor) 581 University of Luxembourg 582 Interdisciplinary Centre for Security, Reliability and Trust 583 4, rue Alphonse Weicker 584 Luxembourg L-2721 585 Luxembourg 587 Phone: (+352) 46 66 44 5841 588 Email: maria-rita.palattella@uni.lu 590 Pascal Thubert 591 Cisco Systems, Inc 592 Village d'Entreprises Green Side 593 400, Avenue de Roumanille 594 Batiment T3 595 Biot - Sophia Antipolis 06410 596 France 598 Phone: +33 497 23 26 34 599 Email: pthubert@cisco.com 601 Thomas Watteyne 602 Linear Technology / Dust Networks 603 30695 Huntwood Avenue 604 Hayward, CA 94544 605 USA 607 Phone: +1 (510) 400-2978 608 Email: twatteyne@linear.com 609 Qin Wang 610 Univ. of Sci. and Tech. Beijing 611 30 Xueyuan Road 612 Beijing, Hebei 100083 613 China 615 Phone: +86 (10) 6233 4781 616 Email: wangqin@ies.ustb.edu.cn