idnits 2.17.1 draft-wang-6tisch-6top-interface-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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (February 11, 2014) is 3721 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 1126, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 1132, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 1138, but not defined == Unused Reference: 'RFC2119' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-minimal' is defined on line 1119, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-00 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-00 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-00 Summary: 2 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: August 15, 2014 Universitat Oberta de Catalunya 6 T. Watteyne 7 Linear Technology 8 February 11, 2014 10 6TiSCH Operation Sublayer (6top) Interface 11 draft-wang-6tisch-6top-interface-01 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 commands 19 internal to the 6top sublayer. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 15, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 3 57 2.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 6 59 2.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 6 61 3. Generic Data Model . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. YANG model of the 6top MIB . . . . . . . . . . . . . . . 8 63 3.2. YANG model of the IEEE802.15.4 PIB . . . . . . . . . . . 22 64 3.3. YANG model of the IEEE802.15.4e PIB . . . . . . . . . . . 23 65 4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 23 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 26 68 5.2. Informative References . . . . . . . . . . . . . . . . . 26 69 5.3. External Informative References . . . . . . . . . . . . . 27 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 72 1. Introduction 74 This document defines a generic data model for the 6TiSCH Operation 75 Sublayer (6top), using the YANG data modeling language. This data 76 model can be used for future network management solutions defined by 77 the 6TiSCH working group. This document also defines a list commands 78 internal to the 6top sublayer. This data model gives access to 79 metrics (e.g. cell state), TSCH configuration and control procedures, 80 and support for the different scheduling mechanisms described in 81 [I-D.ietf-6tisch-architecture]. The 6top sublayer addresses the set 82 of management information and functionalities described in 83 [I-D.ietf-6tisch-tsch]. 85 For example, network formation in a TSCH network is handled by the 86 use of Enhanced Beacons (EB). EBs include information for joining 87 nodes to be able to synchronize and set up an initial network 88 topology. However, [IEEE802154e] does not specify how the period of 89 EBs is configured, nor the rules for a node to select a particular 90 node to join. 6top offers a set of commands so control mechanisms can 91 be introduced on top of TSCH to configure nodes to join a specific 92 node and obtain a unique 16-bit identifier from the network. Once a 93 network is formed, 6top maintains the network's health, allowing for 94 nodes to stay synchronized. It supplies mechanisms to manage each 95 node's time source neighbor and configure the EB interval. Network 96 layers running on top of 6top take advantage of the TSCH MAC layer 97 information so routing metrics, topological information, energy 98 consumption and latency requirements can be adjusted to TSCH, and 99 adapted to application requirements. 101 TSCH requires a mechanism to manage its schedule; 6top provides a set 102 of commands for upper layers to set up specific schedules, either 103 explicitly by detailing specific cell information, or by allowing 104 6top to establish a schedule given a bandwidth or latency 105 requirement. 6top is designed to enable decentralized, centralized or 106 hybrid scheduling solutions. 6top enables internal TSCH queuing 107 configuration, size of buffers, packet priorities, transmission 108 failure behavior, and defines mechanisms to encrypt and authenticate 109 MAC slotframes. 111 As described in [morell04label], due to the slotted nature of a TSCH 112 network, it is possible to use a label switched architecture on top 113 of TSCH cells. As a cell belongs to a specific track, a label header 114 is not needed at each packet; the input cell (or bundle) and the 115 output cell (or bundle) uniquely identify the data flow. The 6top 116 sublayer provides operations to manage the cell mappings. 118 2. 6TiSCH Operation Sublayer (6top) Overview 120 6top is a sublayer which is the next-higher layer for TSCH 121 (Figure 1), as detailed in [I-D.ietf-6tisch-architecture]. 6top 122 offers both management and data interfaces to an upper layer. It 123 includes monitoring and statistics collection, both of which are 124 configurable through its management interface. 126 Protocol Stack 128 +-----------------------------------+ 129 | PCEP | CoAP | | 6LoWPAN | | 130 | PCC | DTLS | PANA | ND |RPL | 131 +------------------------------------------+ 132 | TCP | UDP | ICMP | RSVP | 133 +------------------------------------------+ 134 | IPv6 | 135 +------------------------------------------+ 136 | 6LoWPAN HC | 137 +------------------------------------------+ 138 | 6top | 139 +------------------------------------------+ 140 | IEEE802.15.4e TSCH | 141 +------------------------------------------+ 142 | IEEE802.15.4 | 143 +------------------------------------------+ 145 Figure 1 147 6top distinguishes between hard cells and soft cells. It therefore 148 requires an extra flag to all cells in the TSCH schedule, as detailed 149 in Section 2.1. 151 When a higher layer gives 6top a 6LoWPAN packet for transmission, 152 6top maps it to the appropriate outgoing priority-based queue, as 153 detailed in Section 2.2. 155 Section 3 contains a generic data model for the 6top sublayer, 156 described in the YANG data modeling language. 158 The commands of the management and data interfaces are listed in 159 Section 4. This set of commands is designed to support 160 decentralized, centralized and hybrid scheduling solutions. 162 2.1. Cell Model 164 [IEEE802154e] defines a set of options attached to each cell. A cell 165 can be a Transmit cell, a Receive cell, a Shared cell or a 166 Timekeeping cell. These options are not exclusive, as a cell can be 167 qualified with more than one of them. The MLME-SET-LINK.request 168 command defined in [IEEE802154e] uses a linkOptions bitmap to specify 169 the options of a cell. Acceptable values are: 171 b0 = Transmit 173 b1 = Receive 174 b2 = Shared 176 b3 = Timekeeping 178 b4-b7 = Reserved 180 Only Transmit cells can also be marked as Shared cells. When the 181 shared bit is set, a back-off procedure is applied to handle 182 collisions. Shared behavior does not apply to Receive cells. 184 6top allows an upper layer to schedule a cell at a specific 185 slotOffset and channelOffset, in a specific slotframe. 187 In addition, 6top allows an upper layer to schedule a certain amount 188 of bandwidth to a neighbor, without having to specify the exact 189 slotOffset(s) and channelOffset(s). Once bandwidth is reserved, 6top 190 is in charge of ensuring that this requirement is continuously 191 satisfied. 6top dynamically reallocates cells if needed, and over- 192 provisions if required. 194 6top allows an upper layer to associate a cell with a specific track 195 by using a TrackID. A TrackID is a tuple 196 (TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of 197 the node which initializes the process of creating the track, i.e., 198 the owner of the track; and InstanceID is an instance identifier 199 given by the owner of the track. InstanceID comes from upper layer; 200 InstanceID could for example be the local instance ID defined in RPL. 202 If the TrackID is set to (0,0), the cell can be used by the best- 203 effort QoS configuration or as a Shared cell. If the TrackID is not 204 set to (0,0), i.e., the cell belongs to a specific track, the cell 205 MUST not be set as Shared cell. 207 6top allows an upper layer ask a node manage a a portion of a 208 slotframe, which is named as chunk. Chunks can be delegated 209 explicitly by the PCE to a node, or claimed automatically by any node 210 that participates to the distributed cell scheduling process. The 211 resource in a chunk can be appropriated by the node, i.e. the owner 212 of the chunk. 214 Given this mechanism, 6top defines hard cells (which have been 215 requested specifically) and soft cells (which can be reallocated 216 dynamically). The hard/soft flag is introduced by the 6top sublayer 217 named as CellType, 0: soft cell, 1: hard cell. This option is 218 mandatory; all cells are either hard or soft. 220 2.1.1. hard cells 222 A hard cell is a cell that cannot be dynamically reallocated by 6top. 223 A hard cell is uniquely identified by the following tuple: 225 slotframe ID: ID of the slotframe this cell is part of. 227 slotOffset: the slotOffset for the cell. 229 channelOffset: the channelOffset for the cell. 231 LinkOption bitmap: bitmap as defined in [IEEE802154]. 233 CellType: MUST be set to 1. 235 2.1.2. soft cells 237 A soft cell is a cell that can be reallocated by 6top dynamically. 238 The CellType MUST be set to 0. This cell is installed by 6top given 239 a specific bandwidth requirement. Soft cells are installed through 240 the soft cell negotiation procedure described in "draft-wang-6tisch- 241 6top-sublayer". 243 2.2. Data Transfer Model 245 Once a TSCH schedule is established, 6top is responsible for feeding 246 the data from the upper layer into TSCH. This section describes how 247 6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds 248 it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the 249 properties associated with a packet/fragment from the upper layer 250 includes the next hop neighbor (DestAddr) and expected sending 251 priority of the packet (Priority), and/or TrackID(s). The output to 252 TSCH is the fragment corresponding to the next active cell in the 253 TSCH schedule. 255 6top Data Transfer Model 257 | 258 | (DestAddr, Priority, Fragment) 259 | 260 +---------------------------------------+ 261 | I-MUX | 262 +---------------------------------------+ 263 | | | | .... | 264 | | | | | 265 +---+ +---+ +---+ +---+ +---+ 266 | | | | | | | | | | 267 |Q1 | |Q2 | |Q3 | |Q4 | |Qn | 268 | | | | | | | | | | 269 +---+ +---+ +---+ +---+ +---+ 270 | | | | | 271 | | | | | 272 +---------------------------------------+ 273 | MUX | 274 +---------------------------------------+ 275 | 276 | 277 +---+ 278 |PDU| 279 +---+ 280 | 281 | TSCH MAC-payload 282 | 284 Figure 2 286 In Figure 2, Qi represents a queue, which is either broadcast or 287 unicast, and is assigned a priority. The number of queues is 288 configurable. The relationship between queues and tracks is 289 configurable. For example, for a given queue, only one specific 290 track can be used, all of the tracks can be used, or a subset of the 291 tracks can be used. 293 When 6top receives a packet to transmit through a Send.data command 294 (Section 4), the I-MUX module selects a queue in which to insert it. 295 If the packet's destination address is a unicast (resp. broadcast) 296 address, it will be inserted into a unicast (resp. broadcast) queue. 298 The MUX module is invoked at each scheduled transmit cell by TSCH. 299 When invoked, the MUX module goes through the queues, looking for the 300 best matching frame to send. If it finds a frame, it hands it over 301 to TSCH for transmission. If the next active cell is a broadcast 302 cell, it selects a fragment only from broadcast queues. 304 How the MUX module selects the best frame is configurable. The 305 following rules are a typical example: 307 The frame's layer 2 destination address MUST match the neighbor 308 address associated with the transmit cell. 310 If the transmit cell is associated with a specific track, the 311 frames in the queue corresponding to the TrackID have the 312 highest priority. 314 If the transmit cell is not associated with a specific track, 315 i.e., TrackID=(0,0), frames from a queue with a higher priority 316 MUST be sent before frames from a queue with a lower priority. 318 Further rules can be configured to satisfy specific QoS requirements. 320 3. Generic Data Model 322 This section presents the generic data model of the 6top sublayer, 323 using the YANG data modeling langage. This data model can be used 324 for future network management solutions defined by the 6TiSCH working 325 group. The dada model consists of three parts: 6top MIB, part of the 326 [IEEE802154e] PIB, and part of the [IEEE802154] PIB. 328 3.1. YANG model of the 6top MIB 330 list CellList { 331 key "CellID"; 332 description 333 "List of scheduled cells of a node with all of its neighbors, 334 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 "Equal to SlotframeHandle defined in TSCH"; 346 reference 347 "IEEE802154e"; 348 } 349 leaf SlotOffset { 350 type uint16; 351 description 352 "Defined in IEEE802154e."; 353 reference 354 "IEEE802154e"; 355 } 356 leaf ChannelOffset { 357 type uint8; 358 description 359 "Defined in IEEE802154e. Value range is 0..15"; 360 reference 361 "IEEE802154e"; 362 } 363 leaf LinkOption { 364 type bits { 365 bit Transmit { 366 position 0; 367 } 368 bit Receive { 369 position 1; 370 } 371 bit Share { 372 position 2; 373 } 374 bit Timekeeping { 375 position 3; 376 } 377 bit Reserved1 { 378 position 4; 379 } 380 bit Reserved2 { 381 position 5; 382 } 383 bit Reserved3 { 384 position 6; 385 } 386 bit Reserved4 { 387 position 7; 388 } 389 } 390 description 391 "Defined in IEEE802154e."; 392 reference 393 "IEEE802154e"; 394 } 395 leaf LinkType { 396 type enumeration { 397 enum NORMAL; 398 enum ADVERTISING; 399 } 400 description 401 "Defined in IEEE802154"; 402 reference 403 "IEEE802154"; 404 } 405 leaf CellType { 406 type enumeration { 407 enum SOFT; 408 enum HARD; 409 } 410 description 411 "Defined in 6top"; 412 } 413 leaf TargetNodeAddress { 414 type uint64; 415 description 416 "Defined by 6top, but being constrained by TSCH 417 macNodeAddress size, 2-octets. If using TSCH as MAC, 418 higher 6-octets should be filled with 0, and lowest 419 2-octets is neighbor address"; 420 } 421 leaf TrackID { 422 type uint16; 423 description 424 "A TrackID is a tuple (TrackOwnerAddr,InstanceID), where 425 TrackOwnerAddr is the address of the node which initializes 426 the process of creating the track, i.e., the owner of the 427 track; and InstanceID is an instance identifier given by 428 the owner of the track."; 429 } 430 container Statistic { 431 leaf NumOfStatistic { 432 type uint8; 433 description 434 "Number of statistics collected on the cell"; 435 } 436 list MeasureList { 437 key "StatisticsMetricsID"; 438 leaf StatisticsMetricsID{ 439 type uint16; 440 } 441 leaf StatisticsValue{ 442 type uint16; 443 config false; 444 } 445 } 446 } 447 } 449 list SlotframeList { 450 key "SlotframeID"; 451 leaf SlotframeID { 452 type uint8; 453 } 454 leaf NumOfSlots { 455 type uint16; 456 } 457 } 459 list MonitoringStatusList { 460 key "MonitoringStatusID"; 461 leaf MonitoringStatusID { 462 type uint16; 463 } 464 leaf SlotframeID { 465 type uint8; 466 } 467 leaf TargetNodeAddress { 468 type uint64; 469 } 470 leaf EnforcePolicy { 471 type enumeration { 472 enum DISABLE; 473 enum BESTEFFORT; 474 enum STRICT; 475 enum OVERPROVISION; 476 } 477 description 478 "Currently enforced QoS policy"; 479 } 480 leaf AllocatedHard { 481 type uint16; 482 config false; 483 description 484 "Number of hard cells allocated"; 485 } 486 leaf AllocatedSoft { 487 type uint16; 488 config false; 489 description 490 "Number of soft cells allocated"; 491 } 492 leaf OverProvision { 493 type uint16; 494 config false; 495 description 496 "Overprovisioned cells. 0 if CONFIGURE.qos enforce is 497 DISABLE"; 498 } 499 leaf QoS { 500 type uint16; 501 config false; 502 description 503 "Current QoS including overprovisioned cells, i.e. the 504 bandwidth obtained including the overprovisioned cells."; 505 } 506 leaf NQoS { 507 type uint16; 508 config false; 509 description 510 "Real QoS without provisioned cells, i.e. the actual 511 bandwidth without taking into account the overprovisioned 512 cells."; 513 } 514 } 516 list StatisticsMetricsList { 517 key "StatisticsMetricsID"; 518 leaf StatisticsMetricsID { 519 type uint16; 520 } 521 leaf SlotframeID { 522 type uint16; 523 description 524 "ID of the slotframe. If empty, monitors all slotframe IDs"; 525 reference 526 "IEEE802154e"; 527 } 528 leaf SlotOffset { 529 type uint16; 530 description 531 "Specific slotOffset to be monitored. If empty all timeslots 532 are monitored"; 533 reference 534 "IEEE802154e"; 535 } 536 leaf ChannelOffset { 537 type uint8; 538 description 539 "Specific channelOffset to be monitored. If empty all 540 channels are monitored"; 541 reference 542 "IEEE802154e"; 543 } 544 leaf TargetNodeAddress { 545 type uint64; 546 description 547 "If empty, all neighbor nodes are monitored."; 548 } 549 leaf Metrics { 550 type enumeration { 551 enum PDR; 552 enum ETX; 553 enum RSSI; 554 enum LQI; 555 } 556 description 557 "The metric to be monitored."; 558 } 559 leaf Window { 560 type uint16; 561 description 562 "measurement period, in Number of the slotframe size"; 563 } 564 leaf Enable { 565 type enumeration { 566 enum DISABLE; 567 enum ENABLE; 568 } 569 } 570 } 571 list EBList { 572 key "EbID"; 573 leaf EbID { 574 type uint8; 575 } 576 leaf CellID { 577 type uint16; 578 description 579 "Equal to LinkHandle in IEEE802154e"; 580 } 581 leaf Peroid { 582 type uint16; 583 description 584 "The EBs period, in seconds"; 585 } 586 leaf Expiration { 587 type enumeration { 588 enum NEVERSTOP; 589 enum EXPIRATION; 590 } 591 description 592 "Which Period to indicate when the EBs periodicity will 593 stop. If Zero the period never stops."; 594 } 595 leaf Priority { 596 type uint8; 597 description 598 "The joining priority model that will be used for 599 advertisements. Joining priority MAY be for example 600 SAME_AS_PARENT, RANDOM, BEST_PARENT+1 or 601 DAGRANK(rank)."; 602 } 603 } 605 container TimeSource { 606 leaf policy { 607 type enumeration { 608 enum ALLPARENT; 609 enum BESTCONNECTED; 610 enum LOWESTJOINPRIORITY; 611 } 612 } 613 leaf TargetNodeAddress { 614 type uint64; 615 description 616 "Address of the time source neighbor"; 617 } 618 leaf MinTimeCorrection { 619 type uint16; 620 description 621 "In microsecond"; 622 } 623 leaf MaxTimeCorrection { 624 type uint16; 625 description 626 "In microsecond"; 627 } 628 leaf AveTimeCorrection { 629 type uint16; 630 description 631 "In microsecond"; 632 } 633 } 634 typedef asntype { 635 description 636 "The type to store ASN. String of 5 bytes"; 637 type string { 638 length "0..5"; 639 } 640 } 642 list NeighborList { 643 key "TargetNodeAddress"; 644 leaf TargetNodeAddress { 645 type uint64; 646 description 647 "Address of the time source neighbor"; 648 } 649 leaf RSSI { 650 type uint8; 651 config false; 652 description 653 "The received signal strength"; 654 } 655 leaf LinkQuality { 656 type uint8; 657 config false; 658 description 659 "The LQI metric"; 660 } 661 leaf ASN { 662 type asntype; 663 config false; 664 description 665 "The 5 ASN bytes"; 666 } 667 } 669 list QueueList { 670 key "QueueId"; 671 leaf QueueId { 672 type uint8; 673 description 674 "Address of the time source neighbor"; 675 } 676 leaf TxqLength { 677 type uint8; 678 description 679 "The TX queue length in number of packets"; 680 } 681 leaf RxqLength { 682 type uint8; 683 description 684 "The RX queue length in number of packets"; 685 } 686 leaf NumrTx { 687 type uint8; 688 description 689 "Number of allowed retransmissions."; 690 } 691 leaf Age { 692 type uint16; 693 description 694 "In seconds. Discard packet according to its age 695 on the queue. 0 if no discards are allowed."; 696 } 697 leaf RTXbackoff { 698 type uint8; 699 description 700 "retransmission backoff in number of slotframes. 701 0 if next available timeslot wants to be used."; 702 } 703 leaf StatsWindow { 704 type uint16; 705 description 706 "In second, window of time used to compute stats."; 707 } 708 leaf QueuePriority { 709 type uint8; 710 description 711 "The priority for this queue."; 712 } 713 list TrackIds { 714 key "TrackID"; 715 leaf TrackID{ 716 type uint16; 717 description 718 "The TrackID."; 719 } 720 } 721 leaf MinLenTXQueue { 722 type uint8; 723 config false; 724 description 725 "Statistics, lowest TX queue len registered in the window."; 726 } 727 leaf MaxLenTXQueue { 728 type uint8; 729 config false; 730 description 731 "Statistics, largest TX queue len registered in the window."; 732 } 733 leaf AvgLenTXQueue { 734 type uint8; 735 config false; 736 description 737 "Statistics, avg TX queue len registered in the window."; 738 } 739 leaf MinLenRXQueue { 740 type uint8; 741 config false; 742 description 743 "Statistics, lowest RX queue len registered in the window."; 744 } 745 leaf MaxLenRXQueue { 746 type uint8; 747 config false; 748 description 749 "Statistics, largest RX queue len registered in the window."; 750 } 751 leaf AvgLenRXQueue { 752 type uint8; 753 config false; 754 description 755 "Statistics, avg RX queue len 756 registered in the window."; 757 } 758 leaf MinRetransmissions { 759 type uint8; 760 config false; 761 description 762 "Statistics, lowest number of 763 retransmissions registered in the window."; 764 } 765 leaf MaxRetransmissions { 766 type uint8; 767 config false; 768 description 769 "Statistics, largest number of retransmissions registered 770 in the window."; 771 } 772 leaf AvgRetransmissions { 773 type uint8; 774 config false; 775 description 776 "Statistics, average number of retransmissions registered 777 in the window."; 779 } 780 leaf MinPacketAge { 781 type uint16; 782 config false; 783 description 784 "Statistics, in seconds, minimum time a packet stayed in 785 the queue during the observed window."; 786 } 787 leaf MaxPacketAge { 788 type uint16; 789 config false; 790 description 791 "Statistics, in seconds, maximum time a packet stayed 792 in the queue during the observed window."; 793 } 794 leaf AvgPacketAge { 795 type uint16; 796 config false; 797 description 798 "Statistics, in seconds, average time a packet stayed in 799 the queue during the observed window."; 800 } 801 leaf MinBackoff { 802 type uint8; 803 config false; 804 description 805 "Statistics, in number of slotframes, minimum Backoff 806 for a packet in the queue during the observed window."; 807 } 808 leaf MaxBackoff { 809 type uint8; 810 config false; 811 description 812 "Statistics, in number of slotframes, maximum Backoff 813 for a packet in the queue during the observed window."; 814 } 815 leaf AvgBackoff { 816 type uint8; 817 config false; 818 description 819 "Statistics, in number of slotframes, average Backoff 820 for a packet in the queue during the observed window."; 821 } 822 } 823 list LabelSwitchList { 824 key "LabelSwitchID"; 825 leaf LabelSwitchID { 826 type uint16; 827 } 828 list InputCellIds { 829 key "CellID"; 830 leaf CellID{ 831 type uint16; 832 description 833 "The CellID."; 834 } 835 } 836 list OutputCellIds { 837 key "CellID"; 838 leaf CellID{ 839 type uint16; 840 description 841 "The CellID."; 842 } 843 } 844 leaf LoadBalancingPolicy { 845 type enumeration { 846 enum ROUNDROBIN; 847 enum OTHER; 848 } 849 description 850 "The load-balancing policy."; 851 } 852 } 853 list TrackList { 854 key "TrackId"; 855 leaf TrackId { 856 type uint16; 857 } 858 leaf TrackOwnerAddr { 859 type uint64; 860 description 861 "The address of the node which initializes the process of 862 creating the track, i.e., the owner of the track;"; 863 } 864 leaf InstanceID { 865 type uint16; 866 description 867 "InstanceID is an instance identifier given by the owner of 868 the track. InstanceID comes from upper layer; InstanceID could 869 for example be the local instance ID defined in RPL."; 870 } 871 } 872 list ChunkList { 873 key "ChunkId"; 874 leaf ChunkId{ 875 type uint16; 876 description 877 "The id of a chunk"; 878 } 879 leaf SlotframeId{ 880 type uint8; 881 description 882 "The id of the slotframe that is mapped to this chunk"; 883 } 884 list ChunkCells { 885 key "SlotOffset ChannelOffset"; 886 leaf SlotOffset{ 887 type uint16; 888 description 889 "The slotoffset."; 890 } 891 leaf ChannelOffset{ 892 type uint16; 893 description 894 "The channeloffset."; 895 } 896 leaf CellID{ 897 type uint16; 898 description 899 "Initial value of CellID is 0xFFFF. When the cell is 900 appropriated, the value of CellID is same as that in 901 CellList"; 902 } 903 leaf ChunkCellStatus { 904 type enumeration { 905 enum UNAPPROPRIATED; 906 enum APPROPRIATED; 907 } 908 } 909 } 910 } 912 3.2. YANG model of the IEEE802.15.4 PIB 914 This section describes the YANG model of the part of [IEEE802154] PIB 915 used by 6top, such as security related attributes. This part of data 916 will be accessed through the MLME-GET and MLME-SET [IEEE802154] 917 primitive. 919 TODO 921 3.3. YANG model of the IEEE802.15.4e PIB 923 This section describes the YANG model of the part of [IEEE802154e] 924 PIB used in 6top, such as TSCH related attributes. This part of data 925 will be accessed through the MLME-GET and MLME-SET [IEEE802154] 926 primitive. 928 TODO 930 4. Commands 932 6top provides a set of commands as the interface with the higher 933 layer. Most of these commands are related to the management of 934 slotframes, cells and scheduling information. 6top also provides an 935 interface allowing an upper layer to retrieve status information and 936 statistics. The command set aims to facilitate 6top implementation 937 by describing the main operations that higher layers may use to 938 interact with 6top. The listed commands aim at providing semantics 939 to manipulate 6top MIB, IEEE802.15.4 PIB and IEEE802.15.4e PIB 940 programmatically. 942 CREATE.hardcell: Creates one or more hard cells in the schedule. 943 Fails if the cell already exists. A cell is uniquely identified 944 by the tuple (slotframe ID, slotOffset, channelOffset). 6top 945 schedules the cell and marks it as a hard cell, indicating that it 946 cannot reschedule this cell. The return value is CellID and the 947 created cell is also filled in CellList(Section 3.1). 949 CREATE.softcell: To create soft cell(s). 6top is responsible for 950 picking the exact slotOffset and channelOffset in the schedule, 951 and ensure that the target node chooses the same cell and TrackID. 952 6top marks these cells as soft cell, indicating that it will 953 continuously monitor their performance and reschedule if needed. 954 The return value is CellID, and the created cell is also filled in 955 CellList (Section 3.1). 957 READ.cell: Given a (slotframe ID, slotOffset, channelOffset), 958 retrieves the cell information. A read command can be issued for 959 any cell, hard or soft. 6top gets cell information from CellList 960 (Section 3.1). 962 UPDATE.cell: Update a hard cell, i.e., re-allocate it to a 963 different slotOffset and/or channelOffset. Fails if the cell does 964 not exist. CellList (Section 3.1) will be modified. 966 DELETE.hardcell: To remove a hard cell. This removes the hard 967 cell from the node's schedule, from CellList (Section 3.1). 969 DELETE.softcell: To remove a (number of) soft cell(s). This 970 command leads the pair of nodes figure out the specific cell(s) to 971 be removed. After that, the cell(s) will be removed from the 972 CellLists (Section 3.1) on both sides. 974 REALLOCATE.softcell: To force a re-allocation of a soft cell. The 975 reallocated cell will be installed in a different slotOffset, 976 channelOffset but slotframe and TrackID remain the same. Hard 977 cells MUST NOT be reallocated. This command will result in the 978 modificaition of CellLists (Section 3.1) on both sides. 980 CREATE.slotframe: Creates a new slotframe. Adds a entry to the 981 SlotframeList (Section 3.1). 983 READ.slotframe: Returns the information of a slotframe given its 984 slotframeID from SlotframeList (Section 3.1). 986 UPDATE.slotframe: Change the number of timeslots in a slotframe 987 given its slotframeID in SlotframeList (Section 3.1). 989 DELETE.slotframe: Deletes a slotframe, remove it from 990 SlotframeList (Section 3.1). 992 CONFIGURE.monitoring: Configures the level of QoS the Monitoring 993 process MUST enforce, i.e. config MonitoringStatusList 994 (Section 3.1). 996 READ.monitoring: Reads the current Monitoring status from 997 MonitoringStatusList (Section 3.1). 999 CONFIGURE.statistics: Configures the statistics process in 1000 StatisticsMetricsList(Section 3.1). The CONFIGURE.statistics 1001 enables flexible configuration and supports empty parameters that 1002 will force 6top to conduct statistics on all members of that 1003 dimension. For example, if ChannelOffset is empty and metric is 1004 set as PDR, then, 6top will conduct the statistics of PDR on all 1005 of channels. 1007 READ.statistics: Reads a metric for the specified dimension. 1008 Information is aggregated according to the parameters from 1009 CellList (Section 3.1). 1011 RESET.statistics: Resets the gathered statistics in CellList 1012 (Section 3.1). 1014 CONFIGURE.eb: Configures EBs, i.e. configures EBlist 1015 (Section 3.1). 1017 READ.eb: Reads the EBs configuration from EBList (Section 3.1). 1019 CONFIGURE.timesource: Configures the Time Source Neighbor 1020 selection process, i.e. configure TimeSource (Section 3.1). 1022 READ.timesource: Retrieves information about the time source 1023 neighbors of that node from TimeSource (Section 3.1). 1025 CREATE.neighbor: Creates an entry for a neighbor in the neighbor 1026 table, i.e. NeighborList (Section 3.1). 1028 READ.all.neighbor: Returns the list of neighbors of that node 1029 according to NeighborList (Section 3.1). 1031 READ.neighbor: Returns the information of a specific neighbor of 1032 that node specified by its neighbor address according to 1033 NeighborList (Section 3.1). 1035 UPDATE.neighbor: Updates the last status for a given 1036 TargetNodeAddress in the NeighborList (Section 3.1). 1038 DELETE.neighbor: Deletes a neighbor given its address from 1039 NeighborList (Section 3.1). 1041 CREATE.queue: Creates and Configures a queue in QueueList 1042 (Section 3.1). 1044 READ.queue: Reads the queue configuration for given QueueId from 1045 QueueList (Section 3.1). 1047 READ.queue.stats: For a given QueueId, reads the queue statistics 1048 information from the QueueList (Section 3.1). 1050 UPDATE.queue: For a given QueueId, update its configuration in the 1051 QueueList (Section 3.1). 1053 DELETE.queue: Deletes a Queue for a given QueueId from the 1054 QueueList (Section 3.1). 1056 LabelSwitching.map: Maps an input cell or a bundle of input cells 1057 to an output cell or a bundle of output cells, i.e. adds a entry 1058 to the LabelSwitchList (Section 3.1). 1060 LabelSwitching.unmap: Unmap one input cell or a bundle of input 1061 cells to an output cell or a bundle of output cells, i.e. modifies 1062 the LabelSwitchList (Section 3.1). 1064 CREATE.chunk: Creates a chunk which consists of one or more 1065 unappropriated cells, i.e. adda an entry to the ChunkList 1066 (Section 3.1). 1068 DELETE.chunk: For given ChunkId, removes a chunk from the 1069 ChunkList (Section 3.1), which also causes all of the appropriated 1070 cells in the chunk to be deleted from the TSCH schedule and 1071 CellList (Section 3.1). 1073 CREATE.hardcell.fromchunk: Creates one or more hard cells from a 1074 chunk. 6top schedules the cell and marks it as a hard cell, 1075 indicating that it cannot reschedule this cell. The cell will be 1076 added into the CellList (Section 3.1). In addition, 6top will 1077 change the attributes corresponding to the cell in the ChunkList 1078 (Section 3.1), i.e. its CellID is changed to the same CellID in 1079 the CellList, and its Status is changed to APPROPRIATED. 1081 DELETE.hardcell.fromchunk: To remove a hard cell which comes from 1082 a chunk. This removes the hard cell from the node's schedule and 1083 CellList (Section 3.1). In addition, it changes the attributes 1084 corresponding to the cell in the ChunkList (Section 3.1), i.e. its 1085 CellID is changed back to 0xFFFF, and its Status is changed to 1086 UNAPPROPRIATED. 1088 5. References 1090 5.1. Normative References 1092 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1093 Requirement Levels", BCP 14, RFC 2119, March 1997. 1095 5.2. Informative References 1097 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1098 Network Configuration Protocol (NETCONF)", RFC 6020, 1099 October 2010. 1101 [I-D.ietf-6tisch-tsch] 1102 Watteyne, T., Palattella, M., and L. Grieco, "Using 1103 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 1104 Statement and Goals", draft-ietf-6tisch-tsch-00 (work in 1105 progress), November 2013. 1107 [I-D.ietf-6tisch-architecture] 1108 Thubert, P., Watteyne, T., and R. Assimiti, "An 1109 Architecture for IPv6 over the TSCH mode of IEEE 1110 802.15.4e", draft-ietf-6tisch-architecture-00 (work in 1111 progress), November 2013. 1113 [I-D.ietf-6tisch-terminology] 1114 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1115 "Terminology in IPv6 over the TSCH mode of IEEE 1116 802.15.4e", draft-ietf-6tisch-terminology-00 (work in 1117 progress), November 2013. 1119 [I-D.ietf-6tisch-minimal] 1120 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 1121 Configuration", draft-ietf-6tisch-minimal-00 (work in 1122 progress), November 2013. 1124 5.3. External Informative References 1126 [IEEE802154e] 1127 IEEE standard for Information Technology, "IEEE std. 1128 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1129 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 1130 2012. 1132 [IEEE802154] 1133 IEEE standard for Information Technology, "IEEE std. 1134 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1135 and Physical Layer (PHY) Specifications for Low-Rate 1136 Wireless Personal Area Networks", June 2011. 1138 [OpenWSN] "Berkeley's OpenWSN Project Homepage", 1139 . 1141 [morell04label] 1142 Morell, A., Vilajosana, X., Lopez-Vicario, J., and T. 1143 Watteyne, "Label Switching over IEEE802.15.4e Networks. 1144 Transactions on Emerging Telecommunications Technologies", 1145 June 2013. 1147 Authors' Addresses 1149 Qin Wang (editor) 1150 Univ. of Sci. and Tech. Beijing 1151 30 Xueyuan Road 1152 Beijing, Hebei 100083 1153 China 1155 Phone: +86 (10) 6233 4781 1156 Email: wangqin@ies.ustb.edu.cn 1157 Xavier Vilajosana 1158 Universitat Oberta de Catalunya 1159 156 Rambla Poblenou 1160 Barcelona, Catalonia 08018 1161 Spain 1163 Phone: +34 (646) 633 681 1164 Email: xvilajosana@uoc.edu 1166 Thomas Watteyne 1167 Linear Technology 1168 30695 Huntwood Avenue 1169 Hayward, CA 94544 1170 USA 1172 Phone: +1 (510) 400-2978 1173 Email: twatteyne@linear.com