idnits 2.17.1 draft-satish-6tisch-6top-sf1-04.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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 200: '... node SHOULD send a ResvErr message ...' RFC 2119 keyword, line 257: '... FLOWSPEC. If not, Node B SHOULD send...' RFC 2119 keyword, line 262: '...eld in the 6P request SHOULD be empty....' RFC 2119 keyword, line 273: '... fail, Node B SHOULD send a ResvErr ...' RFC 2119 keyword, line 304: '...Figure 7, Node B SHOULD provide a cand...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2017) is 2370 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: 'I-D.ietf-6tisch-6top-protocol' is mentioned on line 494, but not defined == Missing Reference: 'RFC3209' is mentioned on line 504, but not defined == Missing Reference: 'RFC2205' is mentioned on line 499, but not defined == Missing Reference: 'RFC3473' is mentioned on line 509, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-12 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-13 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-02 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch S. Anamalamudi 3 Internet-Draft Huaiyin Institute of Technology 4 Intended status: Standards Track B. Liu 5 Expires: April 30, 2018 M. Zhang 6 Huawei Technologies 7 AR. Sangi 8 Huaiyin Institute of Technology 9 C. Perkins 10 Futurewei 11 S.V.R.Anand 12 Indian Institute of Science 13 October 27, 2017 15 Scheduling Function One (SF1): hop-by-hop Scheduling with RSVP-TE in 16 6tisch Networks 17 draft-satish-6tisch-6top-sf1-04 19 Abstract 21 This document defines a 6top Scheduling Function called "Scheduling 22 Function One" (SF1) to reserve, label and schedule the end-to-end 23 resources hop-by-hop through the Resource ReserVation Protocol - 24 Traffic Engineering (RSVP-TE). SF1 uses the 6P signaling messages 25 with a global TrackID to add or delete the cells in L2-bundles of 26 isolated traffic flows. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 30, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Operation of Scheduling Function One (SF1) . . . . . . . . . 4 64 2.1. End-to-end Operation . . . . . . . . . . . . . . . . . . 4 65 2.2. One-hop Operation . . . . . . . . . . . . . . . . . . . . 6 66 2.2.1. 3-step transaction . . . . . . . . . . . . . . . . . 6 67 2.2.2. 2-step transaction . . . . . . . . . . . . . . . . . 7 68 2.3. Reroute and Bandwidth Increase mechanism . . . . . . . . 8 69 2.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1. RSVP-PATH message . . . . . . . . . . . . . . . . . . . . 9 72 3.2. RSVP-RESV message . . . . . . . . . . . . . . . . . . . . 10 73 4. Scheduling Function Identifier . . . . . . . . . . . . . . . 11 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. References . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Scheduling Function Zero (SF0) [I-D.ietf-6tisch-6top-sf0] enables on- 84 the-fly cell scheduling (ADD/DELETE) between one-hop neighbors for 85 aggregated (best-effort) traffic flows. In other words, all the 86 instances from nodeA to nodeB in Figure 1 are scheduled in a single 87 L3-bundle (IP link). 89 L3-bundle (Instance-1,Instance-2,...Instance-n) 90 -------------------------------------------------> 91 nodeA<------------------------------------------------- nodeB 92 L3-bundle (Instance-1,Instance-2,...Instance-n) 94 Figure 1: L3-bundle for aggregated traffic flows over one-hop with 95 SF0. 97 Some applications (e.g. Industrial M2M) require end-to-end dedicated 98 L2-bundles to support control/data streams for time-critical 99 applications [I-D.ietf-detnet-use-cases]. For such applications, the 100 sender can reserve a dedicated track to the receiver for each 101 isolated instance. A track is actually a succession of paired 102 L2-bundles (a receive bundle at the downstream node and a transmit 103 bundle at the upstream node), which is identified by a global 104 TrackID. Per-instance L2-bundles need to be scheduled hop-by-hop in 105 between sender and receiver [I-D.ietf-6tisch-architecture]. In 106 addition, cells in the scheduled end-to-end track of each instance 107 may have to be dynamically adapted for bursty time-critical traffic 108 flows. With one-hop based SF0 cell scheduling, it is difficult to 109 schedule dedicated end-to-end cells for isolated traffic flows. 110 Moreover, global bandwidth estimation through Resource Reservation 111 protocol is required for bandwidth allocation in multi-hop cell 112 scheduling. This draft specifies a Scheduling Function One (SF1) to 113 schedule end-to-end dedicated L2-bundles for each instance, and to 114 dynamically adapt the cells in already scheduled L2-bundles through 115 RSVP-TE (see Figure 2). 117 L2-bundle(Instance-1) L2-bundle(Instance-1) 118 -----------------------> ------------------> 119 <------------------------ <------------------- 120 L2-bundle(Instance-1) L2-bundle(Instance-1) 122 L2-bundle(Instance-2) L2-bundle(Instance-2) 123 ----------------------> -----------------> 124 Sender<-----------------------nodeB <----------------- Receiver 125 L2-bundle(Instance-2) L2-bundle(Instance-2) 126 . . 127 . . 128 L2-bundle(Instance-n) L2-bundle(Instance-n) 129 -----------------------> --------------------> 130 <------------------------ <-------------------- 131 L2-bundle(Instance-n) L2-bundle(Instance-n) 133 Figure 2: Dedicated L2-bundles for end-to-end isolated traffic flows 134 with SF1 136 2. Operation of Scheduling Function One (SF1) 138 SF1 is a combination of RSVP-TE and 6P (the 6top protocol 139 [I-D.ietf-6tisch-6top-protocol]). According to the bandwidth and QoS 140 requirements of traffic flows, SF1 can schedule, reserve and label 141 L2-bundles of cells at each hop, build up an end-to-end track 142 identified by a global TrackID, and dynamically adapt the cells in an 143 existing track. 145 Using SF1, the Sender determines when to reserve end-to-end 146 resources. The following events may trigger the use of SF1: 148 o The Sender has an outgoing bandwidth requirement for a new instance 149 to transmit data to Receiver. 151 o The Sender has a new outgoing bandwidth requirement for an existing 152 instance to transmit data to Receiver. 154 In both cases, distributed RSVP-TE is used to provide end-to-end 155 resource reservations along with scheduling operations. The outcome 156 of RSVP-TE is a label switching path (LSP) [RFC3209]. In the context 157 of this draft, a track is actually an LSP, in which the label at each 158 hop is associated to the reserved cells. And the TrackID is 159 equivalent to the LSP_ID. 161 2.1. End-to-end Operation 163 PATH PATH PATH 164 +-----------+ +-----------+ +-----------+ 165 | | | | | | 166 | v | v | v 167 +--------+ +--------+ +--------+ +--------+ 168 | Sender | | Node A | | Node B | |Receiver| 169 +--------+ +--------+ +--------+ +--------+ 170 ^ 6P | ^ 6P | ^ 6P | 171 | Trans. | | Trans. | | Trans. | 172 |<--------->| |<--------->| |<--------->| 173 +-----------+ +-----------+ +-----------+ 174 RESV RESV RESV 176 Figure 3: End-to-end Operation in SF1 178 +--------+ +--------+ +--------+ 179 | Sender |-----PATH----->|Receiver|-----RESV----->| Sender | 180 +--------+ +--------+ +--------+ 181 |----------E2E Track Reservation---------| 182 |-----------------E2E Timeout---------------| 184 Figure 4: End-to-end timeout in SF1 186 It is assumed that an end-to-end route path is already available, for 187 instance by using AODV-RPL [I-D.ietf-roll-aodv-rpl] routing. To 188 initiate the track reservation, the sender sends the RSVP-PATH 189 message to the receiver along the route. The PATH message describes 190 the characteristics of the traffic flow and gathers information along 191 the route to help the receiver(s) construct an appropriate 192 reservation request [RFC2205]. Upon arrival of the PATH message, the 193 receiver sends an RSVP-RESV message upstream to the sender. At each 194 hop, the cells to be reserved are negotiated between 2 neighbors with 195 the help of 6P transactions. If one-hop reservation succeeds, the 196 downstream node assigns a label, which is associated to the selected 197 cells, to the upstream node. And the label is also associated to the 198 track whose TrackID is encapsulated in the FILTER_SPEC of the RESV 199 message. If one-hop reservation fails at an intermediate node, the 200 node SHOULD send a ResvErr message to the receiver and all the nodes 201 along the downstream route to tear down the reserved resources. When 202 the RESV message arrives at the sender before the end-to-end timeout, 203 an end-to-end track is built successfully. If no RESV message is 204 received at the sender when timeout, the track reservation fails. 206 The end-to-end data transmission is achieved through Track Forwarding 207 [I-D.ietf-6tisch-architecture] that can be seen as a G-MPLS operation 208 in which the explicit label at each hop is associated to an implicit 209 label, i.e., the reserved cells. When transmitting data, the sender 210 identifies the track to be used based on Sender and Receiver IP 211 addresses and RPLInstanceID of the packet. At each hop, the packet 212 is transmitted using the reserved L2-bundle of cells on this track. 214 +--------------+ <-Data transmission in end-to-end Track-> 215 | IPv6 | Sender Receiver 216 +--------------+ | | 217 | 6LoWPAN | | | 218 +--------------+ | nodeB | 219 | 6top | | +----+ | 220 +--------------+ | | | | 221 | TSCH MAC | | | | | 222 +--------------+ | | | | 223 | LLN PHY | | L2-Bundle | | L2-Bundle | 224 +--------------+ +----------------+ +---------------+ 225 <--Dedicated cells for each Instance--> 227 Figure 5: Track Forwarding 229 2.2. One-hop Operation 231 Upon arrival of the PATH message at an application receiver, the 232 SENDER_TSPEC and ADSPEC objects are utilized to select the resource 233 reservation parameters in FLOWSPEC of the RESV message. Since RSVP 234 provides receiver initiated resource reservation setup, the 235 scheduling operation proceeds upstream from receiver to sender. In 236 6P the resources are represented as cells, thus the bandwidth can be 237 interpreted as the number of cells, and the QoS can be interpreted as 238 the constraints on cells, e.g. the priority of slotframe, the 239 slotOffset and channelOffset of cells. Therefore, the bandwidth and 240 QoS parameters in FLOWSPEC need to be mapped to number and 241 constraints of cells in the 6P transaction. 243 In this document, when there are two neighbor nodes, the upstream 244 node is named Node A, and the downstream node is named Node B. If 245 Node B is the receiver, the cell reservation is initiated by the 246 arrival of a PATH message. If node B is an intermediate node, the 247 reservation is initiated by the arrival of an RESV message from 248 downstream. The cell reservation begins with 6P transactions, which 249 can be 3-step or 2-step [I-D.ietf-6tisch-6top-protocol]. The 250 operation of RESV message with these two kinds of transactions is 251 specified as follows. 253 2.2.1. 3-step transaction 255 As illustrated in Figure 6, Node B first determines whether it can 256 provide enough qualified cells to receive traffic from Node A, 257 according to the parameters in FLOWSPEC. If not, Node B SHOULD send 258 a ResvErr message. Otherwise, Node B transmits a 6P Request message 259 to Node A with the slotFrame_ID in the metadata field. The type of 260 the Request message (ADD or DELETE) is decided by comparing the the 261 required cells and the currently reserved cells. In a 3-step 262 transaction, the "CellList" field in the 6P request SHOULD be empty. 263 The timeout for the 6P transaction is as defined in 264 [I-D.ietf-6tisch-6top-protocol]. Node A checks the associated 265 slotframe and proposes a candidate CellList. Then a 6P Response 266 message is sent back to Node B. If Node B is able to select expected 267 number of cells in this candidate CellList, it sends an RESV message 268 to Node A, in which the 6P Confirmation message indicating the 269 selected cells is encapsulated as the 6P OPERATION object, and the 270 label is assigned as defined in Section 3.2. Otherwise, the Node B 271 can choose to initiate another 6P transaction on another slotframe 272 which can fulfill the QoS requirement. If all the 6P transactions 273 fail, Node B SHOULD send a ResvErr message all the way to the 274 receiver to tear down all the reserved resources. When the RESV 275 message arrives at Node A, the L2-bundle between Node A and Node B is 276 installed. 278 Node A Node B 279 -------------- -------------- 280 | | FLOWSPEC: 281 | | bandwidth and 282 | | QoS requirements 283 | | 284 | | Map bandwidth 285 | | and QoS to cells 286 | 6P Request with | 287 | an empty CellList | timeout 288 |<--------------------------| --- 289 | | | 290 | 6P Response with | | 291 timeout | candidate CellList | | 292 --- |-------------------------->| X 293 | | RESV carrying 6P | 294 | | Confirmation with | 295 | | selected CellList | 296 X |<--------------------------|Cells reserved 297 Cells reserved| | 298 Label assigned| | 300 Figure 6: Operation of RESV message with 3-step transaction. 302 2.2.2. 2-step transaction 304 As illustrated in Figure 7, Node B SHOULD provide a candidate 305 CellList which can fulfill the requirements in the 6P Request 306 message, then Node A sends back the 6P Response message with a 307 selected CellList. If the number of cells in the selected CellList 308 is what Node B expects, Node B sends an RESV message to Node A 309 including an assigned label and without the 6P OPERATION object. The 310 error handling mechanism is the same as in the 3-step transaction 311 fashion. 313 Node A Node B 314 -------------- -------------- 315 | | FLOWSPEC: 316 | | bandwidth and 317 | | QoS requirements 318 | | 319 | | Map bandwidth and 320 | | QoS to cells 321 | 6P Request and | 322 | candidate CellList | timeout 323 |<--------------------------| --- 324 | | | 325 | 6P Response with | | 326 timeout | selected CellList | | 327 --- |-------------------------->| X 328 | | | 329 | | | 330 | | RESV | 331 X |<--------------------------|Cells reserved 332 Cells reserved| | 333 Label assigned| | 335 Figure 7: Operation of RESV message with 2-step transaction. 337 2.3. Reroute and Bandwidth Increase mechanism 339 Whenever the sender needs to establish a new tunnel that can maintain 340 resource reservations without double counting (at any particular 341 intermediate node) the resources with an existing tunnel, then the 342 "RSVP reroute mechanism" is initiated [RFC3209]. With this 343 operation, bandwidth can be increased or decreased end-to-end in the 344 tunnel. The detailed explanation of the reroute mechanism is 345 explained in [RFC3209]. 347 2.4. Error Codes 349 The detailed explanation of PathErr and ResvErr with different 350 ERROR_SPEC to handle Scheduling and 6P operation errors will be 351 described in later specification. 353 3. Message Format 354 3.1. RSVP-PATH message 356 The basic RSVP-PATH message [RFC2205] is used to carry the "Sender 357 Traffic Specification" along with "characterization parameters" from 358 sender to receiver. Since RSVP treats objects as opaque data, it is 359 permissible to use another protocol element (e.g. GMPLS, 6P, SF1) as 360 an object in a RSVP-PATH message. 362 The format of the PATH message that supports 6tisch scheduling 363 capabilities (6P and SF1) is as follows: 365 ::= [ ] 366 [ [ | ] ... ] 367 [ ] 368 369 370 [ ] 371 372 [ ] 373 [ <6P OPERATION REQUEST> ] 374 [ ] 375 [ ] 376 [ ] 377 [ ... ] 378 380 ::= 381 [ ] 382 [ ] 384 The format of the Generalized Label Request Object in PATH message 385 is: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Length | Class-Num (19)| C-Type (4) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | LSP Enc. Type |Switching Type | G-PID | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 The Generalized Label Request describes the requirement of 396 communication characteristics to support the 6TiSCH-LSP being 397 requested. The Generalized Label Request object is set by the 398 ingress node (6LR), transparently passed by transit nodes, and used 399 by the egress node (6LR). 401 1. LSP Encoding Type (8 bits): Indicates the encoding of the LSP 402 being requested. 404 +---------+--------------+ 405 | Value | Type | 406 +---------+--------------+ 407 | TBD | Timeslot | 408 +---------+--------------+ 410 2. Switching Type (8 bits): Indicates the type of switching that 411 should be performed on a particular link. 413 +---------+-------------------------------------+ 414 | Value | Type | 415 +---------+-------------------------------------+ 416 | 100 |Time-Division-Multiplex (TDM) Capable| 417 +---------+-------------------------------------+ 419 3. G-PID (8 bits): An identifier of the payload carried by an LSP, 420 i.e., an identifier of the client layer of that LSP. 422 +---------+-----------------------+------------+ 423 | Value | Type | Technology | 424 +---------+-----------------------+------------+ 425 | TBD |Wireless PAN (802.15.4)| TSCH | 426 +---------+-----------------------+------------+ 428 "SF1 OPERATION REQUEST" and "6P OPERATION REQUEST" are added in the 429 PATH message to check for 6tisch scheduling capabilities within the 430 intermediate nodes from sender to receiver. The "Timeslot Switching 431 Capability" (TSC) is used as an implicit label to switch the cell at 432 intermediate nodes [RFC3473]. "LABEL_REQUEST" in path message should 433 be set to "Timeslot Switching Capability". If an intermediate node 434 does not support the TSC or "6P transactions" or "SF1 operation" then 435 it MUST send a "PathErr" message back to application. At the sender, 436 the combination of sender and receiver IP addresses and the 437 RPLInstanceID is mapped to a 16-bit identifier. The sender uses this 438 identifier as the Track ID, and encapsulates it in the 439 SENDER_TEMPLATE. 441 3.2. RSVP-RESV message 443 The basic RSVP-RESV messages [RFC2205] are transmitted upstream from 444 receiver to sender to provide resource reservation as well as label 445 distribution. In this specification, hop-by-hop scheduling is 446 extended to support both resource reservation and label distribution. 447 The current specification is only defined for unicast point-to-point 448 traffic flows, i.e., Fixed Filter (FF) reservation style. 450 The format of the RESV message that supports 6tisch scheduling 451 capabilities (6P and SF1) is as follows: 453 ::= [ ] 454 [ [ | ] ... ] 455 [ ] 456 457 458 [ <6P OPERATION> ] 459 [ ] [ ] 460 [ ] 461 [ ] 462 [ ... ] 463