idnits 2.17.1 draft-bormann-coap-misc-06.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o ACK messages that fail to decode are hard to process. The requesting node MAY repeat the request with fewer options in order to receive a simpler answer; if that is not possible, the decoding failure should be treated like a client error. Conversely, nodes SHOULD not send critical options in ACK messages unless the CON message eliciting the ACK contained options that justify this. (There may be exceptions, e.g., a node is always allowed to send a Block option with a large resource representation. A requestor that does not understand Block may never be able to receive that resource representation properly, so it is appropriate to treat the situation as a client error.) -- The document date (August 24, 2010) is 4994 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 (-02) exists of draft-hartke-coap-observe-01 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-11 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 8 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: February 25, 2011 August 24, 2010 7 Miscellaneous additions to CoAP 8 draft-bormann-coap-misc-06 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, CoAP. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on February 25, 2011. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. A Compact Accept Option . . . . . . . . . . . . . . . . . . . 4 51 3. URI encoding . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 3.1. Stateful URI compression . . . . . . . . . . . . . . . . . 6 53 3.2. Support for URIs with Binary Adresses . . . . . . . . . . 7 54 3.3. Where are Uri Options Used? . . . . . . . . . . . . . . . 8 55 4. Option Encoding . . . . . . . . . . . . . . . . . . . . . . . 10 56 4.1. A More Efficient Option Encoding . . . . . . . . . . . . . 10 57 4.2. Critical Options . . . . . . . . . . . . . . . . . . . . . 11 58 4.3. Errors in Options . . . . . . . . . . . . . . . . . . . . 12 59 4.4. Payload-Length Option . . . . . . . . . . . . . . . . . . 12 60 4.5. User-defined Option . . . . . . . . . . . . . . . . . . . 13 61 4.6. Making the Etag option useful . . . . . . . . . . . . . . 13 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 64 6.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 17 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 69 Appendix A. Things we won't do . . . . . . . . . . . . . . . . . 21 70 A.1. An efficient stateless URI encoding . . . . . . . . . . . 21 71 A.2. Media-Types with Self-Describing Length . . . . . . . . . 22 72 Appendix B. Experimental Options . . . . . . . . . . . . . . . . 24 73 B.1. Options indicating absolute time . . . . . . . . . . . . . 24 74 Appendix C. Rationale: Representing Durations . . . . . . . . . . 26 75 C.1. Text for section 3.2.1 of coap-01 . . . . . . . . . . . . 26 76 C.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27 77 C.3. Pseudo-Floating Point . . . . . . . . . . . . . . . . . . 27 78 C.4. A Duration Type for CoAP . . . . . . . . . . . . . . . . . 28 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 81 1. Introduction 83 The CoRE WG is tasked with standardizing an Application Protocol for 84 Constrained Networks/Nodes, CoAP. This protocol is intended to 85 provide RESTful [REST] services not unlike HTTP [RFC2616], while 86 reducing the complexity of implementation as well as the size of 87 packets exchanged in order to make these services useful in a highly 88 constrained network of themselves highly constrained nodes. 90 This objective requires restraint in a number of sometimes 91 conflicting ways: 93 o reducing implementation complexity in order to minimize code size, 95 o reducing message sizes in order to minimize the number of 96 fragments needed for each message (in turn to maximize the 97 probability of delivery of the message), the amount of 98 transmission power needed and the loading of the limited-bandwidth 99 channel, 101 o reducing requirements on the environment such as stable storage, 102 good sources of randomness or user interaction capabilities. 104 This draft attempts to address a number of problems not yet 105 adequately solved in [I-D.ietf-core-coap]. The solutions proposed to 106 these problems are somewhat interrelated and are therefore presented 107 in one draft. 109 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 110 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 111 and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] 112 and indicate requirement levels for compliant CoAP implementations. 114 The term "byte" is used in its now customary sense as a synonym for 115 "octet". 117 2. A Compact Accept Option 119 A resource may be available in a number of representations. Without 120 some information from the client, a server has no easy way to decide 121 which of these would be best served. HTTP has an Accept: request 122 header that a client can use to indicate the media types supported, 123 allowing the server to decide. This header is somewhat unpopular as, 124 for a web browser, there are too many media types to choose from, so 125 -- even with wildcards -- there is no meaningful information to put 126 there. (This has changed a bit for AJAX calls, which may indeed have 127 a specific media type preference.) It is unlikely that machine-to- 128 machine communication would have the same problem. 130 A similar function to the HTTP Accept: header could be added to CoAP 131 as an option in a much simpler way. The CoAP Accept option would 132 simple carry a value that is a sequence of octets, each of which is 133 an acceptable media type for the client, in the order of preference 134 (see Figure 1). If no Accept option is given, the client does not 135 express a preference. 137 0 138 0 1 2 3 4 5 6 7 139 +-+-+-+-+-+-+-+-+ 140 | mediatype | 141 +-+-+-+-+-+-+-+-+ 143 0 1 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | mediatype1 | mediatype2 | etc. 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1: Accept option value: A sequence of media types 151 Accept also has to be given an option type code, e.g. 6, in Table 2 152 of [I-D.ietf-core-coap]. (Alternatively, as Accept appears to be 153 mutually exclusive with Content-Type, the same option number as 154 Content-Type could be used. For both to have the same structure, the 155 Content-Type option could also be repeated for every Acceptable media 156 type.) 158 The other addition that would be required is an error code that 159 mirrors HTTP's "415 Unsupported Media Type". This is indeed already 160 listed as CoAP Code 35 in Table 3 of [I-D.ietf-core-coap]. 162 Proposal: Add an Accept Option. 164 Benefits: A Server does not need to specify one URI each for every 165 possible media type that it wants to serve a resource under. 167 (See also Appendix A.2.) 169 3. URI encoding 171 In HTTP-based systems, URIs can reach significant lengths. While 172 CoAP-based systems may be able to sidestep the most egregious 173 excesses (mostly by simply applying REST principles), a URI such as 175 /.well-known/resources 177 can use up one third of the available payload in a CoAP message 178 transported in a single 6LoWPAN packet. Is there a way to encode 179 these URIs in a more efficient way? 181 Several proposals have been made on the CoRE mailing list, e.g. 182 applying the principle of base64-encoding [RFC4648] in reverse and 183 using only 6 bits per character. However, due to rounding errors and 184 occasional characters that are not in the 64-character subset chosen 185 to be efficiently encodable, the actual gains are limited. 186 Similarly, using 7 bits per character (assuming URIs contain only 187 ASCII characters) only gives a best-case gain of 12.5 %, and that 188 only in the case the URI is a multiple of 8 characters long. On the 189 other hand, the complexity (and danger of subtle interoperability 190 problems) is not entirely trivial. 192 Appendix A.1 defines a potential URI encoding that is slightly more 193 efficient than the abovementioned ones. However, even that was 194 rejected by the WG for its unconvincing cost-benefit ratio, which 195 then went on to discuss Henning Schulzrinne's proposal to add state. 197 3.1. Stateful URI compression 199 Is the approximately 25 % average saving achievable with Huffman- 200 based URI compression schemes worth the complexity? Probably not, 201 because much higher average savings can be achieved by introducing 202 state. 204 Henning Schulzrinne has proposed for a server to be able to supply a 205 shortened URI once a resource has been requested using the full- 206 length URI. Let's call such a shortened referent a _Temporary 207 Resource Identifier_, _TeRI_ for short. This could be expressed by a 208 response option as shown in Figure 2. 210 0 211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | duration | TeRI... 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 2: Option for offering a TeRI in a response 218 The TeRI offer option indicates that the server promises to offer 219 this resources under the TeRI given for at least the time given as 220 the duration. Another TeRI offer can be made later to extend the 221 duration. 223 Once a TeRI for a URI is known (and still within its lifetime), the 224 client can supply a TeRI instead of a URI in its requests. The same 225 option format as an offer could be used to allow the client to 226 indicate how long it believes the TeRI will still be valid (so that 227 the server can decide when to update the lifetime duration). TeRIs 228 in requests could be distinguished from URIs e.g. by using a 229 different option number. 231 Proposal: Add a TeRI option (e.g., number 2) that can be used in 232 CoAP requests and responses. 234 Add a way to indicate a TeRI and its duration in a link-value. 236 Do not add any form of stateless URI encoding. 238 Benefits: Much higher reduction of message size than any stateless 239 URI encoding could achieve. 241 As the use of TeRIs is entirely optional, minimal complexity nodes 242 can get by without implementing them. 244 3.2. Support for URIs with Binary Adresses 246 As defined in [I-D.ietf-core-coap], the Uri option does not provide a 247 way to distinguish an "absolute-URI" from an "absolute-path" 248 [RFC3986]: the leading slash is omitted from the latter. (Ticket 249 #12.) 251 The proposal to fix this is to split the option into three parts: 252 "Uri-Scheme" for the URI Scheme, "Uri-Authority" for Host/Port and 253 "Uri-Path" for the absolute-path. 255 A further problem with that version is that the authority part can be 256 very bulky if it encodes an IPv6 address in ASCII. 258 Proposal: Provide an option "Uri-Authority-Binary" that can be an 259 even number of bytes between 2 and 18 except 12 or 14. 261 o If the number of bytes is 2, the destination IP address of the 262 packet transporting the CoAP message is implied. 264 o If the number of bytes is 4 or 6, the first four bytes of the 265 option value are an IPv4 address in binary. 267 o If the number of bytes is 8 or 10, the first eight bytes are the 268 lower 64 bits of an IPv6 address; the upper eight bytes are 269 implied from the destination address of the packet transporting 270 the CoAP message. 272 o If the number of bytes is 16 or 18, the first 16 bytes are an IPv6 273 address. 275 o If two more bytes remain, this is a port number (as always in 276 network byte order). 278 The resulting authority is (conceptually translated into ASCII and) 279 used in place of an Uri-Authority option. Examples: 281 +-------+--------------------+----------+---------------------------+ 282 | Uri- | Uri-Authority-Bina | Uri-Path | URI | 283 | Schem | ry | | | 284 | e | | | | 285 +-------+--------------------+----------+---------------------------+ 286 | (none | (none) | (none) | "/" | 287 | ) | | | | 288 | | | | | 289 | (none | (none) | 'temp' | "/temp" | 290 | ) | | | | 291 | | | | | 292 | (none | 2 bytes: 61616 | 'temp' | "coap://[DA]:61616/temp" | 293 | ) | | | | 294 | | | | | 295 | 'http | 10 bytes: ::123:45 | (none) | "http://[DA::123:45]:616" | 296 | ' | + 616 | | | 297 | | | | | 298 | (none | 16 bytes: 2000::1 | temp | "coap://[2000::1]/temp" | 299 | ) | | | | 300 | | | | | 301 | 'http | 18 bytes: 2000::1 | temp | "http://[2000::1]:616/tem | 302 | ' | + 616 | | p" | 303 +-------+--------------------+----------+---------------------------+ 305 3.3. Where are Uri Options Used? 307 A URI, represented by an appropriate set of Uri options (one or more 308 of Uri-Scheme, Uri-Authority, Uri-Path, unless the default absolute- 309 path of "/" applies) should be present in every GET, PUT, POST, or 310 DELETE message, unless replaced by a TeRI. The receiver of an ACK 311 can figure out which URI the message pertains to by comparing 312 transaction IDs. 314 In a delayed Confirmable message that contains an asynchronous 315 response to a GET, the URI is included again ("echoed back"). 317 In addition to the context provided by including the URI again in 318 delayed responses, we propose adding a "Token" option, which can be 319 included in GET, PUT, POST, DELETE messages, and is echoed back in 320 exactly those cases where the URI is echoed back. The Token allows a 321 recipient of an asynchronous message to relate back to an earlier 322 request and thus can be used as the long-term equivalent of what TID 323 is for a single transaction. The Token option value is a sequence of 324 bytes, which is opaque to the server. The option is critical. 326 4. Option Encoding 328 The option encoding in [I-D.ietf-core-coap] is neither particularly 329 flexible nor particularly efficient. One important, easily 330 overlooked disadvantage of the encoding is the large number of ways 331 in which the same information can be encoded. This unneeded 332 variability causes problems in interoperability and increases both 333 coding and testing efforts required. 335 4.1. A More Efficient Option Encoding 337 The basic idea of the proposed encoding is to reduce the number of 338 ways the same information can be encoded as far as possible (but not 339 further). This both simplifies decoding (e.g., an implementation 340 that only ever uses short URIs never has to implement long options, 341 because these can only be used with long lengths) and 342 interoperability testing (there is only one way to say a specific 343 thing, so there aren't multiple ways that need testing). 345 One of the undesired variations in packets is the ordering of the 346 options. In this draft, we therefore mandate a total ordering of 347 options, ordered by the option number. 349 As an interesting consequence, the option numbers can now be 350 expressed in delta coding, in turn requiring fewer bits to encode the 351 option number. This frees a number of bits for the length, making 352 the likelihood of actually needing the two-byte form of the option 353 header much smaller. 355 To further reduce variation, the length of the value (as always, not 356 including the option header) is now encoded in such a way that there 357 is only one way to express a given length: The short form (one-byte 358 option tag) can express length values from 0 to 14, and the long form 359 is used for values of 15 to 15+255=270, inclusively (Figure 3). 361 0 1 2 3 4 5 6 7 362 +---+---+---+---+---+---+---+---+ 363 | option delta | length | for 0..14 364 +---+---+---+---+---+---+---+---+ 365 for 15..270: 366 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 367 | option delta | 1 1 1 1 | length - 15 | 368 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 370 Figure 3: Option delta/length representation with small range 372 The small option delta of 0..15 in this encoding limits the 373 difference in option value between two adjacent options (or the value 374 of the option number of the first option). While realistic sequences 375 of options rarely will have a problem here, option numbers 14, 28, 376 ... are reserved for no-op options with no body (implementations will 377 automatically ignore these with zero additional code; see Section 4.2 378 why the reserved values are not 15, 30, ...). Note that the 379 resulting delta that reaches the interim nop option may have any 380 number, e.g., for including option 2 and 27 in one message, the 381 sequence would be: 383 o delta = 2 (option 2, body) 385 o delta = 12 (option 14 = no-op, no body) 387 o delta = 13 (option 27, body) 389 In the unlikely case that only option 40 is needed, the sequence 390 would be: 392 o delta = 14 (option 14 = no-op, no body) 394 o delta = 14 (option 28 = no-op, bo body) 396 o delta = 12 (option 40, body) 398 4.2. Critical Options 400 CoAP is designed to enable the definition of additional options by 401 later extensions. Typically, new options are designed in such a way 402 that they can simply be ignored if not understood, i.e. new options 403 are _elective_. However, some new options may be _critical_, i.e., 404 there is no good way to process the message if the option is not 405 understood. (Actually, half of the options currently on the table 406 are critical in nature.) 408 In the option encoding proposed, odd-numbered options indicate a 409 critical option; even-numbered options indicate elective options. 410 (Note that, again, the even/odd distinction is on the option number 411 resulting from the decoding, not the delta value actually embedded in 412 the packet.) 414 Implementing this proposal requires some renumbering of options from 415 [I-D.ietf-core-coap]. 417 Note that most options that are designated as critical are _not_ 418 meant to be mandatory to implement. "Critical" just means if such an 419 option is encountered in an incoming message, there is no meaningful 420 way to process the message unless it is indeed implemented. 422 4.3. Errors in Options 424 When a message contains a critical option that is not understood by 425 the receiver, we say that _decoding fails_. 427 When a message contains an option that is defined for a specific 428 length of value (e.g., Max-Age, which is only defined for length 1), 429 this is treated like an unknown option. For a critical option, this 430 causes the decoding to fail. For an elective option, this is not an 431 error, the option with the unsupported structure is just ignored. 432 (In both cases, the intention is to allow extension of the option by 433 different syntax in a later revision of the protocol.) 435 If the decoding of a message fails, the processing depends on the 436 message type: 438 o NCN messages and RST messages with decode failures are always 439 silently ignored. 441 o CON messages with decode failures lead to an RST with error code 442 400 (Bad Request). The payload of the RST SHOULD be a copy of the 443 option bytes that caused decoding to fail. However, nodes with 444 minimal capabilities may choose to restrict their error processing 445 to a minimum, 447 o ACK messages that fail to decode are hard to process. The 448 requesting node MAY repeat the request with fewer options in order 449 to receive a simpler answer; if that is not possible, the decoding 450 failure should be treated like a client error. Conversely, nodes 451 SHOULD not send critical options in ACK messages unless the CON 452 message eliciting the ACK contained options that justify this. 453 (There may be exceptions, e.g., a node is always allowed to send a 454 Block option with a large resource representation. A requestor 455 that does not understand Block may never be able to receive that 456 resource representation properly, so it is appropriate to treat 457 the situation as a client error.) 459 4.4. Payload-Length Option 461 Not all transport mappings may provide an unambiguous length of the 462 CoAP message. For UDP, it may also be desirable to pack more than 463 one CoAP message into one UDP payload (aggregation); in that case, 464 for all but the last message there needs to be a way to delimit the 465 payload of that message. 467 We propose a new option, the Payload-Length option. If this option 468 is present, the value of this option is an unsigned integer giving 469 the length of the payload of the message (note that this integer can 470 be zero for a zero-length payload, which can in turn be represented 471 by a zero-length option value). (In the UDP aggregation case, what 472 would have been in the payload of this message after "payload-length" 473 bytes is then actually one or more additional messages.) 475 4.5. User-defined Option 477 To enable experimentation and community-specific options, option 478 number 14 (the first NOP option) can also be used as a user-defined 479 option. For this application, the option value has one or more 480 bytes, the semantics of which are defined by prior agreement between 481 the communicating partners. 483 It is RECOMMENDED to start the option value with a unique identifier, 484 e.g., the SDNV [RFC5050] of the enterprise number of the organisation 485 defining the option, possibly followed by additional discriminating 486 bits or bytes. 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 |1 0 0 0 0 0 0 1|0 1 1 1 0 0 1 1| private opt-id| value... | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 \___SDNV of enterprise number___/ 493 Figure 4: Example option value for user-defined option 495 User-defined Options are elective. 497 The User-defined Option is repeatable. 499 4.6. Making the Etag option useful 501 Problem: The Etag option only allows for up to four bytes in one 502 Etag. If Etags are computed with a random distribution (e.g., by 503 hashing the resource representation), the birthday paradox makes a 504 collision surprisingly likely already for 1e4 variants in 505 circulation. 507 Proposal: Allow longer Etags (i.e., don't specify a specific upper 508 limit). The default Apache Etag has about 8..12 Bytes of 509 information in it (file ID = inode number, size, timestamp; which 510 interestingly is mostly redundant with information available in 511 Content-Length and Last-Modified). If a tighter upper limit is 512 desired, 8 Bytes should suffice for all practical purposes, but 513 makes two-way gatewaying with HTTP more complex. 515 Problem: The Etag option is not useful without an equivalent of 516 "If-None-Match". 518 Proposal: Make Etags useful by defining a new Option "I-Have": The 519 I-Have Option carries a variable length octet sequence that 520 specifies the Etag of a resource representation that is being 521 cached by a client. A client that has one or more representations 522 previously obtained from the resource can indicate to the server 523 that it has cached these representations, such that the server may 524 omit the representation when the state of the resource does not 525 change from a cached representation or changes to one of the other 526 cached representation. The I-Have Option may occur zero or more 527 times. (This can be used to represent a "If-None-Match" HTTP 528 option with one or more Etags. Note that CoAP always uses what 529 would be called a strong validator in HTTP.) As it appears I-Have 530 and Etag are mutually exclusive, I-Have can use the option number 531 of Etag. 533 5. IANA Considerations 535 This draft adds option numbers to Table 2 of [I-D.ietf-core-coap], 536 resulting in: 538 +-----+----+------------------+--------------+-------+--------------+ 539 | Typ | C/ | Name | Data type | Lengt | Default | 540 | e | E | | | h | | 541 +-----+----+------------------+--------------+-------+--------------+ 542 | 0 | E | TeRI | Duration + | 2-n B | (none) | 543 | | | | Sequence of | | | 544 | | | | Bytes | | | 545 | | | | | | | 546 | 1 | C | Content-type | Unsigned | 1 B | 0 | 547 | | | | Integer | | (text/plain) | 548 | | | | | | | 549 | 2 | E | Max-age | Duration | 1 B | 0 | 550 | | | | | | | 551 | 3 | C | Uri-Scheme | String | 1-n B | 'coap' | 552 | | | | | | | 553 | 4 | E | Etag | Sequence of | 1-n* | (none) | 554 | | | | Bytes | B | | 555 | | | | | | | 556 | 5 | C | Uri-Authority | String | 1-n B | '' | 557 | | | | | | | 558 | 6 | E | Location | String | 1-270 | - | 559 | | | | | B | | 560 | | | | | | | 561 | 7 | C | Uri-Authority-Bi | Sequence of | 1-n B | (use | 562 | | | nary | Bytes | | Uri-Authorit | 563 | | | | | | y) | 564 | | | | | | | 565 | 8 | E | Accept | Sequence of | 1-n B | any | 566 | | | | Bytes | | | 567 | | | | | | | 568 | 10 | E | Date | Unsigned | 4-6 B | (none) | 569 | | | | Integer | | | 570 | | | | (Appendix B. | | | 571 | | | | 1) | | | 572 | | | | | | | 573 | 9 | C | Uri-Path | String | 1-n B | '' | 574 | | | | | | | 575 | 11 | C | Token | Sequence of | 1-n B | (none) | 576 | | | | Bytes | | | 577 | | | | | | | 578 | 13 | C | Block (now in | Unsigned | 1-3 B | 0 | 579 | | | coap-block) | Integer | | | 580 | | | | | | | 581 | 14. | E | Nop | None | 0 B | ('') | 582 | . | | | | | | 583 | | | | | | | 584 | 14 | E | User | Sequence of | 1-n B | (none) | 585 | | | | Bytes | | | 586 | | | | | | | 587 | 15 | C | Payload-length | Unsigned | 0-2 B | (none) | 588 | | | | Integer | | | 589 +-----+----+------------------+--------------+-------+--------------+ 591 (The upper limit of "n" indicates that the size is limited only by 592 the options encoding. * indicates that this document proposes to 593 change the limit.) Odd option numbers indicate critical options, 594 even option numbers indicate elective options. Option numbers 14, 595 28, 42, ... (any number divisible by 14) are reserved (they are 596 elective and therefore ignored by all implementations). 598 (Subscription-related options are discussed in 599 [I-D.hartke-coap-observe], so the following option from 600 [I-D.ietf-core-coap] is not further discussed here:) 602 +------+-----+-----------------------+-----------+--------+---------+ 603 | Type | C/E | Name | Data type | Length | Default | 604 +------+-----+-----------------------+-----------+--------+---------+ 605 | 10 | E | Subscription-lifetime | Duration | 1 B | 0 | 606 +------+-----+-----------------------+-----------+--------+---------+ 608 6. Security Considerations 610 TBD. (Weigh the security implications of application layer block- 611 wise transfer against those of adaptation-layer or IP-layer 612 fragmentation. Discuss the implications of TeRIs. Also: Discuss 613 nodes without clocks.) 615 6.1. Amplification Attacks 617 TBD. (This section discusses how CoAP nodes could become implicated 618 in DoS attacks by using the amplifying properties of the protocol, as 619 well as mitigations for this threat.) 621 7. Acknowledgements 623 This work was partially funded by the Klaus Tschira Foundation. 625 Of course, much of the content of this draft is the result of 626 discussions with the [I-D.ietf-core-coap] authors. Tokens were 627 suggested by Gilman Tolle. 629 8. References 631 8.1. Normative References 633 [I-D.hartke-coap-observe] 634 Hartke, K. and C. Bormann, "Observing Resources in CoAP", 635 draft-hartke-coap-observe-01 (work in progress), 636 July 2010. 638 [I-D.ietf-core-coap] 639 Shelby, Z., Frank, B., and D. Sturek, "Constrained 640 Application Protocol (CoAP)", draft-ietf-core-coap-01 641 (work in progress), July 2010. 643 [I-D.ietf-httpbis-p1-messaging] 644 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 645 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 646 J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and 647 Message Parsing", draft-ietf-httpbis-p1-messaging-11 (work 648 in progress), August 2010. 650 [I-D.ietf-httpbis-p4-conditional] 651 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 652 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 653 J. Reschke, "HTTP/1.1, part 4: Conditional Requests", 654 draft-ietf-httpbis-p4-conditional-11 (work in progress), 655 August 2010. 657 [I-D.ietf-httpbis-p6-cache] 658 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 659 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 660 Nottingham, M., and J. Reschke, "HTTP/1.1, part 6: 661 Caching", draft-ietf-httpbis-p6-cache-11 (work in 662 progress), August 2010. 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, March 1997. 667 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 668 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 669 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 671 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 672 Resource Identifier (URI): Generic Syntax", STD 66, 673 RFC 3986, January 2005. 675 8.2. Informative References 677 [REST] Fielding, R., "Architectural Styles and the Design of 678 Network-based Software Architectures", 2000. 680 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 681 version 1.3", RFC 1951, May 1996. 683 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 684 Encodings", RFC 4648, October 2006. 686 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 687 Specification", RFC 5050, November 2007. 689 Appendix A. Things we won't do 691 This annex documents roads that the WG decided not to take, in order 692 to spare readers from reinventing them in vain. 694 A.1. An efficient stateless URI encoding 696 There is very little redundancy by repetition in a typical URI, 697 rendering popular compression methods such as LZ77 (as implemented in 698 in the widely used DEFLATE algorithm [RFC1951]) rather ineffective. 700 For the short, non-repetitive data structures that URIs tend to be, 701 efficient stateless compression is pretty much confined to Huffman 702 (or, for even more complexity, arithmetic) coding. The complexity 703 can be reduced significantly by moving to n-ary Huffman coding, i.e., 704 optimizing not to the bit level, but to a larger level of 705 granularity. Informal experiments by the author show that a 16ary 706 Huffman coding is close to optimal for reasonable URI lengths. In 707 other words, basing the encoding on nibbles (4-bit half-bytes) is 708 both nearly optimal and relatively inexpensive to implement. 710 The actual letter frequencies that will occur in CoAP URIs are hard 711 to predict. As a stopgap, the author has analyzed an HTTP-based URI 712 corpus and found the following characters to occur with high 713 frequency: 715 %.aeinorst 717 In the encoding proposed, each of these ten highly-compressed 718 characters is represented by a single 4-bit nibble. As the % 719 character is used for hexadecimal encoding in URIs, two additional 720 nibbles are used to provide the numeric value of the two hexadecimal 721 numbers following the % character (the original URI will only be 722 properly reconstituted if these are upper-case as they should be 723 according to section 2.1 of the URI specification [RFC3986]; the 724 encoder can choose to send all three characters in dual-nibble format 725 if that matters). An encoder could also map non-ASCII characters to 726 this three-nibble form, even though they are not allowed in URIs. 727 This gives compatibility with the %-encoding required by [RFC3986]. 729 All other characters are represented by both of their nibbles. The 730 resulting sequence of nibbles is reconstituted into a sequence of 731 bytes in most-significant-nibble-first order. Any unused nibble in 732 the last byte of an encoding is set to 0. (Upon decoding, this 733 padding can be readily distinguished from another % combination as 734 this would require another byte after the last byte.) The encoding 735 is summarized in Figure 5. 737 0 1 738 0 1 2 3 4 5 6 7 8 9 0 1 739 +---+---+---+---+ 740 | 1, 8-F | .aeinorst 741 +---+---+---+---+ 189ABCDEF 743 +---+---+---+---+---+---+---+---+ 744 | 2-7 | 0-F | other ASCII 745 +---+---+---+---+---+---+---+---+ 747 +---+---+---+---+---+---+---+---+---+---+---+---+ 748 | 0 | 0-F | 0-F | %HH 749 +---+---+---+---+---+---+---+---+---+---+---+---+ 751 Figure 5: A nibble-based URI encoding 753 An example encoding for "/.well-known/resources" (where the initial 754 slash is left out, as proposed for abs-path URIs) is given in 755 Figure 6. While the more than 28 % savings in this example may seem 756 just an accident, the HTTP-based corpus indeed shows an average 757 savings of about 21.8 %, i.e. the sum of the lengths of the encoded 758 version of all URIs in the corpus is about 78.2 % of the sum of the 759 length of all URIs. (The savings should be noticeably higher with a 760 more RESTful selection of URIs than was available for this 761 experiment.) 763 0 1 2 764 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 765 / . w e l l - k n o w n / r e s o u r c e s 767 2e 77 65 6c 6c 2d 6b 6e 6f 77 6e 2f 72 65 73 6f 75 72 63 65 73 768 -> 769 1 77 9 6c 6c 2d 6b b c 77 b 2f d 9 e c 75 d 63 9 e 770 = 17 79 6c 6c 2d 6b bc 77 b2 fd 9e c7 5d 63 9e 772 Figure 6: Nibble-based URI encoding: 21 -> 15 bytes 774 A.2. Media-Types with Self-Describing Length 776 Open Issues: For coap-00, the Accept option proposed would have 777 needed a way to handle two-byte media types (easiest if these can 778 be made self-describing, at the cost of about 3 bits in the sub- 779 type field; Figure 7). 781 An self-describing representation for long mediatypes could look like 782 this: 784 0 785 0 1 2 3 4 5 6 7 786 +-+-+-+-+-+-+-+-+ 787 | top | sub | (1-byte: unchanged) 788 +-+-+-+-+-+-+-+-+ 790 0 1 791 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | 000 | top | sub | (2-byte) 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Figure 7: A self-describing media type representation 798 Instead, we assume for now that CoAP-01 will switch to a single-byte 799 media type encoding. 801 Appendix B. Experimental Options 803 This annex documents proposals that need significant additional 804 discussion before they can become part of (or go back to) the main 805 CoAP specification. They are not dead, but might die if there turns 806 out to be no good way to solve the problem. 808 B.1. Options indicating absolute time 810 HTTP has a number of headers that may indicate absolute time: 812 o "Date", defined in Section 14.18 in [RFC2616] (Section 9.3 in 813 [I-D.ietf-httpbis-p1-messaging]), giving the absolute time a 814 response was generated; 816 o "Last-Modified", defined in Section 14.29 in [RFC2616], (Section 817 6.6 in [I-D.ietf-httpbis-p4-conditional], giving the absolute time 818 of when the origin server believes the resource representation was 819 last modified; 821 o "If-Modified-Since", defined in Section 14.25 in [RFC2616], 822 "If-Unmodified-Since", defined in Section 14.28 in [RFC2616], and 823 "If-Range", defined in Section 14.27 in [RFC2616] can be used to 824 supply absolute time to gate a conditional request; 826 o "Expires", defined in Section 14.21 in [RFC2616] (Section 3.3 in 827 [I-D.ietf-httpbis-p6-cache]), giving the absolute time after which 828 a response is considered stale. 830 o The more obscure headers "Retry-After", defined in Section 14.37 831 in [RFC2616], and "Warning", defined in section 14.46 in 832 [RFC2616], also may employ absolute time. 834 [I-D.ietf-core-coap] defines a single "Date" option, which however 835 "indicates the creation time and date of a given resource 836 representation", i.e., is closer to a "Last-Modified" HTTP header. 837 HTTP's caching rules [I-D.ietf-httpbis-p6-cache] make use of both 838 "Date" and "Last-Modified", combined with "Expires". The specific 839 semantics required for CoAP needs further consideration. 841 In addition to the definition of the semantics, an encoding for 842 absolute times needs to be specified. 844 In UNIX-related systems, it is customary to indicate absolute time as 845 an integer number of seconds, after midnight UTC, January 1, 1970. 846 Unless negative numbers are employed, this time format cannot 847 represent time values prior to January 1, 1970, which probably is not 848 required for the uses ob absolute time in CoAP. 850 If a 32-bit integer is used and allowance is made for a sign-bit in a 851 local implementation, the latest UTC time value that can be 852 represented by the resulting 31 bit integer value is 03:14:07 on 853 January 19, 2038. If the 32-bit integer is used as an unsigned 854 value, the last date is 2106-02-07, 06:28:15. 856 The reach can be extended by: - moving the epoch forward, e.g. by 40 857 years (= 1262304000 seconds) to 2010-01-01. This makes it impossible 858 to represent Last-Modified times in that past (such as could be 859 gatewayed in from HTTP). - extending the number of bits, e.g. by one 860 more byte, either always or as one of two formats, keeping the 32-bit 861 variant as well. 863 Also, the resolution can be extended by expressing time in 864 milliseconds etc., requiring even more bits (e.g., a 48-bit unsigned 865 integer of milliseconds would last well after year 9999.) 867 For experiments, an experimental "Date" option is defined with the 868 semantics of HTTP's "Last-Modified". It can carry an unsigned 869 integer of 32, 40, or 48 bits; 32- and 40-bit integers indicate the 870 absolute time in seconds since 1970-01-01 00:00 UTC, while 48-bit 871 integers indicate the absolute time in milliseconds since 1970-01-01 872 00:00 UTC. 874 However, that option is not really that useful until there is a 875 "If-Modified-Since" option as well. 877 Appendix C. Rationale: Representing Durations 879 C.1. Text for section 3.2.1 of coap-01 881 Various message types used in CoAP need the representation of 882 *durations*, i.e. of the length of a timespan. In SI units, these 883 are measured in seconds. CoAP durations represent integer numbers of 884 seconds, but instead of representing these numbers as integers, a 885 more compact single-byte pseudo-floating-point (pseudo-FP) 886 representation is used (Figure 8). 888 0 1 2 3 4 5 6 7 889 +---+---+---+---+---+---+---+---+ 890 | 0... value | 891 +---+---+---+---+---+---+---+---+ 893 +---+---+---+---+---+---+---+---+ 894 | 1... mantissa | exponent | 895 +---+---+---+---+---+---+---+---+ 897 Figure 8: Duration in (8,4) pseudo-FP representation 899 If the high bit is clear, the entire n-bit value (including the high 900 bit) is the decoded value. If the high bit is set, the mantissa 901 (including the high bit, with the exponent field cleared out but 902 still present) is shifted left by the exponent to yield the decoded 903 value. 905 The (n,e)-pseudo-FP format can be decoded with a single line of code 906 (plus a couple of constant definitions), as demonstrated in Figure 9. 908 #define N 8 909 #define E 4 910 #define HIBIT (1 << (N - 1)) 911 #define EMASK ((1 << E) - 1) 912 #define MMASK ((1 << N) - 1 - EMASK) 914 #define DECODE_8_4(r) (r < HIBIT ? r : (r & MMASK) << (r & EMASK)) 916 Figure 9: Decoding an (8,4) pseudo-FP value 918 Note that a pseudo-FP encoder needs to consider rounding; different 919 applications of durations may favor rounding up or rounding down the 920 value encoded in the message. 922 The highest pseudo-FP value, represented by an all-ones byte (0xFF), 923 is reserved to indicate an indefinite duration. The next lower value 924 (0xEF) is thus the highest representable value and is decoded as 925 7340032 seconds, a little more than 12 weeks. 927 C.2. Rationale 929 Where CPU power and memory is abundant, a duration can almost always 930 be adequately represented by a non-negative floating-point number 931 representing that number of seconds. Historically, many APIs have 932 also used an integer representation, which limits both the resolution 933 (e.g., if the integer represents the duration in seconds) and often 934 the range (integer machine types have range limits that may become 935 relevant). UNIX's "time_t" (which is used for both absolute time and 936 durations) originally was a signed 32-bit value of seconds, but was 937 later complemented by an additional integer to add microsecond 938 ("struct timeval") and then later nanosecond ("struct timespec") 939 resolution. 941 Three decisions need to be made for each application of the concept 942 of duration: 944 o the *resolution*. What rounding error is acceptable? 946 o the *range*. What is the maximum duration that needs to be 947 represented? 949 o the *number of bits* that can be expended. 951 Obviously, these decisions are interrelated. Typically, a large 952 range needs a large number of bits, unless resolution is traded. For 953 most applications, the actual requirement for resolution are limited 954 for longer durations, but can be more acute for shorter durations. 956 C.3. Pseudo-Floating Point 958 Constrained systems typically avoid the use of floating-point (FP) 959 values, as 961 o simple CPUs often don't have support for floating-point datatypes 963 o software floating-point libraries are expensive in code size and 964 slow. 966 In addition, floating-point datatypes used to be a significant 967 element of market differentiation in CPU design; it has taken the 968 industry a long time to agree on a standard floating point 969 representation. 971 These issues have led to protocols that try to constrain themselves 972 to integer representation even where the ability of a floating point 973 representation to trade range for resolution would be beneficial. 975 The idea of introducing _pseudo-FP_ is to obtain the increased range 976 provided by embedding an exponent, without necessarily getting stuck 977 with hardware datatypes or inefficient software floating-point 978 libraries. 980 For the purposes of this draft, we define an (n,e)-pseudo-FP as a 981 fixed-length value of n bits, e of which may be used for an exponent. 982 Figure 8 illustrates an (8,4)-pseudo-FP value. 984 If the high bit is clear, the entire n-bit value (including the high 985 bit) is the decoded value. If the high bit is set, the mantissa 986 (including the high bit, but with the exponent field cleared out) is 987 shifted left by the exponent to yield the decoded value. 989 The (n,e)-pseudo-FP format can be decoded with a single line of code 990 (plus a couple of constant definition), as demonstrated in Figure 9. 992 Only non-negative numbers can be represented by this format. It is 993 designed to provide full integer resolution for values from 0 to 994 2^(n-1)-1, i.e., 0 to 127 in the (8,4) case, and a mantissa of n-e 995 bits from 2^(n-1) to (2^n-2^e)*2^(2^e-1), i.e., 128 to 7864320 in the 996 (8,4) case. By choosing e carefully, resolution can be traded 997 against range. 999 Note that a pseudo-FP encoder needs to consider rounding; different 1000 applications of durations may favor rounding up or rounding down the 1001 value encoded in the message. This requires a little more than a 1002 single line of code (which is left as an exercise to the reader, as 1003 the most efficient expression depends on hardware details). 1005 C.4. A Duration Type for CoAP 1007 CoAP needs durations in a number of places. In [I-D.ietf-core-coap], 1008 durations occur in the option "Subscription-lifetime" as well as in 1009 the option "Max-age". (Note that the option "Date" is not a 1010 duration, but a point in time.) Other durations of this kind may be 1011 added later. 1013 Most durations relevant to CoAP are best expressed with a minimum 1014 resolution of one second. More detailed resolutions are unlikely to 1015 provide much benefit. 1017 The range of lifetimes and caching ages are probably best kept below 1018 the order of magnitude of months. An (8,4)-pseudo-FP has the maximum 1019 value of 7864320, which is about 91 days; this appears to be adequate 1020 for a subscription lifetime and probably even for a maximum cache 1021 age. Figure 10 shows the values that can be expressed. (If a larger 1022 range for the latter is indeed desired, an (8,5)-pseudo-FP could be 1023 used; this would last 15 milleniums, at the cost of having only 3 1024 bits of accuracy for values larger than 127 seconds.) 1026 Proposal: A single duration type is used throughout CoAP, based on 1027 an (8,4)-pseudo-FP giving a duration in seconds. 1029 Benefits: Implementations can use a single piece of code for 1030 managing all CoAP-related durations. 1032 In addition, length information never needs to be managed for 1033 durations that are embedded in other data structures: All 1034 durations are expressed by a single byte. 1036 It might be worthwhile to reserve one duration value, e.g. 0xFF, for 1037 an indefinite duration. 1039 Duration Seconds Encoded 1040 ----------- ---------- ------- 1041 00:00:00 0x00000000 0x00 1042 00:00:01 0x00000001 0x01 1043 00:00:02 0x00000002 0x02 1044 00:00:03 0x00000003 0x03 1045 00:00:04 0x00000004 0x04 1046 00:00:05 0x00000005 0x05 1047 00:00:06 0x00000006 0x06 1048 00:00:07 0x00000007 0x07 1049 00:00:08 0x00000008 0x08 1050 00:00:09 0x00000009 0x09 1051 00:00:10 0x0000000a 0x0a 1052 00:00:11 0x0000000b 0x0b 1053 00:00:12 0x0000000c 0x0c 1054 00:00:13 0x0000000d 0x0d 1055 00:00:14 0x0000000e 0x0e 1056 00:00:15 0x0000000f 0x0f 1057 00:00:16 0x00000010 0x10 1058 00:00:17 0x00000011 0x11 1059 00:00:18 0x00000012 0x12 1060 00:00:19 0x00000013 0x13 1061 00:00:20 0x00000014 0x14 1062 00:00:21 0x00000015 0x15 1063 00:00:22 0x00000016 0x16 1064 00:00:23 0x00000017 0x17 1065 00:00:24 0x00000018 0x18 1066 00:00:25 0x00000019 0x19 1067 00:00:26 0x0000001a 0x1a 1068 00:00:27 0x0000001b 0x1b 1069 00:00:28 0x0000001c 0x1c 1070 00:00:29 0x0000001d 0x1d 1071 00:00:30 0x0000001e 0x1e 1072 00:00:31 0x0000001f 0x1f 1073 00:00:32 0x00000020 0x20 1074 00:00:33 0x00000021 0x21 1075 00:00:34 0x00000022 0x22 1076 00:00:35 0x00000023 0x23 1077 00:00:36 0x00000024 0x24 1078 00:00:37 0x00000025 0x25 1079 00:00:38 0x00000026 0x26 1080 00:00:39 0x00000027 0x27 1081 00:00:40 0x00000028 0x28 1082 00:00:41 0x00000029 0x29 1083 00:00:42 0x0000002a 0x2a 1084 00:00:43 0x0000002b 0x2b 1085 00:00:44 0x0000002c 0x2c 1086 00:00:45 0x0000002d 0x2d 1087 00:00:46 0x0000002e 0x2e 1088 00:00:47 0x0000002f 0x2f 1089 00:00:48 0x00000030 0x30 1090 00:00:49 0x00000031 0x31 1091 00:00:50 0x00000032 0x32 1092 00:00:51 0x00000033 0x33 1093 00:00:52 0x00000034 0x34 1094 00:00:53 0x00000035 0x35 1095 00:00:54 0x00000036 0x36 1096 00:00:55 0x00000037 0x37 1097 00:00:56 0x00000038 0x38 1098 00:00:57 0x00000039 0x39 1099 00:00:58 0x0000003a 0x3a 1100 00:00:59 0x0000003b 0x3b 1101 00:01:00 0x0000003c 0x3c 1102 00:01:01 0x0000003d 0x3d 1103 00:01:02 0x0000003e 0x3e 1104 00:01:03 0x0000003f 0x3f 1105 00:01:04 0x00000040 0x40 1106 00:01:05 0x00000041 0x41 1107 00:01:06 0x00000042 0x42 1108 00:01:07 0x00000043 0x43 1109 00:01:08 0x00000044 0x44 1110 00:01:09 0x00000045 0x45 1111 00:01:10 0x00000046 0x46 1112 00:01:11 0x00000047 0x47 1113 00:01:12 0x00000048 0x48 1114 00:01:13 0x00000049 0x49 1115 00:01:14 0x0000004a 0x4a 1116 00:01:15 0x0000004b 0x4b 1117 00:01:16 0x0000004c 0x4c 1118 00:01:17 0x0000004d 0x4d 1119 00:01:18 0x0000004e 0x4e 1120 00:01:19 0x0000004f 0x4f 1121 00:01:20 0x00000050 0x50 1122 00:01:21 0x00000051 0x51 1123 00:01:22 0x00000052 0x52 1124 00:01:23 0x00000053 0x53 1125 00:01:24 0x00000054 0x54 1126 00:01:25 0x00000055 0x55 1127 00:01:26 0x00000056 0x56 1128 00:01:27 0x00000057 0x57 1129 00:01:28 0x00000058 0x58 1130 00:01:29 0x00000059 0x59 1131 00:01:30 0x0000005a 0x5a 1132 00:01:31 0x0000005b 0x5b 1133 00:01:32 0x0000005c 0x5c 1134 00:01:33 0x0000005d 0x5d 1135 00:01:34 0x0000005e 0x5e 1136 00:01:35 0x0000005f 0x5f 1137 00:01:36 0x00000060 0x60 1138 00:01:37 0x00000061 0x61 1139 00:01:38 0x00000062 0x62 1140 00:01:39 0x00000063 0x63 1141 00:01:40 0x00000064 0x64 1142 00:01:41 0x00000065 0x65 1143 00:01:42 0x00000066 0x66 1144 00:01:43 0x00000067 0x67 1145 00:01:44 0x00000068 0x68 1146 00:01:45 0x00000069 0x69 1147 00:01:46 0x0000006a 0x6a 1148 00:01:47 0x0000006b 0x6b 1149 00:01:48 0x0000006c 0x6c 1150 00:01:49 0x0000006d 0x6d 1151 00:01:50 0x0000006e 0x6e 1152 00:01:51 0x0000006f 0x6f 1153 00:01:52 0x00000070 0x70 1154 00:01:53 0x00000071 0x71 1155 00:01:54 0x00000072 0x72 1156 00:01:55 0x00000073 0x73 1157 00:01:56 0x00000074 0x74 1158 00:01:57 0x00000075 0x75 1159 00:01:58 0x00000076 0x76 1160 00:01:59 0x00000077 0x77 1161 00:02:00 0x00000078 0x78 1162 00:02:01 0x00000079 0x79 1163 00:02:02 0x0000007a 0x7a 1164 00:02:03 0x0000007b 0x7b 1165 00:02:04 0x0000007c 0x7c 1166 00:02:05 0x0000007d 0x7d 1167 00:02:06 0x0000007e 0x7e 1168 00:02:07 0x0000007f 0x7f 1169 00:02:08 0x00000080 0x80 1170 00:02:24 0x00000090 0x90 1171 00:02:40 0x000000a0 0xa0 1172 00:02:56 0x000000b0 0xb0 1173 00:03:12 0x000000c0 0xc0 1174 00:03:28 0x000000d0 0xd0 1175 00:03:44 0x000000e0 0xe0 1176 00:04:00 0x000000f0 0xf0 1177 00:04:16 0x00000100 0x81 1178 00:04:48 0x00000120 0x91 1179 00:05:20 0x00000140 0xa1 1180 00:05:52 0x00000160 0xb1 1181 00:06:24 0x00000180 0xc1 1182 00:06:56 0x000001a0 0xd1 1183 00:07:28 0x000001c0 0xe1 1184 00:08:00 0x000001e0 0xf1 1185 00:08:32 0x00000200 0x82 1186 00:09:36 0x00000240 0x92 1187 00:10:40 0x00000280 0xa2 1188 00:11:44 0x000002c0 0xb2 1189 00:12:48 0x00000300 0xc2 1190 00:13:52 0x00000340 0xd2 1191 00:14:56 0x00000380 0xe2 1192 00:16:00 0x000003c0 0xf2 1193 00:17:04 0x00000400 0x83 1194 00:19:12 0x00000480 0x93 1195 00:21:20 0x00000500 0xa3 1196 00:23:28 0x00000580 0xb3 1197 00:25:36 0x00000600 0xc3 1198 00:27:44 0x00000680 0xd3 1199 00:29:52 0x00000700 0xe3 1200 00:32:00 0x00000780 0xf3 1201 00:34:08 0x00000800 0x84 1202 00:38:24 0x00000900 0x94 1203 00:42:40 0x00000a00 0xa4 1204 00:46:56 0x00000b00 0xb4 1205 00:51:12 0x00000c00 0xc4 1206 00:55:28 0x00000d00 0xd4 1207 00:59:44 0x00000e00 0xe4 1208 01:04:00 0x00000f00 0xf4 1209 01:08:16 0x00001000 0x85 1210 01:16:48 0x00001200 0x95 1211 01:25:20 0x00001400 0xa5 1212 01:33:52 0x00001600 0xb5 1213 01:42:24 0x00001800 0xc5 1214 01:50:56 0x00001a00 0xd5 1215 01:59:28 0x00001c00 0xe5 1216 02:08:00 0x00001e00 0xf5 1217 02:16:32 0x00002000 0x86 1218 02:33:36 0x00002400 0x96 1219 02:50:40 0x00002800 0xa6 1220 03:07:44 0x00002c00 0xb6 1221 03:24:48 0x00003000 0xc6 1222 03:41:52 0x00003400 0xd6 1223 03:58:56 0x00003800 0xe6 1224 04:16:00 0x00003c00 0xf6 1225 04:33:04 0x00004000 0x87 1226 05:07:12 0x00004800 0x97 1227 05:41:20 0x00005000 0xa7 1228 06:15:28 0x00005800 0xb7 1229 06:49:36 0x00006000 0xc7 1230 07:23:44 0x00006800 0xd7 1231 07:57:52 0x00007000 0xe7 1232 08:32:00 0x00007800 0xf7 1233 09:06:08 0x00008000 0x88 1234 10:14:24 0x00009000 0x98 1235 11:22:40 0x0000a000 0xa8 1236 12:30:56 0x0000b000 0xb8 1237 13:39:12 0x0000c000 0xc8 1238 14:47:28 0x0000d000 0xd8 1239 15:55:44 0x0000e000 0xe8 1240 17:04:00 0x0000f000 0xf8 1241 18:12:16 0x00010000 0x89 1242 20:28:48 0x00012000 0x99 1243 22:45:20 0x00014000 0xa9 1244 1d 01:01:52 0x00016000 0xb9 1245 1d 03:18:24 0x00018000 0xc9 1246 1d 05:34:56 0x0001a000 0xd9 1247 1d 07:51:28 0x0001c000 0xe9 1248 1d 10:08:00 0x0001e000 0xf9 1249 1d 12:24:32 0x00020000 0x8a 1250 1d 16:57:36 0x00024000 0x9a 1251 1d 21:30:40 0x00028000 0xaa 1252 2d 02:03:44 0x0002c000 0xba 1253 2d 06:36:48 0x00030000 0xca 1254 2d 11:09:52 0x00034000 0xda 1255 2d 15:42:56 0x00038000 0xea 1256 2d 20:16:00 0x0003c000 0xfa 1257 3d 00:49:04 0x00040000 0x8b 1258 3d 09:55:12 0x00048000 0x9b 1259 3d 19:01:20 0x00050000 0xab 1260 4d 04:07:28 0x00058000 0xbb 1261 4d 13:13:36 0x00060000 0xcb 1262 4d 22:19:44 0x00068000 0xdb 1263 5d 07:25:52 0x00070000 0xeb 1264 5d 16:32:00 0x00078000 0xfb 1265 6d 01:38:08 0x00080000 0x8c 1266 6d 19:50:24 0x00090000 0x9c 1267 7d 14:02:40 0x000a0000 0xac 1268 8d 08:14:56 0x000b0000 0xbc 1269 9d 02:27:12 0x000c0000 0xcc 1270 9d 20:39:28 0x000d0000 0xdc 1271 10d 14:51:44 0x000e0000 0xec 1272 11d 09:04:00 0x000f0000 0xfc 1273 12d 03:16:16 0x00100000 0x8d 1274 13d 15:40:48 0x00120000 0x9d 1275 15d 04:05:20 0x00140000 0xad 1276 16d 16:29:52 0x00160000 0xbd 1277 18d 04:54:24 0x00180000 0xcd 1278 19d 17:18:56 0x001a0000 0xdd 1279 21d 05:43:28 0x001c0000 0xed 1280 22d 18:08:00 0x001e0000 0xfd 1281 24d 06:32:32 0x00200000 0x8e 1282 27d 07:21:36 0x00240000 0x9e 1283 30d 08:10:40 0x00280000 0xae 1284 33d 08:59:44 0x002c0000 0xbe 1285 36d 09:48:48 0x00300000 0xce 1286 39d 10:37:52 0x00340000 0xde 1287 42d 11:26:56 0x00380000 0xee 1288 45d 12:16:00 0x003c0000 0xfe 1289 48d 13:05:04 0x00400000 0x8f 1290 54d 14:43:12 0x00480000 0x9f 1291 60d 16:21:20 0x00500000 0xaf 1292 66d 17:59:28 0x00580000 0xbf 1293 72d 19:37:36 0x00600000 0xcf 1294 78d 21:15:44 0x00680000 0xdf 1295 84d 22:53:52 0x00700000 0xef 1296 91d 00:32:00 0x00780000 0xff (reserved) 1298 Figure 10 1300 Authors' Addresses 1302 Carsten Bormann 1303 Universitaet Bremen TZI 1304 Postfach 330440 1305 Bremen D-28359 1306 Germany 1308 Phone: +49-421-218-63921 1309 Fax: +49-421-218-7000 1310 Email: cabo@tzi.org 1312 Klaus Hartke 1313 Universitaet Bremen TZI 1314 Postfach 330440 1315 Bremen D-28359 1316 Germany 1318 Phone: +49-421-218-63905 1319 Fax: +49-421-218-7000 1320 Email: hartke@tzi.org