idnits 2.17.1 draft-lijo-6lo-expiration-time-00.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 10 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-roll-routing-dispatch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2731 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-01 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-02 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-09 Summary: 1 error (**), 0 flaws (~~), 5 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: May 1, 2017 Indian Institute of Science 6 Satish Anamalamudi 7 Individual Contributor 8 S.V.R.Anand 9 Malati Hegde 10 Indian Institute of Science 11 C. Perkins 12 Futurewei 13 October 28, 2016 15 Packet expiration time in 6LoWPAN Routing Header 16 draft-lijo-6lo-expiration-time-00 18 Abstract 20 [I-D.ietf-roll-routing-dispatch] for carrying the expiration time of 21 data packets within the 6LoWPAN routing header. The expiration time 22 is useful in making forwarding and scheduling decisions for time 23 critical IoT M2M applications that need deterministic delay 24 guarantees over constrained networks and operate within time- 25 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 May 1, 2017. 44 Copyright Notice 46 Copyright (c) 2016 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. 6LoRHC Header Format . . . . . . . . . . . . . . . . . . . . 3 64 4. Timestamp-6LoRH header . . . . . . . . . . . . . . . . . . . 3 65 5. Timestamp-6LoRH Header in Heterogeneous Network Scenarios . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Low Power and Lossy Networks (LLNs) could be employed for 77 implementing real time industrial applications that require end-to- 78 end delay guarantees [I-D.grossman-detnet-use-cases]. The 79 Deterministic Network requires that data packets generated by the 80 senders have to reach the receivers within strict time bounds. 81 Including an expiration time information in the packets enables 82 intermediate nodes to make appropriate packet forwarding and 83 scheduling decisions to meet this requirement. 85 The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN 86 Routing Header (6LoRH), compression schemes for RPL routing (source 87 routing) operation [RFC6554], header compression of RPI field 88 [RFC6553], and IP-in-IP encapsulation. This document specifies a new 89 Timestamp-6LoRH type to the 6LoWPAN Dispatch Page 1 for including the 90 expiration time of data packets within the 6LoWPAN routing header. 91 In addition, this specification specifies handling of the expiration 92 time when packets traverse through time-synchronized networks 93 operating in different timezones and distinct reference clocks. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in 100 [RFC2119]. 102 3. 6LoRHC Header Format 104 The generic header format of the 6LoRHC header is specified in 105 [I-D.ietf-roll-routing-dispatch]. Figure 1 describes the generic 106 header format for the 6LoRHC header. 108 0 1 109 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 111 |1|0|X| TSE | Type | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 113 <-- Length implied by Type/TSE --> 115 Figure 1: 6LoRHC header format 117 1. X bit: In Figure 1, if 'X' is 0 then it is a critical header. If 118 'X' is 1, then it is a elective header. 120 2. TSE: Type Specific Extension. The meaning depends on the Type, 121 which must be known to all the nodes. The interpretation of the 122 TSE depends on the Type field that follows. For instance, it may 123 be used to transport control bits, the number of elements in an 124 array, or the length of the remainder of 6LoRHC expressed in a 125 unit other than bytes. 127 3. Type: Type of the 6LoRHC. 129 4. Length: variable 131 4. Timestamp-6LoRH header 133 The Timestamp-6LoRH header (see Figure 2) is an elective 6LoRH header 134 that provides a compressed form of expiration time for an IPv6 135 datagram. All nodes within the network SHOULD support the Timestamp- 136 6LoRH header in order to support delay-sensitive deterministic 137 applications. In this specification, the packet origination time is 138 represented in microseconds. In the case of 6tisch networks which is 139 explained below, the origination time is the current ASN 140 [I-D.vilajosana-6tisch-minimal] converted into microseconds. 142 0 1 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- ... ...-+ 145 |1|0|1|D| Size |6LoRH Type TBD |Expiration time in microsec | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- .. .. -+ 148 Figure 2: Timestamp-6LoRH header format 150 D flag (1 bit): The 'D' flag, set by the Sender, indicates the action 151 that needs to be taken when an 6LR detects expiration time is 152 elapsed. If 'D' bit is 1, then the 6LR SHOULD drop the packet if the 153 expiration time is elapsed. If 'D' bit is 0, then the 6LR can choose 154 to ignore the expiration time and forward it. 156 Size (4 bits): Size represents the total length of expiration time 157 measured in octets. In this specification, the maximum length of the 158 expiration time is 8 octets (64 bits). 160 For example, Size = 0001 means the expiration time in the 6LoRHC 161 timestamp header is 1 octet (8 bits) long. Likewise, Size = 1000 162 means the expiration time in the 6LoRHC timestamp header is 8 octet 163 (64 bits) long. 165 6LoRH Type: In this specification, Type value for the Timestamp-6LoRH 166 is TBD. 168 Expiration time: This field describes the time limit before which the 169 packet SHOULD be delivered to the Receiver: 171 expiration_time = packet_origination_time + 172 max_allowable_transmission_delay. 174 Whenever the Sender initiates the IP datagram, it includes the 175 Timestamp-6LoRH header along with other 6LoRH routing header 176 information. The 6LoRH timestamp contains the expiration time as 177 given in the above expression. Since the maximum allowable 178 transmission delay is specific to each application, the expiration 179 time is of variable length. 181 Example: In a 6TiSCH network let the time-slot length be 10ms. If 182 the packet_origination_time = Current ASN is 200, and the 183 max_allowable_delay is 1 second, then: 185 expiration_time = packet_origination_time + max_allowable_delay 186 = 200*10ms + 1 second 187 = 3 * 10^6 microseconds 189 This expiration time requires 22 bits, or 3 octets, in length. The 190 Size is represented as x0011. 192 5. Timestamp-6LoRH Header in Heterogeneous Network Scenarios 194 In this section, Timestamp-6LoRH header operation is described for 3 195 different network scenarios. Figure 3 depicts a constrained time- 196 synchronized LLN that has two subnets N1 and N2, connected through 197 BBRs [I-D.ietf-6lo-backbone-router] with different reference clock 198 times T1 and T2. 200 +-------------------+ 201 | Time Synchronized | 202 | network | 203 +---------+---------+ 204 | 205 | 206 | 207 +--------------+--------------+ 208 | | 209 +-----+ +-----+ 210 | | Backbone | | Backbone 211 o | | router | | router 212 +-----+ +-----+ 213 o o o 214 o o o o o o o o o 215 o LLN o o LLN o o 216 o o o o o o o o o 218 6LoWPAN Network (N1 sub-net) 6LoWPAN Network (N2 sub-net) 220 Figure 3: Intra-network Timezone Scenario 222 Case 1: Endpoints in the same DODAG(N1 sub-net) in non-storing mode. 224 Let us consider the scenario, as shown in Figure 4, where the Sender 225 'S' has an IP datagram to be routed to a Receiver 'R' within the same 226 DODAG. For the route segment from Sender to 6LBR, the Sender 227 includes a Timestamp-6LoRH header. Subsequently, 6LR will perform 228 hop-by-hop operation to forward the packet towards the 6LBR. Once 229 the IP datagram reaches 6LBR, it generates IPv6-in-IPv6 encapsulated 230 packet when sending the packet downwards to the Receiver 231 [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the Timestamp-6LoRH 232 header from the Sender originated IP header to the outer IP header. 233 The Timestamp-6LoRH header contained in the inner IP header is 234 elided. 236 At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Timestamp- 237 6LoRH header is copied back from the outer header to inner header, 238 and the inner IP packet is handed over to 'R'. 240 +-------+ 241 ^ | 6LBR | | 242 | | | | 243 | +-------+ | 244 Default | (F)/ /| \ | IP-in-IP 245 routing | / \ / | \ | Encapsulation 246 | / \ (C) | (D) | 247 | (A) (B) / | / |\ | 248 | /|\ |\: (E) : R | 249 S : : : / \ V 251 Figure 4: End points within same DODAG(N1 sub-net) 253 Case 2: Packet transmission in Heterogeneous Deterministic Networks 254 (Heterogeneous L2 Technologies) 256 Let us consider the scenario, as shown in Figure 5, where the Sender 257 'S' (belonging to DODAG 1) has IP datagram to be routed to a Receiver 258 'R' over a time-synchronized IPv6 network. For the route segment 259 from 'S' to 6LBR, 'S' includes a Timestamp-6LoRH header. 261 +----------------+ 262 | Time | 263 | synchronized |------R 264 | network | 265 |----------------+ 266 | 267 | 268 ----------+----------- 269 ^ | 270 | +---+---+ 271 | | 6LBR | 272 Default | | | 273 routing | +-------+ 274 | (F)/ /| \ 275 | / \ / | \ 276 | / \ (C) | (D) 277 : (A) (B) / | / |\ 278 /|\ |\: (E) : 279 S : : : / \ 280 : : 282 Figure 5: Packet transmission in different Deterministic Networks or 283 Internet 285 Subsequently, 6LR will perform hop-by-hop operation to forward the 286 packet towards the 6LBR. Once the IP datagram reaches 6LBR of 287 DODAG1, it performs the following operation. It computes the 288 remaining time by subtracting the elapsed time from the expiration 289 time. The Timestamp-6LoRH header is updated with the remaining time. 290 This value can then be encoded into In-band OAM Edge to Edge option 291 [I-D.brockners-inband-oam-data] and handed over to IPv6 layer for 292 further routing. Since the IP datagram is routed to another time 293 synchronized deterministic network following its own distinct 294 reference clock, the expiration time in In-band OAM is updated by 295 adding the remaining time to the current time according to the time 296 synchronization of the network of the outgoing interface. 298 Case 3: Packet transmission across different DODAGs (N1 to N2) 300 Let us consider the scenario, as shown in Figure 6, where the Sender 301 'S' (belonging to DODAG 1) has an IP datagram to be sent to Receiver 302 'R' belonging to another DODAG (DODAG 2). For the route segment from 303 'S' to 6LBR, 'S' includes the Timestamp-6LoRH header. Subsequently, 304 each 6LR will perform hop-by-hop operation to forward the packet 305 towards the 6LBR. Once the IP datagram reaches 6LBR of DODAG1, it 306 performs the following operation. It computes the remaining time by 307 subtracting the elapsed time from the expiration time. The 308 expiration time in the Timestamp-6LoRH header is updated with the 309 remaining time. It will then forward the packet to 6LBR of DODAG2. 310 Once the IP datagram reaches 6LBR of DODAG2, it updates the 311 Timestamp-6LoRH header by adding the current time of DODAG2. 312 Further, it generates IPv6-in-IPv6 encapsulated packet when sending 313 the packet downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. 315 Time synchronized network 316 -+---------------------------+- 317 | | 318 DODAG1 +---+---+ +---+---+ DODAG2 319 Instance 1 | 6LBR | | 6LBR | Instance 2 320 | | | | | 321 +-------+ +-------+ | 322 (F)/ /| \ (F)/ /| \ | 323 / \ / | \ / \ / | \ | 324 / \ (C) | (D) / \ (C) | (D) |IP-in-IP 325 (A) (B) / | / |\ (A) (B) / | / |\ | Encapsulation 326 /|\ |\: (E) : : /|\ |\: (E) : :| 327 S : : : / \ : : : : / \ | 328 : : : R V 329 Network N1, time zone T1 NetWork N2, time zone T2 331 Figure 6: Packet transmission in different DODAGs(N1 to N2) 333 Let us consider an example of a 6TiSCH network where S in DODAG1 334 generates the packet at ASN 200 to R in DODAG2. Let the maximum 335 allowable delay be 1 second. The time-slot length in DODAG1 and 336 DODAG2 is assumed to be 10ms. Once the expiration time is encoded in 337 Timestamp-6LoRH header, the packet is forwarded to LBR of DODAG1. 338 Let us say the packet reaches LBR of DODAG1 at ASN 250. 340 current_time = ASN at LBR * slot_length_value. 342 remaining_time = expiration_time - current_time. 344 = ((packet_origination_time + max_allowable_transmission_delay) - 345 current time) 347 = (200*10 ms + 1 second) - 2.5 seconds 348 = 0.5 second 349 = 5 * 10^5 microseconds. 351 The remaining time is encoded in In-Band OAM (see Case 2) and 352 forwarded to LBR2 over a different L2-interface, typically wired. 353 Once the packet reaches LBR2, the expiration time in Timestamp-6LoRH 354 header is re-calculated by adding to it the current ASN, before 355 forwarding the packet to its connected 6TiSCH network. 357 6. IANA Considerations 359 This document defines a new 6LoWPAN Timestamp Header Type, and 360 assigned a value of TBD from the 6LoWPAN Dispatch Page1 number space. 362 6LoRH Type Value 363 +------------------+--------+ 364 | Timestamp-6LoRH | TBD | 365 +------------------+--------+ 367 Figure 7: Timestamp-6LoRH header type 369 7. Security Considerations 371 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 372 apply. Using a compressed format as opposed to the full in-line 373 format is logically equivalent and does not create an opening for a 374 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 376 8. Acknowledgements 378 The authors thank Pascal Thubert for suggesting the idea and 379 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 380 were instrumental in extending the timing information to 381 heterogeneous networks. The authors acknowledge the 6TiSCH WG 382 members for their inputs on the mailing list. Special thanks to 383 Jerry Daniel J for his support and valuable feedback. 385 9. References 387 9.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 395 "Transmission of IPv6 Packets over IEEE 802.15.4 396 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 397 . 399 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 400 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 401 DOI 10.17487/RFC6282, September 2011, 402 . 404 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 405 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 406 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 407 Low-Power and Lossy Networks", RFC 6550, 408 DOI 10.17487/RFC6550, March 2012, 409 . 411 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 412 Power and Lossy Networks (RPL) Option for Carrying RPL 413 Information in Data-Plane Datagrams", RFC 6553, 414 DOI 10.17487/RFC6553, March 2012, 415 . 417 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 418 Routing Header for Source Routes with the Routing Protocol 419 for Low-Power and Lossy Networks (RPL)", RFC 6554, 420 DOI 10.17487/RFC6554, March 2012, 421 . 423 9.2. Informative References 425 [I-D.brockners-inband-oam-data] 426 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 427 Leddy, J., and S. Youell, "Data Formats for In-band OAM", 428 draft-brockners-inband-oam-data-01 (work in progress), 429 July 2016. 431 [I-D.grossman-detnet-use-cases] 432 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 433 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y. 434 Zha, "Deterministic Networking Use Cases", draft-grossman- 435 detnet-use-cases-01 (work in progress), November 2015. 437 [I-D.ietf-6lo-backbone-router] 438 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 439 backbone-router-02 (work in progress), September 2016. 441 [I-D.ietf-roll-routing-dispatch] 442 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 443 "6LoWPAN Routing Header", draft-ietf-roll-routing- 444 dispatch-05 (work in progress), October 2016. 446 [I-D.ietf-roll-useofrplinfo] 447 Robles, I., Richardson, M., and P. Thubert, "When to use 448 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 449 useofrplinfo-09 (work in progress), October 2016. 451 [I-D.vilajosana-6tisch-minimal] 452 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 453 Configuration", draft-vilajosana-6tisch-minimal-00 (work 454 in progress), October 2013. 456 Authors' Addresses 458 Lijo Thomas 459 C-DAC 460 Trivandrum 695033 461 India 463 Email: lijo@cdac.in 464 P.M. Akshay 465 Indian Institute of Science 466 Bangalore 560012 467 India 469 Email: akshaypm@ece.iisc.ernet.in 471 Satish Anamalamudi 472 Individual Contributor 474 Email: satishnaidu80@gmail.com 476 S.V.R Anand 477 Indian Institute of Science 478 Bangalore 560012 479 India 481 Email: anand@ece.iisc.ernet.in 483 Malati Hegde 484 Indian Institute of Science 485 Bangalore 560012 486 India 488 Email: malati@ece.iisc.ernet.in 490 Charles E. Perkins 491 Futurewei 492 2330 Central Expressway 493 Santa Clara 95050 494 Unites States 496 Email: charliep@computer.org