idnits 2.17.1 draft-aayadi-6lowpan-tcphc-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 4995 (Obsoleted by RFC 5795) ** Obsolete normative reference: RFC 4996 (Obsoleted by RFC 6846) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ayadi 3 Internet-Draft D. Ros 4 Intended status: Experimental L. Toutain 5 Expires: April 28, 2011 Telecom Bretagne 6 October 25, 2010 8 TCP header compression for 6LoWPAN 9 draft-aayadi-6lowpan-tcphc-01 11 Abstract 13 This document describes LOWPAN_TCPHC, a scheme for compressing the 14 header of Transmission Control Protocol (TCP) segments, in order to 15 reduce the overhead on low-power and lossy networks. It also 16 specifies the LOWPAN_TCPHC header fields for the transmission of TCP 17 segments over IPv6 for Low-power Wireless Personal Area Networks 18 (6LoWPAN). In many cases, the 20 bytes of the mandatory TCP header 19 can be compressed into as little as 6 bytes. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 28, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Connection Initiation . . . . . . . . . . . . . . . . . . 8 60 2.2. The LoWPAN_TCPHC context . . . . . . . . . . . . . . . . . 10 61 2.2.1. LoWPAN_TCPHC context structure . . . . . . . . . . . . 10 62 2.2.2. Context management . . . . . . . . . . . . . . . . . . 12 63 2.3. Loss detection and retransmissions . . . . . . . . . . . . 12 64 3. Transmission Control Protocol . . . . . . . . . . . . . . . . 13 65 3.1. TCP headers fields . . . . . . . . . . . . . . . . . . . . 14 66 3.2. TCP Header Options . . . . . . . . . . . . . . . . . . . . 15 67 4. TCP header fields compression . . . . . . . . . . . . . . . . 15 68 4.1. TCP ports . . . . . . . . . . . . . . . . . . . . . . . . 16 69 4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 4.3. Sequence and Acknowledgment numbers . . . . . . . . . . . 16 71 4.4. Window . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 4.5. Urgent Pointer . . . . . . . . . . . . . . . . . . . . . . 17 73 5. LOWPAN_TCPHC Packet Format . . . . . . . . . . . . . . . . . . 17 74 5.1. TCP segments types . . . . . . . . . . . . . . . . . . . . 17 75 5.2. LOWPAN_TCPHC Format . . . . . . . . . . . . . . . . . . . 18 76 5.3. Examples of compressed TCP headers . . . . . . . . . . . . 19 77 5.3.1. Compressed header . . . . . . . . . . . . . . . . . . 19 78 6. TCP Option Compression . . . . . . . . . . . . . . . . . . . . 19 79 6.1. Selective Acknowledgment option . . . . . . . . . . . . . 20 80 6.2. Timestamp option . . . . . . . . . . . . . . . . . . . . . 20 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 The 6LoWPAN Working Group [RFC4919] has proposed LOWPAN_IPHC 88 [I-D.ietf-6lowpan-hc], a new version of the LOWPAN_HC1 header 89 compression mechanism [RFC4944] which reduces the IPv6 header to 90 about 3-5 bytes. In [I-D.ietf-6lowpan-hc], a header-compression 91 method for the transport layer (LOWPAN_NHC) has also been introduced, 92 however, only a UDP [RFC0768] datagram compression mechanism is 93 specified. 95 UDP header compression is useful for 6LoWPAN because many Low-power 96 and Lossy Network (LLN) applications are fault-tolerant and do not 97 require 100% reliability. However, other applications and services 98 such as SSH and HTTP require a reliable service from the transport 99 layer that cannot be offered by UDP. Moreover, some usage scenarios 100 of LLNs, such as health, military and security applications, impose 101 strong reliability constraints. Also, in some usage cases (e.g., 102 sending a software update to a wireless node, or sending a query 103 requesting a specific information from the wireless node) there is a 104 need for a reliable data transport. 106 In this document, we focus on the Transmission Control Protocol (TCP) 107 [RFC0793], which carries most of the traffic in IP networks. TCP is 108 a connection-oriented, end-to-end reliable transport protocol. To 109 ensure end-to-end reliability, TCP must recover from packet 110 corruption, loss or out-of-order delivery. This is achieved by 111 assigning a sequence number to each transmitted byte (done by the TCP 112 source), by requiring a positive acknowledgment (ACK) from the TCP 113 destination, and by retransmitting lost or corrupted packets. 115 In the context of 6LoWPAN networks, the size of TCP headers may 116 induce a large overhead, especially for link-layer technologies that 117 use small frames. For instance, a pure TCP acknowledgment (i.e., a 118 TCP ACK carrying no data) without any TCP options represents 25% of 119 the payload of an IEEE 802.15.4 typically [IEEE 802.15.4] MAC frame. 120 In addition, TCP pure ACKs represent roughly 33% of the total number 121 of segments exchanged in a TCP session (this figure may go up to 122 roughly 50% if the Delayed ACK mechanism [RFC1122] is not used). 123 This suggests that the use of header-compression mechanisms for TCP 124 may result in important performance gains, in terms of used bandwidth 125 and/or energy spent for frame transmission. 127 A TCP header compression algorithm for 6LoWPAN should respect some 128 requirements: (a) Efficiency (the scheme must provide low overhead in 129 all cases), (b) Transparency (the resulting header after a 130 compression and decompression should be identical to the original 131 header), (c) Reordering tolerance (the scheme should be able to 132 decompress compressed segments correctly even when segments arrive 133 with a moderate reordering). 135 The goal of this document is thus to define a TCP header compression 136 scheme for 6LoWPAN, called LOWPAN_TCPHC, which allows to 137 significantly reduce the TCP overhead. The TCP header compression 138 and decompression is performed in the edge router between the 6LoWPAN 139 and the external IP network. The compression scheme can also be used 140 between two 6LoWPAN nodes for machine-to-machine communications. 141 This document defines also an encoding format for LOWPAN_TCPHC header 142 compression. Such mechanism and packet format aims at making TCP a 143 more viable proposition for 6LoWPAN networks. Moreover, the 144 LOWPAN_TCPHC mechanism can be used with LOWPAN_IPHC 145 [I-D.ietf-6lowpan-hc] and thus reduce all header overheads to about 146 seven to ten bytes instead of 60 bytes. 148 The proposed scheme does not compress TCP control messages at the 149 connection establishment phase. Those TCP segments are used to 150 exchange a context identifier. Such context identifier replaces the 151 port numbers in subsequent TCP segments, as a means of identifying a 152 given TCP session. Some TCP options, such as Timestamp [RFC2018] and 153 SACK [RFC1323] [RFC2883], are supported (i.e., compressed) by the 154 mechanism, while other options, unlikely to be required/used in 155 6LoWPANs, are omitted. 157 1.1. Related Work 159 This section presents prior work on TCP/IP header compression. In 160 particular, we will briefly describe three existing TCP header 161 compression algorithms. A more detailed discussion of these 162 algorithms can be found in [RFC4996]. 164 One of the first TCP/IP header compression methods was Compressed TCP 165 (CTCP), proposed by Jacobson [RFC1144]. Jacobson's header 166 compression algorithm distinguishes between dynamic fields and static 167 fields. The static fields (e.g., source address, source port, ...) 168 are sent in two situations: when initiating a connection, and when 169 refreshing the context after a loss of synchronization. CTCP 170 proposes to send the difference between the current and the previous 171 value of dynamic fields (e.g., sequence number, acknowledgment 172 number). When the synchronization is lost between the compressor and 173 the decompressor, the TCP sender sends a segment with a regular 174 header to refresh the context. Experimental studies [Perkins et al.] 175 [Srivastava et al.] [Wang04] have shown that the performance of 176 Jacobson's algorithm may degrade significantly in noisy/lossy network 177 environments. An important disadvantage of CTCP is that it does not 178 support TCP options, some of which are ubiquitous nowadays 179 [Medina05]. 181 IPHC [RFC2507] enhances Jacobson's TCP header compression by 182 introducing a mechanism, called TWICE, to repair incorrectly- 183 decompressed headers. TWICE is most efficient when applied to data- 184 carrying TCP segments. [RFC2507] also describes a mechanism for 185 explicitly requesting the transmission of less-compressed or 186 uncompressed headers. such mechanism is especially suited for pure 187 TCP acknowledgments. Note however that IPHC does not actually 188 provide a compression method for TCP options; changing option fields 189 are carried in compressed headers, but without any compression. 190 Also, the header request mechanism may be unsuited for lossy 6LoWPAN 191 networks, which low bit rates and strong energy constraints are at 192 odds with any additional signaling overhead. LoWPAN_TCPHC enhances 193 IPHC by defining an adapted header compression of TCP for LLNs by 194 sending lest significant bytes instead of sending a delta value. 195 Moreover, LoWPAN_TCPHC completes IPHC by defining header compression 196 schemes for the mostly used TCP options. 198 ROHC-TCP [RFC4996] improves on [RFC2507] by providing a new method 199 for compressing all TCP header fields, including the TCP options. 200 ROHC-TCP proposes also to start compressing packets starting from the 201 SYN segments, using parameters from previous or simultaneous 202 connections. This may offer noticeable improvements in performance 203 when most TCP flows are short-lived, i.e., composed of a small number 204 of data segments. Nevertheless, the ROHC-TCP algorithm is fairly 205 complex and its memory requirements may not be met by small, 206 constrained devices. 208 The algorithm described in this document, LOWPAN_TCPHC, supports 209 features like the compression of TCP options and FIN segments, and at 210 the same time it is relatively simple and easy to implement in 211 memory- and CPU-constrained devices. 213 1.2. Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 This section defines general terms related to TCP/IPv6 header 220 compression [RFC2507] [RFC4995] and to the 6LoWPAN architecture 221 [RFC4919] used in this specification. 223 o Subheader: An IPv6 header, a UDP header, or a TCP header. 224 o Header: A chain of subheaders. 225 o Compression: The act of reducing the size of a header by either 226 removing or reducing the size of header fields. This is done in a 227 way such that a decompressor can reconstruct the header if its 228 context state is identical to the context state used when 229 compressing the header. 230 o Decompression: The act of reconstructing a compressed header. 231 o Static fields: These fields are expected to be constant throughout 232 the lifetime of the TCP connection. Static information must be 233 communicated once in some way. 234 o Dynamic fields: These fields are expected to vary between 235 different TCP segments, either randomly within a limited range or 236 in some other manner. 237 o Context identifier (CID): A small unique number identifying the 238 context that should be used to decompress a compressed header. 239 Carried in full headers and compressed headers. 240 o Context: The state used by the compressor to compress a header, 241 and by the decompressor to decompress a header. The context is 242 given by the uncompressed version of the last header sent 243 (compressor) or received (decompressor) over the link, except for 244 fields in the header that are included "as-is" in compressed 245 headers, or that can be inferred from e.g. the size of the link- 246 layer frame. 247 o Full header: An uncompressed header that updates or refreshes the 248 context for a packet stream. It carries a CID that will be used 249 to identify the context. 250 o Regular header: A normal, uncompressed header. It does not carry 251 any CID. 252 o Compressed header: A header in which all the static fields are 253 elided, and all the dynamic fields are sent compressed. 254 o Incorrect decompression: When a decompressed header does not match 255 the corresponding original, uncompressed header. Usually due to 256 mismatching contexts between the compressor and decompressor, 257 caused by e.g. bit errors during the transmission of the 258 compressed header, or by packet loss. 259 o IEEE 802.15.4: A low-power, low-bandwidth link layer protocol. 260 o LoWPAN host: A node that only sources or sinks IPv6 datagrams. 261 Referred to as a host in this document. 262 o LoWPAN router: A node that forwards datagrams between arbitrary 263 source-destination pairs using a single 6LoWPAN interface, 264 performing IP routing on that interface. 265 o LoWPAN edge router (ER): An IPv6 router that interconnects the 266 6LoWPAN to another IP network. Referred to as an Edge Router in 267 this document. 268 o LoWPAN node: A node that composes a 6LoWPAN, referring to both 269 hosts and routers. Simply called a Node in this document. 271 2. Protocol Overview 273 This section gives an overview of the TCP header compression 274 mechanism for 6LoWPAN (LOWPAN_TCPHC). The main purpose of 275 LOWPAN_TCPHC is to reduce the protocol header overhead, with the 276 intent of reducing both bandwidth usage and energy consumption due to 277 packet transmissions. 279 Indeed, the LOWPAN_TCPHC allows establishing TCP connections between 280 an external IP host and a LoWPAN host, and also between two LoWPAN 281 hosts. This former type of connection is performed by an Edge Router 282 (ER) which links the 6LoWPAN to an external IPv6-based network. 283 Figure 1 shows a typical 6LoWPAN topology with which two edge router 284 create a bridge between the LoWPAN network and the external IP 285 network. The path between a LoWPAN node to the external network may 286 change following the movement of the node or the update of routing 287 tables. 289 | * * 290 | * * * 291 | +--------+ * * * * 292 |____| Edge | * * * * * 293 | | Router | * * * * * 294 | +--------+ * * * * 295 | * * * 296 External IP Network -- | * * * 297 | * * * 298 | +--------+ * * * * 299 |____| Edge | * * * * * 300 | | Router | * * * * * 301 | +--------+ * * * * 302 | * * * 303 | * * 304 *: LoWPAN Node 306 Figure 1: A 6LoWPAN network 308 The compression and decompression mechanisms are implemented on the 309 edge routers and on the LoWPAN hosts. The ERs create and maintain 310 the contexts of all TCP connections. Figure 2 and Figure 3 show 311 sequence diagrams of a connection establishment between a LoWPAN host 312 and an external IP host. The external IP host sends and receives 313 regular TCP segments, whereas the LoWPAN host sends and receives 314 segments with compressed headers or full headers. 316 The LOWPAN_TCPHC algorithm does not compress TCP control messages at 317 the connection establishment phase. These segments are used to 318 exchange the context identifier (CID) and allow the ER to create a 319 context using the TCP header fields. The LOWPAN_TCPHC algorithm 320 supports usefull TCP option for LLNs. Supported TCP options that are 321 negotiated in the two first messages are sent in a full header 322 format. Whereas, the remaining supported options are sent compressed 323 with in the TCP segments. The LOWPAN_TCPHC algorithm defines a 324 compression mechanism for TCP SACK and Timestamp options. 326 The TCP connection may also be established between two LoWPAN hosts 327 for Machine-to-Machine communications. In this case, the context 328 should be shared between the two LoWPAN hosts. If a packet is 329 dropped due to loss, then the mechanism refreshes the context by 330 retransmitting lost segments using the mostly compressed header 331 format. 333 The compression protocol uses two different header formats. For the 334 TCP opening phase and for error management, the TCP segments must be 335 sent with a full header. These segments contain the Context 336 Identifier (CID) which will be used to identify the connection during 337 the transfer phase. The CID replaces the two port numbers, hence 338 avoiding to send the port numbers in every packet. The CID value and 339 its size are set by the LoWPAN host if the TCP connection is between 340 a LoWPAN host and an external IP host. Otherwise (i.e., a TCP 341 connection between two LoWPAN hosts), the CID value and its size are 342 set by the LoWPAN host that has opened the connection. For the TCP 343 connection between a LoWPAN host and an external IP host, the couple 344 (CID, Ipv6 address) must be unique. 346 The second kind of header is the compressed header in which all 347 static fields are elided, and all dynamic fields are compressed. 348 Depending on how they change with respect to the last sent segment, 349 dynamic fields may be compressed fully (i.e., elided) or partially 350 (i.e., only a portion of a field is sent, containing the bytes that 351 have changed). 353 The last kind of packet is sent when a packet is lost, corruption or 354 reordering is detected by the TCP receiver. This segment is called 355 mostly compressed header and contains dynamic fields with all bytes 356 uncompressed, while its static fields are elided. This kind of 357 segment should be sent after a loss of synchronization between the 358 compressor and the decompressor. 360 2.1. Connection Initiation 362 This section gives an overview of TCP connection initiation with 363 LOWPAN_TCPHC. 365 External IP host Edge Router LoWPAN host 366 | | | 367 | --- SYN --> | --- SYN with CID=0--> | 368 | The LOWPAN host creates a context for the new TCP connection | 369 | | 370 | | <-- SYN/ACK with CID--- | 371 | The ER creates a context using the received (CID, LoWPAN IPv6) | 372 | | | 373 | <-- SYN/ACK --- | | 374 | --- ACK --> | --- ACK with CID -->| 375 | | | 377 Figure 2: TCP Connection initiated by an external IP-host 379 Figure 2 shows an example of a connection initiation scenario started 380 by an external IP host. In this scenario, an external host sends a 381 SYN segment trying to establish a connection with a LoWPAN host. The 382 SYN message can include options, some of which may be eliminated by 383 the Edge Router (i.e., those options not supported by the 384 LOWPAN_TCPHC mechanism). The ER sends the SYN segment in a full 385 header message with a CID equal to zero. Upon the reception of the 386 SYN segment, the LoWPAN node sends a SYN/ACK segment including a new 387 CID, set to the smallest available CID value. The ER creates a new 388 context with the received information from the SYN/ACK segment. 390 External IP host Edge Router LoWPAN host 391 | | | 392 | | <-- SYN with CID--- | 393 | The LOWPAN host creates a context and sends the SYN message | 394 | | 395 | <-- SYN --- | | 396 | The ER creates a context for the new TCP connection | 397 | | 398 | --- SYN/ACK --> | --- SYN/ACK with CID --> | 399 | <-- ACK --- | <-- ACK with CID --- | 401 Figure 3: TCP Connection initiated by a LoWPAN host 403 Figure 3 gives an example of a TCP connection initiated by a LoWPAN 404 host. The first SYN segment is sent with the full header with a CID 405 value equal to smallest available value of CIDs. Contrary to the 406 first case, the ER creates a context upon the reception of the SYN 407 message from the LoWPAN host. 409 LoWPAN host LoWPAN host 410 | | 411 | <-- SYN with CID--- | 412 | The initiator LOWPAN Host creates a context for the new | 413 | TCP connection and then sends SYN segment | 414 | | 415 | --- SYN/ACK with CID---> | 416 | The receiver creates a context using the initiator IID | 417 | | 418 | <-- ACK with CID --- | 420 Figure 4: TCP/IPv6 Connection between two LoWPAN hosts 422 Figure 4 presents a TCP connection initiated by a LoWPAN node to 423 another LoWPAN node. The LoWPAN host sends in the TCP SYN segment 424 with a CID equals to the smallest available CID value. 426 The CID value is chosen by the first LoWPAN host that is involved in 427 establishing the TCP connection. This way, it is easy to ensure the 428 unicity of the CID. At the same time, this simplifies the context 429 management at the ERs. Moreover, if all CID values are used, the 430 initiator should increase the CID field length from 8 bits to 16 431 bits. 433 2.2. The LoWPAN_TCPHC context 435 2.2.1. LoWPAN_TCPHC context structure 437 The context includes some TCP header fields that are needed by the 438 compressor and the decompressor algorithm. Figure 5 lists the 439 contents of a LOWPAN_TCPHC context. 441 +---------+------------------------------------+----------+ 442 | Field | Description | Length | 443 +---------+------------------------------------+----------+ 444 | CID | Context Identifier | 16 bits | 445 +---------+------------------------------------+----------+ 446 | Address | LoWPAN IPv6 address | 128 bits | 447 ---------+------------------------------------+----------+ 448 | SrcPort | TCP Source Port Number | 16 bits | 449 +---------+------------------------------------+----------+ 450 | DstPort | TCP Destination Port Number | 16 bits | 451 +---------+------------------------------------+----------+ 452 | seq_rcv | Sequence number in incoming segments | 32 bits | 453 +---------+------------------------------------+----------+ 454 | ack_rcv | Acknowledgment number in reception | 32 bits | 455 ---------+------------------------------------+----------+ 456 | wnd_rcv | Window size in reception | 16 bits | 457 ---------+------------------------------------+----------+ 458 | seq_snd | Sequence number in reception | 32 bits | 459 +---------+------------------------------------+----------+ 460 | ack_snd | Acknowledgment number in reception | 32 bits | 461 ---------+------------------------------------+----------+ 462 | wnd_snd | Window size in reception | 16 bits | 463 ---------+------------------------------------+----------+ 464 | State | Context state | 4 bits | 465 +---------+------------------------------------+----------+ 467 Figure 5: Structure of a LOWPAN_TCPHC context 469 The address field saves the Ipv6 address of the 6LoWPAN node. If the 470 TCP connection is established between two 6LoWPAN nodes, the Ipv6 471 address of the initiator is saved in the context. 473 State field indicates in which state a TCP connection is. This field 474 is especially needed by the ERs. The possible states of a context 475 are: closed, using, closing, fin_1, fin_2, fin_3, and shutting. 477 The CID and Ipv6 address are utilized to identify the connection for 478 compressed headers. The SrcPort and DstPort, toghether with the Ipv6 479 adsress, are used to identify the connection for full headers. 481 The seq_rcv, ack_rcv, and wnd_rcv are used to store the dynamic 482 fields of the last incoming segment (except retransmitted segment). 483 While the seq_snd, ack_snd, and wnd_snd are the dynamic fields of the 484 last outgoing segment (except retransmitted segment). 486 2.2.2. Context management 488 This section describes the context management in 6LoWPAN when 489 LOWPAN_TCPHC is used. The edge router to which a LoWPAN node host is 490 attached may change over time, due to route instability or to host 491 mobility However, this change should not break the TCP communication. 492 To ensure the TCP communication despite the change of ER, the ERs 493 should share the contexts of current connections. So, even if a 494 6LoWPAN node changes its attached ER, the new ER should continue to 495 compress the segments using the same context. Context exchange and 496 management between ERs is out of the scope of this document. 498 The edge router should free a context when a TCP connection is 499 finished (e.g., reception of FIN control messages). The Edge Router 500 can also free a connection after a silent period (i.e., when no 501 messages are exchanged after a certain period of time). 503 The ER may remove the context of a TCP connection that is not yet 504 closed. In this case, after receiving a new data segment, the ER 505 SHOULD reply by sending a RST segment to the sender. 507 2.3. Loss detection and retransmissions 509 In this section, we present how the LOWPAN_TCPHC mechanism should 510 react when a segment is lost or is assumed to be lost. The loss is 511 handled when the TCP ACK segment is not received within the RTO. The 512 ER handles a retransmission by scanning the sequence numbers. The ER 513 should send a mostly compressed header segment when it receives an 514 already sent segment. This mechanism allows updating the context on 515 both sides after a packet loss. We assume that the 6LoWPAN has a low 516 bit rate, and also that nodes are memory-constrained and thus the TCP 517 window size is probably limited to a few segments. In this case, the 518 loss of synchronization will likely not lead to a burst of losses. 519 For this reason, this document does not present a refresh algorithm 520 to update the context between the compressor and the decompressor. 522 External IP Host Edge Router LoWPAN Host 523 | | | 524 | --- Regular DATA(124) --> |--- Compressed header DATA(124) -->| 525 | <-- Regular ACK(188) --- | <-- Compressed header ACK(188) ---| 526 | --- Regular DATA(188) --> | --- Compressed header DATA(188) -X| 527 | Data packet (188) is lost in the LoWPAN | 528 | | | 529 | The External node handles the segment loss after an RTO | 530 | and retransmits the lost segment | 531 | | | 532 | --- Regular DATA(188) --> | --- Most Comp. DATA(188) -->| 533 | The ER compresses the retranmitted segment with a mostly | 534 | compressed header | 535 | | | 536 | <-- Regular ACK(252) --- | <-- Compressed header ACK(252) ---| 537 | The receiver decompresses the request data segment, | 538 | and finally sends an ACK to request the next segment | 539 | | | 541 Figure 6: Loss detection in 6LoWPAN 543 Figure 6 shows a scenario where a TCP segment is lost in the 6LoWPAN. 544 After an RTO the enternal IP host retransmits the lost segment. Upon 545 the reception of the retransmitted segment, the ER produces a mostly 546 compressed header allowing the LoWPAN node to decompress the segment. 548 3. Transmission Control Protocol 550 This section presents more details on TCP and its header fields. As 551 it has been defined in [RFC0793], The TCP is a connection-oriented, 552 end-to-end reliable transport protocol mostly used in IP-based 553 networks. The TCP is able to transfer a continuous stream of bytes 554 in each direction between two end-points by packing some number of 555 bytes into segments for transmission through IP-based network. 557 To ensure the end-to-end reliability, the TCP must recover data that 558 is damaged, lost or delivered out-of-order. This is achieved by 559 assigning a sequence number to each transmitted byte (done by the TCP 560 source), and by requiring a positive acknowledgment (ACK) from the 561 TCP destination. If the ACK is not received within the timeout 562 interval, the data segment is assumed to be lost. Then, the source 563 TCP should retransmit it. At the receiver, the sequence numbers are 564 used to correctly order segments that may be received out of order 565 and eliminate duplicates. Damaged segments are handled by adding a 566 checksum to each segment transmitted, checking it at the receiver and 567 rejecting damaged segments. 569 3.1. TCP headers fields 571 In this section, we present a short description of TCP header fields 572 and how they are handled by the compression mechanism. [RFC4413] 573 provides a detailed description of TCP header and TCP header options. 575 o Source port (16 bits): This field identifies the sending port. 576 This field will be replaced by the CID in compressed headers. 577 o Destination port (16 bits): This field identifies the receiving 578 port. This field will be replaced by the CID in compressed 579 headers. 580 o Sequence Number (32 bits): The sequence number of the first data 581 byte in this segment (except when SYN flag is set). If SYN is 582 present the sequence number is the initial sequence number (ISN) 583 and the first data byte is ISN+1. Only the bytes that change 584 (respect to the previous segment) will be sent. If this field 585 does not change, nothing should be sent. 586 o Acknowledgment number (32 bits): If the ACK flag is set this field 587 contains the value of the next sequence number the sender of the 588 segment is expecting to receive. Once a connection is established 589 this is always sent. Only changed bytes of this field according 590 to the last sent segment will be sent. If this field does not 591 change, nothing should be sent. 592 o Reserved (4 bits): Reserved for future use. Must be zero. This 593 field should not be sent in compressed segments. 594 o Flags (8 bits): 595 URG (1 bit): Urgent Pointer field contains a valid value. 596 ACK (1 bit): Acknowledgment field contains a valid value. 597 PSH (1 bit): Push. 598 RST (1 bit): Reset the connection. 599 SYN (1 bit): Synchronize sequence numbers. 600 FIN (1 bit): No more data from sender. 601 CWR (1 bit): Congestion window reduced. 602 ECE (1 bit): Echo the 'congestion experienced' signal in the IP 603 header. 604 o Window (16 bits): The number of data bytes, beginning with the one 605 indicated in the acknowledgment field, the sender of this segment 606 is willing to accept. This field is compressed and only the bytes 607 that have changed are sent. 608 o Checksum (16 bits) The 16-bit checksum field is used for error- 609 checking of the header and data. This field is not compressed by 610 LOWPAN_TCPHC. 611 o Urgent Pointer (16 bits): This field communicates the current 612 value of the urgent pointer as a positive offset from the sequence 613 number in this segment. The urgent pointer points to the sequence 614 number of the byte following the urgent data. This field is only 615 interpreted in segments with the URG flag set to 1. This field is 616 rarely used in TCP communications. For this reason, the URG flag 617 and Urgent Pointer are sent if and only if they are set. In this 618 case, the segment is sent with a full header. 620 3.2. TCP Header Options 622 Options may occupy space at the end of the TCP header and are a 623 multiple of 8 bits in length. Options are considered for the 624 checksum calculation. The most used TCP options are indicated below: 625 o End of Option List (8 bits): indicates the end of the option list. 626 o No-Operation (8 bits): may be used between options. 627 o Maximum Segment Size (32 bits): the maximum segment size at the 628 TCP which sends this segment. 629 o Window Scale Option (24 bits): indicates that the sending TCP end- 630 host is prepared to perform both send and receive window scaling. 631 o SACK-Permitted (16 bits): ask for using SACK option. 632 o SACK (80-320 bits): selective acknowledgment. 633 o Timestamp (80 bits): used to compute RTT. 635 The TCP header padding is used to ensure that the TCP header ends and 636 data begins on the 32-bit boundary. 638 4. TCP header fields compression 640 In this section, we define the LOWPAN_TCPHC specifications for TCP 641 header compression for LLNs. LOWPAN_TCPHC initiates the compression 642 algorithm by exchanging a context identifier at the beginning of the 643 connection. The compressor and decompressor store most fields of the 644 first full headers as a context. 646 As described in [RFC2507], the context consists of the header fields 647 whose values are constant or regularly increasing. The dynamic 648 fields should be elided because they are the same with respect to the 649 previous header. In fact, it is more efficient to send fewer bits, 650 which are the difference from previous value comparing to the sending 651 of the absolute value. The LoWPAN_TCPHC mechanism is based on 652 sending only those fields or parts of fields that do change with 653 respect to the previously sent packet. That is why, the TCP receiver 654 should save the last received segment fields to decompress the next 655 one. For example, the two first bytes of the sequence number field 656 can be elided if they are equal to the value of the previous segment. 658 If a TCP segment is lost and must be retransmitted, the retransmitted 659 segment should be sent with a mostly compressed header. Then, the 660 TCPHC receiver updates the context. 662 The TCP compression format is shown in Figure 10. The three first 663 bits are used to dispatch between different types of segments. 665 LOWPAN_TCPHC uses two bytes which contain the uncompressed flags of 666 TCP. 668 Source and destination port numbers are omitted and replaced by a 669 context identifier. The latter should be sent in connection 670 initiation messages and replaces the source and destination port 671 numbers. 673 The checksum is not compressed and is used by the receiver to check 674 if the decompressed TCP segment is received correctly. To reduce the 675 TCP header length, only these fields which have been changed between 676 two successive segments need to be sent to the receiver. Thus, based 677 on the previously received segment, the receiver reconstructs the 678 original TCP header. 680 The urgent pointer field is transmitted only when the urgent bit is 681 set. When a receiver sends a duplicated acknowledgment, LOWPAN_TCPHC 682 can compress the TCP header down to six bytes (2 bytes LOWPAN_TCPHC, 683 1 byte CID, 1 byte acknowledgment number, 2 bytes Checksum). 685 4.1. TCP ports 687 These fields are part of the definition of a stream and they must be 688 constant for all packets in the stream. TCP port numbers can be 689 elided in TCP compressed segments and replaced by a context 690 identifier (CID). The context identifier should be generated by the 691 the first involved LoWPAN node. 693 4.2. Flags 695 Some of the TCP flags are omitted because TCP control messages that 696 set such flags (SYN, PUSH) are sent uncompressed. The uncompressed 697 flags are : PUSH, FIN, Congestion Window Reduced (CWR) and ECN-Echo 698 indication (ECE). These flags are present in the two bytes of the 699 LOWPAN_TCPHC header. 701 4.3. Sequence and Acknowledgment numbers 703 The sequence number specifies the first data byte in the segment 704 (except the first segment). The length of the sequence number field 705 is four bytes. 707 In a TCP connection, the sequence number is incremented for each 708 packet by a value between 0 and the MSS (Maximum Segment Size). 709 Thus, the less significant bytes (LSB) are expected to change mush 710 frequently than the most significant bytes (MSB). Thus, it is often 711 enough to send the N less-significant bytes if the 4-N bytes most 712 significant bytes do not change. The decompressor module can deduce 713 the elided bytes from the previously received segments. 715 For example: The MSS value is 512 bytes and the current sequence 716 number is 0x00f24512. Then, the sequence number of the next segment 717 should be less or equal to 0x00f24712. The compressed segment can 718 sent with only two bytes instead of sending all 4 bytes. The TCP 719 sender can send two bytes 0x4712 and the TCP receives should add the 720 remaining static bytes 0x00f2. Using this method, we reduce to about 721 50% the length of sequence number or acknowledgment number fields if 722 the MSS value does not exceed 65535 bytes. 724 The sequence number can be elided if a receiver is just acknowledging 725 data segments and does not send data to the source (i.e., the 726 receiver sends a pure TCP ACK). The same algorithm is used for the 727 compression of the acknowledgment number and only bytes which are 728 changed should be carried in-line. If the TCP sink does not generate 729 data, the four bytes of the sequence number are omitted in all 730 acknowledgment segments and only compressed acknowledgment fields 731 should be sent. 733 4.4. Window 735 The window field can be omitted if it does not change in time. 736 Moreover, only the window field bits that have been changed should be 737 sent. The decompression deduces the value of this field from the 738 last received full segment. 740 4.5. Urgent Pointer 742 The urgent pointer field is sent in full header format only if the 743 urgent flag is set. Otherwise, this field is elided. 745 5. LOWPAN_TCPHC Packet Format 747 5.1. TCP segments types 749 Three types of packets are used in a TCP session with header 750 compression: 751 Regular header TCP segment: A normal, uncompressed header. Does not 752 carry any CID. Figure 7 shows the packet format of a regular TCP 753 segment. 755 +------------+----------+-------+ 756 |IPHC (NHC=0)|TCP header|Payload| 757 +------------+----------+-------+ 759 Figure 7: Regular header TCP segment 761 Full header TCP segment: An uncompressed header that updates or 762 refreshes the context for a packet stream. It carries a CID that 763 will be used to identify the context. Figure 8 shows the packet 764 format of a full header TCP segment. 766 +------------+--------+---+----------+-------+ 767 |IPHC (NHC=1)|00000001|CID|TCP header|Payload| 768 +------------+--------+---+----------+-------+ 770 Figure 8: Full header TCP segment 772 Compressed header TCP segment: Figure 9 shows the header stack of a 773 compressed TCP segment. 775 +------------+------------+---+-----------------------+-------+ 776 |IPHC (NHC=1)|LOWPAN_TCPHC|CID|uncompressed TCP fields|Payload| 777 +------------+------------+---+-----------------------+-------+ 779 Figure 9: Compressed header TCP segment 781 5.2. LOWPAN_TCPHC Format 783 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 784 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 785 | 1 | 1 | 0 |Id | Seq | Ack | W |CWR|ECE| F | P | T | S | 786 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 788 Figure 10: TCP Header Encoding 790 Id: Context Identifier Size 791 0: CID is coded in 8 bits. 792 1: CID is coded in 16 bits. 793 Seq: Sequence Number: 794 00: All 32 bits of Sequence Number are elided. 795 01: First 8 less-significant bits of Sequence Number are carried 796 in-line. The remaining 24 bits are elided. 797 10: First 16 less-significant bits of Sequence Number are carried 798 in-line. Last 16 bits of Sequence Number are elided. 799 11: All 32 bits of Sequence Number are carried in-line. 800 Ack: Acknowledgment Number: 801 00: All 32 bits of Acknowledgment Number are elided. 802 01: First 8 less-significant bits of Acknowledgment Number are 803 carried in-line. The remaining 24 bits are elided. 804 10: First 16 less-significant bits of Acknowledgment Number are 805 carried in-line. Last 16 bits of Acknowledgment Number are 806 elided. 808 11: All 32 bits of Acknowledgment Number are carried in-line. 809 W: Window: 810 00: The Window field is elided. 811 01: The less-significant byte of Window field is carried in-line. 812 The most-significant byte is elided. 813 10: The most-significant byte of Window field is carried in-line. 814 The less-significant byte is elided. 815 11: Full 16 bits for Window field are carried in-line. 816 F: FIN flag. 817 P: PUSH flag. 818 CWR: Congestion Window Reduced flag. 819 ECE: ECN-Echo flag. 820 T: Set if the TCP header contains Timestamp option. 821 S: Set if the TCP header contains SACK option. 823 Fields carried in-line (in part or in whole) appear in the same order 824 as they do in the TCP header format [RFC0793]. The TCP Length field 825 must always be elided and it is inferred from lower layers using the 826 6LoWPAN fragmentation header or the MAC layer header. 828 5.3. Examples of compressed TCP headers 830 In this section, we present some examples of a compressed TCP header 831 using LOWPAN_TCPHC. 833 5.3.1. Compressed header 835 Figure 11 represents a header of a TCP data segment whose window 836 field has not changed from with respect its antecedent, the two bytes 837 of the lowest bytes of the sequence number that have been changed. 838 The size of this header is seven bytes. 840 3 1 2 2 2 1 1 1 1 1 1 1 8 16 16 841 +---+-+--+--+--+-+-+-+-+-+-+-+---+----------+----------+ 842 |010|0|01|00|00|0|0|0|0|0|0|0|CID|Seq.Number| Checksum | 843 +---+-+--+--+--+-+-+-+-+-+-+-+---+----------+----------+ 845 Figure 11: Compressed header TCP Header Encoding 847 6. TCP Option Compression 849 This section defines a compression method for the TCP options most 850 likely to be used in 6LoWPAN. The "end of option" byte and the "no 851 operatioon" byte are elided. Taking into account the caracterisctics 852 of the LLNs, the "window scale" option are not supported because it 853 is especially needed in broadband network and the window size in LLNs 854 are limited to few segments. The "maximum segment size" option is 855 negociated in the first control segments, thus they are not 856 compressed. SACK option are not negociated and are allowed by 857 default. However, the ER can decide to allow or to deny an option 858 sent in the SYN segment. LOWPAN_TCPHC compresses the mostly used TCP 859 options : SACK and Timestamp. We assume that the SACK and Timestamp 860 are not negotiated and used by default. LOWPAN_TCPHC specifies two 861 bits for SACK and Timestamp TCP options. Figure 12 shows the 862 structure of a TCP segment including options compressed using 863 LOWPAN_TCPHC. MSS and SACK-Permitted options are sent in a SYN and 864 they are compressed. The Window Scale Option (WSO) is useless in 865 6LoWPAN because it is more performance to use small windows than 866 large windows. The size of the SACK option is 4 bytes and the size 867 of Timestamp option is variable from 2 to 8 bytes. 869 +--------------+-----+----------+-------+-----------+---------+ 870 | LOWPAN_TCPHC | CID | Com. TCP | SACK | Timestamp | Payload | 871 | Encoding | | fields | option| option | | 872 +--------------+-----+----------+-------+-----------+---------+ 874 Figure 12: TCP Header Option Configuration 876 6.1. Selective Acknowledgment option 878 The TCP Selective Acknowledgment option (SACK) [RFC2018] [RFC2883] 879 should be negotiated in set-up phase, then the option may be used 880 when dropped segments are detected by the receiver. This option is 881 to be used to convey extended acknowledgment information over an 882 established connection. The left edge of the block can be replaced 883 by the offset between the first byte of the segment and the right 884 edge by the length of the block. The Left edge and the right edge 885 will be coded in 16 bits. 887 +---------------------+----------------------+ 888 | Left Edge (16 bits) | Right Edge (16 bits) | 889 +---------------------+----------------------+ 891 Figure 13: Compressed SACK option 893 6.2. Timestamp option 895 This option carries eight-byte timestamp fields. If timestamp 896 options [RFC1323] are exchanged in the connection set-up phase, they 897 are expected to appear on all subsequent segments. This overhead 898 added by this option can be reduced: a TCP that does not sent data is 899 not interested to compute the RTTM. And thus, it can replay by 900 sending only Timestamp Echo Reply field (TSecr). However, the 901 Timestamp Value field (TSval) is more important for TCP that send 902 data. 904 LOWPAN_TCPHC sends only bytes that have changed since the last 905 segment to reduce the size of the Timestamp field. LOWPAN_TCPHC 906 defines a bitmap field which specifies the bytes that are elided and 907 the bytes that are carried in-line. Figure 14 shows the structure of 908 the compressed TCP timestamp option fields. 910 +------------------+------------------+------------------+ 911 | Timestamp bitmap | Compressed TSval | Compressed TSecr | 912 +------------------+------------------+------------------+ 914 Figure 14: Compressed Timestamp option 916 7. Acknowledgments 918 This work has been funded by the Pole de Recherche Avancee en 919 Communications (PRACom). The authors would like to thank Patrick 920 Maille and Tiancong Zheng for their useful comments on an early 921 version of this document. 923 8. References 925 [Perkins et al.] 926 Perkins, S. and M. Multa, "Dependency removal for 927 transport protocol header compression over noisy 928 channels", International Conference on 929 Communications 1997, June 1997. 931 [Srivastava et al.] 932 Srivastava, A., Friday, R., Ritter, M., and W. San 933 Filippo, "A study of TCP performance over wireless data 934 networks", Vehicular Technology Conference, IEEE VTS 53rd, 935 May 2001. 937 [Wang04] Wang, R., "An experimental study of TCP/IP's Van Jacobson 938 header compression behavior in lossy space environment", 939 Vehicular Technology Conference, IEEE VTC 60th, 940 September 2004. 942 [Medina05] 943 Medina, A., Allman, M., and S. Floyd, "Measuring the 944 Evolution of Transport Protocols in the Internet", ACM 945 SIGCOMM Computer Communications Review 35(2):37-51, 946 April 2005. 948 [I-D.ietf-6lowpan-hc] 949 Hui, J. and P. Thubert, "Compression Format for IPv6 950 Datagrams in 6LoWPAN Networks", October 2009. 952 [IEEE 802.15.4] 953 IEEE Computer Society, "IEEE Std. 802.15.4-2006", IEEE 954 Standard for Information technology-Telecommunications and 955 information exchange between systems-Local and 956 metropolitan area networks- Specific requirements Part 957 15.4: Wireless Medium Access Control (MAC) and Physical 958 Layer (PHY) Specifications for Low-Rate Wireless Personal 959 Area Networks (WPANs), October 2006. 961 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 962 August 1980. 964 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 965 RFC 793, September 1981. 967 [RFC1122] Braden, R., "Requirements for Internet Hosts - 968 Communication Layers", STD 3, RFC 1122, October 1989. 970 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 971 serial links", RFC 1144, February 1990. 973 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 974 for High Performance", RFC 1323, May 1992. 976 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 977 Selective Acknowledgment Options", RFC 2018, October 1996. 979 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 980 Requirement Levels", BCP 14, RFC 2119, March 1997. 982 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 983 Compression", RFC 2507, February 1999. 985 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 986 Extension to the Selective Acknowledgment (SACK) Option 987 for TCP", RFC 2883, July 2000. 989 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 990 March 2006. 992 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 993 over Low-Power Wireless Personal Area Networks (6LoWPANs): 994 Overview, Assumptions, Problem Statement, and Goals", 995 RFC 4919, August 2007. 997 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 998 "Transmission of IPv6 Packets over IEEE 802.15.4 999 Networks", RFC 4944, September 2007. 1001 [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 1002 Header Compression (ROHC) Framework", RFC 4995, July 2007. 1004 [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 1005 "RObust Header Compression (ROHC): A Profile for TCP/IP 1006 (ROHC-TCP)", RFC 4996, July 2007. 1008 Authors' Addresses 1010 Ahmed Ayadi 1011 Telecom Bretagne 1012 Rue de la Chataigneraie, CS 17607 1013 35576 Cesson Sevigne cedex 1014 France 1016 Phone: +33 2 99 12 70 52 1017 Email: ahmed.ayadi@telecom-bretagne.eu 1019 David Ros 1020 Telecom Bretagne 1021 Rue de la Chataigneraie, CS 17607 1022 35576 Cesson Sevigne cedex 1023 France 1025 Phone: +33 2 99 12 70 46 1026 Email: david.ros@telecom-bretagne.eu 1028 Laurent Toutain 1029 Telecom Bretagne 1030 Rue de la Chataigneraie, CS 17607 1031 35576 Cesson Sevigne cedex 1032 France 1034 Phone: +33 2 99 12 70 26 1035 Email: laurent.toutain@telecom-bretagne.eu