draft-ietf-6lo-6lobac-07.txt   draft-ietf-6lo-6lobac-08.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: August 31, 2017 Johnson Controls Expires: September 11, 2017 Johnson Controls
C. Neilson C. Neilson
Delta Controls Delta Controls
S. Donaldson S. Donaldson
Honeywell Honeywell
February 27, 2017 March 10, 2017
Transmission of IPv6 over MS/TP Networks Transmission of IPv6 over MS/TP Networks
draft-ietf-6lo-6lobac-07 draft-ietf-6lo-6lobac-08
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 and is used primarily 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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 31, 2017. This Internet-Draft will expire on September 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 10 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 10
10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 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] . . . . . . 17 Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 17
Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 20 Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 20
Appendix D. Example 6LoBAC Packet Decode . . . . . . . . . . . . 22 Appendix D. Example 6LoBAC Frame 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 and is used protocol for the RS-485 [TIA-485-A] physical layer and is used
primarily 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
where noted, elements of the 6LoWPAN specifications [RFC4944], elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and
[RFC6282], and [RFC6775] to constrained wired networks. [RFC6775] to constrained wired networks, as noted below.
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. These constraints, together limited processing power and memory. These constraints, together
with low data rates and a small MAC address space, are similar to with low data rates and a small MAC address space, are similar to
those faced in 6LoWPAN networks. MS/TP differs significantly from those faced in 6LoWPAN networks. MS/TP differs significantly from
6LoWPAN in at least three respects: a) MS/TP devices are typically 6LoWPAN in at least three respects: a) MS/TP devices are typically
mains powered, b) all MS/TP devices on a segment can communicate 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) directly so there are no hidden node or mesh routing issues, and c)
the latest MS/TP specification provides support for large 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. The encapsulation (subsequently referred to as MS/TP frames. This specifcation (subsequently referred to as
"LoBAC") supports a REQUIRED header compression mechanism that is "6LoBAC") includes a REQUIRED header compression mechanism that is
based on LOWPAN_IPHC [RFC6282] and improves MS/TP link utilization. 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
skipping to change at page 3, line 40 skipping to change at page 3, line 40
MTU: Maximum Transmission Unit; the size of the largest network MTU: Maximum Transmission Unit; the size of the largest network
layer protocol data unit that can be communicated in a single layer protocol data unit that can be communicated in a single
network transaction 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, as specified in This section provides a brief overview of MS/TP, as specified in
ANSI/ASHRAE Std 135-2016 [BACnet] Clause 9. This version of [BACnet] ANSI/ASHRAE Standard 135-2016 [BACnet] Clause 9. The latest version
Clause 9 incorporates changes to legacy MS/TP, introduced in ANSI/ of [BACnet] integrates changes to legacy MS/TP (approved as
ASHRAE Addendum an to ANSI/ASHRAE Std 135-2012 [Addendum_an], that [Addendum_an]) that provide support for larger frame sizes and
support larger frame sizes and improved error handling. [BACnet] improved error handling. [BACnet] Clause 9 also covers physical
Clause 9 also covers physical layer deployment options. 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.2 kbit/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 interface requires only a
RS-485 [TIA-485-A] transceiver with a driver that can be disabled, UART, an RS-485 [TIA-485-A] transceiver with a driver that can be
and a 5 ms resolution timer. The MS/TP MAC is typically implemented disabled, and a 5 ms resolution timer. The MS/TP MAC is typically
in software. implemented in software.
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 only initiate the transmission of a data frame when Only an MS/TP master node can initiate the unsolicited transfer of
it holds the token. After sending at most a configured maximum data, and only when it holds the token. After sending at most a
number of data frames, a master node passes the token to the next configured maximum number of data frames, a master node passes the
master node (as determined by MAC address). If present on the link, token to the next master node (as determined by MAC address). If
legacy MS/TP implementations (including any slave nodes) ignore the present on the link, legacy MS/TP implementations (including any
frame format defined in this specification. slave nodes) ignore the frame format defined in this specification.
[BACnet] Clause 9 defines a range of Frame Type values used to [BACnet] Clause 9 defines a range of Frame Type values used to
designate frames that contain data and data CRC fields encoded using designate frames that contain data and data CRC fields encoded using
Consistent Overhead Byte Stuffing [COBS] (see Appendix B). The Consistent Overhead Byte Stuffing [COBS] (see Appendix B). The
purpose of COBS encoding is to eliminate preamble sequences from the purpose of COBS encoding is to eliminate preamble sequences from the
Encoded Data and Encoded CRC-32K fields. The Encoded Data is covered 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: 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 5, line 11 skipping to change at page 5, line 11
Encoded Data 2 - 1506 octets (see Section 4 and 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
3 Test_Request
4 Test_Response
... ...
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 that 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. See Section 2 for
must understand Token, Poll For Master, and Reply to Poll For Master 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] Annex G.1. 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]
Clause 9. Clause 9.
1.4. Goals and Constraints 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 on wired end devices in building automation and control networks by
leveraging existing standards to the greatest extent possible, and b) leveraging existing standards to the greatest extent possible, and b)
co-exist with legacy MS/TP implementations. Co-existence allows MS/ to co-exist with legacy MS/TP implementations. Co-existence allows
TP networks to be incrementally upgraded to support IPv6. MS/TP networks to be incrementally upgraded to support IPv6.
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] Clause 9. Master Node state machine as specified in [BACnet] Clause 9.
2. Profile for IPv6 over MS/TP 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.
2.1. Mandatory Features 2.1. Mandatory Features
Nodes that support IPv6 over MS/TP must implement the Master Node [BACnet] Clause 9 specifies mandatory to implement features of MS/TP
state machine as specified in [BACnet] Clause 9 and handle Token, devices. E.g., it is mandatory that all MS/TP nodes respond to a
Poll For Master, and Reply to Poll For Master control frames. Test_Request with a Test_Response frame. All MS/TP master nodes must
Additionally, nodes must implement a Receive Frame state machine as implement the Master Node state machine and handle Token, Poll For
specified in [BACnet] Clause 9 that handles COBS-encoded frames. 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 6LoBAC nodes must support a data rate of 115.2 kbit/s and may support
bit/s and MAY optionally support lower data rates as specified in lower data rates as specified in [BACnet] Clause 9. The method of
[BACnet] Clause 9. selecting the data rate is outside the scope of this specification.
2.2. Configuration Constants 2.2. Configuration Constants
The following constants are used by the Receive Frame state machine. The following constants are used by the Receive Frame state machine.
Nmin_COBS_length The minimum valid length of any LoBAC encapsulated Nmin_COBS_length The minimum valid Length value of any LoBAC
frame: 5 encapsulated frame: 5
Nmax_COBS_length The maximum valid length of any LoBAC encapsulated Nmax_COBS_length The maximum valid Length value of any LoBAC
frame: 1509 encapsulated frame: 1509
2.3. Configuration Parameters 2.3. Configuration Parameters
The following parameters are used by the Master Node state machine. The following parameters are used by the Master Node state machine.
Nmax_info_frames The default maximum number of information frames Nmax_info_frames The default maximum number of information frames
the node may send before it must pass the token: 1 the node may send before it must pass the token: 1
Nmax_master The default highest allowable address for master Nmax_master The default highest allowable address for master
nodes: 127 nodes: 127
skipping to change at page 7, line 21 skipping to change at page 7, line 23
4. Maximum Transmission Unit (MTU) 4. Maximum Transmission Unit (MTU)
Upon transmission, the network layer MTU is formatted according to Upon transmission, the network layer MTU is formatted according to
Section 5 and becomes the MAC service data unit (MSDU). The MSDU is 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. then COBS encoded by MS/TP. Upon reception, the steps are reversed.
[BACnet] Clause 9 supports MSDUs up to 2032 octets in length. [BACnet] Clause 9 supports MSDUs up to 2032 octets in length.
IPv6 [RFC2460] requires that every link in the internet have an MTU IPv6 [RFC2460] requires that every link in the internet have an MTU
of 1280 octets or greater. Additionally, a node must be able to of 1280 octets or greater. Additionally, a node must be able to
accept a fragmented packet that, after reassembly, is as large as accept a fragmented packet that, after reassembly, is as large as
1500 octets. This specification defines an MSDU length of at least 1500 octets. This specification defines an MTU length of at least
1280 octets and at most 1500 octets. Support for an MSDU length of 1280 octets and at most 1500 octets. Support for an MTU length of
1500 octets is RECOMMENDED. 1500 octets is RECOMMENDED.
5. LoBAC Adaptation Layer 5. LoBAC Adaptation Layer
This section specifies an adaptation layer to support compressed IPv6 This section specifies an adaptation layer to support compressed IPv6
headers as specified in Section 10. IPv6 header compression MUST be headers as specified in Section 10. IPv6 header compression MUST be
implemented on all nodes. Implementations MAY also support Generic implemented on all nodes. Implementations MAY also support Generic
Header Compression [RFC7400] for transport layer headers. Header Compression [RFC7400] for transport layer headers.
The LoBAC encapsulation format defined in this section describes the 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 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 packet) follows an encapsulation header stack. LoBAC is a subset of
the LoWPAN encapsulation defined in [RFC4944] as updated by the LoWPAN encapsulation defined in [RFC4944] as updated by [RFC6282]
[RFC6282], therefore the use of "LOWPAN" in literals below is so the use of "LOWPAN" in literals below is intentional. The primary
intentional. The primary difference between LoWPAN and LoBAC is difference between LoWPAN and LoBAC encapsulation is omission of the
omission of the Mesh, Broadcast, Fragmentation, and LOWPAN_HC1 Mesh, Broadcast, Fragmentation, and LOWPAN_HC1 headers in the latter.
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 |
+---------------+---------------+------...-----+ +---------------+---------------+------...-----+
skipping to change at page 8, line 42 skipping to change at page 8, line 42
concatenating the 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|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
A semantically opaque IID having 64 bits of entropy is strongly A semantically opaque IID having 64 bits of entropy is RECOMMENDED
RECOMMENDED for each routable address and MAY be locally generated for each globally scoped address and MAY be locally generated
according to one of the methods cited in Section 12. A node that 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 generates a 64-bit semantically opaque IID MUST register the IID with
its local router(s) by sending a Neighbor Solicitation (NS) message its local router(s) by sending a Neighbor Solicitation (NS) message
with the Address Registration Option (ARO) and process Neighbor with the Address Registration Option (ARO) and process Neighbor
Advertisements (NA) according to [RFC6775]. 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
skipping to change at page 10, line 20 skipping to change at page 10, line 20
formed by padding on the left with a zero octet: 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 6LoBAC REQUIRES LOWPAN_IPHC IPv6 compression, which is specified in
[RFC6282] and included herein by reference. This section will simply [RFC6282] and included herein by reference. This section will simply
identify substitutions that should be made when interpreting the text identify substitutions that should be made when interpreting the text
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"
skipping to change at page 11, line 7 skipping to change at page 11, line 7
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
See [I-D.ietf-6lo-privacy-considerations] for a general discussion of See [RFC8065] for a general discussion of privacy threats faced by
privacy threats faced by constrained nodes. constrained nodes.
[I-D.ietf-6lo-privacy-considerations] makes a distinction between [RFC8065] makes a distinction between "stable" and "temporary"
"stable" and "temporary" addresses. The former are long-lived and addresses. The former are long-lived and typically advertised by
typically advertised by servers. The latter are typically used by servers. The latter are typically used by clients and SHOULD be
clients and SHOULD be changed frequently to mitigate correlation of changed frequently to mitigate correlation of activities over time.
activities over time. Nodes that engage in both activities SHOULD Nodes that engage in both activities SHOULD support simultaneous use
support simultaneous use of multiple addresses per device. of multiple addresses per device.
Globally scoped addresses that contain MAC-address-derived IIDs may Globally scoped addresses that contain MAC-address-derived IIDs may
expose a network to address scanning attacks. For this reason, it is expose a network to address scanning attacks. For this reason, it is
strongly RECOMMENDED that a 64-bit semantically opaque IID be RECOMMENDED that a 64-bit semantically opaque IID be generated for
generated for each globally scoped address in use according to, for each globally scoped address in use according to, for example,
example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]. [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217].
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,
Carsten Bormann provided detailed reviews. Stuart Cheshire invented Carsten Bormann, and Dale Worley provided detailed reviews. Stuart
the very clever COBS encoding. Michael Osborne made the critical Cheshire invented the very clever COBS encoding. Michael Osborne
observation that encoding the data and CRC32K fields separately would made the critical observation that encoding the data and CRC32K
allow the CRC to be calculated on-the-fly. Alexandru Petrescu, Brian fields separately would allow the CRC to be calculated on-the-fly.
Frank, Geoff Mulligan, and Don Sturek offered valuable comments. Alexandru Petrescu, Brian Frank, Geoff Mulligan, and Don Sturek
offered valuable comments.
14. References 14. References
14.1. Normative 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,
<https://www.ashrae.org/File%20Library/docLib/StdsAddenda/
07-31-2014_135_2012_an_at_au_av_aw_ax_az_Final.pdf>.
[BACnet] 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-2016 (Clause 9), January 2016, ANSI/ASHRAE Standard 135-2016, January 2016,
<https://www.ashrae.org/resources--publications/bookstore/ <http://www.techstreet.com/ashrae/standards/
standard-135>. ashrae-135-2016?product_id=1918140#jumps>.
[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 33 skipping to change at page 13, line 28
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <http://www.rfc-editor.org/info/rfc7400>. 2014, <http://www.rfc-editor.org/info/rfc7400>.
14.2. Informative References 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,
<https://www.ashrae.org/File%20Library/docLib/StdsAddenda/
07-31-2014_135_2012_an_at_au_av_aw_ax_az_Final.pdf>.
[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte
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/ <https://users.ece.cmu.edu/~koopman/networks/dsn02/
dsn02_koopman.pdf>. dsn02_koopman.pdf>.
[I-D.ietf-6lo-privacy-considerations] [IEEE.802.3_2012]
Thaler, D., "Privacy Considerations for IPv6 Adaptation IEEE, "802.3-2012", IEEE 802.3-2012,
Layer Mechanisms", draft-ietf-6lo-privacy- DOI 10.1109/ieeestd.2012.6419735, January 2013,
considerations-04 (work in progress), October 2016. <http://ieeexplore.ieee.org/servlet/
opac?punumber=6419733>.
[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,
<http://standards.ieee.org/getieee802/802.3.html>.
[RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical [RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical
Ordering Of Link-Layer Addresses", RFC 2469, Ordering Of Link-Layer Addresses", RFC 2469,
DOI 10.17487/RFC2469, December 1998, DOI 10.17487/RFC2469, December 1998,
<http://www.rfc-editor.org/info/rfc2469>. <http://www.rfc-editor.org/info/rfc2469>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <http://www.rfc-editor.org/info/rfc8065>.
[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, <https://global.ihs.com/
doc_detail.cfm?item_s_key=00032964>.
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] Clause 9 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.
skipping to change at page 17, line 32 skipping to change at page 17, line 32
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 as worst-case overhead in long fields is bounded to one octet per 254 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 legacy MS/TP devices, is placed in
in the MS/TP header Length field before transmission. 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] Clause 9. in [BACnet] Annex T.
<CODE BEGINS> <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.
skipping to change at page 20, line 13 skipping to change at page 20, line 13
<CODE ENDS> <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. some that exceed the [IEEE.802.3_2012] polynomial in performance.
[BACnet] Clause 9 specifies one of these, the CRC-32K (Koopman) [BACnet] Clause 9 specifies one of these, the CRC-32K (Koopman)
polynomial. 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]
Clause 9. Annex G.3.
<CODE BEGINS> <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) */
skipping to change at page 22, line 5 skipping to change at page 22, line 5
} else { } else {
crc_value >>= 1; crc_value >>= 1;
} }
data_value >>= 1; data_value >>= 1;
} }
return crc_value; return crc_value;
} }
<CODE ENDS> <CODE ENDS>
Appendix D. Example 6LoBAC Packet Decode Appendix D. Example 6LoBAC Frame 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
Length: 537 Length: 537
 End of changes. 39 change blocks. 
104 lines changed or deleted 105 lines changed or added

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