draft-ietf-6lo-6lobac-00.txt   draft-ietf-6lo-6lobac-01.txt 
6Lo Working Group K. Lynn, Ed. 6Lo Working Group K. Lynn, Ed.
Internet-Draft Consultant Internet-Draft Verizon
Intended status: Standards Track J. Martocci Intended status: Standards Track J. Martocci
Expires: January 5, 2015 Johnson Controls Expires: September 10, 2015 Johnson Controls
C. Neilson C. Neilson
Delta Controls Delta Controls
S. Donaldson S. Donaldson
Honeywell Honeywell
July 4, 2014 March 9, 2015
Transmission of IPv6 over MS/TP Networks Transmission of IPv6 over MS/TP Networks
draft-ietf-6lo-6lobac-00 draft-ietf-6lo-6lobac-01
Abstract Abstract
Master-Slave/Token-Passing (MS/TP) is a contention-free access method Master-Slave/Token-Passing (MS/TP) is a contention-free access method
for the RS-485 physical layer, which is used extensively in building for the RS-485 physical layer, which is used extensively 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 January 5, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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. MS/TP Mode for IPv6 . . . . . . . . . . . . . . . . . . . . . 5
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 6 3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 6
4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 6 4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 6
5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 7 5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 6
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9
7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 10 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 10
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 11 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 11
10. Header Compression . . . . . . . . . . . . . . . . . . . . . 11 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 14 Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 14
skipping to change at page 2, line 50 skipping to change at page 2, line 50
networks. 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. Together with low data rates
and a small address space, these constraints are similar to those and a small address space, these constraints are similar to those
faced in 6LoWPAN networks and suggest some elements of that solution faced in 6LoWPAN networks and suggest some elements of that solution
might be leveraged. MS/TP differs significantly from 6LoWPAN in at might be leveraged. MS/TP differs significantly from 6LoWPAN in at
least three respects: a) MS/TP devices typically have a continuous least three respects: a) MS/TP devices typically have a continuous
source of power, 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 will support payloads of up to 1501 octets, recent changes to MS/TP provide support for large payloads,
eliminating the need for link-layer fragmentation and reassembly. eliminating the need for link-layer fragmentation and reassembly.
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. This document also specifies a header compression
mechanism, based on [RFC6282], that is RECOMMENDED in order to make mechanism, based on [RFC6282], that is RECOMMENDED in order to make
IPv6 practical on low speed MS/TP networks. IPv6 practical on low speed MS/TP networks.
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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 Check
MAC: Medium Access Control MAC: Medium Access Control
MTU: Maximum Transmission Unit
MSDU: MAC Service Data Unit (MAC client data) MSDU: MAC Service Data Unit (MAC client data)
MTU: Maximum Transmission Unit
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, which is specified
in ANSI/ASHRAE 135-2012 (BACnet) Clause 9 [Clause9] and included in ANSI/ASHRAE 135-2012 (BACnet) Clause 9 [Clause9] and included
herein by reference. BACnet [Clause9] also covers physical layer herein by reference. BACnet [Clause9] also covers physical layer
deployment options. deployment options.
MS/TP is designed to enable multidrop networks over shielded twisted MS/TP is designed to enable multidrop networks over shielded twisted
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Encoded Data* (2 - 1512 octets) . . Encoded Data* (2 - 1507 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
*Note: BACnet Addendum 135-2012an [Addendum_an] defines a range of *Note: BACnet Addendum 135-2012an [Addendum_an] defines a range of
skipping to change at page 5, line 6 skipping to change at page 5, line 6
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 - 1512 octets (see Appendix B) Encoded Data 2 - 1512 octets (see 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 relevent 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
ASHRAE reserves undefined MS/TP Frame Type values 8 through 31 and 34 Frame Types 8 through 127 are reserved for assignment by ASHRAE.
through 127, inclusive. Frame Types 32 through 127 designate COBS- Frame Types 32 through 127 designate COBS-encoded frames and MUST
encoded frames and MUST convey Encoded Data and Encoded CRC-32K convey Encoded Data and Encoded CRC-32K fields. All master nodes
fields. All master nodes MUST understand Token, Poll For Master, and MUST understand Token, Poll For Master, and Reply to Poll For Master
Reply to Poll For Master control frames. See Section 2 for control frames. See Section 2 for additional details.
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 specifies the combined For COBS-encoded frames, the Length field specifies the combined
length of the [COBS] Encoded Data and Encoded CRC-32K fields in length of the [COBS] Encoded Data and Encoded CRC-32K fields in
octets, minus two. (This adjustment is required for backward octets, minus two. (This adjustment is required for backward
compatibility with legacy MS/TP devices.) See Section 4 and compatibility with legacy MS/TP devices.) See Section 4 and
Appendices for additional details. 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 [Clause9].
1.4. Goals and Non-goals 1.4. Goals and Non-goals
The primary goal of this specification is to enable IPv6 directly on The primary goal of this specification is to enable IPv6 directly on
wired end devices in building automation and control networks by 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. A
secondary goal is to co-exist with legacy MS/TP implementations. secondary goal is to co-exist with legacy MS/TP implementations.
Only the minimal changes necessary to support IPv6 over MS/TP are Only the minimum changes necessary to support IPv6 over MS/TP are
specified in BACnet [Addendum_an] (see Note in Section 1.3). specified in BACnet [Addendum_an] (see Note in Section 1.3).
Non-goals include making changes to the MS/TP frame header format, Non-goals include making changes to the MS/TP frame header format,
control frames, Master Node state machine, or addressing modes. control frames, Master Node state machine, or addressing modes.
Also, while the techniques described here may be applicable to other Also, while the techniques described here may be applicable to other
data links, no attempt is made to define a general design pattern. data links, no attempt is made to define a general design pattern.
2. MS/TP Mode for IPv6 2. MS/TP Mode for IPv6
ASHRAE must assign a new MS/TP Frame Type to indicate IPv6 over MS/TP ASHRAE must assign a new MS/TP Frame Type to indicate IPv6 over MS/TP
skipping to change at page 6, line 42 skipping to change at page 6, line 36
(all nodes). A Source Address of 255 MUST NOT be used. MS/TP does (all nodes). A Source Address of 255 MUST NOT be used. MS/TP does
not support multicast, therefore all IPv6 multicast packets MUST be not support multicast, therefore all IPv6 multicast packets MUST be
sent as link-level broadcasts and filtered at the IPv6 layer. sent as link-level broadcasts and filtered at the IPv6 layer.
This specification assumes that a unique IPv6 subnet prefix is This specification assumes that a unique IPv6 subnet prefix is
assigned to each MS/TP segment. Hosts learn IPv6 prefixes via router assigned to each MS/TP segment. Hosts learn IPv6 prefixes via router
advertisements according to [RFC4861]. advertisements according to [RFC4861].
4. Maximum Transmission Unit (MTU) 4. Maximum Transmission Unit (MTU)
BACnet [Addendum_an] supports MPDUs up to 2032 octets in length. BACnet [Addendum_an] supports MSDUs up to 2032 octets in length.
This specification defines an MPDU length of at least 1281 octets and This specification defines an MSDU length of at least 1281 octets and
at most 1501 octets. This is sufficient to convey the minimum MTU at most 1501 octets. This is sufficient to convey the minimum MTU
required by IPv6 [RFC2460] without the need for link-layer required by IPv6 [RFC2460] without the need for link-layer
fragmentation and reassembly. fragmentation and reassembly.
However, the relatively low data rates of MS/TP still make a The relatively low data rates of MS/TP, however, still make a
compelling case for header compression. An adaptation layer to compelling case for header compression. An adaptation layer to
indicate compressed or uncompressed IPv6 headers is specified in indicate compressed or uncompressed IPv6 headers is specified in
Section 5 and the compression scheme is specified in Section 10. Section 5 and the compression scheme is specified in Section 10.
5. LoBAC Adaptation Layer 5. LoBAC Adaptation Layer
The encapsulation formats defined in this section (subsequently The encapsulation formats defined in this section (subsequently
referred to as the "LoBAC" encapsulation) comprise the MSDU (payload) referred to as the "LoBAC" encapsulation) comprise the MSDU (payload)
of an MS/TP frame. The LoBAC payload (i.e., an IPv6 packet) follows of an MS/TP frame. The LoBAC payload (i.e., an IPv6 packet) follows
an encapsulation header stack. LoBAC is a subset of the LoWPAN an encapsulation header stack. LoBAC is a subset of the LoWPAN
skipping to change at page 8, line 49 skipping to change at page 8, line 42
Figure 3: Dispatch Value Bit Patterns Figure 3: Dispatch Value Bit Patterns
NALP: Specifies that the following bits are not a part of the LoBAC NALP: Specifies that the following bits are not a part of the LoBAC
encapsulation, and any LoBAC node that encounters a Dispatch encapsulation, and any LoBAC node that encounters a Dispatch
value of 00xxxxxx shall discard the packet. Non-LoBAC protocols value of 00xxxxxx shall discard the packet. Non-LoBAC protocols
that wish to coexist with LoBAC nodes should include an octet that wish to coexist with LoBAC nodes should include an octet
matching this pattern immediately following the MS/TP header. matching this pattern immediately following the MS/TP header.
ESC: Specifies that the following header is a single 8-bit field for ESC: Specifies that the following header is a single 8-bit field for
the Dispatch value. It allows support for Dispatch values larger the Dispatch value. It allows support for Dispatch values larger
than 127 (see [RFC6282] section 5). than 127 (see Section 5 of [RFC6282]).
IPv6: Specifies that the following header is an uncompressed IPv6 IPv6: Specifies that the following header is an uncompressed IPv6
header [RFC2460]. header [RFC2460].
LOWPAN_IPHC: A value of 011xxxxx specifies a LOWPAN_IPHC compression LOWPAN_IPHC: A value of 011xxxxx specifies a LOWPAN_IPHC compression
header (see Section 10.) header (see Section 10.)
Reserved: A LoBAC node that encounters a Dispatch value in the range Reserved: A LoBAC node that encounters a Dispatch value in the range
01000010 through 01011111 or 1xxxxxxx SHALL discard the packet. 01000010 through 01011111 or 1xxxxxxx SHALL discard the packet.
skipping to change at page 9, line 43 skipping to change at page 9, line 37
|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, as it supports the This is the RECOMMENDED method of forming an IID, as it supports the
most efficient header compression provided by the LOWPAN_IPHC most efficient header compression provided by the LOWPAN_IPHC
[RFC6282] scheme specified in Section 10. [RFC6282] scheme specified in Section 10.
Optionally, an opaque 64-bit IID (for non-link-local addresses) MAY
be formed by the technique discussed in [I-D.ietf-6man-default-iids]
or alternate method. A node that generates a non-link-local address
IID MUST 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.
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
skipping to change at page 10, line 31 skipping to change at page 10, line 31
The Source/Target Link-layer Address option has the following form The Source/Target Link-layer Address option has the following form
when the addresses are 8-bit MS/TP link-layer (node) addresses. when the addresses are 8-bit MS/TP link-layer (node) addresses.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 | | Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Padding (all zeros) -+ + Padding (all zeros) +
| | | |
+- +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| | MS/TP Address | | | MS/TP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option fields: Option fields:
Type: Type:
1: for Source Link-layer address. 1: for Source Link-layer address.
2: for Target Link-layer address. 2: for Target Link-layer address.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
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. work.
14. References 14. References
14.1. Normative References 14.1. Normative References
[Addendum_an] [Addendum_an]
ASHRAE, "Proposed Addendum an to ANSI/ASHRAE Standard ASHRAE, "ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and
135-2012, BACnet - A Data Communication Protocol for az to ANSI/ASHRAE Standard 135-2012, BACnet - A Data
Building Automation and Control Networks (Second Public Communication Protocol for Building Automation and Control
Review)", March 2014, <http://www.bacnet.org/Addenda/ Networks", July 2014,
Add-135-2012an-PPR2-draft-rc4_chair_approved.pdf>. <https://www.ashrae.org/File%20Library/docLib/
StdsAddenda/135_2012_an_at_au_av_aw_ax_az_Final.pdf>.
[Clause9] American Society of Heating, Refrigerating, and Air- [Clause9] 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-2012 (Clause 9), March 2013.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
skipping to change at page 13, line 35 skipping to change at page 13, line 35
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) [EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", March 1997, Registration Authority", March 1997,
<http://standards.ieee.org/regauth/oui/tutorials/ <http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html>. EUI64.html>.
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-02 (work in progress),
January 2015.
[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
(CMSA/CD) Access Method and Physical Layer (CMSA/CD) Access Method and Physical Layer
Specifications", IEEE Std 802.3-2008, December 2008, Specifications", IEEE Std 802.3-2008, December 2008,
<http://standards.ieee.org/getieee802/802.3.html>. <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
skipping to change at page 14, line 36 skipping to change at page 14, line 42
MA-DATA.request ( MA-DATA.request (
destination_address, destination_address,
source_address, source_address,
data, data,
priority, priority,
type type
) )
The 'destination_address' parameter may specify either an individual The 'destination_address' parameter may specify either an individual
or a broadcast MAC entity address. It must contain sufficient or a broadcast MAC entity address. It must contain sufficient
information to create the Destination Address field (see Section 10) information to create the Destination Address field (see Section 1.3)
that is prepended to the frame by the local MAC sublayer entity. The that is prepended to the frame by the local MAC sublayer entity. The
'source_address' parameter, if present, must specify an individual 'source_address' parameter, if present, must specify an individual
MAC address. If the source_address parameter is omitted, the local MAC address. If the source_address parameter is omitted, the local
MAC sublayer entity will insert a value associated with that entity. MAC sublayer entity will insert a value associated with that entity.
The 'data' parameter specifies the MAC service data unit (MSDU) to be The 'data' parameter specifies the MAC service data unit (MSDU) to be
transferred by the MAC sublayer entity. There is sufficient transferred by the MAC sublayer entity. There is sufficient
information associated with the MSDU for the MAC sublayer entity to information associated with the MSDU for the MAC sublayer entity to
determine the length of the data unit. determine the length of the data unit.
skipping to change at page 16, line 11 skipping to change at page 16, line 19
The 'priority' parameter specifies the priority desired for the data The 'priority' parameter specifies the priority desired for the data
unit transfer. The priority parameter is ignored by MS/TP. unit transfer. The priority parameter is ignored by MS/TP.
The 'type' parameter is the value of the MS/TP Frame Type field of The 'type' parameter is the value of the MS/TP Frame Type field of
the incoming frame. the incoming frame.
A.2.3. When Generated A.2.3. When Generated
The MA_DATA.indication is passed from the MAC sublayer entity to the The MA_DATA.indication is passed from the MAC sublayer entity to the
MAC client entity or entites to indicate the arrival of a frame to MAC client entity or entities to indicate the arrival of a frame to
the local MAC sublayer entity that is destined for the MAC client. the local MAC sublayer entity that is destined for the MAC client.
Such frames are reported only if they are validly formed, received Such frames are reported only if they are validly formed, received
without error, and their destination address designates the local MAC without error, and their destination address designates the local MAC
entity. Frames destined for the MAC Control sublayer are not passed entity. Frames destined for the MAC Control sublayer are not passed
to the MAC client. to the MAC client.
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.
skipping to change at page 16, line 44 skipping to change at page 16, line 52
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. [Addendum_an] specifies the preamble octet '0x55' for removal.
The minimum overhead of COBS is one ectet per encoded field. The The minimum overhead of COBS is one ectet per encoded field. The
worst-case overhead is bounded to one octet in 254, or less than worst-case overhead is bounded to one octet in 254, or less than
0.5%, as described in [COBS]. 0.5%, as described in [COBS].
Frame encoding proceeds logically in two passes. The Extended 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 '0x055' with each octet of the output. XOR'ing the preamble octet '0x055' with each octet of the output.
The Extended Data CRC field is then prepared by calculating a CRC-32K The Encoded CRC-32K field is then prepared by calculating a CRC-32K
over the Extended Data field and formatting it for transmission as over 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 [Addendum_an].
#include <stddef.h> #include <stddef.h>
#include <stdint.h> #include <stdint.h>
#define CRC32K_INITIAL_VALUE (0xFFFFFFFF)
#define MSTP_PREAMBLE_X55 (0x55)
/* #define CRC32K_INITIAL_VALUE (0xFFFFFFFF)
* Encodes 'length' octets of data located at 'from' and #define MSTP_PREAMBLE_X55 (0x55)
* writes one or more COBS code blocks at 'to', removing any
* 'mask' octets that may present be in the encoded data.
* Returns the length of the encoded data.
*/
size_t /*
cobs_encode (uint8_t *to, const uint8_t *from, size_t length, * Encodes 'length' octets of data located at 'from' and
uint8_t mask) * writes one or more COBS code blocks at 'to', removing any
{ * 'mask' octets that may present be in the encoded data.
size_t code_index = 0; * Returns the length of the encoded data.
size_t read_index = 0; */
size_t write_index = 1;
uint8_t code = 1;
uint8_t data, last_code;
while (read_index < length) { size_t
data = from[read_index++]; cobs_encode (uint8_t *to, const uint8_t *from, size_t length,
/* uint8_t mask)
* In the case of encountering a non-zero octet in the data, {
* simply copy input to output and increment the code octet. size_t code_index = 0;
*/ size_t read_index = 0;
if (data != 0) { size_t write_index = 1;
to[write_index++] = data ^ mask; uint8_t code = 1;
code++; uint8_t data, last_code;
if (code != 255)
continue;
}
/*
* In the case of encountering a zero in the data or having
* copied the maximum number (254) of non-zero octets, store
* the code octet and reset the encoder state variables.
*/
last_code = code;
to[code_index] = code ^ mask;
code_index = write_index++;
code = 1;
} while (read_index < length) {
/* data = from[read_index++];
* If the last chunk contains exactly 254 non-zero octets, then /*
* this exception is handled above (and returned length must be * In the case of encountering a non-zero octet in the data,
* adjusted). Otherwise, encode the last chunk normally, as if * simply copy input to output and increment the code octet.
* a "phantom zero" is appended to the data. */
*/ if (data != 0) {
if ((last_code == 255) && (code == 1)) to[write_index++] = data ^ mask;
write_index--; code++;
else if (code != 255)
to[code_index] = code ^ mask; continue;
}
/*
* In the case of encountering a zero in the data or having
* copied the maximum number (254) of non-zero octets, store
* the code octet and reset the encoder state variables.
*/
last_code = code;
to[code_index] = code ^ mask;
code_index = write_index++;
code = 1;
}
/*
* If the last chunk contains exactly 254 non-zero octets, then
* this exception is handled above (and returned length must be
* adjusted). Otherwise, encode the last chunk normally, as if
* a "phantom zero" is appended to the data.
*/
if ((last_code == 255) && (code == 1))
write_index--;
else
to[code_index] = code ^ mask;
return write_index; return write_index;
} }
#include <stddef.h> #include <stddef.h>
#include <stdint.h> #include <stdint.h>
#define CRC32K_INITIAL_VALUE (0xFFFFFFFF) #define CRC32K_INITIAL_VALUE (0xFFFFFFFF)
#define CRC32K_RESIDUE (0x0843323B) #define MSTP_PREAMBLE_X55 (0x55)
#define MSTP_PREAMBLE_X55 (0x55)
/* /*
* Decodes 'length' octets of data located at 'from' and * Decodes 'length' octets of data located at 'from' and
* writes the original client data at 'to', restoring any * writes the original client data at 'to', restoring any
* 'mask' octets that may present in the encoded data. * 'mask' octets that may present in the encoded data.
* Returns the length of the encoded data or zero if error. * Returns the length of the encoded data or zero if error.
*/ */
size_t size_t
cobs_decode (uint8_t *to, const uint8_t *from, size_t length, cobs_decode (uint8_t *to, const uint8_t *from, size_t length,
uint8_t mask) uint8_t mask)
{ {
size_t read_index = 0; size_t read_index = 0;
size_t write_index = 0; size_t write_index = 0;
uint8_t code, last_code; uint8_t code, last_code;
while (read_index < length) { while (read_index < length) {
code = from[read_index] ^ mask; code = from[read_index] ^ mask;
last_code = code; last_code = code;
/* /*
* Sanity check the encoding to prevent the while() loop below * Sanity check the encoding to prevent the while() loop below
* from overrunning the output buffer. * from overrunning the output buffer.
*/ */
if (read_index + code > length) if (read_index + code > length)
return 0; return 0;
read_index++; read_index++;
while (--code > 0) while (--code > 0)
to[write_index++] = from[read_index++] ^ mask; to[write_index++] = from[read_index++] ^ mask;
/* /*
* 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;
} }
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 1501 octets required upgrading the Extending the payload of MS/TP to 1501 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. BACnet
[Addendum_an] specifies the CRC-32K (Koopman) polynomial. [Addendum_an] specifies 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 ones Before a frame is transmitted, 'crc_value' is initialized to all
before the function is called. After passing all octets of the ones. After passing each octet of the [COBS] Encoded Data through
[COBS] Encoded Data through the function, the ones complement of the the function, the ones complement of the resulting 'crc_value' is
resulting 'crc_value' is arranged in LSB-first order and is itself arranged in LSB-first order and is itself [COBS] encoded. The length
[COBS] encoded. 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
skipping to change at page 21, line 24 skipping to change at page 21, line 24
/* /*
* Accumulate 'data_value' into the CRC in 'crc_value'. * Accumulate 'data_value' into the CRC in 'crc_value'.
* Return updated CRC. * Return updated CRC.
* *
* Note: crcValue must be set to CRC32K_INITIAL_VALUE * Note: crcValue must be set to CRC32K_INITIAL_VALUE
* before initial call. * before initial call.
*/ */
uint32_t uint32_t
calc_crc32K (uint8_t data_value, uint32_t crc_value) calc_crc32K (uint8_t data_value, uint32_t crc_value)
{ {
uint8_t data, b; int b;
uint32_t crc;
data = data_value;
crc = crc_value;
for (b = 0; b < 8; b++) { for (b = 0; b < sizeof(uint8_t); b++) {
if ((data & 1) ^ (crc & 1)) { if ((data_value & 1) ^ (crc_value & 1)) {
crc >>= 1; crc_value >>= 1;
crc ^= CRC32K_POLY; crc_value ^= CRC32K_POLY;
} else { } else {
crc >>= 1; crc_value >>= 1;
} }
data >>= 1; data_value >>= 1;
} }
return crc; return crc_value;
} }
Authors' Addresses Authors' Addresses
Kerry Lynn (editor) Kerry Lynn (editor)
Consultant Verizon
50 Sylvan Rd
Waltham , MA 02451
USA
Phone: +1 978 460 4253 Phone: +1 781 296 9722
Email: kerlyn@ieee.org Email: kerlyn@ieee.org
Jerry Martocci Jerry Martocci
Johnson Controls, Inc. Johnson Controls, Inc.
507 E. Michigan St 507 E. Michigan St
Milwaukee , WI 53202 Milwaukee , WI 53202
USA USA
Phone: +1 414 524 4010 Phone: +1 414 524 4010
Email: jerald.p.martocci@jci.com Email: jerald.p.martocci@jci.com
 End of changes. 45 change blocks. 
149 lines changed or deleted 159 lines changed or added

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