idnits 2.17.1 draft-ietf-6lowpan-hc-13.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 draft header indicates that this document updates RFC4944, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 27, 2010) is 4953 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: 'RFCthis' is mentioned on line 805, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hui, Ed. 3 Internet-Draft Arch Rock Corporation 4 Updates: 4944 (if approved) P. Thubert 5 Intended status: Standards Track Cisco 6 Expires: March 31, 2011 September 27, 2010 8 Compression Format for IPv6 Datagrams in 6LoWPAN Networks 9 draft-ietf-6lowpan-hc-13 11 Abstract 13 This document specifies an IPv6 header compression format for IPv6 14 packet delivery in 6LoWPAN networks. The compression format relies 15 on shared context to allow compression of arbitrary prefixes. How 16 the information is maintained in that shared context is out of scope. 17 This document specifies compression of multicast addresses and a 18 framework for compressing next headers. UDP header compression is 19 specified within this framework. 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 March 31, 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. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 2. Specific Updates to RFC 4944 . . . . . . . . . . . . . . . . . 4 58 3. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 5 59 3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 6 60 3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6 61 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 9 62 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 10 63 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 10 64 3.2.2. Deriving IIDs from the Encapsulating Header . . . . . 11 65 3.2.3. Stateless Multicast Address Compression . . . . . . . 12 66 3.2.4. Stateful Multicast Address Compression . . . . . . . . 13 67 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 14 68 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 14 69 4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 14 70 4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 16 71 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 16 72 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 17 73 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 18 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 77 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 The [IEEE 802.15.4] standard specifies an MTU of 127 bytes, yielding 86 about 80 octets of actual MAC payload with security enabled, on a 87 wireless link with a link throughput of 250 kbps or less. The 88 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 89 datagrams over such constrained links, taking into account limited 90 bandwidth, memory, or energy resources that are expected in 91 applications such as wireless sensor networks. [RFC4944] defines a 92 Mesh Addressing header to support sub-IP forwarding, a Fragmentation 93 header to support the IPv6 minimum MTU requirement [RFC2460], and 94 stateless header compression for IPv6 datagrams (LOWPAN_HC1 and 95 LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down 96 to (in the best case) several bytes. 98 LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of 99 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local 100 unicast communication, where IPv6 addresses carry the link-local 101 prefix and an Interface Identifier (IID) directly derived from IEEE 102 802.15.4 addresses. In this case, both addresses may be completely 103 elided. However, though link-local addresses are commonly used for 104 local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 105 [RFC3315] or routing protocols, they are usually not used for 106 application-layer data traffic, so the actual value of this 107 compression mechanism is limited. 109 Routable addresses must be used when communicating with devices 110 external to the LoWPAN or in a route-over configuration where IP 111 forwarding occurs within the LoWPAN. For routable addresses, 112 LOWPAN_HC1 requires both IPv6 source and destination addresses to 113 carry the prefix in-line. In cases where the Mesh Addressing header 114 is not used, the IID of a routable address must be carried in-line. 115 However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line 116 and cannot be shortened even when it is derived from the IEEE 117 802.15.4 16-bit short address. When the destination is an IPv6 118 multicast address, LOWPAN_HC1 requires the full 128-bit address to be 119 carried in-line. 121 As a result, this document defines an encoding format, LOWPAN_IPHC, 122 for effective compression of Unique Local, Global, and multicast IPv6 123 Addresses based on shared state within contexts. In addition, this 124 document also introduces a number of additional improvements over the 125 header compression format defined in [RFC4944]. 127 LOWPAN_IPHC allows for compression of some commonly-used IPv6 Hop 128 Limit values. If the LoWPAN is a mesh-under stub, a Hop Limit of 1 129 for inbound and a default value such as 64 for outbound are usually 130 enough for application layer data traffic. Additionally, a hop-limit 131 value of 255 is often used to verify that a communication occurs over 132 a single-hop. This specification enables compression of the IPv6 Hop 133 Limit field in those common cases, whereas LOWPAN_HC1 does not. 135 This document also defines LOWPAN_NHC, an encoding format for 136 arbitrary next headers. LOWPAN_IPHC indicates whether the following 137 header is encoded using LOWPAN_NHC. If so, the bits immediately 138 following the compressed IPv6 header start the LOWPAN_NHC encoding. 139 In contrast, LOWPAN_HC1 could be extended to support compression of 140 next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. 141 Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet 142 and uncompressed IPv6 header fields. This specification moves the 143 next header encoding bits to follow all IPv6-related bits, allowing 144 for a properly layered structure and direct support for IPv6 145 extension headers. 147 Using LOWPAN_NHC, this document defines a compression mechanism for 148 UDP. While [RFC4944] defines a compression mechanism for UDP, that 149 mechanism does not enable checksum compression when rendered possible 150 by additional upper layer mechanisms such as upper layer Message 151 Integrity Check (MIC). This specification adds the capability to 152 elide the UDP checksum over the LoWPAN, which enables saving of a 153 further two octets. 155 Also using LOWPAN_NHC, this document defines encoding formats for 156 IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With 157 LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded 158 efficiently. 160 1.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 2. Specific Updates to RFC 4944 168 This document specifies a header compression format that is intended 169 to replace that defined in Section 10 of [RFC4944]. Implementation 170 of Section 10 of [RFC4944] is now NOT RECOMMENDED. New 171 implementations MAY implement compression according to Section 10 of 172 [RFC4944], but SHOULD NOT send packets compressed according to 173 Section 10 of [RFC4944]. 175 A compliant implementation of [RFC4944] as updated by this document 176 MUST be able to properly process a packet received that makes use of 177 the provisions of this document. A compliant implementation MAY 178 implement additional LOWPAN_NHC types (Section 4) that may be 179 registered (Section 5) in the future. It is out of scope of this 180 document how a compressor learns that a decompressor has additional 181 capabilities. 183 Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 184 datagrams that do not fit within a single link frame. Section 5.3 of 185 [RFC4944] defines the fragment header's datagram_size and 186 datagram_offset values as the size and offset of the IPv6 datagram 187 before compression. As a result, all fragment payload outside the 188 first fragment must carry their respective portions of the IPv6 189 datagram before compression. This document does not change that 190 requirement. When using the fragmentation mechanism described in 191 Section 5.3 of [RFC4944], any header that cannot fit within the first 192 fragment MUST NOT be compressed. 194 The header compression format defined in this document preempts the 195 ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the 196 value of 01 000000 is reserved as a replacement value for ESC, to be 197 finally assigned with the first assignment of extension bytes. 199 3. IPv6 Header Compression 201 In this section, we define the LOWPAN_IPHC encoding format for 202 compressing the IPv6 header. To enable effective compression 203 LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN 204 network. LOWPAN_IPHC assumes the following will be the common case 205 for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label 206 are both zero; Payload Length can be inferred from lower layers from 207 either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; 208 Hop Limit will be set to a well-known value by the source; addresses 209 assigned to 6LoWPAN interfaces will be formed using the link-local 210 prefix or a small set of routable prefixes assigned to the entire 211 6LoWPAN network; addresses assigned to 6LoWPAN interfaces are formed 212 with an IID derived directly from either the 64-bit extended or 16- 213 bit short IEEE 802.15.4 addresses. 215 +-------------------------------------+---------------------------- 216 | Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields 217 +-------------------------------------+---------------------------- 219 Figure 1: LOWPAN_IPHC Header 221 The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from 222 the rightmost bit of the dispatch type. The encoding may be extended 223 by another octet to support additional contexts. Any information 224 from the uncompressed IPv6 header fields carried in-line follow the 225 LOWPAN_IPHC encoding, as shown in Figure 1. In the best case, the 226 LOWPAN_IPHC can compress the IPv6 header down to two octets (the 227 dispatch octet and the LOWPAN_IPHC encoding) with link-local 228 communication. 230 When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 231 header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, 232 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination 233 Address). The Hop Limit may not be compressed because it needs to 234 decremented at each hop and may take any value. Stateful address 235 compression must be applied to the source and destination IPv6 236 addresses because they do not statelessly match the source and 237 destination link layer addresses on intermediate hops. 239 3.1. LOWPAN_IPHC Encoding Format 241 This section specifies the format of the LOWPAN_IPHC encoding that 242 describes how an IPv6 header is compressed. The encoding can be 2 243 octets long for the base encoding or 3 octets long when an additional 244 context encoding is present. The IPv6 header fields that are not 245 fully elided are placed immediately after the LOWPAN_IPHC, either in 246 a compressed form if the field is partially elided, or literally. 248 3.1.1. Base Format 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 251 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 252 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 253 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 255 Figure 2: LOWPAN_IPHC base Encoding 257 TF: Traffic Class, Flow Label: 258 00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes) 259 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided 260 10: ECN + DSCP (1 byte), Flow Label is elided 261 11: Traffic Class and Flow Label are elided. 262 NH: Next Header: 263 0: Full 8 bits for Next Header are carried in-line. 264 1: The Next Header field is compressed and the next header is 265 encoded using LOWPAN_NHC, which is discussed in Section 4. 267 HLIM: Hop Limit: 268 00: The Hop Limit field is carried in-line. 269 01: The Hop Limit field is compressed and the hop limit is 1. 270 10: The Hop Limit field is compressed and the hop limit is 64. 271 11: The Hop Limit field is compressed and the hop limit is 255. 273 CID: Context Identifier Extension: 274 0: No additional 8-bit Context Identifier Extension is used. If 275 context-based compression is specified in either SAC or DAC, 276 context 0 is used. 277 1: An additional 8-bit Context Identifier Extension field 278 immediately follows the DAM field. 280 SAC: Source Address Compression 281 0: Source address compression uses stateless compression. 282 1: Source address compression uses stateful, context-based 283 compression. 285 SAM: Source Address Mode: 286 If SAC=0: 287 00: 128 bits. The full address is carried in-line. 288 01: 64 bits. The first 64-bits of the address are elided. 289 The value of those bits is the link-local prefix padded with 290 zeros. The remaining 64 bits are carried in-line. 291 10: 16 bits. The first 112 bits of the address are elided. 292 The value of the first 64 bits is the link-local prefix 293 padded with zeros. The following 64 bits are 0000:00ff: 294 fe00:XXXX, where XXXX are the 16 bits carried in-line. 295 11: 0 bits. The address is fully elided. The first 64 bits 296 of the address are the link-local prefix padded with zeros. 297 The remaining 64 bits are computed from the encapsulating 298 header (e.g. 802.15.4 or IPv6 source address) as specified 299 in Section 3.2.2. 300 If SAC=1: 301 00: The UNSPECIFIED address, :: 302 01: 64 bits. The address is derived using context information 303 and the 64 bits carried in-line. Any bits of the IID not 304 covered by context information are taken directly from the 305 corresponding bits carried in-line. Any remaining bits are 306 zero. 307 10: 16 bits. The address is derived using context information 308 and the 16 bits carried in-line. Any bits of the IID not 309 covered by context information are taken directly from their 310 corresponding bits in the 16-bit to IID mapping given by 311 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in- 312 line. Any remaining bits are zero. 314 11: 0 bits. The address is fully elided. The prefix is 315 derived using context information. Any bits of the IID not 316 covered by the context information are computed from the 317 encapsulating header (e.g. 802.15.4 or IPv6 source address) 318 as specified in Section 3.2.2. Any remaining bits are zero. 320 M: Multicast Compression 321 0: Destination address is not a multicast address. 322 1: Destination address is a multicast address. 324 DAC: Destination Address Compression 325 0: Destination address compression uses stateless compression. 326 1: Destination address compression uses stateful, context-based 327 compression. 329 DAM: Destination Address Mode: 330 If M=0 and DAC=0 This case matches SAC=0 but for the destination 331 address: 332 00: 128 bits. The full address is carried in-line. 333 01: 64 bits. The first 64-bits of the address are elided. 334 The value of those bits is the link-local prefix padded with 335 zeros. The remaining 64 bits are carried in-line. 336 10: 16 bits. The first 112 bits of the address are elided. 337 The value of the first 64 bits is the link-local prefix 338 padded with zeros. The following 64 bits are 0000:00ff: 339 fe00:XXXX, where XXXX are the 16 bits carried in-line. 340 11: 0 bits. The address is fully elided. The first 64 bits 341 of the address are the link-local prefix padded with zeros. 342 The remaining 64 bits are computed from the encapsulating 343 header (e.g. 802.15.4 or IPv6 destination address) as 344 specified in Section 3.2.2. 345 If M=0 and DAC=1: 346 00: Reserved. 347 01: 64 bits. The address is derived using context information 348 and the 64 bits carried in-line. Any bits of the IID not 349 covered by context information are taken directly from the 350 corrseponding bits carried in-line. Any remaining bits are 351 zero. 352 10: 16 bits. The address is derived using context information 353 and the 16 bits carried in-line. Any bits of the IID not 354 covered by context information are taken directly from their 355 corresponding bits in the 16-bit to IID mapping given by 356 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in- 357 line. Any remaining bits are zero. 359 11: 0 bits. The address is fully elided. The prefix is 360 derived using context information. Any bits of the IID not 361 covered by the context information are computed from the 362 encapsulating header (e.g. 802.15.4 or IPv6 destination 363 address) as specified in Section 3.2.2. Any remaining bits 364 are zero. 365 If M=1 and DAC=0: 366 00: 128 bits. The full address is carried in-line. 367 01: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 368 10: 32 bits. The address takes the form FFXX::00XX:XXXX. 369 11: 8 bits. The address takes the form FF02::00XX. 370 If M=1 and DAC=1: 371 00: 48 bits. This format is designed to match Unicast-Prefix- 372 based IPv6 Multicast Addresses as defined in [RFC3306] and 373 [RFC3956]. The multicast address takes the form FFXX:XXLL: 374 PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles 375 that are carried in-line, in the order in which they appear 376 in this format. P denotes nibbles used to encode the prefix 377 itself. L denotes nibbles used to encode the prefix length. 378 The prefix information P and L is taken from the specified 379 context. 380 01: reserved 381 10: reserved 382 11: reserved 384 3.1.2. Context Identifier Extension 386 This specification expects that a conceptual context is shared 387 between the node that compresses a packet and the node(s) that need 388 to expand it. How the contexts are shared and maintained is out of 389 scope. What information is contained within a context information is 390 out of scope. Actions in response to unknown and/or invalid contexts 391 are out of scope. The specification enables a node to use up to 16 392 contexts. The context used to encode the source address does not 393 have to be the same as the context used to encode the destination 394 address. 396 If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an 397 additional octet extends the LOWPAN_IPHC encoding following the DAM 398 bits but before the IPv6 header fields that are carried in-line. The 399 additional octet identifies the pair of contexts to be used when the 400 IPv6 source and/or destination address is compressed. The context 401 identifier is 4 bits for each address, supporting up to 16 contexts. 402 Context 0 is the default context. The encoding is shown in Figure 3. 404 0 1 2 3 4 5 6 7 405 +---+---+---+---+---+---+---+---+ 406 | SCI | DCI | 407 +---+---+---+---+---+---+---+---+ 409 Figure 3: LOWPAN_IPHC Encoding 411 SCI: Source Context Identifier Identifies the prefix that is used 412 when the IPv6 source address is statefully compressed. 413 DCI: Destination Context Identifier Identifies the prefix that is 414 used when the IPv6 destination address is statefully compressed. 416 3.2. IPv6 Header Encoding 418 Fields carried in-line (in part or in whole) appear in the same order 419 as they do in the IPv6 header format [RFC2460]. The Version field is 420 always elided. Unicast IPv6 addresses may be compressed to 64 or 16 421 bits or completely elided. Multicast IPv6 addresses may be 422 compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST 423 always be elided and inferred from lower layers using the 6LoWPAN 424 Fragmentation header or the IEEE 802.15.4 header. 426 3.2.1. Traffic Class and Flow Label Compression 428 The Traffic Class field in the IPv6 header comprises 6 bits of 429 diffserv extension [RFC2474] and 2 bits of Explicit Congestion 430 Notification (ECN) [RFC3168]. The TF field in the LOWPAN_IPHC 431 encoding indicates whether the Traffic Class and Flow Label are 432 carried in-line in the compressed IPv6 header. When Flow Label is 433 included while the Traffic Class is compressed, an additional 4 bits 434 are included to maintain byte-alignment. Two of the 4 bits contain 435 the ECN bits from the Traffic Class field. 437 To ensure that the ECN bits appear in the same location for all 438 encodings that include them, the Traffic Class field is rotated right 439 by 2 bits in the compressed IPv6 header. The encodings are shown 440 below: 442 1 2 3 443 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |ECN| DSCP | rsv | Flow Label | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 TF = 00: Traffic Class and Flow Label carried in-line. 450 1 2 451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |ECN|rsv| Flow Label | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 TF = 01: Flow Label carried in-line. 458 0 1 2 3 4 5 6 7 459 +-+-+-+-+-+-+-+-+ 460 |ECN| DSCP | 461 +-+-+-+-+-+-+-+-+ 463 TF = 10: Traffic Class carried in-line. 465 3.2.2. Deriving IIDs from the Encapsulating Header 467 LOWPAN_IPHC elides the IIDs of source or destination addresses when 468 SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived 469 from the encapsulating header. When the encapsulating header carries 470 IPv6 addresses, bits for the source and destination addresses are 471 copied verbatim from the source and destination addresses of the 472 encapsulating IPv6 header. 474 The remainder of this section defines the mapping from IEEE 802.15.4 475 link-layer addresses to IIDs for both short and extended IEEE 476 802.15.4 addresses. IID bits not covered by the context information 477 MAY be elided if they match the link-layer address mapping and MUST 478 NOT be elided if they do not. 480 An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 481 address. Generating an IID from an extended address is identical to 482 that defined in Appendix A of [RFC4291]. The only change needed to 483 transform an IEEE EUI-64 identifier to an interface identifier is to 484 invert the universal/local bit. 486 A short IEEE 802.15.4 address is 16 bits in length. Short addresses 487 are mapped into the restricted space of IEEE EUI-64 addresses by 488 setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short 489 address, and all other bits to zero. As a result, an IID generated 490 from a short address has the form: 492 0000:00ff:fe00:XXXX 494 where XXXX carries the short address. The universal/local bit is 495 zero to indicate local scope. 497 This mapping for non-EUI-64 identifiers differs from that presented 498 in Appendix A of [RFC4291]. Using the restricted space ensures no 499 overlap with IIDs generated from unrestricted IEEE EUI-64 addresses. 500 Also, including 0xfffe in the middle of the IID helps avoid overlap 501 with other locally managed IIDs. 503 This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is 504 also used to reconstruct any part of an IID not covered by context 505 information. 507 3.2.3. Stateless Multicast Address Compression 509 LOWPAN_IPHC supports stateless compression of multicast addresses 510 when M = 1 and DAC = 0. An IPv6 multicast address may be compressed 511 down to 48, 32, or 8 bits using stateless compression. The format 512 supports compression of the Solicited-Node Multicast Address (FF02:: 513 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 514 bits of the multicast group identifier are zero. The 8-bit 515 compressed form only carries the least-significant bits of the 516 multicast group identifier. The 48 and 32-bit compressed forms carry 517 the multicast scope and flags in-line, in addition to the least- 518 significant bits of the multicast group identifier. 520 1 2 3 521 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Flags | Scope | Group Identifier | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Group Identifier | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 DAM = 01. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) 529 1 2 3 530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Flags | Scope | Group Identifier | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 DAM = 10. 32-bit Compressed Multicast Address (FFfs::00gg:gggg). 537 0 1 2 3 4 5 6 7 538 +-+-+-+-+-+-+-+-+ 539 | Group ID | 540 +-+-+-+-+-+-+-+-+ 542 DAM = 11. 8-bit Compressed Multicast Address (FF02::gg). 544 3.2.4. Stateful Multicast Address Compression 546 LOWPAN_IPHC supports stateful compression of multicast addresses when 547 M = 1 and DAC = 1. This document currently defines DAM = 00: 548 context-based compression of Unicast-Prefix-based IPv6 Multicast 549 Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and 550 Network Prefix can be taken from a context. As a result, LOWPAN_IPHC 551 can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 552 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and 553 32-bit Group Identifier in-line. 555 1 2 3 556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Flags | Scope | Rsvd / RIID | Group Identifier | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Group Identifier | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression 565 Note that the Reserved field MUST carry the reserved bits from the 566 multicast address format as described in [RFC3306]. When a 567 Rendezvous Point is encoded in the multicast address as described in 568 [RFC3956], the Reserved field carries the RIID bits in-line. 570 4. IPv6 Next Header Compression 572 LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set 573 to 1. This also indicates the use of 6LoWPAN next header 574 compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered 575 from the first bits in the LOWPAN_NHC encoding. The following bits 576 are specific to the IPv6 Next Header value. Figure 4 shows the 577 structure of an IPv6 datagram compressed using LOWPAN_IPHC and 578 LOWPAN_NHC. 580 +-------------+-------------+-------------+-----------------+-------- 581 | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload 582 | Encoding | IP Fields | Encoding | Header Fields | 583 +-------------+-------------+-------------+-----------------+-------- 585 Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 587 4.1. LOWPAN_NHC Format 589 Compression formats for different next headers are identified by a 590 variable-length bit-pattern immediately following the LOWPAN_IPHC 591 compressed header. When defining a next header compression format, 592 the number of bits used SHOULD be determined by the perceived 593 frequency of using that format. However, the number of bits and any 594 remaining encoding bits SHOULD respect octet alignment. The 595 following bits are specific to the next header compression format. 596 This document defines a compression format for IPv6 Extension and UDP 597 headers. 599 +----------------+--------------------------- 600 | var-len NHC ID | compressed next header... 601 +----------------+--------------------------- 603 Figure 5: LOWPAN_NHC Encoding 605 4.2. IPv6 Extension Header Compression 607 A necessary property of encoding headers using LOWPAN_NHC is that the 608 immediately preceding header must either be encoded using LOWPAN_IPHC 609 or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN 610 encoding format defined in this document must be contiguous. As a 611 result, this document defines a set of LOWPAN_NHC encodings for 612 selected IPv6 Extension Headers such that the UDP Header Compression 613 defined in Section 4.3 may be used in the presence of those extension 614 headers. 616 The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a 617 single LOWPAN_NHC octet followed by the IPv6 Extension Header. The 618 format of the LOWPAN_NHC octet is shown in Figure 6. The first 7 619 bits serve as an identifier for the IPv6 Extension Header immediately 620 following the LOWPAN_NHC octet. The remaining bit indicates whether 621 or not the following header utilizes LOWPAN_NHC encoding. 623 0 1 2 3 4 5 6 7 624 +---+---+---+---+---+---+---+---+ 625 | 1 | 1 | 1 | 0 | EID |NH | 626 +---+---+---+---+---+---+---+---+ 628 Figure 6: IPv6 Extension Header Encoding 630 EID: IPv6 Extension Header ID: 631 0: IPv6 Hop-by-Hop Options Header[RFC2460] 632 1: IPv6 Routing Header[RFC2460] 633 2: IPv6 Fragment Header[RFC2460] 634 3: IPv6 Destination Options Header[RFC2460] 635 4: IPv6 Mobility Header [RFC3775] 636 5: Reserved 637 6: Reserved 638 7: IPv6 Header 640 NH: Next Header: 641 0: Full 8 bits for Next Header are carried in-line. 642 1: The Next Header field is elided and the next header is encoded 643 using LOWPAN_NHC, which is discussed in Section 4. 645 For the most part, the IPv6 Extension Header is carried verbatim in 646 the bytes immediately following the LOWPAN_NHC octet, with two 647 important exceptions: Length Field and Next Header Field. 649 The Next Header Field contained in IPv6 Extension Headers is elided 650 when the NH bit is set in the LOWPAN_NHC encoding octet. Note that 651 doing so allows LOWPAN_NHC to utilize no more overhead than the non- 652 encoded IPv6 Extension Header. 654 The Length Field contained in a compressed IPv6 Extension Header 655 indicates the number of octets that pertain to the (compressed) 656 extension header following the Length Field. Note that this changes 657 the Length Field definition in [RFC2460] from indicating the header 658 size in 8-octet units, not including the first 8 octets. Changing 659 the Length Field to be in units of octets removes wasteful internal 660 fragmentation. 662 IPv6 Hop-by-Hop and Destination Options Headers may use a trailing 663 Pad1 or PadN to achieve 8-octet alignment. When there is a single 664 trailing Pad1 or PadN option of 7 octets or less and the containing 665 header is a multiple of 8 octets, the trailing Pad1 or PadN option 666 MAY be elided by the compressor. A decompressor MUST ensure that the 667 containing header is padded out to a multiple of 8 octets in length, 668 using a Pad1 or PadN option if necessary. Note that Pad1 and PadN 669 options that appear in locations other than the end MUST be carried 670 in-line as they are used to align subsequent options. 672 Note that specifying units in octets means that LOWPAN_NHC MUST NOT 673 be used to encode IPv6 Extension Headers that have more than 255 674 octets following the Length Field after compression. 676 When the identified next header is an IPv6 Header (EID=7), the NH bit 677 of the LOWPAN_NHC encoding is unused and MUST be set to zero. The 678 following bytes MUST be encoded using LOWPAN_IPHC as defined in 679 Section 3. 681 4.3. UDP Header Compression 683 This document defines a compression format for UDP headers using 684 LOWPAN_NHC. The UDP compression format is shown in Figure 7. Bits 0 685 through 4 represent the NHC ID and '11110' indicates the specific UDP 686 header compression encoding defined in this section. 688 4.3.1. Compressing UDP ports 690 This specification introduces a range of well-known ports (0xF0Bx) 691 that can be compressed to 4 bits. Considering that this represents 692 only 16 contiguous ports, it can be expected that many incompatible 693 applications will use the same port numbers for their own end-to-end 694 needs. 696 The overloading of the 0xF0Bx ports increases the risk of getting the 697 wrong type of payload and misinterpreting the content compared to 698 ports that are reserved at IANA. As a result, it is recommended that 699 the use of those ports be associated with a mechanism such as a 700 Transport Layer Security (TLS) Message Integrity Check (MIC) that 701 validates that the content is expected and checked for integrity. 703 4.3.2. Compressing UDP checksum 705 The UDP checksum operation is mandatory with IPv6 [RFC2460] for all 706 packets. For that reason [RFC4944] disallows the compression of the 707 UDP checksum. 709 With this specification, a compressor in the source transport 710 endpoint MAY elide the UDP checksum if it is authorized by the Upper 711 Layer. The compressor SHOULD NOT set the C bit unless it has 712 received such authorization. The Upper Layer SHOULD only provide the 713 authorization in the following cases: 715 Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo- 716 fieldbus by tunneling existing field protocols over UDP. If the 717 tunneled PDU possesses its own addressing, security and integrity 718 check, the tunneling mechanism MAY authorize to elide the UDP 719 checksum in order to save on the encapsulation overhead. 720 Upper Layer Message Integrity Check: In this case, there is some 721 other form of integrity check in the UDP payload that covers at 722 least the same information as the UDP checksum (pseudo-header, 723 data) and has at least the same strength. 725 A forwarding node MAY imply authorization from an incoming packet if 726 the C bit is set. A forwarding node that cannot unambiguously derive 727 such authorization SHOULD NOT elide the UDP checksum when performing 728 6LoWPAN compression. The forwarding node that expands a 6LoWPAN 729 packet with the C bit on MUST compute the UDP checksum on behalf of 730 the source node and place that checksum in the restored UDP header as 731 specified in the incumbent standards [RFC0768], [RFC2460]. 733 If a 6LoWPAN termination is also the transport endpoint and it 734 receives a compressed packet with the C bit set, then it is entitled 735 to ignore the UDP checksum process completely. If the C bit is not 736 set, the packet might have been forwarded by an edge router, so this 737 is not an indication that the MIC is not present. If the terminating 738 node knows that the message integrity will be validated by the upper 739 layer by some state associated to the Service Access Point, it is 740 entitled to ignore the checksum operation as if the C bit was set. 742 4.3.3. UDP LOWPAN_NHC Format 744 0 1 2 3 4 5 6 7 745 +---+---+---+---+---+---+---+---+ 746 | 1 | 1 | 1 | 1 | 0 | C | P | 747 +---+---+---+---+---+---+---+---+ 749 Figure 7: UDP Header Encoding 751 C: Checksum: 752 0: All 16 bits of Checksum are carried in-line. 753 1: All 16 bits of Checksum are elided. The Checksum is recovered 754 by recomputing it on the 6LoWPAN termination point. 756 P: Ports: 757 00: All 16 bits for both Source Port and Destination Port are 758 carried in-line. 759 01: All 16 bits for Source Port are carried in-line. First 8 760 bits of Destination Port is 0xF0 and elided. The remaining 8 761 bits of Destination Port are carried in-line. 762 10: First 8 bits of Source Port are 0xF0 and elided. The 763 remaining 8 bits of Source Port are carried in-line. All 16 764 bits for Destination Port are carried in-line. 765 11: First 12 bits of both Source Port and Destination Port are 766 0xF0B and elided. The remaining 4 bits for each are carried 767 in-line. 769 Fields carried in-line (in part or in whole) appear in the same order 770 as they do in the UDP header format [RFC0768]. The UDP Length field 771 MUST always be elided and is inferred from lower layers using the 772 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 774 5. IANA Considerations 776 This document defines a new IPv6 header compression format for 777 6LoWPAN networks. The document allocates the following 32 Dispatch 778 type field values for LOWPAN_IPHC: 780 01 100000 781 through 782 01 111111 784 This assignment preempts the assignment of 01 111111 for ESC 785 [RFC4944], which is possible as no extension bytes have been 786 allocated yet that would enable the use of ESC. Instead, the value: 788 01 000000 790 is reserved as a replacement value for ESC, to be finally assigned 791 with the first assignment of extension bytes. 793 This document also creates a new IANA registry for the LOWPAN_NHC 794 header type, with the following initial content: 796 00000000 to 11011111: (unassigned) 797 1110000N: IPv6 Hop-by-Hop Options Header [RFCthis] 798 1110001N: IPv6 Routing Header [RFCthis] 799 1110010N: IPv6 Fragment Header [RFCthis] 800 1110011N: IPv6 Destination Options Header [RFCthis] 801 1110100N: IPv6 Mobility Header [RFCthis] 802 1110101N: (Reserved for future extension headers) 803 1110110N: (Reserved for future extension headers) 804 1110111N: IPv6 Header [RFCthis] 805 11110CPP: UDP Header [RFCthis] 806 11111000 to 11111110: (unassigned) 807 11111111: (unassigned, reserved for extensions) 809 Capital letters in bit positions represent class-specific bit 810 assignments. N indicates whether or not additional LOWPAN_NHC 811 encodings follow, as defined in Section 4.2. CPP represents 812 variables specific to UDP header compression defined in Section 4.3. 814 The policy for this registry [RFC5226] is IETF Review. In this 815 process, new values SHOULD be assigned in a way that preserves the 816 NHC ID abstraction of Section 4 (i.e., k one-bits followed by one 817 zero-bit identify the general class of NHC, followed by class- 818 specific bit assignments). 820 6. Security Considerations 822 The definition of LOWPAN_IPHC permits the compression of header 823 information on communication that could take place in its absence, 824 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 825 PAN may have associated with it a number of prefixes through shared 826 context. How the shared context is assigned and managed is beyond 827 the scope of this document. 829 The overloading of the 0xF0Bx ports increases the risk of getting the 830 wrong type of payload and misinterpreting the content compared to 831 ports that reserved at IANA. It is thus recommended that the use of 832 those ports be associated with a mechanism such as a Transport Layer 833 Security (TLS) Message Integrity Check (MIC) that validates that the 834 content is expected and checked for integrity. 836 7. Acknowledgements 838 Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten 839 Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik 840 Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach 841 Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design 842 consideration and implementation feedback. 844 8. Changes 846 (This section to be removed by the RFC editor.) 848 Draft 13: 849 - Specify that address bits not covered by the context or IID are 850 zero. 852 Draft 12: 853 - Specify that 16-bit to IID mapping is used to derive IID bits 854 when SAC/DAC=1 and the context does not cover those bits. 856 Draft 11: 857 - Removed incorrect and unnecessary text in specifying how to 858 derive the IID bits not covered by the context. 859 - Adjust formatting to reduce orphans and widows. 861 Draft 10: 862 - Specify that the IID has the form 0000:00ff:fe00:XXXX when SAC/ 863 DAC=0 and SAM/DAM=10. 865 Draft 09: 866 - Indicate that a mechanism to learn decompressor's capabilities 867 to decode additional (future) NHCs is out of scope. 868 - Clarify how to derive IID bits not covered by the context when 869 only 16 bits are carried inline. 870 - Clarify the value of the Length field for compressed extension 871 headers. 872 - Added an IANA registry for LOWPAN_NHC types. 874 Draft 08: 875 - Clarified that the lower bits of an IPv6 address may be derived 876 from an IPv6 header, not just an 802.15.4 header. Change text 877 from "derived from link-layer header" to "derived from 878 encapsulating header". 880 Draft 07: 882 - Added section on mapping link-layer addresses to IIDs. 883 - Added text on restricting compressed headers to first fragment 884 when using fragment headers defined in Section 5.3 of [RFC4944]. 885 - Minor editorial edits. 887 Draft 06: 888 - Reworked introduction. 889 - Added section on updates to [RFC4944]. 890 - Fixed description of number of bits used for IPHC encoding. 891 - Specify M=0 only for non-multicast addresses and M=1 only for 892 multicast addresses. 893 - Move 128-bit multicast encoding to DAC=0. 894 - Redefined ESC dispatch value to 01 000000. 895 - Many detailed edits. 897 Draft 05: 898 - Added LOWPAN_NHC encodings for IPv6 Extension Headers. 899 - Specify use of context 0 when CID is 0. 900 - Indicate that first 64-bits is link-local prefix padded with 901 zeros when link-local prefix is elided. 902 - Made prefix-based multicast encoding format more explicit for 903 clarity. 904 - Changed wording around stateful compression to allow for using 905 the in-line bits as an additional index to identify the compressed 906 address. 907 - Removed support for compressing unspecified address. 908 - Full 128-bit addr in-line only in stateless encoding. 910 Draft 04: 911 - Fixed typos leftover from the changes in 03. 912 - Gave more details on UDP checksum compression. 913 - Clarify that the context information is out of scope. 914 - Added security concern on 0xF0Bx port overloading. 916 Draft 03: 917 - Decoupled meaning of SAM bits from the destination address. 918 - Have separate bit to indicate multicast address compression. 919 - More extensive support for multicast address compression, 920 including Unicast-Prefix-based Multicast Addresses. 922 Draft 02: 923 - Updated wording with compression mode to clarify that a 924 compression mode does not enforce what kind of destination address 925 is being used. Specifically changed Destination Dependent Field 926 to Compression Mode. 928 - Specify that the configuration and management of contexts is out 929 of scope of this document. 931 Draft 01: 932 - HC back to 1 byte by default by stealing a few bits from the 933 dispatch field. 934 - Added better support for multicast address compression. 935 - Fixed alignment for UDP port compression. 936 - Better support for Traffic Class and Flow Label compression. 937 - Pascal joined as an author. 939 9. References 941 9.1. Normative References 943 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 944 August 1980. 946 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 947 Requirement Levels", BCP 14, RFC 2119, March 1997. 949 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 950 (IPv6) Specification", RFC 2460, December 1998. 952 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 953 "Definition of the Differentiated Services Field (DS 954 Field) in the IPv4 and IPv6 Headers", RFC 2474, 955 December 1998. 957 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 958 of Explicit Congestion Notification (ECN) to IP", 959 RFC 3168, September 2001. 961 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 962 in IPv6", RFC 3775, June 2004. 964 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 965 Architecture", RFC 4291, February 2006. 967 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 968 "Transmission of IPv6 Packets over IEEE 802.15.4 969 Networks", RFC 4944, September 2007. 971 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 972 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 973 May 2008. 975 9.2. Informative References 977 [IEEE 802.15.4] 978 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 979 October 2006. 981 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 982 Multicast Addresses", RFC 3306, August 2002. 984 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 985 and M. Carney, "Dynamic Host Configuration Protocol for 986 IPv6 (DHCPv6)", RFC 3315, July 2003. 988 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 989 Point (RP) Address in an IPv6 Multicast Address", 990 RFC 3956, November 2004. 992 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 993 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 994 September 2007. 996 Authors' Addresses 998 Jonathan W. Hui (editor) 999 Arch Rock Corporation 1000 501 2nd St. Ste. 410 1001 San Francisco, California 94107 1002 USA 1004 Phone: +415 692 0828 1005 Email: jhui@archrock.com 1007 Pascal Thubert 1008 Cisco Systems 1009 Village d'Entreprises Green Side 1010 400, Avenue de Roumanille 1011 Batiment T3 1012 Biot - Sophia Antipolis 06410 1013 FRANCE 1015 Phone: +33 4 97 23 26 34 1016 Email: pthubert@cisco.com