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