idnits 2.17.1 draft-bormann-coap-misc-12.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 15, 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC2046' is mentioned on line 420, but not defined == Missing Reference: 'RFC3676' is mentioned on line 413, but not defined == Missing Reference: 'RFC5147' is mentioned on line 413, but not defined == Missing Reference: 'I-D.ietf-core-link-format' is mentioned on line 416, but not defined == Missing Reference: 'RFC3023' is mentioned on line 418, but not defined ** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303) == Missing Reference: 'RFC2045' is mentioned on line 420, but not defined == Missing Reference: 'EXIMIME' is mentioned on line 422, but not defined == Missing Reference: 'RFC4627' is mentioned on line 424, but not defined ** Obsolete undefined reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Missing Reference: 'RFCXXXX' is mentioned on line 440, but not defined == 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-04 == 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: 3 errors (**), 0 flaws (~~), 15 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 18, 2012 February 15, 2012 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-12 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 18, 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. Option delimiter for 15 or more options . . . . . . . . . 4 55 3. Vendor-defined Option . . . . . . . . . . . . . . . . . . . . 7 56 4. Patience, Leisure, and Pledge . . . . . . . . . . . . . . . . 8 57 4.1. Patience . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.2. Leisure . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.3. Pledge . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.4. Option Formats . . . . . . . . . . . . . . . . . . . . . . 9 61 5. Combining Content-Type and Content-Encoding . . . . . . . . . 11 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 68 Appendix A. The Nursery (Things that still need to ripen a 69 bit) . . . . . . . . . . . . . . . . . . . . . . . . 18 70 A.1. Payload-Length Option . . . . . . . . . . . . . . . . . . 18 71 A.2. URI Authorities with Binary Adresses . . . . . . . . . . . 18 72 Appendix B. The Cemetery (Things we won't do) . . . . . . . . . . 20 73 B.1. Stateful URI compression . . . . . . . . . . . . . . . . . 20 74 B.2. Beyond 270 bytes in a single option . . . . . . . . . . . 21 75 B.3. Beyond 15 options . . . . . . . . . . . . . . . . . . . . 22 76 B.3.1. Implementation considerations . . . . . . . . . . . . 23 77 B.3.2. What should we do now? . . . . . . . . . . . . . . . . 24 78 B.3.3. Alternatives . . . . . . . . . . . . . . . . . . . . . 24 79 B.3.4. Alternative: Going to a delimiter model . . . . . . . 24 80 Appendix C. Experimental Options . . . . . . . . . . . . . . . . 25 81 C.1. Options indicating absolute time . . . . . . . . . . . . . 25 82 C.2. Representing Durations . . . . . . . . . . . . . . . . . . 26 83 C.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27 84 C.4. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 28 85 C.5. A Duration Type for CoAP . . . . . . . . . . . . . . . . . 29 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 88 1. Introduction 90 The CoRE WG is tasked with standardizing an Application Protocol for 91 Constrained Networks/Nodes, CoAP [I-D.ietf-core-coap]. This protocol 92 is intended to provide RESTful [REST] services not unlike HTTP 93 [RFC2616], while reducing the complexity of implementation as well as 94 the size of packets exchanged in order to make these services useful 95 in a highly constrained network of themselves highly constrained 96 nodes. 98 This objective requires restraint in a number of sometimes 99 conflicting ways: 101 o reducing implementation complexity in order to minimize code size, 103 o reducing message sizes in order to minimize the number of 104 fragments needed for each message (in turn to maximize the 105 probability of delivery of the message), the amount of 106 transmission power needed and the loading of the limited-bandwidth 107 channel, 109 o reducing requirements on the environment such as stable storage, 110 good sources of randomness or user interaction capabilities. 112 This draft attempts to address a number of problems not yet 113 adequately solved in [I-D.ietf-core-coap]. The solutions proposed to 114 these problems are somewhat interrelated and are therefore presented 115 in one draft. 117 The appendix contains the "CoAP cemetery" (possibly later to move 118 into its own draft), documenting roads that the WG decided not to 119 take, in order to spare readers from reinventing them in vain. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 The term "byte" is used in its now customary sense as a synonym for 126 "octet". 128 2. Getting rid of artificial limitations 130 _Artificial limitations_ are limitations of a protocol or system that 131 are not rooted in limitations of actual capabilities, but in 132 arbitrary design decisions. Proper system design tries to avoid 133 artificial limitations, as these tend to cause complexity in systems 134 that need to work with these limitations. 136 E.g., the original UNIX filesystem had an artificial limitation of 137 the length of a path name component to 14 bytes. This led to all 138 kinds of workarounds in programs that manipulate file names: E.g., 139 systematically replacing a ".el" extension in a filename with a 140 ".elc" for the compiled file might exceed the limit, so all ".el" 141 files were suddenly limited to 13-byte filenames. 143 Note that, today, there still is a limitation in most file system 144 implementations, typically at 255. This just happens to be high 145 enough to rarely be of real-world concern; we will refer to this case 146 as a "painless" artificial limitation. 148 CoAP-08 has two highly recognizable artificial limitations in its 149 protocol encoding 151 o The number of options in a single message is limited to 15 max. 153 o The length of an option is limited to 270 max. 155 It is arguable that the latter limitation causes few problems, just 156 as the 255-byte path name component limitation in filenames today 157 causes few problems. Just in case, Appendix B.2 provides a design to 158 extend this; as a precaution to future extensions of this kind, the 159 current encoding for length 270 (eight ones in the extension byte) 160 could be marked as reserved today. 162 A discussion of approaches for going beyond 15 options is in 163 Appendix B.3. The following subsection provides text that should go 164 into [I-D.ietf-core-coap]. 166 2.1. Option delimiter for 15 or more options 168 (This section addresses core-coap ticket #176.) 170 In Section 3.1 of [I-D.ietf-core-coap], replace 171 Option Count (OC): 4-bit unsigned integer. Indicates the number 172 of options after the header. If set to 0, there are no options 173 and the payload (if any) immediately follows the header. The 174 format of options is defined below. 176 Figure 1 178 by 180 Option Count (OC): 4-bit unsigned integer. Indicates the number of 181 options after the header. If set to 0, there are no options and the 182 payload (if any) immediately follows the header. If set to 15, the 183 sequence of options is terminated by a delimiter. The format of 184 options and of the delimiter is defined below. 186 In Section 3.2, add at the end: 188 Setting OC to 15 means that the number of options is no longer given 189 explicitly. Instead, the sequence of options is terminated by a byte 190 with a special interpretation, 0xF0. (Note that, by this, the option 191 _delta_ of 15 is made special, not any specific option number.) The 192 next byte after the special delimiter byte is then the first byte of 193 the payload. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |Ver| T | 15 | Code | Message ID | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Options ... 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |1 1 1 1 0 0 0 0| Payload (if any) ... 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: Option Terminator for CoAP Messages with 15+ options 207 The byte 0xF0 has this special meaning only if OC=15, i.e. it retains 208 its usual meaning of (option delta = 15, option length = 0) for other 209 values of OC. 211 Implementation note: As can be seen from the proof of concept code 212 in Figure 3, the actual implementation cost for a decoder is 213 around 4 lines of code (or about 8-10 machine code instructions). 215 while numopt > 0 216 nextbyte = ... get next byte 218 if numopt == 15 # new 219 break if nextbyte == 0xF0 # new 220 else # new 221 numopt -= 1 222 end # new 224 ... decode the delta and length from nextbyte and handle them 225 end 227 Figure 3: Implementing the Option Terminator 229 3. Vendor-defined Option 231 To enable experimentation and community-specific options, option 232 number 14 (the first NOP option) can also be used as a vendor-defined 233 option. For this application, the option value has one or more 234 bytes, the semantics of which are defined by prior agreement between 235 the communicating partners. 237 It is RECOMMENDED to start the option value with a unique identifier, 238 e.g., the SDNV [RFC5050] of the enterprise number of the organisation 239 defining the option, possibly followed by additional discriminating 240 bits or bytes as defined by the organisation. 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id| value... | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 \___SDNV of enterprise number___/ 247 Figure 4: Example option value for vendor-defined option 249 Note that a Vendor-defined Option cannot be empty, not only because 250 there would be no space for the SDNV, but in particular as the empty 251 option 14 is reserved for fenceposting ([I-D.ietf-core-coap], section 252 3.2). (Obviously, once a Vendor-defined Option is in use, there is 253 never a need for a fence-post for option number 14.) 255 Vendor-defined Options are elective. 257 The Vendor-defined Option is repeatable. 259 +-----+----------+--------+-------------+---------+---------+ 260 | No. | C/E | Name | Format | Length | Default | 261 +-----+----------+--------+-------------+---------+---------+ 262 | 14 | Elective | Vendor | (see below) | 1-270 B | (empty) | 263 +-----+----------+--------+-------------+---------+---------+ 265 4. Patience, Leisure, and Pledge 267 A number of options might be useful for controlling the timing of 268 interactions. 270 (This section also addresses core-coap ticket #177.) 272 4.1. Patience 274 A client may have a limited time period in which it can actually make 275 use of the response for a request. Using the Patience option, it can 276 provide an (elective) indication how much time it is willing to wait 277 for the response from the server, giving the server license to ignore 278 or reject the request if it cannot fulfill it in this period. 280 If the server knows early that it cannot fulfill the request in the 281 time requested, it MAY indicate this with a 5.04 "Timeout" response. 282 For non-safe methods (such as PUT, POST, DELETE), the server SHOULD 283 indicate whether it has fulfilled the request by either responding 284 with 5.04 "Timeout" (and not further processing the request) or by 285 processing the request normally. 287 Note that the value of the Patience option should be chosen such that 288 the client will be able to make use of the result even in the 289 presence of the expected network delays for the request and the 290 response. Similarly, when a proxy receives a request with a Patience 291 option and cannot fulfill that request from its cache, it may want to 292 adjust the value of the option before forwarding it to an upstream 293 server. 295 (TBD: The various cases that arise when combining Patience with 296 Observe.) 298 The Patience option is elective. Hence, a client MUST be prepared to 299 receive a normal response even after the chosen Patience period (plus 300 an allowance for network delays) has elapsed. 302 4.2. Leisure 304 Servers generally will compute an internal value that we will call 305 Leisure, which indicates the period of time that will be used for 306 responding to a request. A Patience option, if present, can be used 307 as an upper bound for the Leisure. Leisure may be non-zero for 308 congestion control reasons, in particular for responses to multicast 309 requests. For these, the server should have a group size estimate G, 310 a target rate R (which both should be chosen conservatively) and an 311 estimated response size S; a rough lower bound for Leisure can then 312 be computed as follows: 314 lb_Leisure = S * G / R 316 Figure 5 318 E.g., for a multicast request with link-local scope on an 2.4 GHz 319 IEEE 802.15.4 (6LoWPAN) network, G could be (relatively 320 conservatively) set to 100, S to 100 bytes, and the target rate to 8 321 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is 10 322 seconds. 324 To avoid response implosion, responses to multicast requests SHOULD 325 be dithered within a Leisure period chosen by the server to fall 326 between these two bounds. 328 Currently, we don't foresee a need to signal a value for Leisure from 329 client to server (beyond the signalling provided by Patience) or from 330 server to client, but an appropriate Option might be added later. 332 4.3. Pledge 334 In a basic observation relationship [I-D.ietf-core-observe], the 335 server makes a pledge to keep the client in the observation 336 relationship for a resource at least until the max-age for the 337 resource is reached. 339 To save the client some effort in re-establishing observation 340 relationships each time max-age is reached, the server MAY want to 341 extend its pledge beyond the end of max-age by signalling in a 342 response/notification an additional time period using the Pledge 343 Option, in parallel to the Observe Option. 345 The Pledge Option MUST NOT be used unless the server can make a 346 reasonable promise not to lose the observation relationship in this 347 time frame. 349 Currently, we don't foresee a need to signal a value for Pledge from 350 client to server, but an appropriate behavior might be added later 351 for this option when sent in a request. 353 4.4. Option Formats 355 +-----+----------+----------+-----------------+--------+---------+ 356 | No. | C/E | Name | Format | Length | Default | 357 +-----+----------+----------+-----------------+--------+---------+ 358 | 22 | Elective | Patience | Duration in mis | 1 B | (none) | 359 | | | | | | | 360 | 24 | Elective | Pledge | Duration in s | 1 B | 0 | 361 +-----+----------+----------+-----------------+--------+---------+ 363 All timing options use the Duration data type (see Appendix C.2), 364 however Patience (and Leisure, if that ever becomes an option) uses a 365 timebase of mibiseconds (mis = 1/1024 s) instead of seconds. (This 366 reduces the range of the Duration from ~ 91 days to 128 minutes.) 368 Implementation note: As there are no strong accuracy requirements on 369 the clocks employed, making use of any existing time base of 370 milliseconds is a valid implementation approach (2.4 % off). 372 None of the options may be repeated. 374 5. Combining Content-Type and Content-Encoding 376 (This section addresses core-coap ticket #181.) 378 There may be rare cases where the Content-Encoding concept of HTTP 379 may be applicable to CoAP as well. Instead of defining another 380 option to carry that information, the decision was to combine it with 381 the Internet Media Type into the single Option unfortunately called 382 Content-Type. 384 In Section 5.10.4, add behind: 386 5.10.4. Content-Type 388 The Content-Type Option indicates the representation format of the 389 message payload. The representation format is given as a numeric 390 media type identifier that is defined in the CoAP Media Type registry 391 (Section 11.3). No default value is assumed in the absence of the 392 option. 394 Figure 6 396 the new text: 398 Apart from indicating the equivalent of an HTTP Content-Type, a media 399 type identifier registry entry may also incorporate the equivalent of 400 one or more Content-Encodings [RFC2616]. 402 and continue: 404 This option is "critical". It MUST NOT occur more than once. 406 Figure 7 408 In Section 11.3, change table 5 to: 410 +--------------------------+----+-----+-----------------------------+ 411 | Media type | CE | Id. | Reference | 412 +--------------------------+----+-----+-----------------------------+ 413 | text/plain; | -- | 0 | [RFC2046][RFC3676][RFC5147] | 414 | charset=utf-8 | | | | 415 | | | | | 416 | application/link-format | -- | 40 | [I-D.ietf-core-link-format] | 417 | | | | | 418 | application/xml | -- | 41 | [RFC3023] | 419 | | | | | 420 | application/octet-stream | -- | 42 | [RFC2045][RFC2046] | 421 | | | | | 422 | application/exi | -- | 47 | [EXIMIME] | 423 | | | | | 424 | application/json | -- | 50 | [RFC4627] | 425 +--------------------------+----+-----+-----------------------------+ 427 Table 1: CoAP Media Types (CE = Content-Encoding) 429 6. IANA Considerations 431 This draft adds option numbers to Table 2 of [I-D.ietf-core-coap]: 433 +--------+----------+-----------+ 434 | Number | Name | Reference | 435 +--------+----------+-----------+ 436 | 14 | Vendor | [RFCXXXX] | 437 | | | | 438 | 22 | Patience | [RFCXXXX] | 439 | | | | 440 | 24 | Pledge | [RFCXXXX] | 441 +--------+----------+-----------+ 443 Table 2: New CoAP Option Numbers 445 7. Security Considerations 447 TBD. 449 8. Acknowledgements 451 This work was partially funded by the Klaus Tschira Foundation. 453 Of course, much of the content of this draft is the result of 454 discussions with the [I-D.ietf-core-coap] authors. 456 Patience and Leisure were influenced by a mailing list discussion 457 with Esko Dijk, Kepeng Li, and Salvatore Loreto - thanks! 459 9. References 461 9.1. Normative References 463 [I-D.ietf-core-coap] 464 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 465 "Constrained Application Protocol (CoAP)", 466 draft-ietf-core-coap-08 (work in progress), October 2011. 468 [I-D.ietf-core-observe] 469 Hartke, K., "Observing Resources in CoAP", 470 draft-ietf-core-observe-04 (work in progress), 471 February 2012. 473 [I-D.ietf-httpbis-p1-messaging] 474 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 475 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 476 J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and 477 Message Parsing", draft-ietf-httpbis-p1-messaging-18 (work 478 in progress), January 2012. 480 [I-D.ietf-httpbis-p4-conditional] 481 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 482 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 483 J. Reschke, "HTTP/1.1, part 4: Conditional Requests", 484 draft-ietf-httpbis-p4-conditional-18 (work in progress), 485 January 2012. 487 [I-D.ietf-httpbis-p6-cache] 488 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 489 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 490 Nottingham, M., and J. Reschke, "HTTP/1.1, part 6: 491 Caching", draft-ietf-httpbis-p6-cache-18 (work in 492 progress), January 2012. 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 498 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 499 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 501 9.2. Informative References 503 [REST] Fielding, R., "Architectural Styles and the Design of 504 Network-based Software Architectures", 2000. 506 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 507 Specification", RFC 5050, November 2007. 509 Appendix A. The Nursery (Things that still need to ripen a bit) 511 A.1. Payload-Length Option 513 Not all transport mappings may provide an unambiguous length of the 514 CoAP message. For UDP, it may also be desirable to pack more than 515 one CoAP message into one UDP payload (aggregation); in that case, 516 for all but the last message there needs to be a way to delimit the 517 payload of that message. 519 This can be solved using a new option, the Payload-Length option. If 520 this option is present, the value of this option is an unsigned 521 integer giving the length of the payload of the message (note that 522 this integer can be zero for a zero-length payload, which can in turn 523 be represented by a zero-length option value). (In the UDP 524 aggregation case, what would have been in the payload of this message 525 after "payload-length" bytes is then actually one or more additional 526 messages.) 528 A.2. URI Authorities with Binary Adresses 530 One problem with the way URI authorities are represented in the URI 531 syntax is that the authority part can be very bulky if it encodes an 532 IPv6 address in ASCII. 534 Proposal: Provide an option "Uri-Authority-Binary" that can be an 535 even number of bytes between 2 and 18 except 12 or 14. 537 o If the number of bytes is 2, the destination IP address of the 538 packet transporting the CoAP message is implied. 540 o If the number of bytes is 4 or 6, the first four bytes of the 541 option value are an IPv4 address in binary. 543 o If the number of bytes is 8 or 10, the first eight bytes are the 544 lower 64 bits of an IPv6 address; the upper eight bytes are 545 implied from the destination address of the packet transporting 546 the CoAP message. 548 o If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 549 address. 551 o If two more bytes remain, this is a port number (as always in 552 network byte order). 554 The resulting authority is (conceptually translated into ASCII and) 555 used in place of an Uri-Authority option, or inserted into a Proxy- 556 Uri. Examples: 558 +-------------+------------------+---------+------------------------+ 559 | Proxy-Uri | Uri-Authority-Bi | Uri-Pat | URI | 560 | | nary | h | | 561 +-------------+------------------+---------+------------------------+ 562 | (none) | (none) | (none) | "/" | 563 | | | | | 564 | (none) | (none) | 'temp' | "/temp" | 565 | | | | | 566 | (none) | 2 bytes: 61616 | 'temp' | "coap://[DA]:61616/tem | 567 | | | | p" | 568 | | | | | 569 | (none) | 16 bytes: | temp | "coap://[2000::1]/temp | 570 | | 2000::1 | | " | 571 | | | | | 572 | 'http://' | 10 bytes: | (none) | "http://[DA::123:45]:6 | 573 | | ::123:45 + 616 | | 16" | 574 | | | | | 575 | 'http:///te | 18 bytes: | (none) | "http://[2000::1]:616/ | 576 | mp' | 2000::1 + 616 | | temp" | 577 +-------------+------------------+---------+------------------------+ 579 Appendix B. The Cemetery (Things we won't do) 581 This annex documents roads that the WG decided not to take, in order 582 to spare readers from reinventing them in vain. 584 B.1. Stateful URI compression 586 Is the approximately 25 % average saving achievable with Huffman- 587 based URI compression schemes worth the complexity? Probably not, 588 because much higher average savings can be achieved by introducing 589 state. 591 Henning Schulzrinne has proposed for a server to be able to supply a 592 shortened URI once a resource has been requested using the full- 593 length URI. Let's call such a shortened referent a _Temporary 594 Resource Identifier_, _TeRI_ for short. This could be expressed by a 595 response option as shown in Figure 8. 597 0 598 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | duration | TeRI... 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 8: Option for offering a TeRI in a response 605 The TeRI offer option indicates that the server promises to offer 606 this resources under the TeRI given for at least the time given as 607 the duration. Another TeRI offer can be made later to extend the 608 duration. 610 Once a TeRI for a URI is known (and still within its lifetime), the 611 client can supply a TeRI instead of a URI in its requests. The same 612 option format as an offer could be used to allow the client to 613 indicate how long it believes the TeRI will still be valid (so that 614 the server can decide when to update the lifetime duration). TeRIs 615 in requests could be distinguished from URIs e.g. by using a 616 different option number. 618 Proposal: Add a TeRI option that can be used in CoAP requests and 619 responses. 621 Add a way to indicate a TeRI and its duration in a link-value. 623 Do not add any form of stateless URI encoding. 625 Benefits: Much higher reduction of message size than any stateless 626 URI encoding could achieve. 628 As the use of TeRIs is entirely optional, minimal complexity nodes 629 can get by without implementing them. 631 Drawbacks: Adds considerable state and complexity to the protocol. 633 It turns out that real CoAP URIs are short enough that TeRIs are 634 not needed. 636 (Discuss the security implications of TeRIs.) 638 B.2. Beyond 270 bytes in a single option 640 The authors would argue that 270 as the maximum length of an option 641 is already beyond the "painless" threshold. 643 If that is not the consensus of the WG, the scheme can easily be 644 extended as in Figure 9: 646 for 15..269: 647 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 648 | Option Delta | 1 1 1 1 | Length - 15 | 649 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 650 | Option Value ... 651 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 653 for 270..65805: 654 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 655 | Option Delta | 1 1 1 1 | 1 1 1 1 1 1 1 1 | 656 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 657 | Length - 270 (in network byte order) | 658 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 659 | Option Value ... 660 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 662 Figure 9: Ridiculously Long Option Header 664 The infinite number of obvious variations on this scheme are left as 665 an exercise to the reader. 667 Again, as a precaution to future extensions, the current encoding for 668 length 270 (eight ones in the extension byte) could be marked as 669 reserved today. 671 B.3. Beyond 15 options 673 (This section keeps discussion that is no longer needed as we have 674 agreed to do what is documented in Section 2.1). 676 The limit of 15 options is motivated by the fixed four-bit field "OC" 677 that is used for indicating the number of options in the fixed-length 678 CoAP header (Figure 10). 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 |Ver| T | OC | Code | Message ID | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Options (if any) ... 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Payload (if any) ... 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Figure 10: Four-byte fixed header in a CoAP Message 692 Note that there is another fixed four-bit field in CoAP: the option 693 length (Figure 11 - note that this figure is not to the same scale as 694 the previous figure): 696 0 1 2 3 4 5 6 7 697 +---+---+---+---+---+---+---+---+ 698 | Option Delta | Length | for 0..14 699 +---+---+---+---+---+---+---+---+ 700 | Option Value ... 701 +---+---+---+---+---+---+---+---+ 703 Figure 11: Short Option Header 705 Since 15 is inacceptable for a maximum option length, the all-ones 706 value (15) was taken out of the set of allowable values for the short 707 header, and a long header was introduced that allows the insertion of 708 an extension byte (Figure 12): 710 for 15..270: 711 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 712 | Option Delta | 1 1 1 1 | Length - 15 | 713 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 714 | Option Value ... 715 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 717 Figure 12: Long Option Header 719 We might want to use the same technique for the CoAP header as well. 720 There are two obvious places where the extension byte could be 721 placed: 723 1. right after the byte carrying the OC field, so the structure is 724 the same as for the option header; 726 2. right after the fixed-size CoAP header. 728 Both solutions lose the fixed-size-ness of the CoAP header. 730 Solution 1 has the disadvantage that the CoAP header is also changing 731 in structure: The extension byte is wedged between the first and the 732 second byte of the CoAP header. This is unfortunate, as the number 733 of options only comes into play when the option processing begins, so 734 it is more natural to use solution 2 (Figure 13): 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 |Ver| T | 15 | Code | Message ID | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | OC - 15 | Options ... 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Payload (if any) ... 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Figure 13: Extended header for CoAP Messages with 15+ options 748 This would allow for up to 270 options in a CoAP message, which is 749 very likely way beyond the "painless" threshold. 751 B.3.1. Implementation considerations 753 For a message decoder, this extension creates relatively little pain, 754 as the number of options only becomes interesting when the encoding 755 turns to the options part of the message, which is then simply lead 756 in by the extension byte if the four-bit field is 15. 758 For a message encoder, this extension is not so rosy. If the encoder 759 is constructing the message serially, it may not know in advance 760 whether the number of options will exceed 14. None of the following 761 implementation strategies is particularly savory, but all of them do 762 work: 764 1. Encode the options serially under the assumption that the number 765 of options will be 14 or less. When the 15th option needs to be 766 encoded, abort the option encoding, and restart it from scratch 767 one byte further to the left. 769 2. Similar to 1, except that the bytes already encoded are all moved 770 one byte to right, the extension byte is inserted, and the option 771 encoding process is continued. 773 3. The encoder always leaves space for the extension byte (at least 774 if it can't prove the number will be less thatn 14). If the 775 extension byte is not needed, an Option 0 with length 0 is 776 encoded instead (i.e., one byte is wasted - this option is 777 elective and will be ignored by the receiver). 779 As a minimum, to enable strategy 3, the option 0 should be reserved 780 at least for the case of length=0. 782 B.3.2. What should we do now? 784 As a minimum proposal for the next version of CoAP, the value 15 for 785 OC should be marked as reserved today. 787 B.3.3. Alternatives 789 One alternative that has been discussed previously is to have an 790 "Options" Option, which allows the carriage of multiple options in 791 the belly of a single one. This could also be used to carry more 792 than 15 options. However: 794 o The conditional introduction of an Options option has 795 implementation considerations that are likely to be more severe 796 than the ones listed above; 798 o since 270 bytes may not be enough for the encoding of _all_ 799 options, the "Options" option would need to be repeatable. This 800 creates many different ways to encode the same message, leading to 801 combinatorial explosion in test cases for ensuring 802 interoperability. 804 B.3.4. Alternative: Going to a delimiter model 806 Another alternative is to spend the additional byte not as an 807 extended count, but as an option terminator. 809 (See Section 2.1.) 811 Appendix C. Experimental Options 813 This annex documents proposals that need significant additional 814 discussion before they can become part of (or go back to) the main 815 CoAP specification. They are not dead, but might die if there turns 816 out to be no good way to solve the problem. 818 C.1. Options indicating absolute time 820 HTTP has a number of headers that may indicate absolute time: 822 o "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in 823 [I-D.ietf-httpbis-p1-messaging]), giving the absolute time a 824 response was generated; 826 o "Last-Modified", defined in Section 14.29 in [RFC2616], (Section 827 6.6 in [I-D.ietf-httpbis-p4-conditional], giving the absolute time 828 of when the origin server believes the resource representation was 829 last modified; 831 o "If-Modified-Since", defined in Section 14.25 in [RFC2616], 832 "If-Unmodified-Since", defined in Section 14.28 in [RFC2616], and 833 "If-Range", defined in Section 14.27 in [RFC2616] can be used to 834 supply absolute time to gate a conditional request; 836 o "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in 837 [I-D.ietf-httpbis-p6-cache]), giving the absolute time after which 838 a response is considered stale. 840 o The more obscure headers "Retry-After", defined in Section 14.37 841 in [RFC2616], and "Warning", defined in section 14.46 in 842 [RFC2616], also may employ absolute time. 844 [I-D.ietf-core-coap] defines a single "Date" option, which however 845 "indicates the creation time and date of a given resource 846 representation", i.e., is closer to a "Last-Modified" HTTP header. 847 HTTP's caching rules [I-D.ietf-httpbis-p6-cache] make use of both 848 "Date" and "Last-Modified", combined with "Expires". The specific 849 semantics required for CoAP needs further consideration. 851 In addition to the definition of the semantics, an encoding for 852 absolute times needs to be specified. 854 In UNIX-related systems, it is customary to indicate absolute time as 855 an integer number of seconds, after midnight UTC, January 1, 1970. 856 Unless negative numbers are employed, this time format cannot 857 represent time values prior to January 1, 1970, which probably is not 858 required for the uses ob absolute time in CoAP. 860 If a 32-bit integer is used and allowance is made for a sign-bit in a 861 local implementation, the latest UTC time value that can be 862 represented by the resulting 31 bit integer value is 03:14:07 on 863 January 19, 2038. If the 32-bit integer is used as an unsigned 864 value, the last date is 2106-02-07, 06:28:15. 866 The reach can be extended by: - moving the epoch forward, e.g. by 40 867 years (= 1262304000 seconds) to 2010-01-01. This makes it impossible 868 to represent Last-Modified times in that past (such as could be 869 gatewayed in from HTTP). - extending the number of bits, e.g. by one 870 more byte, either always or as one of two formats, keeping the 32-bit 871 variant as well. 873 Also, the resolution can be extended by expressing time in 874 milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned 875 integer of milliseconds would last well after year 9999.) 877 For experiments, an experimental "Date" option is defined with the 878 semantics of HTTP's "Last-Modified". It can carry an unsigned 879 integer of 32, 40, or 48 bits; 32- and 40-bit integers indicate the 880 absolute time in seconds since 1970-01-01 00:00 UTC, while 48-bit 881 integers indicate the absolute time in milliseconds since 1970-01-01 882 00:00 UTC. 884 However, that option is not really that useful until there is a 885 "If-Modified-Since" option as well. 887 (Also: Discuss nodes without clocks.) 889 C.2. Representing Durations 891 Various message types used in CoAP need the representation of 892 *durations*, i.e. of the length of a timespan. In SI units, these 893 are measured in seconds. CoAP durations represent integer numbers of 894 seconds, but instead of representing these numbers as integers, a 895 more compact single-byte pseudo-floating-point (pseudo-FP) 896 representation is used (Figure 14). 898 0 1 2 3 4 5 6 7 899 +---+---+---+---+---+---+---+---+ 900 | 0... value | 901 +---+---+---+---+---+---+---+---+ 903 +---+---+---+---+---+---+---+---+ 904 | 1... mantissa | exponent | 905 +---+---+---+---+---+---+---+---+ 906 Figure 14: Duration in (8,4) pseudo-FP representation 908 If the high bit is clear, the entire n-bit value (including the high 909 bit) is the decoded value. If the high bit is set, the mantissa 910 (including the high bit, with the exponent field cleared out but 911 still present) is shifted left by the exponent to yield the decoded 912 value. 914 The (n,e)-pseudo-FP format can be decoded with a single line of code 915 (plus a couple of constant definitions), as demonstrated in 916 Figure 15. 918 #define N 8 919 #define E 4 920 #define HIBIT (1 << (N - 1)) 921 #define EMASK ((1 << E) - 1) 922 #define MMASK ((1 << N) - 1 - EMASK) 924 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 926 Figure 15: Decoding an (8,4) pseudo-FP value 928 Note that a pseudo-FP encoder needs to consider rounding; different 929 applications of durations may favor rounding up or rounding down the 930 value encoded in the message. 932 The highest pseudo-FP value, represented by an all-ones byte (0xFF), 933 is reserved to indicate an indefinite duration. The next lower value 934 (0xEF) is thus the highest representable value and is decoded as 935 7340032 seconds, a little more than 12 weeks. 937 C.3. Rationale 939 Where CPU power and memory is abundant, a duration can almost always 940 be adequately represented by a non-negative floating-point number 941 representing that number of seconds. Historically, many APIs have 942 also used an integer representation, which limits both the resolution 943 (e.g., if the integer represents the duration in seconds) and often 944 the range (integer machine types have range limits that may become 945 relevant). UNIX's "time_t" (which is used for both absolute time and 946 durations) originally was a signed 32-bit value of seconds, but was 947 later complemented by an additional integer to add microsecond 948 ("struct timeval") and then later nanosecond ("struct timespec") 949 resolution. 951 Three decisions need to be made for each application of the concept 952 of duration: 954 o the *resolution*. What rounding error is acceptable? 956 o the *range*. What is the maximum duration that needs to be 957 represented? 959 o the *number of bits* that can be expended. 961 Obviously, these decisions are interrelated. Typically, a large 962 range needs a large number of bits, unless resolution is traded. For 963 most applications, the actual requirement for resolution are limited 964 for longer durations, but can be more acute for shorter durations. 966 C.4. Pseudo-Floating Point 968 Constrained systems typically avoid the use of floating-point (FP) 969 values, as 971 o simple CPUs often don't have support for floating-point datatypes 973 o software floating-point libraries are expensive in code size and 974 slow. 976 In addition, floating-point datatypes used to be a significant 977 element of market differentiation in CPU design; it has taken the 978 industry a long time to agree on a standard floating point 979 representation. 981 These issues have led to protocols that try to constrain themselves 982 to integer representation even where the ability of a floating point 983 representation to trade range for resolution would be beneficial. 985 The idea of introducing _pseudo-FP_ is to obtain the increased range 986 provided by embedding an exponent, without necessarily getting stuck 987 with hardware datatypes or inefficient software floating-point 988 libraries. 990 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 991 fixed-length value of n bits, e of which may be used for an exponent. 992 Figure 14 illustrates an (8,4)-pseudo-FP value. 994 If the high bit is clear, the entire n-bit value (including the high 995 bit) is the decoded value. If the high bit is set, the mantissa 996 (including the high bit, but with the exponent field cleared out) is 997 shifted left by the exponent to yield the decoded value. 999 The (n,e)-pseudo-FP format can be decoded with a single line of code 1000 (plus a couple of constant definition), as demonstrated in Figure 15. 1002 Only non-negative numbers can be represented by this format. It is 1003 designed to provide full integer resolution for values from 0 to 1004 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 1005 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 1006 (8,4) case. By choosing e carefully, resolution can be traded 1007 against range. 1009 Note that a pseudo-FP encoder needs to consider rounding; different 1010 applications of durations may favor rounding up or rounding down the 1011 value encoded in the message. This requires a little more than a 1012 single line of code (which is left as an exercise to the reader, as 1013 the most efficient expression depends on hardware details). 1015 C.5. A Duration Type for CoAP 1017 CoAP needs durations in a number of places. In [I-D.ietf-core-coap], 1018 durations occur in the option "Subscription-lifetime" as well as in 1019 the option "Max-age". (Note that the option "Date" is not a 1020 duration, but a point in time.) Other durations of this kind may be 1021 added later. 1023 Most durations relevant to CoAP are best expressed with a minimum 1024 resolution of one second. More detailed resolutions are unlikely to 1025 provide much benefit. 1027 The range of lifetimes and caching ages are probably best kept below 1028 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 1029 value of 7864320, which is about 91 days; this appears to be adequate 1030 for a subscription lifetime and probably even for a maximum cache 1031 age. Figure 16 shows the values that can be expressed. (If a larger 1032 range for the latter is indeed desired, an (8,5)-pseudo-FP could be 1033 used; this would last 15 milleniums, at the cost of having only 3 1034 bits of accuracy for values larger than 127 seconds.) 1036 Proposal: A single duration type is used throughout CoAP, based on 1037 an (8,4)-pseudo-FP giving a duration in seconds. 1039 Benefits: Implementations can use a single piece of code for 1040 managing all CoAP-related durations. 1042 In addition, length information never needs to be managed for 1043 durations that are embedded in other data structures: All 1044 durations are expressed by a single byte. 1046 It might be worthwhile to reserve one duration value, e.g. 0xFF, for 1047 an indefinite duration. 1049 Duration Seconds Encoded 1050 ----------- ---------- ------- 1051 00:00:00 0x00000000 0x00 1052 00:00:01 0x00000001 0x01 1053 00:00:02 0x00000002 0x02 1054 00:00:03 0x00000003 0x03 1055 00:00:04 0x00000004 0x04 1056 00:00:05 0x00000005 0x05 1057 00:00:06 0x00000006 0x06 1058 00:00:07 0x00000007 0x07 1059 00:00:08 0x00000008 0x08 1060 00:00:09 0x00000009 0x09 1061 00:00:10 0x0000000a 0x0a 1062 00:00:11 0x0000000b 0x0b 1063 00:00:12 0x0000000c 0x0c 1064 00:00:13 0x0000000d 0x0d 1065 00:00:14 0x0000000e 0x0e 1066 00:00:15 0x0000000f 0x0f 1067 00:00:16 0x00000010 0x10 1068 00:00:17 0x00000011 0x11 1069 00:00:18 0x00000012 0x12 1070 00:00:19 0x00000013 0x13 1071 00:00:20 0x00000014 0x14 1072 00:00:21 0x00000015 0x15 1073 00:00:22 0x00000016 0x16 1074 00:00:23 0x00000017 0x17 1075 00:00:24 0x00000018 0x18 1076 00:00:25 0x00000019 0x19 1077 00:00:26 0x0000001a 0x1a 1078 00:00:27 0x0000001b 0x1b 1079 00:00:28 0x0000001c 0x1c 1080 00:00:29 0x0000001d 0x1d 1081 00:00:30 0x0000001e 0x1e 1082 00:00:31 0x0000001f 0x1f 1083 00:00:32 0x00000020 0x20 1084 00:00:33 0x00000021 0x21 1085 00:00:34 0x00000022 0x22 1086 00:00:35 0x00000023 0x23 1087 00:00:36 0x00000024 0x24 1088 00:00:37 0x00000025 0x25 1089 00:00:38 0x00000026 0x26 1090 00:00:39 0x00000027 0x27 1091 00:00:40 0x00000028 0x28 1092 00:00:41 0x00000029 0x29 1093 00:00:42 0x0000002a 0x2a 1094 00:00:43 0x0000002b 0x2b 1095 00:00:44 0x0000002c 0x2c 1096 00:00:45 0x0000002d 0x2d 1097 00:00:46 0x0000002e 0x2e 1098 00:00:47 0x0000002f 0x2f 1099 00:00:48 0x00000030 0x30 1100 00:00:49 0x00000031 0x31 1101 00:00:50 0x00000032 0x32 1102 00:00:51 0x00000033 0x33 1103 00:00:52 0x00000034 0x34 1104 00:00:53 0x00000035 0x35 1105 00:00:54 0x00000036 0x36 1106 00:00:55 0x00000037 0x37 1107 00:00:56 0x00000038 0x38 1108 00:00:57 0x00000039 0x39 1109 00:00:58 0x0000003a 0x3a 1110 00:00:59 0x0000003b 0x3b 1111 00:01:00 0x0000003c 0x3c 1112 00:01:01 0x0000003d 0x3d 1113 00:01:02 0x0000003e 0x3e 1114 00:01:03 0x0000003f 0x3f 1115 00:01:04 0x00000040 0x40 1116 00:01:05 0x00000041 0x41 1117 00:01:06 0x00000042 0x42 1118 00:01:07 0x00000043 0x43 1119 00:01:08 0x00000044 0x44 1120 00:01:09 0x00000045 0x45 1121 00:01:10 0x00000046 0x46 1122 00:01:11 0x00000047 0x47 1123 00:01:12 0x00000048 0x48 1124 00:01:13 0x00000049 0x49 1125 00:01:14 0x0000004a 0x4a 1126 00:01:15 0x0000004b 0x4b 1127 00:01:16 0x0000004c 0x4c 1128 00:01:17 0x0000004d 0x4d 1129 00:01:18 0x0000004e 0x4e 1130 00:01:19 0x0000004f 0x4f 1131 00:01:20 0x00000050 0x50 1132 00:01:21 0x00000051 0x51 1133 00:01:22 0x00000052 0x52 1134 00:01:23 0x00000053 0x53 1135 00:01:24 0x00000054 0x54 1136 00:01:25 0x00000055 0x55 1137 00:01:26 0x00000056 0x56 1138 00:01:27 0x00000057 0x57 1139 00:01:28 0x00000058 0x58 1140 00:01:29 0x00000059 0x59 1141 00:01:30 0x0000005a 0x5a 1142 00:01:31 0x0000005b 0x5b 1143 00:01:32 0x0000005c 0x5c 1144 00:01:33 0x0000005d 0x5d 1145 00:01:34 0x0000005e 0x5e 1146 00:01:35 0x0000005f 0x5f 1147 00:01:36 0x00000060 0x60 1148 00:01:37 0x00000061 0x61 1149 00:01:38 0x00000062 0x62 1150 00:01:39 0x00000063 0x63 1151 00:01:40 0x00000064 0x64 1152 00:01:41 0x00000065 0x65 1153 00:01:42 0x00000066 0x66 1154 00:01:43 0x00000067 0x67 1155 00:01:44 0x00000068 0x68 1156 00:01:45 0x00000069 0x69 1157 00:01:46 0x0000006a 0x6a 1158 00:01:47 0x0000006b 0x6b 1159 00:01:48 0x0000006c 0x6c 1160 00:01:49 0x0000006d 0x6d 1161 00:01:50 0x0000006e 0x6e 1162 00:01:51 0x0000006f 0x6f 1163 00:01:52 0x00000070 0x70 1164 00:01:53 0x00000071 0x71 1165 00:01:54 0x00000072 0x72 1166 00:01:55 0x00000073 0x73 1167 00:01:56 0x00000074 0x74 1168 00:01:57 0x00000075 0x75 1169 00:01:58 0x00000076 0x76 1170 00:01:59 0x00000077 0x77 1171 00:02:00 0x00000078 0x78 1172 00:02:01 0x00000079 0x79 1173 00:02:02 0x0000007a 0x7a 1174 00:02:03 0x0000007b 0x7b 1175 00:02:04 0x0000007c 0x7c 1176 00:02:05 0x0000007d 0x7d 1177 00:02:06 0x0000007e 0x7e 1178 00:02:07 0x0000007f 0x7f 1179 00:02:08 0x00000080 0x80 1180 00:02:24 0x00000090 0x90 1181 00:02:40 0x000000a0 0xa0 1182 00:02:56 0x000000b0 0xb0 1183 00:03:12 0x000000c0 0xc0 1184 00:03:28 0x000000d0 0xd0 1185 00:03:44 0x000000e0 0xe0 1186 00:04:00 0x000000f0 0xf0 1187 00:04:16 0x00000100 0x81 1188 00:04:48 0x00000120 0x91 1189 00:05:20 0x00000140 0xa1 1190 00:05:52 0x00000160 0xb1 1191 00:06:24 0x00000180 0xc1 1192 00:06:56 0x000001a0 0xd1 1193 00:07:28 0x000001c0 0xe1 1194 00:08:00 0x000001e0 0xf1 1195 00:08:32 0x00000200 0x82 1196 00:09:36 0x00000240 0x92 1197 00:10:40 0x00000280 0xa2 1198 00:11:44 0x000002c0 0xb2 1199 00:12:48 0x00000300 0xc2 1200 00:13:52 0x00000340 0xd2 1201 00:14:56 0x00000380 0xe2 1202 00:16:00 0x000003c0 0xf2 1203 00:17:04 0x00000400 0x83 1204 00:19:12 0x00000480 0x93 1205 00:21:20 0x00000500 0xa3 1206 00:23:28 0x00000580 0xb3 1207 00:25:36 0x00000600 0xc3 1208 00:27:44 0x00000680 0xd3 1209 00:29:52 0x00000700 0xe3 1210 00:32:00 0x00000780 0xf3 1211 00:34:08 0x00000800 0x84 1212 00:38:24 0x00000900 0x94 1213 00:42:40 0x00000a00 0xa4 1214 00:46:56 0x00000b00 0xb4 1215 00:51:12 0x00000c00 0xc4 1216 00:55:28 0x00000d00 0xd4 1217 00:59:44 0x00000e00 0xe4 1218 01:04:00 0x00000f00 0xf4 1219 01:08:16 0x00001000 0x85 1220 01:16:48 0x00001200 0x95 1221 01:25:20 0x00001400 0xa5 1222 01:33:52 0x00001600 0xb5 1223 01:42:24 0x00001800 0xc5 1224 01:50:56 0x00001a00 0xd5 1225 01:59:28 0x00001c00 0xe5 1226 02:08:00 0x00001e00 0xf5 1227 02:16:32 0x00002000 0x86 1228 02:33:36 0x00002400 0x96 1229 02:50:40 0x00002800 0xa6 1230 03:07:44 0x00002c00 0xb6 1231 03:24:48 0x00003000 0xc6 1232 03:41:52 0x00003400 0xd6 1233 03:58:56 0x00003800 0xe6 1234 04:16:00 0x00003c00 0xf6 1235 04:33:04 0x00004000 0x87 1236 05:07:12 0x00004800 0x97 1237 05:41:20 0x00005000 0xa7 1238 06:15:28 0x00005800 0xb7 1239 06:49:36 0x00006000 0xc7 1240 07:23:44 0x00006800 0xd7 1241 07:57:52 0x00007000 0xe7 1242 08:32:00 0x00007800 0xf7 1243 09:06:08 0x00008000 0x88 1244 10:14:24 0x00009000 0x98 1245 11:22:40 0x0000a000 0xa8 1246 12:30:56 0x0000b000 0xb8 1247 13:39:12 0x0000c000 0xc8 1248 14:47:28 0x0000d000 0xd8 1249 15:55:44 0x0000e000 0xe8 1250 17:04:00 0x0000f000 0xf8 1251 18:12:16 0x00010000 0x89 1252 20:28:48 0x00012000 0x99 1253 22:45:20 0x00014000 0xa9 1254 1d 01:01:52 0x00016000 0xb9 1255 1d 03:18:24 0x00018000 0xc9 1256 1d 05:34:56 0x0001a000 0xd9 1257 1d 07:51:28 0x0001c000 0xe9 1258 1d 10:08:00 0x0001e000 0xf9 1259 1d 12:24:32 0x00020000 0x8a 1260 1d 16:57:36 0x00024000 0x9a 1261 1d 21:30:40 0x00028000 0xaa 1262 2d 02:03:44 0x0002c000 0xba 1263 2d 06:36:48 0x00030000 0xca 1264 2d 11:09:52 0x00034000 0xda 1265 2d 15:42:56 0x00038000 0xea 1266 2d 20:16:00 0x0003c000 0xfa 1267 3d 00:49:04 0x00040000 0x8b 1268 3d 09:55:12 0x00048000 0x9b 1269 3d 19:01:20 0x00050000 0xab 1270 4d 04:07:28 0x00058000 0xbb 1271 4d 13:13:36 0x00060000 0xcb 1272 4d 22:19:44 0x00068000 0xdb 1273 5d 07:25:52 0x00070000 0xeb 1274 5d 16:32:00 0x00078000 0xfb 1275 6d 01:38:08 0x00080000 0x8c 1276 6d 19:50:24 0x00090000 0x9c 1277 7d 14:02:40 0x000a0000 0xac 1278 8d 08:14:56 0x000b0000 0xbc 1279 9d 02:27:12 0x000c0000 0xcc 1280 9d 20:39:28 0x000d0000 0xdc 1281 10d 14:51:44 0x000e0000 0xec 1282 11d 09:04:00 0x000f0000 0xfc 1283 12d 03:16:16 0x00100000 0x8d 1284 13d 15:40:48 0x00120000 0x9d 1285 15d 04:05:20 0x00140000 0xad 1286 16d 16:29:52 0x00160000 0xbd 1287 18d 04:54:24 0x00180000 0xcd 1288 19d 17:18:56 0x001a0000 0xdd 1289 21d 05:43:28 0x001c0000 0xed 1290 22d 18:08:00 0x001e0000 0xfd 1291 24d 06:32:32 0x00200000 0x8e 1292 27d 07:21:36 0x00240000 0x9e 1293 30d 08:10:40 0x00280000 0xae 1294 33d 08:59:44 0x002c0000 0xbe 1295 36d 09:48:48 0x00300000 0xce 1296 39d 10:37:52 0x00340000 0xde 1297 42d 11:26:56 0x00380000 0xee 1298 45d 12:16:00 0x003c0000 0xfe 1299 48d 13:05:04 0x00400000 0x8f 1300 54d 14:43:12 0x00480000 0x9f 1301 60d 16:21:20 0x00500000 0xaf 1302 66d 17:59:28 0x00580000 0xbf 1303 72d 19:37:36 0x00600000 0xcf 1304 78d 21:15:44 0x00680000 0xdf 1305 84d 22:53:52 0x00700000 0xef 1306 91d 00:32:00 0x00780000 0xff (reserved) 1308 Figure 16 1310 Authors' Addresses 1312 Carsten Bormann 1313 Universitaet Bremen TZI 1314 Postfach 330440 1315 Bremen D-28359 1316 Germany 1318 Phone: +49-421-218-63921 1319 Fax: +49-421-218-7000 1320 Email: cabo@tzi.org 1322 Klaus Hartke 1323 Universitaet Bremen TZI 1324 Postfach 330440 1325 Bremen D-28359 1326 Germany 1328 Phone: +49-421-218-63905 1329 Fax: +49-421-218-7000 1330 Email: hartke@tzi.org