--- 1/draft-ietf-6lo-6lobac-07.txt 2017-03-13 17:14:04.759119975 -0700 +++ 2/draft-ietf-6lo-6lobac-08.txt 2017-03-13 17:14:04.811121223 -0700 @@ -1,23 +1,23 @@ 6Lo Working Group K. Lynn, Ed. Internet-Draft Verizon Labs Intended status: Standards Track J. Martocci -Expires: August 31, 2017 Johnson Controls +Expires: September 11, 2017 Johnson Controls C. Neilson Delta Controls S. Donaldson Honeywell - February 27, 2017 + March 10, 2017 Transmission of IPv6 over MS/TP Networks - draft-ietf-6lo-6lobac-07 + draft-ietf-6lo-6lobac-08 Abstract Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily 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,21 +28,21 @@ 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 August 31, 2017. + This Internet-Draft will expire on September 11, 2017. Copyright Notice Copyright (c) 2017 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 @@ -64,48 +64,48 @@ 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 10 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 14 Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 17 Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 20 - Appendix D. Example 6LoBAC Packet Decode . . . . . . . . . . . . 22 + Appendix D. Example 6LoBAC Frame Decode . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Master-Slave/Token-Passing (MS/TP) is a medium access control (MAC) protocol for the RS-485 [TIA-485-A] physical layer and is used primarily 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, - where noted, elements of the 6LoWPAN specifications [RFC4944], - [RFC6282], and [RFC6775] to constrained wired networks. + IPv6 addresses on MS/TP networks. The general approach is to adapt + elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and + [RFC6775] to constrained wired networks, as noted below. An MS/TP device is typically based on a low-cost microcontroller with limited processing power and memory. These constraints, together with low data rates and a small MAC address space, are similar to those faced in 6LoWPAN networks. MS/TP differs significantly from 6LoWPAN in at least three respects: a) MS/TP devices are typically mains powered, b) all MS/TP devices on a segment can communicate directly so there are no hidden node or mesh routing issues, and c) the latest MS/TP specification provides support for large payloads, eliminating the need for fragmentation and reassembly below IPv6. The following sections provide a brief overview of MS/TP, then describe how to form IPv6 addresses and encapsulate IPv6 packets in - MS/TP frames. The encapsulation (subsequently referred to as - "LoBAC") supports a REQUIRED header compression mechanism that is + MS/TP frames. This specifcation (subsequently referred to as + "6LoBAC") includes a REQUIRED header compression mechanism that is based on LOWPAN_IPHC [RFC6282] and improves MS/TP link utilization. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Abbreviations Used @@ -123,49 +123,49 @@ MTU: Maximum Transmission Unit; the size of the largest network layer protocol data unit that can be communicated in a single network transaction UART: Universal Asynchronous Transmitter/Receiver 1.3. MS/TP Overview This section provides a brief overview of MS/TP, as specified in - ANSI/ASHRAE Std 135-2016 [BACnet] Clause 9. This version of [BACnet] - Clause 9 incorporates changes to legacy MS/TP, introduced in ANSI/ - ASHRAE Addendum an to ANSI/ASHRAE Std 135-2012 [Addendum_an], that - support larger frame sizes and improved error handling. [BACnet] - Clause 9 also covers physical layer deployment options. + ANSI/ASHRAE Standard 135-2016 [BACnet] Clause 9. The latest version + of [BACnet] integrates changes to legacy MS/TP (approved as + [Addendum_an]) that provide support for larger frame sizes and + improved error handling. [BACnet] Clause 9 also covers physical + layer deployment options. MS/TP is designed to enable multidrop networks over shielded twisted pair wiring. It can support network segments up to 1000 meters in - length at a data rate of 115,200 bit/s, or segments up to 1200 meters - in length at lower bit 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 5 ms resolution timer. The MS/TP MAC is typically implemented - in software. + length at a data rate of 115.2 kbit/s, or segments up to 1200 meters + in length at lower bit rates. An MS/TP interface requires only a + UART, an RS-485 [TIA-485-A] transceiver with a driver that can be + disabled, and a 5 ms resolution timer. The MS/TP MAC is typically + implemented in software. 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 only 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). If present on the link, - legacy MS/TP implementations (including any slave nodes) ignore the - frame format defined in this specification. + Only an MS/TP master node can initiate the unsolicited transfer of + data, and only 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). If + present on the link, legacy MS/TP implementations (including any + slave nodes) ignore the frame format defined in this specification. [BACnet] Clause 9 defines a range of Frame Type values used to designate frames that contain data and data CRC fields encoded using Consistent Overhead Byte Stuffing [COBS] (see Appendix B). The purpose of COBS encoding is to eliminate preamble sequences from the Encoded Data and Encoded CRC-32K fields. The Encoded Data is covered - by a 32-bit CRC [CRC32K] (see Appendix C) which is also COBS encoded. + by a 32-bit CRC [CRC32K] (see Appendix C) that is also COBS encoded. MS/TP COBS-encoded frames have the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x55 | 0xFF | Frame Type | DA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA | Length (MS octet first) | Header CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -191,83 +191,86 @@ Encoded Data 2 - 1506 octets (see Section 4 and Appendix B) Encoded CRC-32K five octets (see Appendix C) (pad) (optional) at most one octet of trailer: 0xFF The Frame Type is used to distinguish between different types of MAC frames. The types relevant to this specification (in decimal) are: 0 Token 1 Poll For Master 2 Reply To Poll For Master + 3 Test_Request + 4 Test_Response ... 34 IPv6 over MS/TP (LoBAC) Encapsulation Frame Types 8 - 31 and 35 - 127 are reserved for assignment by ASHRAE. Frame Types 32 - 127 designate COBS-encoded frames that - convey Encoded Data and Encoded CRC-32K fields. All master nodes - must understand Token, Poll For Master, and Reply to Poll For Master - control frames. See Section 2 for additional details. + convey Encoded Data and Encoded CRC-32K fields. See Section 2 for + additional details. The Destination and Source Addresses are each one octet in length. See Section 3 for additional details. For COBS-encoded frames, the Length field indicates the size of the [COBS] Encoded Data field in octets, plus three. (This adjustment is required in order for legacy MS/TP devices to ignore COBS-encoded frames.) See Section 4 and Appendices for additional details. The Header CRC field covers the Frame Type, Destination Address, Source Address, and Length fields. The Header CRC generation and check procedures are specified in [BACnet] Annex G.1. Use of the optional 0xFF trailer octet is discussed in [BACnet] Clause 9. 1.4. Goals and Constraints - The main goals of this specification are to a) enable IPv6 directly + The main goals of this specification are a) to enable IPv6 directly on wired end devices in building automation and control networks by leveraging existing standards to the greatest extent possible, and b) - co-exist with legacy MS/TP implementations. Co-existence allows MS/ - TP networks to be incrementally upgraded to support IPv6. + to co-exist with legacy MS/TP implementations. Co-existence allows + MS/TP networks to be incrementally upgraded to support IPv6. In order to co-exist with legacy devices, no changes are permitted to the MS/TP addressing modes, frame header format, control frames, or Master Node state machine as specified in [BACnet] Clause 9. 2. Profile for IPv6 over MS/TP ASHRAE has assigned an MS/TP Frame Type value of 34 to indicate IPv6 over MS/TP (LoBAC) Encapsulation. This falls within the range of values that designate COBS-encoded data frames. 2.1. Mandatory Features - Nodes that support IPv6 over MS/TP must implement the Master Node - state machine as specified in [BACnet] Clause 9 and handle Token, - Poll For Master, and Reply to Poll For Master control frames. - Additionally, nodes must implement a Receive Frame state machine as - specified in [BACnet] Clause 9 that handles COBS-encoded frames. + [BACnet] Clause 9 specifies mandatory to implement features of MS/TP + devices. E.g., it is mandatory that all MS/TP nodes respond to a + Test_Request with a Test_Response frame. All MS/TP master nodes must + implement the Master Node state machine and handle Token, Poll For + Master, and Reply to Poll For Master control frames. 6LoBAC nodes + are MS/TP master nodes that implement a Receive Frame state machine + capable of handling COBS-encoded frames. - MS/TP nodes that support IPv6 MUST support a data rate of 115,200 - bit/s and MAY optionally support lower data rates as specified in - [BACnet] Clause 9. + 6LoBAC nodes must support a data rate of 115.2 kbit/s and may support + lower data rates as specified in [BACnet] Clause 9. The method of + selecting the data rate is outside the scope of this specification. 2.2. Configuration Constants The following constants are used by the Receive Frame state machine. - Nmin_COBS_length The minimum valid length of any LoBAC encapsulated - frame: 5 + Nmin_COBS_length The minimum valid Length value of any LoBAC + encapsulated frame: 5 - Nmax_COBS_length The maximum valid length of any LoBAC encapsulated - frame: 1509 + Nmax_COBS_length The maximum valid Length value of any LoBAC + encapsulated frame: 1509 2.3. Configuration Parameters The following parameters are used by the Master Node state machine. Nmax_info_frames The default maximum number of information frames the node may send before it must pass the token: 1 Nmax_master The default highest allowable address for master nodes: 127 @@ -298,39 +301,38 @@ 4. Maximum Transmission Unit (MTU) Upon transmission, the network layer MTU is formatted according to Section 5 and becomes the MAC service data unit (MSDU). The MSDU is then COBS encoded by MS/TP. Upon reception, the steps are reversed. [BACnet] Clause 9 supports MSDUs up to 2032 octets in length. IPv6 [RFC2460] requires that every link in the internet have an MTU of 1280 octets or greater. Additionally, a node must be able to accept a fragmented packet that, after reassembly, is as large as - 1500 octets. This specification defines an MSDU length of at least - 1280 octets and at most 1500 octets. Support for an MSDU length of + 1500 octets. This specification defines an MTU length of at least + 1280 octets and at most 1500 octets. Support for an MTU length of 1500 octets is RECOMMENDED. 5. LoBAC Adaptation Layer This section specifies an adaptation layer to support compressed IPv6 headers as specified in Section 10. IPv6 header compression MUST be implemented on all nodes. Implementations MAY also support Generic Header Compression [RFC7400] for transport layer headers. The LoBAC encapsulation format defined in this section describes the MSDU of an IPv6 over MS/TP frame. The LoBAC payload (i.e., an IPv6 packet) follows an encapsulation header stack. LoBAC is a subset of - the LoWPAN encapsulation defined in [RFC4944] as updated by - [RFC6282], therefore the use of "LOWPAN" in literals below is - intentional. The primary difference between LoWPAN and LoBAC is - omission of the Mesh, Broadcast, Fragmentation, and LOWPAN_HC1 - headers. + the LoWPAN encapsulation defined in [RFC4944] as updated by [RFC6282] + so the use of "LOWPAN" in literals below is intentional. The primary + difference between LoWPAN and LoBAC encapsulation is omission of the + Mesh, Broadcast, Fragmentation, and LOWPAN_HC1 headers in the latter. All LoBAC encapsulated datagrams transmitted over MS/TP are prefixed by an encapsulation header stack consisting of a Dispatch value followed by zero or more header fields. The only sequence currently defined for LoBAC is the LOWPAN_IPHC header followed by payload, as shown below: +---------------+---------------+------...-----+ | IPHC Dispatch | IPHC Header | Payload | +---------------+---------------+------...-----+ @@ -367,22 +369,22 @@ concatenating the 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| +----------------+----------------+----------------+----------------+ - A semantically opaque IID having 64 bits of entropy is strongly - RECOMMENDED for each routable address and MAY be locally generated + A semantically opaque IID having 64 bits of entropy is RECOMMENDED + for each globally scoped address and MAY be locally generated according to one of the methods cited in Section 12. A node that generates a 64-bit semantically opaque IID MUST register the IID with its local router(s) by sending a Neighbor Solicitation (NS) message with the Address Registration Option (ARO) and process Neighbor Advertisements (NA) according to [RFC6775]. An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an MS/TP interface MUST have a length of 64 bits. 7. IPv6 Link Local Address @@ -440,21 +442,21 @@ formed by padding on the left with a zero octet: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0xFF | +-+-+-+-+-+-+-+-+---------------+ 10. Header Compression - LoBAC uses LOWPAN_IPHC IPv6 compression, which is specified in + 6LoBAC REQUIRES LOWPAN_IPHC IPv6 compression, which is specified in [RFC6282] and included herein by reference. This section will simply identify substitutions that should be made when interpreting the text of [RFC6282]. In general the following substitutions should be made: - Replace instances of "6LoWPAN" with "MS/TP network" - Replace instances of "IEEE 802.15.4 address" with "MS/TP address" @@ -474,66 +476,59 @@ 11. IANA Considerations This document uses values previously reserved by [RFC4944] and [RFC6282] and makes no further requests of IANA. Note to RFC Editor: this section may be removed upon publication. 12. Security Considerations - See [I-D.ietf-6lo-privacy-considerations] for a general discussion of - privacy threats faced by constrained nodes. + See [RFC8065] for a general discussion of privacy threats faced by + constrained nodes. - [I-D.ietf-6lo-privacy-considerations] makes a distinction between - "stable" and "temporary" addresses. The former are long-lived and - typically advertised by servers. The latter are typically used by - clients and SHOULD be changed frequently to mitigate correlation of - activities over time. Nodes that engage in both activities SHOULD - support simultaneous use of multiple addresses per device. + [RFC8065] makes a distinction between "stable" and "temporary" + addresses. The former are long-lived and typically advertised by + servers. The latter are typically used by clients and SHOULD be + changed frequently to mitigate correlation of activities over time. + Nodes that engage in both activities SHOULD support simultaneous use + of multiple addresses per device. Globally scoped addresses that contain MAC-address-derived IIDs may expose a network to address scanning attacks. For this reason, it is - strongly RECOMMENDED that a 64-bit semantically opaque IID be - generated for each globally scoped address in use according to, for - example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]. + RECOMMENDED that a 64-bit semantically opaque IID be generated for + each globally scoped address in use according to, for example, + [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]. 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. 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 encoding the data and CRC32K fields separately would - allow the CRC to be calculated on-the-fly. Alexandru Petrescu, Brian - Frank, Geoff Mulligan, and Don Sturek offered valuable comments. + and support from the outset. Peter van der Stok, James Woodyatt, + Carsten Bormann, and Dale Worley provided detailed reviews. Stuart + Cheshire invented the very clever COBS encoding. Michael Osborne + made the critical observation that encoding the data and CRC32K + fields separately 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, - . - [BACnet] American Society of Heating, Refrigerating, and Air- Conditioning Engineers, "BACnet - A Data Communication Protocol for Building Automation and Control Networks", - ANSI/ASHRAE 135-2016 (Clause 9), January 2016, - . + ANSI/ASHRAE Standard 135-2016, January 2016, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 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, DOI 10.17487/RFC2460, December 1998, . @@ -595,55 +590,61 @@ DOI 10.17487/RFC7217, April 2014, . [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, . 14.2. Informative References + [Addendum_an] + American Society of Heating, Refrigerating, and Air- + Conditioning Engineers, "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, + . + [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 Dependable Systems and Networks (DSN 2002) , June 2002, - . - [I-D.ietf-6lo-privacy-considerations] - Thaler, D., "Privacy Considerations for IPv6 Adaptation - Layer Mechanisms", draft-ietf-6lo-privacy- - considerations-04 (work in progress), October 2016. - - [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, - . + [IEEE.802.3_2012] + IEEE, "802.3-2012", IEEE 802.3-2012, + DOI 10.1109/ieeestd.2012.6419735, January 2013, + . [RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, DOI 10.17487/RFC2469, December 1998, . + [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- + Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, + February 2017, . + [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. + 485-A-98) (R2003)", March 2003, . Appendix A. Abstract MAC Interface This Appendix is informative and not part of the standard. [BACnet] Clause 9 provides support for MAC-layer clients through its SendFrame and ReceivedDataNoReply procedures. However, it does not define a network-protocol independent abstract interface for the MAC. This is provided below as an aid to implementation. @@ -765,26 +767,26 @@ The minimum overhead of COBS is one octet per encoded field. The worst-case overhead in long fields is bounded to one octet per 254 as described in [COBS]. Frame encoding proceeds logically in two passes. The Encoded Data field is prepared by passing the MSDU through the COBS encoder and XOR'ing the preamble octet '0x55' with each octet of the output. The Encoded CRC-32K field is then prepared by calculating a CRC-32K over the Encoded Data field and formatting it for transmission as described in Appendix C. The combined length of these fields, minus - two octets for compatibility with existing MS/TP devices, is placed - in the MS/TP header Length field before transmission. + two octets for compatibility with legacy MS/TP devices, is placed in + the MS/TP header Length field before transmission. Example COBS encoder and decoder functions are shown below for illustration. Complete examples of use and test vectors are provided - in [BACnet] Clause 9. + in [BACnet] Annex T. #include #include /* * Encodes 'length' octets of data located at 'from' and * writes one or more COBS code blocks at 'to', removing any * 'mask' octets that may present be in the encoded data. @@ -880,41 +882,41 @@ Appendix C. Encoded CRC-32K [CRC32K] This Appendix is informative and not part of the standard. Extending the payload of MS/TP to 1500 octets required upgrading the Data CRC from 16 bits to 32 bits. P.Koopman has authored several papers on evaluating CRC polynomials for network applications. In [CRC32K], he surveyed the entire 32-bit polynomial space and noted - some that exceed the [IEEE.802.3] polynomial in performance. + some that exceed the [IEEE.802.3_2012] polynomial in performance. [BACnet] Clause 9 specifies one of these, the CRC-32K (Koopman) polynomial. The specified use of the calc_crc32K() function is as follows. Before a frame is transmitted, 'crc_value' is initialized to all ones. After passing each octet of the [COBS] Encoded Data through the function, the ones complement of the resulting 'crc_value' is arranged in LSB-first order and is itself [COBS] encoded. The length of the resulting Encoded CRC-32K field is always five octets. Upon reception of a frame, 'crc_value' is initialized to all ones. The octets of the Encoded Data field are accumulated by the calc_crc32K() function before decoding. The Encoded CRC-32K field is then decoded and the resulting four octets are accumulated by the calc_crc32K() function. If the result is the expected residue value 'CRC32K_RESIDUE', then the frame was received correctly. An example CRC-32K function in shown below for illustration. Complete examples of use and test vectors are provided in [BACnet] - Clause 9. + Annex G.3. #include /* See BACnet Addendum 135-2012an, section G.3.2 */ #define CRC32K_INITIAL_VALUE (0xFFFFFFFF) #define CRC32K_RESIDUE (0x0843323B) /* CRC-32K polynomial, 1 + x**1 + ... + x**30 (+ x**32) */ @@ -939,21 +941,21 @@ } else { crc_value >>= 1; } data_value >>= 1; } return crc_value; } -Appendix D. Example 6LoBAC Packet Decode +Appendix D. Example 6LoBAC Frame Decode This Appendix is informative and not part of the standard. 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