idnits 2.17.1 draft-lijo-6lo-expiration-time-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2600 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) == Outdated reference: A later version (-07) exists of draft-brockners-inband-oam-data-02 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-03 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Lijo Thomas 3 Internet-Draft C-DAC 4 Intended status: Standards Track P. Akshay 5 Expires: September 14, 2017 Indian Institute of Science 6 Satish Anamalamudi 7 Huaiyin Institute of Technology 8 S.V.R.Anand 9 Malati Hegde 10 Indian Institute of Science 11 C. Perkins 12 Futurewei 13 March 13, 2017 15 Packet expiration time in 6LoWPAN Routing Header 16 draft-lijo-6lo-expiration-time-02 18 Abstract 20 This document specifies a new type to the 6LoWPAN Dispatch Page 1 for 21 carrying the expiration time of data packets within the 6LoWPAN 22 routing header. The expiration time is useful in making forwarding 23 and scheduling decisions for time critical IoT M2M applications that 24 need deterministic delay guarantees over constrained networks and 25 operate within time-synchronized networks. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 64 4. Deadline-6LoRH Description . . . . . . . . . . . . . . . . . 3 65 5. Deadline-6LoRH Format . . . . . . . . . . . . . . . . . . . . 4 66 6. Deadline-6LoRH in Three Network Scenarios . . . . . . . . . . 6 67 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non- 68 storing mode. . . . . . . . . . . . . . . . . . . . . . . 6 69 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 70 Technologies. . . . . . . . . . . . . . . . . . . . . . . 7 71 6.3. Scenario 3: Packet transmission across different DODAGs 72 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 10.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Low Power and Lossy Networks (LLNs) are likely to be employed for 84 implementing real time industrial applications that require end-to- 85 end delay guarantees [I-D.grossman-detnet-use-cases]. A 86 Deterministic Network typically requires that data packets generated 87 by the senders have to reach the receivers within strict time bounds. 88 Intermediate nodes use the expiration time information to make 89 appropriate packet forwarding and scheduling decisions to meet the 90 time bounds. 92 The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN 93 Routing Header (6LoRH), compression schemes for RPL routing (source 94 routing) operation [RFC6554], header compression of RPL Packet 95 Information [RFC6553], and IP-in-IP encapsulation. This document 96 specifies a new Deadline-6LoRH type to the 6LoWPAN Dispatch Page 1, 97 so that the expiration time of data packets can be included within 98 the 6LoWPAN routing header. In addition, this specification 99 specifies handling of the expiration time when packets traverse 100 through time-synchronized networks operating in different timezones 101 or distinct reference clocks. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 [RFC2119]. 110 3. 6LoRHE Generic Format 112 The generic header format of the 6LoRHE is specified in 113 [I-D.ietf-roll-routing-dispatch]. Figure 1 describes the 6LoRHE 114 generic format. 116 0 1 117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 119 |1|0|1| Length | Type | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 121 <-- Length --> 123 Figure 1: 6LoRHE format 125 1. Length: In Figure 1, Length of the 6LoRHE expressed in bytes, 126 excluding the first 2 bytes. This enables a node to skip a 127 6LoRHE that it does not support and/or cannot parse, for instance 128 if the Type is not recognized. 130 2. Type: Type of the 6LoRHE. 132 3. Length: variable 134 4. Deadline-6LoRH Description 136 The Deadline-6LoRH (see Figure 2) is an elective 6LoRH that provides 137 a compressed form of expiration time for an IPv6 datagram. Along 138 with the expiration timer, the header can include the packet 139 origination time, to enable a close estimate of the total delay 140 incurred by a packet. 142 The packet expiration time field contains the value of the packet 143 expiration time. The packet SHOULD be delivered to the Receiver 144 before this time. 146 packet_expiration_time = packet_origination_time + max_delay 148 All nodes within the network SHOULD process the Deadline-6LoRH in 149 order to support delay-sensitive deterministic applications. In this 150 specification, the packet origination time is represented in 151 microseconds or milliseconds according to a scaling parameter value 152 in the routing header. In the case of a time slotted synchronized 153 network where a global time is maintained in the units of slot 154 lengths of certain resolution, the origination time is converted from 155 the current time into microseconds or milliseconds. A 6tisch minimal 156 network [I-D.vilajosana-6tisch-minimal] is such a network, where the 157 slot duration is typically 10msec, and the global time is given as 158 ASN (Absolute Slot Number). 160 The delay experienced by packets in the network is a useful metric 161 for network diagnostics and performance monitoring. To support this 162 feature, the specification provides an optional packet Origination 163 Time field as part of the header which is initialized by the sender 164 using the current clock time of the outgoing network interface 165 through which the packet is forwarded. Whenever the packets crosses 166 over to a network using a different reference clock, the Origination 167 Time field is updated to represent the same Origination Time but 168 using the reference clock of the outgoing interface into the new 169 network. This is the same as the current time when the packet is 170 transmitted into the new network, minus the delay already experienced 171 by the packet, say 't'. In effect, to the newly entered network, the 172 packet will appear to have originated 't' time units earlier with 173 respect to the reference clock of the new network. 175 Origination Time in new network = current_time_in_new_network - 176 delay_already_experienced_in_previous_network(s) 178 5. Deadline-6LoRH Format 180 0 1 2 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |1|0|1| Length | 6LoRH Type |O|D| ER|ETL| OR| OTL |Rsv| EXP | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | ET (variable length) | OT(variable length)(optional) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 2: Deadline-6LoRH format 190 Length (5 bits): Length represents the total length of the Expiration 191 Time type measured in octets. 193 6LoRH Type: TBD 194 O flag (1bit): Indicates the presence of Origination Time field. '1' 195 means the Origination Time is present, and '0' means it is absent. 197 D flag (1 bit): The 'D' flag, set by the Sender, indicates the action 198 that needs to be taken when an 6LR detects expiration time is 199 elapsed. If 'D' bit is 1, then the 6LR SHOULD drop the packet if the 200 expiration time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore 201 the Expiration Time and forward it. 203 ER (2 bits) Indicates time units for packet expiration time field: 205 00 : Expiration time represented in microseconds 206 01 : Expiration time represented in milliseconds 207 10 : Expiration time represented in seconds 208 11 : User defined 210 ETL (3 bits): Length of Expiration Time field. 212 For example, if the expiration time is represented in microseconds 213 ETL = 000 means the expiration time in the 6LoRHE is 1 octet (8 bits) 214 long. Similarly, Length = 111 means the expiration time is 8 octets 215 (64 bits) long. 217 OR (2 bits) : Indicates time units for Packet Origination Time: 219 00 : Expiration time represented in microseconds 220 01 : Expiration time represented in milliseconds 221 10 : Expiration time represented in seconds 222 11 : User defined 224 OTL (3 bits) : Length of Origination Time field. 226 Rsv (2 bits) : Reserved 228 EXP (3 bits) : Multiplication factor expressed as exponent of 2. 230 The value of the ET field is multiplied by 2 to this power, to get 231 the actual expiration time in the units represented by ER. The 232 default value of EXP is 000, so that the ET field is unaffected. 234 ET Value (0..64-bit) : Expiration Time value 236 OT Value (0..64-bit) : Origination Time value 238 Whenever the Sender initiates the IP datagram, it includes the 239 Deadline-6LoRH along with other 6LoRH information. 241 Example: consider a 6TiSCH network with time-slot length of 10ms. 242 Let the current ASN when the packet is originated be 200, and the 243 maximum allowable delay (max_delay) for the packet delivery is 1 244 second from the packet origination, then: 246 expiration_time = packet_origination_time + max_delay 248 = 200*10ms + 1 second 249 = 3 * 10^6 microseconds 251 This expiration time requires 22 bits in the worst case, or 3 octets. 252 Better compression can be achieved by using a combination of OR and 253 EXP bit fields. 255 6. Deadline-6LoRH in Three Network Scenarios 257 In this section, Deadline-6LoRH operation is described for 3 network 258 scenarios. Figure 3 depicts a constrained time-synchronized LLN that 259 has two subnets N1 and N2, connected through LBRs 260 [I-D.ietf-6lo-backbone-router] with different reference clock times 261 T1 and T2. 263 +-------------------+ 264 | Time Synchronized | 265 | Network | 266 +---------+---------+ 267 | 268 | 269 | 270 +--------------+--------------+ 271 | | 272 +-----+ +-----+ 273 | | Backbone | | Backbone 274 o | | router | | router 275 +-----+ +-----+ 276 o o o 277 o o o o o o o o o 278 o LLN o o LLN o o 279 o o o o o o o o o 280 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 282 Figure 3: Intra-network Timezone Scenario 284 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode. 286 In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram 287 to be routed to a Receiver 'R' within the same DODAG. For the route 288 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRH by 289 encoding the expiration time contained in the inband-OAM header 290 extension. Then 6LR begins hop-by-hop operation to forward the 291 packet towards the 6LBR. Once 6LBR receives the IP datagram, it 292 generates a IPv6-in-IPv6 encapsulated packet when sending the packet 293 downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR 294 copies the Deadline-6LoRH from the Sender originated IP header to the 295 outer IP header. The Deadline-6LoRH contained in the inner IP header 296 is elided. 298 +-------+ 299 ^ | 6LBR | | 300 | | | | 301 | +-------+ | 302 Default | (F)/ /| \ | IP-in-IP 303 routing | / \ / | \ | Encapsulation 304 | / \ (C) | (D) | 305 | (A) (B) / | / |\ | 306 | /|\ |\: (E) : R | 307 S : : : / \ V 309 Figure 4: End points within same DODAG(subnet N1) 311 At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Deadline- 312 6LoRH is copied back from the outer header to inner header, and the 313 inner IP packet is delivered to 'R'. 315 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 317 In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG 318 1) has IP datagram to be routed to a Receiver 'R' over a time- 319 synchronized IPv6 network. For the route segment from 'S' to 6LBR, 320 'S' includes a Deadline-6LoRH. Subsequently, 6LR will perform hop- 321 by-hop operation to forward the packet towards the 6LBR. Once the IP 322 datagram reaches 6LBR of DODAG1, it encodes the expiration time (and, 323 if available, the origination time) into the In-band OAM header 324 extension, [I-D.brockners-inband-oam-data] and passes the datagram to 325 the IPv6 layer for further routing. 327 +----------------+ 328 | Time | 329 | synchronized |------R 330 | Network | 331 +----------------+ 332 | 333 | 334 ----------+----------- 335 ^ | 336 | +---+---+ 337 | | 6LBR | 338 Default | | | 339 routing | +------++ 340 | (F)/ /| \ 341 | / \ / | \ 342 | / \ (C) | (D) 343 : (A) (B) / | / |\ 344 /|\ |\: (E) : 345 S : : : / \ 346 : : 348 Figure 5: Packet transmission in Dissimilar L2 Technologies or 349 Internet 351 The IP datagram is routed to another time synchronized deterministic 352 network following its own distinct reference clock, so the expiration 353 time in In-band OAM has to be updated according to the measurement of 354 the current time in the new network. 356 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to 357 N2). 359 Consider the scenario depicted in Figure 6, in which the Sender 'S' 360 (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' 361 belonging to another DODAG (DODAG 2). The operation of this scenario 362 can be decomposed into combination of case 1 and case 2 scenarios. 363 For the route segment from 'S' to 6LBR, 'S' includes the Deadline- 364 6LoRH. Subsequently, each 6LR will perform hop-by-hop operation to 365 forward the packet towards the 6LBR. Once the IP datagram reaches 366 6LBR1 of DODAG1, it applies the same rule as described in Case 2 367 while routing the packet to LBR2 over a (likely) time synchronized 368 wired backhaul. The wired side of LBR2 can be mapped to receiver of 369 Case 2. Once the packet reaches LBR2, it updates the Deadline-6LoRH 370 by adding the current time of DODAG2. Further, it generates an IPv6- 371 in-IPv6 encapsulated packet when sending the packet downstream to the 372 Receiver [I-D.ietf-roll-useofrplinfo]. 374 Time Synchronized Network 375 -+---------------------------+- 376 | | 377 DODAG1 +---+---+ +---+---+ DODAG2 378 Instance 1 | 6LBR1 | | 6LBR2 | Instance 2 379 | | | | | 380 +-------+ +-------+ | 381 (F)/ /| \ (F)/ /| \ | 382 / \ / | \ / \ / | \ | 383 / \ (C) | (D) / \ (C) | (D) |IP-in-IP 384 (A) (B) / | / |\ (A) (B) / | / |\ | Encapsulation 385 /|\ |\: (E) : : /|\ |\: (E) : :| 386 S : : : / \ : : : : / \ | 387 : : : R V 388 Network N1, time zone T1 NetWork N2, time zone T2 390 Figure 6: Packet transmission in different DODAGs(N1 to N2) 392 Consider an example of a 6TiSCH network in which S in DODAG1 393 generates the packet at ASN 200 to R in DODAG2. Let the maximum 394 allowable delay be 1 second. The time-slot length in DODAG1 and 395 DODAG2 is assumed to be 10ms. Once the expiration time is encoded in 396 Deadline-6LoRH, the packet is forwarded to LBR of DODAG1. Suppose 397 the packet reaches LBR of DODAG1 at ASN 250. 399 current_time = ASN at LBR * slot_length_value 401 remaining_time = expiration_time - current_time 403 = ((packet_origination_time + max_delay) - current time) 405 = (200*10 ms + 1 second) - 2.5 seconds 406 = 0.5 second 407 = 5 * 10^5 microseconds. 409 The remaining time is encoded in In-Band OAM (see Case 2) and 410 forwarded to LBR2 over a different L2-interface, typically wired. 411 Once the packet reaches LBR2, the expiration time in Deadline-6LoRH 412 is adjusted by adding or subtracting the difference between the 413 reference clocks of the two networks, before forwarding the packet to 414 its connected 6TiSCH network. 416 7. IANA Considerations 418 This document defines a new 6LoWPAN Timestamp Header Type, and 419 assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space. 421 6LoRH Type Value 422 +------------------+--------+ 423 | Deadline-6LoRH | TBD | 424 +------------------+--------+ 426 Figure 7: Deadline-6LoRH type 428 8. Security Considerations 430 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 431 apply. Using a compressed format as opposed to the full in-line 432 format is logically equivalent and does not create an opening for a 433 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 435 9. Acknowledgements 437 The authors thank Pascal Thubert for suggesting the idea and 438 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 439 were instrumental in extending the timing information to 440 heterogeneous networks. The authors acknowledge the 6TiSCH WG 441 members for their inputs on the mailing list. Special thanks to 442 Jerry Daniel,Shalu Rajendran, Seema Kumar, Avinash Mohan and Anita 443 Varghese for their support and valuable feedback. 445 10. References 447 10.1. Normative References 449 [I-D.ietf-roll-routing-dispatch] 450 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 451 "6LoWPAN Routing Header", draft-ietf-roll-routing- 452 dispatch-05 (work in progress), October 2016. 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, 456 DOI 10.17487/RFC2119, March 1997, 457 . 459 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 460 "Transmission of IPv6 Packets over IEEE 802.15.4 461 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 462 . 464 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 465 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 466 DOI 10.17487/RFC6282, September 2011, 467 . 469 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 470 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 471 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 472 Low-Power and Lossy Networks", RFC 6550, 473 DOI 10.17487/RFC6550, March 2012, 474 . 476 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 477 Power and Lossy Networks (RPL) Option for Carrying RPL 478 Information in Data-Plane Datagrams", RFC 6553, 479 DOI 10.17487/RFC6553, March 2012, 480 . 482 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 483 Routing Header for Source Routes with the Routing Protocol 484 for Low-Power and Lossy Networks (RPL)", RFC 6554, 485 DOI 10.17487/RFC6554, March 2012, 486 . 488 10.2. Informative References 490 [I-D.brockners-inband-oam-data] 491 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 492 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 493 P., and R. <>, "Data Formats for In-situ OAM", draft- 494 brockners-inband-oam-data-02 (work in progress), October 495 2016. 497 [I-D.grossman-detnet-use-cases] 498 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 499 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y. 500 Zha, "Deterministic Networking Use Cases", draft-grossman- 501 detnet-use-cases-01 (work in progress), November 2015. 503 [I-D.ietf-6lo-backbone-router] 504 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 505 backbone-router-03 (work in progress), January 2017. 507 [I-D.ietf-roll-useofrplinfo] 508 Robles, I., Richardson, M., and P. Thubert, "When to use 509 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 510 useofrplinfo-11 (work in progress), March 2017. 512 [I-D.vilajosana-6tisch-minimal] 513 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 514 Configuration", draft-vilajosana-6tisch-minimal-00 (work 515 in progress), October 2013. 517 Authors' Addresses 519 Lijo Thomas 520 C-DAC 521 Trivandrum 695033 522 India 524 Email: lijo@cdac.in 526 P.M. Akshay 527 Indian Institute of Science 528 Bangalore 560012 529 India 531 Email: akshaypm@ece.iisc.ernet.in 533 Satish Anamalamudi 534 Huaiyin Institute of Technology 535 No.89 North Beijing Road, Qinghe District 536 Huaian 537 China 539 Email: satishnaidu80@gmail.com 541 S.V.R Anand 542 Indian Institute of Science 543 Bangalore 560012 544 India 546 Email: anand@ece.iisc.ernet.in 548 Malati Hegde 549 Indian Institute of Science 550 Bangalore 560012 551 India 553 Email: malati@ece.iisc.ernet.in 554 Charles E. Perkins 555 Futurewei 556 2330 Central Expressway 557 Santa Clara 95050 558 Unites States 560 Email: charliep@computer.org