idnits 2.17.1 draft-ietf-6tisch-terminology-00.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 18, 2013) is 3805 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 452, but not defined == Unused Reference: 'I-D.draft-sudhaakar-6tisch-coap' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6tisch-architecture' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'I-D.vilajosana-6tisch-minimal' is defined on line 439, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-chakrabarti-nordmark-6man-efficient-nd-02 == Outdated reference: A later version (-01) exists of draft-thubert-6tisch-architecture-00 Summary: 0 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: April 14, 2014 cisco 6 T. Watteyne 7 Linear Technology / Dust Networks 8 Q. Wang 9 Univ. of Sci. and Tech. Beijing 10 November 18, 2013 12 Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e 13 draft-ietf-6tisch-terminology-00 15 Abstract 17 6TiSCH proposes an architecture for an IPv6 multilink 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 April 14, 2014. 48 Copyright Notice 50 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . 8 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 6.2. Informative References . . . . . . . . . . . . . . . . . 9 73 6.3. External Informative References . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 a set of IETF sublayers and 111 protocols (in particular, for setting up a schedule with 112 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 model 117 supported by 6TiSCH. Packets are routed at layer 3, 118 where QoS and RED operations are expected to prioritize 119 flows with differentiated services. 121 6top: 6top is the adaptation layer between TSCH and upper 122 layers like 6LoWPAN and RPL. It is defined in 123 [I-D.draft-wang-6tsch-6top]. 125 6top Data Convey Model: Model describing how the 6top adaptation 126 layer feeds the data flow coming from upper layers into 127 TSCH. It is composed by an I-MUX module, a MUX module, a 128 set of priority queues, and a PDU (Payload Data Unit). 130 ASN: Absolute Slot Number, the timeslot counter, incremented 131 by one at each timeslot. It is wide enough to not roll 132 over in practice. See 133 [I-D.watteyne-6tsch-tsch-lln-context]. 135 Blacklist: Set of frequencies which should not be used for 136 communication. 138 BBR: Backbone Router. In the 6TiSCH architecture, it is an 139 LBR and also a NEAR. It performs ND proxy operations 140 between registered devices and classical ND devices that 141 are located over the backbone. 143 Bundle: A group of equivalent scheduled cells, i.e. cells 144 identified by different [slotOffset, channelOffset], 145 which are scheduled for a same purpose, with the same 146 neighbor, with the same flags, and the same slotframe. 147 The size of the bundle refers to the number of cells it 148 contains. Given the length of the slotframe, the size of 149 the bundle translates directly into bandwidth, either 150 logical, or physical. 152 Cell: A single element in the TSCH sloframe, identified by a 153 slotOffset value, a channelOffset value, a slotframe_ID 154 and Hopping_Sequence_ID. A cell can be scheduled or 155 unscheduled. During an unscheduled cell, the node does 156 not communicate. When a cell is scheduled, it is 157 assigned a MAC-layer slotframe identifier, a neighbor MAC 158 address (which can be the broadcast address), and one or 159 more of the following flags: TX, RX, shared, 160 timeskeeping, hard. A broadcast cell is an alias for "a 161 scheduled cell with neighbor address the broadcast 162 address". 164 ChannelOffset: Identifies a row in the TSCH slotframe. The number 165 of available channelOffsets is equal to the number of 166 available frequencies. The channelOffset translates into 167 a frequency when the communication takes place, resulting 168 in channel hopping, as detailed in 169 [I-D.watteyne-6tsch-tsch-lln-context]. 171 Communication Paradigm: It is Associated with the Information Model 172 [RFC3444] of the state that is exchanged, and indicates: 173 the location of that state (e.g., centralized vs. 174 distributed, RESTful, etc.), the numbers of parties 175 (e.g., P2P vs. P2MP) and the relationship between parties 176 (e.g., master/slave vs. peers) at a high level of 177 protocol abstraction. Layer 5 client/server REST is a 178 typical communication paradigm, but industrial protocols 179 also use publish/subscribe which is P2MP and source/sink 180 which is MP2MP and primarily used for alarms and alerts 181 at the application layer. At layer 3, basic flooding, 182 P2P synchronization and path-marking (RSVP-like) are 183 commonly used paradigms, whereas at layer 2, master/slave 184 polling and peer-to-peer forwarding are classical 185 examples. 187 Dedicated Cell: A cell that is reserved for a given node to transmit 188 to a specific neighbor. 190 Distributed cell reservation: A reservation of a cell done by one or 191 more in-network entities (typically a connection 192 endpoint). 194 Distributed track reservation: A reservation of a track done by one 195 or more in-network entities (typically a connection 196 endpoint). 198 EB: Enhanced Beacon frame used by an advertising node to 199 announce the presence of the network. It contains 200 information about the timeslot length, the current ASN 201 value, the slotframes and timeslots the beaconing mote is 202 listening on, and a 1-byte join priority (i.e., number of 203 hops separating the node sending the EB, and the PAN 204 coordinator). 206 FF: 6LoWPAN Fragment Forwarding. It is one of the three 207 forwarding model supported by 6TiSCH. The 6LoWPAN 208 Fragment is used as a label for switching at the 6LoWPAN 209 sublayer, as defined in 210 [I-D.thubert-roll-forwarding-frags]. 212 GMPLS: Generalized Multi-Protocol Label Switching, a 2.5 layer 213 service that is used to forward packets based on the 214 concept of generalized labels. 216 Hard Cell: A scheduled cell that is locked, i.e., it cannot be moved 217 by 6top in the schedule. See 218 [I-D.draft-wang-6tsch-6top]. 220 Hopping Sequence: Sequence of frequencies, identified by a 221 Hopping_Sequence_ID, used for channel hopping, when 222 translating the channel offset value into a frequency 223 (i.e., PHY channel). See 224 [I-D.watteyne-6tsch-tsch-lln-context]. 226 IE: Information Elements, a list of Type-Length-Value 227 containers placed at the end of the MAC header, used to 228 pass data between layers or devices. A small number of 229 types are defined by TSCH, but a range of types is 230 available for extensions, and thus, is exploitable by 231 6TiSCH. See [I-D.watteyne-6tsch-tsch-lln-context]. 233 I-MUX module: Inverse-Multiplexer, a classifier that receives 234 6LoWPAN frames and places them into priority queues. 236 Interaction Model: It is a particular way of implementing a 237 communication paradigm. Defined at a lower level of 238 abstraction, it includes protocol-specific details such 239 as a particular method (e.g., a REST GET) and a Data 240 Model for the state to be exchanged. 242 KMP: Key Managment Protocol. 244 LBR: LLN Border Router. It is an LLN device, usually powered, 245 that acts as a Border Router to the outside within the 246 6TiSCH architecture. 248 Link: A communication facility or medium over which nodes can 249 communicate at the link layer, i.e., the layer 250 immediately below IP. Thus, the IETF parlance for the 251 term "Link" is adopted, as opposed to the incompatible 252 IEEE802.15.4e terminology. In the context of the 6TiSCH 253 architecture, which applies to Low Power Lossy Networks 254 (LLNs), an IPv6 subnet is usually not congruent to a 255 single link and techniques such as IPv6 Neighbor 256 Discovery Proxying and Routing Over LLNs are required to 257 achieve reachability within the multilink subnet. A link 258 is distinct from a track. In fact, link local addresses 259 are not expected to be used over a track for end to end 260 communication. Finally, from the Layer 3 perspective 261 (where the inner complexities of TSCH operations are 262 hidden to enable classical IP routing and Forwarding), a 263 single radio interface may be seen as a number of Links 264 with different capabilities for unicast or multicast 265 services. 267 Logical Cell: A cell that corresponds to granted bandwidth but is 268 only lazily associated to a physical cell, based on 269 usage. 271 MAC: Medium Access Control. 273 MUX module: Multiplexer, the entity that dequeues frames from 274 priority queues and associates them to a cell for 275 transmission. 277 NEAR: Energy Aware Default Router, as defined in 278 [I-D.chakrabarti-nordmark-6man-efficient-nd]. 280 NME: Network Management Entity, the entity in the network 281 managing cells and other device resources. It may 282 cooperate with the PCE. It interacts with LLN nodes 283 through the backbone router. 285 PANA: Protocol for carrying Authentication for Network Access, 286 as defined in [RFC5191] . It is the protocol used in the 287 6TiSCH architecture for handling authentication during 288 the join process. 290 PCE: Path Computation Element, the entity in the network which 291 is responsible for building and maintaining the TSCH 292 schedule, when centralized scheduling is used. 294 PCE cell reservation: The reservation of a cell done by the PCE. 296 PCE track reservation: The reservation of a track done by the PCE. 298 QoS: Quality of Service. 300 SA: Security Association. 302 Shared Cell: A cell that is used by more than one transmitter nodes 303 at the same time and on the same channelOffset. Only 304 cells with TX flag can be marked as "shared". A backoff 305 algorithm is used to resolve contention. 307 SlotOffset: Identifies a column in the TSCH schedule, i.e., the 308 number of timeslots since the beginning of the current 309 iteration of the slotframe. 311 Slotframe: A MAC-level abstraction that is internal to the node and 312 contains a series of timeslots of equal length and 313 priority. It is characterized by a slotframe_ID, and a 314 slotframe_size. Multiple slotframes can coexist in a 315 node's schedule, i.e., a node can have multiple 316 activities scheduled in different slotframes, based on 317 the priority of its packets/traffic flows. The timeslots 318 in the Slotframe are indexed by the SlotOffset; the first 319 timeslot is at SlotOffset 0. 321 Soft Cell: A scheduled cell that is not locked, i.e., it may be 322 moved in the schedule within a same slotframe by 6top, as 323 described in [I-D.draft-wang-6tsch-6top]. 325 TF: Track Forwarding. It is the simplest and fastest 326 forwarding model supported by 6TiSCH. It is a G-MPLS- 327 like forwarding model. The input cell characterises the 328 flow and indicates the output cell. 330 Timeslot: A basic communication unit in TSCH which allows a 331 transmitter node to send a frame to a receiver neighbor, 332 and that receiver neighbor to optionally send back an 333 acknowledgment. The length of the timeslot determines 334 the maximum size of the frame that can be exchanged. 336 Time Source Neighbor: A neighbor a node uses as its time reference, 337 and to which it needs to keep its clock synchronized. A 338 node can have one or more time source neighbors. 340 Track: A determined sequence of cells along a multi-hop path. 341 It is typically the result of a reservation. The node 342 that initializes the process for establishing a track is 343 the owner of the track. The latter assigns a unique 344 identifier to the track, called TrackID. 346 TrackID: Unique identifier of a track, assigned by the owner of 347 the track. 349 TSCH: Time Slotted Channel Hopping, a medium access mode of the 350 [IEEE802154e] standard which uses time synchronization to 351 achieve ultra low-power operation and channel hopping to 352 enable high reliability. 354 TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset 355 and a channelOffset. The slotframe size (the "width" of 356 the matrix) is the number of timeslots it contains. The 357 number of channelOffset values (the "height" of the 358 matrix) is equal to the number of available frequencies. 359 The TSCH schedule contains all the scheduled cells from 360 all slotframes and is sufficient to qualify the 361 communication in the TSCH network. 363 3. IANA Considerations 365 This specification does not require IANA action. 367 4. Security Considerations 369 This specification is not found to introduce new security threat. 371 5. Acknowledgements 373 Thanks to the IoT6 European Project (STREP) of the 7th Framework 374 Program (Grant 288445). 376 6. References 378 6.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 384 Information Models and Data Models", RFC 3444, January 385 2003. 387 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 388 Yegin, "Protocol for Carrying Authentication for Network 389 Access (PANA)", RFC 5191, May 2008. 391 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 392 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 393 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 394 Lossy Networks", RFC 6550, March 2012. 396 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 397 Protocol for Low-Power and Lossy Networks (RPL)", RFC 398 6552, March 2012. 400 6.2. Informative References 402 [I-D.chakrabarti-nordmark-6man-efficient-nd] 403 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 404 Wasserman, "Efficiency aware IPv6 Neighbor Discovery 405 Optimizations", draft-chakrabarti-nordmark-6man-efficient- 406 nd-02 (work in progress), July 2013. 408 [I-D.draft-sudhaakar-6tisch-coap] 409 Sudhaakar, R., Ed. and P. Zand, "6TiSCH Data Model for 410 CoAP-00 (work in progress) ", October 2013. 412 [I-D.draft-wang-6tsch-6top] 413 Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 414 Operation Sublayer (6top). draft-wang-6tisch-6top-00 (work 415 in progress) ", October 2013. 417 [I-D.ietf-roll-terminology] 418 Vasseur, J., "Terms used in Ruting for Low power And Lossy 419 Networks", draft-ietf-roll-terminology-13 (work in 420 progress), October 2013. 422 [I-D.ohba-6tsch-security] 423 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 424 A. Yegin, "Security Framework and Key Management Protocol 425 Requirements for 6TSCH", draft-ohba-6tsch-security-01 426 (work in progress), July 2013. 428 [I-D.thubert-6tisch-architecture] 429 Thubert, P., Assimiti, R., and T. Watteyne, "An 430 Architecture for IPv6 over the TSCH mode of IEEE 431 IEEE802.15.4e", draft-thubert-6tisch-architecture-00 (work 432 in progress), October 2013. 434 [I-D.thubert-roll-forwarding-frags] 435 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 436 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 437 progress), September 2013. 439 [I-D.vilajosana-6tisch-minimal] 440 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 441 Configuration", draft-vilajosana-6tisch-minimal-00 (work 442 in progress), October 2013. 444 [I-D.watteyne-6tsch-tsch-lln-context] 445 Watteyne, T., Palattella, M., and L. Grieco, "Using 446 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 447 Statement and Goals", draft-watteyne-6tsch-tsch-lln- 448 context-02 (work in progress), May 2013. 450 6.3. External Informative References 452 [IEEE802154e] 453 IEEE standard for Information Technology, "IEEE std. 454 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 455 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 456 2012. 458 Authors' Addresses 460 Maria Rita Palattella (editor) 461 University of Luxembourg 462 Interdisciplinary Centre for Security, Reliability and Trust 463 4, rue Alphonse Weicker 464 Luxembourg L-2721 465 LUXEMBOURG 467 Phone: (+352) 46 66 44 5841 468 Email: maria-rita.palattella@uni.lu 469 Pascal Thubert 470 Cisco Systems, Inc 471 Village d'Entreprises Green Side 472 400, Avenue de Roumanille 473 Batiment T3 474 Biot - Sophia Antipolis 06410 475 FRANCE 477 Phone: +33 497 23 26 34 478 Email: pthubert@cisco.com 480 Thomas Watteyne 481 Linear Technology / Dust Networks 482 30695 Huntwood Avenue 483 Hayward, CA 94544 484 USA 486 Phone: +1 (510) 400-2978 487 Email: twatteyne@linear.com 489 Qin Wang 490 Univ. of Sci. and Tech. Beijing 491 30 Xueyuan Road 492 Beijing, Hebei 100083 493 China 495 Phone: +86 (10) 6233 4781 496 Email: wangqin@ies.ustb.edu.cn