idnits 2.17.1 draft-ietf-6man-6lobac-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 178 has weird spacing: '...Address one o...' -- The document date (March 12, 2012) is 4426 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance Working Group K. Lynn, Ed. 3 Internet-Draft Consultant 4 Intended status: Standards Track J. Martocci 5 Expires: September 13, 2012 Johnson Controls 6 C. Neilson 7 Delta Controls 8 S. Donaldson 9 Honeywell 10 March 12, 2012 12 Transmission of IPv6 over MS/TP Networks 13 draft-ietf-6man-6lobac-01 15 Abstract 17 MS/TP (Master-Slave/Token-Passing) is a contention-free access method 18 for the RS-485 physical layer that is used extensively in building 19 automation networks. This document describes 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 13, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. MS/TP Mode for IPv6 . . . . . . . . . . . . . . . . . . . . . 6 59 3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 7 61 5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . . 7 62 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9 63 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 10 64 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10 65 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 11 66 10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 11 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 14.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Appendix A. Extended Data CRC [CRC32K] . . . . . . . . . . . . . 14 74 Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 77 1. Introduction 79 MS/TP (Master-Slave/Token-Passing) is a contention-free access method 80 for the RS-485 [TIA-485-A] physical layer that is used extensively in 81 building automation networks. This document describes the frame 82 format for transmission of IPv6 [RFC2460] packets and the method of 83 forming link-local and statelessly autoconfigured IPv6 addresses on 84 MS/TP networks. The general approach is to adapt elements of the 85 6LoWPAN [RFC4944] specification to constrained wired networks. 87 An MS/TP device is typically based on a low-cost microcontroller with 88 limited processing power and memory. Together with low data rates 89 and a small address space, these constraints are similar to those 90 faced in 6LoWPAN networks and suggest some elements of that solution 91 might be applied. MS/TP differs significantly from 6LoWPAN in at 92 least three respects: a) MS/TP devices typically have a continuous 93 source of power, 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 proposed changes to MS/TP will support payloads of up to 1501 octets, 96 eliminating the need for link-layer fragmentation and reassembly. 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 document also specifies a header compression 101 mechanism, based on [RFC6282], that is recommended in order to make 102 IPv6 practical on low speed MS/TP networks. 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 Check 120 MAC: Medium Access Control 122 MSDU: MAC Service Data Unit (MAC client data) 124 UART: Universal Asynchronous Transmitter/Receiver 126 1.3. MS/TP Overview 128 This section provides a brief overview of MS/TP, which is specified 129 in Clause 9 of ANSI/ASHRAE 135-2010 [BACnet] and included herein by 130 reference. [BACnet] also covers physical layer deployment options. 132 MS/TP is designed to enable multidrop networks over shielded twisted 133 pair wiring. It can support segments up to 1200 meters in length or 134 data rates up to 115,200 baud (at this highest data rate the segment 135 length is limited to 1000 meters). An MS/TP link requires only a 136 UART, a 5ms resolution timer, and a [TIA-485-A] transceiver with a 137 driver that can be disabled. These features combine to make MS/TP a 138 cost-effective field bus for the most numerous and least expensive 139 devices in a building automation network. 141 The differential signaling used by [TIA-485-A] requires a contention- 142 free MAC. MS/TP uses a token to control access to a multidrop bus. 143 A master node may initiate the transmission of a data frame when it 144 holds the token. After sending at most a configured maximum number 145 of data frames, a master node passes the token to the next master 146 node (as determined by node address). Slave nodes transmit only when 147 polled and are not considered part of this specification. 149 MS/TP frames have the following format*: 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | 0x55 | 0xFF | Frame Type* | DA | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | SA | Length (MS octet first) | Header CRC | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 / / 159 / Data and Extended Data CRC fields* / 160 / encoded using Consistent Overhead Byte Stuffing [COBS] / 161 / / 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | optional 0xFF | 164 +-+-+-+-+-+-+-+-+ 166 Figure 1: MS/TP Extended Frame Format 168 *Note: A BACnet proposal [Addendum_an], now in public review, assigns 169 a new Frame Type for IPv6 Encapsulation, extends the maximum length 170 of the Data field to 1501 octets, and specifies a 32-bit Extended 171 Data CRC [CRC32K] for these frames. The Data and Extended Data CRC 172 fields are [COBS] encoded and present only if Length is non-zero. 174 The MS/TP frame fields have the following descriptions**: 176 Preamble two octet preamble: 0x55, 0xFF 177 Frame Type one octet 178 Destination Address one octet address 179 Source Address one octet address 180 Length two octets, most significant octet first 181 Header CRC one octet 182 Data 0 - 1501 octets** 183 (present only if Length is non-zero) 184 Extended Data CRC four octets**, least significant octet first 185 (present only if Length is non-zero) 186 (pad) (optional) at most one octet of trailer: 0xFF 188 The Frame Type is used to distinguish between different types of MAC 189 frames. Currently defined types (in decimal) are: 191 00 Token 192 01 Poll For Master 193 02 Reply To Poll For Master 194 ... 195 10 IPv6 over MS/TP Encapsulation** 197 Frame Types 11 through 127 are reserved for assignment by ASHRAE. 198 All master nodes MUST understand Token, Poll For Master, and Reply to 199 Poll For Master frames. See Section 2 for additional details. 201 The Destination and Source Addresses are each one octet in length. 202 See Section 3 for additional details. 204 A non-zero Length field specifies the length of the [COBS] encoded 205 Data and Extended Data CRC fields in octets, minus two. (Note: This 206 trick is required for co-existence with legacy MS/TP devices.) See 207 Section 4 and Appendices for additional details. 209 The Header CRC field covers the Frame Type, Destination Address, 210 Source Address, and Length fields. The Header CRC generation and 211 check procedures are specified in [BACnet]. 213 **The Data and Extended Data CRC fields are conditional on the Frame 214 Type and the Length and will always be present in frames specified by 215 this document. These fields are concatenated and then encoded before 216 transmission using Consistent Overhead Byte Stuffing [COBS] to remove 217 preamble sequences from the fields. The Extended Data CRC and COBS 218 encoding procedures are specified in the BACnet [Addendum_an] change 219 proposal and briefly summarized in Appendices A and B below. 221 1.4. Goals and Non-goals 223 The primary goal of this specification is to enable IPv6 directly to 224 wired end devices in building automation and control networks, while 225 leveraging existing standards to the greatest extent possible. A 226 secondary goal is to co-exist with legacy MS/TP implementations. 227 Only the minimum changes necessary to support IPv6 over MS/TP are 228 proposed in BACnet [Addendum_an] (see note in Section 1.3). 230 Non-goals include making changes to the MS/TP frame header format, 231 control frames, Master Node state machine, or addressing modes. 232 Also, while the techniques described here may be applicable to other 233 data links, no attempt is made to define a general design pattern. 235 2. MS/TP Mode for IPv6 237 The BACnet [Addendum_an] change proposal allocates a new MS/TP Frame 238 Type from the ASHRAE reserved range to indicate IPv6 Encapsulation. 239 The new Frame Type for IPv6 Encapsulation is 10 (0x0A). 241 All MS/TP master nodes (including those that support IPv6) must 242 understand Token, Poll For Master, and Reply to Poll For Master 243 control frames and support the Master Node state machine as specified 244 in [BACnet]. MS/TP master nodes that support IPv6 must also support 245 the Receive Frame state machine as specified in [BACnet] as extended 246 by [Addendum_an]. 248 3. Addressing Modes 250 MS/TP node (link-layer) addresses are one octet in length. The 251 method of assigning node addresses is outside the scope of this 252 document. However, each MS/TP node on the link MUST have a unique 253 address or a misconfiguration condition exists. 255 [BACnet] specifies that addresses 0 through 127 are valid for master 256 nodes. The method specified in Section 6 for creating the Interface 257 Identifier (IID) ensures that an IID of all zeros can never result. 259 A Destination Address of 255 (0xFF) denotes a link-level broadcast 260 (all nodes). A Source Address of 255 MUST NOT be used. MS/TP does 261 not support multicast, therefore all IPv6 multicast packets MUST be 262 sent as link-level broadcasts and filtered at the IPv6 layer. 264 This document assumes that each MS/TP link maps onto a unique IPv6 265 subnet prefix. Hosts learn IPv6 prefixes via router advertisements 266 according to [RFC4861]. 268 4. Maximum Transmission Unit (MTU) 270 The BACnet [Addendum_an] change proposal specifies that the MSDU be 271 increased to 1501 octets and covered by a 32-bit CRC. This is 272 sufficient to convey an MTU of at least 1280 octets as required by 273 IPv6 without the need for link-layer fragmentation and reassembly. 275 However, the relatively low data rates of MS/TP still make a 276 compelling case for header compression. An adaptation layer to 277 indicate compressed or uncompressed IPv6 headers is specified below 278 in Section 5 and the compression scheme is specified in Section 10. 280 5. LoBAC Adaptation Layer 282 The encapsulation formats defined in this section (subsequently 283 referred to as the "LoBAC" encapsulation) comprise the payload (MSDU) 284 of an MS/TP frame. The LoBAC payload (i.e., an IPv6 packet) follows 285 an encapsulation header stack. LoBAC is a subset of the LoWPAN 286 encapsulation defined in [RFC4944], therefore the use of "LOWPAN" in 287 literals below is intentional. The primary differences between LoBAC 288 and LoWPAN are: a) exclusion of the Fragmentation, Mesh, and 289 Broadcast headers, and b) use of LOWPAN_IPHC [RFC6282] in place of 290 LOWPAN_HC1 header compression (which is deprecated by [RFC6282]). 292 All LoBAC encapsulated datagrams transmitted over MS/TP are prefixed 293 by an encapsulation header stack. Each header in the stack consists 294 of a header type followed by zero or more header fields. Whereas in 295 an IPv6 header the stack would contain, in the following order, 296 addressing, hop-by-hop options, routing, fragmentation, destination 297 options, and finally payload [RFC2460]; in a LoBAC encapsulation the 298 analogous sequence is (optional) header compression and payload. The 299 header stacks that are valid in a LoBAC network are shown below. 301 A LoBAC encapsulated IPv6 datagram: 303 +---------------+-------------+---------+ 304 | IPv6 Dispatch | IPv6 Header | Payload | 305 +---------------+-------------+---------+ 307 A LoBAC encapsulated LOWPAN_IPHC compressed IPv6 datagram: 309 +---------------+-------------+---------+ 310 | IPHC Dispatch | IPHC Header | Payload | 311 +---------------+-------------+---------+ 313 All protocol datagrams (i.e., IPv6 or compressed IPv6 headers) SHALL 314 be preceded by one of the valid LoBAC encapsulation headers. This 315 permits uniform software treatment of datagrams without regard to 316 their mode of transmission. 318 The definition of LoBAC headers consists of the dispatch value, the 319 definition of the header fields that follow, and their ordering 320 constraints relative to all other headers. Although the header stack 321 structure provides a mechanism to address future demands on the LoBAC 322 (LoWPAN) adaptation layer, it is not intended to provided general 323 purpose extensibility. This format document specifies a small set of 324 header types using the header stack for clarity, compactness, and 325 orthogonality. 327 5.1. Dispatch Value and Header 329 The LoBAC Dispatch value begins with a "0" bit followed by a "1" bit. 330 The Dispatch value and header are shown here: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |0|1| Dispatch | Type-specific header 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Dispatch 6-bit selector. Identifies the type of header 339 immediately following the Dispatch value. 341 Type-specific header A header determined by the Dispatch value. 343 Figure 2: Dispatch Value and Header 345 The Dispatch value may be treated as an unstructured namespace. Only 346 a few symbols are required to represent current LoBAC functionality. 347 Although some additional savings could be achieved by encoding 348 additional functionality into the dispatch value, these measures 349 would tend to constrain the ability to address future alternatives. 351 Pattern Header Type 352 +------------+-----------------------------------------------------+ 353 | 00 xxxxxx | NALP - Not a LoWPAN (LoBAC) frame | 354 | 01 000000 | ESC - Additional Dispatch octet follows | 355 | 01 000001 | IPv6 - Uncompressed IPv6 Addresses | 356 | ... | reserved - Defined or reserved by [RFC4944] | 357 | 01 1xxxxx | LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] | 358 | 1x xxxxxx | reserved - Defined or reserved by [RFC4944] | 359 +------------+-----------------------------------------------------+ 361 Figure 3: Dispatch Value Bit Patterns 363 NALP: Specifies that the following bits are not a part of the LoBAC 364 encapsulation, and any LoBAC node that encounters a Dispatch 365 value of 00xxxxxx shall discard the packet. Non-LoBAC protocols 366 that wish to coexist with LoBAC nodes should include an octet 367 matching this pattern immediately following the MS/TP header. 369 ESC: Specifies that the following header is a single 8-bit field for 370 the Dispatch value. It allows support for Dispatch values larger 371 than 127 (see [RFC6282] section 5). 373 IPv6: Specifies that the following header is an uncompressed IPv6 374 header [RFC2460]. 376 LOWPAN_IPHC: A value of 011xxxxx specifies a LOWPAN_IPHC compression 377 header (see Section 10.) 379 Reserved: A LoBAC node that encounters a Dispatch value in the range 380 01000010 through 01011111 or 1xxxxxxx SHALL discard the packet. 382 6. Stateless Address Autoconfiguration 384 This section defines how to obtain an IPv6 Interface Identifier. The 385 general procedure is described in Appendix A of [RFC4291], "Creating 386 Modified EUI-64 Format Interface Identifiers". 388 The Interface Identifier may be based on an [EUI-64] identifier 389 assigned to the device (but this is not typical for MS/TP). In this 390 case, the Interface Identifier is formed from the EUI-64 by inverting 391 the "u" (universal/local) bit according to [RFC4291]. This will 392 result in a globally unique Interface Identifier. 394 If the device does not have an EUI-64, then the Interface Identifier 395 MUST be formed by concatenating its 8-bit MS/TP node address to the 396 seven octets 0x00, 0x00, 0x00, 0xFF, 0xFE, 0x00, 0x00. For example, 397 an MS/TP node address of hexadecimal value 0x4F results in the 398 following Interface Identifier: 400 |0 1|1 3|3 4|4 6| 401 |0 5|6 1|2 7|8 3| 402 +----------------+----------------+----------------+----------------+ 403 |0000000000000000|0000000011111111|1111111000000000|0000000001001111| 404 +----------------+----------------+----------------+----------------+ 406 Note that this results in the universal/local bit set to "0" to 407 indicate local scope. 409 An IPv6 address prefix used for stateless autoconfiguration [RFC4862] 410 of an MS/TP interface MUST have a length of 64 bits. 412 7. IPv6 Link Local Address 414 The IPv6 link-local address [RFC4291] for an MS/TP interface is 415 formed by appending the Interface Identifier, as defined above, to 416 the prefix FE80::/64. 418 10 bits 54 bits 64 bits 419 +----------+-----------------------+----------------------------+ 420 |1111111010| (zeros) | Interface Identifier | 421 +----------+-----------------------+----------------------------+ 423 8. Unicast Address Mapping 425 The address resolution procedure for mapping IPv6 non-multicast 426 addresses into MS/TP link-layer addresses follows the general 427 description in Section 7.2 of [RFC4861], unless otherwise specified. 429 The Source/Target Link-layer Address option has the following form 430 when the addresses are 8-bit MS/TP node (link-layer) addresses. 432 0 1 433 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type | Length=1 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | 0x00 | MS/TP Address | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 +- Padding -+ 441 | (all zeros) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Option fields: 446 Type: 448 1: for Source Link-layer address. 450 2: for Target Link-layer address. 452 Length: This is the length of this option (including the type and 453 length fields) in units of 8 octets. The value of this field is 1 454 for 8-bit MS/TP node addresses. 456 MS/TP Address: The 8-bit address in canonical bit order [RFC2469]. 457 This is the unicast address the interface currently responds to. 459 9. Multicast Address Mapping 461 All IPv6 multicast packets MUST be sent to MS/TP Destination Address 462 255 (broadcast) and filtered at the IPv6 layer. When represented as 463 a 16-bit address in a compressed header (see Section 10), it MUST be 464 formed by padding on the left with a zero: 466 0 1 467 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | 0x00 | 0xFF | 470 +-+-+-+-+-+-+-+-+---------------+ 472 10. Header Compression 474 LoBAC uses LOWPAN_IPHC IPv6 compression, which is specified in 475 [RFC6282] and included herein by reference. This section will simply 476 identify substitutions that should be made when interpreting the text 477 of [RFC6282]. 479 In general the following substitutions should be made: 481 * Replace "6LoWPAN" with "MS/TP network" 483 * Replace "IEEE 802.15.4 address" with "MS/TP address" 485 When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 486 address") it MUST be formed by padding the MS/TP address to the left 487 with a zero: 489 0 1 490 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | 0x00 | MS/TP address | 493 +-+-+-+-+-+-+-+-+---------------+ 495 11. IANA Considerations 497 This document uses values previously reserved by [RFC4944] and 498 [RFC6282] and makes no further requests of IANA. 500 Note to RFC Editor: this section may be removed upon publication. 502 12. Security Considerations 504 The method of deriving Interface Identifiers from MAC addresses is 505 intended to preserve global uniqueness when possible. However, there 506 is no protection from duplication through accident or forgery. 508 13. Acknowledgments 510 We are grateful to the authors of [RFC4944] and members of the IETF 511 6LoWPAN working group; this document borrows extensively from their 512 work. 514 14. References 516 14.1. Normative References 518 [BACnet] American Society of Heating, Refrigerating, and Air- 519 Conditioning Engineers, "BACnet, A Data Communication 520 Protocol for Building Automation and Control Networks 521 (ANSI Approved)", ANSI/ASHRAE 135-2010, April 2011. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 527 (IPv6) Specification", RFC 2460, December 1998. 529 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 530 Architecture", RFC 4291, February 2006. 532 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 533 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 534 September 2007. 536 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 537 Address Autoconfiguration", RFC 4862, September 2007. 539 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 540 "Transmission of IPv6 Packets over IEEE 802.15.4 541 Networks", RFC 4944, September 2007. 543 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 544 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 545 September 2011. 547 14.2. Informative References 549 [Addendum_an] 550 ASHRAE, "BSR/ASHRAE Addendum an to ANSI/ASHRAE Standard 551 135-2010, BACnet - A Data Communication Protocol for 552 Building Automation and Control Networks (Advisory Public 553 Review Draft)", September 2011, 554 . 556 [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte 557 Stuffing", IEEE/ACM TRANSACTIONS ON NETWORKING, VOL.7, 558 NO.2 , April 1999, 559 . 561 [CRC32K] Koopman, P., "32-Bit Cyclic Redundancy Codes for Internet 562 Applications", IEEE/IFIP International Conference on 563 Dependable Systems and Networks (DSN 2002) , June 2002, . 567 [EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 568 Registration Authority", March 1997, . 571 [RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical 572 Ordering Of Link-Layer Addresses", RFC 2469, 573 December 1998. 575 [TIA-485-A] 576 Telecommunications Industry Association, "TIA-485-A, 577 Electrical Characteristics of Generators and Receivers for 578 Use in Balanced Digital Multipoint Systems (ANSI/TIA/ 579 EIA-485-A-98) (R2003)", March 2003. 581 Appendix A. Extended Data CRC [CRC32K] 583 This Appendix is informative and not part of the standard. 585 Extending the payload of MS/TP to 1501 octets requires upgrading the 586 Data CRC from 16 bits to 32 bits. Koopman has published several 587 papers on choosing the right CRC polynomial for the application. In 588 [CRC32K], he surveyed the entire 32-bit polynomial space and 589 identified some that exceed the 802.3 polynomial in performance. 591 The BACnet MS/TP change proposal [Addendum_an] specifies the CRC32K 592 (Koopman) polynomial. An example C implementation is shown below. 593 The specified use of the function is that 'crcValue' is initialized 594 to all ones before the function is first called and, upon running the 595 function over all octets in the payload, the ones complement of 596 'crcValue' be sent in LSB-first order. Upon reception, the data 597 field and modified 'crcValue' are passed again through the function. 598 If these fields were properly received, the result of the function 599 will be 'CRC32K_RESIDUE'. 601 #include 603 /* See ASHRAE 135-2010 Addendum an, section G.3.2 */ 604 #define CRC32K_INITIAL_VALUE (0xFFFFFFFF) 605 #define CRC32K_RESIDUE (0x0843323B) 606 /* CRC-32K polynomial, 1 + x**1 + ... + x**30 (+ x**32) */ 607 #define CRC32K_POLY (0xEB31D82E) 609 /* 610 * Accumulate 'dataValue' into the CRC in 'crcValue'. 611 * Return updated CRC. 612 * 613 * Note: crcValue must be set to CRC32K_INITIAL_VALUE 614 * before initial call. 615 */ 616 uint32_t 617 CalcExtendedDataCRC(uint8_t dataValue, uint32_t crcValue) 618 { 619 uint8_t data, b; 620 uint32_t crc; 622 data = dataValue; 623 crc = crcValue; 625 for (b = 0; b < 8; b++) { 626 if ((data & 1) ^ (crc & 1)) { 627 crc >>= 1; 628 crc ^= CRC32K_POLY; 629 } else { 630 crc >>= 1; 631 } 632 data >>= 1; 633 } 634 return crc; 635 } 637 Appendix B. Consistent Overhead Byte Stuffing [COBS] 639 This Appendix is informative and not part of the standard. 641 The BACnet change proposal [Addendum_an] corrects a long-standing 642 issue with the MS/TP specification; namely that preamble sequences 643 were not escaped whenever they appeared in the Data or Data CRC 644 fields. In some cases, this could result in dropped frames due to 645 mis-alignment. The solution is encode the Data and Extended Data CRC 646 fields before transmission using Consistent Overhead Byte Stuffing 647 [COBS] and decode these fields upon reception. 649 COBS is a run-length encoding method that effectively removes '0x00' 650 octets from its input. The worst-case overhead is bounded at approx. 651 one octet in 254, or less than 0.5%, as described in [COBS]. An 652 aribtrary octet value may be removed by XOR'ing the COBS output with 653 the specified value. In the case of MS/TP, the '0x55' preamble octet 654 is specified for removal. 656 Encoding proceeds logically in three passes. First, the Extended 657 Data CRC is calculated over the data, modified for transmission as 658 described in Appendix A, and appended to the data. The combined 659 fields are then passed through the COBS encoder. The resulting 660 output is then XOR'd with the MS/TP preamble octet '0x55'. The 661 length of the encoded fields, minus two octets for compatibility with 662 existing MS/TP devices, is placed in the MS/TP header Length field 663 before transmission. 665 An example C implementation that combines these passes is shown 666 below. The decode() function is the inverse of the encode() 667 function. 669 #include 671 #define MSTP_PREAMBLE_55 (0x55) 673 /* 674 * Encodes 'length' octets of data at the location pointed to by 'input' 675 * and writes the output to the location pointed to by 'output'. 676 * Returns the number of octets written to 'output'. 677 */ 678 size_t 679 frame_encode (uint8_t *output, const uint8_t *input, size_t length) 680 { 681 size_t code_index = 0; 682 size_t read_index = 0; 683 size_t write_index = 1; 684 uint8_t code = 1; 685 uint8_t data; 686 int i; 688 uint32_t crc32K = CRC32K_INITIAL_VALUE; 690 while (read_index < length) { 691 data = input[read_index++]; 692 crc32K = CalcExtendedDataCRC(data, crc32K); 693 /* 694 * In the common case, simply copy input to output and 695 * increment the number of octets copied. 696 */ 697 if (data != 0) { 698 output[write_index++] = (data ^ MSTP_PREAMBLE_55); 699 code++; 700 if (code != 0xFF) 701 continue; 702 } 703 /* 704 * In the special case of encountering a zero in the input or 705 * having copied the maximum number (254) of non-zero octets, 706 * store the count and re-initialize encoder variables. 707 */ 708 output[code_index] = (code ^ MSTP_PREAMBLE_55); 709 code_index = write_index++; 710 code = 1; 711 } 712 /* 713 * Run the one's complement of the CRC value through the encoder, 714 * LSB first. 715 */ 716 crc32K = ~crc32K; 717 for (i = 0; i < 4; i++) { 718 data = ((uint8_t *) &crc32K)[i]; 720 if (data != 0) { 721 output[write_index++] = (data ^ MSTP_PREAMBLE_55); 722 code++; 723 if (code != 0xFF) 724 continue; 725 } 726 /* 727 * In the special case of encountering a zero in the input or 728 * having copied the maximum number (254) of non-zero octets, 729 * store the count and re-initialize encoder variables. 730 */ 731 output[code_index] = (code ^ MSTP_PREAMBLE_55); 732 code_index = write_index++; 733 last_code = code; 734 code = 1; 735 } 736 /* Append a "phantom zero" to the output stream. */ 737 output[code_index] = (code ^ MSTP_PREAMBLE_55); 738 /* 739 * Return the combined value of the Data and Extended CRC fields. 740 * Subtract two before use as the MS/TP frame Length field. 741 */ 742 return write_index; 743 } 744 /* 745 * Takes COBS encoded Data and Extended Data CRC fields as 'input'. 746 * The 'length' contains the actual length of these fields in 747 * octets (that is, the header Length field plus two). 748 * Decodes the Data and Extended Data CRC fields into 'output'. 749 * Returns length of decoded Data in octets. 750 * Note: Safe to call with 'output' <= 'input'. 751 */ 752 size_t 753 frame_decode (uint8_t *output, const uint8_t *input, size_t length) 754 { 755 uint16_t read_index = 0; 756 uint16_t write_index = 0; 757 uint8_t code, data; 758 int i; 760 crc32 = CRC32K_INITIAL_VALUE; 761 while (read_index < length) { 762 code = (input[read_index] ^ MSTP_PREAMBLE_55); 763 /* 764 * Sanity check the encoding to prevent the for() loop below 765 * from overrunning the output buffer. 766 */ 767 if ((read_index + code) > length) 768 return 0; 770 read_index++; 772 for (i = 1; i < code; i++) { 773 data = (input[read_index++] ^ MSTP_PREAMBLE_55); 774 crc32 = CalcExtendedDataCRC(data, crc32); 775 output[write_index++] = data; 776 } 777 if ((code < 0xFF) && (read_index < length)) { 778 data = '\0'; 779 crc32 = CalcExtendedDataCRC(data, crc32); 780 output[write_index++] = data; 781 } 782 } 783 if (crc32K == CRC32K_RESIDUE) 784 return write_index - sizeof(uint32_t); 785 else 786 return 0; 787 } 789 Authors' Addresses 791 Kerry Lynn (editor) 792 Consultant 794 Phone: +1 978 460 4253 795 Email: kerlyn@ieee.org 797 Jerry Martocci 798 Johnson Controls, Inc. 799 507 E. Michigan St 800 Milwaukee, WI 53202 801 USA 803 Phone: +1 414 524 4010 804 Email: jerald.p.martocci@jci.com 806 Carl Neilson 807 Delta Controls, Inc. 808 17850 56th Ave 809 Surrey, BC V3S 1C7 810 Canada 812 Phone: +1 604 575 5913 813 Email: cneilson@deltacontrols.com 815 Stuart Donaldson 816 Honeywell Automation & Control Solutions 817 6670 185th Ave NE 818 Redmond, WA 98052 819 USA 821 Email: stuart.donaldson@honeywell.com