idnits 2.17.1 draft-ietf-6tisch-6top-interface-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 131 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the TrackID is set to (0,0), the cell can be used by the best-effort QoS configuration or as a Shared cell. If the TrackID is not set to (0,0), i.e., the cell belongs to a specific track, the cell MUST not be set as Shared cell. -- The document date (October 27, 2014) is 3462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 1492, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 1498, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 1504, but not defined == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 1469, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-minimal' is defined on line 1475, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-coap' is defined on line 1485, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-02 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-03 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-02 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-03 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-01 == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-01 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: April 30, 2015 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 October 27, 2014 10 6TiSCH Operation Sublayer (6top) Interface 11 draft-ietf-6tisch-6top-interface-02 13 Abstract 15 This document defines a generic data model for the 6TiSCH Operation 16 Sublayer (6top), using the YANG data modeling language. This data 17 model can be used for future network management solutions defined by 18 the 6TiSCH working group. This document also defines a list of 19 commands for the internal use of the 6top sublayer and or to be used 20 by implementers as an API guideline or basic specification. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 3 59 3.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 6 61 3.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 6 63 4. Generic Data Model . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. YANG model of the 6top MIB . . . . . . . . . . . . . . . 8 65 4.2. YANG model of the IEEE802.15.4 PIB . . . . . . . . . . . 24 66 5. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 29 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 33 69 6.2. Informative References . . . . . . . . . . . . . . . . . 33 70 6.3. External Informative References . . . . . . . . . . . . . 34 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 73 1. Introduction 75 This document defines a generic data model for the 6TiSCH Operation 76 Sublayer (6top), using the YANG data modeling language defined in 77 [RFC6020]. This data model can be used for future network management 78 solutions defined by the 6TiSCH working group. This document also 79 defines a list commands internal to the 6top sublayer. This data 80 model gives access to metrics (e.g. cell state), TSCH configuration 81 and control procedures, and support for the different scheduling 82 mechanisms described in [I-D.ietf-6tisch-architecture]. The 6top 83 sublayer addresses the set of management information and 84 functionalities described in [I-D.ietf-6tisch-tsch]. 86 For example, network formation in a TSCH network is handled by the 87 use of Enhanced Beacons (EB). EBs include information for joining 88 nodes to be able to synchronize and set up an initial network 89 topology. However, [IEEE802154e] does not specify how the period of 90 EBs is configured, nor the rules for a node to select a particular 91 node to join. 6top offers a set of commands so control mechanisms can 92 be introduced on top of TSCH to configure nodes to join a specific 93 node and obtain a unique 16-bit identifier from the network. Once a 94 network is formed, 6top maintains the network's health, allowing for 95 nodes to stay synchronized. It supplies mechanisms to manage each 96 node's time source neighbor and configure the EB interval. Network 97 layers running on top of 6top take advantage of the TSCH MAC layer 98 information so routing metrics, topological information, energy 99 consumption and latency requirements can be adjusted to TSCH, and 100 adapted to application requirements. 102 TSCH requires a mechanism to manage its schedule; 6top provides a set 103 of commands for upper layers to set up specific schedules, either 104 explicitly by detailing specific cell information, or by allowing 105 6top to establish a schedule given a bandwidth or latency 106 requirement. 6top is designed to enable decentralized, centralized or 107 hybrid scheduling solutions. 6top enables internal TSCH queuing 108 configuration, size of buffers, packet priorities, transmission 109 failure behavior, and defines mechanisms to encrypt and authenticate 110 MAC slotframes. 112 As described in [morell04label], due to the slotted nature of a TSCH 113 network, it is possible to use a label switched architecture on top 114 of TSCH cells. As a cell belongs to a specific track, a label header 115 is not needed at each packet; the input cell (or bundle) and the 116 output cell (or bundle) uniquely identify the data flow. The 6top 117 sublayer provides operations to manage the cell mappings. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. 6TiSCH Operation Sublayer (6top) Overview 127 6top is a sublayer which is the next-higher layer for TSCH 128 (Figure 1), as detailed in [I-D.ietf-6tisch-architecture]. 6top 129 offers both management and data interfaces to an upper layer, and 130 includes monitoring and statistics collection, both of which are 131 configurable through its management interface. The detail of 6top- 132 sublayer is described in [I-D.wang-6tisch-6top-sublayer] 133 Protocol Stack 135 +-----------------------------------+ 136 | PCEP | CoAP | | 6LoWPAN | | 137 | PCC | DTLS | PANA | ND |RPL | 138 +------------------------------------------+ 139 | TCP | UDP | ICMP | RSVP | 140 +------------------------------------------+ 141 | IPv6 | 142 +------------------------------------------+ 143 | 6LoWPAN HC | 144 +------------------------------------------+ 145 | 6top | 146 +------------------------------------------+ 147 | IEEE802.15.4e TSCH | 148 +------------------------------------------+ 149 | IEEE802.15.4 | 150 +------------------------------------------+ 152 Figure 1 154 6top distinguishes between hard cells and soft cells. It therefore 155 requires an extra flag to all cells in the TSCH schedule, as detailed 156 in Section 3.1. 158 When a higher layer gives 6top a 6LoWPAN packet for transmission, 159 6top maps it to the appropriate outgoing priority-based queue, as 160 detailed in Section 3.2. 162 Section 4 contains a generic data model for the 6top sublayer, 163 described in the YANG data modeling language. 165 The commands of the management and data interfaces are listed in 166 Section 5. This set of commands is designed to support 167 decentralized, centralized and hybrid scheduling solutions. 169 3.1. Cell Model 171 [IEEE802154e] defines a set of options attached to each cell. A cell 172 can be a Transmit cell, a Receive cell, a Shared cell or a 173 Timekeeping cell. These options are not exclusive, as a cell can be 174 qualified with more than one of them. The MLME-SET-LINK.request 175 command defined in [IEEE802154e] uses a linkOptions bitmap to specify 176 the options of a cell. Acceptable values are: 178 b0 = Transmit 180 b1 = Receive 181 b2 = Shared 183 b3 = Timekeeping 185 b4-b7 = Reserved 187 Only Transmit cells can also be marked as Shared cells. When the 188 shared bit is set, a back-off procedure is applied to handle 189 collisions. Shared behavior does not apply to Receive cells. 191 6top allows an upper layer to schedule a cell at a specific 192 slotOffset and channelOffset, in a specific slotframe. 194 In addition, 6top allows an upper layer to schedule a certain amount 195 of bandwidth to a neighbor, without having to specify the exact 196 slotOffset(s) and channelOffset(s). Once bandwidth is reserved, 6top 197 is in charge of ensuring that this requirement is continuously 198 satisfied. 6top dynamically reallocates cells if needed, and over- 199 provisions if required. 201 6top allows an upper layer to associate a cell with a specific track 202 by using a TrackID. A TrackID is a tuple 203 (TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of 204 the node which initializes the process of creating the track, i.e., 205 the owner of the track; and InstanceID is an instance identifier 206 given by the owner of the track. InstanceID comes from upper layer; 207 InstanceID could for example be the local instance ID defined in RPL. 209 If the TrackID is set to (0,0), the cell can be used by the best- 210 effort QoS configuration or as a Shared cell. If the TrackID is not 211 set to (0,0), i.e., the cell belongs to a specific track, the cell 212 MUST not be set as Shared cell. 214 6top allows an upper layer to ask a node to manage a portion of a 215 slotframe, which is named as chunk. Chunks can be delegated 216 explicitly by the PCE to a node, or claimed automatically by any node 217 that participates to the distributed cell scheduling process. The 218 resource in a chunk can be appropriated by the node, i.e. the owner 219 of the chunk. 221 Given this mechanism, 6top defines hard cells (which have been 222 requested specifically) and soft cells (which can be reallocated 223 dynamically). The hard/soft flag is introduced by the 6top sublayer 224 named as CellType, 0: soft cell, 1: hard cell. This option is 225 mandatory; all cells are either hard or soft. 227 3.1.1. hard cells 229 A hard cell is a cell that cannot be dynamically reallocated by 6top. 230 The CellType MUST be set to 1. The cell is installed by 6top given 231 specific slotframe ID, slotOffset, and channelOffset. 233 3.1.2. soft cells 235 A soft cell is a cell that can be reallocated by 6top dynamically. 236 The CellType MUST be set to 0. This cell is installed by 6top given 237 a specific bandwidth requirement. Soft cells are installed through 238 the soft cell negotiation procedure described in 239 [I-D.wang-6tisch-6top-sublayer]. 241 3.2. Data Transfer Model 243 Once a TSCH schedule is established, 6top is responsible for feeding 244 the data from the upper layer into TSCH. This section describes how 245 6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds 246 it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the 247 properties associated with a packet/fragment from the upper layer 248 includes the next hop neighbor (DestAddr) and expected sending 249 priority of the packet (Priority), and/or TrackID(s). The output to 250 TSCH is the fragment corresponding to the next active cell in the 251 TSCH schedule. 253 6top Data Transfer Model 255 | 256 | (DestAddr, Priority, Fragment) 257 | 258 +---------------------------------------+ 259 | I-MUX | 260 +---------------------------------------+ 261 | | | | .... | 262 | | | | | 263 +---+ +---+ +---+ +---+ +---+ 264 | | | | | | | | | | 265 |Q1 | |Q2 | |Q3 | |Q4 | |Qn | 266 | | | | | | | | | | 267 +---+ +---+ +---+ +---+ +---+ 268 | | | | | 269 | | | | | 270 +---------------------------------------+ 271 | MUX | 272 +---------------------------------------+ 273 | 274 | 275 +---+ 276 |PDU| 277 +---+ 278 | 279 | TSCH MAC-payload 280 | 282 Figure 2 284 In Figure 2, Qi represents a queue, which is either broadcast or 285 unicast, and has an assigned priority. The number of queues is 286 configurable. The relationship between queues and tracks is 287 configurable. For example, for a given queue, only one specific 288 track can be used, all of the tracks can be used, or a subset of the 289 tracks can be used. 291 When 6top receives a packet to transmit through a Send.data command 292 (Section 5), the I-MUX module selects a queue in which to insert it. 293 If the packet's destination address is a unicast (resp. broadcast) 294 address, it will be inserted into a unicast (resp. broadcast) queue. 296 The MUX module is invoked at each scheduled transmit cell by TSCH. 297 When invoked, the MUX module goes through the queues, looking for the 298 best matching frame to send. If it finds a frame, it hands it over 299 to TSCH for transmission. If the next active cell is a broadcast 300 cell, it selects a fragment only from broadcast queues. 302 How the MUX module selects the best frame is configurable. The 303 following rules are a typical example: 305 The frame's layer 2 destination address MUST match the neighbor 306 address associated with the transmit cell. 308 If the transmit cell is associated with a specific track, the 309 frames in the queue corresponding to the TrackID have the 310 highest priority. 312 If the transmit cell is not associated with a specific track, 313 i.e., TrackID=(0,0), frames from a queue with a higher priority 314 MUST be sent before frames from a queue with a lower priority. 316 Further rules can be configured to satisfy specific QoS requirements. 318 4. Generic Data Model 320 This section presents the generic data model of the 6top sublayer, 321 using the YANG data modeling langage. This data model can be used 322 for future network management solutions defined by the 6TiSCH working 323 group. The data model consists of the MIB (management information 324 base) defined in 6top, and part of the PIB (personal area network 325 information base) defined in [IEEE802154e] and [IEEE802154]. 327 4.1. YANG model of the 6top MIB 329 list CellList { 330 key "CellID"; 331 description 332 "List of scheduled cells of a node with all of its neighbors, 333 in all of its slotframes."; 335 leaf CellID { 336 type uint16; 337 description 338 "Equal to Linkhandle in the linkTable of TSCH"; 339 reference 340 "IEEE802154e"; 341 } 342 leaf SlotframeID { 343 type uint8; 344 description 345 "SlotframeID, one in SlotframeList, indicates the slotframe 346 the cell belongs to."; 347 reference 348 "IEEE802154e"; 349 } 350 leaf SlotOffset { 351 type uint16; 352 description 353 "Defined in IEEE802154e."; 354 reference 355 "IEEE802154e"; 356 } 357 leaf ChannelOffset { 358 type uint16; 359 description 360 "Defined in IEEE802154e."; 361 reference 362 "IEEE802154e"; 363 } 364 leaf LinkOption { 365 type bits { 366 bit Transmit { 367 position 0; 368 } 369 bit Receive { 370 position 1; 371 } 372 bit Share { 373 position 2; 374 } 375 bit Timekeeping { 376 position 3; 377 } 378 bit Reserved1 { 379 position 4; 380 } 381 bit Reserved2 { 382 position 5; 383 } 384 bit Reserved3 { 385 position 6; 386 } 387 bit Reserved4 { 388 position 7; 389 } 390 } 391 description 392 "Defined in IEEE802154e."; 393 reference 394 "IEEE802154e"; 395 } 396 leaf LinkType { 397 type enumeration { 398 enum NORMAL; 399 enum ADVERTISING; 400 } 401 description 402 "Defined in IEEE802154"; 403 reference 404 "IEEE802154"; 405 } 406 leaf CellType { 407 type enumeration { 408 enum SOFT; 409 enum HARD; 410 } 411 description 412 "Defined in 6top"; 413 } 414 leaf TargetNodeAddress { 415 type uint64; 416 description 417 "Defined by 6top, but being constrained by TSCH 418 macNodeAddress size, 2-octets. If using TSCH as MAC, 419 higher 6-octets should be filled with 0, and lowest 420 2-octets is neighbor address"; 421 } 422 leaf TrackID { 423 type uint16; 424 description 425 "A TrackID is one in the TrackList, pointing to a tuple 426 (TrackOwnerAddr,InstanceID) , where TrackOwnerAddr is the 427 address of the node which initializes the process of 428 creating the track, i.e., the owner of the track; and 429 InstanceID is an instance identifier given by the owner of 430 the track."; 431 } 432 container Statistic { 433 leaf NumOfStatistic { 434 type uint8; 435 description 436 "Number of statistics collected on the cell"; 437 } 438 list MeasureList { 439 key "StatisticsMetricsID"; 440 leaf StatisticsMetricsID{ 441 type uint16; 442 description 443 "An index of StatisticsMetricList, which defines how 444 to collect data and get the statistics value"; 445 } 446 leaf StatisticsValue{ 447 type uint16; 448 config false; 449 description 450 "updated by 6top according to the statistics method 451 specified by StatisticsMetricsID"; 452 } 453 } 454 } 455 } 457 list SlotframeList { 458 key "SlotframeID"; 459 description 460 "List of all of the slotframes used by the node."; 462 leaf SlotframeID { 463 type uint8; 464 description 465 "Equal to SlotframeHandle defined in TSCH"; 466 reference 467 "IEEE802154e"; 468 } 469 leaf NumOfSlots { 470 type uint16; 471 description 472 "indicates how many timeslots in the slotframe"; 473 } 474 } 476 list MonitoringStatusList { 477 key "MonitoringStatusID"; 478 description 479 "List of the monitoring configuration and results per 480 slotframe and neighbor. Basically, it is used for Monitoring 481 Function of 6top to re-allocate softcells or initial the 482 softcell negotiation process to increase/decrease number of 483 softcells. Upper layer can use it also."; 485 leaf MonitoringStatusID { 486 type uint16; 487 } 488 leaf SlotframeID { 489 type uint8; 490 description 491 "SlotframeID, one in SlotframeList, indicates the slotframe 492 being monitored"; 493 reference 494 "IEEE802154e"; 495 } 496 leaf TargetNodeAddress { 497 type uint64; 498 description 499 "Defined by 6top, but being constrained by TSCH 500 macNodeAddress size, 2-octets. If using TSCH as MAC, 501 higher 6-octets should be filled with 0, and lowest 502 2-octets is neighbor address. It indicates the communication 503 link being mornitored"; 504 } 505 leaf EnforcePolicy { 506 type enumeration { 507 enum DISABLE; 508 enum BESTEFFORT; 509 enum STRICT; 510 enum OVERPROVISION; 511 } 512 description 513 "Currently enforced QoS policy. DISABLE-no QoS; 514 BESTEFFORT- best effort policy is used; STRICT- Strict 515 Priority Queueing; OVERPROVISION- cell overprovision"; 516 } 517 leaf AllocatedHard { 518 type uint16; 519 config false; 520 description 521 "Number of hard cells allocated"; 522 } 523 leaf AllocatedSoft { 524 type uint16; 525 config false; 526 description 527 "Number of soft cells allocated"; 528 } 529 leaf OverProvision { 530 type uint16; 531 config false; 532 description 533 "Overprovisioned cells. 0 if EnforcePolicy is 534 DISABLE"; 535 } 536 leaf QoS { 537 type uint16; 538 config false; 539 description 540 "Current QoS including overprovisioned cells, i.e. the 541 bandwidth obtained including the overprovisioned cells."; 543 } 544 leaf NQoS { 545 type uint16; 546 config false; 547 description 548 "Real QoS without over provisioned cells, i.e. the actual 549 bandwidth without taking into account the overprovisioned 550 cells."; 551 } 552 } 554 list StatisticsMetricsList { 555 key "StatisticsMetricsID"; 556 description 557 "List of Statistics Metrics used in the node. Statistics can be set and queried."; 559 leaf StatisticsMetricsID { 560 type uint16; 561 } 562 leaf SlotframeID { 563 type uint16; 564 description 565 "SlotframeID, one in SlotframeList, specifies the slotframe to 566 which the statistics metrics applies to. If empty, applies to 567 all slotframes"; 568 reference 569 "IEEE802154e"; 570 } 571 leaf SlotOffset { 572 type uint16; 573 description 574 "Specific slotOffset to which the statistics metrics applies 575 to. If empty, applies to all timeslots"; 576 reference 577 "IEEE802154e"; 578 } 579 leaf ChannelOffset { 580 type uint8; 581 description 582 "Specific channelOffset to which the statistics metrics applies 583 to. If empty, applies to all channels"; 584 reference 585 "IEEE802154e"; 586 } 587 leaf TargetNodeAddress { 588 type uint64; 589 description 590 "Specific neighbor nodes to which the statistics metrics 591 applies to. If empty, applies to all neighbor nodes."; 592 } 593 leaf Metrics { 594 type enumeration { 595 enum macCounterOctets 596 enum macRetryCount 597 enum macMultipleRetryCount 598 enum macTXFailCount 599 enum macTXSuccessCount 600 enum macFCSErrorCount 601 enum macSecurityFailure 602 enum macDuplicateFrameCount 603 enum macRXSuccessCount 604 enum macNACKcount 605 enum PDR; 606 enum ETX; 607 enum RSSI; 608 enum LQI; 609 } 610 description 611 "The metric to be monitored. Include those provided by underlying IEEE 802.15.4e TSCH -- see table 4i (2012). PDR,ETX,RSSI,LQI are maintained by 6top. "; 612 } 613 leaf Window { 614 type uint16; 615 description 616 "measurement period, in Number of the slotframes. If not specified the metrics are updated continuously in time. If a period is specified the metric values are given for the specified time-window"; 617 } 618 leaf Enable { 619 type enumeration { 620 enum DISABLE; 621 enum ENABLE; 622 } 623 description 624 "indicates the StatisticsMetric is active or not"; 625 } 626 } 627 list EBList { 628 key "EbID"; 629 description 630 "List of information related with the EBs used by the node"; 632 leaf EbID { 633 type uint8; 634 } 636 leaf CellID { 637 type uint16; 638 description 639 "CellID, one in CellList, indicates the cell used to send 640 EB"; 641 } 642 leaf SlotframeId{ 643 type uint8; 644 description 645 "SlotframeID, one in SlotframeList, indicates the 646 slotframe to which the EB is send"; 647 } 648 leaf Period { 649 type uint16; 650 description 651 "The EBs period, in seconds, indicates the interval between 652 two EB sends"; 653 } 654 leaf Expiration { 655 type enumeration { 656 enum NEVERSTOP; 657 enum EXPIRATION; 658 } 659 description 660 "NEVERSTOP- the period of the EB never stops; EXPIRATION- 661 when the Period arrives, the EB will stop."; 662 } 663 leaf Priority { 664 type uint8; 665 description 666 "The joining priority model that will be used for 667 advertisements. Joining priority MAY be for example 668 SAME_AS_PARENT, RANDOM, BEST_PARENT+1 or 669 DAGRANK(rank)."; 670 } 671 } 673 container TimeSource { 674 description 675 "specify the timesource selection policy and some relative 676 statistics."; 678 leaf policy { 679 type enumeration { 680 enum ALLPARENT; 681 enum BESTCONNECTED; 682 enum LOWESTJOINPRIORITY; 683 } 684 description 685 "indicates the policy to choose timesource. ALLPARENT- choose 686 from all parents; BESTCONNECTED- choose the best-connected 687 node; LOWESTJOINPRIORITY- choose the node with lowest priority 688 in its EB."; 689 } 690 leaf TargetNodeAddress { 691 type uint64; 692 description 693 "Address of the time source neighbor"; 694 } 695 leaf MinTimeCorrection { 696 type uint16; 697 config false; 698 description 699 "measured in microsecond"; 700 } 701 leaf MaxTimeCorrection { 702 type uint16; 703 config false; 704 description 705 "measured in microsecond"; 706 } 707 leaf AveTimeCorrection { 708 type uint16; 709 config false; 710 description 711 "measured and computed in microsecond"; 712 } 713 } 714 typedef asntype { 715 description 716 "The type to store ASN. String of 5 bytes"; 717 type string { 718 length "0..5"; 719 } 720 } 722 list NeighborList { 723 key "TargetNodeAddress"; 724 description 725 "statistics per communication link."; 727 leaf TargetNodeAddress { 728 type uint64; 729 description 730 "Address of the time source neighbor"; 731 } 732 leaf RSSI { 733 type uint8; 734 config false; 735 description 736 "The received signal strength"; 737 } 738 leaf LinkQuality { 739 type uint8; 740 config false; 741 description 742 "The LQI metric"; 743 } 744 leaf ASN { 745 type asntype; 746 config false; 747 description 748 "The 5 ASN bytes, indicates the most recent timeslot when a 749 packet from the neighbor was received"; 750 } 751 } 753 list QueueList { 754 key "QueueId"; 755 description 756 "List of Queues, including configuration and statistics."; 758 leaf QueueId { 759 type uint8; 760 description 761 "Queue Identifier"; 763 } 764 leaf TxqLength { 765 type uint8; 766 description 767 "The TX queue length in number of packets"; 768 } 769 leaf RxqLength { 770 type uint8; 771 description 772 "The RX queue length in number of packets"; 773 } 774 leaf NumrTx { 775 type uint8; 776 description 777 "Number of allowed retransmissions."; 778 } 779 leaf Age { 780 type uint16; 781 description 782 "In seconds. Discard packet according to its age 783 on the queue. 0 if no discards are allowed."; 784 } 785 leaf RTXbackoff { 786 type uint8; 787 description 788 "retransmission backoff in number of slotframes. 789 0 if next available timeslot wants to be used."; 790 } 791 leaf StatsWindow { 792 type uint16; 793 description 794 "In second, window of time used to compute stats."; 795 } 796 leaf QueuePriority { 797 type uint8; 798 description 799 "The priority for this queue."; 800 } 801 list TrackIds { 802 key "TrackID"; 803 leaf TrackID{ 804 type uint16; 805 description 806 "The TrackID, one in TrackList, indicates the Track is 807 associated with the Queue."; 808 } 809 } 810 leaf MinLenTXQueue { 811 type uint8; 812 config false; 813 description 814 "Statistics, lowest TX queue length registered in the window."; 815 } 816 leaf MaxLenTXQueue { 817 type uint8; 818 config false; 819 description 820 "Statistics, largest TX queue length registered in the 821 window."; 822 } 823 leaf AvgLenTXQueue { 824 type uint8; 825 config false; 826 description 827 "Statistics, avg TX queue length registered in the window."; 828 } 829 leaf MinLenRXQueue { 830 type uint8; 831 config false; 832 description 833 "Statistics, lowest RX queue length registered in the window."; 834 } 835 leaf MaxLenRXQueue { 836 type uint8; 837 config false; 838 description 839 "Statistics, largest RX queue len registered in the window."; 840 } 841 leaf AvgLenRXQueue { 842 type uint8; 843 config false; 844 description 845 "Statistics, avg RX queue length registered in the window."; 846 } 847 leaf MinRetransmissions { 848 type uint8; 849 config false; 850 description 851 "Statistics, lowest number of retransmissions registered in 852 the window."; 853 } 854 leaf MaxRetransmissions { 855 type uint8; 856 config false; 857 description 858 "Statistics, largest number of retransmissions registered 859 in the window."; 860 } 861 leaf AvgRetransmissions { 862 type uint8; 863 config false; 864 description 865 "Statistics, average number of retransmissions registered 866 in the window."; 867 } 868 leaf MinPacketAge { 869 type uint16; 870 config false; 871 description 872 "Statistics, in seconds, minimum time a packet stayed in 873 the queue during the observed window."; 874 } 875 leaf MaxPacketAge { 876 type uint16; 877 config false; 878 description 879 "Statistics, in seconds, maximum time a packet stayed 880 in the queue during the observed window."; 881 } 882 leaf AvgPacketAge { 883 type uint16; 884 config false; 885 description 886 "Statistics, in seconds, average time a packet stayed in 887 the queue during the observed window."; 888 } 889 leaf MinBackoff { 890 type uint8; 891 config false; 892 description 893 "Statistics, in number of slotframes, minimum Backoff 894 for a packet in the queue during the observed window."; 895 } 896 leaf MaxBackoff { 897 type uint8; 898 config false; 899 description 900 "Statistics, in number of slotframes, maximum Backoff 901 for a packet in the queue during the observed window."; 902 } 903 leaf AvgBackoff { 904 type uint8; 905 config false; 906 description 907 "Statistics, in number of slotframes, average Backoff 908 for a packet in the queue during the observed window."; 909 } 910 } 912 list LabelSwitchList { 913 key "LabelSwitchID"; 914 description 915 "List of Label switch' configuration on the node"; 917 leaf LabelSwitchID { 918 type uint16; 919 } 920 list InputCellIds { 921 key "CellID"; 922 leaf CellID{ 923 type uint16; 924 description 925 "The CellID, indicates the Rx cell on which the packet will 926 come in."; 927 } 928 } 929 list OutputCellIds { 930 key "CellID"; 931 leaf CellID{ 932 type uint16; 933 description 934 "The CellID, indicates the Tx cell on which the received 935 packet should be sent out."; 936 } 937 } 938 leaf LoadBalancingPolicy { 939 type enumeration { 940 enum ROUNDROBIN; 941 enum OTHER; 942 } 943 description 944 "The load-balancing policy. ROUNDROBIN- Round robin algorithm 945 is used for forwarding scheduling."; 946 } 947 } 948 list TrackList { 949 key "TrackId"; 950 description 951 "List of the tracks through the node."; 953 leaf TrackId { 954 type uint16; 955 description 956 "Track Identifier, named locally. It is used to refer to the 957 tuple (TrackOwnerAddr, InstanceID)."; 958 } 959 leaf TrackOwnerAddr { 960 type uint64; 961 description 962 "The address of the node which initializes the process of 963 creating the track, i.e., the owner of the track;"; 964 } 965 leaf InstanceID { 966 type uint16; 967 description 968 "InstanceID is an instance identifier given by the owner of 969 the track. InstanceID comes from upper layer; InstanceID could 970 for example be the local instance ID defined in RPL."; 971 } 972 } 973 list ChunkList { 974 key "ChunkId"; 975 description 976 "List of the chunks assigned to the node."; 978 leaf ChunkId{ 979 type uint16; 980 description 981 "The identifier of a chunk"; 982 } 983 leaf SlotframeId{ 984 type uint8; 985 description 986 "SlotframeID, one in SlotframeList, indicates the 987 slotframe to which the chunk belongs"; 988 } 989 leaf SlotBase { 990 type uint16; 991 description 992 "the base slotOffset of the chunk in the slotframe"; 993 } 994 leaf SlotStep { 995 type uint8; 996 description 997 "the slot incremental of the chunk"; 998 } 999 leaf ChannelBase { 1000 type uint8; 1001 description 1002 "the base channelOffset of the chunk"; 1003 } 1004 leaf ChannelStep { 1005 type uint8; 1006 description 1007 "the channel incremental of the chunk"; 1008 } 1009 leaf ChunkSize { 1010 type uint8; 1011 description 1012 "the number of cells in the chunk. The chunk is the set 1013 of (slotOffset(i), channelOffset(i)), 1014 i=0..Chunksize-1, 1015 slotOffset(i)= (slotBase + i * slotStep) % slotframeLen, 1016 channelOffset(i) = (channelBase + i * channelStep) % 16"; 1017 } 1018 } 1019 list ChunkCellList { 1020 key "SlotOffset ChannelOffset"; 1021 description 1022 "List of all of the cells assigned to the node via the 1023 assignment of chunks."; 1025 leaf SlotOffset{ 1026 type uint16; 1027 description 1028 "The slotoffset of a cell which belongs to a Chunk"; 1029 } 1030 leaf ChannelOffset{ 1031 type uint16; 1032 description 1033 "The channeloffset of a cell which belongs to a chunk."; 1034 } 1035 leaf ChunkId { 1036 type uint16; 1037 description 1038 "Identifier of the chunk the cell belongs to"; 1039 } 1040 leaf CellID{ 1041 type uint16; 1042 description 1043 "Initial value of CellID is 0xFFFF. When the cell is 1044 scheduled, the value of CellID is same as that in 1045 CellList"; 1046 } 1047 leaf ChunkCellStatus { 1048 type enumeration { 1049 enum UNSCHEDULED; 1050 enum SCHEDULED; 1051 } 1052 } 1053 } 1055 4.2. YANG model of the IEEE802.15.4 PIB 1057 This section describes the YANG model of the part of PIB 1058 ([IEEE802154] and [IEEE802154e]) used by 6top, such as security 1059 related attributes, TSCH related attributes. This part of data will 1060 be accessed through the MLME-GET and MLME-SET primitive [IEEE802154] 1061 directly, instead of using 6top comannds. 1063 TODO the security related attributes will be added after 6TiSCH WG 1064 has consensus on the security scheme of 6top 1066 container TSCHSpecificPIBAttributes { 1067 description 1068 "TSCH specific MAC PIB attributes."; 1069 reference 1070 "table 52b in IEEE802.15.4e-2012."; 1072 leaf macMinBE { 1073 type uint8; 1074 description 1075 "defined in Table 52b of IEEE802.15.4e-2012, 1076 The minimum value of the backoff exponent (BE) in the 1077 CSMA-CA algorithm or the TSCH-CA algorithm. default: 1078 3-CSMA-CA, 1-TSCH-CA"; 1079 } 1080 leaf macMaxBE { 1081 type uint8; 1082 description 1083 "defined in Table 52b of IEEE802.15.4e-2012, 1084 The maximum value of the backoff exponent (BE) in the 1085 CSMA-CA algorithm or the TSCH-CA algorithm. default: 1086 5-CSMA-CA, 7-TSCH-CA"; 1087 } 1088 leaf macDisconnectTime { 1089 type uint16; 1090 description 1091 "defined in Table 52b of IEEE802.15.4e-2012, 1092 Time (in Timeslots) to send out Disassociate frames 1093 before disconnecting, default: 0x00ff"; 1094 } 1095 leaf macJoinPriority { 1096 type uint8; 1097 description 1098 "defined in Table 52b of IEEE802.15.4e-2012, 1099 The lowest join priority from the TSCH Synchronization 1100 IE in an Enhanced beacon, default: 1"; 1101 } 1102 leaf macASN { 1103 type asntype; 1104 description 1105 "defined in Table 52b of IEEE802.15.4e-2012, 1106 The Absolute Slot Number, i.e., the number of slots 1107 that ha elapsed since the start of the network."; 1108 } 1109 leaf macNoHLBuffers { 1110 type enumeration { 1111 enum TRUE; 1112 enum FALSE; 1113 } 1114 description 1115 "defined in Table 52b of IEEE802.15.4e-2012, 1116 If the value is TRUE, the higher layer receiving the 1117 frame payload cannot buffer it, and the device should 1118 acknowledge frames with a NACK; If FALSE, the higher 1119 layer can accept the frame payload. default: FALSE"; 1120 } 1121 } 1123 list TSCHmacTimeslotTemplate { 1124 key "macTimeslotTemplateId"; 1125 description 1126 "List of all timeslot templates used in the node."; 1127 reference 1128 "table 52e in IEEE802.15.4e-2012."; 1130 leaf macTimeslotTemplateId { 1131 type uint8; 1132 description 1133 "defined in Table 52e of IEEE802.15.4e-2012. 1134 Identifier of Timeslot Template. default: 0"; 1135 } 1136 leaf macTsCCAOffset { 1137 type uint16; 1138 description 1139 "The time between the beginning of timeslot and start 1140 of CCA operation, in microsecond. default: 1800"; 1141 } 1142 leaf macTsCCA { 1143 type uint16; 1144 description 1145 "Duration of CCA, in microsecond. default: 128"; 1146 } 1147 leaf macTsTxOffset { 1148 type uint16; 1149 description 1150 "The time between the beginning of the timeslot and 1151 the start of frame transmission, in microsecond. 1152 default: 2120"; 1153 } 1154 leaf macTsRxOffset { 1155 type uint16; 1156 description 1157 "Beginning of the timeslot to when the receiver shall 1158 be listening, in microsecond. default: 1120"; 1159 } 1160 leaf macTsRxAckDelay { 1161 type uint16; 1162 description 1163 "End of frame to when the transmitter shall listen for 1164 Acknowledgment, in microsecond. default: 800"; 1165 } 1166 leaf macTsTxAckDelay { 1167 type uint16; 1168 description 1169 "End of frame to start of Acknowledgment, in 1170 microsecond. 1171 default: 1000"; 1172 } 1173 leaf macTsRxWait { 1174 type uint16; 1175 description 1176 "The time to wait for start of frame, in microsecond. 1177 default: 2200"; 1178 } 1179 leaf macTsAckWait { 1180 type uint16; 1181 description 1182 "The minimum time to wait for start of an 1183 Acknowledgment, in microsecond. default: 400"; 1184 } 1185 leaf macTsRxTx { 1186 type uint16; 1187 description 1188 "Transmit to Receive turnaround, in microsecond. 1189 default: 192"; 1190 } 1191 leaf macTsMaxAck { 1192 type uint16; 1193 description 1194 "Transmission time to send Acknowledgment,in 1195 microsecond. default: 2400"; 1196 } 1197 leaf macTsMaxTx { 1198 type uint16; 1199 description 1200 "Transmission time to send the maximum length frame, 1201 in microsecond. default: 4256"; 1202 } 1203 leaf macTsTimeslotLength { 1204 type uint16; 1205 description 1206 "The total length of the timeslot including any unused 1207 time after frame transmission and Acknowledgment, 1208 in microsecond. default: 10000"; 1209 } 1210 } 1211 list TSCHHoppingSequence { 1212 key "macHoppingSequenceID"; 1213 description 1214 "List of all channel hopping sequences used in the 1215 nodes"; 1216 reference 1217 "Table 52f of IEEE802.15.4e-2012"; 1219 leaf macHoppingSequenceID { 1220 type uint8; 1221 description 1222 "defined in Table 52f of IEEE802.15.4e-2012. 1223 Each hopping sequence has a unique ID. default: 0"; 1224 } 1225 leaf macChannelPage { 1226 type uint8; 1227 description 1228 "Corresponds to the 5 MSBs (b27, ..., b31) of a row 1229 in phyChannelsSupported. Note this may not correspond 1230 to the current channelPage in use."; 1231 } 1232 leaf macNumberOfChannels { 1233 type uint16; 1234 description 1235 "Number of channels supported by the PHY on this 1236 channelPage."; 1237 } 1238 leaf macPhyConfiguration { 1239 type uint32; 1240 description 1241 "For channel pages 0 to 6, the 27 LSBs(b0, b1, ..., 1242 b26) indicate the status (1 = to be used, 0 = not to 1243 be used) for each of the up to 27 valid channels 1244 available to the PHY. For pages 7 and 8, the 27 LSBs 1245 indicate the configuration of the PHY, and the channel 1246 list is contained in the extendedBitmap."; 1247 } 1248 leaf macExtendedBitmap { 1249 type uint64; 1250 description 1251 "For pages 7 and 8, a bitmap of numberOfChannels bits, 1252 where bk shall indicate the status of channel k for 1253 each of the up to numberOfChannels valid channels 1254 supported by that channel page and phyConfiguration. 1255 Otherwise field is empty."; 1256 } 1257 leaf macHoppingSequenceLength { 1258 type uint16; 1259 description 1260 "The number of channels in the Hopping Sequence. 1261 Does not necessarily equal numberOfChannels."; 1262 } 1263 list macHoppingSequenceList { 1264 key "HoppingChannelID"; 1265 leaf HoppingChannelID { 1266 type uint16; 1267 description 1268 "channels to be hopped over"; 1269 } 1270 } 1271 leaf macCurrentHop { 1272 type uint16; 1273 config false; 1274 description 1275 "Index of the current position in the hopping sequence 1276 list."; 1277 } 1278 } 1280 5. Commands 1282 6top provides a set of commands as the interface with the higher 1283 layer. Most of these commands are related to the management of 1284 slotframes, cells and scheduling information. 6top also provides an 1285 interface allowing an upper layer to retrieve status information and 1286 statistics. The command set aims to facilitate 6top implementation 1287 by describing the main operations that higher layers may use to 1288 interact with 6top. The listed commands aim at providing semantics 1289 to manipulate 6top MIB, IEEE802.15.4 PIB and IEEE802.15.4e PIB 1290 programmatically. 1292 CREATE.hardcell: Creates one or more hard cells in the schedule. 1293 Fails if the cell already exists. A cell is uniquely identified 1294 by the tuple (slotframe ID, slotOffset, channelOffset). 6top 1295 schedules the cell and marks it as a hard cell, indicating that it 1296 cannot reschedule this cell. The return value is CellID and the 1297 created cell is also filled in CellList(Section 4.1). 1299 CREATE.softcell: To create soft cell(s). 6top is responsible for 1300 picking the exact slotOffset and channelOffset in the schedule, 1301 and ensure that the target node chooses the same cell and TrackID. 1302 6top marks these cells as soft cell, indicating that it will 1303 continuously monitor their performance and reschedule if needed. 1304 The return value is CellID, and the created cell is also filled in 1305 CellList (Section 4.1). 1307 READ.cell: Given a (slotframe ID, slotOffset, channelOffset), 1308 retrieves the cell information. A read command can be issued for 1309 any cell, hard or soft. 6top gets cell information from CellList 1310 (Section 4.1). 1312 UPDATE.cell: Update a hard cell, i.e., re-allocate it to a 1313 different slotOffset and/or channelOffset. Fails if the cell does 1314 not exist. CellList (Section 4.1) will be modified. 1316 DELETE.hardcell: To remove a hard cell. This removes the hard 1317 cell from the node's schedule, from CellList (Section 4.1). 1319 DELETE.softcell: To remove a (number of) soft cell(s). This 1320 command leads the pair of nodes figure out the specific cell(s) to 1321 be removed. After that, the cell(s) will be removed from the 1322 CellLists (Section 4.1) on both sides. 1324 REALLOCATE.softcell: To force a re-allocation of a soft cell. The 1325 reallocated cell will be installed in a different slotOffset, 1326 channelOffset but slotframe and TrackID remain the same. Hard 1327 cells MUST NOT be reallocated. This command will result in the 1328 modificaition of CellLists (Section 4.1) on both sides. 1330 CREATE.slotframe: Creates a new slotframe. Adds a entry to the 1331 SlotframeList (Section 4.1). 1333 READ.slotframe: Returns the information of a slotframe given its 1334 slotframeID from SlotframeList (Section 4.1). 1336 UPDATE.slotframe: Change the number of timeslots in a slotframe 1337 given its slotframeID in SlotframeList (Section 4.1). 1339 DELETE.slotframe: Deletes a slotframe, remove it from 1340 SlotframeList (Section 4.1). 1342 CONFIGURE.monitoring: Configures the level of QoS the Monitoring 1343 process MUST enforce, i.e. config MonitoringStatusList 1344 (Section 4.1). 1346 READ.monitoring: Reads the current Monitoring status from 1347 MonitoringStatusList (Section 4.1). 1349 CONFIGURE.statistics: Configures the statistics process in 1350 StatisticsMetricsList(Section 4.1). The CONFIGURE.statistics 1351 enables flexible configuration and supports empty parameters that 1352 will force 6top to conduct statistics on all members of that 1353 dimension. For example, if ChannelOffset is empty and metric is 1354 set as PDR, then, 6top will conduct the statistics of PDR on all 1355 of channels. 1357 READ.statistics: Reads a metric for the specified dimension. 1358 Information is aggregated according to the parameters from 1359 CellList (Section 4.1). 1361 RESET.statistics: Resets the gathered statistics in CellList 1362 (Section 4.1). 1364 CONFIGURE.eb: Configures EBs, i.e. configures EBlist 1365 (Section 4.1). 1367 READ.eb: Reads the EBs configuration from EBList (Section 4.1). 1369 CONFIGURE.timesource: Configures the Time Source Neighbor 1370 selection process, i.e. configure TimeSource (Section 4.1). 1372 READ.timesource: Retrieves information about the time source 1373 neighbors of that node from TimeSource (Section 4.1). 1375 CREATE.neighbor: Creates an entry for a neighbor in the neighbor 1376 table, i.e. NeighborList (Section 4.1). 1378 READ.all.neighbor: Returns the list of neighbors of that node 1379 according to NeighborList (Section 4.1). 1381 READ.neighbor: Returns the information of a specific neighbor of 1382 that node specified by its neighbor address according to 1383 NeighborList (Section 4.1). 1385 UPDATE.neighbor: Updates the last status for a given 1386 TargetNodeAddress in the NeighborList (Section 4.1). 1388 DELETE.neighbor: Deletes a neighbor given its address from 1389 NeighborList (Section 4.1). 1391 CREATE.queue: Creates and Configures a queue in QueueList 1392 (Section 4.1). 1394 READ.queue: Reads the queue configuration for given QueueId from 1395 QueueList (Section 4.1). 1397 READ.queue.stats: For a given QueueId, reads the queue statistics 1398 information from the QueueList (Section 4.1). 1400 UPDATE.queue: For a given QueueId, update its configuration in the 1401 QueueList (Section 4.1). 1403 DELETE.queue: Deletes a Queue for a given QueueId from the 1404 QueueList (Section 4.1). 1406 LabelSwitching.map: Maps an input cell or a bundle of input cells 1407 to an output cell or a bundle of output cells, i.e. adds a entry 1408 to the LabelSwitchList (Section 4.1). 1410 LabelSwitching.unmap: Unmap one input cell or a bundle of input 1411 cells to an output cell or a bundle of output cells, i.e. modifies 1412 the LabelSwitchList (Section 4.1). 1414 CREATE.chunk: Creates a chunk which consists of one or more 1415 unscheduled cells, i.e. add an entry to the ChunkList 1416 (Section 4.1). 1418 READ.chunk: Returns the information of a chunk given its ChunkID 1419 from ChunkList (Section 4.1). 1421 DELETE.chunk: For given ChunkId, removes a chunk from the 1422 ChunkList (Section 4.1), which also causes all of the scheduled 1423 cells in the chunk to be deleted from the TSCH schedule and 1424 CellList (Section 4.1). 1426 CREATE.hardcell.fromchunk: Creates one or more hard cells from a 1427 chunk. 6top schedules the cell and marks it as a hard cell, 1428 indicating that it cannot reschedule this cell. The cell will be 1429 added into the CellList (Section 4.1). In addition, 6top will 1430 change the attributes corresponding to the cell in the 1431 ChunkCellList (Section 4.1), i.e. its CellID is changed to the 1432 same CellID in the CellList, and its Status is changed to 1433 SCHEDULED. 1435 READ.chunkcell: Returns the information of all cells in a chunk 1436 given its ChunkID from ChunkCellList (Section 4.1). 1438 DELETE.hardcell.fromchunk: To remove a hard cell which comes from 1439 a chunk. This removes the hard cell from the node's schedule and 1440 CellList (Section 4.1). In addition, it changes the attributes 1441 corresponding to the cell in the ChunkCellList (Section 4.1), i.e. 1442 its CellID is changed back to 0xFFFF, and its Status is changed to 1443 UNSCHEDULED. 1445 6. References 1446 6.1. Normative References 1448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1449 Requirement Levels", BCP 14, RFC 2119, March 1997. 1451 6.2. Informative References 1453 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1454 Network Configuration Protocol (NETCONF)", RFC 6020, 1455 October 2010. 1457 [I-D.ietf-6tisch-tsch] 1458 Watteyne, T., Palattella, M., and L. Grieco, "Using 1459 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 1460 Statement and Goals", draft-ietf-6tisch-tsch-02 (work in 1461 progress), October 2014. 1463 [I-D.ietf-6tisch-architecture] 1464 Thubert, P., Watteyne, T., and R. Assimiti, "An 1465 Architecture for IPv6 over the TSCH mode of IEEE 1466 802.15.4e", draft-ietf-6tisch-architecture-03 (work in 1467 progress), July 2014. 1469 [I-D.ietf-6tisch-terminology] 1470 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1471 "Terminology in IPv6 over the TSCH mode of IEEE 1472 802.15.4e", draft-ietf-6tisch-terminology-02 (work in 1473 progress), July 2014. 1475 [I-D.ietf-6tisch-minimal] 1476 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 1477 Configuration", draft-ietf-6tisch-minimal-03 (work in 1478 progress), October 2014. 1480 [I-D.wang-6tisch-6top-sublayer] 1481 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 1482 Operation Sublayer (6top)", draft-wang-6tisch-6top- 1483 sublayer-01 (work in progress), July 2014. 1485 [I-D.ietf-6tisch-coap] 1486 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 1487 Interaction using CoAP", draft-ietf-6tisch-coap-01 (work 1488 in progress), July 2014. 1490 6.3. External Informative References 1492 [IEEE802154e] 1493 IEEE standard for Information Technology, "IEEE std. 1494 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1495 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 1496 2012. 1498 [IEEE802154] 1499 IEEE standard for Information Technology, "IEEE std. 1500 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1501 and Physical Layer (PHY) Specifications for Low-Rate 1502 Wireless Personal Area Networks", June 2011. 1504 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1505 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1506 a Standards-Based Low-Power Wireless Development 1507 Environment", Transactions on Emerging Telecommunications 1508 Technologies , August 2012. 1510 [morell04label] 1511 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 1512 Watteyne, "Label Switching over IEEE802.15.4e Networks. 1513 Transactions on Emerging Telecommunications Technologies", 1514 June 2013. 1516 Authors' Addresses 1518 Qin Wang (editor) 1519 Univ. of Sci. and Tech. Beijing 1520 30 Xueyuan Road 1521 Beijing, Hebei 100083 1522 China 1524 Phone: +86 (10) 6233 4781 1525 Email: wangqin@ies.ustb.edu.cn 1527 Xavier Vilajosana 1528 Universitat Oberta de Catalunya 1529 156 Rambla Poblenou 1530 Barcelona, Catalonia 08018 1531 Spain 1533 Phone: +34 (646) 633 681 1534 Email: xvilajosana@uoc.edu 1535 Thomas Watteyne 1536 Linear Technology 1537 30695 Huntwood Avenue 1538 Hayward, CA 94544 1539 USA 1541 Phone: +1 (510) 400-2978 1542 Email: twatteyne@linear.com