< draft-ietf-6lo-6lobac-06.txt   draft-ietf-6lo-6lobac-07.txt >
6Lo Working Group K. Lynn, Ed. 6Lo Working Group K. Lynn, Ed.
Internet-Draft Verizon Labs Internet-Draft Verizon Labs
Intended status: Standards Track J. Martocci Intended status: Standards Track J. Martocci
Expires: May 4, 2017 Johnson Controls Expires: August 31, 2017 Johnson Controls
C. Neilson C. Neilson
Delta Controls Delta Controls
S. Donaldson S. Donaldson
Honeywell Honeywell
October 31, 2016 February 27, 2017
Transmission of IPv6 over MS/TP Networks Transmission of IPv6 over MS/TP Networks
draft-ietf-6lo-6lobac-06 draft-ietf-6lo-6lobac-07
Abstract Abstract
Master-Slave/Token-Passing (MS/TP) is a medium access control method Master-Slave/Token-Passing (MS/TP) is a medium access control method
for the RS-485 physical layer, which is used extensively in building for the RS-485 physical layer and is used primarily in building
automation networks. This specification defines the frame format for automation networks. This specification defines the frame format for
transmission of IPv6 packets and the method of forming link-local and transmission of IPv6 packets and the method of forming link-local and
statelessly autoconfigured IPv6 addresses on MS/TP networks. statelessly autoconfigured IPv6 addresses on MS/TP networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on August 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MS/TP Mode for IPv6 . . . . . . . . . . . . . . . . . . . . . 6 2. Profile for IPv6 over MS/TP . . . . . . . . . . . . . . . . . 5
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 6 3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 6
4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 6 4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 7
5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 7 5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 7
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 8 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 8
7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 8 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 9
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 9 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 10
10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 14 Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 14
Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 16 Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 17
Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 19 Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 20
Appendix D. Example 6LoBAC Packet Decode . . . . . . . . . . . . 22 Appendix D. Example 6LoBAC Packet Decode . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Master-Slave/Token-Passing (MS/TP) is a medium access control (MAC) 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 protocol for the RS-485 [TIA-485-A] physical layer and is used
extensively in building automation networks. This specification primarily in building automation networks. This specification
defines the frame format for transmission of IPv6 [RFC2460] packets defines the frame format for transmission of IPv6 [RFC2460] packets
and the method of forming link-local and statelessly autoconfigured and the method of forming link-local and statelessly autoconfigured
IPv6 addresses on MS/TP networks. The general approach is to adapt IPv6 addresses on MS/TP networks. The general approach is to adapt,
elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and where noted, elements of the 6LoWPAN specifications [RFC4944],
[RFC6775], where noted, to constrained wired networks. [RFC6282], and [RFC6775] to constrained wired networks.
An MS/TP device is typically based on a low-cost microcontroller with An MS/TP device is typically based on a low-cost microcontroller with
limited processing power and memory. Together with low data rates limited processing power and memory. These constraints, together
and a small MAC address space, these constraints are similar to those with low data rates and a small MAC address space, are similar to
faced in 6LoWPAN networks and suggest some elements of that solution those faced in 6LoWPAN networks. MS/TP differs significantly from
might be leveraged. MS/TP differs significantly from 6LoWPAN in at 6LoWPAN in at least three respects: a) MS/TP devices are typically
least three respects: a) MS/TP devices typically have a continuous mains powered, b) all MS/TP devices on a segment can communicate
source of power, b) all MS/TP devices on a segment can communicate
directly so there are no hidden node or mesh routing issues, and c) directly so there are no hidden node or mesh routing issues, and c)
recent changes to MS/TP provide support for larger payloads, the latest MS/TP specification provides support for large payloads,
eliminating the need for fragmentation and reassembly below IPv6. eliminating the need for fragmentation and reassembly below IPv6.
The following sections provide a brief overview of MS/TP, then The following sections provide a brief overview of MS/TP, then
describe how to form IPv6 addresses and encapsulate IPv6 packets in describe how to form IPv6 addresses and encapsulate IPv6 packets in
MS/TP frames. This document also specifies a header compression MS/TP frames. The encapsulation (subsequently referred to as
mechanism, based on [RFC6282], that is REQUIRED in order to reduce "LoBAC") supports a REQUIRED header compression mechanism that is
latency and make IPv6 practical on MS/TP networks. based on LOWPAN_IPHC [RFC6282] and improves MS/TP link utilization.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Abbreviations Used 1.2. Abbreviations Used
ASHRAE: American Society of Heating, Refrigerating, and Air- ASHRAE: American Society of Heating, Refrigerating, and Air-
Conditioning Engineers (http://www.ashrae.org) Conditioning Engineers (http://www.ashrae.org)
BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol
for Building Automation and Control Networks for Building Automation and Control Networks
CRC: Cyclic Redundancy Check CRC: Cyclic Redundancy Code
MAC: Medium Access Control MAC: Medium Access Control
MSDU: MAC Service Data Unit (MAC client data) MSDU: MAC Service Data Unit (MAC client data)
MTU: Maximum Transmission Unit 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 UART: Universal Asynchronous Transmitter/Receiver
1.3. MS/TP Overview 1.3. MS/TP Overview
This section provides a brief overview of MS/TP, which is specified This section provides a brief overview of MS/TP, as specified in
in ANSI/ASHRAE 135-2012 (BACnet) Clause 9 [Clause9] and included ANSI/ASHRAE Std 135-2016 [BACnet] Clause 9. This version of [BACnet]
herein by reference. BACnet [Clause9] also covers physical layer Clause 9 incorporates changes to legacy MS/TP, introduced in ANSI/
deployment options. 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.
MS/TP is designed to enable multidrop networks over shielded twisted MS/TP is designed to enable multidrop networks over shielded twisted
pair wiring. It can support network segments up to 1000 meters in 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 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 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, RS-485 [TIA-485-A] transceiver with a driver that can be disabled,
and a 5 ms resolution timer. These features make MS/TP a cost- and a 5 ms resolution timer. The MS/TP MAC is typically implemented
effective field bus for the most numerous and least expensive devices in software.
in a building automation network.
The differential signaling used by [TIA-485-A] requires a contention- 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. 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 A master node may only initiate the transmission of a data frame when
holds the token. After sending at most a configured maximum number it holds the token. After sending at most a configured maximum
of data frames, a master node passes the token to the next master number of data frames, a master node passes the token to the next
node (as determined by MAC address). If present on the link, legacy master node (as determined by MAC address). If present on the link,
MS/TP implementations (including all slave nodes) ignore the frame legacy MS/TP implementations (including any slave nodes) ignore the
format defined in this specification. frame format defined in this specification.
BACnet Addendum 135-2012an [Addendum_an] defines a range of Frame [BACnet] Clause 9 defines a range of Frame Type values used to
Type values to designate frames that contain larger data and data CRC designate frames that contain data and data CRC fields encoded using
fields, encoded using Consistent Overhead Byte Stuffing [COBS] (see Consistent Overhead Byte Stuffing [COBS] (see Appendix B). The
Appendix B). The purpose of COBS encoding is to eliminate preamble purpose of COBS encoding is to eliminate preamble sequences from the
sequences from the Encoded Data and Encoded CRC-32K fields. The Encoded Data and Encoded CRC-32K fields. The Encoded Data is covered
maximum length of an MSDU as defined by this specification is 1500 by a 32-bit CRC [CRC32K] (see Appendix C) which is also COBS encoded.
octets (before encoding). The Encoded Data is covered by a 32-bit
CRC [CRC32K] (see Appendix C). The CRC-32K is then COBS encoded.
MS/TP COBS-encoded frames have the following format: MS/TP COBS-encoded frames have the following format:
0 1 2 3 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 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 | | 0x55 | 0xFF | Frame Type | DA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA | Length (MS octet first) | Header CRC | | SA | Length (MS octet first) | Header CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 43 skipping to change at page 4, line 41
. Encoded Data (2 - 1506 octets) . . Encoded Data (2 - 1506 octets) .
. . . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Encoded CRC-32K (5 octets) | | | Encoded CRC-32K (5 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | optional 0xFF | | | optional 0xFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MS/TP COBS-Encoded Frame Format Figure 1: MS/TP COBS-Encoded Frame Format
MS/TP COBS-encoded frame fields have the following descriptions: MS/TP COBS-encoded frame fields are defined as follows:
Preamble two octet preamble: 0x55, 0xFF Preamble two octet preamble: 0x55, 0xFF
Frame Type one octet Frame Type one octet
Destination Address one octet address Destination Address one octet address
Source Address one octet address Source Address one octet address
Length two octets, most significant octet first Length two octets, most significant octet first
Header CRC one octet Header CRC one octet
Encoded Data 2 - 1506 octets (see Appendix B) Encoded Data 2 - 1506 octets (see Section 4 and Appendix B)
Encoded CRC-32K five octets (see Appendix C) Encoded CRC-32K five octets (see Appendix C)
(pad) (optional) at most one octet of trailer: 0xFF (pad) (optional) at most one octet of trailer: 0xFF
The Frame Type is used to distinguish between different types of MAC The Frame Type is used to distinguish between different types of MAC
frames. The types relevant to this specification (in decimal) are: frames. The types relevant to this specification (in decimal) are:
0 Token 0 Token
1 Poll For Master 1 Poll For Master
2 Reply To Poll For Master 2 Reply To Poll For Master
... ...
34 IPv6 over MS/TP (LoBAC) Encapsulation 34 IPv6 over MS/TP (LoBAC) Encapsulation
Frame Types 8 - 31 and 35 - 127 are reserved for assignment by Frame Types 8 - 31 and 35 - 127 are reserved for assignment by
ASHRAE. Frame Types 32 - 127 designate COBS-encoded frames and MUST ASHRAE. Frame Types 32 - 127 designate COBS-encoded frames that
convey Encoded Data and Encoded CRC-32K fields. All master nodes convey Encoded Data and Encoded CRC-32K fields. All master nodes
MUST understand Token, Poll For Master, and Reply to Poll For Master must understand Token, Poll For Master, and Reply to Poll For Master
control frames. See Section 2 for additional details. control frames. See Section 2 for additional details.
The Destination and Source Addresses are each one octet in length. The Destination and Source Addresses are each one octet in length.
See Section 3 for additional details. See Section 3 for additional details.
For COBS-encoded frames, the Length field indicates the size of the For COBS-encoded frames, the Length field indicates the size of the
[COBS] Encoded Data field in octets, plus three. (This adjustment is [COBS] Encoded Data field in octets, plus three. (This adjustment is
required in order for legacy MS/TP devices to ignore COBS-encoded required in order for legacy MS/TP devices to ignore COBS-encoded
frames.) See Section 4 and Appendices for additional details. frames.) See Section 4 and Appendices for additional details.
The Header CRC field covers the Frame Type, Destination Address, The Header CRC field covers the Frame Type, Destination Address,
Source Address, and Length fields. The Header CRC generation and Source Address, and Length fields. The Header CRC generation and
check procedures are specified in BACnet [Clause9]. check procedures are specified in [BACnet] Annex G.1.
Use of the optional 0xFF trailer octet is discussed in BACnet Use of the optional 0xFF trailer octet is discussed in [BACnet]
[Clause9]. Clause 9.
1.4. Goals and Constraints 1.4. Goals and Constraints
The primary goal of this specification is to enable IPv6 directly on The main goals of this specification are to a) enable IPv6 directly
wired end devices in building automation and control networks by on wired end devices in building automation and control networks by
leveraging existing standards to the greatest extent possible. A leveraging existing standards to the greatest extent possible, and b)
secondary goal is to co-exist with legacy MS/TP implementations. co-exist with legacy MS/TP implementations. Co-existence allows MS/
Only the minimum changes necessary to support IPv6 over MS/TP were TP networks to be incrementally upgraded to support IPv6.
specified in BACnet [Addendum_an] (see Section 1.3).
In order to co-exist with legacy devices, no changes are permitted to In order to co-exist with legacy devices, no changes are permitted to
the MS/TP addressing modes, frame header format, control frames, or the MS/TP addressing modes, frame header format, control frames, or
Master Node state machine as specified in BACnet [Clause9]. Master Node state machine as specified in [BACnet] Clause 9.
2. MS/TP Mode for IPv6 2. Profile for IPv6 over MS/TP
ASHRAE has assigned an MS/TP Frame Type value of 34 to indicate IPv6 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 over MS/TP (LoBAC) Encapsulation. This falls within the range of
values that designate COBS-encoded data frames. values that designate COBS-encoded data frames.
All MS/TP master nodes (including those that support IPv6) MUST 2.1. Mandatory Features
implement the Master Node state machine specified in BACnet [Clause9]
and handle Token, Poll For Master, and Reply to Poll For Master
control frames. MS/TP master nodes that support IPv6 MUST also
implement the Receive Frame state machine specified in [Clause9] as
extended by BACnet [Addendum_an].
All MS/TP nodes that support IPv6 MUST support a data rate of 115,200 Nodes that support IPv6 over MS/TP must implement the Master Node
bit/s and MAY optionally support lower data rates as defined in state machine as specified in [BACnet] Clause 9 and handle Token,
BACnet [Clause9]. 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.
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.
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
Nmax_COBS_length The maximum valid length 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
The mechanisms for setting parameters or monitoring MS/TP performance
are outside the scope of this specification.
3. Addressing Modes 3. Addressing Modes
MS/TP node (MAC) addresses are one octet in length. The method of MS/TP node (MAC) addresses are one octet in length and assigned
assigning MAC addresses is outside the scope of this specification. dynamically. The method of assigning MAC addresses is outside the
However, each MS/TP node on the link MUST have a unique address in scope of this specification. However, each MS/TP node on the link
order to ensure correct MAC operation. MUST have a unique address in order to ensure correct MAC operation.
BACnet [Clause9] specifies that addresses 0 through 127 are valid for [BACnet] Clause 9 specifies that addresses 0 through 127 are valid
master nodes. The method specified in Section 6 for creating a MAC- for master nodes. The method specified in Section 6 for creating a
layer-derived Interface Identifier (IID) ensures that an IID of all MAC-address-derived Interface Identifier (IID) ensures that an IID of
zeros can never result. all zeros can never be generated.
A Destination Address of 255 (all nodes) indicates a MAC-layer A Destination Address of 255 (all nodes) indicates a MAC-layer
broadcast. MS/TP does not support multicast, therefore all IPv6 broadcast. MS/TP does not support multicast, therefore all IPv6
multicast packets MUST be broadcast at the MAC layer and filtered at multicast packets MUST be broadcast at the MAC layer and filtered at
the IPv6 layer. A Source Address of 255 MUST NOT be used. the IPv6 layer. A Source Address of 255 MUST NOT be used.
Hosts learn IPv6 prefixes via router advertisements according to Hosts learn IPv6 prefixes via router advertisements according to
[RFC4861]. [RFC4861].
4. Maximum Transmission Unit (MTU) 4. Maximum Transmission Unit (MTU)
BACnet [Addendum_an] supports MSDUs up to 2032 octets in length. Upon transmission, the network layer MTU is formatted according to
This specification defines an MSDU length of at least 1280 octets and Section 5 and becomes the MAC service data unit (MSDU). The MSDU is
at most 1500 octets (before encoding). This is sufficient to convey then COBS encoded by MS/TP. Upon reception, the steps are reversed.
the minimum MTU required by IPv6 [RFC2460] without the need for link- [BACnet] Clause 9 supports MSDUs up to 2032 octets in length.
layer fragmentation and reassembly. Support for an MSDU length of
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 is RECOMMENDED. 1500 octets is RECOMMENDED.
5. LoBAC Adaptation Layer 5. LoBAC Adaptation Layer
The relatively low data rates of MS/TP dictate header compression as This section specifies an adaptation layer to support compressed IPv6
a means to reduce latency. This section specifies an adaptation headers as specified in Section 10. IPv6 header compression MUST be
layer to support compressed IPv6 headers as specified in Section 10. implemented on all nodes. Implementations MAY also support Generic
IPv6 header compression MUST be implemented on all nodes. Header Compression [RFC7400] for transport layer headers.
Implementations MAY also support Generic Header Compression (GHC)
[RFC7400] for transport layer headers. A node implementing [RFC7400]
MUST probe its peers for GHC support before applying GHC.
The encapsulation format defined in this section (subsequently The LoBAC encapsulation format defined in this section describes the
referred to as the "LoBAC" encapsulation) comprises the MSDU of an MSDU of an IPv6 over MS/TP frame. The LoBAC payload (i.e., an IPv6
IPv6 over MS/TP frame. The LoBAC payload (i.e., an IPv6 packet) packet) follows an encapsulation header stack. LoBAC is a subset of
follows an encapsulation header stack. LoBAC is a subset of the the LoWPAN encapsulation defined in [RFC4944] as updated by
LoWPAN encapsulation defined in [RFC4944] and extended by [RFC6282], [RFC6282], therefore the use of "LOWPAN" in literals below is
therefore the use of "LOWPAN" in literals below is intentional. The intentional. The primary difference between LoWPAN and LoBAC is
primary difference between LoWPAN and LoBAC is omission of the Mesh, omission of the Mesh, Broadcast, Fragmentation, and LOWPAN_HC1
Broadcast, Fragmentation, and LOWPAN_HC1 headers. headers.
All LoBAC encapsulated datagrams transmitted over MS/TP are prefixed All LoBAC encapsulated datagrams transmitted over MS/TP are prefixed
by an encapsulation header stack consisting of a Dispatch value by an encapsulation header stack consisting of a Dispatch value
followed by zero or more header fields. The only sequence currently followed by zero or more header fields. The only sequence currently
defined for LoBAC is the LOWPAN_IPHC header followed by payload, as defined for LoBAC is the LOWPAN_IPHC header followed by payload, as
shown below: shown below:
+---------------+---------------+------...-----+ +---------------+---------------+------...-----+
| IPHC Dispatch | IPHC Header | Payload | | IPHC Dispatch | IPHC Header | Payload |
+---------------+---------------+------...-----+ +---------------+---------------+------...-----+
Figure 2: A LoBAC Encapsulated LOWPAN_IPHC Compressed IPv6 Datagram Figure 2: A LoBAC Encapsulated LOWPAN_IPHC Compressed IPv6 Datagram
The Dispatch value may be treated as an unstructured namespace. Only The Dispatch value is treated as an unstructured namespace. Only a
a single pattern is used to represent current LoBAC functionality. single pattern is used to represent current LoBAC functionality.
Pattern Header Type Pattern Header Type
+------------+-----------------------------------------------------+ +------------+-----------------------------------------------------+
| 01 1xxxxx | LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] | | 01 1xxxxx | LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] |
+------------+-----------------------------------------------------+ +------------+-----------------------------------------------------+
Figure 3: LoBAC Dispatch Value Bit Pattern Figure 3: LoBAC Dispatch Value Bit Pattern
Other IANA-assigned 6LoWPAN Dispatch values do not apply to 6LoBAC Other IANA-assigned 6LoWPAN Dispatch values do not apply to 6LoBAC
unless otherwise specified. unless otherwise specified.
6. Stateless Address Autoconfiguration 6. Stateless Address Autoconfiguration
This section defines how to obtain an IPv6 Interface Identifier. The This section defines how to obtain an IPv6 Interface Identifier.
general procedure for creating a MAC-address-derived IID is described This specification distinguishes between two types of IID, MAC-
in [RFC4291] Appendix A, "Creating Modified EUI-64 Format Interface address-derived and semantically opaque.
Identifiers", as updated by [RFC7136].
The IID SHOULD NOT embed an [EUI-64] or any other globally unique A MAC-address-derived IID is the RECOMMENDED type for use in forming
hardware identifier assigned to a device (see Section 12). a link-local address, as it affords the most efficient header
compression provided by the LOWPAN_IPHC [RFC6282] format specified in
Section 10. 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 Interface Identifier for link-local addresses SHOULD be formed by The Interface Identifier for link-local addresses SHOULD be formed by
concatenating a node's' 8-bit MS/TP MAC address to the seven octets 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 0x00, 0x00, 0x00, 0xFF, 0xFE, 0x00, 0x00. For example, an MS/TP MAC
address of hexadecimal value 0x4F results in the following IID: address of hexadecimal value 0x4F results in the following IID:
|0 1|1 3|3 4|4 6| |0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3| |0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
|0000000000000000|0000000011111111|1111111000000000|0000000001001111| |0000000000000000|0000000011111111|1111111000000000|0000000001001111|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
This is the RECOMMENDED method of forming an IID for use in link- A semantically opaque IID having 64 bits of entropy is strongly
local addresses, as it affords the most efficient header compression RECOMMENDED for each routable address and MAY be locally generated
provided by the LOWPAN_IPHC [RFC6282] format specified in Section 10. 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
A 64-bit random IID is RECOMMENDED for each globally scoped address its local router(s) by sending a Neighbor Solicitation (NS) message
and SHOULD be locally generated according to one of the methods cited with the Address Registration Option (ARO) and process Neighbor
in Section 12. A node that generates a 64-bit random IID MUST Advertisements (NA) according to [RFC6775].
register it 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] An IPv6 address prefix used for stateless autoconfiguration [RFC4862]
of an MS/TP interface MUST have a length of 64 bits. of an MS/TP interface MUST have a length of 64 bits.
7. IPv6 Link Local Address 7. IPv6 Link Local Address
The IPv6 link-local address [RFC4291] for an MS/TP interface is The IPv6 link-local address [RFC4291] for an MS/TP interface is
formed by appending the Interface Identifier, as defined above, to formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64. the prefix FE80::/64.
skipping to change at page 9, line 46 skipping to change at page 10, line 10
for 8-bit MS/TP MAC addresses. for 8-bit MS/TP MAC addresses.
MS/TP Address: The 8-bit address in canonical bit order [RFC2469]. MS/TP Address: The 8-bit address in canonical bit order [RFC2469].
This is the unicast address the interface currently responds to. This is the unicast address the interface currently responds to.
9. Multicast Address Mapping 9. Multicast Address Mapping
All IPv6 multicast packets MUST be sent to MS/TP Destination Address All IPv6 multicast packets MUST be sent to MS/TP Destination Address
255 (broadcast) and filtered at the IPv6 layer. When represented as 255 (broadcast) and filtered at the IPv6 layer. When represented as
a 16-bit address in a compressed header (see Section 10), it MUST be a 16-bit address in a compressed header (see Section 10), it MUST be
formed by padding on the left with a zero: formed by padding on the left with a zero octet:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0xFF | | 0x00 | 0xFF |
+-+-+-+-+-+-+-+-+---------------+ +-+-+-+-+-+-+-+-+---------------+
10. Header Compression 10. Header Compression
LoBAC uses LOWPAN_IPHC IPv6 compression, which is specified in LoBAC uses LOWPAN_IPHC IPv6 compression, which is specified in
skipping to change at page 10, line 20 skipping to change at page 10, line 33
of [RFC6282]. of [RFC6282].
In general the following substitutions should be made: In general the following substitutions should be made:
- Replace instances of "6LoWPAN" with "MS/TP network" - Replace instances of "6LoWPAN" with "MS/TP network"
- Replace instances of "IEEE 802.15.4 address" with "MS/TP address" - Replace instances of "IEEE 802.15.4 address" with "MS/TP address"
When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short
address") it MUST be formed by padding the MS/TP address to the left address") it MUST be formed by padding the MS/TP address to the left
with a zero: with a zero octet:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | MS/TP address | | 0x00 | MS/TP address |
+-+-+-+-+-+-+-+-+---------------+ +-+-+-+-+-+-+-+-+---------------+
If LOWPAN_IPHC compression [RFC6282] is used with context, the If LOWPAN_IPHC compression [RFC6282] is used with context, the
router(s) directly attached to the MS/TP segment MUST disseminate the router(s) directly attached to the MS/TP segment MUST disseminate the
6LoWPAN Context Option (6CO) according to [RFC6775], Section 7.2. 6LoWPAN Context Option (6CO) according to [RFC6775], Section 7.2.
11. IANA Considerations 11. IANA Considerations
This document uses values previously reserved by [RFC4944] and This document uses values previously reserved by [RFC4944] and
[RFC6282] and makes no further requests of IANA. [RFC6282] and makes no further requests of IANA.
Note to RFC Editor: this section may be removed upon publication. Note to RFC Editor: this section may be removed upon publication.
12. Security Considerations 12. Security Considerations
Globally scoped addresses that contain IIDs generated using MS/TP See [I-D.ietf-6lo-privacy-considerations] for a general discussion of
node addresses may expose a network to address scanning attacks. For privacy threats faced by constrained nodes.
this reason, it is RECOMMENDED that a different (but stable) IID be
[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.
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 generated for each globally scoped address in use according to, for
example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]. example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217].
MS/TP networks are by definition wired and not susceptible to casual
eavesdropping. By the same token, MS/TP nodes are stationary and
correlation of activities or location tracking of individuals is
unlikely. See [I-D.ietf-6lo-privacy-considerations] for a full
discussion of mitigation of the threats posed to constrained nodes.
13. Acknowledgments 13. Acknowledgments
We are grateful to the authors of [RFC4944] and members of the IETF We are grateful to the authors of [RFC4944] and members of the IETF
6LoWPAN working group; this document borrows liberally from their 6LoWPAN working group; this document borrows liberally from their
work. Ralph Droms and Brian Haberman provided indispensable guidance work. Ralph Droms and Brian Haberman provided indispensable guidance
and support from the outset. Peter van der Stok, James Woodyatt, and and support from the outset. Peter van der Stok, James Woodyatt, and
Carsten Bormann provided detailed reviews. Stuart Cheshire invented Carsten Bormann provided detailed reviews. Stuart Cheshire invented
the very clever COBS encoding. Michael Osborne made the critical the very clever COBS encoding. Michael Osborne made the critical
observation that separately encoding the data and CRC32K fields would observation that encoding the data and CRC32K fields separately would
allow the CRC to be calculated on-the-fly. Alexandru Petrescu, Brian allow the CRC to be calculated on-the-fly. Alexandru Petrescu, Brian
Frank, Geoff Mulligan, and Don Sturek offered valuable comments. Frank, Geoff Mulligan, and Don Sturek offered valuable comments.
14. References 14. References
14.1. Normative References 14.1. Normative References
[Addendum_an] [Addendum_an]
ASHRAE, "ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and ASHRAE, "ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and
az to ANSI/ASHRAE Standard 135-2012, BACnet - A Data az to ANSI/ASHRAE Standard 135-2012, BACnet - A Data
Communication Protocol for Building Automation and Control Communication Protocol for Building Automation and Control
Networks", July 2014, Networks", July 2014,
<https://www.ashrae.org/File%20Library/docLib/StdsAddenda/ <https://www.ashrae.org/File%20Library/docLib/StdsAddenda/
07-31-2014_135_2012_an_at_au_av_aw_ax_az_Final.pdf>. 07-31-2014_135_2012_an_at_au_av_aw_ax_az_Final.pdf>.
[Clause9] American Society of Heating, Refrigerating, and Air- [BACnet] American Society of Heating, Refrigerating, and Air-
Conditioning Engineers, "BACnet - A Data Communication Conditioning Engineers, "BACnet - A Data Communication
Protocol for Building Automation and Control Networks", Protocol for Building Automation and Control Networks",
ANSI/ASHRAE 135-2012 (Clause 9), March 2013. ANSI/ASHRAE 135-2016 (Clause 9), January 2016,
<https://www.ashrae.org/resources--publications/bookstore/
standard-135>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
skipping to change at page 13, line 23 skipping to change at page 13, line 44
Stuffing", IEEE/ACM TRANSACTIONS ON NETWORKING, VOL.7, Stuffing", IEEE/ACM TRANSACTIONS ON NETWORKING, VOL.7,
NO.2 , April 1999, NO.2 , April 1999,
<http://www.stuartcheshire.org/papers/COBSforToN.pdf>. <http://www.stuartcheshire.org/papers/COBSforToN.pdf>.
[CRC32K] Koopman, P., "32-Bit Cyclic Redundancy Codes for Internet [CRC32K] Koopman, P., "32-Bit Cyclic Redundancy Codes for Internet
Applications", IEEE/IFIP International Conference on Applications", IEEE/IFIP International Conference on
Dependable Systems and Networks (DSN 2002) , June 2002, Dependable Systems and Networks (DSN 2002) , June 2002,
<http://www.ece.cmu.edu/~koopman/networks/dsn02/ <http://www.ece.cmu.edu/~koopman/networks/dsn02/
dsn02_koopman.pdf>. dsn02_koopman.pdf>.
[EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", March 1997,
<http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html>.
[I-D.ietf-6lo-privacy-considerations] [I-D.ietf-6lo-privacy-considerations]
Thaler, D., "Privacy Considerations for IPv6 Adaptation Thaler, D., "Privacy Considerations for IPv6 Adaptation
Layer Mechanisms", draft-ietf-6lo-privacy- Layer Mechanisms", draft-ietf-6lo-privacy-
considerations-04 (work in progress), October 2016. considerations-04 (work in progress), October 2016.
[IEEE.802.3] [IEEE.802.3]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
3: Carrier Sense Multiple Access with Collision Detection 3: Carrier Sense Multiple Access with Collision Detection
skipping to change at page 14, line 9 skipping to change at page 14, line 29
[TIA-485-A] [TIA-485-A]
Telecommunications Industry Association, "TIA-485-A, Telecommunications Industry Association, "TIA-485-A,
Electrical Characteristics of Generators and Receivers for Electrical Characteristics of Generators and Receivers for
Use in Balanced Digital Multipoint Systems (ANSI/TIA/EIA- 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 Appendix A. Abstract MAC Interface
This Appendix is informative and not part of the standard. This Appendix is informative and not part of the standard.
BACnet [Clause9] provides support for MAC-layer clients through its [BACnet] Clause 9 provides support for MAC-layer clients through its
SendFrame and ReceivedDataNoReply procedures. However, it does not SendFrame and ReceivedDataNoReply procedures. However, it does not
define a network-protocol independent abstract interface for the MAC. define a network-protocol independent abstract interface for the MAC.
This is provided below as an aid to implementation. This is provided below as an aid to implementation.
A.1. MA-DATA.request A.1. MA-DATA.request
A.1.1. Function A.1.1. Function
This primitive defines the transfer of data from a MAC client entity This primitive defines the transfer of data from a MAC client entity
to a single peer entity or multiple peer entities in the case of a to a single peer entity or multiple peer entities in the case of a
skipping to change at page 16, line 24 skipping to change at page 17, line 9
A.2.4. Effect on Receipt A.2.4. Effect on Receipt
The effect of receipt of this primitive by the MAC client is The effect of receipt of this primitive by the MAC client is
unspecified. unspecified.
Appendix B. Consistent Overhead Byte Stuffing [COBS] Appendix B. Consistent Overhead Byte Stuffing [COBS]
This Appendix is informative and not part of the standard. This Appendix is informative and not part of the standard.
BACnet [Addendum_an] corrects a long-standing issue with the MS/TP [BACnet] Clause 9 corrects a long-standing issue with the MS/TP
specification; namely that preamble sequences were not escaped specification; namely that preamble sequences were not escaped
whenever they appeared in the Data or Data CRC fields. In rare whenever they appeared in the Data or Data CRC fields. In rare
cases, this resulted in dropped frames due to loss of frame cases, this resulted in dropped frames due to loss of frame
synchronization. The solution is to encode the Data and 32-bit Data synchronization. The solution is to encode the Data and 32-bit Data
CRC fields before transmission using Consistent Overhead Byte CRC fields before transmission using Consistent Overhead Byte
Stuffing [COBS] and decode these fields upon reception. Stuffing [COBS] and decode these fields upon reception.
COBS is a run-length encoding method that nominally removes '0x00' COBS is a run-length encoding method that nominally removes '0x00'
octets from its input. Any selected octet value may be removed by octets from its input. Any selected octet value may be removed by
XOR'ing that value with each octet of the COBS output. BACnet XOR'ing that value with each octet of the COBS output. [BACnet]
[Addendum_an] specifies the preamble octet '0x55' for removal. Clause 9 specifies the preamble octet '0x55' for removal.
The minimum overhead of COBS is one octet per encoded field. The 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, worst-case overhead in long fields is bounded to one octet per 254 as
or less than 0.4%, as described in [COBS]. described in [COBS].
Frame encoding proceeds logically in two passes. The Encoded Data Frame encoding proceeds logically in two passes. The Encoded Data
field is prepared by passing the MSDU through the COBS encoder and 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 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 Encoded CRC-32K field is then prepared by calculating a CRC-32K over
the Encoded Data field and formatting it for transmission as the Encoded Data field and formatting it for transmission as
described in Appendix C. The combined length of these fields, minus described in Appendix C. The combined length of these fields, minus
two octets for compatibility with existing MS/TP devices, is placed two octets for compatibility with existing MS/TP devices, is placed
in the MS/TP header Length field before transmission. in the MS/TP header Length field before transmission.
Example COBS encoder and decoder functions are shown below for Example COBS encoder and decoder functions are shown below for
illustration. Complete examples of use and test vectors are provided illustration. Complete examples of use and test vectors are provided
in BACnet [Addendum_an]. in [BACnet] Clause 9.
<CODE BEGINS>
#include <stddef.h> #include <stddef.h>
#include <stdint.h> #include <stdint.h>
/* /*
* Encodes 'length' octets of data located at 'from' and * Encodes 'length' octets of data located at 'from' and
* writes one or more COBS code blocks at 'to', removing any * writes one or more COBS code blocks at 'to', removing any
* 'mask' octets that may present be in the encoded data. * 'mask' octets that may present be in the encoded data.
* Returns the length of the encoded data. * Returns the length of the encoded data.
*/ */
skipping to change at page 19, line 45 skipping to change at page 19, line 45
* Restore the implicit zero at the end of each decoded block * Restore the implicit zero at the end of each decoded block
* except when it contains exactly 254 non-zero octets or the * except when it contains exactly 254 non-zero octets or the
* end of data has been reached. * end of data has been reached.
*/ */
if ((last_code != 255) && (read_index < length)) if ((last_code != 255) && (read_index < length))
to[write_index++] = 0; to[write_index++] = 0;
} }
return write_index; return write_index;
} }
<CODE ENDS>
Appendix C. Encoded CRC-32K [CRC32K] Appendix C. Encoded CRC-32K [CRC32K]
This Appendix is informative and not part of the standard. This Appendix is informative and not part of the standard.
Extending the payload of MS/TP to 1500 octets required upgrading the 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 Data CRC from 16 bits to 32 bits. P.Koopman has authored several
papers on evaluating CRC polynomials for network applications. In papers on evaluating CRC polynomials for network applications. In
[CRC32K], he surveyed the entire 32-bit polynomial space and noted [CRC32K], he surveyed the entire 32-bit polynomial space and noted
some that exceed the [IEEE.802.3] polynomial in performance. BACnet some that exceed the [IEEE.802.3] polynomial in performance.
[Addendum_an] specifies the CRC-32K (Koopman) polynomial. [BACnet] Clause 9 specifies one of these, the CRC-32K (Koopman)
polynomial.
The specified use of the calc_crc32K() function is as follows. The specified use of the calc_crc32K() function is as follows.
Before a frame is transmitted, 'crc_value' is initialized to all Before a frame is transmitted, 'crc_value' is initialized to all
ones. After passing each octet of the [COBS] Encoded Data through ones. After passing each octet of the [COBS] Encoded Data through
the function, the ones complement of the resulting 'crc_value' is the function, the ones complement of the resulting 'crc_value' is
arranged in LSB-first order and is itself [COBS] encoded. The length arranged in LSB-first order and is itself [COBS] encoded. The length
of the resulting Encoded CRC-32K field is always five octets. of the resulting Encoded CRC-32K field is always five octets.
Upon reception of a frame, 'crc_value' is initialized to all ones. Upon reception of a frame, 'crc_value' is initialized to all ones.
The octets of the Encoded Data field are accumulated by the The octets of the Encoded Data field are accumulated by the
calc_crc32K() function before decoding. The Encoded CRC-32K field is calc_crc32K() function before decoding. The Encoded CRC-32K field is
then decoded and the resulting four octets are accumulated by the then decoded and the resulting four octets are accumulated by the
calc_crc32K() function. If the result is the expected residue value calc_crc32K() function. If the result is the expected residue value
'CRC32K_RESIDUE', then the frame was received correctly. 'CRC32K_RESIDUE', then the frame was received correctly.
An example CRC-32K function in shown below for illustration. An example CRC-32K function in shown below for illustration.
Complete examples of use and test vectors are provided in BACnet Complete examples of use and test vectors are provided in [BACnet]
[Addendum_an]. Clause 9.
<CODE BEGINS>
#include <stdint.h> #include <stdint.h>
/* See BACnet Addendum 135-2012an, section G.3.2 */ /* See BACnet Addendum 135-2012an, section G.3.2 */
#define CRC32K_INITIAL_VALUE (0xFFFFFFFF) #define CRC32K_INITIAL_VALUE (0xFFFFFFFF)
#define CRC32K_RESIDUE (0x0843323B) #define CRC32K_RESIDUE (0x0843323B)
/* CRC-32K polynomial, 1 + x**1 + ... + x**30 (+ x**32) */ /* CRC-32K polynomial, 1 + x**1 + ... + x**30 (+ x**32) */
#define CRC32K_POLY (0xEB31D82E) #define CRC32K_POLY (0xEB31D82E)
skipping to change at page 22, line 5 skipping to change at page 21, line 40
crc_value >>= 1; crc_value >>= 1;
crc_value ^= CRC32K_POLY; crc_value ^= CRC32K_POLY;
} else { } else {
crc_value >>= 1; crc_value >>= 1;
} }
data_value >>= 1; data_value >>= 1;
} }
return crc_value; return crc_value;
} }
<CODE ENDS>
Appendix D. Example 6LoBAC Packet Decode Appendix D. Example 6LoBAC Packet Decode
This Appendix is informative and not part of the standard. This Appendix is informative and not part of the standard.
BACnet MS/TP, Src (2), Dst (1), IPv6 Encapsulation BACnet MS/TP, Src (2), Dst (1), IPv6 Encapsulation
Preamble 55: 0x55 Preamble 55: 0x55
Preamble FF: 0xff Preamble FF: 0xff
Frame Type: IPv6 Encapsulation (34) Frame Type: IPv6 Encapsulation (34)
Destination Address: 1 Destination Address: 1
Source Address: 2 Source Address: 2
 End of changes. 67 change blocks. 
169 lines changed or deleted 202 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/