< draft-ietf-6lo-6lobac-05.txt   draft-ietf-6lo-6lobac-06.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: December 18, 2016 Johnson Controls Expires: May 4, 2017 Johnson Controls
C. Neilson C. Neilson
Delta Controls Delta Controls
S. Donaldson S. Donaldson
Honeywell Honeywell
June 16, 2016 October 31, 2016
Transmission of IPv6 over MS/TP Networks Transmission of IPv6 over MS/TP Networks
draft-ietf-6lo-6lobac-05 draft-ietf-6lo-6lobac-06
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, 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 December 18, 2016. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . 8
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 9 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 9
10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10 10. Header Compression . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 13 Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 14
Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 16 Appendix B. Consistent Overhead Byte Stuffing [COBS] . . . . . . 16
Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 19 Appendix C. Encoded CRC-32K [CRC32K] . . . . . . . . . . . . . . 19
Appendix D. Example 6LoBAC Packet Decode . . . . . . . . . . . . 21 Appendix D. Example 6LoBAC Packet Decode . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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, which is used
extensively in building automation networks. This specification extensively 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 elements of the 6LoWPAN specifications [RFC4944], [RFC6282], and
[RFC6775] to constrained wired networks. [RFC6775], where noted, 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. Together with low data rates
and a small MAC address space, these constraints are similar to those and a small MAC 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 provide support for larger payloads, recent changes to MS/TP provide support for larger payloads,
skipping to change at page 5, line 42 skipping to change at page 5, line 42
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 [Clause9].
Use of the optional 0xFF trailer octet is discussed in BACnet
[Clause9].
1.4. Goals and Constraints 1.4. Goals and Constraints
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 minimum changes necessary to support IPv6 over MS/TP were Only the minimum changes necessary to support IPv6 over MS/TP were
specified in BACnet [Addendum_an] (see Section 1.3). 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 [Clause9].
2. MS/TP Mode for IPv6 2. MS/TP Mode for IPv6
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 All MS/TP master nodes (including those that support IPv6) MUST
implement the Master Node state machine specified in BACnet [Clause9] implement the Master Node state machine specified in BACnet [Clause9]
and handle Token, Poll For Master, and Reply to Poll For Master and handle Token, Poll For Master, and Reply to Poll For Master
control frames. MS/TP master nodes that support IPv6 must also control frames. MS/TP master nodes that support IPv6 MUST also
implement the Receive Frame state machine specified in [Clause9] as implement the Receive Frame state machine specified in [Clause9] as
extended by BACnet [Addendum_an]. extended by BACnet [Addendum_an].
All MS/TP nodes that support IPv6 MUST support a data rate of 115,200 All MS/TP nodes that support IPv6 MUST support a data rate of 115,200
bit/s and MAY optionally support lower data rates as defined in bit/s and MAY optionally support lower data rates as defined in
BACnet [Clause9]. BACnet [Clause9].
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. The method of
skipping to change at page 6, line 38 skipping to change at page 6, line 41
However, each MS/TP node on the link MUST have a unique address in However, each MS/TP node on the link MUST have a unique address in
order to ensure correct MAC operation. order to ensure correct MAC operation.
BACnet [Clause9] specifies that addresses 0 through 127 are valid for BACnet [Clause9] specifies that addresses 0 through 127 are valid for
master nodes. The method specified in Section 6 for creating a MAC- master nodes. The method specified in Section 6 for creating a MAC-
layer-derived Interface Identifier (IID) ensures that an IID of all layer-derived Interface Identifier (IID) ensures that an IID of all
zeros can never result. zeros can never result.
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 SHOULD be broadcast at the MAC layer and filtered multicast packets MUST be broadcast at the MAC layer and filtered at
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. BACnet [Addendum_an] supports MSDUs up to 2032 octets in length.
This specification defines an MSDU length of at least 1280 octets and This specification defines an MSDU length of at least 1280 octets and
at most 1500 octets (before encoding). This is sufficient to convey at most 1500 octets (before encoding). This is sufficient to convey
the minimum MTU required by IPv6 [RFC2460] without the need for link- the minimum MTU required by IPv6 [RFC2460] without the need for link-
layer fragmentation and reassembly. Support for an MSDU length of layer fragmentation and reassembly. 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 indicate header compression as The relatively low data rates of MS/TP dictate header compression as
a means to reduce latency. This section specifies an adaptation a means to reduce latency. This section specifies an adaptation
layer to support compressed IPv6 headers and the compression format layer to support compressed IPv6 headers as specified in Section 10.
is specified in Section 10. IPv6 header compression MUST be implemented on all nodes.
Implementations MAY also support Generic Header Compression (GHC) Implementations MAY also support Generic Header Compression (GHC)
[RFC7400] for transport layer headers. A node implementing [RFC7400] [RFC7400] for transport layer headers. A node implementing [RFC7400]
MUST probe its peers for GHC support before applying GHC. MUST probe its peers for GHC support before applying GHC.
The encapsulation format defined in this section (subsequently The encapsulation format defined in this section (subsequently
referred to as the "LoBAC" encapsulation) comprises the MSDU of an referred to as the "LoBAC" encapsulation) comprises the MSDU of an
IPv6 over MS/TP frame. The LoBAC payload (i.e., an IPv6 packet) IPv6 over MS/TP frame. The LoBAC payload (i.e., an IPv6 packet)
follows an encapsulation header stack. LoBAC is a subset of the follows an encapsulation header stack. LoBAC is a subset of the
LoWPAN encapsulation defined in [RFC4944] and extended by [RFC6282], LoWPAN encapsulation defined in [RFC4944] and extended by [RFC6282],
skipping to change at page 8, line 30 skipping to change at page 8, line 30
|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- This is the RECOMMENDED method of forming an IID for use in link-
local addresses, as it affords the most efficient header compression local addresses, as it affords the most efficient header compression
provided by the LOWPAN_IPHC [RFC6282] format specified in Section 10. provided by the LOWPAN_IPHC [RFC6282] format specified in Section 10.
A 64-bit privacy IID is RECOMMENDED for each forwardable address and A 64-bit random IID is RECOMMENDED for each globally scoped address
SHOULD be locally generated according to one of the methods cited in and SHOULD be locally generated according to one of the methods cited
Section 12. A node that generates a 64-bit privacy IID MUST register in Section 12. A node that generates a 64-bit random IID MUST
it with its local router(s) by sending a Neighbor Solicitation (NS) register it with its local router(s) by sending a Neighbor
message with the Address Registration Option (ARO) and process Solicitation (NS) message with the Address Registration Option (ARO)
Neighbor Advertisements (NA) according to [RFC6775]. 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 43 skipping to change at page 9, line 43
Length: This is the length of this option (including the type and Length: This is the length of this option (including the type and
length fields) in units of 8 octets. The value of this field is 1 length fields) in units of 8 octets. The value of this field is 1
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 SHOULD be sent to MS/TP Destination All IPv6 multicast packets MUST be sent to MS/TP Destination Address
Address 255 (broadcast) and filtered at the IPv6 layer. When 255 (broadcast) and filtered at the IPv6 layer. When represented as
represented as a 16-bit address in a compressed header (see a 16-bit address in a compressed header (see Section 10), it MUST be
Section 10), it MUST be formed by padding on the left with a zero: formed by padding on the left with a zero:
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 41 skipping to change at page 10, line 41
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
Forwardable addresses that contain IIDs generated using MS/TP node Globally scoped addresses that contain IIDs generated using MS/TP
addresses may expose a network to address scanning attacks. For this node addresses may expose a network to address scanning attacks. For
reason, it is RECOMMENDED that a different (but stable) IID be this reason, it is RECOMMENDED that a different (but stable) IID be
generated for each forwardable 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 MS/TP networks are by definition wired and not susceptible to casual
eavesdropping. By the same token, MS/TP nodes are stationary and eavesdropping. By the same token, MS/TP nodes are stationary and
correlation of activities or location tracking of individuals is correlation of activities or location tracking of individuals is
unlikely. 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 separately encoding the data and CRC32K fields would
skipping to change at page 13, line 28 skipping to change at page 13, line 28
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-6lo-privacy-considerations]
Thaler, D., "Privacy Considerations for IPv6 Adaptation
Layer Mechanisms", draft-ietf-6lo-privacy-
considerations-04 (work in progress), October 2016.
[IEEE.802.3] [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-2012, December 2012, Specifications", IEEE Std 802.3-2012, December 2012,
<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 26, line 22 skipping to change at page 27, line 22
Phone: +1 781 296 9722 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 Email: jpmartocci@sbcglobal.net
Email: jerald.p.martocci@jci.com
Carl Neilson Carl Neilson
Delta Controls, Inc. Delta Controls, Inc.
17850 56th Ave 17850 56th Ave
Surrey , BC V3S 1C7 Surrey , BC V3S 1C7
Canada Canada
Phone: +1 604 575 5913 Phone: +1 604 575 5913
Email: cneilson@deltacontrols.com Email: cneilson@deltacontrols.com
 End of changes. 19 change blocks. 
32 lines changed or deleted 40 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/