idnits 2.17.1 draft-ietf-6lo-6lobac-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 187 has weird spacing: '...Address one ...' -- The document date (March 10, 2017) is 2597 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BACnet' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group K. Lynn, Ed. 3 Internet-Draft Verizon Labs 4 Intended status: Standards Track J. Martocci 5 Expires: September 11, 2017 Johnson Controls 6 C. Neilson 7 Delta Controls 8 S. Donaldson 9 Honeywell 10 March 10, 2017 12 Transmission of IPv6 over MS/TP Networks 13 draft-ietf-6lo-6lobac-08 15 Abstract 17 Master-Slave/Token-Passing (MS/TP) is a medium access control method 18 for the RS-485 physical layer and is used primarily in building 19 automation networks. This specification defines the frame format for 20 transmission of IPv6 packets and the method of forming link-local and 21 statelessly autoconfigured IPv6 addresses on MS/TP networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 11, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Profile for IPv6 over MS/TP . . . . . . . . . . . . . . . . . 5 59 3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 7 61 5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 7 62 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 8 63 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 9 64 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9 65 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 10 66 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 14 72 Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 17 73 Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 20 74 Appendix D. Example 6LoBAC Frame Decode . . . . . . . . . . . . 22 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 77 1. Introduction 79 Master-Slave/Token-Passing (MS/TP) is a medium access control (MAC) 80 protocol for the RS-485 [TIA-485-A] physical layer and is used 81 primarily in building automation networks. This specification 82 defines the frame format for transmission of IPv6 [RFC2460] packets 83 and the method of forming link-local and statelessly autoconfigured 84 IPv6 addresses on MS/TP networks. The general approach is to adapt 85 elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and 86 [RFC6775] to constrained wired networks, as noted below. 88 An MS/TP device is typically based on a low-cost microcontroller with 89 limited processing power and memory. These constraints, together 90 with low data rates and a small MAC address space, are similar to 91 those faced in 6LoWPAN networks. MS/TP differs significantly from 92 6LoWPAN in at least three respects: a) MS/TP devices are typically 93 mains powered, b) all MS/TP devices on a segment can communicate 94 directly so there are no hidden node or mesh routing issues, and c) 95 the latest MS/TP specification provides support for large payloads, 96 eliminating the need for fragmentation and reassembly below IPv6. 98 The following sections provide a brief overview of MS/TP, then 99 describe how to form IPv6 addresses and encapsulate IPv6 packets in 100 MS/TP frames. This specifcation (subsequently referred to as 101 "6LoBAC") includes a REQUIRED header compression mechanism that is 102 based on LOWPAN_IPHC [RFC6282] and improves MS/TP link utilization. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 1.2. Abbreviations Used 112 ASHRAE: American Society of Heating, Refrigerating, and Air- 113 Conditioning Engineers (http://www.ashrae.org) 115 BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol 116 for Building Automation and Control Networks 118 CRC: Cyclic Redundancy Code 120 MAC: Medium Access Control 122 MSDU: MAC Service Data Unit (MAC client data) 124 MTU: Maximum Transmission Unit; the size of the largest network 125 layer protocol data unit that can be communicated in a single 126 network transaction 128 UART: Universal Asynchronous Transmitter/Receiver 130 1.3. MS/TP Overview 132 This section provides a brief overview of MS/TP, as specified in 133 ANSI/ASHRAE Standard 135-2016 [BACnet] Clause 9. The latest version 134 of [BACnet] integrates changes to legacy MS/TP (approved as 135 [Addendum_an]) that provide support for larger frame sizes and 136 improved error handling. [BACnet] Clause 9 also covers physical 137 layer deployment options. 139 MS/TP is designed to enable multidrop networks over shielded twisted 140 pair wiring. It can support network segments up to 1000 meters in 141 length at a data rate of 115.2 kbit/s, or segments up to 1200 meters 142 in length at lower bit rates. An MS/TP interface requires only a 143 UART, an RS-485 [TIA-485-A] transceiver with a driver that can be 144 disabled, and a 5 ms resolution timer. The MS/TP MAC is typically 145 implemented in software. 147 The differential signaling used by [TIA-485-A] requires a contention- 148 free MAC. MS/TP uses a token to control access to a multidrop bus. 149 Only an MS/TP master node can initiate the unsolicited transfer of 150 data, and only when it holds the token. After sending at most a 151 configured maximum number of data frames, a master node passes the 152 token to the next master node (as determined by MAC address). If 153 present on the link, legacy MS/TP implementations (including any 154 slave nodes) ignore the frame format defined in this specification. 156 [BACnet] Clause 9 defines a range of Frame Type values used to 157 designate frames that contain data and data CRC fields encoded using 158 Consistent Overhead Byte Stuffing [COBS] (see Appendix B). The 159 purpose of COBS encoding is to eliminate preamble sequences from the 160 Encoded Data and Encoded CRC-32K fields. The Encoded Data is covered 161 by a 32-bit CRC [CRC32K] (see Appendix C) that is also COBS encoded. 163 MS/TP COBS-encoded frames have the following format: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | 0x55 | 0xFF | Frame Type | DA | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | SA | Length (MS octet first) | Header CRC | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 . . 173 . Encoded Data (2 - 1506 octets) . 174 . . 175 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | Encoded CRC-32K (5 octets) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 178 | | optional 0xFF | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 1: MS/TP COBS-Encoded Frame Format 183 MS/TP COBS-encoded frame fields are defined as follows: 185 Preamble two octet preamble: 0x55, 0xFF 186 Frame Type one octet 187 Destination Address one octet address 188 Source Address one octet address 189 Length two octets, most significant octet first 190 Header CRC one octet 191 Encoded Data 2 - 1506 octets (see Section 4 and Appendix B) 192 Encoded CRC-32K five octets (see Appendix C) 193 (pad) (optional) at most one octet of trailer: 0xFF 195 The Frame Type is used to distinguish between different types of MAC 196 frames. The types relevant to this specification (in decimal) are: 198 0 Token 199 1 Poll For Master 200 2 Reply To Poll For Master 201 3 Test_Request 202 4 Test_Response 203 ... 204 34 IPv6 over MS/TP (LoBAC) Encapsulation 206 Frame Types 8 - 31 and 35 - 127 are reserved for assignment by 207 ASHRAE. Frame Types 32 - 127 designate COBS-encoded frames that 208 convey Encoded Data and Encoded CRC-32K fields. See Section 2 for 209 additional details. 211 The Destination and Source Addresses are each one octet in length. 212 See Section 3 for additional details. 214 For COBS-encoded frames, the Length field indicates the size of the 215 [COBS] Encoded Data field in octets, plus three. (This adjustment is 216 required in order for legacy MS/TP devices to ignore COBS-encoded 217 frames.) See Section 4 and Appendices for additional details. 219 The Header CRC field covers the Frame Type, Destination Address, 220 Source Address, and Length fields. The Header CRC generation and 221 check procedures are specified in [BACnet] Annex G.1. 223 Use of the optional 0xFF trailer octet is discussed in [BACnet] 224 Clause 9. 226 1.4. Goals and Constraints 228 The main goals of this specification are a) to enable IPv6 directly 229 on wired end devices in building automation and control networks by 230 leveraging existing standards to the greatest extent possible, and b) 231 to co-exist with legacy MS/TP implementations. Co-existence allows 232 MS/TP networks to be incrementally upgraded to support IPv6. 234 In order to co-exist with legacy devices, no changes are permitted to 235 the MS/TP addressing modes, frame header format, control frames, or 236 Master Node state machine as specified in [BACnet] Clause 9. 238 2. Profile for IPv6 over MS/TP 240 ASHRAE has assigned an MS/TP Frame Type value of 34 to indicate IPv6 241 over MS/TP (LoBAC) Encapsulation. This falls within the range of 242 values that designate COBS-encoded data frames. 244 2.1. Mandatory Features 246 [BACnet] Clause 9 specifies mandatory to implement features of MS/TP 247 devices. E.g., it is mandatory that all MS/TP nodes respond to a 248 Test_Request with a Test_Response frame. All MS/TP master nodes must 249 implement the Master Node state machine and handle Token, Poll For 250 Master, and Reply to Poll For Master control frames. 6LoBAC nodes 251 are MS/TP master nodes that implement a Receive Frame state machine 252 capable of handling COBS-encoded frames. 254 6LoBAC nodes must support a data rate of 115.2 kbit/s and may support 255 lower data rates as specified in [BACnet] Clause 9. The method of 256 selecting the data rate is outside the scope of this specification. 258 2.2. Configuration Constants 260 The following constants are used by the Receive Frame state machine. 262 Nmin_COBS_length The minimum valid Length value of any LoBAC 263 encapsulated frame: 5 265 Nmax_COBS_length The maximum valid Length value of any LoBAC 266 encapsulated frame: 1509 268 2.3. Configuration Parameters 270 The following parameters are used by the Master Node state machine. 272 Nmax_info_frames The default maximum number of information frames 273 the node may send before it must pass the token: 1 275 Nmax_master The default highest allowable address for master 276 nodes: 127 278 The mechanisms for setting parameters or monitoring MS/TP performance 279 are outside the scope of this specification. 281 3. Addressing Modes 283 MS/TP node (MAC) addresses are one octet in length and assigned 284 dynamically. The method of assigning MAC addresses is outside the 285 scope of this specification. However, each MS/TP node on the link 286 MUST have a unique address in order to ensure correct MAC operation. 288 [BACnet] Clause 9 specifies that addresses 0 through 127 are valid 289 for master nodes. The method specified in Section 6 for creating a 290 MAC-address-derived Interface Identifier (IID) ensures that an IID of 291 all zeros can never be generated. 293 A Destination Address of 255 (all nodes) indicates a MAC-layer 294 broadcast. MS/TP does not support multicast, therefore all IPv6 295 multicast packets MUST be broadcast at the MAC layer and filtered at 296 the IPv6 layer. A Source Address of 255 MUST NOT be used. 298 Hosts learn IPv6 prefixes via router advertisements according to 299 [RFC4861]. 301 4. Maximum Transmission Unit (MTU) 303 Upon transmission, the network layer MTU is formatted according to 304 Section 5 and becomes the MAC service data unit (MSDU). The MSDU is 305 then COBS encoded by MS/TP. Upon reception, the steps are reversed. 306 [BACnet] Clause 9 supports MSDUs up to 2032 octets in length. 308 IPv6 [RFC2460] requires that every link in the internet have an MTU 309 of 1280 octets or greater. Additionally, a node must be able to 310 accept a fragmented packet that, after reassembly, is as large as 311 1500 octets. This specification defines an MTU length of at least 312 1280 octets and at most 1500 octets. Support for an MTU length of 313 1500 octets is RECOMMENDED. 315 5. LoBAC Adaptation Layer 317 This section specifies an adaptation layer to support compressed IPv6 318 headers as specified in Section 10. IPv6 header compression MUST be 319 implemented on all nodes. Implementations MAY also support Generic 320 Header Compression [RFC7400] for transport layer headers. 322 The LoBAC encapsulation format defined in this section describes the 323 MSDU of an IPv6 over MS/TP frame. The LoBAC payload (i.e., an IPv6 324 packet) follows an encapsulation header stack. LoBAC is a subset of 325 the LoWPAN encapsulation defined in [RFC4944] as updated by [RFC6282] 326 so the use of "LOWPAN" in literals below is intentional. The primary 327 difference between LoWPAN and LoBAC encapsulation is omission of the 328 Mesh, Broadcast, Fragmentation, and LOWPAN_HC1 headers in the latter. 330 All LoBAC encapsulated datagrams transmitted over MS/TP are prefixed 331 by an encapsulation header stack consisting of a Dispatch value 332 followed by zero or more header fields. The only sequence currently 333 defined for LoBAC is the LOWPAN_IPHC header followed by payload, as 334 shown below: 336 +---------------+---------------+------...-----+ 337 | IPHC Dispatch | IPHC Header | Payload | 338 +---------------+---------------+------...-----+ 340 Figure 2: A LoBAC Encapsulated LOWPAN_IPHC Compressed IPv6 Datagram 342 The Dispatch value is treated as an unstructured namespace. Only a 343 single pattern is used to represent current LoBAC functionality. 345 Pattern Header Type 346 +------------+-----------------------------------------------------+ 347 | 01 1xxxxx | LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] | 348 +------------+-----------------------------------------------------+ 350 Figure 3: LoBAC Dispatch Value Bit Pattern 352 Other IANA-assigned 6LoWPAN Dispatch values do not apply to 6LoBAC 353 unless otherwise specified. 355 6. Stateless Address Autoconfiguration 357 This section defines how to obtain an IPv6 Interface Identifier. 358 This specification distinguishes between two types of IID, MAC- 359 address-derived and semantically opaque. 361 A MAC-address-derived IID is the RECOMMENDED type for use in forming 362 a link-local address, as it affords the most efficient header 363 compression provided by the LOWPAN_IPHC [RFC6282] format specified in 364 Section 10. The general procedure for creating a MAC-address-derived 365 IID is described in [RFC4291] Appendix A, "Creating Modified EUI-64 366 Format Interface Identifiers", as updated by [RFC7136]. 368 The Interface Identifier for link-local addresses SHOULD be formed by 369 concatenating the node's 8-bit MS/TP MAC address to the seven octets 370 0x00, 0x00, 0x00, 0xFF, 0xFE, 0x00, 0x00. For example, an MS/TP MAC 371 address of hexadecimal value 0x4F results in the following IID: 373 |0 1|1 3|3 4|4 6| 374 |0 5|6 1|2 7|8 3| 375 +----------------+----------------+----------------+----------------+ 376 |0000000000000000|0000000011111111|1111111000000000|0000000001001111| 377 +----------------+----------------+----------------+----------------+ 379 A semantically opaque IID having 64 bits of entropy is RECOMMENDED 380 for each globally scoped address and MAY be locally generated 381 according to one of the methods cited in Section 12. A node that 382 generates a 64-bit semantically opaque IID MUST register the IID with 383 its local router(s) by sending a Neighbor Solicitation (NS) message 384 with the Address Registration Option (ARO) and process Neighbor 385 Advertisements (NA) according to [RFC6775]. 387 An IPv6 address prefix used for stateless autoconfiguration [RFC4862] 388 of an MS/TP interface MUST have a length of 64 bits. 390 7. IPv6 Link Local Address 392 The IPv6 link-local address [RFC4291] for an MS/TP interface is 393 formed by appending the Interface Identifier, as defined above, to 394 the prefix FE80::/64. 396 10 bits 54 bits 64 bits 397 +----------+-----------------------+----------------------------+ 398 |1111111010| (zeros) | Interface Identifier | 399 +----------+-----------------------+----------------------------+ 401 8. Unicast Address Mapping 403 The address resolution procedure for mapping IPv6 non-multicast 404 addresses into MS/TP MAC-layer addresses follows the general 405 description in Section 7.2 of [RFC4861], unless otherwise specified. 407 The Source/Target Link-layer Address option has the following form 408 when the addresses are 8-bit MS/TP MAC-layer (node) addresses. 410 0 1 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Length=1 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | 0x00 | MS/TP Address | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 + Padding (all zeros) + 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Option fields: 424 Type: 426 1: for Source Link-layer address. 428 2: for Target Link-layer address. 430 Length: This is the length of this option (including the type and 431 length fields) in units of 8 octets. The value of this field is 1 432 for 8-bit MS/TP MAC addresses. 434 MS/TP Address: The 8-bit address in canonical bit order [RFC2469]. 435 This is the unicast address the interface currently responds to. 437 9. Multicast Address Mapping 439 All IPv6 multicast packets MUST be sent to MS/TP Destination Address 440 255 (broadcast) and filtered at the IPv6 layer. When represented as 441 a 16-bit address in a compressed header (see Section 10), it MUST be 442 formed by padding on the left with a zero octet: 444 0 1 445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | 0x00 | 0xFF | 448 +-+-+-+-+-+-+-+-+---------------+ 450 10. Header Compression 452 6LoBAC REQUIRES LOWPAN_IPHC IPv6 compression, which is specified in 453 [RFC6282] and included herein by reference. This section will simply 454 identify substitutions that should be made when interpreting the text 455 of [RFC6282]. 457 In general the following substitutions should be made: 459 - Replace instances of "6LoWPAN" with "MS/TP network" 461 - Replace instances of "IEEE 802.15.4 address" with "MS/TP address" 463 When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 464 address") it MUST be formed by padding the MS/TP address to the left 465 with a zero octet: 467 0 1 468 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | 0x00 | MS/TP address | 471 +-+-+-+-+-+-+-+-+---------------+ 473 If LOWPAN_IPHC compression [RFC6282] is used with context, the 474 router(s) directly attached to the MS/TP segment MUST disseminate the 475 6LoWPAN Context Option (6CO) according to [RFC6775], Section 7.2. 477 11. IANA Considerations 479 This document uses values previously reserved by [RFC4944] and 480 [RFC6282] and makes no further requests of IANA. 482 Note to RFC Editor: this section may be removed upon publication. 484 12. Security Considerations 486 See [RFC8065] for a general discussion of privacy threats faced by 487 constrained nodes. 489 [RFC8065] makes a distinction between "stable" and "temporary" 490 addresses. The former are long-lived and typically advertised by 491 servers. The latter are typically used by clients and SHOULD be 492 changed frequently to mitigate correlation of activities over time. 493 Nodes that engage in both activities SHOULD support simultaneous use 494 of multiple addresses per device. 496 Globally scoped addresses that contain MAC-address-derived IIDs may 497 expose a network to address scanning attacks. For this reason, it is 498 RECOMMENDED that a 64-bit semantically opaque IID be generated for 499 each globally scoped address in use according to, for example, 500 [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]. 502 13. Acknowledgments 504 We are grateful to the authors of [RFC4944] and members of the IETF 505 6LoWPAN working group; this document borrows liberally from their 506 work. Ralph Droms and Brian Haberman provided indispensable guidance 507 and support from the outset. Peter van der Stok, James Woodyatt, 508 Carsten Bormann, and Dale Worley provided detailed reviews. Stuart 509 Cheshire invented the very clever COBS encoding. Michael Osborne 510 made the critical observation that encoding the data and CRC32K 511 fields separately would allow the CRC to be calculated on-the-fly. 512 Alexandru Petrescu, Brian Frank, Geoff Mulligan, and Don Sturek 513 offered valuable comments. 515 14. References 517 14.1. Normative References 519 [BACnet] American Society of Heating, Refrigerating, and Air- 520 Conditioning Engineers, "BACnet - A Data Communication 521 Protocol for Building Automation and Control Networks", 522 ANSI/ASHRAE Standard 135-2016, January 2016, 523 . 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, 528 DOI 10.17487/RFC2119, March 1997, 529 . 531 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 532 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 533 December 1998, . 535 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 536 C., and M. Carney, "Dynamic Host Configuration Protocol 537 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 538 2003, . 540 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 541 RFC 3972, DOI 10.17487/RFC3972, March 2005, 542 . 544 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 545 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 546 2006, . 548 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 549 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 550 DOI 10.17487/RFC4861, September 2007, 551 . 553 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 554 Address Autoconfiguration", RFC 4862, 555 DOI 10.17487/RFC4862, September 2007, 556 . 558 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 559 Extensions for Stateless Address Autoconfiguration in 560 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 561 . 563 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 564 "Transmission of IPv6 Packets over IEEE 802.15.4 565 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 566 . 568 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 569 DOI 10.17487/RFC5535, June 2009, 570 . 572 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 573 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 574 DOI 10.17487/RFC6282, September 2011, 575 . 577 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 578 Bormann, "Neighbor Discovery Optimization for IPv6 over 579 Low-Power Wireless Personal Area Networks (6LoWPANs)", 580 RFC 6775, DOI 10.17487/RFC6775, November 2012, 581 . 583 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 584 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 585 February 2014, . 587 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 588 Interface Identifiers with IPv6 Stateless Address 589 Autoconfiguration (SLAAC)", RFC 7217, 590 DOI 10.17487/RFC7217, April 2014, 591 . 593 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 594 IPv6 over Low-Power Wireless Personal Area Networks 595 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 596 2014, . 598 14.2. Informative References 600 [Addendum_an] 601 American Society of Heating, Refrigerating, and Air- 602 Conditioning Engineers, "ANSI/ASHRAE Addenda an, at, au, 603 av, aw, ax, and az to ANSI/ASHRAE Standard 135-2012, 604 BACnet - A Data Communication Protocol for Building 605 Automation and Control Networks", July 2014, 606 . 609 [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte 610 Stuffing", IEEE/ACM TRANSACTIONS ON NETWORKING, VOL.7, 611 NO.2 , April 1999, 612 . 614 [CRC32K] Koopman, P., "32-Bit Cyclic Redundancy Codes for Internet 615 Applications", IEEE/IFIP International Conference on 616 Dependable Systems and Networks (DSN 2002) , June 2002, 617 . 620 [IEEE.802.3_2012] 621 IEEE, "802.3-2012", IEEE 802.3-2012, 622 DOI 10.1109/ieeestd.2012.6419735, January 2013, 623 . 626 [RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical 627 Ordering Of Link-Layer Addresses", RFC 2469, 628 DOI 10.17487/RFC2469, December 1998, 629 . 631 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 632 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 633 February 2017, . 635 [TIA-485-A] 636 Telecommunications Industry Association, "TIA-485-A, 637 Electrical Characteristics of Generators and Receivers for 638 Use in Balanced Digital Multipoint Systems (ANSI/TIA/EIA- 639 485-A-98) (R2003)", March 2003, . 642 Appendix A. Abstract MAC Interface 644 This Appendix is informative and not part of the standard. 646 [BACnet] Clause 9 provides support for MAC-layer clients through its 647 SendFrame and ReceivedDataNoReply procedures. However, it does not 648 define a network-protocol independent abstract interface for the MAC. 649 This is provided below as an aid to implementation. 651 A.1. MA-DATA.request 653 A.1.1. Function 655 This primitive defines the transfer of data from a MAC client entity 656 to a single peer entity or multiple peer entities in the case of a 657 broadcast address. 659 A.1.2. Semantics of the Service Primitive 661 The semantics of the primitive are as follows: 663 MA-DATA.request ( 664 destination_address, 665 source_address, 666 data, 667 type 668 ) 670 The 'destination_address' parameter may specify either an individual 671 or a broadcast MAC entity address. It must contain sufficient 672 information to create the Destination Address field (see Section 1.3) 673 that is prepended to the frame by the local MAC sublayer entity. The 674 'source_address' parameter, if present, must specify an individual 675 MAC address. If the source_address parameter is omitted, the local 676 MAC sublayer entity will insert a value associated with that entity. 678 The 'data' parameter specifies the MAC service data unit (MSDU) to be 679 transferred by the MAC sublayer entity. There is sufficient 680 information associated with the MSDU for the MAC sublayer entity to 681 determine the length of the data unit. 683 The 'type' parameter specifies the value of the MS/TP Frame Type 684 field that is prepended to the frame by the local MAC sublayer 685 entity. 687 A.1.3. When Generated 689 This primitive is generated by the MAC client entity whenever data 690 shall be transferred to a peer entity or entities. This can be in 691 response to a request from higher protocol layers or from data 692 generated internally to the MAC client, such as a Token frame. 694 A.1.4. Effect on Receipt 696 Receipt of this primitive will cause the MAC entity to insert all MAC 697 specific fields, including Destination Address, Source Address, Frame 698 Type, and any fields that are unique to the particular media access 699 method, and pass the properly formed frame to the lower protocol 700 layers for transfer to the peer MAC sublayer entity or entities. 702 A.2. MA-DATA.indication 704 A.2.1. Function 706 This primitive defines the transfer of data from the MAC sublayer 707 entity to the MAC client entity or entities in the case of a 708 broadcast address. 710 A.2.2. Semantics of the Service Primitive 712 The semantics of the primitive are as follows: 714 MA-DATA.indication ( 715 destination_address, 716 source_address, 717 data, 718 type 719 ) 721 The 'destination_address' parameter may be either an individual or a 722 broadcast address as specified by the Destination Address field of 723 the incoming frame. The 'source_address' parameter is an individual 724 address as specified by the Source Address field of the incoming 725 frame. 727 The 'data' parameter specifies the MAC service data unit (MSDU) as 728 received by the local MAC entity. There is sufficient information 729 associated with the MSDU for the MAC sublayer client to determine the 730 length of the data unit. 732 The 'type' parameter is the value of the MS/TP Frame Type field of 733 the incoming frame. 735 A.2.3. When Generated 737 The MA_DATA.indication is passed from the MAC sublayer entity to the 738 MAC client entity or entities to indicate the arrival of a frame to 739 the local MAC sublayer entity that is destined for the MAC client. 740 Such frames are reported only if they are validly formed, received 741 without error, and their destination address designates the local MAC 742 entity. Frames destined for the MAC Control sublayer are not passed 743 to the MAC client. 745 A.2.4. Effect on Receipt 747 The effect of receipt of this primitive by the MAC client is 748 unspecified. 750 Appendix B. Consistent Overhead Byte Stuffing [COBS] 752 This Appendix is informative and not part of the standard. 754 [BACnet] Clause 9 corrects a long-standing issue with the MS/TP 755 specification; namely that preamble sequences were not escaped 756 whenever they appeared in the Data or Data CRC fields. In rare 757 cases, this resulted in dropped frames due to loss of frame 758 synchronization. The solution is to encode the Data and 32-bit Data 759 CRC fields before transmission using Consistent Overhead Byte 760 Stuffing [COBS] and decode these fields upon reception. 762 COBS is a run-length encoding method that nominally removes '0x00' 763 octets from its input. Any selected octet value may be removed by 764 XOR'ing that value with each octet of the COBS output. [BACnet] 765 Clause 9 specifies the preamble octet '0x55' for removal. 767 The minimum overhead of COBS is one octet per encoded field. The 768 worst-case overhead in long fields is bounded to one octet per 254 as 769 described in [COBS]. 771 Frame encoding proceeds logically in two passes. The Encoded Data 772 field is prepared by passing the MSDU through the COBS encoder and 773 XOR'ing the preamble octet '0x55' with each octet of the output. The 774 Encoded CRC-32K field is then prepared by calculating a CRC-32K over 775 the Encoded Data field and formatting it for transmission as 776 described in Appendix C. The combined length of these fields, minus 777 two octets for compatibility with legacy MS/TP devices, is placed in 778 the MS/TP header Length field before transmission. 780 Example COBS encoder and decoder functions are shown below for 781 illustration. Complete examples of use and test vectors are provided 782 in [BACnet] Annex T. 784 786 #include 787 #include 789 /* 790 * Encodes 'length' octets of data located at 'from' and 791 * writes one or more COBS code blocks at 'to', removing any 792 * 'mask' octets that may present be in the encoded data. 793 * Returns the length of the encoded data. 794 */ 796 size_t 797 cobs_encode (uint8_t *to, const uint8_t *from, size_t length, 798 uint8_t mask) 799 { 800 size_t code_index = 0; 801 size_t read_index = 0; 802 size_t write_index = 1; 803 uint8_t code = 1; 804 uint8_t data, last_code; 806 while (read_index < length) { 807 data = from[read_index++]; 808 /* 809 * In the case of encountering a non-zero octet in the data, 810 * simply copy input to output and increment the code octet. 811 */ 812 if (data != 0) { 813 to[write_index++] = data ^ mask; 814 code++; 815 if (code != 255) 816 continue; 817 } 818 /* 819 * In the case of encountering a zero in the data or having 820 * copied the maximum number (254) of non-zero octets, store 821 * the code octet and reset the encoder state variables. 822 */ 823 last_code = code; 824 to[code_index] = code ^ mask; 825 code_index = write_index++; 826 code = 1; 827 } 828 /* 829 * If the last chunk contains exactly 254 non-zero octets, then 830 * this exception is handled above (and returned length must be 831 * adjusted). Otherwise, encode the last chunk normally, as if 832 * a "phantom zero" is appended to the data. 833 */ 834 if ((last_code == 255) && (code == 1)) 835 write_index--; 836 else 837 to[code_index] = code ^ mask; 839 return write_index; 840 } 841 #include 842 #include 844 /* 845 * Decodes 'length' octets of data located at 'from' and 846 * writes the original client data at 'to', restoring any 847 * 'mask' octets that may present in the encoded data. 848 * Returns the length of the encoded data or zero if error. 849 */ 850 size_t 851 cobs_decode (uint8_t *to, const uint8_t *from, size_t length, 852 uint8_t mask) 853 { 854 size_t read_index = 0; 855 size_t write_index = 0; 856 uint8_t code, last_code; 858 while (read_index < length) { 859 code = from[read_index] ^ mask; 860 last_code = code; 861 /* 862 * Sanity check the encoding to prevent the while() loop below 863 * from overrunning the output buffer. 864 */ 865 if (read_index + code > length) 866 return 0; 868 read_index++; 869 while (--code > 0) 870 to[write_index++] = from[read_index++] ^ mask; 871 /* 872 * Restore the implicit zero at the end of each decoded block 873 * except when it contains exactly 254 non-zero octets or the 874 * end of data has been reached. 875 */ 876 if ((last_code != 255) && (read_index < length)) 877 to[write_index++] = 0; 878 } 879 return write_index; 880 } 882 884 Appendix C. Encoded CRC-32K [CRC32K] 886 This Appendix is informative and not part of the standard. 888 Extending the payload of MS/TP to 1500 octets required upgrading the 889 Data CRC from 16 bits to 32 bits. P.Koopman has authored several 890 papers on evaluating CRC polynomials for network applications. In 891 [CRC32K], he surveyed the entire 32-bit polynomial space and noted 892 some that exceed the [IEEE.802.3_2012] polynomial in performance. 893 [BACnet] Clause 9 specifies one of these, the CRC-32K (Koopman) 894 polynomial. 896 The specified use of the calc_crc32K() function is as follows. 897 Before a frame is transmitted, 'crc_value' is initialized to all 898 ones. After passing each octet of the [COBS] Encoded Data through 899 the function, the ones complement of the resulting 'crc_value' is 900 arranged in LSB-first order and is itself [COBS] encoded. The length 901 of the resulting Encoded CRC-32K field is always five octets. 903 Upon reception of a frame, 'crc_value' is initialized to all ones. 904 The octets of the Encoded Data field are accumulated by the 905 calc_crc32K() function before decoding. The Encoded CRC-32K field is 906 then decoded and the resulting four octets are accumulated by the 907 calc_crc32K() function. If the result is the expected residue value 908 'CRC32K_RESIDUE', then the frame was received correctly. 910 An example CRC-32K function in shown below for illustration. 911 Complete examples of use and test vectors are provided in [BACnet] 912 Annex G.3. 914 916 #include 918 /* See BACnet Addendum 135-2012an, section G.3.2 */ 919 #define CRC32K_INITIAL_VALUE (0xFFFFFFFF) 920 #define CRC32K_RESIDUE (0x0843323B) 922 /* CRC-32K polynomial, 1 + x**1 + ... + x**30 (+ x**32) */ 923 #define CRC32K_POLY (0xEB31D82E) 925 /* 926 * Accumulate 'data_value' into the CRC in 'crc_value'. 927 * Return updated CRC. 928 * 929 * Note: crc_value must be set to CRC32K_INITIAL_VALUE 930 * before initial call. 931 */ 932 uint32_t 933 calc_crc32K (uint8_t data_value, uint32_t crc_value) 934 { 935 int b; 937 for (b = 0; b < 8; b++) { 938 if ((data_value & 1) ^ (crc_value & 1)) { 939 crc_value >>= 1; 940 crc_value ^= CRC32K_POLY; 941 } else { 942 crc_value >>= 1; 943 } 944 data_value >>= 1; 945 } 946 return crc_value; 947 } 949 951 Appendix D. Example 6LoBAC Frame Decode 953 This Appendix is informative and not part of the standard. 955 BACnet MS/TP, Src (2), Dst (1), IPv6 Encapsulation 956 Preamble 55: 0x55 957 Preamble FF: 0xff 958 Frame Type: IPv6 Encapsulation (34) 959 Destination Address: 1 960 Source Address: 2 961 Length: 537 962 Header CRC: 0x1c [correct] 963 Extended Data CRC: 0x9e7259e2 [correct] 964 6LoWPAN 965 IPHC Header 966 011. .... = Pattern: IP header compression (0x03) 967 ...1 1... .... .... = Traffic class and flow label: 968 Version, traffic class, and flow label 969 compressed (0x0003) 970 .... .0.. .... .... = Next header: Inline 971 .... ..00 .... .... = Hop limit: Inline (0x0000) 972 .... .... 1... .... = Context identifier extension: True 973 .... .... .1.. .... = Source address compression: Stateful 974 .... .... ..01 .... = Source address mode: 975 64-bits inline (0x0001) 976 .... .... .... 0... = Multicast address compression: False 977 .... .... .... .1.. = Destination address compression: 978 Stateful 979 .... .... .... ..10 = Destination address mode: 980 16-bits inline (0x0002) 981 0000 .... = Source context identifier: 0x00 982 .... 0000 = Destination context identifier: 0x00 983 [Source context: aaaa:: (aaaa::)] 984 [Destination context: aaaa:: (aaaa::)] 985 Next header: ICMPv6 (0x3a) 986 Hop limit: 63 987 Source: aaaa::1 (aaaa::1) 988 Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1) 989 Internet Protocol Version 6, Src: aaaa::1 (aaaa::1), 990 Dst: aaaa::ff:fe00:1 (aaaa::ff:fe00:1) 991 0110 .... .... .... .... .... .... .... = Version: 6 992 .... 0000 0000 .... .... .... .... .... = Traffic class: 993 0x00000000 994 .... 0000 00.. .... .... .... .... .... = Differentiated 995 Services Field: 996 Default (0x00000000) 997 .... .... ..0. .... .... .... .... .... = ECN-Capable Transport 998 (ECT): Not set 999 .... .... ...0 .... .... .... .... .... = ECN-CE: Not set 1000 .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 1001 Payload length: 518 1002 Next header: ICMPv6 (58) 1003 Hop limit: 63 1004 Source: aaaa::1 (aaaa::1) 1005 Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1) 1006 Internet Control Message Protocol v6 1007 Type: Echo (ping) request (128) 1008 Code: 0 1009 Checksum: 0x783f [correct] 1010 Identifier: 0x2ee5 1011 Sequence: 2 1012 [Response In: 5165] 1013 Data (510 bytes) 1014 Data: e4dbe8553ba0040008090a0b0c0d0e0f1011121314151617... 1015 [Length: 510] 1017 Frame (547 bytes): 1018 55 ff 22 01 02 02 19 1c 56 2d 83 56 6f 6a 54 54 U.".....V-.VojTT 1019 54 54 54 54 57 54 56 54 d5 50 2d 6a 7b b0 5c 57 TTTTWTVT.P-j{.\W 1020 b1 8e bd 00 6e f5 51 ac 5d 5c 5f 5e 59 58 5b 5a ....n.Q.]\_^YX[Z 1021 45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ 1022 75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z 1023 65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj 1024 15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................ 1025 05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................ 1026 35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=98;: 1027 25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+* 1028 d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................ 1029 c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................ 1030 f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................ 1031 e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................ 1032 95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................ 1033 85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................ 1034 b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................ 1035 a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 ab aa ................ 1036 ab 54 57 56 51 50 53 52 5d 5c 5f 5e 59 58 5b 5a .TWVQPSR]\_^YX[Z 1037 45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ 1038 75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z 1039 65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj 1040 15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................ 1041 05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................ 1042 35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=98;: 1043 25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+* 1044 d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................ 1045 c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................ 1046 f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................ 1047 e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................ 1048 95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................ 1049 85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................ 1050 b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................ 1051 a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 50 cb ..............P. 1052 27 0c b7 '.. 1054 Decoded Data and CRC32K (537 bytes): 1055 78 d6 00 3a 3f 00 00 00 00 00 00 00 01 00 01 80 x..:?........... 1056 00 78 3f 2e e5 00 02 e4 db e8 55 3b a0 04 00 08 .x?.......U;.... 1057 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................ 1058 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'( 1059 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678 1060 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH 1061 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX 1062 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh 1063 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx 1064 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~.......... 1065 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................ 1066 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................ 1067 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................ 1068 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................ 1069 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................ 1070 d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................ 1071 e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................ 1072 f9 fa fb fc fd fe ff 00 01 02 03 04 05 06 07 08 ................ 1073 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................ 1074 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'( 1075 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678 1076 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH 1077 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX 1078 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh 1079 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx 1080 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~.......... 1081 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................ 1082 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................ 1083 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................ 1084 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................ 1085 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................ 1086 d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................ 1087 e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................ 1088 f9 fa fb fc fd 9e 72 59 e2 ......rY. 1090 Decompressed 6LoWPAN IPHC (558 bytes): 1091 60 00 00 00 02 06 3a 3f aa aa 00 00 00 00 00 00 `.....:?........ 1092 00 00 00 00 00 00 00 01 aa aa 00 00 00 00 00 00 ................ 1093 00 00 00 ff fe 00 00 01 80 00 78 3f 2e e5 00 02 ..........x?.... 1094 e4 db e8 55 3b a0 04 00 08 09 0a 0b 0c 0d 0e 0f ...U;........... 1095 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 1096 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 1097 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? 1098 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO 1099 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_ 1100 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno 1101 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~. 1102 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................ 1103 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................ 1104 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................ 1105 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................ 1106 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................ 1107 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................ 1108 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................ 1109 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff ................ 1110 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................ 1111 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 1112 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 1113 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? 1114 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO 1115 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_ 1116 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno 1117 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~. 1118 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................ 1119 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................ 1120 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................ 1121 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................ 1122 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................ 1123 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................ 1124 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................ 1125 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd .............. 1127 Authors' Addresses 1129 Kerry Lynn (editor) 1130 Verizon Labs 1131 50 Sylvan Rd 1132 Waltham , MA 02451 1133 USA 1135 Phone: +1 781 296 9722 1136 Email: kerlyn@ieee.org 1138 Jerry Martocci 1139 Johnson Controls, Inc. 1140 507 E. Michigan St 1141 Milwaukee , WI 53202 1142 USA 1144 Email: jpmartocci@sbcglobal.net 1146 Carl Neilson 1147 Delta Controls, Inc. 1148 17850 56th Ave 1149 Surrey , BC V3S 1C7 1150 Canada 1152 Phone: +1 604 575 5913 1153 Email: cneilson@deltacontrols.com 1155 Stuart Donaldson 1156 Honeywell Automation & Control Solutions 1157 6670 185th Ave NE 1158 Redmond , WA 98052 1159 USA 1161 Email: stuart.donaldson@honeywell.com