| < draft-ietf-6tisch-terminology-07.txt | draft-ietf-6tisch-terminology-08.txt > | |||
|---|---|---|---|---|
| 6TiSCH MR. Palattella, Ed. | 6TiSCH MR. Palattella, Ed. | |||
| Internet-Draft SnT/Univ. of Luxembourg | Internet-Draft LIST | |||
| Intended status: Informational P. Thubert | Intended status: Informational P. Thubert | |||
| Expires: September 22, 2016 cisco | Expires: June 19, 2017 cisco | |||
| T. Watteyne | T. Watteyne | |||
| Linear Technology / Dust Networks | Linear Technology / Dust Networks | |||
| Q. Wang | Q. Wang | |||
| Univ. of Sci. and Tech. Beijing | Univ. of Sci. and Tech. Beijing | |||
| March 21, 2016 | December 16, 2016 | |||
| Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e | Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e | |||
| draft-ietf-6tisch-terminology-07 | draft-ietf-6tisch-terminology-08 | |||
| Abstract | Abstract | |||
| 6TiSCH proposes an architecture for an IPv6 multi-link subnet that is | This document provides a glossary of terminology used in IPv6 over | |||
| composed of a high speed powered backbone and a number of | the TSCH mode of IEEE 802.15.4e (6TiSCH). This document extends | |||
| IEEE802.15.4e TSCH wireless networks attached and synchronized by | existing terminology documents for Low-power and Lossy Networks. | |||
| backbone routers. This document extends existing terminology | ||||
| documents available for Low-power and Lossy Networks to provide | ||||
| additional terminology elements. | ||||
| Requirements Language | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | ||||
| "OPTIONAL" in this document are to be interpreted as described in RFC | ||||
| 2119 [RFC2119]. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on September 22, 2016. | This Internet-Draft will expire on June 19, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 | 4.3. External Informative References . . . . . . . . . . . . . 10 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6.3. External Informative References . . . . . . . . . . . . . 13 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
| 1. Introduction | 1. Introduction | |||
| The IEEE802.15.4 Medium Access Control (MAC) has evolved with | The IEEE802.15.4 Medium Access Control (MAC) has evolved with the | |||
| IEEE802.15.4e which provides in particular the Time Slotted Channel | Time Slotted Channel Hopping (TSCH) mode for industrial-type | |||
| Hopping (TSCH) mode for industrial-type applications. It provides | applications. It provides deterministic capabilities to the point | |||
| deterministic capabilities to the point that a packet that pertains | that a packet that pertains to a certain flow crosses the network | |||
| to a certain flow crosses the network from node to node following a | from node to node following a very precise schedule, like a train | |||
| very precise schedule, like a train leaves intermediate stations at | leaves intermediate stations at precise times along its path. | |||
| precise times along its path. | ||||
| This document provides additional terminology elements to cover terms | This document provides additional terminology elements to cover terms | |||
| that are new to the context of TSCH wireless networks and other | that are new to the context of TSCH wireless networks and other | |||
| deterministic networks. | deterministic networks. | |||
| 2. Terminology | 2. Terminology | |||
| The draft extends [I-D.ietf-roll-terminology] and use terms from RFC | The draft extends [RFC7102] and use terms from [RFC6550] and | |||
| 6550 [RFC6550] and RFC 6552 [RFC6552], which are all included here by | [RFC6552], which are all included here by reference. | |||
| reference. | ||||
| The draft does not reuse terms from IEEE802.15.4e such as "path" or | The draft does not reuse terms from IEEE802.15.4e such as "path" or | |||
| "link" which bear a meaning that is quite different from classical | "link" which bear a meaning that is quite different from classical | |||
| IETF parlance. | IETF parlance. | |||
| This document adds the following terms: | This document adds the following terms: | |||
| 6TiSCH: IPv6 over the Timeslotted Channel Hopping (TSCH) mode of | 6TiSCH: IPv6 over the Timeslotted Channel Hopping (TSCH) mode of | |||
| IEEE802.15.4e. It defines (i)the 6top sublayer; (ii) a | IEEE802.15.4e. It defines (i) the 6top sublayer; (ii) a | |||
| set of protocols for setting up a TSCH schedule with a | set of protocols for setting up a TSCH schedule in | |||
| centralized and/or distributed approach, for managing the | distributed approach, for managing the allocation of | |||
| allocation of resources; and (iii) the architecture to | resources; and (iii) the architecture to bind them | |||
| bind them together, for use in IPv6 TSCH based networks. | together, for use in IPv6 TSCH based networks. | |||
| 6F: IPv6 Forwarding. One of the three forwarding models | ||||
| supported by 6TiSCH. Packets are routed at layer 3, | ||||
| where Quality of Service (QoS) and Active Queue | ||||
| Management (e.g., Random Early Detection, RED, [RFC2309]) | ||||
| operations are expected to prioritize flows with | ||||
| differentiated services. | ||||
| 6top: The "6TiSCH Operation Sublayer" (6top) is the next | 6top: The "6TiSCH Operation Sublayer" (6top) is the next | |||
| highest layer of the IEEE802.15.4e TSCH medium access | highest layer of the IEEE802.15.4e TSCH medium access | |||
| control layer in the 6TiSCH Architecture. It implements | control layer. It implements and terminates the "6top | |||
| and terminates the "6top Protocol" (6P), and contains one | Protocol" (6P), and contains a "6top Scheduling Function" | |||
| or more "6top Scheduling Function" (SF). It is defined | (SF). | |||
| in [I-D.wang-6tisch-6top-protocol]. | ||||
| 6top Data Convey Model: Model describing how the 6top adaptation | ||||
| layer feeds the data flow coming from upper layers into | ||||
| TSCH. It is composed by an I-MUX module, a MUX module, a | ||||
| set of priority queues, and a PDU (Payload Data Unit). | ||||
| See [I-D.wang-6tisch-6top-protocol]. | ||||
| SF: The "6top Scheduling Function" (SF) is the policy inside | SF: The "6top Scheduling Function" (SF) "is the cell | |||
| the "6TiSCH Operation Sublayer" (6top) which decides when | management entity that add or delete cells dynamically | |||
| to add/remove cells. General guidelines for designing a | based on its allocation policy in order to fulfill cell | |||
| SF are provided in [I-D.wang-6tisch-6top-protocol]. | requirements. The cell negotiation with a neighbor is | |||
| done using 6P. General guidelines for designing a SF are | ||||
| provided in [I-D.ietf-6tisch-6top-protocol]. | ||||
| SFID: The "6top Scheduling Function Identifier" (SFID) is a | SFID: The "6top Scheduling Function Identifier" (SFID) is a | |||
| 1-byte field identifying a SF. It is defined in | 4-bit field identifying a SF. Defined in | |||
| [I-D.wang-6tisch-6top-protocol]. | [I-D.ietf-6tisch-6top-protocol]. | |||
| 6P: The "6top Protocol" (6P) allows neighbor nodes to | 6P: The "6top Protocol" (6P) allows neighbor nodes to | |||
| communicate to add/delete cells to one another in their | communicate to add/delete cells to one another in their | |||
| TSCH schedule. It is defined in | TSCH schedule. Defined in | |||
| [I-D.wang-6tisch-6top-protocol]. | [I-D.ietf-6tisch-6top-protocol]. | |||
| 6P Transaction: Part of the "6top Protocol" (6P), it consists in a | ||||
| complete negotiation between two neighbor nodes. A | ||||
| transaction starts when a node wishes to add/delete one | ||||
| or more cells to one of its neighbors; it ends when the | ||||
| cell(s) have been added / deleted from the schedule of | ||||
| both neighbor, or when the transaction has failed. It is | ||||
| defined in [I-D.wang-6tisch-6top-protocol]. | ||||
| ARO: [RFC6775] defines a number of new Neighbor Discovery | 6P Transaction: Part of the "6top Protocol" (6P), the action of two | |||
| options including the Address Registration Option (ARO). | neighbors exchanging a 6P request message and the | |||
| corresponding 6P response message. Defined in | ||||
| [I-D.ietf-6tisch-6top-protocol]. | ||||
| ASN: Absolute Slot Number, the total number of timeslots that | ASN: Absolute Slot Number, the total number of timeslots that | |||
| has elapsed since the PAN coordinator has started the | have elapsed since the PAN coordinator has started the | |||
| TSCH network. It is incremented by one at each timeslot. | TSCH network. Incremented by one at each timeslot. It | |||
| It is wide enough to not roll over in practice. See | is wide enough to not roll over in practice. See | |||
| [IEEE802154e]. | [IEEE802154-2015] and [RFC7554]. | |||
| Blacklist of Frequencies: Simply defined Blacklist in [IEEE802154e], | Blacklist of Frequencies: A set of frequencies which should not be | |||
| it is the set of frequencies among the 16 available ones, | used for communication. See [IEEE802154-2015] and | |||
| which should not be used for communication. | [RFC7554]. | |||
| BBR: Backbone Router. In the 6TiSCH architecture, it is an | BBR: Backbone Router. In the 6TiSCH architecture, an LBR and | |||
| LBR and also a IPv6 ND-efficiency-aware Router (NEAR) | also a IPv6 ND-efficiency-aware Router (NEAR) | |||
| [I-D.chakrabarti-nordmark-6man-efficient-nd]. It | [I-D.chakrabarti-nordmark-6man-efficient-nd]. Performs | |||
| performs ND proxy operations between registered devices | ND proxy operations between registered devices and | |||
| and classical ND devices that are located over the | classical ND devices that are located over the backbone. | |||
| backbone. | ||||
| Broadcast Cell: A scheduled cell used for broadcast transmission. | Broadcast Cell: A scheduled cell used for broadcast transmission. | |||
| Bundle: A group of equivalent scheduled cells, i.e. cells | Bundle: A group of equivalent scheduled cells, i.e. cells | |||
| identified by different [slotOffset, channelOffset], | identified by different [slotOffset, channelOffset], | |||
| which are scheduled for a same purpose, with the same | which are scheduled for a same purpose, with the same | |||
| neighbor, with the same flags, and the same slotframe. | neighbor, with the same flags, and the same slotframe. | |||
| The size of the bundle refers to the number of cells it | The size of the bundle refers to the number of cells it | |||
| contains. Given the length of the slotframe, the size of | contains. For a given slotframe length, the size of the | |||
| the bundle translates directly into bandwidth. A bundle | bundle translates directly into bandwidth. A bundle is a | |||
| represents a half-duplex link between nodes, one | local abstraction thar represents a half-duplex link for | |||
| transmitter and one or more receivers, with a bandwidth | either sending or receiving, with bandwidth that amounts | |||
| that amount to the sum of the cells in the bundle. A | to the sum of the cells in the bundle. A bundle is | |||
| bundle is globally identified by (source MAC, destination | globally identified by (source MAC, destination MAC, | |||
| MAC, TrackID). At Layer 3 a pair of bundles forms a | TrackID). At Layer 3, a pair of bundles forms a link. | |||
| link. By usining a well-known constant, NULLT, as | By using a well-known constant, NULLT, as TrackId for a | |||
| TrackId for a L3 link, the IP link between adjacent nodes | L3 link, the IP link between adjacent nodes A and B | |||
| A and B comprises 2 bundles: (macA, macB, NULLT) and | comprises 2 bundles: (macA, macB, NULLT) and (macB, macA, | |||
| (macB, macA, NULLT). At L2 a pair of bundles forms a | NULLT). At Layer 2, a pair of bundles forms a switching | |||
| switching state. Considered a segment A-B-C along a | state. Considered a segment A-B-C along a track, there | |||
| track, there are two bundles in node B, one incoming = | are two bundles in node B, one incoming = (macA, macB, | |||
| (macA, macB, trackId) and one outgoing = (macB, macC, | trackId) and one outgoing = (macB, macC, trackId). | |||
| trackId). | ||||
| CCA: Clear Channel Assessment. Mechanism defined in | ||||
| [IEEE802154-2015], section 6.2.5.2. In a TSCH network, | ||||
| CCA can be used to detect other radio networks in | ||||
| vicinity. Nodes listen the channel before sending, to | ||||
| detect other ongoing transmissions. Because the network | ||||
| is synchronized, CCA cannot be used to detect colliding | ||||
| transmission within the same network. CCA is necessary | ||||
| for the 6TiSCH minimal configuration | ||||
| [I-D.ietf-6tisch-minimal] in shared slots, and in | ||||
| presence of multiple instances of 6TiSCH networks. | ||||
| Cell: A single element in the TSCH schedule, identified by a | Cell: A single element in the TSCH schedule, identified by a | |||
| slotOffset, a channelOffset, a slotframeHandle. A cell | slotOffset, a channelOffset, a slotframeHandle. A cell | |||
| can be scheduled or unscheduled. | can be scheduled or unscheduled. | |||
| Centralized Cell Reservation: A reservation of a cell done by a | Centralized Cell Reservation: A reservation of a cell done by a | |||
| centralized entity (e.g., a PCE) in the network. | centralized entity (e.g., a PCE) in the network. | |||
| Centralized Track Reservation: A reservation of a track done by a | Centralized Track Reservation: A reservation of a track done by a | |||
| centralized entity (e.g., a PCE) in the network. | centralized entity (e.g., a PCE) in the network. | |||
| ChannelOffset: Identifies a row in the TSCH schedule. The number of | ChannelOffset: Identifies a row in the TSCH schedule. The number of | |||
| available channelOffsets is equal to the number of | available channelOffset values is equal to the number of | |||
| available frequencies. The channelOffset translates into | available frequencies. The channelOffset translates into | |||
| a frequency when the communication takes place, resulting | a frequency when the communication takes place, resulting | |||
| in channel hopping, as detailed in [RFC7554]. | in channel hopping. See [RFC7554]. | |||
| Channel Distribution/Usage (CDU) matrix: : Matrix of cells (i,j) | Channel Distribution/Usage (CDU) matrix: : Matrix of cells (i,j) | |||
| representing the spectrum (channel) distribution among | representing the spectrum (channel) distribution among | |||
| the different nodes in the 6TiSCH network. The CDU | the different nodes in the 6TiSCH network. The CDU | |||
| matrix has width in timeslots, equal to the period of the | matrix has width in timeslots, equal to the period of the | |||
| network scheduling operation, and height equal to the | network scheduling operation, and height equal to the | |||
| number of available channels. Every cell (i,j) in the | number of available channels. Every cell (i,j) in the | |||
| CDU, identified by (slotOffset, channelOffset), belongs | CDU, identified by (slotOffset, channelOffset), belongs | |||
| to a specific chunk. It has to be noticed that such a | to a specific chunk. It has to be noticed that such a | |||
| matrix which includes all the cells grouped in chunks, | matrix which includes all the cells grouped in chunks, | |||
| skipping to change at page 5, line 45 ¶ | skipping to change at page 5, line 20 ¶ | |||
| Chunk: A well-known list of cells, distributed in time and | Chunk: A well-known list of cells, distributed in time and | |||
| frequency, within a CDU matrix; a chunk represents a | frequency, within a CDU matrix; a chunk represents a | |||
| portion of a CDU matrix. The partition of the CDU in | portion of a CDU matrix. The partition of the CDU in | |||
| chunks is globally known by all the nodes in the network | chunks is globally known by all the nodes in the network | |||
| to support the appropriation process, which is a | to support the appropriation process, which is a | |||
| negotiation between nodes within an interference domain. | negotiation between nodes within an interference domain. | |||
| A node that manages to appropriate a chunk gets to decide | A node that manages to appropriate a chunk gets to decide | |||
| which transmissions will occur over the cells in the | which transmissions will occur over the cells in the | |||
| chunk within its interference domain (i.e., a parent node | chunk within its interference domain (i.e., a parent node | |||
| will decide when the cells within the appropriated chunk | will decide when the cells within the appropriated chunk | |||
| are used and by which node, among its children.) | are used and by which node, among its children. | |||
| Communication Paradigm: It is Associated with the Information Model | ||||
| [RFC3444] of the state that is exchanged, and indicates: | ||||
| the location of that state (e.g., centralized vs. | ||||
| distributed, RESTful, etc.), the numbers of parties | ||||
| (e.g., point to point, P2P, vs. point to multi-point, | ||||
| P2MP) and the relationship between parties (e.g., master/ | ||||
| slave vs. peers) at a high level of protocol abstraction. | ||||
| Layer 5 client/server REST is a typical communication | ||||
| paradigm, but industrial protocols also use publish/ | ||||
| subscribe which is P2MP and source/sink which is multi- | ||||
| point to multi-point (MP2MP) and primarily used for | ||||
| alarms and alerts at the application layer. At layer 3, | ||||
| basic flooding, P2P synchronization and path-marking | ||||
| (RSVP-like) are commonly used paradigms, whereas at layer | ||||
| 2, master/slave polling and peer-to-peer forwarding are | ||||
| classical examples. | ||||
| DAR/DAC: [RFC6775] defines the Duplicate Address Request (DAR) and | ||||
| Duplicate Address Confirmation (DAC) options to turn the | ||||
| multicast Duplicate Address Detection protocol into a | ||||
| unicast-based multi-hop process between routers and the | ||||
| backbone router. | ||||
| Dedicated Cell: A cell that is reserved for a given node to transmit | Dedicated Cell: A cell that is reserved for a given node to transmit | |||
| to a specific neighbor. | to a specific neighbor. | |||
| Deterministic Network: A Deterministic Network supports traffic | Deterministic Network: The generic concept of deterministic network | |||
| flows with communication patterns that are known a | is defined in [I-D.ietf-detnet-architecture]. When | |||
| priori. Thus, routing paths and communication schedules | applied to 6TiSCH it refers to the reservation of tracks | |||
| can be computed in advance, in a fashion similar to a | which guarantee an end to end latency and optimize the | |||
| railway system, to avoid losses due to packet collisions, | PDR for well-characterized flows. | |||
| and to perform global optimizations across multiple | ||||
| flows. A deterministic network can allocates the | ||||
| required resources (buffers, processors, medium access) | ||||
| along the multi-hop routing path at the precise moment | ||||
| the resources are needed. | ||||
| Distributed Cell Reservation: A reservation of a cell done by one or | Distributed Cell Reservation: A reservation of a cell done by one or | |||
| more in-network entities (typically a connection | more in-network entities (typically a connection | |||
| endpoint). | endpoint). | |||
| Distributed Track Reservation: A reservation of a track done by one | Distributed Track Reservation: A reservation of a track done by one | |||
| or more in-network entities (typically a connection | or more in-network entities (typically a connection | |||
| endpoint). | endpoint). | |||
| EARO: [I-D.thubert-6lo-rfc6775-update-reqs] extends the ARO | ||||
| option to include some additional fields necessary to | ||||
| distinguish duplicate addresses from nodes that have | ||||
| moved networks when there are mulitple LLNs linked over a | ||||
| backbone. | ||||
| EB: Enhanced Beacon frame used by a node to announce the | EB: Enhanced Beacon frame used by a node to announce the | |||
| presence of the network. It contains useful information | presence of the network. It contains enough information | |||
| (see [IEEE802154e] for details) that allow a new node to | for a joining node to synchronize to the network. See | |||
| synhronize and join the network. | [IEEE802154-2015] and [RFC7554]. | |||
| FF: 6LoWPAN Fragment Forwarding. It is one of the three | ||||
| forwarding models supported by 6TiSCH. The 6LoWPAN | ||||
| Fragment is used as a label for switching at the 6LoWPAN | ||||
| sublayer, as defined in | ||||
| [I-D.thubert-roll-forwarding-frags]. | ||||
| GMPLS: Generalized Multi-Protocol Label Switching, a 2.5 layer | ||||
| service that is used to forward packets based on the | ||||
| concept of generalized labels. | ||||
| Hard Cell: A scheduled cell which the 6top sublayer cannot | Hard Cell: A scheduled cell which the 6top sublayer cannot relocate. | |||
| reallocate. See [I-D.wang-6tisch-6top-protocol]. | ||||
| Hopping Sequence: Ordered sequence of frequencies, identified by a | Hopping Sequence: Ordered sequence of frequencies, identified by a | |||
| Hopping_Sequence_ID, used for channel hopping, when | Hopping_Sequence_ID, used for channel hopping, when | |||
| translating the channel offset value into a frequency | translating the channel offset value into a frequency | |||
| (i.e., PHY channel). See [IEEE802154e] and [RFC7554]. | (i.e., PHY channel). See [IEEE802154-2015] and | |||
| [RFC7554]. | ||||
| IE: Information Elements, a list of Type-Length-Value | ||||
| containers placed at the end of the MAC header, used to | ||||
| pass data between layers or devices. A small number of | ||||
| types are defined by [IEEE802154e], but a range of types | ||||
| is available for extensions, and thus, is exploitable by | ||||
| 6TiSCH. See [IEEE802154e]. | ||||
| I-MUX module: Inverse-Multiplexer, a classifier that receives | ||||
| 6LoWPAN frames and places them into priority queues. See | ||||
| [I-D.wang-6tisch-6top-protocol]. | ||||
| Interaction Model: It is a particular way of implementing a | ||||
| communication paradigm. Defined at a lower level of | ||||
| abstraction, it includes protocol-specific details such | ||||
| as a particular method (e.g., a REST GET) and a Data | ||||
| Model for the state to be exchanged. | ||||
| Interference Domain: The Interference Domain of a given | IE: Information Element, a Type-Length-Value containers | |||
| (transmitter) node A includes all the nodes in its | placed at the end of the MAC header, used to pass data | |||
| neighbourhood that can generate interference at its | between layers or devices. Some IE identifiers are | |||
| receiver B, when transmitting on the same channel (i.e., | managed by the IEEE [IEEE802154-2015]. Some IE | |||
| using the same frequency). | identifiers are managed by the IETF | |||
| [I-D.kivinen-802-15-ie]. | ||||
| JCE: The Join Coordination Entity (JCE) is a central entity | JCE: The Join Coordination Entity (JCE) is a central entity | |||
| like the Path Computation Element (PCE), that may assist | that coordinates the joining of new nodes in the network. | |||
| in several aspects of the join protocol, such as | See [I-D.ietf-6tisch-minimal-security] and | |||
| authentication, authorization, and configuration. | [I-D.ietf-6tisch-dtsecurity-secure-join]. | |||
| JA: The Join Assistant (JA) is a one-hop neighbor of a | JA: The Join Assistant (JA) is a one-hop neighbor of a | |||
| joining node that may facilitate it to become meaningful | joining node that may facilitate it to become meaningful | |||
| part of the network (e.g., by serving as a local | part of the network (e.g., by serving as a local | |||
| connectivity point to the remainder of the network). | connectivity point to the remainder of the network). JA | |||
| emits EBs, used by JNs to synchronize to the network. | ||||
| See [I-D.ietf-6tisch-minimal-security] and | ||||
| [I-D.ietf-6tisch-dtsecurity-secure-join]. | ||||
| JN: The Joining Node (JN) is a device attempting to join a | ||||
| particular 6TiSCH network. See | ||||
| [I-D.ietf-6tisch-minimal-security]. | ||||
| Join Protocol: The protocol which secures initial communication | Join Protocol: The protocol which secures initial communication | |||
| between a joining node and the JCE. | between a joining node and the JCE. | |||
| LBR: Low-power Lossy Network (LLN) Border Router. It is an | LBR: Low-power Lossy Network (LLN) Border Router. It is an | |||
| LLN device, usually powered, that acts as a Border Router | LLN device, usually powered, that acts as a Border Router | |||
| to the outside within the 6TiSCH architecture. | to the outside within the 6TiSCH architecture. | |||
| Link: A communication facility or medium over which nodes can | Link: A communication facility or medium over which nodes can | |||
| communicate at the link layer, i.e., the layer | communicate at the link layer, i.e., the layer | |||
| immediately below IP. Thus, the IETF parlance for the | immediately below IP. Thus, the IETF parlance for the | |||
| term "Link" is adopted, as opposed to the IEEE802.15.4e | term "Link" is adopted, as opposed to the IEEE802.15.4e | |||
| terminology. In the context of the 6TiSCH architecture, | terminology. | |||
| which applies to Low Power Lossy Networks (LLNs), an IPv6 | ||||
| subnet is usually not congruent to a single link and | ||||
| techniques such as IPv6 Neighbor Discovery Proxying are | ||||
| used to achieve reachability within the multilink subnet. | ||||
| A link is distinct from a track. In fact, link local | ||||
| addresses are not expected to be used over a track for | ||||
| end to end communication. Finally, from the Layer 3 | ||||
| perspective (where the inner complexities of TSCH | ||||
| operations are hidden to enable classical IP routing and | ||||
| forwarding), a single radio interface may be seen as a | ||||
| number of Links with different capabilities for unicast | ||||
| or multicast services. | ||||
| MAC: Medium Access Control. | ||||
| MUX Module: Multiplexer, the entity that dequeues frames from | ||||
| priority queues and associates them to a cell for | ||||
| transmission. See [I-D.wang-6tisch-6top-sublayer]. | ||||
| NEAR: IPv6 ND-efficiency-aware Router, as defined in | ||||
| [I-D.chakrabarti-nordmark-6man-efficient-nd]. | ||||
| NME: Network Management Entity, the entity in the network | ||||
| managing cells and other device resources. It may | ||||
| cooperate with the PCE. It interacts with LLN nodes | ||||
| through the backbone router. | ||||
| Operational Network: A IEEE802.15.4e network whose encryption/ | Operational Network: A IEEE802.15.4e network whose encryption/ | |||
| authentication keys are determined by some algorithms/ | authentication keys are determined by some algorithms/ | |||
| protocols. There may be network-wide group keys, or per- | protocols. There may be network-wide group keys, or per- | |||
| link keys. | link keys. | |||
| Operational Network Key: A Link-layer key known by all authorized | (to) Relocate a Cell: The action operated by the 6top sublayer of | |||
| nodes, used for multicast messages. | ||||
| PCE: Path Computation Element, the entity in the network which | ||||
| is responsible for building and maintaining the TSCH | ||||
| schedule, when centralized scheduling is used. | ||||
| QoS: Quality of Service. | ||||
| (to) Reallocate a Cell: The action operated by the 6top sublayer of | ||||
| changing the slotOffset and/or channelOffset of a soft | changing the slotOffset and/or channelOffset of a soft | |||
| cell. | cell. | |||
| (to) Schedule a Cell: The action of turning an unscheduled cell into | (to) Schedule a Cell: The action of turning an unscheduled cell into | |||
| a scheduled cell. | a scheduled cell. | |||
| Scheduled cell: A cell which is assigned a neighbor MAC address | Scheduled cell: A cell which is assigned a neighbor MAC address | |||
| (broadcast address is also possible), and one or more of | (broadcast address is also possible), and one or more of | |||
| the following flags: TX, RX, shared, timeskeeping. A | the following flags: TX, RX, shared, timeskeeping. A | |||
| scheduled cell can be used by the IEEE802.15.4e TSCH | scheduled cell can be used by the IEEE802.15.4e TSCH | |||
| implementation to communicate. A scheduled cell can be | implementation to communicate. A scheduled cell can be | |||
| either a hard or a soft cell. | either a hard or a soft cell. | |||
| Shared Cell: A cell marked with both the "TX" and "shared" flags. | Shared Cell: A cell marked with both the "TX" and "shared" flags. | |||
| This cell can be used by more than one transmitter node. | This cell can be used by more than one transmitter node. | |||
| A backoff algorithm is used to resolve contention. See | A back-off algorithm is used to resolve contention. See | |||
| [RFC7554]. | [IEEE802154-2015] and [RFC7554]. | |||
| SlotOffset: Identifies a column in the TSCH schedule, i.e., the | SlotOffset: Identifies a column in the TSCH schedule, i.e., the | |||
| number of timeslots since the beginning of the current | number of timeslots since the beginning of the current | |||
| iteration of the slotframe. | iteration of the slotframe. See [IEEE802154-2015] and | |||
| [RFC7554]. | ||||
| Slotframe: A MAC-level abstraction that is internal to the node and | Slotframe: A collection of timeslots repeating in time, analogous to | |||
| contains a series of timeslots of equal length and | a superframe in that it defines periods of communication | |||
| priority. It is characterized by a slotframe_ID, and a | opportunities. It is characterized by a slotframe_ID, | |||
| slotframe_size. Multiple slotframes can coexist in a | and a slotframe_size. Multiple slotframes can coexist in | |||
| node's schedule, i.e., a node can have multiple | a node's schedule, i.e., a node can have multiple | |||
| activities scheduled in different slotframes, based on | activities scheduled in different slotframes, based on | |||
| the priority of its packets/traffic flows. The timeslots | the priority of its packets/traffic flows. The timeslots | |||
| in the Slotframe are indexed by the SlotOffset; the first | in the Slotframe are indexed by the SlotOffset; the first | |||
| timeslot is at SlotOffset 0. | timeslot is at SlotOffset 0. See [IEEE802154-2015] and | |||
| [RFC7554]. | ||||
| Soft Cell: A scheduled cell which the 6top sublayer can reallocate, | ||||
| as described in [I-D.wang-6tisch-6top-protocol]. | ||||
| TF: Track Forwarding. It is the simplest and fastest | Soft Cell: A scheduled cell which the 6top sublayer can relocate. | |||
| forwarding model supported by 6TiSCH. It is a GMPLS-like | ||||
| forwarding model. The incoming bundle (and thus, the | ||||
| input cell) characterizes the flow and indicates the | ||||
| outgoing bundle (and output cell). | ||||
| Timeslot: A basic communication unit in TSCH which allows a | Timeslot: A basic communication unit in TSCH which allows a | |||
| transmitter node to send a frame to a receiver neighbor, | transmitter node to send a frame to a receiver neighbor, | |||
| and that receiver neighbor to optionally send back an | and that receiver neighbor to optionally send back an | |||
| acknowledgment. | acknowledgment. See [IEEE802154-2015] and [RFC7554]. | |||
| Time Source Neighbor: A neighbor that a node uses as its time | Time Source Neighbor: A neighbor that a node uses as its time | |||
| reference, and to which it needs to keep its clock | reference, and to which it needs to keep its clock | |||
| synchronized. A node can have one or more time source | synchronized. See [IEEE802154-2015] and [RFC7554]. | |||
| neighbors. | ||||
| Track: A determined sequence of cells along a multi-hop path. | Track: A determined sequence of cells along a multi-hop path. | |||
| It is typically the result of a track reservation. The | It is typically the result of a track reservation. The | |||
| node that initializes the process for establishing a | node that initializes the process of establishing a track | |||
| track is the owner of the track. The latter assigns a | is the owner of the track. The latter assigns a unique | |||
| unique identifier to the track, called TrackID. | identifier to the track, called TrackID. | |||
| TrackID: Unique identifier of a track, assigned by the owner of | TrackID: Unique identifier of a track, assigned by the owner of | |||
| the track. | the track. | |||
| TSCH: Time Slotted Channel Hopping, a medium access mode of the | TSCH: Time Slotted Channel Hopping, a medium access mode of the | |||
| [IEEE802154e] standard which uses time synchronization to | [IEEE802154-2015] standard which uses time | |||
| achieve ultra low-power operation and channel hopping to | synchronization to achieve ultra low-power operation and | |||
| enable high reliability. | channel hopping to enable high reliability. See | |||
| [IEEE802154-2015] and [RFC7554]. | ||||
| TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset | TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset | |||
| and a channelOffset. The TSCH schedule contains all the | and a channelOffset. The TSCH schedule contains all the | |||
| scheduled cells from all slotframes and is sufficient to | scheduled cells from all slotframes and is sufficient to | |||
| qualify the communication in the TSCH network. The | qualify the communication in the TSCH network. The | |||
| "width of the matrix is equal to the number of scheduled | ||||
| timeslots in all the concurrent active slotframes. The | ||||
| number of channelOffset values (the "height" of the | number of channelOffset values (the "height" of the | |||
| matrix) is equal to the number of available frequencies. | matrix) is equal to the number of available frequencies. | |||
| See [IEEE802154-2015] and [RFC7554]. | ||||
| Unscheduled Cell: A cell which is not used by the IEEE802.15.4e TSCH | Unscheduled Cell: A cell which is not used by the IEEE802.15.4e TSCH | |||
| implementation. | implementation. See [IEEE802154-2015] and [RFC7554]. | |||
| 3. IANA Considerations | ||||
| This specification does not require IANA action. | ||||
| 4. Security Considerations | ||||
| This specification is not found to introduce new security threats. | ||||
| 5. Acknowledgments | ||||
| Thanks to the IoT6 European Project (STREP) of the 7th Framework | 3. Security Considerations | |||
| Program (Grant 288445). | ||||
| 6. References | Since this document specifies terminology and does not specify new | |||
| procedures or protocols, it raises no new security issues. | ||||
| 6.1. Normative References | 4. References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | 4.1. Normative References | |||
| Requirement Levels", BCP 14, RFC 2119, | ||||
| DOI 10.17487/RFC2119, March 1997, | ||||
| <http://www.rfc-editor.org/info/rfc2119>. | ||||
| [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, | [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, | |||
| S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., | S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., | |||
| Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, | Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, | |||
| S., Wroclawski, J., and L. Zhang, "Recommendations on | S., Wroclawski, J., and L. Zhang, "Recommendations on | |||
| Queue Management and Congestion Avoidance in the | Queue Management and Congestion Avoidance in the | |||
| Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, | Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, | |||
| <http://www.rfc-editor.org/info/rfc2309>. | <http://www.rfc-editor.org/info/rfc2309>. | |||
| [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between | [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between | |||
| Information Models and Data Models", RFC 3444, | Information Models and Data Models", RFC 3444, | |||
| DOI 10.17487/RFC3444, January 2003, | DOI 10.17487/RFC3444, January 2003, | |||
| <http://www.rfc-editor.org/info/rfc3444>. | <http://www.rfc-editor.org/info/rfc3444>. | |||
| [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., | ||||
| and A. Yegin, "Protocol for Carrying Authentication for | ||||
| Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, | ||||
| May 2008, <http://www.rfc-editor.org/info/rfc5191>. | ||||
| [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | ||||
| Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | ||||
| January 2012, <http://www.rfc-editor.org/info/rfc6347>. | ||||
| [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., | [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., | |||
| Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, | Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, | |||
| JP., and R. Alexander, "RPL: IPv6 Routing Protocol for | JP., and R. Alexander, "RPL: IPv6 Routing Protocol for | |||
| Low-Power and Lossy Networks", RFC 6550, | Low-Power and Lossy Networks", RFC 6550, | |||
| DOI 10.17487/RFC6550, March 2012, | DOI 10.17487/RFC6550, March 2012, | |||
| <http://www.rfc-editor.org/info/rfc6550>. | <http://www.rfc-editor.org/info/rfc6550>. | |||
| [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing | [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing | |||
| Protocol for Low-Power and Lossy Networks (RPL)", | Protocol for Low-Power and Lossy Networks (RPL)", | |||
| RFC 6552, DOI 10.17487/RFC6552, March 2012, | RFC 6552, DOI 10.17487/RFC6552, March 2012, | |||
| <http://www.rfc-editor.org/info/rfc6552>. | <http://www.rfc-editor.org/info/rfc6552>. | |||
| [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | |||
| Bormann, "Neighbor Discovery Optimization for IPv6 over | Bormann, "Neighbor Discovery Optimization for IPv6 over | |||
| Low-Power Wireless Personal Area Networks (6LoWPANs)", | Low-Power Wireless Personal Area Networks (6LoWPANs)", | |||
| RFC 6775, DOI 10.17487/RFC6775, November 2012, | RFC 6775, DOI 10.17487/RFC6775, November 2012, | |||
| <http://www.rfc-editor.org/info/rfc6775>. | <http://www.rfc-editor.org/info/rfc6775>. | |||
| [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and | |||
| Application Protocol (CoAP)", RFC 7252, | Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January | |||
| DOI 10.17487/RFC7252, June 2014, | 2014, <http://www.rfc-editor.org/info/rfc7102>. | |||
| <http://www.rfc-editor.org/info/rfc7252>. | ||||
| [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using | [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using | |||
| IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the | IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the | |||
| Internet of Things (IoT): Problem Statement", RFC 7554, | Internet of Things (IoT): Problem Statement", RFC 7554, | |||
| DOI 10.17487/RFC7554, May 2015, | DOI 10.17487/RFC7554, May 2015, | |||
| <http://www.rfc-editor.org/info/rfc7554>. | <http://www.rfc-editor.org/info/rfc7554>. | |||
| 6.2. Informative References | 4.2. Informative References | |||
| [I-D.chakrabarti-nordmark-6man-efficient-nd] | [I-D.chakrabarti-nordmark-6man-efficient-nd] | |||
| Chakrabarti, S., Nordmark, E., Thubert, P., and M. | Chakrabarti, S., Nordmark, E., Thubert, P., and M. | |||
| Wasserman, "IPv6 Neighbor Discovery Optimizations for | Wasserman, "IPv6 Neighbor Discovery Optimizations for | |||
| Wired and Wireless Networks", draft-chakrabarti-nordmark- | Wired and Wireless Networks", draft-chakrabarti-nordmark- | |||
| 6man-efficient-nd-07 (work in progress), February 2015. | 6man-efficient-nd-07 (work in progress), February 2015. | |||
| [I-D.ietf-roll-terminology] | [I-D.ietf-6tisch-6top-protocol] | |||
| Vasseur, J., "Terms used in Routing for Low power And | Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- | |||
| Lossy Networks", draft-ietf-roll-terminology-13 (work in | ietf-6tisch-6top-protocol-03 (work in progress), October | |||
| progress), October 2013. | 2016. | |||
| [I-D.ietf-6tisch-dtsecurity-secure-join] | ||||
| Richardson, M., "6tisch Secure Join protocol", draft-ietf- | ||||
| 6tisch-dtsecurity-secure-join-00 (work in progress), | ||||
| December 2016. | ||||
| [I-D.ietf-6tisch-minimal] | ||||
| Vilajosana, X. and K. Pister, "Minimal 6TiSCH | ||||
| Configuration", draft-ietf-6tisch-minimal-17 (work in | ||||
| progress), November 2016. | ||||
| [I-D.ietf-6tisch-minimal-security] | ||||
| malisa.vucinic@st.com, m., Simon, J., and K. Pister, | ||||
| "Minimal Security Framework for 6TiSCH", draft-ietf- | ||||
| 6tisch-minimal-security-00 (work in progress), December | ||||
| 2016. | ||||
| [I-D.ietf-detnet-architecture] | ||||
| Finn, N. and P. Thubert, "Deterministic Networking | ||||
| Architecture", draft-ietf-detnet-architecture-00 (work in | ||||
| progress), September 2016. | ||||
| [I-D.kivinen-802-15-ie] | ||||
| Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information | ||||
| Element for IETF", draft-kivinen-802-15-ie-04 (work in | ||||
| progress), October 2016. | ||||
| [I-D.thubert-6lo-rfc6775-update-reqs] | [I-D.thubert-6lo-rfc6775-update-reqs] | |||
| Thubert, P. and P. Stok, "Requirements for an update to | Thubert, P. and P. Stok, "Requirements for an update to | |||
| 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-reqs-06 | 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-reqs-07 | |||
| (work in progress), January 2015. | (work in progress), April 2016. | |||
| [I-D.thubert-roll-forwarding-frags] | [I-D.thubert-roll-forwarding-frags] | |||
| Thubert, P. and J. Hui, "LLN Fragment Forwarding and | Thubert, P. and J. Hui, "LLN Fragment Forwarding and | |||
| Recovery", draft-thubert-roll-forwarding-frags-02 (work in | Recovery", draft-thubert-roll-forwarding-frags-02 (work in | |||
| progress), September 2013. | progress), September 2013. | |||
| [I-D.wang-6tisch-6top-protocol] | 4.3. External Informative References | |||
| Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- | ||||
| wang-6tisch-6top-protocol-00 (work in progress), March | ||||
| 2016. | ||||
| [I-D.wang-6tisch-6top-sublayer] | ||||
| Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer | ||||
| (6top)", draft-wang-6tisch-6top-sublayer-04 (work in | ||||
| progress), November 2015. | ||||
| 6.3. External Informative References | ||||
| [IEEE802154e] | [IEEE802154-2015] | |||
| IEEE standard for Information Technology, "IEEE std. | IEEE standard for Information Technology, "IEEE Std | |||
| 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area | 802.15.4-2015 Standard for Low-Rate Wireless Personal Area | |||
| Networks (LR-WPANs) Amendment 1: MAC sublayer", April | Networks (WPANs)", December 2015. | |||
| 2012. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Maria Rita Palattella (editor) | Maria Rita Palattella (editor) | |||
| University of Luxembourg | Luxembourg Institute of Science and Technology | |||
| Interdisciplinary Centre for Security, Reliability and Trust | Department 'Environmental Research and Innovation' (ERIN) | |||
| 4, rue Alphonse Weicker | 41, rue du Brill | |||
| Luxembourg L-2721 | Belvaux L-4422 | |||
| Luxembourg | Luxembourg | |||
| Phone: (+352) 46 66 44 5841 | Phone: (+352) 275 888-5055 | |||
| Email: maria-rita.palattella@uni.lu | Email: mariarita.palattella@list.lu | |||
| Pascal Thubert | Pascal Thubert | |||
| Cisco Systems, Inc | Cisco Systems, Inc | |||
| Village d'Entreprises Green Side | Village d'Entreprises Green Side | |||
| 400, Avenue de Roumanille | 400, Avenue de Roumanille | |||
| Batiment T3 | Batiment T3 | |||
| Biot - Sophia Antipolis 06410 | Biot - Sophia Antipolis 06410 | |||
| France | France | |||
| Phone: +33 497 23 26 34 | Phone: +33 497 23 26 34 | |||
| Email: pthubert@cisco.com | Email: pthubert@cisco.com | |||
| End of changes. 57 change blocks. | ||||
| 315 lines changed or deleted | 189 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||