idnits 2.17.1 draft-frank-6lowapp-chopan-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 193 has weird spacing: '... method meth...' == Line 203 has weird spacing: '... utf optio...' == Line 284 has weird spacing: '... u2|str value...' -- The document date (September 11, 2009) is 5342 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HTTP' is mentioned on line 768, but not defined == Missing Reference: 'Chopan' is mentioned on line 768, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Frank 3 Internet-Draft Tridium, Inc 4 Intended status: Standards Track September 11, 2009 5 Expires: March 15, 2010 7 Chopan - Compressed HTTP Over PANs 8 draft-frank-6lowapp-chopan-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 15, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes a method for compressing HTTP messages into a 47 binary format to be transmitted using UDP over 6LoWPAN wireless 48 networks. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 54 1.2. Security Considerations . . . . . . . . . . . . . . . . . 3 55 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Datagram Format . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Format Notation . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Request Format . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Response Format . . . . . . . . . . . . . . . . . . . . . 6 60 2.4. Compressed Headers . . . . . . . . . . . . . . . . . . . . 7 61 2.5. Mime Type Codes . . . . . . . . . . . . . . . . . . . . . 9 62 2.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3. UDP Transmission . . . . . . . . . . . . . . . . . . . . . . . 11 64 4. Transaction-Id . . . . . . . . . . . . . . . . . . . . . . . . 12 65 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 5.1. Cache Control . . . . . . . . . . . . . . . . . . . . . . 13 67 5.2. ETag Validation . . . . . . . . . . . . . . . . . . . . . 14 68 5.3. Interception Proxy Caching . . . . . . . . . . . . . . . . 15 69 5.4. Sleeping Nodes . . . . . . . . . . . . . . . . . . . . . . 16 70 5.5. Cache Refresh . . . . . . . . . . . . . . . . . . . . . . 17 71 5.6. Caching non-GET Methods . . . . . . . . . . . . . . . . . 18 72 6. HTTP to Chopan Gateways . . . . . . . . . . . . . . . . . . . 20 73 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 23 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 1. Introduction 79 The Pervasive Internet is a vision that everyday devices with 80 microprocessors are woven into the fabric of the Internet. One of 81 the critical emerging technologies in this domain is 6LoWPAN which 82 enables low cost, low power devices to communicate using the Internet 83 Protocol. 6LoWPAN is the first step towards building the Pervasive 84 Internet. Chopan defines the next step: integrating 6LoWPAN devices 85 with the World Wide Web to leverage the massive investment in 86 existing URI and HTTP infrastructure. 88 Chopan is derived from HTTP with these changes: 90 o UDP: utilizes UDP packets instead of TCP as the underlying 91 transport protocol 93 o Binary compression: HTTP headers are compressed into a binary 94 format to save bandwidth and buffer space 96 o Interception Caches: transparent caching is used to minimize PAN 97 traffic and manage sleeping nodes 99 o Gateways: may be used to translate between full HTTP and Chopan to 100 interoperate with the existing Web infrastructure 102 1.1. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 1.2. Security Considerations 110 Discussed in Section 7. 112 1.3. Terminology 114 6LoWPAN: IPv6 for Low power Personal Area Networks described in 115 [RFC4944]. 117 Compression: translation from of a TCP/HTTP text based message into a 118 compressed binary UDP/Chopan message (gateway functionality). 120 Decompression: translation from of a binary UDP/Chopan message into a 121 TCP/HTTP text based message (gateway functionality). 123 Gateway: a node which transparently translates between HTTP and 124 Chopan messages. 126 HTTP: Hyper Text Transfer Protocol described in [RFC2616]. 128 PAN: Personal Area Network - an IP sub-network with constrained 129 bandwidth and/or constrained computing devices. This specification 130 is designed for low power PANs running 6LoWPAN, but Chopan is an 131 ideal solution for any network with bandwidth or computing 132 restraints. 134 Interception Proxy Cache: a node which transparently intercepts HTTP 135 requests to an origin server and returns cached responses on its 136 behalf. 138 Origin Server: the server on which the master version of resource 139 resides. 141 Resource: an abstract unit of information identified with a URI and 142 transported over a network using a MIME typed representation. 144 Sleeping Nodes: battery powered network nodes which spend most of 145 their time in a hibernation state to converse power. 147 TCP: Transmission Control Protocol described in [RFC0793]. 149 UDP: User Datagram Protocol described in [RFC0768]. 151 UTF-8: Encoding of Unicode characters compatible with ASCII described 152 in [RFC2279] 154 2. Datagram Format 156 Chopan uses a customized binary encoding for HTTP requests and 157 responses to achieve message compression into a UDP packet. A two 158 byte magic number is used to identify the packet as a Chopan message 159 - "h6" for requests and "H6" for responses. Both requests and 160 responses allow for zero or more compressed headers. 162 Any bytes after the headers in the packet are considered the message- 163 body. The length of the message-body is implied by the packet length 164 (the Content-Length header MAY be omitted). The entire message MUST 165 fit with in a single UDP packet. When running over 6LoWPAN, messages 166 SHOULD fit into a single 802.15.4 frame to avoid fragmentation. 168 2.1. Format Notation 170 Message formats are described as a data structure using the following 171 primitive types: 173 o u1: an unsigned 8-bit byte 175 o u2: an unsigned 16-bit integer in network byte order 177 o str: UTF-8 [RFC2279] encoded text, followed by a null terminator 178 (0x00) byte 180 o x[]: an sequence of type x which contains zero or more occurrences 182 o x|y: either x OR y 184 2.2. Request Format 186 A normal HTTP request is composed of a request-line, a set of 187 request-headers, and the message-body. This information is 188 compressed in the following binary format: 190 request 191 { 192 u2 magic 0x6836 - ASCII "h6" 193 method method 194 str uri 195 header[] headers 196 u1 zero byte end of headers 197 u1[] message-body 198 } 200 method 201 { 202 u1 method-code 203 utf optional string value only if method-code is 0x80 204 } 206 The HTTP request-line contains three pieces of information: the 207 method, URI, and version. The URI is encoded as a null-terminated 208 UTF-8 string. Standard request methods are encoded into a byte as 209 follows: 211 Method Code ASCII Char 212 ------------ ---- ---------- 213 DELETE 0x44 D 214 GET 0x47 G 215 HEAD 0x48 H 216 OPTIONS 0x4F O 217 POST 0x50 P 218 PUT (Update) 0x55 U 219 TRACE 0x54 T 220 str value 0x80 - 222 Most standard methods are encoded into a single byte, for example 223 "GET" is encoded into the ASCII byte 'G'. If the method code is 224 0x80, then it is followed by a null terminated UTF-8 string. 226 2.3. Response Format 228 A normal HTTP response is composed of a status-line, response- 229 headers, and the message-body. This information is compressed in the 230 following binary format: 232 response 233 { 234 u2 magic - ASCII "H6" 235 u1 status-code 236 header[] headers 237 u1 zero byte end of headers 238 u1[] message-body 239 } 241 The HTTP status code is compressed into a single byte where the top 242 3-bits represent the 100s decimal digit, and the bottom 5-bits 243 represent the last two decimal digits. Example of binary mappings: 245 1xx -> 0x2X, b001x_xxxx 246 2xx -> 0x4X, b010x_xxxx 247 3xx -> 0x6X, b011x_xxxx 248 4xx -> 0x8X, b100x_xxxx 249 5xx -> 0xAX, b101x_xxxx 250 200 -> 0x40 // OK 251 404 -> 0x84 // Not Found 252 415 -> 0x4F // Unsupported Media Type 253 416 -> 0x50 // Requested range not satisfiable 254 417 -> 0x51 // Expectation Failed 256 2.4. Compressed Headers 258 Standardized HTTP request and response headers are compressed using 259 predefined binary codes. Compressed headers are encoded as follows: 261 header 262 { 263 u1 header-code (high bit determines encoding of value) 264 u2|str value (u2 or str based on header-code high bit) 265 } 267 Headers are encoded using a 8-bit header-code which represents the 268 header name. If the high bit (0x80) is clear in the header-code, 269 then the value is encoded as an unsigned 16-bit integer. If the high 270 bit is set, then the value is encoded as a null terminated UTF-8 271 string. The u2 value encoding allows compression on a header-by- 272 header basis. Refer to the table below how each header utilizes a u2 273 value. 275 If an HTTP header name does not have a standard binary encoding, then 276 it MAY be stripped at the proxy gateway, otherwise it can be passed 277 using its string name. Uncompressed header names are encoded as 278 follows: 280 uncompressed-header 281 { 282 u1 header-code is 0x7f (u2 val) or 0xff (str val) 283 str name encoded as null terminated string 284 u2|str value 285 } 287 The following table defines the header codes for standard HTTP 288 headers. Each code has the high bit clear indicating a u2 value. 289 Mask the code with 0x80 to obtain the str value code: 291 Header Code Notes 292 ------------------ ---- ------------------------------------------- 293 End-Of-Headers 0x00 zero indicates no more headers 294 Uncompressed 0x7F name string, u2/string value 295 Accept 0x01 u2 val: mime type code 296 Accept-Charset 0x02 297 Accept-Encoding 0x03 298 Accept-Language 0x04 299 Accept-Ranges 0x05 300 Age 0x06 u2 val: delta age in seconds 301 Allow 0x07 302 Authorization 0x08 303 Awake-Time 0x09 u2 val: seconds, used with check-in request 304 Cache-Control 0x0A u2 val: max-age in seconds 305 Connection 0x0B unsupported 306 Content-Encoding 0x0C 307 Content-Language 0x0D 308 Content-Length 0x0E u2 val: bytes; omit to imply by packet size 309 Content-Location 0x0F 310 Content-MD5 0x10 311 Content-Type 0x11 u2 val: mime type code 312 Cookie 0x12 313 Date 0x13 314 ETag 0x14 u2 val: etag is 4 digit upper case hex str 315 Expect 0x15 u2 val: uncompressed code 100 is 0x64 316 Expires 0x16 should be avoided (use max-age) 317 From 0x17 318 Host 0x18 319 If-Match 0x19 u2 val: etag is 4 digit upper case hex str 320 If-Modified-Since 0x1A should be avoided (use max-age) 321 If-None-Match 0x1B u2 val: etag is 4 digit upper case hex str 322 If-Range 0x1C 323 If-Unmodified-Since 0x1D should be avoided (use max-age) 324 Last-Modified 0x1E should be avoided (use age, max-age) 325 Location 0x1F 326 Max-Forwards 0x20 u2 val: number of hops 327 Pragma 0x21 obsolete 328 Proxy-Authenticate 0x22 329 Proxy-Authorization 0x23 330 Range 0x24 331 Referer 0x25 332 Retry-After 0x26 u2 val: seconds, used with 202 responses 333 Server 0x27 334 Set-Cookie 0x28 335 Sleep-Time 0X29 u2 val: seconds, used for check-in requests 336 TE 0x2A 337 Transaction-Id 0x2B u2 val: same as 4 digit upper case hex str 338 Trailer 0x2C unsupported 339 Transfer-Encoding 0x2D 340 Upgrade 0x2E 341 User-Agent 0x2F 342 Vary 0x30 343 Via 0x31 344 Warning 0x32 u2 val: uncompressed code 111 is 0x6F 345 WWW-Authenticate 0x33 347 2.5. Mime Type Codes 349 The Accept and Content-Type headers may be compressed into an 350 unsigned 16-bit type code using the following table: 352 Mime Type Code Notes 353 ------------------------ ------ ------------------------------- 354 application/octet-stream 0xA001 used for arbitrary binary files 355 text/plain 0xB001 charset implied to be UTF-8 356 text/html 0xB002 charset implied to be UTF-8 357 text/xml 0xB003 charset implied to be UTF-8 358 text/csv 0xB004 charset implied to be UTF-8 360 NOTE: we also need to give thought to what kind of information models 361 we use and how they are represented with existing or new MIME types. 362 For example we might want to use ASN.1 MIBs, binary oBIX, etc... 364 2.6. Example 366 Assume the following HTTP request: 368 GET /pt07 HTTP/1.1 369 Host: sensor2086.acme.com 370 Accept: text/plain 371 If-None-Match: "3A7F" 372 Cache-Control: max-age=900 374 The HTTP request above would be compressed into the following 375 sequence of hexadecimal bytes: 377 68 36 47 2F 70 74 30 37 00 01 B0 01 1B 3A 7F 0A 03 84 00 378 ^ ^ ^ ^ ^ ^ ^ 379 | | | | | | +- End 380 | | +- URI | | +- Cache-Control 381 | +- GET | +- If-None-Match 382 +- magic +- Accept 384 Note that we stripped the Host header and compressed Accept, If-None- 385 Match, and Cache-Control into two byte header values. 387 3. UDP Transmission 389 One of the primary characteristics of Chopan is the ability to 390 transmit HTTP requests and responses over UDP. Since HTTP was 391 originally designed to be run over TCP, we must make some design 392 trade-offs to layer the protocol over an unreliable packet based 393 transport. 395 Chopin follows the standard HTTP request/response model. A client 396 makes a Chopan request to a server with a request message. When the 397 server receives the request, it sends the client back a response 398 message. 400 Both the request and response messages MUST fit within one UDP 401 packet, as such large message bodies are not supported. However, the 402 Range header may be used to chunk the transfer of resources which do 403 not fit a single UDP packet. When running over 6LoWPAN, messages 404 SHOULD fit into a single 802.15.4 frame to avoid fragmentation. 406 Because UDP is unreliable, there is no guarantee that a server 407 receives a request, nor that a client receives the response. If a 408 client does not receive a response to its request after a reasonable 409 amount of time, then it SHOULD retry the request up to three times 410 before timing out. It is therefore possible that the server might 411 receive the same request multiple times. A request is "retry safe" 412 if it can be retried multiple times by the client without 413 compromising server state. Idempotent methods like GET and HEAD MUST 414 be retry safe. Methods such as PUT and DELETE should also be retry 415 safe since they atomically modify or delete the resource. Methods 416 like POST are typically not retry safe unless coupled with another 417 mechanism. In the next section we examine an extension to HTTP for 418 making requests retry safe with the Transaction-Id header. 420 UDP does not guarantee message order. Therefore, it is the client's 421 responsibility to impose message ordering if required. Message 422 ordering can be maintained by waiting for a response, before sending 423 the next request. When message ordering is not required, the client 424 MAY have multiple simultaneous outstanding requests. This can 425 increase throughput on networks with high latency. If performing 426 concurrent requests, clients SHOULD use the Transaction-Id header to 427 match responses to requests. 429 4. Transaction-Id 431 Due to the unreliable nature of UDP, requests and responses do not 432 have guaranteed delivery or ordering. This can particularly cause 433 problems when a non-idempotent request is received successfully by 434 the server, but the response packet is dropped. In this case the 435 client's expected behavior is to retry the request which might cause 436 the server to receive the same request multiple times. For methods 437 such as POST which are not implicitly retry-safe, we define a new 438 header called Transaction-Id. 440 Transaction-Id is a unique identifier generated by the client. The 441 tuple of the client's IP address, port number, and Transaction-Id 442 should be globally unique within the transaction's temporal window. 443 Any retries initiated by the client MUST include the same transaction 444 id in the retry requests. 446 When a server receives a request with a Transaction-Id header, it 447 MUST pass the identifier back to the client via the response's 448 Transaction-Id header. The server MAY also choose to utilize the 449 Transaction-Id to implement "at-most-once" semantics. It is a server 450 local matter to decide how to apply the transaction id for a given 451 HTTP method and resource. 453 If a client attempts to request a method on the resource which 454 requires a Transaction-Id header and fails to specify one, then the 455 server SHOULD respond with 400 Bad Request. 457 5. Caching 459 6LoWPAN networks are typified by a gateway device which acts as a 460 router or bridge between the PAN and the external IP network. Often 461 the external IP network is physically connected by high a bandwidth 462 technology such as Ethernet or WiFi. The PAN itself typically has 463 low bandwidth and is composed of resource constrained nodes. Often 464 times the nodes in a PAN are battery powered, and spend most of their 465 time sleeping. 467 Because of this physical architecture, it is desirable for the more 468 capable nodes in the PAN to serve as caches for the more constrained 469 devices. Effective use of caching enables Chopan to optimize both 470 bandwidth on the PAN and power on constrained devices. In the case 471 of a sleeping node, it allows proxies to immediately return cached 472 representations of resources. 474 5.1. Cache Control 476 HTTP [RFC2616] defines a sophisticated caching model in sections 13 477 and 14.9. This model has multiple caching features, often with 478 overlapping functionality. Since Chopan is targeted for resource 479 constrained devices, this specification recommends use of a subset of 480 the HTTP caching model based on resource age and max-age. 482 It is expected that most resources accessed by Chopan are 483 representations of sensor data. The nature of the sensor data 484 determines its cache life. For example a temperature sensor in a 485 room is likely to change very slowly, so it might have a cache life 486 of fifteen minutes. But a temperature sensor in an oven might have a 487 cache life of only ten seconds before it is considered stale data. 488 Chopan uses existing HTTP caching features to give both the client 489 and server a say in cache management. 491 When an origin server publishes a resource representation via a GET 492 request, it SHOULD specify the Age header. For example if a resource 493 represents a sensor, and that sensor was read 4 seconds ago, then the 494 Age header should be set to 4 seconds. If the resource has an age 495 less than 1 second, then set the Age header to 0. The Age header 496 SHOULD be compressed into a two byte value if less than 18.2 hours. 498 In cases when the origin server has knowledge about the cache life of 499 a given resource, it SHOULD set the Cache-Control header with a Max- 500 Age directive. Note that the two byte value encoding of Cache- 501 Control is implied to be Max-Age as a number of seconds. When the 502 server specifies Max-Age, it is directing upstream proxies and 503 clients how long to cache the resource. For example if a resource 504 specifies an Age of 4 seconds, and a Max-Age of 30 seconds, then the 505 resource should be cached for 26 seconds before it is considered 506 stale. 508 Clients MAY also specify the Cache-Control header with a Max-Age 509 directive on requests. In this case, the client is directing the 510 maximum amount of staleness which may be tolerated. For example if a 511 client requests a resource with a Max-Age of 10 seconds, and the 512 resource has an age of 8 seconds, then the server may respond with 513 the cached resource. If however the resource has an age older then 514 10 seconds, then the server should refresh its cache. In the case of 515 a proxy cache, this means contacting the origin server. In the case 516 of the origin server, it may require polling the sensor. 518 A resource is considered stale if its Age is greater than either Max- 519 Age specified by the server or the Max-Age specified by the client. 520 If a server node has a cached version of a resource which is stale, 521 it SHOULD always attempt to refresh its cache. If the cache cannot 522 be refreshed immediately because of normal operation (for example the 523 origin server is a sleeping node), then the stale resource should be 524 returned and the Warning header SHOULD be specified with the 110 525 status code (response is stale). If cache refresh fails abnormally 526 (for example the origin server cannot be contacted), then the stale 527 resource SHOULD be returned and the Warning header specified with the 528 111 status code (revalidation failed). 530 5.2. ETag Validation 532 Key to any caching strategy is cache validation, the mechanism used 533 by a client or proxy to refresh its cache with the origin server. 534 Often even though a cached resource has expired, the original 535 resource hasn't been modified. But in order to avoid re-transmitting 536 the entire resource the client and server must define a mechanism to 537 validate the cached copy. In HTTP this validation may be negotiated 538 using either timestamps or entity tags. Chopen discourages the use 539 of timestamps because often nodes do not support time clocks. 540 Instead entity tags SHOULD be used for cache validation. 542 An entity tag is an opaque hash of a given resource's version. It is 543 defined by the origin server using the ETag header. If possible, a 544 two byte etag should be used to allow for optimal compression. If an 545 etag was specified for a cached resource, then clients and proxies 546 SHOULD specify the If-None-Match header on cache refresh. The server 547 SHOULD respond with a 304 (Not Modified) response if the etag has 548 been not modified. 550 5.3. Interception Proxy Caching 552 In Chopan, caching is done transparently to the client via 553 "interception caching". Interception caching is a commonly used 554 technique used to insert HTTP caches between clients and origin 555 servers, without requiring client configuration. Clients send 556 packets to the origin server directly, but as these packets are 557 routed into the PAN, one of the routing nodes processes the message 558 directly on behalf of the origin server. This architecture requires 559 that routing nodes in the PAN are actively examining the packets 560 before they are routed to their destination address. 562 The downside to using interception caching, is that technically it 563 breaks the encapsulation of the IP stack - routing nodes must become 564 aware of an application level protocol. The upside to this design, 565 is that client nodes do not have be explicitly configured to know 566 about the proxies for every PAN. Since PANs have the potential to 567 add billions of new nodes to the Internet, it seems reasonable to 568 trade-off the purity of IP routing within the PAN to maintain the 569 simplicity of the Internet at large. 571 Interception caches SHOULD use a combination of the destination port 572 and the packet's magic two byte marker to sniff Chopan packets. By 573 default we assume Chopan runs on UDP port 80, although proxies SHOULD 574 make this configurable. 576 The lifecycle of an interception cache request: 578 1. The client sends a request to the origin server 580 2. The interception proxy traps the request 582 3. If the request can be immediately fulfilled by a cached 583 representation of that resource in the proxy, then the proxy 584 responds directly to client on behalf of the origin server using 585 the origin server's IP address 587 4. If the proxy has no cached representation of the resource (or the 588 cache has expired), then it makes its own request to the origin 589 server for the resource to update its cache, then performs step 3 590 to return the cached resource to the client 592 5. Cache might also be actively refreshed periodically (see Cache 593 Refresh) 595 This lifecycle assumes that the origin server is a powered device 596 which is awake during normal operation. If the origin server is a 597 battery powered device then the origin server is mostly likely 598 sleeping. This use case is discussed further in Sleeping Nodes 599 section. 601 Interception proxies SHOULD be transparent to the client. However, 602 when a proxy communicates directly with the origin server it has a 603 choice to forward the client's original packet (with the client's IP 604 address), or to initiate a new request (with the proxy's IP address). 605 Proxy's SHOULD initiate new requests using the proxy's own IP 606 address. This means that origin servers are effectively responding 607 directly to the proxy with no knowledge of the original client 608 request. The disadvantage of this model is that it breaks end-to-end 609 communication principles of the Internet. However this model 610 provides significant advantages: 612 o On 6LoWPAN it keeps IP addressing to intra-PAN nodes which results 613 in better compression (since we don't need to pass through the 614 external IP address); 616 o It ensures that the response gets routed directly back to the 617 proxy for caching; 619 o Gateways which are translating TCP/HTTP into UDP/Chopan do not 620 have UDP packets from the client to begin with (rather they are 621 translating from a TCP stream) 623 o Sleeping nodes which require active cache refresh must be polled 624 directly by the proxy 626 5.4. Sleeping Nodes 628 PANs commonly include battery powered nodes which spend most of their 629 time sleeping to conserve power. These nodes periodically wake up to 630 check sensors, perform computation, and catch up on network 631 communications. Because of their nature, sleeping nodes do not make 632 for reliable origin servers. Chopan handles this use case by 633 fronting all sleeping nodes with interception caches. This allows 634 all requests for resources on the sleeping nodes to be transparently 635 brokered by proxies. Proxies then synchronize their caches with the 636 sleeping nodes periodically during a "check-in" process. 638 The lifecycle for interception caching of sleeping nodes follows the 639 standard interception model detailed above. However, when a request 640 is made for a resource the proxy doesn't have in its cache, the 641 request cannot be immediately fulfilled. In this case the proxy 642 SHOULD return a 202 Accepted response indicating that background 643 processing is required before the request can be completed (waiting 644 for the sleeping node to wake up). The Retry-After header SHOULD be 645 set indicating the number of seconds before the request should be 646 tried again. The retry time should be based on the time it will take 647 the sleeping node to wake up, check-in, and give the proxy a chance 648 to refresh its cache. The Retry-After header can be estimated from 649 the Awake-Time and Sleep-Time headers (see below). 651 Sleeping nodes MUST be configured to check-in with their proxy or 652 proxies when they wake up. This is done by sending a POST request to 653 the "/ci" URI of each proxy. When a proxy node receives a check-in 654 request, it SHOULD respond with 200 OK response. The sleeping node 655 SHOULD use standard retry/timeout mechanism to ensure that the 656 check-in is received by the proxy. After the sleeping node has 657 checked-in, then the proxy SHOULD poll for all the resources in its 658 cache which require refreshing. This will include all new pending 659 resources which resulted in 202 responses. After the sleeping node 660 has given the proxy a chance to refresh its cache, it can go back to 661 sleep. 663 Sleeping nodes SHOULD specify the Awake-Time and Sleep-Time headers 664 in their check-in request. The Awake-Time header specifies how long 665 the node expects to stay awake to give the proxy a chance for cache 666 refresh. The Sleep-Time indicates how long the node expects to sleep 667 before the next check-in. A proxy should expect the next check-in 668 after the sum of Awake-Time and Sleep-Time has elapsed - this period 669 can then be used for estimating the proxy's Retry-After header. 671 5.5. Cache Refresh 673 Chopan proxies can take an active or a passive approach to cache 674 refresh. In a passive model, stale resources are allowed to expire 675 and are eventually flushed from the cache. New requests for the 676 resources are forwarded to the origin server, and the response is 677 used to refresh the cache. On the other hand, the proxy can actively 678 poll origin servers to refresh cached resources independent of client 679 requests. 681 For sleeping nodes, proxies MUST actively refresh their cache. This 682 is required because there are only limited windows of opportunity 683 while the node is awake for the proxy to refresh resources. 685 When the origin server is a powered node, either active or passive 686 cache refresh may be used. Using active refresh to proactively keep 687 caches refreshed can potentially decrease the latency of external 688 requests. 690 Cached resources can be in one of the following states: 692 o Pending: these are resources on sleeping nodes which have resulted 693 in a 202 response. Eventually we expect to poll the node on 694 check-in and turn them into fresh resources or invalid resources. 696 o Fresh: these are resources with an Age less than both the client's 697 and server's configured Max-Age. 699 o Stale: these are resources with an Age which exceeds either the 700 client's or server's Max-Age. The proxy may continue to maintain 701 stale resources in the cache for some period of time. 703 o Flushed: resources may be flushed from a cache at any time. 704 Normally stale resources are flushed after a timeout period. 705 However LRU caches may flush fresh resources if buffer space is 706 exceeded. 708 o Invalid: some proxies may maintain a cached representation of a 709 resource to indicate an error condition. This is helpful when a 710 proxy receives a request for a sleeping node and returns 202, then 711 after the check-in discovers the origin server returns 404 for the 712 resource. In this case the proxy SHOULD temporarily cache an 713 error return so that the client's next poll will receive a 404 714 instead of another 202. 716 5.6. Caching non-GET Methods 718 In most circumstances, clients make GET requests to retrieve 719 representations of resources. In this case, proxies are caching the 720 response which contains that resource representation. However 721 clients may also perform POST, PUT, or DELETE requests. In the case 722 where the origin server is a powered node, these requests SHOULD 723 always be immediately forwarded to the origin server. 725 However in the case of sleeping nodes, the proxy MUST cache the 726 request itself until the node wakes up and checks-in. Without this 727 functionality it would be impossible to perform these HTTP methods on 728 sleeping nodes. Non-GET methods to sleeping nodes MUST use a 729 Transaction-Id to associate the request with a specified client IP 730 address, port number, and transaction id. 732 Let's consider a transaction for a resource POST on a sleeping node: 734 1. Client POSTs to origin server with a unique transaction id 736 2. Proxy transparently intercepts the request, caches it, and 737 returns 202 739 3. Upon check-in the proxy forwards the request then caches the 740 response 742 4. Client waits for Retry-After, then resubmits POST request using 743 same transaction id 745 5. Proxy transparently intercepts the request and returns cached 746 response with the transaction id 748 6. HTTP to Chopan Gateways 750 Chopan leverages the HTTP standard in order to provide 751 interoperability with the World Wide Web. Interoperability is 752 achieved by using standard HTTP external to the PAN and using Chopan 753 internal to the PAN. Nodes which perform HTTP-Chopan translation are 754 called Chopan gateways: 756 o Requests into the PAN are translated from HTTP to Chopan. 758 o Requests from inside the PAN to the external network are 759 translated from Chopan to HTTP. 761 o Requests from inside the PAN to other nodes inside the PAN are 762 Chopan end-to-end 764 Diagram of gateway translations: 766 <= External | PAN => 767 Client -> [HTTP] -> Gateway -> [Chopan] -> Server 768 Server <- [HTTP] <- Gateway <- [Chopan] <- Client 770 Gateway translations SHOULD be performed transparently. Clients 771 external the PAN assume they are communicating HTTP directly to the 772 origin server. Gateways intercept these HTTP requests and translate 773 them into Chopan requests. Likewise responses are translated from 774 Chopan back to HTTP. 776 Because Chopan recommends that translation happens transparently, 777 this means that the gateway must be sniffing incoming packets for 778 TCP/HTTP requests. This design has all the same issues as detailed 779 in Interception Proxy Caching. It is expected that in most 780 implementations the gateway will also perform interception caching, 781 although this specification does not require it. 783 HTTP to Chopan is referred to as compression, and Chopan to HTTP is 784 referred to as decompression. During the compression process the 785 text format of requests and responses is encoded into Chopan's binary 786 message format. Each HTTP header is examined and mapped into its 787 binary encoding. Depending on the quality of the PAN link layer, the 788 compression process may strip out HTTP headers, according to these 789 priorities: 791 o Content type and cache-control headers SHOULD never be stripped 793 o Standard headers with u2 value encodings or short strings SHOULD 794 be maintained 796 o Standard headers without u2 value encodings or with longer strings 797 MAY be stripped 799 o Non-standard headers SHOULD be stripped (assuming typical PAN 800 constraints) 802 The Chopan compression and stripping of headers is a gateway to 803 origin server matter. This does not free the gateway from faithfully 804 implementing the full HTTP specification and abiding by its 805 conventions. In the cases where HTTP headers or functionality is 806 reduced to meet Chopan constraints, the gateway should compensate so 807 that the client's perspective is communication with a fully compliant 808 HTTP origin server. 810 7. Security 812 Ideally Internet protocols implement an end-to-end security model 813 between the two endpoint nodes. However it is difficult to implement 814 end-to-end session based security with unreliable packet protocols 815 and sleeping nodes. Rather Chopan, recommends that the security 816 strategy is divided between internal and external PAN nodes. 818 Internally all PAN nodes should be fully trusted using link layer 819 security such as the AES encryption specified by 802.15.4. 821 External to the PAN, the gateway should utilize full TCP/HTTP to 822 enable the well known security mechanisms associated with those 823 protocols. This includes TLS/HTTPS and the various HTTP 824 authentication mechanisms. 826 NOTE: A lot more to think about here... 828 8. Normative References 830 [RFC0768] Postel, J., "User Datagram Protocol", RFC 768, 831 August 1980. 833 [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, 834 September 1981. 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, March 1997. 839 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 840 10646", RFC 2279, January 1998. 842 [RFC2616] Fielding, R., "Hypertext Transfer Protocol -- HTTP/1.1", 843 RFC 2616, June 1999. 845 [RFC4944] Montenegro, G., "Transmission of IPv6 Packets over IEEE 846 802.15.4 Networks", RFC 4944, September 2007. 848 Author's Address 850 Brian Frank 851 Tridium, Inc 852 Richmond, VA 853 US 855 Email: brian.tridium@gmail.com