idnits 2.17.1 draft-bormann-coap-misc-11.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 (February 14, 2012) is 4452 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-03 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-18 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft K. Hartke 4 Intended status: Informational Universitaet Bremen TZI 5 Expires: August 17, 2012 February 14, 2012 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-11 10 Abstract 12 This short I-D makes a number of partially interrelated proposals how 13 to solve certain problems in the CoRE WG's main protocol, the 14 Constrained Application Protocol (CoAP). The current version has 15 been resubmitted to keep information about these proposals available; 16 the proposals are not all fleshed out at this point in time. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 17, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Getting rid of artificial limitations . . . . . . . . . . . . 4 54 2.1. Beyond 15 options . . . . . . . . . . . . . . . . . . . . 4 55 2.1.1. Implementation considerations . . . . . . . . . . . . 6 56 2.1.2. What should we do now? . . . . . . . . . . . . . . . . 7 57 2.1.3. Alternatives . . . . . . . . . . . . . . . . . . . . . 7 58 2.1.4. Alternative: Going to a delimiter model . . . . . . . 7 59 2.2. Beyond 270 bytes in a single option . . . . . . . . . . . 8 60 3. URI Authorities with Binary Adresses . . . . . . . . . . . . . 9 61 4. Vendor-defined Option . . . . . . . . . . . . . . . . . . . . 11 62 5. Payload-Length Option . . . . . . . . . . . . . . . . . . . . 12 63 6. Patience, Leisure, and Pledge . . . . . . . . . . . . . . . . 13 64 6.1. Patience . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6.2. Leisure . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.3. Pledge . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6.4. Option Formats . . . . . . . . . . . . . . . . . . . . . . 14 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 74 Appendix A. The Cemetery (Things we won't do) . . . . . . . . . . 21 75 A.1. Stateful URI compression . . . . . . . . . . . . . . . . . 21 76 Appendix B. Experimental Options . . . . . . . . . . . . . . . . 23 77 B.1. Options indicating absolute time . . . . . . . . . . . . . 23 78 B.2. Representing Durations . . . . . . . . . . . . . . . . . . 24 79 B.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 25 80 B.4. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 26 81 B.5. A Duration Type for CoAP . . . . . . . . . . . . . . . . . 27 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 84 1. Introduction 86 The CoRE WG is tasked with standardizing an Application Protocol for 87 Constrained Networks/Nodes, CoAP [I-D.ietf-core-coap]. This protocol 88 is intended to provide RESTful [REST] services not unlike HTTP 89 [RFC2616], while reducing the complexity of implementation as well as 90 the size of packets exchanged in order to make these services useful 91 in a highly constrained network of themselves highly constrained 92 nodes. 94 This objective requires restraint in a number of sometimes 95 conflicting ways: 97 o reducing implementation complexity in order to minimize code size, 99 o reducing message sizes in order to minimize the number of 100 fragments needed for each message (in turn to maximize the 101 probability of delivery of the message), the amount of 102 transmission power needed and the loading of the limited-bandwidth 103 channel, 105 o reducing requirements on the environment such as stable storage, 106 good sources of randomness or user interaction capabilities. 108 This draft attempts to address a number of problems not yet 109 adequately solved in [I-D.ietf-core-coap]. The solutions proposed to 110 these problems are somewhat interrelated and are therefore presented 111 in one draft. 113 The appendix contains the "CoAP cemetery" (possibly later to move 114 into its own draft), documenting roads that the WG decided not to 115 take, in order to spare readers from reinventing them in vain. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 The term "byte" is used in its now customary sense as a synonym for 122 "octet". 124 2. Getting rid of artificial limitations 126 _Artificial limitations_ are limitations of a protocol or system that 127 are not rooted in limitations of actual capabilities, but in 128 arbitrary design decisions. Proper system design tries to avoid 129 artificial limitations, as these tend to cause complexity in systems 130 that need to work with these limitations. 132 E.g., the original UNIX filesystem had an artificial limitation of 133 the length of a path name component to 14 bytes. This led to all 134 kinds of workarounds in programs that manipulate file names: E.g., 135 systematically replacing a ".el" extension in a filename with a 136 ".elc" for the compiled file might exceed the limit, so all ".el" 137 files were suddenly limited to 13-byte filenames. 139 Note that, today, there still is a limitation in most file system 140 implementations, typically at 255. This just happens to be high 141 enough to rarely be of real-world concern; we will refer to this case 142 as a "painless" artificial limitation. 144 CoAP-08 has two highly recognizable artificial limitations in its 145 protocol encoding 147 o The number of options in a single message is limited to 15 max. 149 o The length of an option is limited to 270 max. 151 It is arguable that the latter limitation causes few problems, just 152 as the 255-byte path name component limitation in filenames today 153 causes few problems. Just in case, Section 2.2 provides a design to 154 extend this. 156 2.1. Beyond 15 options 158 The limit of 15 options is motivated by the fixed four-bit field "OC" 159 that is used for indicating the number of options in the fixed-length 160 CoAP header (Figure 1). 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |Ver| T | OC | Code | Message ID | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Options (if any) ... 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Payload (if any) ... 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: Four-byte fixed header in a CoAP Message 173 Note that there is another fixed four-bit field in CoAP: the option 174 length (Figure 2 - note that this figure is not to the same scale as 175 the previous figure): 177 0 1 2 3 4 5 6 7 178 +---+---+---+---+---+---+---+---+ 179 | Option Delta | Length | for 0..14 180 +---+---+---+---+---+---+---+---+ 181 | Option Value ... 182 +---+---+---+---+---+---+---+---+ 184 Figure 2: Short Option Header 186 Since 15 is inacceptable for a maximum option length, the all-ones 187 value (15) was taken out of the set of allowable values for the short 188 header, and a long header was introduced that allows the insertion of 189 an extension byte (Figure 3): 191 for 15..270: 192 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 193 | Option Delta | 1 1 1 1 | Length - 15 | 194 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 195 | Option Value ... 196 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 198 Figure 3: Long Option Header 200 We might want to use the same technique for the CoAP header as well. 201 There are two obvious places where the extension byte could be 202 placed: 204 1. right after the byte carrying the OC field, so the structure is 205 the same as for the option header; 207 2. right after the fixed-size CoAP header. 209 Both solutions lose the fixed-size-ness of the CoAP header. 211 Solution 1 has the disadvantage that the CoAP header is also changing 212 in structure: The extension byte is wedged between the first and the 213 second byte of the CoAP header. This is unfortunate, as the number 214 of options only comes into play when the option processing begins, so 215 it is more natural to use solution 2 (Figure 4): 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 |Ver| T | 15 | Code | Message ID | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | OC - 15 | Options ... 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Payload (if any) ... 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 4: Extended header for CoAP Messages with 15+ options 229 This would allow for up to 270 options in a CoAP message, which is 230 very likely way beyond the "painless" threshold. 232 2.1.1. Implementation considerations 234 For a message decoder, this extension creates relatively little pain, 235 as the number of options only becomes interesting when the encoding 236 turns to the options part of the message, which is then simply lead 237 in by the extension byte if the four-bit field is 15. 239 For a message encoder, this extension is not so rosy. If the encoder 240 is constructing the message serially, it may not know in advance 241 whether the number of options will exceed 14. None of the following 242 implementation strategies is particularly savory, but all of them do 243 work: 245 1. Encode the options serially under the assumption that the number 246 of options will be 14 or less. When the 15th option needs to be 247 encoded, abort the option encoding, and restart it from scratch 248 one byte further to the left. 250 2. Similar to 1, except that the bytes already encoded are all moved 251 one byte to right, the extension byte is inserted, and the option 252 encoding process is continued. 254 3. The encoder always leaves space for the extension byte (at least 255 if it can't prove the number will be less thatn 14). If the 256 extension byte is not needed, an Option 0 with length 0 is 257 encoded instead (i.e., one byte is wasted - this option is 258 elective and will be ignored by the receiver). 260 As a minimum, to enable strategy 3, the option 0 should be reserved 261 at least for the case of length=0. 263 2.1.2. What should we do now? 265 As a minimum proposal for the next version of CoAP, the value 15 for 266 OC should be marked as reserved today. 268 2.1.3. Alternatives 270 One alternative that has been discussed previously is to have an 271 "Options" Option, which allows the carriage of multiple options in 272 the belly of a single one. This could also be used to carry more 273 than 15 options. However: 275 o The conditional introduction of an Options option has 276 implementation considerations that are likely to be more severe 277 than the ones listed above; 279 o since 270 bytes may not be enough for the encoding of _all_ 280 options, the "Options" option would need to be repeatable. This 281 creates many different ways to encode the same message, leading to 282 combinatorial explosion in test cases for ensuring 283 interoperability. 285 2.1.4. Alternative: Going to a delimiter model 287 Another alternative is to spend the additional byte not as an 288 extended count, but as an option terminator. 290 In this proposal setting OC to 15 means that the number of options is 291 no longer given explicitly. Instead, the sequence of options is 292 terminated by a byte with a special interpretation, 0xF0. (Note that 293 the option _delta_ of 15 is made special, not any specific option 294 number.) The next byte is then the first byte of the payload. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |Ver| T | 15 | Code | Message ID | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Options ... 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |1 1 1 1 0 0 0 0| Payload (if any) ... 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 5: Option Terminator for CoAP Messages with 15+ options 308 (It is to be decided whether 0xF0 is made special only for OC=15, 309 i.e. if it retains its usual meaning of (option delta = 15, option 310 length = 0) for other values of OC.) 312 2.2. Beyond 270 bytes in a single option 314 The authors would argue that 270 as the maximum length of an option 315 is already beyond the "painless" threshold. 317 If that is not the consensus of the WG, the scheme can easily be 318 extended as in Figure 6: 320 for 15..269: 321 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 322 | Option Delta | 1 1 1 1 | Length - 15 | 323 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 324 | Option Value ... 325 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 327 for 270..65805: 328 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 329 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 330 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 331 | Length - 270 (in network byte order) | 332 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 333 | Option Value ... 334 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 336 Figure 6: Ridiculously Long Option Header 338 The infinite number of obvious variations on this scheme are left as 339 an exercise to the reader. 341 Again, as a precaution to future extensions, the current encoding for 342 length 270 (eight ones in the extension byte) could be marked as 343 reserved today. 345 3. URI Authorities with Binary Adresses 347 One problem with the way URI authorities are represented in the URI 348 syntax is that the authority part can be very bulky if it encodes an 349 IPv6 address in ASCII. 351 Proposal: Provide an option "Uri-Authority-Binary" that can be an 352 even number of bytes between 2 and 18 except 12 or 14. 354 o If the number of bytes is 2, the destination IP address of the 355 packet transporting the CoAP message is implied. 357 o If the number of bytes is 4 or 6, the first four bytes of the 358 option value are an IPv4 address in binary. 360 o If the number of bytes is 8 or 10, the first eight bytes are the 361 lower 64 bits of an IPv6 address; the upper eight bytes are 362 implied from the destination address of the packet transporting 363 the CoAP message. 365 o If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 366 address. 368 o If two more bytes remain, this is a port number (as always in 369 network byte order). 371 The resulting authority is (conceptually translated into ASCII and) 372 used in place of an Uri-Authority option, or inserted into a Proxy- 373 Uri. Examples: 375 +-------------+------------------+---------+------------------------+ 376 | Proxy-Uri | Uri-Authority-Bi | Uri-Pat | URI | 377 | | nary | h | | 378 +-------------+------------------+---------+------------------------+ 379 | (none) | (none) | (none) | "/" | 380 | | | | | 381 | (none) | (none) | 'temp' | "/temp" | 382 | | | | | 383 | (none) | 2 bytes: 61616 | 'temp' | "coap://[DA]:61616/tem | 384 | | | | p" | 385 | | | | | 386 | (none) | 16 bytes: | temp | "coap://[2000::1]/temp | 387 | | 2000::1 | | " | 388 | | | | | 389 | 'http://' | 10 bytes: | (none) | "http://[DA::123:45]:6 | 390 | | ::123:45 + 616 | | 16" | 391 | | | | | 392 | 'http:///te | 18 bytes: | (none) | "http://[2000::1]:616/ | 393 | mp' | 2000::1 + 616 | | temp" | 394 +-------------+------------------+---------+------------------------+ 396 4. Vendor-defined Option 398 To enable experimentation and community-specific options, option 399 number 14 (the first NOP option) can also be used as a vendor-defined 400 option. For this application, the option value has one or more 401 bytes, the semantics of which are defined by prior agreement between 402 the communicating partners. 404 It is RECOMMENDED to start the option value with a unique identifier, 405 e.g., the SDNV [RFC5050] of the enterprise number of the organisation 406 defining the option, possibly followed by additional discriminating 407 bits or bytes as defined by the organisation. 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id| value... | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 \___SDNV of enterprise number___/ 414 Figure 7: Example option value for vendor-defined option 416 Note that a Vendor-defined Option cannot be empty, not only because 417 there would be no space for the SDNV, but in particular as the empty 418 option 14 is reserved for fenceposting ([I-D.ietf-core-coap], section 419 3.2). (Obviously, once a Vendor-defined Option is in use, there is 420 never a need for a fence-post for option number 14.) 422 Vendor-defined Options are elective. 424 The Vendor-defined Option is repeatable. 426 +-----+----------+--------+-------------+---------+---------+ 427 | No. | C/E | Name | Format | Length | Default | 428 +-----+----------+--------+-------------+---------+---------+ 429 | 14 | Elective | Vendor | (see below) | 1-270 B | (empty) | 430 +-----+----------+--------+-------------+---------+---------+ 432 5. Payload-Length Option 434 Not all transport mappings may provide an unambiguous length of the 435 CoAP message. For UDP, it may also be desirable to pack more than 436 one CoAP message into one UDP payload (aggregation); in that case, 437 for all but the last message there needs to be a way to delimit the 438 payload of that message. 440 This can be solved using a new option, the Payload-Length option. If 441 this option is present, the value of this option is an unsigned 442 integer giving the length of the payload of the message (note that 443 this integer can be zero for a zero-length payload, which can in turn 444 be represented by a zero-length option value). (In the UDP 445 aggregation case, what would have been in the payload of this message 446 after "payload-length" bytes is then actually one or more additional 447 messages.) 449 6. Patience, Leisure, and Pledge 451 A number of options might be useful for controlling the timing of 452 interactions. 454 6.1. Patience 456 A client may have a limited time period in which it can actually make 457 use of the response for a request. Using the Patience option, it can 458 provide an (elective) indication how much time it is willing to wait 459 for the response from the server, giving the server license to ignore 460 or reject the request if it cannot fulfill it in this period. 462 If the server knows early that it cannot fulfill the request in the 463 time requested, it MAY indicate this with a 5.04 "Timeout" response. 464 For non-safe methods (such as PUT, POST, DELETE), the server SHOULD 465 indicate whether it has fulfilled the request by either responding 466 with 5.04 "Timeout" (and not further processing the request) or by 467 processing the request normally. 469 Note that the value of the Patience option should be chosen such that 470 the client will be able to make use of the result even in the 471 presence of the expected network delays for the request and the 472 response. Similarly, when a proxy receives a request with a Patience 473 option and cannot fulfill that request from its cache, it may want to 474 adjust the value of the option before forwarding it to an upstream 475 server. 477 (TBD: The various cases that arise when combining Patience with 478 Observe.) 480 The Patience option is elective. Hence, a client MUST be prepared to 481 receive a normal response even after the chosen Patience period (plus 482 an allowance for network delays) has elapsed. 484 6.2. Leisure 486 Servers generally will compute an internal value that we will call 487 Leisure, which indicates the period of time that will be used for 488 responding to a request. A Patience option, if present, can be used 489 as an upper bound for the Leisure. Leisure may be non-zero for 490 congestion control reasons, in particular for responses to multicast 491 requests. For these, the server should have a group size estimate G, 492 a target rate R (which both should be chosen conservatively) and an 493 estimated response size S; a rough lower bound for Leisure can then 494 be computed as follows: 496 lb_Leisure = S * G / R 498 Figure 8 500 E.g., for a multicast request with link-local scope on an 2.4 GHz 501 IEEE 802.15.4 (6LoWPAN) network, G could be (relatively 502 conservatively) set to 100, S to 100 bytes, and the target rate to 8 503 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is 10 504 seconds. 506 To avoid response implosion, responses to multicast requests SHOULD 507 be dithered within a Leisure period chosen by the server to fall 508 between these two bounds. 510 Currently, we don't foresee a need to signal a value for Leisure from 511 client to server (beyond the signalling provided by Patience) or from 512 server to client, but an appropriate Option might be added later. 514 6.3. Pledge 516 In a basic observation relationship [I-D.ietf-core-observe], the 517 server makes a pledge to keep the client in the observation 518 relationship for a resource at least until the max-age for the 519 resource is reached. 521 To save the client some effort in re-establishing observation 522 relationships each time max-age is reached, the server MAY want to 523 extend its pledge beyond the end of max-age by signalling in a 524 response/notification an additional time period using the Pledge 525 Option, in parallel to the Observe Option. 527 The Pledge Option MUST NOT be used unless the server can make a 528 reasonable promise not to lose the observation relationship in this 529 time frame. 531 Currently, we don't foresee a need to signal a value for Pledge from 532 client to server, but an appropriate behavior might be added later 533 for this option when sent in a request. 535 6.4. Option Formats 537 +-----+----------+----------+-----------------+--------+---------+ 538 | No. | C/E | Name | Format | Length | Default | 539 +-----+----------+----------+-----------------+--------+---------+ 540 | 22 | Elective | Patience | Duration in mis | 1 B | (none) | 541 | | | | | | | 542 | 24 | Elective | Pledge | Duration in s | 1 B | 0 | 543 +-----+----------+----------+-----------------+--------+---------+ 545 All timing options use the Duration data type (see Appendix B.2), 546 however Patience (and Leisure, if that ever becomes an option) uses a 547 timebase of mibiseconds (mis = 1/1024 s) instead of seconds. (This 548 reduces the range of the Duration from ~ 91 days to 128 minutes.) 550 None of the options may be repeated. 552 7. IANA Considerations 554 This draft adds option numbers to Table 2 of [I-D.ietf-core-coap], 555 resulting in: 557 TBD. 559 8. Security Considerations 561 TBD. 563 9. Acknowledgements 565 This work was partially funded by the Klaus Tschira Foundation. 567 Of course, much of the content of this draft is the result of 568 discussions with the [I-D.ietf-core-coap] authors. 570 10. References 572 10.1. Normative References 574 [I-D.ietf-core-coap] 575 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 576 "Constrained Application Protocol (CoAP)", 577 draft-ietf-core-coap-08 (work in progress), October 2011. 579 [I-D.ietf-core-observe] 580 Hartke, K. and Z. Shelby, "Observing Resources in CoAP", 581 draft-ietf-core-observe-03 (work in progress), 582 October 2011. 584 [I-D.ietf-httpbis-p1-messaging] 585 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 586 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 587 J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and 588 Message Parsing", draft-ietf-httpbis-p1-messaging-18 (work 589 in progress), January 2012. 591 [I-D.ietf-httpbis-p4-conditional] 592 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 593 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 594 J. Reschke, "HTTP/1.1, part 4: Conditional Requests", 595 draft-ietf-httpbis-p4-conditional-18 (work in progress), 596 January 2012. 598 [I-D.ietf-httpbis-p6-cache] 599 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 600 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 601 Nottingham, M., and J. Reschke, "HTTP/1.1, part 6: 602 Caching", draft-ietf-httpbis-p6-cache-18 (work in 603 progress), January 2012. 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, March 1997. 608 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 609 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 610 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 612 10.2. Informative References 614 [REST] Fielding, R., "Architectural Styles and the Design of 615 Network-based Software Architectures", 2000. 617 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 618 Specification", RFC 5050, November 2007. 620 Appendix A. The Cemetery (Things we won't do) 622 This annex documents roads that the WG decided not to take, in order 623 to spare readers from reinventing them in vain. 625 A.1. Stateful URI compression 627 Is the approximately 25 % average saving achievable with Huffman- 628 based URI compression schemes worth the complexity? Probably not, 629 because much higher average savings can be achieved by introducing 630 state. 632 Henning Schulzrinne has proposed for a server to be able to supply a 633 shortened URI once a resource has been requested using the full- 634 length URI. Let's call such a shortened referent a _Temporary 635 Resource Identifier_, _TeRI_ for short. This could be expressed by a 636 response option as shown in Figure 9. 638 0 639 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | duration | TeRI... 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 9: Option for offering a TeRI in a response 646 The TeRI offer option indicates that the server promises to offer 647 this resources under the TeRI given for at least the time given as 648 the duration. Another TeRI offer can be made later to extend the 649 duration. 651 Once a TeRI for a URI is known (and still within its lifetime), the 652 client can supply a TeRI instead of a URI in its requests. The same 653 option format as an offer could be used to allow the client to 654 indicate how long it believes the TeRI will still be valid (so that 655 the server can decide when to update the lifetime duration). TeRIs 656 in requests could be distinguished from URIs e.g. by using a 657 different option number. 659 Proposal: Add a TeRI option that can be used in CoAP requests and 660 responses. 662 Add a way to indicate a TeRI and its duration in a link-value. 664 Do not add any form of stateless URI encoding. 666 Benefits: Much higher reduction of message size than any stateless 667 URI encoding could achieve. 669 As the use of TeRIs is entirely optional, minimal complexity nodes 670 can get by without implementing them. 672 Drawbacks: Adds considerable state and complexity to the protocol. 674 It turns out that real CoAP URIs are short enough that TeRIs are 675 not needed. 677 (Discuss the security implications of TeRIs.) 679 Appendix B. Experimental Options 681 This annex documents proposals that need significant additional 682 discussion before they can become part of (or go back to) the main 683 CoAP specification. They are not dead, but might die if there turns 684 out to be no good way to solve the problem. 686 B.1. Options indicating absolute time 688 HTTP has a number of headers that may indicate absolute time: 690 o "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in 691 [I-D.ietf-httpbis-p1-messaging]), giving the absolute time a 692 response was generated; 694 o "Last-Modified", defined in Section 14.29 in [RFC2616], (Section 695 6.6 in [I-D.ietf-httpbis-p4-conditional], giving the absolute time 696 of when the origin server believes the resource representation was 697 last modified; 699 o "If-Modified-Since", defined in Section 14.25 in [RFC2616], 700 "If-Unmodified-Since", defined in Section 14.28 in [RFC2616], and 701 "If-Range", defined in Section 14.27 in [RFC2616] can be used to 702 supply absolute time to gate a conditional request; 704 o "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in 705 [I-D.ietf-httpbis-p6-cache]), giving the absolute time after which 706 a response is considered stale. 708 o The more obscure headers "Retry-After", defined in Section 14.37 709 in [RFC2616], and "Warning", defined in section 14.46 in 710 [RFC2616], also may employ absolute time. 712 [I-D.ietf-core-coap] defines a single "Date" option, which however 713 "indicates the creation time and date of a given resource 714 representation", i.e., is closer to a "Last-Modified" HTTP header. 715 HTTP's caching rules [I-D.ietf-httpbis-p6-cache] make use of both 716 "Date" and "Last-Modified", combined with "Expires". The specific 717 semantics required for CoAP needs further consideration. 719 In addition to the definition of the semantics, an encoding for 720 absolute times needs to be specified. 722 In UNIX-related systems, it is customary to indicate absolute time as 723 an integer number of seconds, after midnight UTC, January 1, 1970. 724 Unless negative numbers are employed, this time format cannot 725 represent time values prior to January 1, 1970, which probably is not 726 required for the uses ob absolute time in CoAP. 728 If a 32-bit integer is used and allowance is made for a sign-bit in a 729 local implementation, the latest UTC time value that can be 730 represented by the resulting 31 bit integer value is 03:14:07 on 731 January 19, 2038. If the 32-bit integer is used as an unsigned 732 value, the last date is 2106-02-07, 06:28:15. 734 The reach can be extended by: - moving the epoch forward, e.g. by 40 735 years (= 1262304000 seconds) to 2010-01-01. This makes it impossible 736 to represent Last-Modified times in that past (such as could be 737 gatewayed in from HTTP). - extending the number of bits, e.g. by one 738 more byte, either always or as one of two formats, keeping the 32-bit 739 variant as well. 741 Also, the resolution can be extended by expressing time in 742 milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned 743 integer of milliseconds would last well after year 9999.) 745 For experiments, an experimental "Date" option is defined with the 746 semantics of HTTP's "Last-Modified". It can carry an unsigned 747 integer of 32, 40, or 48 bits; 32- and 40-bit integers indicate the 748 absolute time in seconds since 1970-01-01 00:00 UTC, while 48-bit 749 integers indicate the absolute time in milliseconds since 1970-01-01 750 00:00 UTC. 752 However, that option is not really that useful until there is a 753 "If-Modified-Since" option as well. 755 (Also: Discuss nodes without clocks.) 757 B.2. Representing Durations 759 Various message types used in CoAP need the representation of 760 *durations*, i.e. of the length of a timespan. In SI units, these 761 are measured in seconds. CoAP durations represent integer numbers of 762 seconds, but instead of representing these numbers as integers, a 763 more compact single-byte pseudo-floating-point (pseudo-FP) 764 representation is used (Figure 10). 766 0 1 2 3 4 5 6 7 767 +---+---+---+---+---+---+---+---+ 768 | 0... value | 769 +---+---+---+---+---+---+---+---+ 771 +---+---+---+---+---+---+---+---+ 772 | 1... mantissa | exponent | 773 +---+---+---+---+---+---+---+---+ 774 Figure 10: Duration in (8,4) pseudo-FP representation 776 If the high bit is clear, the entire n-bit value (including the high 777 bit) is the decoded value. If the high bit is set, the mantissa 778 (including the high bit, with the exponent field cleared out but 779 still present) is shifted left by the exponent to yield the decoded 780 value. 782 The (n,e)-pseudo-FP format can be decoded with a single line of code 783 (plus a couple of constant definitions), as demonstrated in 784 Figure 11. 786 #define N 8 787 #define E 4 788 #define HIBIT (1 << (N - 1)) 789 #define EMASK ((1 << E) - 1) 790 #define MMASK ((1 << N) - 1 - EMASK) 792 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 794 Figure 11: Decoding an (8,4) pseudo-FP value 796 Note that a pseudo-FP encoder needs to consider rounding; different 797 applications of durations may favor rounding up or rounding down the 798 value encoded in the message. 800 The highest pseudo-FP value, represented by an all-ones byte (0xFF), 801 is reserved to indicate an indefinite duration. The next lower value 802 (0xEF) is thus the highest representable value and is decoded as 803 7340032 seconds, a little more than 12 weeks. 805 B.3. Rationale 807 Where CPU power and memory is abundant, a duration can almost always 808 be adequately represented by a non-negative floating-point number 809 representing that number of seconds. Historically, many APIs have 810 also used an integer representation, which limits both the resolution 811 (e.g., if the integer represents the duration in seconds) and often 812 the range (integer machine types have range limits that may become 813 relevant). UNIX's "time_t" (which is used for both absolute time and 814 durations) originally was a signed 32-bit value of seconds, but was 815 later complemented by an additional integer to add microsecond 816 ("struct timeval") and then later nanosecond ("struct timespec") 817 resolution. 819 Three decisions need to be made for each application of the concept 820 of duration: 822 o the *resolution*. What rounding error is acceptable? 824 o the *range*. What is the maximum duration that needs to be 825 represented? 827 o the *number of bits* that can be expended. 829 Obviously, these decisions are interrelated. Typically, a large 830 range needs a large number of bits, unless resolution is traded. For 831 most applications, the actual requirement for resolution are limited 832 for longer durations, but can be more acute for shorter durations. 834 B.4. Pseudo-Floating Point 836 Constrained systems typically avoid the use of floating-point (FP) 837 values, as 839 o simple CPUs often don't have support for floating-point datatypes 841 o software floating-point libraries are expensive in code size and 842 slow. 844 In addition, floating-point datatypes used to be a significant 845 element of market differentiation in CPU design; it has taken the 846 industry a long time to agree on a standard floating point 847 representation. 849 These issues have led to protocols that try to constrain themselves 850 to integer representation even where the ability of a floating point 851 representation to trade range for resolution would be beneficial. 853 The idea of introducing _pseudo-FP_ is to obtain the increased range 854 provided by embedding an exponent, without necessarily getting stuck 855 with hardware datatypes or inefficient software floating-point 856 libraries. 858 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 859 fixed-length value of n bits, e of which may be used for an exponent. 860 Figure 10 illustrates an (8,4)-pseudo-FP value. 862 If the high bit is clear, the entire n-bit value (including the high 863 bit) is the decoded value. If the high bit is set, the mantissa 864 (including the high bit, but with the exponent field cleared out) is 865 shifted left by the exponent to yield the decoded value. 867 The (n,e)-pseudo-FP format can be decoded with a single line of code 868 (plus a couple of constant definition), as demonstrated in Figure 11. 870 Only non-negative numbers can be represented by this format. It is 871 designed to provide full integer resolution for values from 0 to 872 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 873 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 874 (8,4) case. By choosing e carefully, resolution can be traded 875 against range. 877 Note that a pseudo-FP encoder needs to consider rounding; different 878 applications of durations may favor rounding up or rounding down the 879 value encoded in the message. This requires a little more than a 880 single line of code (which is left as an exercise to the reader, as 881 the most efficient expression depends on hardware details). 883 B.5. A Duration Type for CoAP 885 CoAP needs durations in a number of places. In [I-D.ietf-core-coap], 886 durations occur in the option "Subscription-lifetime" as well as in 887 the option "Max-age". (Note that the option "Date" is not a 888 duration, but a point in time.) Other durations of this kind may be 889 added later. 891 Most durations relevant to CoAP are best expressed with a minimum 892 resolution of one second. More detailed resolutions are unlikely to 893 provide much benefit. 895 The range of lifetimes and caching ages are probably best kept below 896 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 897 value of 7864320, which is about 91 days; this appears to be adequate 898 for a subscription lifetime and probably even for a maximum cache 899 age. Figure 12 shows the values that can be expressed. (If a larger 900 range for the latter is indeed desired, an (8,5)-pseudo-FP could be 901 used; this would last 15 milleniums, at the cost of having only 3 902 bits of accuracy for values larger than 127 seconds.) 904 Proposal: A single duration type is used throughout CoAP, based on 905 an (8,4)-pseudo-FP giving a duration in seconds. 907 Benefits: Implementations can use a single piece of code for 908 managing all CoAP-related durations. 910 In addition, length information never needs to be managed for 911 durations that are embedded in other data structures: All 912 durations are expressed by a single byte. 914 It might be worthwhile to reserve one duration value, e.g. 0xFF, for 915 an indefinite duration. 917 Duration Seconds Encoded 918 ----------- ---------- ------- 919 00:00:00 0x00000000 0x00 920 00:00:01 0x00000001 0x01 921 00:00:02 0x00000002 0x02 922 00:00:03 0x00000003 0x03 923 00:00:04 0x00000004 0x04 924 00:00:05 0x00000005 0x05 925 00:00:06 0x00000006 0x06 926 00:00:07 0x00000007 0x07 927 00:00:08 0x00000008 0x08 928 00:00:09 0x00000009 0x09 929 00:00:10 0x0000000a 0x0a 930 00:00:11 0x0000000b 0x0b 931 00:00:12 0x0000000c 0x0c 932 00:00:13 0x0000000d 0x0d 933 00:00:14 0x0000000e 0x0e 934 00:00:15 0x0000000f 0x0f 935 00:00:16 0x00000010 0x10 936 00:00:17 0x00000011 0x11 937 00:00:18 0x00000012 0x12 938 00:00:19 0x00000013 0x13 939 00:00:20 0x00000014 0x14 940 00:00:21 0x00000015 0x15 941 00:00:22 0x00000016 0x16 942 00:00:23 0x00000017 0x17 943 00:00:24 0x00000018 0x18 944 00:00:25 0x00000019 0x19 945 00:00:26 0x0000001a 0x1a 946 00:00:27 0x0000001b 0x1b 947 00:00:28 0x0000001c 0x1c 948 00:00:29 0x0000001d 0x1d 949 00:00:30 0x0000001e 0x1e 950 00:00:31 0x0000001f 0x1f 951 00:00:32 0x00000020 0x20 952 00:00:33 0x00000021 0x21 953 00:00:34 0x00000022 0x22 954 00:00:35 0x00000023 0x23 955 00:00:36 0x00000024 0x24 956 00:00:37 0x00000025 0x25 957 00:00:38 0x00000026 0x26 958 00:00:39 0x00000027 0x27 959 00:00:40 0x00000028 0x28 960 00:00:41 0x00000029 0x29 961 00:00:42 0x0000002a 0x2a 962 00:00:43 0x0000002b 0x2b 963 00:00:44 0x0000002c 0x2c 964 00:00:45 0x0000002d 0x2d 965 00:00:46 0x0000002e 0x2e 966 00:00:47 0x0000002f 0x2f 967 00:00:48 0x00000030 0x30 968 00:00:49 0x00000031 0x31 969 00:00:50 0x00000032 0x32 970 00:00:51 0x00000033 0x33 971 00:00:52 0x00000034 0x34 972 00:00:53 0x00000035 0x35 973 00:00:54 0x00000036 0x36 974 00:00:55 0x00000037 0x37 975 00:00:56 0x00000038 0x38 976 00:00:57 0x00000039 0x39 977 00:00:58 0x0000003a 0x3a 978 00:00:59 0x0000003b 0x3b 979 00:01:00 0x0000003c 0x3c 980 00:01:01 0x0000003d 0x3d 981 00:01:02 0x0000003e 0x3e 982 00:01:03 0x0000003f 0x3f 983 00:01:04 0x00000040 0x40 984 00:01:05 0x00000041 0x41 985 00:01:06 0x00000042 0x42 986 00:01:07 0x00000043 0x43 987 00:01:08 0x00000044 0x44 988 00:01:09 0x00000045 0x45 989 00:01:10 0x00000046 0x46 990 00:01:11 0x00000047 0x47 991 00:01:12 0x00000048 0x48 992 00:01:13 0x00000049 0x49 993 00:01:14 0x0000004a 0x4a 994 00:01:15 0x0000004b 0x4b 995 00:01:16 0x0000004c 0x4c 996 00:01:17 0x0000004d 0x4d 997 00:01:18 0x0000004e 0x4e 998 00:01:19 0x0000004f 0x4f 999 00:01:20 0x00000050 0x50 1000 00:01:21 0x00000051 0x51 1001 00:01:22 0x00000052 0x52 1002 00:01:23 0x00000053 0x53 1003 00:01:24 0x00000054 0x54 1004 00:01:25 0x00000055 0x55 1005 00:01:26 0x00000056 0x56 1006 00:01:27 0x00000057 0x57 1007 00:01:28 0x00000058 0x58 1008 00:01:29 0x00000059 0x59 1009 00:01:30 0x0000005a 0x5a 1010 00:01:31 0x0000005b 0x5b 1011 00:01:32 0x0000005c 0x5c 1012 00:01:33 0x0000005d 0x5d 1013 00:01:34 0x0000005e 0x5e 1014 00:01:35 0x0000005f 0x5f 1015 00:01:36 0x00000060 0x60 1016 00:01:37 0x00000061 0x61 1017 00:01:38 0x00000062 0x62 1018 00:01:39 0x00000063 0x63 1019 00:01:40 0x00000064 0x64 1020 00:01:41 0x00000065 0x65 1021 00:01:42 0x00000066 0x66 1022 00:01:43 0x00000067 0x67 1023 00:01:44 0x00000068 0x68 1024 00:01:45 0x00000069 0x69 1025 00:01:46 0x0000006a 0x6a 1026 00:01:47 0x0000006b 0x6b 1027 00:01:48 0x0000006c 0x6c 1028 00:01:49 0x0000006d 0x6d 1029 00:01:50 0x0000006e 0x6e 1030 00:01:51 0x0000006f 0x6f 1031 00:01:52 0x00000070 0x70 1032 00:01:53 0x00000071 0x71 1033 00:01:54 0x00000072 0x72 1034 00:01:55 0x00000073 0x73 1035 00:01:56 0x00000074 0x74 1036 00:01:57 0x00000075 0x75 1037 00:01:58 0x00000076 0x76 1038 00:01:59 0x00000077 0x77 1039 00:02:00 0x00000078 0x78 1040 00:02:01 0x00000079 0x79 1041 00:02:02 0x0000007a 0x7a 1042 00:02:03 0x0000007b 0x7b 1043 00:02:04 0x0000007c 0x7c 1044 00:02:05 0x0000007d 0x7d 1045 00:02:06 0x0000007e 0x7e 1046 00:02:07 0x0000007f 0x7f 1047 00:02:08 0x00000080 0x80 1048 00:02:24 0x00000090 0x90 1049 00:02:40 0x000000a0 0xa0 1050 00:02:56 0x000000b0 0xb0 1051 00:03:12 0x000000c0 0xc0 1052 00:03:28 0x000000d0 0xd0 1053 00:03:44 0x000000e0 0xe0 1054 00:04:00 0x000000f0 0xf0 1055 00:04:16 0x00000100 0x81 1056 00:04:48 0x00000120 0x91 1057 00:05:20 0x00000140 0xa1 1058 00:05:52 0x00000160 0xb1 1059 00:06:24 0x00000180 0xc1 1060 00:06:56 0x000001a0 0xd1 1061 00:07:28 0x000001c0 0xe1 1062 00:08:00 0x000001e0 0xf1 1063 00:08:32 0x00000200 0x82 1064 00:09:36 0x00000240 0x92 1065 00:10:40 0x00000280 0xa2 1066 00:11:44 0x000002c0 0xb2 1067 00:12:48 0x00000300 0xc2 1068 00:13:52 0x00000340 0xd2 1069 00:14:56 0x00000380 0xe2 1070 00:16:00 0x000003c0 0xf2 1071 00:17:04 0x00000400 0x83 1072 00:19:12 0x00000480 0x93 1073 00:21:20 0x00000500 0xa3 1074 00:23:28 0x00000580 0xb3 1075 00:25:36 0x00000600 0xc3 1076 00:27:44 0x00000680 0xd3 1077 00:29:52 0x00000700 0xe3 1078 00:32:00 0x00000780 0xf3 1079 00:34:08 0x00000800 0x84 1080 00:38:24 0x00000900 0x94 1081 00:42:40 0x00000a00 0xa4 1082 00:46:56 0x00000b00 0xb4 1083 00:51:12 0x00000c00 0xc4 1084 00:55:28 0x00000d00 0xd4 1085 00:59:44 0x00000e00 0xe4 1086 01:04:00 0x00000f00 0xf4 1087 01:08:16 0x00001000 0x85 1088 01:16:48 0x00001200 0x95 1089 01:25:20 0x00001400 0xa5 1090 01:33:52 0x00001600 0xb5 1091 01:42:24 0x00001800 0xc5 1092 01:50:56 0x00001a00 0xd5 1093 01:59:28 0x00001c00 0xe5 1094 02:08:00 0x00001e00 0xf5 1095 02:16:32 0x00002000 0x86 1096 02:33:36 0x00002400 0x96 1097 02:50:40 0x00002800 0xa6 1098 03:07:44 0x00002c00 0xb6 1099 03:24:48 0x00003000 0xc6 1100 03:41:52 0x00003400 0xd6 1101 03:58:56 0x00003800 0xe6 1102 04:16:00 0x00003c00 0xf6 1103 04:33:04 0x00004000 0x87 1104 05:07:12 0x00004800 0x97 1105 05:41:20 0x00005000 0xa7 1106 06:15:28 0x00005800 0xb7 1107 06:49:36 0x00006000 0xc7 1108 07:23:44 0x00006800 0xd7 1109 07:57:52 0x00007000 0xe7 1110 08:32:00 0x00007800 0xf7 1111 09:06:08 0x00008000 0x88 1112 10:14:24 0x00009000 0x98 1113 11:22:40 0x0000a000 0xa8 1114 12:30:56 0x0000b000 0xb8 1115 13:39:12 0x0000c000 0xc8 1116 14:47:28 0x0000d000 0xd8 1117 15:55:44 0x0000e000 0xe8 1118 17:04:00 0x0000f000 0xf8 1119 18:12:16 0x00010000 0x89 1120 20:28:48 0x00012000 0x99 1121 22:45:20 0x00014000 0xa9 1122 1d 01:01:52 0x00016000 0xb9 1123 1d 03:18:24 0x00018000 0xc9 1124 1d 05:34:56 0x0001a000 0xd9 1125 1d 07:51:28 0x0001c000 0xe9 1126 1d 10:08:00 0x0001e000 0xf9 1127 1d 12:24:32 0x00020000 0x8a 1128 1d 16:57:36 0x00024000 0x9a 1129 1d 21:30:40 0x00028000 0xaa 1130 2d 02:03:44 0x0002c000 0xba 1131 2d 06:36:48 0x00030000 0xca 1132 2d 11:09:52 0x00034000 0xda 1133 2d 15:42:56 0x00038000 0xea 1134 2d 20:16:00 0x0003c000 0xfa 1135 3d 00:49:04 0x00040000 0x8b 1136 3d 09:55:12 0x00048000 0x9b 1137 3d 19:01:20 0x00050000 0xab 1138 4d 04:07:28 0x00058000 0xbb 1139 4d 13:13:36 0x00060000 0xcb 1140 4d 22:19:44 0x00068000 0xdb 1141 5d 07:25:52 0x00070000 0xeb 1142 5d 16:32:00 0x00078000 0xfb 1143 6d 01:38:08 0x00080000 0x8c 1144 6d 19:50:24 0x00090000 0x9c 1145 7d 14:02:40 0x000a0000 0xac 1146 8d 08:14:56 0x000b0000 0xbc 1147 9d 02:27:12 0x000c0000 0xcc 1148 9d 20:39:28 0x000d0000 0xdc 1149 10d 14:51:44 0x000e0000 0xec 1150 11d 09:04:00 0x000f0000 0xfc 1151 12d 03:16:16 0x00100000 0x8d 1152 13d 15:40:48 0x00120000 0x9d 1153 15d 04:05:20 0x00140000 0xad 1154 16d 16:29:52 0x00160000 0xbd 1155 18d 04:54:24 0x00180000 0xcd 1156 19d 17:18:56 0x001a0000 0xdd 1157 21d 05:43:28 0x001c0000 0xed 1158 22d 18:08:00 0x001e0000 0xfd 1159 24d 06:32:32 0x00200000 0x8e 1160 27d 07:21:36 0x00240000 0x9e 1161 30d 08:10:40 0x00280000 0xae 1162 33d 08:59:44 0x002c0000 0xbe 1163 36d 09:48:48 0x00300000 0xce 1164 39d 10:37:52 0x00340000 0xde 1165 42d 11:26:56 0x00380000 0xee 1166 45d 12:16:00 0x003c0000 0xfe 1167 48d 13:05:04 0x00400000 0x8f 1168 54d 14:43:12 0x00480000 0x9f 1169 60d 16:21:20 0x00500000 0xaf 1170 66d 17:59:28 0x00580000 0xbf 1171 72d 19:37:36 0x00600000 0xcf 1172 78d 21:15:44 0x00680000 0xdf 1173 84d 22:53:52 0x00700000 0xef 1174 91d 00:32:00 0x00780000 0xff (reserved) 1176 Figure 12 1178 Authors' Addresses 1180 Carsten Bormann 1181 Universitaet Bremen TZI 1182 Postfach 330440 1183 Bremen D-28359 1184 Germany 1186 Phone: +49-421-218-63921 1187 Fax: +49-421-218-7000 1188 Email: cabo@tzi.org 1190 Klaus Hartke 1191 Universitaet Bremen TZI 1192 Postfach 330440 1193 Bremen D-28359 1194 Germany 1196 Phone: +49-421-218-63905 1197 Fax: +49-421-218-7000 1198 Email: hartke@tzi.org