Internet Engineering Task Force (IETF) K. Lynn, Ed.
Request for Comments: 8163 Verizon Labs
Category: Standards Track J. Martocci
ISSN: 2070-1721 Johnson Controls
C. Neilson
Delta Controls
S. Donaldson
Honeywell
May 2017
Internet Engineering Task Force (IETF) K. Lynn, Ed.
Request for Comments: 8163 Verizon Labs
Category: Standards Track J. Martocci
ISSN: 2070-1721 Johnson Controls
C. Neilson
Delta Controls
S. Donaldson
Honeywell
May 2017
Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks
通过主从/令牌传递（MS/TP）网络传输IPv6
Abstract
摘要
Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.
主从/令牌传递（MS/TP）是RS-485物理层的一种介质访问控制方法，主要用于楼宇自动化网络。本规范定义了IPv6数据包传输的帧格式以及在MS/TP网络上形成链路本地和无状态自动配置IPv6地址的方法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8163.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8163.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Profile for IPv6 over MS/TP . . . . . . . . . . . . . . . . . 6
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 7
4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 8
5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 8
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9
7. IPv6 Link-Local Address . . . . . . . . . . . . . . . . . . . 10
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 11
10. Header Compression . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 15
Appendix B. Consistent Overhead Byte Stuffing (COBS) . . . . . . 17
Appendix C. Encoded CRC-32K (CRC32K) . . . . . . . . . . . . . . 20
Appendix D. Example 6LoBAC Frame Decode . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Profile for IPv6 over MS/TP . . . . . . . . . . . . . . . . . 6
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . 7
4. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 8
5. LoBAC Adaptation Layer . . . . . . . . . . . . . . . . . . . 8
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9
7. IPv6 Link-Local Address . . . . . . . . . . . . . . . . . . . 10
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 11
10. Header Compression . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Abstract MAC Interface . . . . . . . . . . . . . . . 15
Appendix B. Consistent Overhead Byte Stuffing (COBS) . . . . . . 17
Appendix C. Encoded CRC-32K (CRC32K) . . . . . . . . . . . . . . 20
Appendix D. Example 6LoBAC Frame Decode . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 primarily in building automation networks. This specification defines the frame format for transmission of IPv6 [RFC2460] packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. The general approach is to adapt elements of the 6LoWPAN specifications ([RFC4944], [RFC6282], and [RFC6775]) to constrained wired networks, as noted below.
主从/令牌传递（MS/TP）是RS-485[TIA-485-a]物理层的介质访问控制（MAC）协议，主要用于楼宇自动化网络。本规范定义了用于传输IPv6[RFC2460]数据包的帧格式，以及在MS/TP网络上形成链路本地和无状态自动配置IPv6地址的方法。一般方法是将6LoWPAN规范的元素（[RFC4944]、[RFC6282]和[RFC6775]）适应受约束的有线网络，如下所述。
An MS/TP device is typically based on a low-cost microcontroller with limited processing power and memory. These constraints, together with low data rates and a small MAC address space, are similar to those faced in 6LoWPAN networks. MS/TP differs significantly from 6LoWPAN in at least three respects: a) MS/TP devices are typically 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) the latest MS/TP specification provides support for large payloads, eliminating the need for fragmentation and reassembly below IPv6.
MS/TP设备通常基于处理能力和内存有限的低成本微控制器。这些限制，加上低数据速率和较小的MAC地址空间，与6LoWPAN网络中面临的限制类似。MS/TP与6LoWPAN至少在三个方面存在显著差异：a）MS/TP设备通常由电源供电，b）网段上的所有MS/TP设备都可以直接通信，因此不存在隐藏节点或网状路由问题，以及c）最新的MS/TP规范提供了对大型有效负载的支持，无需在IPv6下进行碎片化和重新组装。
The following sections provide a brief overview of MS/TP and then describe how to form IPv6 addresses and encapsulate IPv6 packets in MS/TP frames. This specification (subsequently referred to as "6LoBAC") includes a REQUIRED header compression mechanism that is based on LOWPAN_IPHC [RFC6282] and improves MS/TP link utilization.
以下各节简要概述了MS/TP，然后描述了如何在MS/TP帧中形成IPv6地址和封装IPv6数据包。本规范（随后称为“6LoBAC”）包括基于LOWPAN_IPHC[RFC6282]的所需报头压缩机制，并提高MS/TP链路利用率。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
ASHRAE: American Society of Heating, Refrigerating, and Air-
Conditioning Engineers <http://www.ashrae.org>
ASHRAE: American Society of Heating, Refrigerating, and Air-
Conditioning Engineers <http://www.ashrae.org>
BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol for Building Automation and Control Networks
BACnet：一种用于楼宇自动化和控制网络的ISO/ANSI/ASHRAE标准数据通信协议
CRC: Cyclic Redundancy Code
循环冗余码
MAC: Medium Access Control
媒体访问控制
MSDU: MAC Service Data Unit (MAC client data)
MSDU:MAC服务数据单元（MAC客户端数据）
MTU: Maximum Transmission Unit; the size of the largest data unit at the network-layer protocol that can be communicated in a single network transaction
MTU：最大传输单位；网络层协议中可在单个网络事务中通信的最大数据单元的大小
UART: Universal Asynchronous Transmitter/Receiver
通用异步发射机/接收机
This section provides a brief overview of MS/TP, as specified in Clause 9 of the ANSI/ASHRAE Standard 135-2016 [BACnet]. The latest version of [BACnet] integrates changes to legacy MS/TP (approved as [Addendum_an]) that provide support for larger frame sizes and improved error handling. [BACnet], Clause 9 also covers physical-layer deployment options.
本节简要概述了ANSI/ASHRAE标准135-2016[BACnet]第9条规定的MS/TP。[BACnet]的最新版本集成了对传统MS/TP（批准为[附录]）的更改，支持更大的帧大小和改进的错误处理。[BACnet]，第9条还包括物理层部署选项。
MS/TP is designed to enable multidrop networks over shielded twisted pair wiring. It can support network segments up to 1000 meters in 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 interface requires only a UART, an RS-485 [TIA-485-A] transceiver with a driver that can be disabled, and a 5 ms resolution timer. The MS/TP MAC is typically implemented in software.
MS/TP设计用于通过屏蔽双绞线实现多点网络。它可以以115.2 kbit/s的数据速率支持长度不超过1000米的网段，或者以较低的比特率支持长度不超过1200米的网段。MS/TP接口只需要一个UART、一个RS-485[TIA-485-a]收发器（带可禁用的驱动器）和一个5毫秒分辨率的定时器。MS/TP MAC通常在软件中实现。
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. Only an MS/TP master node can initiate the unsolicited transfer of data, and only when it holds the token. After sending at most a configured maximum number of data frames, a master node passes the token to the next master node (as determined by the MAC address). If present on the link, legacy MS/TP implementations (including any slave nodes) ignore the frame format defined in this specification.
[TIA-485-A]使用的差分信令需要无争用MAC。MS/TP使用令牌控制对多点总线的访问。只有MS/TP主节点可以发起未经请求的数据传输，并且仅当它持有令牌时。在最多发送配置的最大数据帧数后，主节点将令牌传递给下一个主节点（由MAC地址确定）。如果链路上存在，传统MS/TP实现（包括任何从属节点）将忽略本规范中定义的帧格式。
[BACnet], Clause 9 defines a range of Frame Type values used to designate frames that contain Data and Data CRC fields encoded using Consistent Overhead Byte Stuffing [COBS] (see Appendix B). The purpose of COBS encoding is to eliminate preamble sequences from the Encoded Data and Encoded CRC-32K fields. The Encoded Data field is covered by a 32-bit CRC [CRC32K] (see Appendix C) that is also COBS encoded.
[BACnet]，第9条定义了一系列帧类型值，用于指定包含使用一致开销字节填充[COBS]编码的数据和数据CRC字段的帧（见附录B）。COBS编码的目的是从编码数据和编码CRC-32K字段中消除前导序列。编码数据字段由32位CRC[CRC32K]（见附录C）覆盖，该CRC[CRC32K]也是COBS编码的。
MS/TP COBS-encoded frames have the following format:
MS/TP COBS编码帧具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x55 | 0xFF | Frame Type | DA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA | Length (MS octet first) | Header CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Encoded Data (2 - 1506 octets) .
. .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Encoded CRC-32K (5 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | optional 0xFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x55 | 0xFF | Frame Type | DA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA | Length (MS octet first) | Header CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Encoded Data (2 - 1506 octets) .
. .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Encoded CRC-32K (5 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | optional 0xFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MS/TP COBS-Encoded Frame Format
图1:MS/TP COBS编码帧格式
MS/TP COBS-encoded frame fields are defined as follows:
MS/TP COBS编码的帧字段定义如下：
Preamble two octet preamble: 0x55, 0xFF Frame Type one octet Destination Address one octet address Source Address one octet address Length two octets, most significant octet first Header CRC one octet Encoded Data 2 - 1506 octets (see Section 4 and Appendix B) Encoded CRC-32K five octets (see Appendix C) (pad) (optional) at most one octet of trailer: 0xFF
前导码两个八位字节前导码：0x55，0xFF帧类型一个八位字节目的地址一个八位字节地址源地址一个八位字节地址长度两个八位字节，最高有效八位字节第一个头CRC一个八位字节编码数据2-1506个八位字节（见第4节和附录B）编码CRC-32K五个八位字节（见附录C）（pad）（可选）拖车最多一个八位字节：0xFF
The Frame Type is used to distinguish between different types of MAC frames. The types relevant to this specification (in decimal) are:
帧类型用于区分不同类型的MAC帧。与本规范相关的类型（十进制）为：
0 Token 1 Poll For Master 2 Reply To Poll For Master 3 Test_Request 4 Test_Response ... 34 IPv6 over MS/TP (LoBAC) Encapsulation
0主机2的令牌1轮询答复主机3测试请求4测试响应的轮询。。。34 IPv6 over MS/TP（LoBAC）封装
Frame Types 8 - 31 and 35 - 127 are reserved for assignment by ASHRAE. Frame Types 32 - 127 designate COBS-encoded frames that convey Encoded Data and Encoded CRC-32K fields. See Section 2 for additional details.
帧类型8-31和35-127保留给ASHRAE分配。帧类型32-127指定COBS编码的帧，这些帧传送编码数据和编码CRC-32K字段。更多详细信息，请参见第2节。
The Destination and Source Addresses are each one octet in length. See Section 3 for additional details.
目标地址和源地址的长度均为一个八位字节。更多详细信息，请参见第3节。
For COBS-encoded frames, the Length field indicates the size of the [COBS] Encoded Data field in octets, plus three. (This adjustment is required in order for legacy MS/TP devices to ignore COBS-encoded frames.) See Section 4 and the Appendices for additional details.
对于COBS编码的帧，长度字段表示[COBS]编码数据字段的大小（以八位字节为单位），加上三位字节。（为了使传统MS/TP设备忽略COBS编码的帧，需要进行此调整。）有关更多详细信息，请参阅第4节和附录。
The Header CRC field covers the Frame Type, Destination Address, Source Address, and Length fields. The Header CRC generation and check procedures are specified in [BACnet], Annex G.1.
标头CRC字段包括帧类型、目标地址、源地址和长度字段。[BACnet]附录G.1中规定了标头CRC生成和检查程序。
Use of the optional 0xFF trailer octet is discussed in [BACnet], Clause 9.
[BACnet]第9条讨论了可选0xFF拖车八位字节的使用。
The main goals of this specification are a) to enable IPv6 directly on wired end devices in building automation and control networks by leveraging existing standards to the greatest extent possible, and b) to co-exist with legacy MS/TP implementations. Co-existence allows MS/TP networks to be incrementally upgraded to support IPv6.
本规范的主要目标是a）通过最大程度地利用现有标准，在楼宇自动化和控制网络中的有线终端设备上直接启用IPv6，以及b）与传统MS/TP实现共存。共存允许MS/TP网络增量升级以支持IPv6。
In order to co-exist with legacy devices, no changes are permitted to the MS/TP addressing modes, frame header format, control frames, or Master Node state machine as specified in [BACnet], Clause 9.
为了与传统设备共存，不允许更改[BACnet]第9条中规定的MS/TP寻址模式、帧头格式、控制帧或主节点状态机。
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 values that designate COBS-encoded data frames.
ASHRAE已将MS/TP帧类型值指定为34，以指示IPv6 over MS/TP（LoBAC）封装。这属于指定COBS编码数据帧的值范围。
[BACnet], Clause 9 specifies mandatory-to-implement features of MS/TP devices. For example, it is mandatory that all MS/TP nodes respond to a Test_Request with a Test_Response frame. All MS/TP master nodes must implement the Master Node state machine and handle Token, Poll For 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.
[BACnet]，第9条规定了实现MS/TP设备功能的强制性要求。例如，所有MS/TP节点必须使用测试响应帧响应测试请求。所有MS/TP主节点必须实现主节点状态机并处理令牌、主节点轮询和主控制帧应答轮询。6LoBAC节点是MS/TP主节点，实现能够处理COBS编码帧的接收帧状态机。
6LoBAC nodes must support a data rate of 115.2 kbit/s and may support lower data rates as specified in [BACnet], Clause 9. The method of selecting the data rate is outside the scope of this specification.
6LoBAC节点必须支持115.2 kbit/s的数据速率，并可支持[BACnet]第9条规定的较低数据速率。选择数据速率的方法不在本规范的范围内。
The following constants are used by the Receive Frame state machine.
接收帧状态机使用以下常量。
Nmin_COBS_length The minimum valid Length value of any LoBAC-encapsulated frame: 5
Nmin_COBS_length任何LoBAC封装帧的最小有效长度值：5
Nmax_COBS_length The maximum valid Length value of any LoBAC-encapsulated frame: 1509
Nmax_COBS_length任何LoBAC封装帧的最大有效长度值：1509
The following parameters are used by the Master Node state machine.
主节点状态机使用以下参数。
Nmax_info_frames The default maximum number of information frames the node may send before it must pass the token: 1
Nmax_info_frames节点在必须通过令牌之前可以发送的默认最大信息帧数：1
Nmax_master The default highest allowable address for master nodes: 127
Nmax_master主节点的默认最高允许地址：127
The mechanisms for setting parameters or monitoring MS/TP performance are outside the scope of this specification.
设置参数或监控MS/TP性能的机制不在本规范的范围内。
MS/TP node (MAC) addresses are one octet in length and are assigned dynamically. The method of assigning MAC addresses is outside the scope of this specification. However, each MS/TP node on the link MUST have a unique address in order to ensure correct MAC operation.
MS/TP节点（MAC）地址的长度为一个八位字节，并动态分配。分配MAC地址的方法不在本规范的范围内。但是，链路上的每个MS/TP节点必须具有唯一的地址，以确保正确的MAC操作。
[BACnet], Clause 9 specifies that addresses 0 through 127 are valid for master nodes. The method specified in Section 6 for creating a MAC-address-derived Interface Identifier (IID) ensures that an IID of all zeros can never be generated.
[BACnet]，第9条规定地址0到127对主节点有效。第6节中指定的用于创建MAC地址派生接口标识符（IID）的方法确保永远不会生成全零的IID。
A Destination Address of 255 (all nodes) indicates a MAC-layer broadcast. MS/TP does not support multicast; therefore, all IPv6 multicast packets MUST be broadcast at the MAC layer and filtered at the IPv6 layer. A Source Address of 255 MUST NOT be used.
255（所有节点）的目标地址表示MAC层广播。MS/TP不支持多播；因此，所有IPv6多播数据包必须在MAC层广播，并在IPv6层过滤。不得使用255的源地址。
Hosts learn IPv6 prefixes via router advertisements according to [RFC4861].
主机根据[RFC4861]通过路由器广告学习IPv6前缀。
Upon transmission, the network-layer MTU is formatted according to 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. [BACnet], Clause 9 supports MSDUs up to 2032 octets in length.
在传输时，网络层MTU根据第5节进行格式化，并成为MAC服务数据单元（MSDU）。然后由MS/TP对MSDU进行COBS编码。接收时，步骤颠倒。[BACnet]，第9条支持长度不超过2032个八位字节的MSDU。
IPv6 [RFC2460] requires that every link in an internet have an MTU of 1280 octets or greater. Additionally, a node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. This specification defines an MTU length of at least 1280 octets and at most 1500 octets. Support for an MTU length of 1500 octets is RECOMMENDED.
IPv6[RFC2460]要求互联网中的每条链路都有1280个八位字节或更大的MTU。此外，节点必须能够接受碎片数据包，在重新组装后，碎片数据包的大小可达1500个八位字节。本规范规定MTU长度至少为1280个八位字节，最多为1500个八位字节。建议支持1500个八位字节的MTU长度。
This section specifies an adaptation layer to support compressed IPv6 headers as specified in Section 10. IPv6 header compression MUST be implemented on all 6LoBAC nodes. Implementations MAY also support Generic Header Compression [RFC7400] for transport layer headers.
本节指定了一个适配层，以支持第10节中指定的压缩IPv6头。IPv6报头压缩必须在所有6LoBAC节点上实现。实现还可以支持传输层头的通用头压缩[RFC7400]。
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 packet) follows an encapsulation header stack. LoBAC is a subset of the LoWPAN encapsulation defined in [RFC4944], as updated by [RFC6282], so the use of "LOWPAN" in literals below is intentional. The primary difference between LoWPAN and LoBAC encapsulation is omission of the Mesh, Broadcast, Fragmentation, and LOWPAN_HC1 headers in the latter.
本节中定义的LoBAC封装格式描述了IPv6 over MS/TP帧的MSDU。LoBAC有效负载（即IPv6数据包）遵循封装头堆栈。LoBAC是[RFC4944]中定义的LoWPAN封装的子集，由[RFC6282]更新，因此在下面的文本中使用“LoWPAN”是有意的。LoWPAN和LoBAC封装之间的主要区别在于后者省略了网格、广播、碎片和LoWPAN_HC1头。
All LoBAC-encapsulated datagrams transmitted over MS/TP are prefixed by an encapsulation header stack consisting of a Dispatch value followed by zero or more header fields. The only sequence currently defined for LoBAC is the LOWPAN_IPHC header followed by payload, as shown below:
通过MS/TP传输的所有LoBAC封装数据报都以封装头堆栈作为前缀，该堆栈由一个分派值和零个或多个头字段组成。目前为LoBAC定义的唯一序列是LOWPAN_IPHC标头，后跟有效负载，如下所示：
+---------------+---------------+------...-----+
| IPHC Dispatch | IPHC Header | Payload |
+---------------+---------------+------...-----+
+---------------+---------------+------...-----+
| IPHC Dispatch | IPHC Header | Payload |
+---------------+---------------+------...-----+
Figure 2: A LoBAC-Encapsulated LOWPAN_IPHC Compressed IPv6 Datagram
图2:LoBAC封装的LOWPAN_IPHC压缩IPv6数据报
The Dispatch value is treated as an unstructured namespace. Only a single pattern is used to represent current LoBAC functionality.
分派值被视为非结构化命名空间。只有一个模式用于表示当前的LoBAC功能。
Pattern Header Type
+------------+-----------------------------------------------------+
| 01 1xxxxx | LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] |
+------------+-----------------------------------------------------+
Pattern Header Type
+------------+-----------------------------------------------------+
| 01 1xxxxx | LOWPAN_IPHC - LOWPAN_IPHC compressed IPv6 [RFC6282] |
+------------+-----------------------------------------------------+
Figure 3: LoBAC Dispatch Value Bit Pattern
图3:LoBAC分派值位模式
Other IANA-assigned 6LoWPAN Dispatch values do not apply to 6LoBAC unless otherwise specified.
除非另有规定，否则IANA分配的其他6LoWPAN分派值不适用于6LoBAC。
This section defines how to obtain an IPv6 Interface Identifier. This specification distinguishes between two types of IIDs, MAC-address-derived and semantically opaque.
本节定义如何获取IPv6接口标识符。本规范区分两种类型的IID，MAC地址派生和语义不透明。
A MAC-address-derived IID is the RECOMMENDED type for use in forming a link-local address, as it affords the most efficient header compression provided by the LOWPAN_IPHC [RFC6282] format specified in Section 10. The general procedure for creating a MAC-address-derived IID is described in Appendix A of [RFC4291], "Creating Modified EUI-64 Format Interface Identifiers", as updated by [RFC7136].
MAC地址派生的IID是用于形成链路本地地址的推荐类型，因为它提供了第10节规定的LOWPAN_IPHC[RFC6282]格式提供的最有效的报头压缩。[RFC4291]“创建修改的EUI-64格式接口标识符”的附录a中描述了创建MAC地址派生IID的一般过程，并由[RFC7136]更新。
The Interface Identifier for link-local addresses SHOULD be formed by concatenating the node's 8-bit MS/TP MAC address to the seven octets 0x00, 0x00, 0x00, 0xFF, 0xFE, 0x00, and 0x00. For example, an MS/TP MAC address of hexadecimal value 0x4F results in the following IID:
链路本地地址的接口标识符应通过将节点的8位MS/TP MAC地址连接到七个八位字节0x00、0x00、0x00、0xFF、0xFE、0x00和0x00来形成。例如，十六进制值0x4F的MS/TP MAC地址会导致以下IID：
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000011111111|1111111000000000|0000000001001111|
+----------------+----------------+----------------+----------------+
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000011111111|1111111000000000|0000000001001111|
+----------------+----------------+----------------+----------------+
A semantically opaque IID having 64 bits of entropy is RECOMMENDED for each globally scoped address and MAY be locally generated 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 its local router(s) by sending a Neighbor Solicitation (NS) message with the Address Registration Option (ARO) and process Neighbor Advertisements (NAs) according to [RFC6775].
对于每个全局作用域地址，建议使用具有64位熵的语义不透明IID，并且可以根据第12节中引用的方法之一在本地生成IID。生成64位语义不透明IID的节点必须通过发送带有地址注册选项（ARO）的邻居请求（NS）消息，向其本地路由器注册IID，并根据[RFC6775]处理邻居播发（NAs）。
An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an MS/TP interface MUST have a length of 64 bits.
用于MS/TP接口的无状态自动配置[RFC4862]的IPv6地址前缀的长度必须为64位。
The IPv6 link-local address [RFC4291] for an MS/TP interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
MS/TP接口的IPv6链路本地地址[RFC4291]是通过将接口标识符（如上所述）附加到前缀FE80:：/64来形成的。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
The address resolution procedure for mapping IPv6 non-multicast addresses into MS/TP MAC-layer addresses follows the general description in Section 7.2 of [RFC4861], unless otherwise specified.
除非另有规定，否则将IPv6非多播地址映射到MS/TP MAC层地址的地址解析过程遵循[RFC4861]第7.2节中的一般说明。
The Source/Target Link-Layer Address option has the following form when the addresses are 8-bit MS/TP MAC-layer (node) addresses.
当地址为8位MS/TP MAC层（节点）地址时，源/目标链路层地址选项具有以下形式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | MS/TP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Padding (all zeros) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | MS/TP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Padding (all zeros) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option fields:
选项字段：
Type:
类型：
1: for Source Link-Layer address.
1：用于源链接层地址。
2: for Target Link-Layer address.
2：用于目标链路层地址。
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 for 8-bit MS/TP MAC addresses.
长度：此选项的长度（包括类型和长度字段），以8个八位字节为单位。对于8位MS/TP MAC地址，此字段的值为1。
MS/TP Address: The 8-bit address in canonical bit order [RFC2469]. This is the unicast address the interface currently responds to.
MS/TP地址：标准位顺序的8位地址[RFC2469]。这是接口当前响应的单播地址。
All IPv6 multicast packets MUST be sent to MS/TP Destination Address 255 (broadcast) and filtered at the IPv6 layer. When represented as a 16-bit address in a compressed header (see Section 10), it MUST be formed by padding on the left with a zero octet:
所有IPv6多播数据包必须发送到MS/TP目标地址255（广播），并在IPv6层进行过滤。当在压缩头中表示为16位地址时（参见第10节），必须通过在左侧填充零八位字节来形成：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0xFF |
+-+-+-+-+-+-+-+-+---------------+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0xFF |
+-+-+-+-+-+-+-+-+---------------+
6LoBAC REQUIRES LOWPAN_IPHC IPv6 compression, which is specified in [RFC6282] and included herein by reference. This section will simply identify substitutions that should be made when interpreting the text of [RFC6282].
6LoBAC需要LOWPAN_IPHC IPv6压缩，该压缩在[RFC6282]中规定，并通过引用包含在本文中。本节仅确定在解释[RFC6282]文本时应进行的替换。
In general, the following substitutions should be made:
一般而言，应进行以下替换：
- Replace instances of "6LoWPAN" with "MS/TP network"
- 将“6LoWPAN”的实例替换为“MS/TP网络”
- Replace instances of "IEEE 802.15.4 address" with "MS/TP address"
- 将“IEEE 802.15.4地址”的实例替换为“MS/TP地址”
When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short address"), it MUST be formed by padding the MS/TP address to the left with a zero octet:
当调用16位地址（即IEEE 802.15.4“短地址”）时，必须通过在MS/TP地址左侧填充零八位组来形成：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | MS/TP address |
+-+-+-+-+-+-+-+-+---------------+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | MS/TP address |
+-+-+-+-+-+-+-+-+---------------+
If LOWPAN_IPHC compression [RFC6282] is used with context, the router(s) directly attached to the MS/TP segment MUST disseminate the 6LoWPAN Context Option (6CO) according to Section 7.2 of [RFC6775].
如果LOWPAN_IPHC压缩[RFC6282]与上下文一起使用，则直接连接到MS/TP段的路由器必须根据[RFC6775]第7.2节传播6LoWPAN上下文选项（6CO）。
This document uses values previously reserved by [RFC4944] and [RFC6282]; it does not require any IANA actions.
本文件使用[RFC4944]和[RFC6282]先前保留的值；它不需要任何IANA操作。
See [RFC8065] for a general discussion of privacy threats faced by constrained nodes.
有关受约束节点面临的隐私威胁的一般性讨论，请参见[RFC8065]。
[RFC8065] makes a distinction between "stable" and "temporary" addresses. The former are long-lived and typically advertised by servers. The latter are typically used by clients and SHOULD be changed frequently to mitigate correlation of activities over time. Nodes that engage in both activities SHOULD support simultaneous use of multiple addresses per device.
[RFC8065]区分了“稳定”和“临时”地址。前者寿命长，通常由服务器发布广告。后者通常由客户端使用，应经常更改，以减少活动随时间的相关性。参与这两个活动的节点应支持每个设备同时使用多个地址。
Globally scoped addresses that contain MAC-address-derived IIDs may expose a network to address-scanning attacks. For this reason, it is RECOMMENDED that a 64-bit semantically opaque IID be generated for each globally scoped address in use according to, for example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217].
包含MAC地址派生IID的全局作用域地址可能会使网络暴露于地址扫描攻击。因此，建议根据例如[RFC3315]、[RFC3972]、[RFC4941]、[RFC5535]或[RFC7217]为使用中的每个全局作用域地址生成64位语义不透明IID。
[BACnet] ASHRAE, "BACnet-A Data Communication Protocol for Building Automation and Control Networks", ANSI/ASHRAE Standard 135-2016, January 2016, <http://www.techstreet.com/ashrae/standards/ ashrae-135-2016?product_id=1918140#jumps>.
[BACnet]ASHRAE，“楼宇自动化和控制网络的BACnet-A数据通信协议”，ANSI/ASHRAE标准135-2016，2016年1月<http://www.techstreet.com/ashrae/standards/ ashrae-135-2016？产品id=1918140。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 3972，DOI 10.17487/RFC3972，2005年3月<http://www.rfc-editor.org/info/rfc3972>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI 10.17487/RFC5535, June 2009, <http://www.rfc-editor.org/info/rfc5535>.
[RFC5535]Bagnulo，M.，“基于哈希的地址（HBA）”，RFC 5535，DOI 10.17487/RFC55352009年6月<http://www.rfc-editor.org/info/rfc5535>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]Hui，J.，Ed.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，DOI 10.17487/RFC6282，2011年9月<http://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]Shelby，Z.，Ed.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功率无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 6775，DOI 10.17487/RFC67752012年11月<http://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，DOI 10.17487/RFC7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<http://www.rfc-editor.org/info/rfc7217>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, <http://www.rfc-editor.org/info/rfc7400>.
[RFC7400]Bormann，C.，“6LoWPAN GHC：低功率无线个人区域网络（6LoWPANs）上IPv6的通用报头压缩”，RFC 7400，DOI 10.17487/RFC7400，2014年11月<http://www.rfc-editor.org/info/rfc7400>.
[Addendum_an] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication Protocol for Building Automation and Control Networks", ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to ANSI/ASHRAE Standard 135-2012, July 2014, <https://www.ashrae.org/File%20Library/docLib/StdsAddenda/ 07-31-2014_135_2012_an_at_au_av_aw_ax_az_Final.pdf>.
【附录】ANSI/ASHRAE，“附录：BACnet——楼宇自动化和控制网络的数据通信协议”，ANSI/ASHRAE附录an、at、au、av、aw、ax和az至ANSI/ASHRAE标准135-2012，2014年7月<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 Stuffing", IEEE/ACM Transactions on Networking, Volume 7, Issue 2, DOI 10.1109/90.769765, April 1999, <http://www.stuartcheshire.org/papers/COBSforToN.pdf>.
[COBS]Cheshire，S.和M.Baker，“一致开销字节填充”，IEEE/ACM网络事务，第7卷，第2期，DOI 10.1109/90.769765，1999年4月<http://www.stuartcheshire.org/papers/COBSforToN.pdf>.
[CRC32K] Koopman, P., "32-Bit Cyclic Redundancy Codes for Internet Applications", Proceedings of the International Conference on Dependable Systems and Networks (DSN 2002), June 2002, <https://users.ece.cmu.edu/~koopman/networks/dsn02/ dsn02_koopman.pdf>.
[CRC32K]Koopman，P.，“互联网应用中的32位循环冗余码”，可靠系统和网络国际会议记录（DSN 2002），2002年6月<https://users.ece.cmu.edu/~koopman/networks/dsn02/dsn02\u koopman.pdf>。
[IEEE.802.3] IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2015, DOI 10.1109/IEEESTD.2016.7428776, <http://standards.ieee.org/getieee802/ download/802.3-2015.zip>.
[IEEE.802.3]IEEE，“以太网的IEEE标准”，IEEE 802.3-2015，DOI 10.1109/IEEESTD.2016.7428776<http://standards.ieee.org/getieee802/ 下载/802.3-2015.zip>。
[RFC2469] Narten, T. and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, DOI 10.17487/RFC2469, December 1998, <http://www.rfc-editor.org/info/rfc2469>.
[RFC2469]Narten，T.和C.Burton，“链路层地址规范排序的注意事项”，RFC 2469，DOI 10.17487/RFC2469，1998年12月<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>.
[RFC8065]Thaler，D.，“IPv6适配层机制的隐私考虑”，RFC 8065，DOI 10.17487/RFC8065，2017年2月<http://www.rfc-editor.org/info/rfc8065>.
[TIA-485-A] TIA, "Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems", TIA-485-A (Revision of TIA-485), March 2003, <https://global.ihs.com/ doc_detail.cfm?item_s_key=00032964>.
[TIA-485-A]TIA，“用于平衡数字多点系统的发电机和接收器的电气特性”，TIA-485-A（TIA-485的修订版），2003年3月<https://global.ihs.com/ doc_detail.cfm？项目编号=00032964>。
This Appendix is informative and not part of the standard.
本附录仅供参考，不属于本标准的一部分。
[BACnet], Clause 9 provides support for MAC-layer clients through its SendFrame and ReceivedDataNoReply procedures. However, it does not define a network-protocol independent abstract interface for the MAC. This is provided below as an aid to implementation.
[BACnet]，第9条通过其SendFrame和ReceivedDataOreply过程为MAC层客户端提供支持。但是，它没有为MAC定义独立于网络协议的抽象接口。下文提供了这一信息，以帮助实施。
This primitive defines the transfer of data from a MAC client entity to a single peer entity or multiple peer entities in the case of a broadcast address.
该原语定义了在广播地址的情况下，从MAC客户端实体到单个对等实体或多个对等实体的数据传输。
The semantics of the primitive are as follows:
原语的语义如下所示：
MA-DATA.request ( destination_address, source_address, data, type )
MA-DATA.request（目标地址、源地址、数据、类型）
The 'destination_address' parameter may specify either an individual or a broadcast MAC entity address. It must contain sufficient information to create the Destination Address field (see Section 1.3) that is prepended to the frame by the local MAC sublayer entity. The 'source_address' parameter, if present, must specify an individual MAC address. If the source_address parameter is omitted, the local MAC sublayer entity will insert a value associated with that entity.
“destination_address”参数可以指定单个或广播MAC实体地址。它必须包含足够的信息来创建目标地址字段（见第1.3节），该字段由本地MAC子层实体预先添加到帧中。“源地址”参数（如果存在）必须指定单个MAC地址。如果省略source_address参数，则本地MAC子层实体将插入与该实体关联的值。
The 'data' parameter specifies the MAC service data unit (MSDU) to be transferred by the MAC sublayer entity. There is sufficient information associated with the MSDU for the MAC sublayer entity to determine the length of the data unit.
“data”参数指定MAC子层实体要传输的MAC服务数据单元（MSDU）。MAC子层实体有足够的与MSDU关联的信息来确定数据单元的长度。
The 'type' parameter specifies the value of the MS/TP Frame Type field that is prepended to the frame by the local MAC sublayer entity.
“type”参数指定本地MAC子层实体在帧前面添加的MS/TP帧类型字段的值。
This primitive is generated by the MAC client entity whenever data shall be transferred to a peer entity or entities. This can be in response to a request from higher protocol layers or from data generated internally to the MAC client, such as a Token frame.
每当数据传输到对等实体时，MAC客户端实体就会生成该原语。这可以响应来自更高协议层的请求，或者来自MAC客户端内部生成的数据，例如令牌帧。
Receipt of this primitive will cause the MAC entity to insert all MAC-specific fields, including Destination Address, Source Address, Frame Type, and any fields that are unique to the particular media access method, and pass the properly formed frame to the lower protocol layers for transfer to the peer MAC sublayer entity or entities.
接收此原语将导致MAC实体插入所有MAC特定字段，包括目标地址、源地址、帧类型和特定媒体访问方法特有的任何字段，并将正确形成的帧传递给较低的协议层，以便传输到对等MAC子层实体。
This primitive defines the transfer of data from the MAC sublayer entity to the MAC client entity or entities in the case of a broadcast address.
该原语定义了在广播地址的情况下，从MAC子层实体到MAC客户端实体的数据传输。
The semantics of the primitive are as follows:
原语的语义如下所示：
MA-DATA.indication ( destination_address, source_address, data, type )
MA-DATA.indication（目的地地址、源地址、数据、类型）
The 'destination_address' parameter may be either an individual or a broadcast address as specified by the Destination Address field of the incoming frame. The 'source_address' parameter is an individual address as specified by the Source Address field of the incoming frame.
“destination_address”参数可以是单个地址，也可以是由传入帧的destination address字段指定的广播地址。“source_address”参数是由传入帧的source address字段指定的单个地址。
The 'data' parameter specifies the MAC service data unit (MSDU) as received by the local MAC entity. There is sufficient information associated with the MSDU for the MAC sublayer client to determine the length of the data unit.
“data”参数指定本地MAC实体接收的MAC服务数据单元（MSDU）。MAC子层客户端有足够的与MSDU关联的信息来确定数据单元的长度。
The 'type' parameter is the value of the MS/TP Frame Type field of the incoming frame.
“type”参数是传入帧的MS/TP Frame type字段的值。
The MA_DATA.indication is passed from the MAC sublayer entity to the 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. Such frames are reported only if they are validly formed and received without error, and their Destination Address designates the local MAC entity. Frames destined for the MAC Control sublayer are not passed to the MAC client.
MA_DATA.indication从MAC子层实体传递到MAC客户端实体，以指示帧到达目的地为MAC客户端的本地MAC子层实体。只有当这些帧被有效地形成并且无误地接收，并且它们的目的地地址指定本地MAC实体时，才报告这些帧。发送给MAC控制子层的帧不会传递给MAC客户端。
The effect of receipt of this primitive by the MAC client is unspecified.
MAC客户端接收此原语的效果未指定。
Appendix B. Consistent Overhead Byte Stuffing (COBS)
附录B.一致开销字节填充（COBS）
This Appendix is informative and not part of the standard.
本附录仅供参考，不属于本标准的一部分。
[BACnet], Clause 9 corrects a long-standing issue with the MS/TP specification, namely that preamble sequences were not escaped whenever they appeared in the Data or Data CRC fields. In rare cases, this resulted in dropped frames due to loss-of-frame synchronization. The solution is to encode the Data and 32-bit Data CRC fields before transmission using Consistent Overhead Byte Stuffing [COBS] and decode these fields upon reception.
[BACnet]，第9条纠正了MS/TP规范的一个长期存在的问题，即前导序列在数据或数据CRC字段中出现时不会转义。在极少数情况下，这会由于丢失帧同步而导致丢失帧。解决方案是在传输前使用一致开销字节填充[COBS]对数据和32位数据CRC字段进行编码，并在接收时对这些字段进行解码。
COBS is a run-length encoding method that nominally removes '0x00' octets from its input. Any selected octet value may be removed by XOR'ing that value with each octet of the COBS output. [BACnet], Clause 9 specifies the preamble octet '0x55' for removal.
COBS是一种运行长度编码方法，名义上从输入中删除“0x00”八位字节。任何选定的八位字节值都可以通过将该值与COBS输出的每个八位字节进行异或来删除。[BACnet]，第9条规定删除前导八位组“0x55”。
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 described in [COBS].
COBS的最小开销是每个编码字段一个八位字节。如[COBS]中所述，长字段中的最坏情况开销限定为每254个八位组一个。
Frame encoding proceeds logically in two passes. The Encoded Data 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 Encoded CRC-32K field is then prepared by calculating a CRC-32K over the Encoded Data field and formatting it for transmission as described in Appendix C. The combined length of these fields, minus two octets for compatibility with legacy MS/TP devices, is placed in the MS/TP header Length field before transmission.
帧编码逻辑上分两次进行。编码数据字段是通过将MSDU通过COBS编码器并将前导八位字节“0x55”与输出的每个八位字节异或而准备的。然后，通过计算编码数据字段上的CRC-32K并按照附录C中所述对其进行格式化以进行传输来准备编码的CRC-32K字段。这些字段的组合长度减去两个八位字节以与传统MS/TP设备兼容，在传输之前放入MS/TP报头长度字段。
Example COBS encoder and decoder functions are shown below for illustration. Complete examples of use and test vectors are provided in [BACnet], Annex T.
示例COBS编码器和解码器功能如下所示，以供说明。[BACnet]附录T中提供了使用和测试向量的完整示例。
<CODE BEGINS>
<代码开始>
#include <stddef.h>
#include <stdint.h>
#include <stddef.h>
#include <stdint.h>
/*
* Encodes 'length' octets of data located at 'from' and
* writes one or more COBS code blocks at 'to', removing any
* 'mask' octets that may be present in the encoded data.
* Returns the length of the encoded data.
*/
/*
* Encodes 'length' octets of data located at 'from' and
* writes one or more COBS code blocks at 'to', removing any
* 'mask' octets that may be present 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,
uint8_t mask)
{
size_t code_index = 0;
size_t read_index = 0;
size_t write_index = 1;
uint8_t code = 1;
uint8_t data, last_code;
size_t
cobs_encode (uint8_t *to, const uint8_t *from, size_t length,
uint8_t mask)
{
size_t code_index = 0;
size_t read_index = 0;
size_t write_index = 1;
uint8_t code = 1;
uint8_t data, last_code;
while (read_index < length) {
data = from[read_index++];
/*
* In the case of encountering a non-zero octet in the data,
* simply copy input to output and increment the code octet.
*/
if (data != 0) {
to[write_index++] = data ^ mask;
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;
}
/*
* If the last chunk contains exactly 254 non-zero octets, then
* this exception is handled above (and the returned length must
* be adjusted). Otherwise, encode the last chunk normally, as if
while (read_index < length) {
data = from[read_index++];
/*
* In the case of encountering a non-zero octet in the data,
* simply copy input to output and increment the code octet.
*/
if (data != 0) {
to[write_index++] = data ^ mask;
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;
}
/*
* If the last chunk contains exactly 254 non-zero octets, then
* this exception is handled above (and the 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;
* 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 <stdint.h>
#include <stddef.h>
#include <stdint.h>
/*
* Decodes 'length' octets of data located at 'from' and
* writes the original client data at 'to', restoring any
* 'mask' octets that may present in the encoded data.
* Returns the length of the encoded data or zero if error.
*/
size_t
cobs_decode (uint8_t *to, const uint8_t *from, size_t length,
uint8_t mask)
{
size_t read_index = 0;
size_t write_index = 0;
uint8_t code, last_code;
/*
* Decodes 'length' octets of data located at 'from' and
* writes the original client data at 'to', restoring any
* 'mask' octets that may present in the encoded data.
* Returns the length of the encoded data or zero if error.
*/
size_t
cobs_decode (uint8_t *to, const uint8_t *from, size_t length,
uint8_t mask)
{
size_t read_index = 0;
size_t write_index = 0;
uint8_t code, last_code;
while (read_index < length) {
code = from[read_index] ^ mask;
last_code = code;
/*
* Sanity check the encoding to prevent the while() loop below
* from overrunning the output buffer.
*/
if (read_index + code > length)
return 0;
while (read_index < length) {
code = from[read_index] ^ mask;
last_code = code;
/*
* Sanity check the encoding to prevent the while() loop below
* from overrunning the output buffer.
*/
if (read_index + code > length)
return 0;
read_index++;
while (--code > 0)
to[write_index++] = from[read_index++] ^ mask;
/*
* Restore the implicit zero at the end of each decoded block
* except when it contains exactly 254 non-zero octets or the
* end of data has been reached.
*/
if ((last_code != 255) && (read_index < length))
to[write_index++] = 0;
read_index++;
while (--code > 0)
to[write_index++] = from[read_index++] ^ mask;
/*
* Restore the implicit zero at the end of each decoded block
* except when it contains exactly 254 non-zero octets or the
* end of data has been reached.
*/
if ((last_code != 255) && (read_index < length))
to[write_index++] = 0;
}
return write_index;
}
}
return write_index;
}
<CODE ENDS>
<代码结束>
Appendix C. Encoded CRC-32K (CRC32K)
附录C编码CRC-32K（CRC32K）
This Appendix is informative and not part of the standard.
本附录仅供参考，不属于本标准的一部分。
Extending the payload of MS/TP to 1500 octets requires upgrading the Data CRC from 16 bits to 32 bits. P. Koopman has authored several papers on evaluating CRC polynomials for network applications. In [CRC32K], he surveyed the entire 32-bit polynomial space and noted some that exceed the [IEEE.802.3] polynomial in performance. [BACnet], Clause 9 specifies one of these, the CRC-32K (Koopman) polynomial.
将MS/TP的有效负载扩展到1500个八位字节需要将数据CRC从16位升级到32位。P.Koopman撰写了几篇关于评估网络应用中的CRC多项式的论文。在[CRC32K]中，他调查了整个32位多项式空间，并注意到一些在性能上超过[IEEE.802.3]多项式。[BACnet]，第9条规定了其中之一，即CRC-32K（Koopman）多项式。
The specified use of the calc_crc32K() function is as follows. Before a frame is transmitted, 'crc_value' is initialized to all ones. After passing each octet of the [COBS] Encoded Data field through the function, the ones complement of the resulting 'crc_value' is arranged in LSB-first order and is itself [COBS] encoded. The length of the resulting Encoded CRC-32K field is always five octets.
calc_crc32K（）函数的指定用法如下所示。在传输帧之前，“crc_值”初始化为所有值。通过函数传递[COBS]编码数据字段的每个八位组后，生成的“crc_值”的补位按LSB一阶排列，并且其本身是[COBS]编码的。生成的编码CRC-32K字段的长度始终为五个八位字节。
Upon reception of a frame, 'crc_value' is initialized to all ones. The octets of the Encoded Data field are accumulated by the calc_crc32K() function before decoding. The Encoded CRC-32K field is then decoded and the resulting four octets are accumulated by the calc_crc32K() function. If the result is the expected residue value 'CRC32K_RESIDUE', then the frame was received correctly.
接收到帧后，“crc_值”初始化为所有值。编码数据字段的八位字节在解码前由calc_crc32K（）函数累加。然后对编码的CRC-32K字段进行解码，并通过calc_crc32K（）函数累积得到的四个八位字节。如果结果是预期的剩余值“CRC32K_剩余”，则帧接收正确。
An example CRC-32K function is shown below for illustration. Complete examples of use and test vectors are provided in [BACnet], Annex G.3.
下面显示了一个示例CRC-32K函数以供说明。[BACnet]附录G.3中提供了使用和测试向量的完整示例。
<CODE BEGINS>
<代码开始>
#include <stdint.h>
#include <stdint.h>
/* See ANSI/ASHRAE Standard 135-2016 [BACnet], Section G.3.2 */
#define CRC32K_INITIAL_VALUE (0xFFFFFFFF)
#define CRC32K_RESIDUE (0x0843323B)
/* See ANSI/ASHRAE Standard 135-2016 [BACnet], Section G.3.2 */
#define CRC32K_INITIAL_VALUE (0xFFFFFFFF)
#define CRC32K_RESIDUE (0x0843323B)
/* CRC-32K polynomial, 1 + x**1 + ... + x**30 (+ x**32) */
#define CRC32K_POLY (0xEB31D82E)
/* CRC-32K polynomial, 1 + x**1 + ... + x**30 (+ x**32) */
#define CRC32K_POLY (0xEB31D82E)
/*
* Accumulate 'data_value' into the CRC in 'crc_value'.
* Return updated CRC.
*
* Note: crc_value must be set to CRC32K_INITIAL_VALUE
* before initial call.
*/
uint32_t
calc_crc32K (uint8_t data_value, uint32_t crc_value)
{
int b;
/*
* Accumulate 'data_value' into the CRC in 'crc_value'.
* Return updated CRC.
*
* Note: crc_value must be set to CRC32K_INITIAL_VALUE
* before initial call.
*/
uint32_t
calc_crc32K (uint8_t data_value, uint32_t crc_value)
{
int b;
for (b = 0; b < 8; b++) {
if ((data_value & 1) ^ (crc_value & 1)) {
crc_value >>= 1;
crc_value ^= CRC32K_POLY;
} else {
crc_value >>= 1;
}
data_value >>= 1;
}
return crc_value;
}
for (b = 0; b < 8; b++) {
if ((data_value & 1) ^ (crc_value & 1)) {
crc_value >>= 1;
crc_value ^= CRC32K_POLY;
} else {
crc_value >>= 1;
}
data_value >>= 1;
}
return crc_value;
}
<CODE ENDS>
<代码结束>
This Appendix is informative and not part of the standard.
本附录仅供参考，不属于本标准的一部分。
BACnet MS/TP, Src (2), Dst (1), IPv6 Encapsulation
Preamble 55: 0x55
Preamble FF: 0xff
Frame Type: IPv6 Encapsulation (34)
Destination Address: 1
Source Address: 2
Length: 537
Header CRC: 0x1c [correct]
Extended Data CRC: 0x9e7259e2 [correct]
6LoWPAN
IPHC Header
011. .... = Pattern: IP header compression (0x03)
...1 1... .... .... = Traffic class and flow label:
Version, traffic class, and flow label
compressed (0x0003)
.... .0.. .... .... = Next header: Inline
.... ..00 .... .... = Hop limit: Inline (0x0000)
.... .... 1... .... = Context identifier extension: True
.... .... .1.. .... = Source address compression: Stateful
.... .... ..01 .... = Source address mode:
64-bits inline (0x0001)
.... .... .... 0... = Multicast address compression: False
.... .... .... .1.. = Destination address compression:
Stateful
.... .... .... ..10 = Destination address mode:
16-bits inline (0x0002)
0000 .... = Source context identifier: 0x00
.... 0000 = Destination context identifier: 0x00
[Source context: aaaa:: (aaaa::)]
[Destination context: aaaa:: (aaaa::)]
Next header: ICMPv6 (0x3a)
Hop limit: 63
Source: aaaa::1 (aaaa::1)
Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1)
BACnet MS/TP, Src (2), Dst (1), IPv6 Encapsulation
Preamble 55: 0x55
Preamble FF: 0xff
Frame Type: IPv6 Encapsulation (34)
Destination Address: 1
Source Address: 2
Length: 537
Header CRC: 0x1c [correct]
Extended Data CRC: 0x9e7259e2 [correct]
6LoWPAN
IPHC Header
011. .... = Pattern: IP header compression (0x03)
...1 1... .... .... = Traffic class and flow label:
Version, traffic class, and flow label
compressed (0x0003)
.... .0.. .... .... = Next header: Inline
.... ..00 .... .... = Hop limit: Inline (0x0000)
.... .... 1... .... = Context identifier extension: True
.... .... .1.. .... = Source address compression: Stateful
.... .... ..01 .... = Source address mode:
64-bits inline (0x0001)
.... .... .... 0... = Multicast address compression: False
.... .... .... .1.. = Destination address compression:
Stateful
.... .... .... ..10 = Destination address mode:
16-bits inline (0x0002)
0000 .... = Source context identifier: 0x00
.... 0000 = Destination context identifier: 0x00
[Source context: aaaa:: (aaaa::)]
[Destination context: aaaa:: (aaaa::)]
Next header: ICMPv6 (0x3a)
Hop limit: 63
Source: aaaa::1 (aaaa::1)
Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1)
Internet Protocol Version 6, Src: aaaa::1 (aaaa::1),
Dst: aaaa::ff:fe00:1 (aaaa::ff:fe00:1)
0110 .... .... .... .... .... .... .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class:
0x00000000
.... 0000 00.. .... .... .... .... .... = Differentiated
Services Field:
Default (0x00000000)
.... .... ..0. .... .... .... .... .... = ECN-Capable Transport
(ECT): Not set
.... .... ...0 .... .... .... .... .... = ECN-CE: Not set
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 518
Next header: ICMPv6 (58)
Hop limit: 63
Source: aaaa::1 (aaaa::1)
Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1)
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0x783f [correct]
Identifier: 0x2ee5
Sequence: 2
[Response In: 5165]
Data (510 bytes)
Data: e4dbe8553ba0040008090a0b0c0d0e0f1011121314151617...
[Length: 510]
Internet Protocol Version 6, Src: aaaa::1 (aaaa::1),
Dst: aaaa::ff:fe00:1 (aaaa::ff:fe00:1)
0110 .... .... .... .... .... .... .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class:
0x00000000
.... 0000 00.. .... .... .... .... .... = Differentiated
Services Field:
Default (0x00000000)
.... .... ..0. .... .... .... .... .... = ECN-Capable Transport
(ECT): Not set
.... .... ...0 .... .... .... .... .... = ECN-CE: Not set
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 518
Next header: ICMPv6 (58)
Hop limit: 63
Source: aaaa::1 (aaaa::1)
Destination: aaaa::ff:fe00:1 (aaaa::ff:fe00:1)
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0x783f [correct]
Identifier: 0x2ee5
Sequence: 2
[Response In: 5165]
Data (510 bytes)
Data: e4dbe8553ba0040008090a0b0c0d0e0f1011121314151617...
[Length: 510]
Frame (547 bytes):
55 ff 22 01 02 02 19 1c 56 2d 83 56 6f 6a 54 54 U.".....V-.VojTT
54 54 54 54 57 54 56 54 d5 50 2d 6a 7b b0 5c 57 TTTTWTVT.P-j{.\W
b1 8e bd 00 6e f5 51 ac 5d 5c 5f 5e 59 58 5b 5a ....n.Q.]\_^YX[Z
45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ
75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z
65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj
15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................
05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................
35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=<?>98;:
25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+*
d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................
c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................
f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................
e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................
95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................
85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................
b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................
a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 ab aa ................
ab 54 57 56 51 50 53 52 5d 5c 5f 5e 59 58 5b 5a .TWVQPSR]\_^YX[Z
45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ
75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z
65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj
15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................
05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................
35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=<?>98;:
25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+*
d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................
c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................
f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................
e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................
95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................
85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................
b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................
a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 50 cb ..............P.
27 0c b7 '..
Frame (547 bytes):
55 ff 22 01 02 02 19 1c 56 2d 83 56 6f 6a 54 54 U.".....V-.VojTT
54 54 54 54 57 54 56 54 d5 50 2d 6a 7b b0 5c 57 TTTTWTVT.P-j{.\W
b1 8e bd 00 6e f5 51 ac 5d 5c 5f 5e 59 58 5b 5a ....n.Q.]\_^YX[Z
45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ
75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z
65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj
15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................
05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................
35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=<?>98;:
25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+*
d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................
c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................
f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................
e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................
95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................
85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................
b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................
a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 ab aa ................
ab 54 57 56 51 50 53 52 5d 5c 5f 5e 59 58 5b 5a .TWVQPSR]\_^YX[Z
45 44 47 46 41 40 43 42 4d 4c 4f 4e 49 48 4b 4a EDGFA@CBMLONIHKJ
75 74 77 76 71 70 73 72 7d 7c 7f 7e 79 78 7b 7a utwvqpsr}|.~yx{z
65 64 67 66 61 60 63 62 6d 6c 6f 6e 69 68 6b 6a edgfa`cbmlonihkj
15 14 17 16 11 10 13 12 1d 1c 1f 1e 19 18 1b 1a ................
05 04 07 06 01 00 03 02 0d 0c 0f 0e 09 08 0b 0a ................
35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 54761032=<?>98;:
25 24 27 26 21 20 23 22 2d 2c 2f 2e 29 28 2b 2a %$'&! #"-,/.)(+*
d5 d4 d7 d6 d1 d0 d3 d2 dd dc df de d9 d8 db da ................
c5 c4 c7 c6 c1 c0 c3 c2 cd cc cf ce c9 c8 cb ca ................
f5 f4 f7 f6 f1 f0 f3 f2 fd fc ff fe f9 f8 fb fa ................
e5 e4 e7 e6 e1 e0 e3 e2 ed ec ef ee e9 e8 eb ea ................
95 94 97 96 91 90 93 92 9d 9c 9f 9e 99 98 9b 9a ................
85 84 87 86 81 80 83 82 8d 8c 8f 8e 89 88 8b 8a ................
b5 b4 b7 b6 b1 b0 b3 b2 bd bc bf be b9 b8 bb ba ................
a5 a4 a7 a6 a1 a0 a3 a2 ad ac af ae a9 a8 50 cb ..............P.
27 0c b7 '..
Decoded Data and CRC32K (537 bytes):
78 d6 00 3a 3f 00 00 00 00 00 00 00 01 00 01 80 x..:?...........
00 78 3f 2e e5 00 02 e4 db e8 55 3b a0 04 00 08 .x?.......U;....
09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................
19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'(
29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678
39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH
49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh
69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx
79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~..........
89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................
99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................
a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................
b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................
c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................
d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................
e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................
f9 fa fb fc fd fe ff 00 01 02 03 04 05 06 07 08 ................
09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................
19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'(
29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678
39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH
49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh
69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx
79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~..........
89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................
99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................
a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................
b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................
c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................
d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................
e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................
f9 fa fb fc fd 9e 72 59 e2 ......rY.
Decoded Data and CRC32K (537 bytes):
78 d6 00 3a 3f 00 00 00 00 00 00 00 01 00 01 80 x..:?...........
00 78 3f 2e e5 00 02 e4 db e8 55 3b a0 04 00 08 .x?.......U;....
09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................
19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'(
29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678
39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH
49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh
69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx
79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~..........
89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................
99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................
a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................
b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................
c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................
d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................
e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................
f9 fa fb fc fd fe ff 00 01 02 03 04 05 06 07 08 ................
09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 ................
19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 ....... !"#$%&'(
29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 )*+,-./012345678
39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH
49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 YZ[\]^_`abcdefgh
69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 ijklmnopqrstuvwx
79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 yz{|}~..........
89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 ................
99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 ................
a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 ................
b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 ................
c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 ................
d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 ................
e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 ................
f9 fa fb fc fd 9e 72 59 e2 ......rY.
Decompressed 6LoWPAN IPHC (558 bytes):
60 00 00 00 02 06 3a 3f aa aa 00 00 00 00 00 00 `.....:?........
00 00 00 00 00 00 00 01 aa aa 00 00 00 00 00 00 ................
00 00 00 ff fe 00 00 01 80 00 78 3f 2e e5 00 02 ..........x?....
e4 db e8 55 3b a0 04 00 08 09 0a 0b 0c 0d 0e 0f ...U;...........
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO
50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_
60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno
70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~.
80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................
90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................
a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................
b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................
d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................
e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff ................
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO
50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_
60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno
70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~.
80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................
90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................
a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................
b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................
d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................
e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ..............
Decompressed 6LoWPAN IPHC (558 bytes):
60 00 00 00 02 06 3a 3f aa aa 00 00 00 00 00 00 `.....:?........
00 00 00 00 00 00 00 01 aa aa 00 00 00 00 00 00 ................
00 00 00 ff fe 00 00 01 80 00 78 3f 2e e5 00 02 ..........x?....
e4 db e8 55 3b a0 04 00 08 09 0a 0b 0c 0d 0e 0f ...U;...........
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO
50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_
60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno
70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~.
80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................
90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................
a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................
b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................
d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................
e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff ................
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO
50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f PQRSTUVWXYZ[\]^_
60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f `abcdefghijklmno
70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f pqrstuvwxyz{|}~.
80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f ................
90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f ................
a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af ................
b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ................
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf ................
d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ................
e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef ................
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ..............
Acknowledgements
致谢
We are grateful to the authors of [RFC4944] and members of the IETF 6LoWPAN working group; this document borrows liberally from their work. Ralph Droms and Brian Haberman provided indispensable guidance and support from the outset. Peter van der Stok, James Woodyatt, Carsten Bormann, and Dale Worley provided detailed reviews. Stuart Cheshire invented the very clever COBS encoding. Michael Osborne made the critical observation that encoding the data and CRC32K fields separately would allow the CRC to be calculated on the fly. Alexandru Petrescu, Brian Frank, Geoff Mulligan, and Don Sturek offered valuable comments.
我们感谢[RFC4944]的作者和IETF 6LoWPAN工作组的成员；这份文件大量借鉴了他们的工作。拉尔夫·德罗姆斯和布赖恩·哈伯曼从一开始就提供了不可或缺的指导和支持。彼得·范德斯托克、詹姆斯·伍迪亚特、卡斯滕·鲍曼和戴尔·沃利提供了详细的评论。斯图尔特·切希尔发明了非常聪明的COBS编码。迈克尔·奥斯本（Michael Osborne）提出了一个关键的观察结果，即单独编码数据和CRC32K字段将允许动态计算CRC。亚历山德鲁·彼得雷斯库、布赖恩·弗兰克、杰夫·穆利根和唐·斯特雷克提出了宝贵的意见。
Authors' Addresses
作者地址
Kerry Lynn (editor) Verizon Labs 50 Sylvan Rd Waltham, MA 02451 United States of America Phone: +1 781 296 9722 Email: kerlyn@ieee.org
Kerry Lynn（编辑）Verizon实验室马萨诸塞州沃尔瑟姆市Sylvan路50号02451美利坚合众国电话：+1 781 296 9722电子邮件：kerlyn@ieee.org
Jerry Martocci Johnson Controls, Inc. 507 E. Michigan St Milwaukee, WI 53202 United States of America Email: jpmartocci@sbcglobal.net
Jerry Martocci Johnson Controls，Inc.美国威斯康星州密尔沃基市密歇根东街507号邮编：53202电子邮件：jpmartocci@sbcglobal.net
Carl Neilson Delta Controls, Inc. 17850 56th Ave Surrey, BC V3S 1C7 Canada Phone: +1 604 575 5913 Email: cneilson@deltacontrols.com
卡尔·尼尔森三角洲控制有限公司，地址：17850加拿大卑诗省萨里56大街V3S 1C7电话：+1604 575 5913电子邮件：cneilson@deltacontrols.com
Stuart Donaldson Honeywell Automation & Control Solutions 6670 185th Ave NE Redmond, WA 98052 United States of America Email: stuart.donaldson@honeywell.com
斯图尔特·唐纳森·霍尼韦尔自动化与控制解决方案公司，地址：美国华盛顿州雷德蒙东北大街6670 185号，邮编：98052电子邮件：斯图尔特。donaldson@honeywell.com