--- 1/draft-ietf-6lo-6lobac-02.txt 2015-10-19 15:15:08.906124089 -0700 +++ 2/draft-ietf-6lo-6lobac-03.txt 2015-10-19 15:15:08.958125363 -0700 @@ -1,23 +1,23 @@ 6Lo Working Group K. Lynn, Ed. Internet-Draft Verizon Labs Intended status: Standards Track J. Martocci -Expires: January 7, 2016 Johnson Controls +Expires: April 21, 2016 Johnson Controls C. Neilson Delta Controls S. Donaldson Honeywell - July 6, 2015 + October 19, 2015 Transmission of IPv6 over MS/TP Networks - draft-ietf-6lo-6lobac-02 + draft-ietf-6lo-6lobac-03 Abstract Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer, which is used extensively in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. Status of This Memo @@ -28,57 +28,58 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 7, 2016. + This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. MS/TP Mode for IPv6 . . . . . . . . . . . . . . . . . . . . . 5 + 2. MS/TP Mode for IPv6 . . . . . . . . . . . . . . . . . . . . . 6 3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 6 4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 6 - 5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 6 - 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 7 + 5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 7 + 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 8 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 8 - 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 8 + 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 9 - 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 9 + 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 13 - Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 15 + Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 16 Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + Appendix D. Example 6LoBAC Packet Decode . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Master-Slave/Token-Passing (MS/TP) is a medium access control (MAC) protocol for the RS-485 [TIA-485-A] physical layer, which is used extensively in building automation networks. This specification defines the frame format for transmission of IPv6 [RFC2460] packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. The general approach is to adapt elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and @@ -126,31 +127,30 @@ UART: Universal Asynchronous Transmitter/Receiver 1.3. MS/TP Overview This section provides a brief overview of MS/TP, which is specified in ANSI/ASHRAE 135-2012 (BACnet) Clause 9 [Clause9] and included herein by reference. BACnet [Clause9] also covers physical layer deployment options. MS/TP is designed to enable multidrop networks over shielded twisted - pair wiring. It can support a data rate of 115,200 baud on segments - up to 1000 meters in length, or segments up to 1200 meters in length - at lower baud rates. An MS/TP link requires only a UART, an RS-485 - [TIA-485-A] transceiver with a driver that can be disabled, and a 5ms - resolution timer. These features make MS/TP a cost-effective field - bus for the most numerous and least expensive devices in a building - automation network. + pair wiring. It can support network segments up to 1000 meters in + length at a data rate of 115,200 baud, or segments up to 1200 meters + in length at lower baud rates. An MS/TP link requires only a UART, + an RS-485 [TIA-485-A] transceiver with a driver that can be disabled, + and a 5ms resolution timer. These features make MS/TP a cost- + effective field bus for the most numerous and least expensive devices + in a building automation network. The differential signaling used by [TIA-485-A] requires a contention- free MAC. MS/TP uses a token to control access to a multidrop bus. - A master node may initiate the transmission of a data frame when it holds the token. After sending at most a configured maximum number of data frames, a master node passes the token to the next master node (as determined by MAC address). Slave nodes do not support the frame format required to convey IPv6 over MS/TP and therefore SHALL NOT be considered part of this specification. MS/TP COBS-encoded* frames have the following format: 0 1 2 3 @@ -239,20 +239,24 @@ over MS/TP (LoBAC) Encapsulation. This falls within the range of values that designate COBS-encoded data frames. All MS/TP master nodes (including those that support IPv6) must understand Token, Poll For Master, and Reply to Poll For Master control frames and support the Master Node state machine as specified in BACnet [Clause9]. MS/TP master nodes that support IPv6 must also support the Receive Frame state machine as specified in [Clause9] and extended by BACnet [Addendum_an]. + All MS/TP nodes that support IPv6 MUST support a data rate of 115,200 + baud and MAY optionally support lower data rates as defined in BACnet + [Clause9]. + 3. Addressing Modes MS/TP node (MAC) addresses are one octet in length. The method of assigning MAC addresses is outside the scope of this specification. However, each MS/TP node on the link MUST have a unique address in order to ensure correct MAC operation. BACnet [Clause9] specifies that addresses 0 through 127 are valid for master nodes. The method specified in Section 6 for creating a MAC- layer-derived Interface Identifier (IID) ensures that an IID of all @@ -266,21 +270,22 @@ This specification assumes that at most one unique local and/or global IPv6 prefix is assigned to each MS/TP segment. Hosts learn IPv6 prefixes via router advertisements according to [RFC4861]. 4. Maximum Transmission Unit (MTU) BACnet [Addendum_an] supports MSDUs up to 2032 octets in length. This specification defines an MSDU length of at least 1280 octets and at most 1500 octets (before encoding). This is sufficient to convey the minimum MTU required by IPv6 [RFC2460] without the need for link- - layer fragmentation and reassembly. + layer fragmentation and reassembly. Support for an MSDU length of + 1500 octets is RECOMMENDED. 5. LoBAC Adaptation Layer The relatively low data rates of MS/TP indicate header compression as a means to reduce latency. This section specifies an adaptation layer to support compressed IPv6 headers and the compression format is specified in Section 10. Implementations MAY also support Generic Header Compression (GHC) [RFC7400] for transport layer headers. A node implementing [RFC7400] @@ -324,22 +329,22 @@ This section defines how to obtain an IPv6 Interface Identifier. The general procedure for creating a MAC-address-derived IID is described in [RFC4291] Appendix A, "Creating Modified EUI-64 Format Interface Identifiers", as updated by [RFC7136]. The IID SHOULD NOT embed an [EUI-64] or any other globally unique hardware identifier assigned to a device (see Section 12). The Interface Identifier for link-local addresses SHOULD be formed by - concatenating its 8-bit MS/TP MAC address to the seven octets 0x00, - 0x00, 0x00, 0xFF, 0xFE, 0x00, 0x00. For example, an MS/TP MAC + concatenating a node's' 8-bit MS/TP MAC address to the seven octets + 0x00, 0x00, 0x00, 0xFF, 0xFE, 0x00, 0x00. For example, an MS/TP MAC address of hexadecimal value 0x4F results in the following IID: |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |0000000000000000|0000000011111111|1111111000000000|0000000001001111| +----------------+----------------+----------------+----------------+ This is the RECOMMENDED method of forming an IID for use in link- local addresses, as it affords the most efficient header compression @@ -373,25 +378,25 @@ description in Section 7.2 of [RFC4861], unless otherwise specified. The Source/Target Link-layer Address option has the following form when the addresses are 8-bit MS/TP MAC-layer (node) addresses. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x00 | MS/TP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Padding (all zeros) + | | - + +-+-+-+-+-+-+-+-+ - | | MS/TP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option fields: Type: 1: for Source Link-layer address. 2: for Target Link-layer address. @@ -456,74 +461,92 @@ [I-D.ietf-6man-ipv6-address-generation-privacy]. The issue most relevant to MS/TP networks is address scanning. This is mainly an issue for routable addresses and probably only for those hosted on the global Internet. This specification RECOMMENDS mitigating this threat according to [I-D.ietf-6man-default-iids]. 13. Acknowledgments We are grateful to the authors of [RFC4944] and members of the IETF 6LoWPAN working group; this document borrows liberally from their - work. + work. Ralph Droms and Brian Haberman provided indispensable guidance + and support from the outset. Peter van der Stok, James Woodyatt, and + Carsten Bormann provided detailed reviews. Stuart Cheshire invented + the very clever COBS encoding. Michael Osborne made the critical + observation that seperately encoding the data and CRC32K fields would + allow the CRC to be calculated on-the-fly. Alexandru Petrescu, Brian + Frank, Geoff Mulligan, and Don Sturek offered valuable comments. 14. References 14.1. Normative References [Addendum_an] ASHRAE, "ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to ANSI/ASHRAE Standard 135-2012, BACnet - A Data Communication Protocol for Building Automation and Control Networks", July 2014, . [Clause9] American Society of Heating, Refrigerating, and Air- Conditioning Engineers, "BACnet - A Data Communication Protocol for Building Automation and Control Networks", ANSI/ASHRAE 135-2012 (Clause 9), March 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, - September 2007. + DOI 10.17487/RFC4861, September 2007, + . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless - Address Autoconfiguration", RFC 4862, September 2007. + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 - Networks", RFC 4944, September 2007. + Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, + . - [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 + [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, - September 2011. + DOI 10.17487/RFC6282, September 2011, + . - [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, - "Neighbor Discovery Optimization for IPv6 over Low-Power - Wireless Personal Area Networks (6LoWPANs)", RFC 6775, - November 2012. + [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. + Bormann, "Neighbor Discovery Optimization for IPv6 over + Low-Power Wireless Personal Area Networks (6LoWPANs)", + RFC 6775, DOI 10.17487/RFC6775, November 2012, + . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 - Interface Identifiers", RFC 7136, February 2014. + Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, + February 2014, . [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks - (6LoWPANs)", RFC 7400, November 2014. + (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November + 2014, . 14.2. Informative References [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte Stuffing", IEEE/ACM TRANSACTIONS ON NETWORKING, VOL.7, NO.2 , April 1999, . [CRC32K] Koopman, P., "32-Bit Cyclic Redundancy Codes for Internet Applications", IEEE/IFIP International Conference on @@ -532,41 +555,42 @@ dsn02_koopman.pdf>. [EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", March 1997, . [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and S. LIU, "Recommendation on Stable IPv6 Interface Identifiers", - draft-ietf-6man-default-iids-04 (work in progress), June - 2015. + draft-ietf-6man-default-iids-08 (work in progress), + October 2015. [I-D.ietf-6man-ipv6-address-generation-privacy] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", - draft-ietf-6man-ipv6-address-generation-privacy-07 (work - in progress), June 2015. + draft-ietf-6man-ipv6-address-generation-privacy-08 (work + in progress), September 2015. [IEEE.802.3] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CMSA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2012, December 2012, . [RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical - Ordering Of Link-Layer Addresses", RFC 2469, December - 1998. + Ordering Of Link-Layer Addresses", RFC 2469, + DOI 10.17487/RFC2469, December 1998, + . [TIA-485-A] Telecommunications Industry Association, "TIA-485-A, Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems (ANSI/TIA/EIA- 485-A-98) (R2003)", March 2003. Appendix A. Abstract MAC Interface This Appendix is informative and not part of the standard. @@ -875,20 +900,222 @@ crc_value >>= 1; crc_value ^= CRC32K_POLY; } else { crc_value >>= 1; } data_value >>= 1; } return crc_value; } +Appendix D. Example 6LoBAC Packet Decode + + This Appendix is informative and not part of the standard. + + No. Time Source Destination + 5161 8.816048 aaaa::1 aaaa::ff:fe00:1 + Protocol Length Info + ICMPv6 547 Echo (ping) request id=0x2ee5, seq=2, + hop limit=63 (reply in 5165) + + Frame 5161: 547 bytes on wire (4376 bits), 547 bytes captured + (4376 bits) on interface 0 + Interface id: 0 (/tmp/pipe) + Encapsulation type: BACnet MS/TP (63) + Arrival Time: Sep 3, 2015 19:46:44.377881000 EDT + [Time shift for this packet: 0.000000000 seconds] + Epoch Time: 1441324004.377881000 seconds + [Time delta from previous captured frame: 0.050715000 seconds] + [Time delta from previous displayed frame: 0.050715000 seconds] + [Time since reference or first frame: 8.816048000 seconds] + Frame Number: 5161 + Frame Length: 547 bytes (4376 bits) + Capture Length: 547 bytes (4376 bits) + [Frame is marked: False] + [Frame is ignored: False] + [Protocols in frame: mstp:6lowpan:ipv6:ipv6.nxt:icmpv6:data] + [Coloring Rule Name: ICMP] + [Coloring Rule String: icmp || icmpv6] + BACnet MS/TP, Src (2), Dst (1), IPv6 Encapsulation + Preamble 55: 0x55 + Preamble FF: 0xff + Frame Type: IPv6 Encapsulation (34) + Destination Address: 1 + Source Address: 2 + Length: 537 + Header CRC: 0x1c [correct] + [Good: True] + [Bad: False] + Extended Data CRC: 0x9e7259e2 [correct] + 6LoWPAN + IPHC Header + 011. .... = Pattern: IP header compression (0x03) + ...1 1... .... .... = Traffic class and flow label: + Version, traffic class, and flow label + compressed (0x0003) + .... .0.. .... .... = Next header: Inline + .... ..00 .... .... = Hop limit: Inline (0x0000) + .... .... 1... .... = Context identifier extension: True + .... .... .1.. .... = Source address compression: Stateful + .... .... ..01 .... = Source address mode: + 64-bits inline (0x0001) + .... .... .... 0... = Multicast address compression: False + .... .... .... .1.. = Destination address compression: + Stateful + .... .... .... ..10 = Destination address mode: + 16-bits inline (0x0002) + 0000 .... = Source context identifier: 0x00 + .... 0000 = Destination context identifier: 0x00 + [Source context: aaaa:: (aaaa::)] + [Destination context: aaaa:: (aaaa::)] + Next header: ICMPv6 (0x3a) + Hop limit: 63 + Source: aaaa::1 (aaaa::1) + Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1) + Internet Protocol Version 6, Src: aaaa::1 (aaaa::1), + Dst: aaaa::ff:fe00:1 (aaaa::ff:fe00:1) + 0110 .... .... .... .... .... .... .... = Version: 6 + .... 0000 0000 .... .... .... .... .... = Traffic class: + 0x00000000 + .... 0000 00.. .... .... .... .... .... = Differentiated + Services Field: + Default (0x00000000) + .... .... ..0. .... .... .... .... .... = ECN-Capable Transport + (ECT): Not set + .... .... ...0 .... .... .... .... .... = ECN-CE: Not set + .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 + Payload length: 518 + Next header: ICMPv6 (58) + Hop limit: 63 + Source: aaaa::1 (aaaa::1) + Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1) + Internet Control Message Protocol v6 + Type: Echo (ping) request (128) + Code: 0 + Checksum: 0x783f [correct] + Identifier: 0x2ee5 + Sequence: 2 + [Response In: 5165] + Data (510 bytes) + Data: e4dbe8553ba0040008090a0b0c0d0e0f1011121314151617... + [Length: 510] + + Frame (547 bytes): + 55 ff 22 01 02 02 19 1c 56 2d 83 56 6f 6a 54 54 U.".....V-.VojTT + 54 54 54 54 57 54 56 54 d5 50 2d 6a 7b b0 5c 57 TTTTWTVT.P-j{.\W + b1 8e bd 00 6e f5 51 ac 5d 5c 5f 5e 59 58 5b 5a ....n.Q.]\_^YX[Z + 45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ + 75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z + 65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj + 15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................ + 05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................ + 35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=98;: + 25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+* + d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................ + c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................ + f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................ + e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................ + 95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................ + 85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................ + b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................ + a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 ab aa ................ + ab 54 57 56 51 50 53 52 5d 5c 5f 5e 59 58 5b 5a .TWVQPSR]\_^YX[Z + 45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ + 75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z + 65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj + 15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................ + 05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................ + 35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=98;: + 25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+* + d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................ + c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................ + f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................ + e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................ + 95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................ + 85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................ + b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................ + a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 50 cb ..............P. + 27 0c b7 '.. + + Decoded Data and CRC32K (537 bytes): + 78 d6 00 3a 3f 00 00 00 00 00 00 00 01 00 01 80 x..:?........... + 00 78 3f 2e e5 00 02 e4 db e8 55 3b a0 04 00 08 .x?.......U;.... + 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................ + 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'( + 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678 + 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH + 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX + 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh + 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx + 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~.......... + 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................ + 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................ + a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................ + b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................ + c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................ + d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................ + e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................ + f9 fa fb fc fd fe ff 00 01 02 03 04 05 06 07 08 ................ + 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................ + 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'( + 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678 + 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH + 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX + 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh + 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx + 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~.......... + 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................ + 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................ + a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................ + b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................ + c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................ + d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................ + e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................ + f9 fa fb fc fd 9e 72 59 e2 ......rY. + + Decompressed 6LoWPAN IPHC (558 bytes): + 60 00 00 00 02 06 3a 3f aa aa 00 00 00 00 00 00 `.....:?........ + 00 00 00 00 00 00 00 01 aa aa 00 00 00 00 00 00 ................ + 00 00 00 ff fe 00 00 01 80 00 78 3f 2e e5 00 02 ..........x?.... + e4 db e8 55 3b a0 04 00 08 09 0a 0b 0c 0d 0e 0f ...U;........... + 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ + 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ + 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? + 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO + 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_ + 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno + 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~. + 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................ + 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................ + a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................ + b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................ + c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................ + d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................ + e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................ + f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff ................ + 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................ + 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ + 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ + 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? + 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO + 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_ + 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno + 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~. + 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................ + 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................ + a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................ + b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................ + c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................ + d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................ + e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................ + f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd .............. + Authors' Addresses Kerry Lynn (editor) Verizon Labs 50 Sylvan Rd Waltham , MA 02451 USA Phone: +1 781 296 9722 Email: kerlyn@ieee.org