idnits 2.17.1 draft-karaagac-6tisch-int-01.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 has text resembling RFC 2119 boilerplate text. -- The document date (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE802154e' is mentioned on line 647, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 641, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-08 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-08 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Karaagac 3 Internet-Draft J. Hoebeke 4 Intended status: Standards Track Ghent University - imec 5 Expires: January 14, 2021 July 13, 2020 7 In-band Network Telemetry for 6TiSCH Networks 8 draft-karaagac-6tisch-int-01 10 Abstract 12 This document describes In-band Network Telemetry for 6TiSCH 13 Networks, offering a flexible monitoring solution with minimal 14 resource consumption and communication overhead while supporting a 15 wide range of monitoring operations and strategies for dealing with 16 various network scenarios and use cases. It enables 6TiSCH networks 17 to collect per-packet and per-hop monitoring information by 18 piggybacking telemetry information onto the data packets by 19 exploiting the remaining space in the IEEE 802.15.4e frames, thus not 20 impacting network behavior and performance. This document also 21 discusses the data fields and associated data types for 6TiSCH INT 22 mechanism. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 14, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. In-band Network Telemetry for 6TiSCH . . . . . . . . . . . . 4 61 2.1. Capacity-Neutral Network Monitoring . . . . . . . . . . . 5 62 2.2. INT Data Model, Format and Encoding . . . . . . . . . . . 6 63 2.2.1. INT Sub-IE Format . . . . . . . . . . . . . . . . . . 8 64 2.2.2. Telemetry Data Model . . . . . . . . . . . . . . . . 10 65 2.3. INT Strategies . . . . . . . . . . . . . . . . . . . . . 12 66 2.3.1. Opportunistic Logic . . . . . . . . . . . . . . . . . 12 67 2.3.2. Probabilistic Logic . . . . . . . . . . . . . . . . . 12 68 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 4.1. IETF IE Subtype INT . . . . . . . . . . . . . . . . . . . 13 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 6.2. Informative References . . . . . . . . . . . . . . . . . 14 75 6.3. External Informative References . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 For continuous, persistent and problem-free operation of "IPv6 over 81 the TSCH mode of IEEE 802.15.4e" (6TiSCH) Networks 82 [I-D.ietf-6tisch-architecture], it is critical to have visibility and 83 awareness into what is happening on the network at any one time. For 84 centrally managed 6TiSCH networks, it is required to collect and 85 analyze network performance data, often as close to real time as 86 possible. For TiSCH networks with distributed management solutions, 87 it is still vital to monitor network nodes continuously or 88 periodically to ensure their functioning, detect relevant problems, 89 perform traffic engineering and network optimization. 91 Nevertheless, efficient monitoring and management mechanisms for 92 these networks have not been addressed adequately. First, 93 traditional active network and health monitoring systems (i.e. 94 statistical polling, active probing) are of limited applicability in 95 these constrained and dynamic networks due to their static and 96 inefficient design. Especially, considering the constrained nature 97 of sensor networks, the introduced control traffic can occupy 98 extensive network resources, impact network behavior and/or interfere 99 with the scheduled application traffic flow. Secondly, the passive 100 health monitoring and tomography methods can only offer limited 101 capabilities for collecting in-network state information and 102 telemetry data, thus are not sufficient for advanced network 103 monitoring and fine-grained management operations. In addition, the 104 6TiSCH WG is defining a management interface, based on CoAP 105 Management Interface (CoMI) [I-D.ietf-core-comi], which can be used 106 to monitor network performance and perform network configurations 107 [I-D.ietf-6tisch-coap]. However, performing telemetry via CoMI 108 interfaces will result in a polling-based monitoring scheme which may 109 cause a large amount of control traffic. 111 This document specifies an In-Band Network Telemetry (INT) mechanism 112 adapted to 6TiSCH Networks. It provides the definition of telemetry 113 semantics and data models for 6TiSCH Networks and their efficient 114 encoding in the IEEE 802.15.4e [IEEE802154e] frames. Additionally, 115 it defines a set of novel telemetry operations and strategies for 116 dealing with various network scenarios and system interactions. 118 The proposed INT-based network monitoring solution creates an 119 efficient, adaptive and flexible design which offers several novel 120 monitoring functionalities and telemetry operations for 6TiSCH 121 Networks. 123 o Opportunistic piggybacking mechanism that eliminates the need for 124 artificial probing packets and resource reservation for monitoring 125 data in 6TiSCH Networks. 127 o Real-time monitoring capabilities where the collected telemetry 128 data reflects the momentary network performance and the exact 129 treatment that an application packet encounters. 131 o The combination of real-time edge-to-edge packet-level network 132 information (e.g. reliability, latency) and hop-by-hop telemetry 133 data (e.g. per-hop latencies, queue states and link qualities). 135 o Flexibility in terms of telemetry initiation and addition 136 approaches: continuous, periodic, event-driven or query-driven. 138 o Flexibility for forwarding nodes to initiate an INT operation on a 139 packet with another source. 141 o Flexibility for source and forwarding nodes to decide what to add: 142 even a subset of INT entries if not all of them fit in the frame. 144 1.1. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in BCP 14 [RFC2119] 149 [RFC8174] when, and only when, they appear in all capitals, as shown 150 here. 152 Readers are expected to be familiar with terms and concepts defined 153 in [IEEE802154e] and [I-D.ietf-6tisch-architecture]. 155 "RPL", "RPL Dag Rank", MaxRankIncrease, MinRankIncrease and RootRank 156 are defined in the "RPL: IPv6 Routing Protocol for Low-Power and 157 Lossy Networks" [RFC6550] specification. 159 This document refers also to the following terminology. 161 INT : In-band Network Telemetry 163 E2E : End-to-End 165 HBH : Hop-by-Hop 167 2. In-band Network Telemetry for 6TiSCH 169 INT, or also referred to as In-situ Operations, Administration, and 170 Maintenance (iOAM) [I-D.ietf-ippm-ioam-data], is created to 171 complement current out-of-band monitoring mechanisms and allows for 172 telemetry metadata to be collected as packets traverse a network. 173 The term "in-band" refers to the fact that telemetry data is carried 174 within data packets rather than being sent within specifically 175 dedicated packets. Therefore, it does not require artificial probing 176 packets or dedicated middle-boxes, and the network state is obtained 177 at the exact point in time the real user traffic passes through. 178 Also, the insertion of in-band information does not change the 179 forwarding behavior of the packet. However, it might impact the 180 packet delivery ratios (PDR) due to the increase in the length of the 181 transmitted frames. 183 The 6TiSCH INT mechanism collects the telemetry data while a packet 184 is traversing towards the Backbone Router. This measurement data can 185 typically be node or network state information such as health/failure 186 reports, link/neighbor statistics, network topology and node/link 187 occupancy. When the packets reach the edge (backbone router) of the 188 network, the telemetry metadata is removed and telemetry reports are 189 generated to be used by the Network Management Entity (NME) for 190 further visualization, analysis and management. 192 2.1. Capacity-Neutral Network Monitoring 194 In a Timeslotted Channel Hopping (TSCH) [RFC7554] network, time is 195 globally synchronized and is sliced up into time slots. The time 196 synchronization in the network means that all nodes share a timeslot 197 counter, named Absolute Slot Number (ASN), indicating the total 198 number of slots which have passed since the network has started 199 [IEEE802154e]. The overall communication is orchestrated by a 200 schedule which instructs each node what to do (transmit, receive, 201 sleep) in each timeslot [IEEE802154e]. In this TSCH schedule, a 202 single element, named cell, is identified by a pair of slotOffset and 203 channelOffset, which is used to define the communication time and 204 frequency. 206 The duration of a time slot is not defined by the standard, but it is 207 defined to be long enough to send a data frame, handle the radio 208 turnaround and receive an ACK, typically being 10ms. With radios 209 that are compliant with IEEE 802.15.4 operating in the 2.4 GHz 210 frequency band, a maximum-length frame of 127 bytes is considered, 211 which takes around 4 ms to transmit [RFC7554]. Whatever size that a 212 node is sending, the resources are reserved for that node so that it 213 can transmit a data frame of 127 bytes. If the node has a shorter 214 frame to send, there will be remaining time for that node to sleep or 215 stay idle. That means the reserved time/bandwidth resources are 216 wasted, instead of being used for other good reasons. Therefore, 217 this paper proposes a mechanism that collects the monitoring 218 information for each node by piggybacking telemetry information on 219 the data packets in order to leverage these remaining resources, as 220 presented in Figure 1. If there is no or insufficient remaining 221 space in the transmitted frame, the node cannot add any telemetry 222 information. 224 : COMMUNICATION SLOT OPERATION : 225 : : 226 : +-------+---------------------+---+ +-----+ : 227 : | MAC | Frame |FCS| | ACK | : 228 : | Header| Payload | | | | : 229 ______:__|_______|_____________________|___|_____|_____|__:______ 230 : : 231 : +-------+---+---+---+---------+---+ +-----+ : 232 : | MAC |INT|INT|INT| Frame |FCS| | ACK | : 233 : | Header| | | | Payload | | | | : 234 ______:__|_______|___|___|___|_________|___|_____|_____|__:______ 235 : : 236 : +-------+---+-----------------+---+ +-----+ : 237 : | MAC |INT| Frame |FCS| | ACK | : 238 : | Header| | Payload | | | | : 239 ______:__|_______|___|_________________|___|_____|_____|__:______ 240 : : 242 Figure 1: Capacity-Neutral Network Monitoring. 244 Regarding the cost of the INT operation, there will only be a limited 245 amount of extra energy consumption for the transmitting and receiving 246 nodes in order to transmit/receive extra bytes in the frame. 247 However, it will not use any resource (i.e. slot, bandwidth) reserved 248 for other application or control traffic and it will not have any 249 effect on the network capacity, network behavior and traffic flows. 251 2.2. INT Data Model, Format and Encoding 253 For the insertion of telemetry data in IEEE 802.15.4 MAC frames, the 254 Information Elements (IEs) are used, which are positioned between the 255 end of the MAC Header and the Frame Payload. The IEs are intended to 256 extend 802.15.4 in an interoperable manner and they can be exchanged 257 between one-hop neighbors or forwarded for communication towards 258 further away devices, thus allowing several optimizations 259 [IEEE802154]. The IEs are structured containers as Type, Length, 260 Value fields (TLV) and they have two types, named Header IEs and 261 Payload IEs [IEEE802154]. Header IEs are part of the MAC header and 262 most of their processing is done by the MAC, so IETF protocols should 263 not have any direct effect on that processing. Contrary, Payload IEs 264 are part of the MAC payload and they may be encrypted and 265 authenticated. According to the standard, each frame can include one 266 or more Header or Payload IEs that contain information. 268 IETF has formulated a request towards the IEEE 802.15 Assigned 269 Numbers Authority (ANA) to allocate a registry number and described 270 how IETF IEs should be formatted with their subtypes [RFC8137]. 271 Also, 6TiSCH WG has expressed the need for IEs and a temporary 272 assignment is already provided [RFC8137]. For the design of IEs for 273 INT data, an IETF INT sub-IE type is created by following the IETF IE 274 subtype format. 276 For inserting an INT sub-IE in a MAC frame, the node first must set 277 the "Information Elements Present" field in the 802.15.4 header. 278 Next, Header IEs must be added which will be terminated by a Header 279 Termination 1 IE (2 Bytes). If there is no Header IE, the Header 280 Termination 1 IE must still be added in order to indicate the start 281 of Payload IEs [IEEE802154]. After that, the IETF IE descriptor (2 282 Bytes: type, id, length) must be added, where the IETF IE Group ID is 283 assigned as 0x5 in IEEE 802.15 ANA [ana2019]. Then, the INT sub-IEs 284 must be added including the INT sub-IE descriptors (1 Byte: sub-IE 285 ID) and the relevant INT data. At the end of the payload IEs, a 286 Payload Termination IE (2 Byte) must be added. Considering all these 287 necessary IEs, 7 Bytes of overhead will be added to the frame in 288 order to insert any size of INT data. The resulting frame format 289 after the INT sub-IE insertion is provided in Figure 2. 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Frame Control | Seq. No | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 294 | | 295 ~ Addressing Fields & Aux. Security Header & Header IEs ~ 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Header Termination 1 IE | IETF IE descriptor (0x5) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | INT sub-IE ID | | 301 +-+-+-+-+-+-+-+-+ + 302 ~ INT sub-IE Content ~ 303 | | 304 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | Payload Termination IE | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 308 1 2 3 310 Figure 2: The frame format with inserted INT IE. 312 The following subsections describe the approach and format for 313 embedding telemetry information in the body of an active data packet 314 via IETF INT sub-IEs. 316 2.2.1. INT Sub-IE Format 318 The INT-extended packets in transit must contain telemetry 319 instructions, so the network nodes can process and insert relevant 320 telemetry data according to these instructions when processing the 321 packets. In this regard, based on the requirements and targeted 322 telemetry functionalities for 6TiSCH networks, the INT sub-IE format 323 is designed with its headers and content, as shown in Figure 3. In 324 this format, the Subtype Id represents the IETF IEs subtype 325 identifier as defined in [RFC8137]: IANA_IETF_IE_INT. 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Subtype ID | INT Control | Seq. No (8b) | Bitmap (8b)* | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 ~ INT content ~ 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 335 1 2 3 337 Figure 3: The format of the IETF INT IE Subtype. 339 The INT Header consists of three parts; INT Control header, Sequence 340 Number and Bitmap. The INT Control header will be used to instruct 341 the other nodes about the telemetry modes and functions considered in 342 the particular packet. The detailed format of this field is provided 343 in Figure 4. The sequence number is an 8-bit counter for the INT 344 source, in order to differentiate between different INT data entries 345 from the same node and to detect the end-to-end delivery ratio for 346 data packets with INT entries. Finally, the Bitmap is the optional 347 INT request vector where each bit represents another type of INT 348 data. It is used to inform middle nodes about the relevant telemetry 349 data to add or determine the content of the INT metadata during the 350 decoding. The details of the INT control header is provided in the 351 remainder of this subsection. 353 +-------+-------+-------+--------+--------+-------+-------+-------+ 354 |Bits:0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 355 +-------+-------+-------+--------+--------+-------+-------+-------+ 356 | INT | HBH |Encoding| Bitmap | Over | Loop | Query | 357 | Mode | Mode | Mode | Mode | flow | back | | 358 +-------+---------------+--------+--------+-------+-------+-------+ 360 Figure 4: The format of the INT Control Field. 362 INT Mode (1b): defines the mode of telemetry operation: End-to-End 363 (E2E) or Hop-by-Hop (HBH). In E2E mode, the middle nodes may 364 only forward the INT data without any processing or addition. 365 This mode may be used to monitor end-to-end network performance 366 or notify a central entity about local performance issues. On 367 the other hand, HBH mode may be used to perform per-hop telemetry 368 operation which allows all or a subset of the traversing nodes to 369 add telemetry data if any space is left in the current frame. 371 HBH Mode (2b): defines the behavior of middle nodes in Hop-by-Hop 372 telemetry operations. It must be 0 if End-to-End INT Mode is 373 selected. If Mode 1 (Opportunistic) is selected, then all the 374 nodes will try to add telemetry data in a opportunistic manner. 375 Mode 2 (Probabilistic) will trigger the middle nodes to follow a 376 probabilistic approach for telemetry addition. So the nodes may 377 add telemetry data with a certain probability which can 378 dynamically change based on the last time it added a telemetry, 379 the available space in the forwarded frame and the remaining 380 number of hops. This approach can be beneficial when attempts to 381 add INT data frequently lead to frame size overflows and can 382 enable collecting data from a more diverse set of nodes in the 383 network. Finally, Mode 3 enables middle nodes to decide to add 384 or skip telemetry data in distributed manner. In this mode, the 385 nodes which detect performance drops/issues may add telemetry 386 data to packets as a middle node. This will also avoid the usage 387 of resources for already known/not important data. 389 Encoding Mode (1b): determines the encoding mode that will be used 390 in the INT content. The first option is using the Bitmap mode 391 (Content or Node) which must be followed by telemetry data as 392 byte array. The type of each data will determine the length of 393 that field which will be used to process/decode the data. The 394 second option is using a TLV encoding, where each entry must be 395 encoded with its type, length and value. This will bring 396 flexibility to insert data with variable length and enable nodes 397 to decide on the INT content to insert. In order to reveal the 398 owner of each INT entry, each node must add a Node Id entry 399 before the other telemetry data. In addition, the whole INT 400 content should be processed to understand what kind of telemetry 401 data is added by each node. 403 Bitmap Mode (1b): defines what kind of bitmap will be used: Content 404 Bitmap vs Node Bitmap. If it is Content Bitmap, then that bitmap 405 will apply for each node that adds INT data. Each node must 406 follow the given bitmap and concatenate the relevant entries to 407 the end of the current INT content. The content must include all 408 fields mentioned in the bitmap with correct sizes. So, the 409 bitmap can be used to detect the length of each field during 410 decoding. Alternatively, the Node Bitmap option enables each 411 node to add its own bitmap along with the INT data which will 412 bring independence to nodes for adding different kinds of INT 413 data. During decoding, each node bitmap can be used to detect 414 the length of each field. 416 Overflow (1b): states if any INT entry overflow has happened until 417 that particular hop. If it is set, all of the following hops 418 will know that they won't be able to add any INT entry, and so 419 they can avoid any kind of INT processing. 421 Loopback (1b): may be used by the central entity to achieve downlink 422 INT operation towards an end node. The central entity may insert 423 an INT sub-IE entry with enabled loopback and then middle nodes 424 may add INT data until it arrives at the destination node. After 425 that, that node must forward the collected INT data to the 426 central management entity in any of the following uplink data 427 messages as INT entry. This downlink INT operation will still 428 happen fully in-band. 430 Query (1b): may be used by the central unit to trigger an uplink INT 431 operation with given configuration. When a node receives a 432 packet with attached INT sub-IE including Query bit set, then it 433 should create an INT operation using the received bitmap. This 434 can be used to create a polling-based INT operation triggered by 435 central entity. For instance, there can be the case that the 436 central management entity detects a problem in the network, but 437 there is not sufficient data to troubleshoot or isolate it. Then 438 it can send a query to certain nodes to collect more insight 439 about the problem. 441 2.2.2. Telemetry Data Model 443 Based on a number of monitoring and management scenarios for 6TiSCH 444 Networks, a number of Telemetry Data types are defined. The proposed 445 telemetry data model with limited scope is provided in Table 1 with 446 details about their bitmap id, name, size and description. One can 447 extend the INT Metadata by defining any relevant telemetry data types 448 in order to collect other network status information; such as link 449 quality, number of neighbors, number of incoming/outgoing cells, 450 number of re-transmissions. As it is shown in Table 1, four of the 451 bitmap ids are reserved for any further type definition. 453 +--------+------------------+------+--------------------------------+ 454 | Bitmap | Name | Size | Description | 455 | ID | | | | 456 +--------+------------------+------+--------------------------------+ 457 | 0 | Node ID | 2B | Device identifier (e.g. | 458 | | | | 802.15.4 16bit short address) | 459 | 1 | Receive Channel | 2B | Channel (4b) & Reception or | 460 | | & Timestamp | | Generation time (12b) | 461 | 2 | Utilization | 1B | Transit Delay (4b), Queue | 462 | | indicator | | Depth (4b) | 463 | 3 | RSSI | 1B | Received Signal Strength | 464 | | | | (-127...0...127) | 465 | 4-7 | Reserved | - | Reserved for other telemetry | 466 | | | | data | 467 +--------+------------------+------+--------------------------------+ 469 Table 1: Telemetry Data Model 471 Node Id is one of the fundamental telemetry information types and 472 represents the unique identifier of the node that inserts the 473 telemetry data. In the scope of 6TiSCH networks, IEEE 802.15.4 474 16-bit short addresses can be used. 476 Receive Channel and Timestamp constitute a combined telemetry entry. 477 The first 4 bits of this field represent the channel (0...15) the 478 packet is received on, i.e. one of the available 16 IEEE 802.15.4 479 channels. The Timestamp represents the 12 least significant bits of 480 the time (expressed in ASN which is 5 bytes) at which a packet that 481 needs to be forwarded is received. For the source node, this time 482 represents the time the packet is generated. Since all of the 483 network nodes share the same ASN, the timestamps on each node are 484 inherently synchronized. Assuming a 10ms slot length, 12 bits are 485 enough to represent 40.96 seconds which is sufficient to detect all 486 of the timestamps based on the reception ASN at the border router. 487 The packet generation time can also allow us to understand the age of 488 telemetry data and evaluate its validity. 490 Utilization indicator illustrates the node occupation when the packet 491 traverses that node. The first 4 bits of this field represent the 492 transit delay which is the delay (in slots) between the reception of 493 a frame and its entry to the outgoing queue to be transmitted to the 494 next hop. For the source node, this field will be 0. The remaining 495 4 bits constitute the Queue Depth value which is the number of 496 packets in the outgoing queue at the time. 498 RSSI represents the received signal strength for that frame measured 499 at the particular hop. It must take values between -127 dBm and 127 500 dBm. This value is 0 for the source node and will be ignored during 501 INT processing. 503 2.3. INT Strategies 505 During INT entry initiation and addition process, the nodes can 506 follow various INT strategies via making use of several locally 507 calculated indicators. For instance, the nodes may avoid adding 508 repetitive INT entries by checking the last time a similar INT 509 operation is performed. Additionally, they may continuously process 510 all locally collected telemetry data, detect events/misbehavior and 511 assign an importance/relevance metric to each of them, then trigger 512 an INT operation respectively. 514 2.3.1. Opportunistic Logic 516 In this strategy, each node tries to exploit immediate telemetry 517 insertion opportunities, regardless of any planning or principle, in 518 a greedy manner. So, the nodes will take every chance to insert 519 telemetry in any suitable outgoing packet towards the border router. 521 Although this approach will maximize the total amount of collected 522 telemetry, the source node and the nodes which are closer to the 523 source will have a higher chance to insert telemetry data and 524 subsequent nodes may not even get any chance to add any telemetry. 525 This results in an unfair telemetry distribution and different INT 526 inter-arrival times for different nodes. Therefore, for certain 527 network scenarios, especially for large networks with limited 528 telemetry opportunities, this approach may result in an inadequate 529 network view due to the telemetry information that comes from only a 530 limited part of the network. 532 2.3.2. Probabilistic Logic 534 In this strategy, the nodes are following a probabilistic approach 535 where each node may insert or skip INT entries with certain 536 probabilities which must be dynamically calculated in a distributed 537 manner. This probability can be calculated based on the current 538 frame size (including headers, payload, current INT), the size of a 539 newly to be added INT entry based on Bitmap, and the remaining hop 540 count that can be calculated based on the RPL Dag Rank and RPL link 541 parameters (i.e. MaxRankIncrease, MinRankIncrease, RootRank) 542 [RFC6550]. 544 This approach assures each node with equal opportunity to insert 545 telemetry data, despite their different distances. Although this 546 approach may result in a lower amount of telemetry data, it will 547 result in a better distribution of the telemetry data across nodes 548 and thus a more diverse set of telemetries and a more clear/wider 549 network image. 551 3. Acknowledgements 553 TBD! 555 4. IANA Considerations 557 4.1. IETF IE Subtype INT 559 This document requires a number assignment in the "IEEE Std 802.15.4 560 IETF IE Subtype IDs" registry for IANA_IETF_IE_INT. 562 5. Security Considerations 564 Regarding the security of the INT entries, the INT protocol does not 565 define its own security mechanisms. However, since INT fields are 566 carried as Payload IEs, they can be encrypted and authenticated 567 through link-layer security through CCM* with the same level of 568 security as any other Payload IE. 570 INT mechanism makes use of Payload IEs in order to transfer/collect 571 the telemetry information from network nodes. However, a malicious 572 agent can exploit the contents of the INT Sub-IEs in order to 573 implement a Covert Channel attack and transfer information for other 574 purposes. Based on the INT Sub-IE Control Fields and INT request 575 vector (Bitmap), a validation process can be applied at border router 576 to detect and prevent possible covert/hidden channels. 578 Since the content of the INT sub-IE is modified at each hop, INT 579 mechanism does not guarantee the preservation of the original 580 telemetry information, thus creates an opportunity for a modification 581 attack. 583 6. References 585 6.1. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, 589 DOI 10.17487/RFC2119, March 1997, 590 . 592 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 593 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 594 May 2017, . 596 6.2. Informative References 598 [I-D.ietf-6tisch-architecture] 599 Thubert, P., "An Architecture for IPv6 over the TSCH mode 600 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work 601 in progress), October 2019. 603 [I-D.ietf-6tisch-coap] 604 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 605 Interaction using CoAP", draft-ietf-6tisch-coap-03 (work 606 in progress), March 2015. 608 [I-D.ietf-core-comi] 609 Veillette, M., Stok, P., Pelov, A., Bierman, A., and I. 610 Petrov, "CoAP Management Interface", draft-ietf-core- 611 comi-08 (work in progress), September 2019. 613 [I-D.ietf-ippm-ioam-data] 614 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 615 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 616 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 617 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 618 ietf-ippm-ioam-data-08 (work in progress), October 2019. 620 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 621 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 622 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 623 Low-Power and Lossy Networks", RFC 6550, 624 DOI 10.17487/RFC6550, March 2012, 625 . 627 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 628 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 629 Internet of Things (IoT): Problem Statement", RFC 7554, 630 DOI 10.17487/RFC7554, May 2015, 631 . 633 [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 634 Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 635 2017, . 637 6.3. External Informative References 639 [ana2019] Alfvin, R., "802.15.4 ANA database", January 2019. 641 [IEEE802154] 642 IEEE standard for Information Technology, "IEEE Std. 643 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 644 and Physical Layer (PHY) Specifications for Low-Rate 645 Wireless Personal Area Networks", October 2019. 647 [IEEE802154e] 648 IEEE standard for Information Technology, "IEEE std. 649 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 650 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 651 2012. 653 Authors' Addresses 655 Abdulkadir Karaagac 656 Ghent University - imec 657 iGent Tower 658 Technologiepark-Zwijnaarde 126 659 Gent B-9052 660 Belgium 662 Email: abdulkadir.karaagac@gmail.com 664 Jeroen Hoebeke 665 Ghent University - imec 666 iGent Tower 667 Technologiepark-Zwijnaarde 126 668 Gent B-9052 669 Belgium 671 Email: jeroen.hoebeke@ugent.be