Internet Engineering Task Force (IETF) A. Moise
Request for Comments: 6142 J. Brodkin
Category: Informational Future DOS R&D Inc.
ISSN: 2070-1721 March 2011
Internet Engineering Task Force (IETF) A. Moise
Request for Comments: 6142 J. Brodkin
Category: Informational Future DOS R&D Inc.
ISSN: 2070-1721 March 2011
ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP
ANSI C12.22、IEEE 1703和MC12.22 IP传输
Abstract
摘要
This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network.
此RFC为在IP网络上传输ANSI C12.22/IEEE 1703/MC12.22高级计量基础设施（AMI）应用层消息提供了一个框架。
This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations.
本文件不是代表ANSI C12.19和C12.22工作组提交的正式文件。它是由这些小组的参与者创建的，建立在几个专有的C12.22-over-IP实现的基础上。本文档的内容表达了这些实现的一致聚合。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc6142.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6142.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括简化的BSD许可证文本，如本规范第4.e节所述
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
如简化的BSD许可证所述，信托法律条款和许可证不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................3
4. The C12.22 IP Network Segment ...................................6
4.1. Composition of a C12.22 IP Network Segment .................6
4.2. Native IP Address ..........................................7
4.3. Encoding of Native IP Addresses ............................7
4.4. Standardized Port Numbers ..................................9
4.5. Use of UDP Source Port 0 ...................................9
4.6. IP Multicast ..............................................10
4.7. IP Broadcast ..............................................12
4.8. Encoding of Multicast and Broadcast Addresses .............12
5. IP Message Transport ...........................................14
5.1. C12.22 Connection Types and TCP/UDP Transport Modes .......14
5.2. IP Message Transport Details ..............................15
5.2.1. TCP and UDP Port Use ...............................15
5.2.2. Active-OPEN UDP Mode (CL=1, CL Accept=0) ...........16
5.2.3. Passive-OPEN UDP Mode (CL=1, CL Accept=1) ..........17
5.2.4. Active-OPEN TCP Mode (CO=1, CO Accept=0) ...........17
5.2.5. Passive-OPEN TCP Mode (CO=1, CO Accept=1) ..........18
5.2.6. TCP and C12.22 Message Directionality ..............18
5.3. Using IP Broadcast/Multicast ..............................19
5.4. Transport Protocol Decisions ..............................20
5.4.1. Unicast Versus Multicast Versus Broadcast ..........20
5.4.2. Sending Large C12.22 APDUs Using UDP ...............20
5.4.3. Choice of Protocol for C12.22 Response APDUs .......20
5.5. Quality of Service ........................................20
5.6. Congestion Control ........................................21
6. Security Considerations ........................................21
7. IANA Considerations ............................................23
8. Acknowledgments ................................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................25
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................3
4. The C12.22 IP Network Segment ...................................6
4.1. Composition of a C12.22 IP Network Segment .................6
4.2. Native IP Address ..........................................7
4.3. Encoding of Native IP Addresses ............................7
4.4. Standardized Port Numbers ..................................9
4.5. Use of UDP Source Port 0 ...................................9
4.6. IP Multicast ..............................................10
4.7. IP Broadcast ..............................................12
4.8. Encoding of Multicast and Broadcast Addresses .............12
5. IP Message Transport ...........................................14
5.1. C12.22 Connection Types and TCP/UDP Transport Modes .......14
5.2. IP Message Transport Details ..............................15
5.2.1. TCP and UDP Port Use ...............................15
5.2.2. Active-OPEN UDP Mode (CL=1, CL Accept=0) ...........16
5.2.3. Passive-OPEN UDP Mode (CL=1, CL Accept=1) ..........17
5.2.4. Active-OPEN TCP Mode (CO=1, CO Accept=0) ...........17
5.2.5. Passive-OPEN TCP Mode (CO=1, CO Accept=1) ..........18
5.2.6. TCP and C12.22 Message Directionality ..............18
5.3. Using IP Broadcast/Multicast ..............................19
5.4. Transport Protocol Decisions ..............................20
5.4.1. Unicast Versus Multicast Versus Broadcast ..........20
5.4.2. Sending Large C12.22 APDUs Using UDP ...............20
5.4.3. Choice of Protocol for C12.22 Response APDUs .......20
5.5. Quality of Service ........................................20
5.6. Congestion Control ........................................21
6. Security Considerations ........................................21
7. IANA Considerations ............................................23
8. Acknowledgments ................................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................25
The ANSI C12.22 standard [1] provides a set of application layer messaging services that are applicable for the enterprise and End Device components of an Advanced Metering Infrastructure (AMI) for the Smart Grid. The messaging services are tailored for, but not limited to, the exchange of the Data Table Elements defined and co-published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [23]. These standards were developed jointly by ANSI (ANSI C12.22 and ANSI C12.19), IEEE (IEEE 1377 and IEEE 1703), and Measurement Canada (MC12.19 and MC12.22).
ANSI C12.22标准[1]提供了一组应用层消息传递服务，适用于智能电网高级计量基础设施（AMI）的企业和终端设备组件。消息传递服务针对但不限于ANSI C12.19[2]、IEEE P1377[3]和MC12.19[23]中定义和共同发布的数据表元素的交换而定制。这些标准由ANSI（ANSI C12.22和ANSI C12.19）、IEEE（IEEE 1377和IEEE 1703）和加拿大计量局（MC12.19和MC12.22）共同制定。
ANSI C12.22, which is an application level messaging protocol, may be transported over any underlying transport network. This RFC defines the requirements governing the transmission of ANSI C12.22 Messages via the TCP and UDP transports in IP networks (whereby the OSI Session, Presentation, and Application Layers of ANSI C12.22 are collapsed into a single Application Layer).
ANSI C12.22是一种应用程序级消息传递协议，可以通过任何底层传输网络进行传输。该RFC定义了通过IP网络中的TCP和UDP传输来控制ANSI C12.22消息传输的要求（据此，ANSI C12.22的OSI会话、表示和应用层被折叠为单个应用层）。
Specifically, this RFC applies to the operational details of Section 5, "C12.22 Node to C12.22 Network Segment Details", of ANSI C12.22, and covers the mapping, encoding, and interpreting of ANSI C12.19 Device Network Table Elements and Native Addresses for use on IP networks.
具体而言，本RFC适用于ANSI C12.22第5节“C12.22节点到C12.22网段详细信息”的操作细节，并涵盖了ANSI C12.19设备网络表元素和IP网络上使用的本机地址的映射、编码和解释。
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 RFC 2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
Throughout this document, we use terms like "ANSI C12.22" or "ANSI C12.19", as in "C12.22 Relay" or "ANSI C12.19 Device". These terms are interchangeable with the terms "IEEE 1703 Relay" and "IEEE 1377 Device", respectively. However, the recent versions of the Utility End Device communication standards were developed under the auspices of ANSI C12 SC17 WG1 and ANSI C12 SC17 WG2. For that reason, the terminology used in this document expands on the ANSI C12.22-2008 [1] and ANSI C12.19-2008 [2] definitions as revised by IEEE 1703-2010 [5] and IEEE 1377-2010 [3].
在本文档中，我们使用“ANSI C12.22”或“ANSI C12.19”等术语，如“C12.22继电器”或“ANSI C12.19设备”。这些术语可分别与术语“IEEE 1703继电器”和“IEEE 1377设备”互换。然而，公用事业终端设备通信标准的最新版本是在ANSI C12 SC17 WG1和ANSI C12 SC17 WG2的支持下制定的。因此，本文件中使用的术语扩展了经IEEE 1703-2010[5]和IEEE 1377-2010[3]修订的ANSI C12.22-2008[1]和ANSI C12.19-2008[2]定义。
This specification uses a number of terms to refer to the roles played by participants (actors) in, and objects of, the ANSI C12.22 [1], IEEE 1703 [5], and MC12.22 [24] protocol. Any terms prefixed by "C12.22" or "C12.19" that are not defined in this document can be resolved in [1], [5], [24] or in [2], [3], [23].
本规范使用了许多术语来表示ANSI C12.22[1]、IEEE 1703[5]和MC12.22[24]协议的参与者（参与者）和对象所扮演的角色。本文件中未定义的任何前缀为“C12.22”或“C12.19”的术语可在[1]、[5]、[24]或[2]、[3]、[23]中解决。
ACSE
ACSE
Association Control Service Element. In the context of this specification and of [1], ACSEs are encoded per ISO/IEC 10035-1 [6] using the ASN.1 Basic Encoding Rules (BER) [7].
关联控制服务元素。在本规范和[1]的上下文中，ACSE按照ISO/IEC 10035-1[6]使用ASN.1基本编码规则（BER）[7]进行编码。
Active-OPEN UDP
主动开放UDP
Active-OPEN UDP is a state used by a local C12.22 IP Node to expect and receive incoming C12.22 Messages that it solicited from a foreign C12.22 IP Node using UDP. The local C12.22 IP Node MAY exit the Active-OPEN UDP state when it has received all of the expected C12.22 Messages or a C12.22 Message timeout has occurred. The local C12.22 IP Node receives all C12.22 Response Messages solicited from the foreign C12.22 IP Node that arrive at the local port number that matches the source port number used to solicit the C12.22 Messages from the foreign C12.22 IP Node.
Active OPEN UDP是本地C12.22 IP节点使用的一种状态，用于期望和接收其使用UDP从外部C12.22 IP节点请求的传入C12.22消息。当本地C12.22 IP节点收到所有预期的C12.22消息或发生C12.22消息超时时，可能会退出活动的开放UDP状态。本地C12.22 IP节点接收从外部C12.22 IP节点请求的所有C12.22响应消息，这些消息到达与用于从外部C12.22 IP节点请求C12.22消息的源端口号匹配的本地端口号。
Active-OPEN TCP
主动开放式TCP
Active-OPEN TCP is a state used by a local C12.22 IP Node to establish a TCP connection with a fully specified foreign C12.22 IP Node using TCP and the foreign C12.22 IP Node's registered Native IP Address. The Active-OPEN TCP state is identical to a local "Active-OPEN" as defined in [9].
主动开放TCP是本地C12.22 IP节点使用TCP和外部C12.22 IP节点的注册本机IP地址与完全指定的外部C12.22 IP节点建立TCP连接所使用的状态。活动打开TCP状态与[9]中定义的本地“活动打开”状态相同。
APDU
阿普杜
Application Protocol Data Unit. In the context of the ANSI C12.22 Application, it is an ACSE C12.22 Message.
应用协议数据单元。在ANSI C12.22应用程序的上下文中，它是ACSE C12.22消息。
ACSE APDU
ACSE APDU
ACSE Application Protocol Data Unit; same as APDU.
ACSE应用协议数据单元；与APDU相同。
ApTitle
阿普蒂尔
An ANSI C12.22 Application-process Title. An ApTitle is a name for a system-independent application activity that exposes application services to the application agent, e.g., a set of application service elements that together perform all or part of the communication aspects of an application process. An ApTitle is encoded as a unique registered (as per [1]) object identifier.
ANSI C12.22应用程序过程标题。ApTitle是向应用程序代理公开应用程序服务的独立于系统的应用程序活动的名称，例如，一组应用程序服务元素共同执行应用程序流程的所有或部分通信方面。ApTitle编码为唯一的注册（根据[1]）对象标识符。
C12.22 IP Node
C12.22 IP节点
A C12.22 Node that is located on a C12.22 IP Network Segment and communicates using the Internet Protocol.
位于C12.22 IP网段上并使用Internet协议进行通信的C12.22节点。
C12.22 IP Network Segment
C12.22 IP网段
A collection of all C12.22 IP Nodes that implement the IP-based protocols, as defined in this specification, and can communicate with each other using IP routers, switches, and bridges and without the use of a C12.22 Relay.
所有C12.22 IP节点的集合，这些节点实现本规范中定义的基于IP的协议，并且可以使用IP路由器、交换机和网桥相互通信，而无需使用C12.22中继。
C12.22 IP Relay
C12.22 IP继电器
A C12.22 IP Node that performs the functions of a C12.22 Relay. A C12.22 IP Relay acts as a bridge between a C12.22 IP Network Segment and an adjacent, C12.22 Network Segment.
执行C12.22中继功能的C12.22 IP节点。C12.22 IP中继充当C12.22 IP网段和相邻C12.22网段之间的桥梁。
C12.22 Message
C12.22信息
An ACSE APDU that is fully assembled, or a segment of a C12.22 Request Message, or a segment of a C12.22 Response Message. The C12.22 Message described in this specification MUST be encoded using [7].
完全组装的ACSE APDU，或C12.22请求消息的一段，或C12.22响应消息的一段。本规范中描述的C12.22消息必须使用[7]进行编码。
C12.22 Request Message
C12.22请求消息
A fully assembled C12.22 APDU that contains an ACSE user-information element, which includes one or more EPSEM Service Requests.
一种完全组装的C12.22 APDU，包含ACSE用户信息元素，其中包括一个或多个EPSEM服务请求。
C12.22 Response Message
C12.22响应消息
A fully assembled C12.22 APDU that contains an ACSE user-information element, which includes one or more EPSEM service responses.
一种完全组装的C12.22 APDU，包含ACSE用户信息元素，其中包括一个或多个EPSEM服务响应。
Connection
联系
A logical and physical binding between two or more users of a service [1].
服务的两个或多个用户之间的逻辑和物理绑定[1]。
EPSEM
爱普生
Extended Protocol Specification for Electronic Metering. EPSEM defines structures and services used to encode multiple requests and responses for use by devices such as gas, water, electricity, and related electronic modules or appliances.
电子计量的扩展协议规范。EPSEM定义了用于对多个请求和响应进行编码的结构和服务，以供设备（如煤气、水、电和相关电子模块或设备）使用。
Initiating C12.22 IP Node
启动C12.22 IP节点
A role of a C12.22 IP Node in which it initiates the transmission of a C12.22 Request Message.
C12.22 IP节点的一种角色，在该节点中发起C12.22请求消息的传输。
Native Address
本地地址
The term "Native Address" refers to the transport address that may be used to reach a C12.22 Node on its C12.22 Network Segment [1]. In this specification, the Native Address refers to the Native IP Address.
术语“本机地址”是指可用于到达其C12.22网段上的C12.22节点的传输地址[1]。在本规范中，本机地址指本机IP地址。
Passive-OPEN UDP
被动开放UDP
Passive-OPEN UDP is a state used by a local C12.22 IP Node to expect and receive incoming C12.22 Messages from any foreign C12.22 IP Node using UDP. When the Passive-OPEN UDP state is active, the local C12.22 IP Node accepts all C12.22 Messages that arrive at the local port number that was registered by the local C12.22 IP Node.
被动开放UDP是本地C12.22 IP节点使用的一种状态，用于期望和接收来自任何使用UDP的外部C12.22 IP节点的传入C12.22消息。当被动开放UDP状态为活动时，本地C12.22 IP节点接受所有到达本地C12.22 IP节点注册的本地端口号的C12.22消息。
Passive-OPEN TCP
被动开放TCP
Passive-OPEN TCP is a state used by a local C12.22 IP Node that wants to establish a TCP connection with an unspecified foreign C12.22 IP Node using TCP. In this case, any foreign C12.22 IP Node MAY connect to the local C12.22 IP Node as long as the local port matches the port used by the foreign C12.22 IP Node. The Passive-OPEN TCP state is identical to "local passive OPEN" defined in [9].
被动开放TCP是本地C12.22 IP节点使用的状态，该节点希望使用TCP与未指定的外部C12.22 IP节点建立TCP连接。在这种情况下，只要本地端口与外部C12.22 IP节点使用的端口匹配，任何外部C12.22 IP节点都可以连接到本地C12.22 IP节点。被动打开TCP状态与[9]中定义的“本地被动打开”相同。
Responding C12.22 IP Node
响应C12.22 IP节点
A role of a C12.22 IP Node in which it responds to the reception of a C12.22 Request Message.
C12.22 IP节点的一种角色，在该节点中，它响应C12.22请求消息的接收。
Target C12.22 IP Node
目标C12.22 IP节点
The C12.22 IP Node that is the destination for a C12.22 Message.
作为C12.22消息目的地的C12.22 IP节点。
This section defines the characteristics of the C12.22 IP Network Segment.
本节定义了C12.22 IP网段的特性。
A C12.22 Network Segment is a collection of C12.22 Nodes that can communicate with each other directly -- without having to forward C12.22 Messages through a C12.22 Relay.
C12.22网段是C12.22节点的集合，这些节点可以直接相互通信，而无需通过C12.22中继转发C12.22消息。
A C12.22 IP Network Segment comprises C12.22 IP Nodes and the network infrastructure that enables any one node to reach all other nodes on
C12.22 IP网段包括C12.22 IP节点和网络基础设施，该网络基础设施使任何一个节点都能够连接到网络上的所有其他节点
the same segment. All C12.22 IP Nodes on the C12.22 IP Network Segment employ the same IP address encoding scheme (per Figures 1 and 2) and the same network and transport protocols in accordance with this specification.
同一部分。根据本规范，C12.22 IP网段上的所有C12.22 IP节点采用相同的IP地址编码方案（根据图1和图2）以及相同的网络和传输协议。
There is no restriction on the size of a C12.22 IP Network Segment. It MAY be as small as a single LAN or subnet, or it MAY include numerous, heterogeneous LANs and WANs connected by routers, bridges, and switches. The C12.22 IP Network Segment MAY be completely private, or include communication across the global Internet.
C12.22 IP网段的大小没有限制。它可能与单个LAN或子网一样小，也可能包括通过路由器、网桥和交换机连接的众多异构LAN和WAN。C12.22 IP网段可以是完全私有的，或者包括通过全球互联网的通信。
The term "Native IP Address" denotes a Native Address that MAY be used to reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP Address includes the binary IP address, and an OPTIONAL port number that MAY be followed by an OPTIONAL protocol identifier. The Native IP Address SHALL be encoded as described below in Section 4.3, "Encoding of Native IP Addresses".
术语“本机IP地址”表示可用于到达其C12.22 IP网段上的C12.22节点的本机地址。本机IP地址包括二进制IP地址和可选端口号，该端口号后面可能跟有可选协议标识符。本机IP地址应按照第4.3节“本机IP地址编码”中的说明进行编码。
The IP address of the C12.22 IP Node MUST be configured before the C12.22 IP Node attempts to send or receive any C12.22 Message on its C12.22 IP Network Segment. If the port number is not explicitly configured by the controlling application, it SHALL be set to the default port number, 1153 (see Section 4.4, "Standardized Port Numbers", below).
在C12.22 IP节点尝试在其C12.22 IP网段上发送或接收任何C12.22消息之前，必须配置C12.22 IP节点的IP地址。如果控制应用程序未明确配置端口号，则应将其设置为默认端口号1153（见下文第4.4节“标准化端口号”）。
It is beyond the scope of this specification to define the method of configuration, the configuration parameters, or any administrative controls that the system administrator may wish to implement to assign an IP address.
定义系统管理员为分配IP地址而可能希望实施的配置方法、配置参数或任何管理控制超出了本规范的范围。
ANSI C12.22 defines binary fields for encoding a C12.22 Native Address for transport within C12.22 Messages and for storage in C12.19 Device Tables. In this RFC, the fields SHALL contain an IPv4 or an IPv6 binary native IP address that is followed by an OPTIONAL two-byte TCP or UDP port number. The TCP or UDP port number, when present, MAY be followed by an OPTIONAL one-byte transport protocol identifier ("Protocol" for IPv4 or "Next Header" for IPv6). The transport protocol identifier SHALL be set to 17 (0x11) for UDP transport, or to 6 (0x06) for TCP transport, or not set (absent) for both UDP and TCP transports. The transport protocol values SHALL be consistent with the C12.22 Node's registered attributes (see Connectionless (CL) and Connection-Oriented (CO) flags in Section 5.1, "C12.22 Connection Types and TCP/UDP Transport Modes", below).
ANSI C12.22定义二进制字段，用于编码C12.22本机地址，以便在C12.22消息中传输，并用于在C12.19设备表中存储。在此RFC中，字段应包含IPv4或IPv6二进制本机IP地址，后跟可选的两字节TCP或UDP端口号。TCP或UDP端口号（如果存在）后面可以跟一个可选的单字节传输协议标识符（“协议”表示IPv4或“下一个标头”表示IPv6）。对于UDP传输，传输协议标识符应设置为17（0x11）；对于TCP传输，传输协议标识符应设置为6（0x06）；对于UDP和TCP传输，传输协议标识符应设置为未设置（不存在）。传输协议值应与C12.22节点的注册属性一致（见下文第5.1节“C12.22连接类型和TCP/UDP传输模式”中的无连接（CL）和面向连接（CO）标志）。
ANSI C12.22 allows the Native Address fields to be conveyed in select ANSI C12.22 EPSEM service elements (e.g., ANSI C12.22 Registration Service <native-address>, ANSI C12.22 Resolve Service response <local-address>, and ANSI C12.19 INTERFACE_CTRL_TBL Element NATIVE_ADDRESS). The length of the C12.22 Native Address is qualified by an ANSI C12.22 address length field (e.g., ANSI C12.22 Registration Service <address-length>, ANSI C12.22 Resolve Service response <local-address-length>, and ANSI C12.19 ACT_NETWORK_TBL Element NATIVE_ADDRESS_LEN).
ANSI C12.22允许在选择的ANSI C12.22 EPSEM服务元素中传输本机地址字段（例如，ANSI C12.22注册服务<本机地址>、ANSI C12.22解析服务响应<本地地址>、ANSI C12.19接口\u控制\u TBL元素本机\u地址）。C12.22本机地址的长度由ANSI C12.22地址长度字段限定（例如，ANSI C12.22注册服务<Address length>、ANSI C12.22解析服务响应<local Address length>、ANSI C12.19 ACT\u NETWORK\u TBL元素本机地址）。
The ANSI C12.22 Registration Service permits only one Native Address to be recorded with each registered ApTitle. For this reason, a C12.22 IP Node that wishes to register different port numbers for UDP and TCP MUST register twice using different ApTitles.
ANSI C12.22注册服务只允许在每个已注册地址中记录一个本机地址。因此，希望为UDP和TCP注册不同端口号的C12.22 IP节点必须使用不同的适配器注册两次。
The binary Native IP Address fields SHALL be encoded in network byte order, as shown in Figure 1.
二进制本机IP地址字段应按网络字节顺序编码，如图1所示。
IP Address (ADDR), Port (P), Transport (T)
Address
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 4 | ADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address (ADDR), Port (P), Transport (T)
Address
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 4 | ADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4+Port 6 | ADDR4 | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4+Port 6 | ADDR4 | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4+Port 7 | ADDR4 | P |T|
+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4+Port 7 | ADDR4 | P |T|
+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 16 | ADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 16 | ADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6+Port 18 | ADDR6 | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6+Port 18 | ADDR6 | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6+Port 19 | ADDR6 | P |T|
+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6+Port 19 | ADDR6 | P |T|
+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Encoding of the Native IP Addresses for ANSI C12.22
图1:ANSI C12.22的本机IP地址编码
When an ANSI C12.22 Native Address is encoded in the ANSI C12.19 Tables' BINARY data Elements, the size of the Native Address Element is defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (see Table 121 of [1], and [2]). This is the actual number of octets that are placed inside the C12.19 BINARY Element. This value is common to all of the C12.22 Node's interfaces, including those that are not IP based (thus not conforming to this specification). For this reason, the ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than, and SHALL NOT be smaller than, the actual length needed to encode a Native IP Address per Figure 1. When this is the case, the C12.22 Native IP Address SHALL be padded with zero (0) to fill the Table's BINARY data Element.
当ANSI C12.22本机地址编码在ANSI C12.19表格的二进制数据元素中时，本机地址元素的大小由ACT_NETWORK_TBL.Native_Address_LEN定义（参见[1]和[2]中的表121）。这是放置在C12.19二进制元素中的实际八位字节数。该值对于所有C12.22节点的接口都是通用的，包括那些不基于IP的接口（因此不符合本规范）。因此，ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN可大于且不得小于图1中编码本机IP地址所需的实际长度。在这种情况下，C12.22本机IP地址应填充零（0），以填充表格的二进制数据元素。
In instances where the Native IP Address length does not exactly match any of the Address Lengths listed in Figure 1, the actual Address Length SHALL be determined by stripping all trailing binary zeros (0x00) and then adjusting the Address Length upwards to the next largest value shown in Figure 1.
在本机IP地址长度与图1中列出的任何地址长度不完全匹配的情况下，实际地址长度应通过去除所有尾随二进制零（0x00），然后将地址长度向上调整至图1中所示的下一个最大值来确定。
IANA (Internet Assigned Numbers Authority) has assigned port 1153 for UDP [8] and TCP [9] C12.22 IP Messages.
IANA（互联网分配号码管理局）已为UDP[8]和TCP[9]C12.22 IP消息分配了端口1153。
By default, C12.22 IP Nodes SHALL send all C12.22 Application association initiation message requests with 1153 set as the destination port number.
默认情况下，C12.22 IP节点应发送所有C12.22应用程序关联启动消息请求，并将1153设置为目标端口号。
To ensure interoperability among C12.22 IP Nodes, all C12.22 IP Relays and Master Relays SHALL monitor and accept UDP and TCP messages destined to port 1153.
为确保C12.22 IP节点之间的互操作性，所有C12.22 IP继电器和主继电器应监控并接受发送至端口1153的UDP和TCP消息。
Any IP firewalls or Access Control Lists (ACLs) shielding C12.22 Nodes and the IP network MUST be configured to forward UDP and TCP traffic destined to port 1153 and other ports that are assigned and registered by the network administrator, in order to maintain the continuity of the C12.22 IP Network Segment.
屏蔽C12.22节点和IP网络的任何IP防火墙或访问控制列表（ACL）必须配置为转发目的地为端口1153和网络管理员分配和注册的其他端口的UDP和TCP流量，以保持C12.22 IP网段的连续性。
Although RFC 768 [8] allows for a source port number of zero (0), C12.22 IP Nodes SHALL NOT send datagrams on UDP with the source port set to zero. A C12.22 IP Node SHALL ignore and SHALL NOT respond to any C12.22 Message that it receives from source port 0.
尽管RFC 768[8]允许源端口号为零（0），但C12.22 IP节点不应在源端口设置为零的情况下在UDP上发送数据报。C12.22 IP节点应忽略并不对其从源端口0接收到的任何C12.22消息作出响应。
Further details of the C12.22 IP Node's use of UDP, and of TCP, are given in Section 5, "IP Message Transport", below.
关于C12.22 IP节点使用UDP和TCP的更多详细信息，请参见下文第5节“IP消息传输”。
In addition to unicast, the ANSI C12.22 protocol requires the support of a multicast message delivery service from the network. In cases where C12.22 IP Nodes MUST perform Native IP Address discovery (e.g., the discovery of the Native IP Address of C12.22 IP Relays that provide a route out of the C12.22 IP Network Segment, or the discovery of the Native IP Address of a C12.22 IP Master Relay on the C12.22 IP Network), the C12.22 IP Nodes use IP multicast to send a C12.22 Message that contains an EPSEM Resolve Service Request on the IP LAN.
除了单播之外，ANSI C12.22协议还需要支持来自网络的多播消息传递服务。在C12.22 IP节点必须执行本机IP地址发现的情况下（例如，发现提供C12.22 IP网段路由的C12.22 IP中继的本机IP地址，或发现C12.22 IP网络上C12.22 IP主中继的本机IP地址），C12.22 IP节点使用IP多播发送C12.22消息，该消息包含IP LAN上的EPSEM解析服务请求。
IP multicast is also desirable, for example, when a C12.22 Host needs to read a multitude of C12.22 Nodes (e.g., meters) that are configured with a common C12.22 multicast group ApTitle. Using IP multicast, the C12.22 Host MAY send a C12.22 Message containing an EPSEM Read Service Request that reaches all C12.22 Nodes on the C12.22 IP Network Segment.
例如，当C12.22主机需要读取配置有公共C12.22多播组ApTitle的多个C12.22节点（例如，仪表）时，IP多播也是可取的。使用IP多播，C12.22主机可以发送包含EPSEM读取服务请求的C12.22消息，该请求到达C12.22 IP网段上的所有C12.22节点。
For these reasons, all C12.22 IP Relays and Master Relays SHALL support IP multicast, and it is RECOMMENDED that all C12.22 Nodes support IP multicast. Any IPv4 C12.22 IP Node that supports IP multicast SHALL use the Internet Group Management Protocol version 1 (IGMPv1) [10] as a minimum, to report (i.e., request) membership in the C12.22 multicast group to its local router(s). It is RECOMMENDED that C12.22 IP Nodes implement IGMPv3 [11].
因此，所有C12.22 IP中继和主中继都应支持IP多播，建议所有C12.22节点都支持IP多播。支持IP多播的任何IPv4 C12.22 IP节点应至少使用Internet组管理协议版本1（IGMPv1）[10]，以向其本地路由器报告（即请求）C12.22多播组中的成员资格。建议C12.22 IP节点实现IGMPv3[11]。
Any IPv6 C12.22 IP Node that supports IP multicast SHALL use Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [12]), possibly within ICMPv6 (RFC 4443 [13]), to report membership.
支持IP多播的任何IPv6 C12.22 IP节点应使用多播侦听器发现版本2（MLDv2）（RFC 3810[12]），可能在ICMPv6（RFC 4443[13]）内，以报告成员身份。
Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network Segment MUST support Protocol Independent Multicast - Sparse Mode (PIM-SM) (RFC 4601 [14]) along with IGMPv1 (RFC 1112 [10]) as a minimum for IPv4, or MLDv2 for IPv6 (RFC 3810 [12]). It is RECOMMENDED that they implement IGMPv3 [11]. It is beyond the scope of this specification to define the mechanism for selecting an initial Rendezvous Point (RP) for the C12.22 multicast group, the use of shared versus source trees, or the mechanism for inter-domain multicast routing.
将C12.22 IP网段上的C12.22 IP节点互连的路由器必须支持协议独立多播稀疏模式（PIM-SM）（RFC 4601[14]）以及IGMPv1（RFC 1112[10]），作为IPv4的最低要求，或支持IPv6的MLDv2（RFC 3810[12]）。建议他们实施IGMPv3[11]。定义为C12.22多播组选择初始集合点（RP）的机制、共享树与源树的使用或域间多播路由的机制超出了本规范的范围。
IANA has registered the "All C1222 Nodes" multicast group, and has assigned the IPv4 multicast address of 224.0.2.4 and the IPv6 multicast address of FF0X::204, where X represents the Scope field as defined in RFC 4291, "IP Version 6 Addressing Architecture" [15].
IANA已注册“所有C1222节点”多播组，并已分配IPv4多播地址224.0.2.4和IPv6多播地址FF0X:：204，其中X表示RFC 4291“IP版本6寻址体系结构”中定义的范围字段[15]。
For IPv6, all C12.22 IP Relays, C12.22 IP Master Relays, and all C12.22 IP Nodes configured to support broadcast and multicast (see Section 5.3, "Using IP Broadcast/Multicast", below) SHALL join the global-scope multicast address, FF0E::204, as well as all of the assigned, reduced-scope, multicast addresses:
对于IPv6，所有配置为支持广播和多播的C12.22 IP中继、C12.22 IP主中继和所有C12.22 IP节点（见下文第5.3节“使用IP广播/多播”）应加入全局范围多播地址FF0E:：204，以及所有分配的缩小范围多播地址：
link-local -- FF02::204;
admin-local -- FF04::204;
site-local -- FF05::204; and
organization-local -- FF08::204.
link-local -- FF02::204;
admin-local -- FF04::204;
site-local -- FF05::204; and
organization-local -- FF08::204.
IPv6 C12.22 IP Nodes SHOULD use the minimum scope needed, when initiating IP multicast messages to reach another C12.22 IP Node on the C12.22 Network. This practice allows the sender to limit unnecessary propagation of C12.22 IP Multicast Messages.
在启动IP多播消息以到达C12.22网络上的另一个C12.22 IP节点时，IPv6 C12.22 IP节点应使用所需的最小作用域。这种做法允许发送方限制C12.22 IP多播消息的不必要传播。
To determine the minimum scope required to reach the closest C12.22 IP Relay on the C12.22 Node's IP Network Segment, this specification RECOMMENDS the following simple steps:
为了确定到达C12.22节点IP网段上最近的C12.22 IP中继所需的最小范围，本规范建议以下简单步骤：
1. Starting with the smallest (local-most) scope (i.e., link-local scope or another pre-configured scope), send the C12.22 EPSEM Resolve Service Request for the purpose of C12.22 IP Relay discovery.
1. 从最小（本地most）作用域（即链路本地作用域或另一个预配置的作用域）开始，发送C12.22 EPSEM解析服务请求，以进行C12.22 IP中继发现。
2. Listen for a response from a C12.22 IP Relay; then:
2. 收听来自C12.22 IP继电器的响应；然后：
A. If no response is received, assign the next wider scope level, then repeat steps (1) and (2) at the newly assigned scope.
A.如果没有收到响应，则分配下一个更宽的范围级别，然后在新分配的范围重复步骤（1）和（2）。
B. If a response is received, then record the scope level as the minimum scope to use on the node's C12.22 IP Network Segment.
B.如果收到响应，则将范围级别记录为节点的C12.22 IP网段上要使用的最小范围。
A C12.22 IPv6 Node that initiates any EPSEM Service Request SHOULD use the minimum scope necessary to reach its Target C12.22 IP Nodes. A C12.22 IPv6 Relay SHALL use the global scope for any C12.22 Message destined for the global Internet.
发起任何EPSEM服务请求的C12.22 IPv6节点应使用到达其目标C12.22 IP节点所需的最小范围。C12.22 IPv6中继应将全局范围用于发送至全球互联网的任何C12.22消息。
This specification does not preclude the use of the unassigned scope values defined in [15]; those scope values MAY be used on a private basis, or through mutual operating agreements.
本规范不排除使用[15]中定义的未分配范围值；这些范围值可在私人基础上使用，或通过相互经营协议使用。
For IPv4, all C12.22 IP Relays, C12.22 IP Master Relays, and all C12.22 IP Nodes configured to support broadcast/multicast SHALL join the assigned multicast address of 224.0.2.4. This global address does not provide for the type of scoping discussed above for IPv6, nor is it compatible with the administratively scoped IP multicast
对于IPv4，所有配置为支持广播/多播的C12.22 IP中继、C12.22 IP主中继和所有C12.22 IP节点应加入分配的224.0.2.4多播地址。此全局地址不提供上面讨论的IPv6作用域类型，也不与管理作用域IP多播兼容
specification in RFC 2365 [16]. Therefore, a different technique to limit the propagation of C12.22 IP Multicast Messages is needed. One available technique to control IPv4 multicast scope is through the use of the Time-to-Live (TTL) attribute in the IP packet header. This attribute is not managed by the C12.22 protocol.
RFC 2365[16]中的规范。因此，需要一种不同的技术来限制C12.22 IP多播消息的传播。控制IPv4多播作用域的一种可用技术是通过在IP数据包报头中使用生存时间（TTL）属性。此属性不受C12.22协议的管理。
In the implementation of this technique, an administrative domain MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in the administrative domain SHOULD be configured with a TTL sufficiently large to reach that C12.22 IP Relay.
在该技术的实现中，管理域必须包括至少一个C12.22 IP中继，并且管理域中的所有C12.22 IP节点都应配置足够大的TTL以到达该C12.22 IP中继。
A C12.22 IPv4 Node that initiates any C12.22 Request Message SHOULD use the minimum TTL needed to reach its Target C12.22 IP Nodes.
发起任何C12.22请求消息的C12.22 IPv4节点应使用到达其目标C12.22 IP节点所需的最小TTL。
IP broadcast is not generally suitable as a replacement for, or an alternative to, multicast in a C12.22 IP Network Segment. IP broadcast is not supported in IPv6, and it suffers from limited scope in IPv4. This specification, however, does not preclude the use of IP network directed or limited/local scope (address 255.255.255.255) broadcast within a controlled management domain (as per RFC 2644 [17]).
IP广播通常不适合作为C12.22 IP网段中多播的替代品或替代品。IPv6不支持IP广播，并且它在IPv4中的作用域有限。然而，本规范并不排除在受控管理域内（根据RFC 2644[17]）使用IP网络定向或有限/本地范围（地址255.255.255.255）广播。
ANSI C12.22 Tables provide BINARY Elements for encoding a broadcast or multicast Native IP Address for transport within a C12.22 Message. The encoding of these Table Elements is identical to that defined in Section 4.3, "Encoding of Native IP Addresses". These fields SHALL be used as shown in Figure 2.
ANSI C12.22表格提供二进制元素，用于编码C12.22消息内传输的广播或多播本机IP地址。这些表元素的编码与第4.3节“本机IP地址编码”中定义的编码相同。这些字段的使用如图2所示。
IP Address (ADDR), Port (P), Transport (T)
Address
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 4 |BADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address (ADDR), Port (P), Transport (T)
Address
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 4 |BADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 6 |BADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 6 |BADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 7 |BADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 7 |BADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 4 |MADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 4 |MADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 6 |MADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 6 |MADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 7 |MADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 7 |MADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 16 | MADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 16 | MADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 18 | MADDR6 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 18 | MADDR6 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 19 | MADDR6 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 19 | MADDR6 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encoding of Broadcast/Multicast Native IP Addresses
图2：广播/多播本机IP地址的编码
The IPv4 and IPv6 multicast addresses -- MADDR4 and MADDR6, respectively -- are those assigned by IANA for use by ANSI C12.22.
IPv4和IPv6多播地址——分别为MADDR4和MADDR6——是IANA分配给ANSI C12.22使用的地址。
When a broadcast/multicast Native IP Address is encoded in the ANSI C12.19 Tables' BINARY data Elements, the size of the Native Address Element transmitted is defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (see Table 121 of [1], and [2]). This is the actual number of octets that are placed inside the C12.19 BINARY Element. This value is common to all of the C12.22 Node's interfaces, including those that are not IP based (thus not conforming to this specification). For this reason, the ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than, and SHALL NOT be smaller than, the actual length needed to encode a broadcast/multicast Native IP Address per Figure 2. When this is the case, the C12.22 Native IP Address SHALL be padded with zero (0) to fill the Table's BINARY data Element.
当广播/多播本机IP地址编码在ANSI C12.19表的二进制数据元素中时，传输的本机地址元素的大小由ACT_NETWORK_TBL.Native_Address_LEN定义（见[1]和[2]中的表121）。这是放置在C12.19二进制元素中的实际八位字节数。该值对于所有C12.22节点的接口都是通用的，包括那些不基于IP的接口（因此不符合本规范）。因此，ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN可大于且不得小于图2所示的对广播/多播本机IP地址进行编码所需的实际长度。在这种情况下，C12.22本机IP地址应填充零（0），以填充表格的二进制数据元素。
The IPv4 network directed broadcast address can be computed by performing a bitwise OR between the bit complement of the subnet mask of the target IP subnet and the IP address of any host on that IP subnet.
IPv4网络定向广播地址可以通过在目标IP子网的子网掩码的位补码和该IP子网上任何主机的IP地址之间执行按位或运算来计算。
This section defines a C12.22 Node's usage of the Connection-Oriented (CO) and Connectionless (CL) transport layer protocols -- TCP and UDP, respectively.
本节定义了C12.22节点对面向连接（CO）和无连接（CL）传输层协议（TCP和UDP）的使用。
A C12.22 IP Node's use of TCP and UDP is based on its registered capabilities as defined in its configuration parameters (flags) and as expressed in the Node's accepted registration attributes [1]:
C12.22 IP节点对TCP和UDP的使用基于其配置参数（标志）中定义的注册功能以及节点接受的注册属性[1]中表示的注册功能：
CL Flag = <connection-type>.CONNECTIONLESS_MODE_SUPPORTED;
CL Accept Flag = <connection-type>.ACCEPT_CONNECTIONLESS;
CO Flag = <connection-type>.CONNECTION_MODE_SUPPORTED; and
CO Accept Flag = <connection-type>.ACCEPT_CONNECTIONS.
CL Flag = <connection-type>.CONNECTIONLESS_MODE_SUPPORTED;
CL Accept Flag = <connection-type>.ACCEPT_CONNECTIONLESS;
CO Flag = <connection-type>.CONNECTION_MODE_SUPPORTED; and
CO Accept Flag = <connection-type>.ACCEPT_CONNECTIONS.
The mapping of the connection-type parameters to the IP-based transport variants that a C12.22 Node MAY support is defined in Table 1.
表1中定义了C12.22节点可能支持的连接类型参数到基于IP的传输变体的映射。
+------+------+----------+----------+-------------------------------+
| CL | CO | CL | CO | IP Transport Mode Supported |
| Flag | Flag | Accept | Accept | |
| | | Flag | Flag | |
+------+------+----------+----------+-------------------------------+
| 0 | 0 | x | x | Invalid |
| 0 | 1 | 0 | 0 | TCP, Active-OPEN |
| 0 | 1 | 0 | 1 | TCP, Passive- and Active-OPEN |
| 0 | 1 | 1 | 0 | Invalid |
| 0 | 1 | 1 | 1 | Invalid |
| 1 | 0 | 0 | 0 | UDP, Active-OPEN |
| 1 | 0 | 0 | 1 | Invalid |
| 1 | 0 | 1 | 0 | UDP, Passive- and Active-OPEN |
| 1 | 0 | 1 | 1 | Invalid |
| 1 | 1 | 0 | 0 | UDP, Active-OPEN; TCP |
| | | | | Active-OPEN |
| 1 | 1 | 0 | 1 | UDP, Active-OPEN; TCP, |
| | | | | Passive- and Active-OPEN |
| 1 | 1 | 1 | 0 | UDP, Passive- and |
| | | | | Active-OPEN; TCP, Active-OPEN |
| 1 | 1 | 1 | 1 | UDP, Passive- and |
| | | | | Active-OPEN; TCP, Passive- |
| | | | | and Active-OPEN |
+------+------+----------+----------+-------------------------------+
+------+------+----------+----------+-------------------------------+
| CL | CO | CL | CO | IP Transport Mode Supported |
| Flag | Flag | Accept | Accept | |
| | | Flag | Flag | |
+------+------+----------+----------+-------------------------------+
| 0 | 0 | x | x | Invalid |
| 0 | 1 | 0 | 0 | TCP, Active-OPEN |
| 0 | 1 | 0 | 1 | TCP, Passive- and Active-OPEN |
| 0 | 1 | 1 | 0 | Invalid |
| 0 | 1 | 1 | 1 | Invalid |
| 1 | 0 | 0 | 0 | UDP, Active-OPEN |
| 1 | 0 | 0 | 1 | Invalid |
| 1 | 0 | 1 | 0 | UDP, Passive- and Active-OPEN |
| 1 | 0 | 1 | 1 | Invalid |
| 1 | 1 | 0 | 0 | UDP, Active-OPEN; TCP |
| | | | | Active-OPEN |
| 1 | 1 | 0 | 1 | UDP, Active-OPEN; TCP, |
| | | | | Passive- and Active-OPEN |
| 1 | 1 | 1 | 0 | UDP, Passive- and |
| | | | | Active-OPEN; TCP, Active-OPEN |
| 1 | 1 | 1 | 1 | UDP, Passive- and |
| | | | | Active-OPEN; TCP, Passive- |
| | | | | and Active-OPEN |
+------+------+----------+----------+-------------------------------+
Table 1: C12.22 Node Parameters to IP Transport Mapping
表1:C12.22节点参数到IP传输映射
Every C12.22 IP Node MUST support at least one of the unicast CO or CL operating capabilities (as advertised in Decade 12, "Node Network Control Tables" [1], where available, and as registered using the C12.22 Registration Service [1]).
每个C12.22 IP节点必须支持至少一种单播CO或CL操作能力（如第12个十年“节点网络控制表”[1]中公布的，如可用，并使用C12.22注册服务注册[1]）。
General rules:
一般规则：
1. A C12.22 IP Node that implements [CL Accept=1] SHALL receive incoming UDP C12.22 Messages on its registered Native IP Address (IP address and port number).
1. 实现[CL Accept=1]的C12.22 IP节点应在其注册的本机IP地址（IP地址和端口号）上接收传入UDP C12.22消息。
2. A C12.22 IP Node that implements [CO Accept=1] SHALL receive incoming TCP connections on its registered Native IP Address (IP address and port number).
2. 实现[CO Accept=1]的C12.22 IP节点应在其注册的本机IP地址（IP地址和端口号）上接收传入TCP连接。
3. A C12.22 IP Relay that forwards a UDP C12.22 Message to a C12.22 IP Node on the C12.22 IP Network Segment SHALL send the C12.22 Message to the C12.22 IP Node's registered Native IP Address (IP address and port number).
3. 将UDP C12.22消息转发至C12.22 IP网段上的C12.22 IP节点的C12.22 IP中继应将C12.22消息发送至C12.22 IP节点的注册本机IP地址（IP地址和端口号）。
4. A C12.22 IP Relay that forwards a TCP C12.22 Message to a C12.22 IP Node on the C12.22 IP Network Segment MAY use an established TCP connection to that C12.22 IP Node, or it SHALL establish a new TCP connection to the C12.22 IP Node's registered Native IP Address (IP address and port number).
4. 将TCP C12.22消息转发到C12.22 IP网段上的C12.22 IP节点的C12.22 IP中继可以使用到该C12.22 IP节点的已建立TCP连接，或者它应建立到C12.22 IP节点的已注册本机IP地址（IP地址和端口号）的新TCP连接。
5. A C12.22 IP Node that implements [CL=1] SHOULD set the source port number in outbound UDP C12.22 Messages to its registered port number. When the target UDP C12.22 IP Node is reachable using direct messaging (as defined in [1]), the C12.22 IP Node MAY set the source port number to a UDP port number that is different than its registered port number.
5. 实现[CL=1]的C12.22 IP节点应将出站UDP C12.22消息中的源端口号设置为其注册的端口号。当目标UDP C12.22 IP节点可以使用直接消息（如[1]中所定义）访问时，C12.22 IP节点可以将源端口号设置为与其注册端口号不同的UDP端口号。
6. When the registered Native IP Address of a C12.22 IP Node does not include the OPTIONAL port number, then port 1153 SHALL be assumed and used as the registered port number.
6. 当C12.22 IP节点的注册本机IP地址不包括可选端口号时，应假定端口1153并将其用作注册端口号。
7. All C12.22 IP Nodes SHOULD use port 1153 in their Native IP Address when registering.
7. 所有C12.22 IP节点在注册时应在其本机IP地址中使用端口1153。
A C12.22 IP Node that supports this mode SHALL NOT monitor for unsolicited incoming C12.22 Messages via UDP. As a result, the C12.22 IP Node is incapable of receiving unsolicited C12.22 Messages using UDP.
支持此模式的C12.22 IP节点不得通过UDP监控未经请求的传入C12.22消息。因此，C12.22 IP节点无法使用UDP接收未经请求的C12.22消息。
The C12.22 IP Node MAY enter the Active-OPEN UDP state by initiating an unsolicited UDP transmission to a Target C12.22 IP Node, which is expected to implement the Passive-OPEN UDP mode.
C12.22 IP节点可通过发起到目标C12.22 IP节点的未经请求的UDP传输进入主动开放UDP状态，该目标C12.22 IP节点预计将实现被动开放UDP模式。
C12.22 IP Nodes SHOULD use their registered UDP port number, or if not yet registered, then they SHOULD use port 1153 as the source port number for all UDP C12.22 IP Messages.
C12.22 IP节点应使用其注册的UDP端口号，如果尚未注册，则应使用端口1153作为所有UDP C12.22 IP消息的源端口号。
A C12.22 IP Node that operates in this mode SHALL be capable of receiving solicited and unsolicited C12.22 Messages from other C12.22 IP Nodes. The C12.22 Node MAY change the port number that it monitors by using the <native-address> parameter of the ANSI C12.22 Registration Service. The C12.22 IP Node MAY initiate unsolicited Active-OPEN UDP transmissions to other C12.22 IP Nodes that implement the Passive-OPEN UDP mode.
在此模式下运行的C12.22 IP节点应能够从其他C12.22 IP节点接收请求和非请求的C12.22消息。C12.22节点可以使用ANSI C12.22注册服务的<native address>参数更改其监视的端口号。C12.22 IP节点可以发起到实现被动开放UDP模式的其他C12.22 IP节点的主动开放UDP传输。
When operating in this mode, the C12.22 IP Nodes SHALL use their registered UDP port number as the source port number for all UDP C12.22 IP Messages.
在此模式下运行时，C12.22 IP节点应使用其注册的UDP端口号作为所有UDP C12.22 IP消息的源端口号。
All C12.22 IP Relays SHALL support the Passive-OPEN UDP mode. C12.22 Authentication Hosts and C12.22 Notification Hosts that implement UDP SHALL support the Passive-OPEN UDP mode. For all other C12.22 IP Nodes, the Passive-OPEN UDP mode is the RECOMMENDED mode when implementing UDP.
所有C12.22 IP继电器应支持无源开放UDP模式。实现UDP的C12.22身份验证主机和C12.22通知主机应支持被动开放UDP模式。对于所有其他C12.22 IP节点，在实现UDP时，建议使用被动开放UDP模式。
A C12.22 IP Node that supports this mode SHALL NOT monitor for inbound TCP connections. As a result, the node is incapable of accepting incoming connections via TCP. The C12.22 IP Node MAY initiate TCP connections to Target C12.22 IP Nodes, which are expected to implement the Passive-OPEN TCP mode.
支持此模式的C12.22 IP节点不应监视入站TCP连接。因此，节点无法通过TCP接受传入连接。C12.22 IP节点可启动到目标C12.22 IP节点的TCP连接，目标C12.22 IP节点预计将实现被动开放TCP模式。
In this mode, C12.22 Messages exchanged by a pair of associated C12.22 IP Nodes can only be communicated through any of the TCP connections that were initiated by the C12.22 IP Node that implements this mode. The loss or closure of a connection SHALL NOT automatically result in the termination of the C12.22 associations between the peer nodes. In order to continue exchanging C12.22 Messages without loss of association, the initiating C12.22 IP Node MAY re-establish new TCP connections with the peer node, or use existing connections to the peer node. The termination of the C12.22 Application associations is dependent upon C12.22 Application timeout attributes and C12.22 link management services (such as Procedure 25, "Network Interface Control" [1]).
在此模式下，由一对关联的C12.22 IP节点交换的C12.22消息只能通过实现此模式的C12.22 IP节点启动的任何TCP连接进行通信。连接的丢失或关闭不应自动导致对等节点之间的C12.22关联终止。为了在不丢失关联的情况下继续交换C12.22消息，发起C12.22 IP节点可以与对等节点重新建立新的TCP连接，或者使用到对等节点的现有连接。C12.22应用程序关联的终止取决于C12.22应用程序超时属性和C12.22链路管理服务（如程序25，“网络接口控制”[1]）。
A C12.22 IP Node that operates in this mode SHALL monitor and accept incoming TCP connections. The C12.22 Node MAY change the port number that it monitors by using the <native-address> parameter of the ANSI C12.22 Registration Service. The C12.22 IP Node MAY initiate Active-OPEN TCP connections to other C12.22 IP Nodes that implement the Passive-OPEN TCP mode.
在此模式下运行的C12.22 IP节点应监控并接受传入的TCP连接。C12.22节点可以使用ANSI C12.22注册服务的<native address>参数更改其监视的端口号。C12.22 IP节点可以启动到其他C12.22 IP节点的主动开放式TCP连接，这些节点实现被动开放式TCP模式。
In this mode, C12.22 Messages exchanged by a pair of associated C12.22 IP Nodes can arrive through any of the TCP connections that were established by either node. The loss or closure of a connection SHALL NOT automatically result in the termination of the C12.22 associations between the peer nodes. In order to continue exchanging C12.22 Messages without loss of association, either C12.22 IP Node MAY re-establish new TCP connections with the peer node, or use existing connections to the peer node. The termination of the C12.22 Application associations is dependent upon C12.22 Application timeout attributes and C12.22 link management services (such as Procedure 25, "Network Interface Control" [1]).
在此模式下，由一对关联的C12.22 IP节点交换的C12.22消息可以通过任一节点建立的任何TCP连接到达。连接的丢失或关闭不应自动导致对等节点之间的C12.22关联终止。为了在不丢失关联的情况下继续交换C12.22消息，C12.22 IP节点可以与对等节点重新建立新的TCP连接，或者使用与对等节点的现有连接。C12.22应用程序关联的终止取决于C12.22应用程序超时属性和C12.22链路管理服务（如程序25，“网络接口控制”[1]）。
All C12.22 IP Relays SHALL support the Passive-OPEN TCP mode. C12.22 Authentication Hosts and C12.22 Notification Hosts that implement TCP SHALL support Passive-OPEN TCP mode. For all other C12.22 IP Nodes, Passive-OPEN TCP mode is the RECOMMENDED mode when implementing TCP.
所有C12.22 IP继电器应支持被动开放TCP模式。实现TCP的C12.22身份验证主机和C12.22通知主机应支持被动开放TCP模式。对于所有其他C12.22 IP节点，在实施TCP时，建议使用被动开放TCP模式。
C12.22 IP Nodes MAY use TCP in one of two ways: bi-directional traffic flow or uni-directional traffic flow.
C12.22 IP节点可以两种方式之一使用TCP：双向流量或单向流量。
When TCP connections are used, any new or established TCP connection between the two C12.22 IP Nodes MAY be used equivalently by the C12.22 IP Nodes to send and to receive C12.22 Messages. This is the RECOMMENDED and default mode of operation because ANSI C12.22 requires the transport network to be reliable and connectionless (per connectionless-mode ACSE). For this reason, ANSI C12.22 defines peer-to-peer application associations and not peer-to-peer connections.
使用TCP连接时，两个C12.22 IP节点之间的任何新的或已建立的TCP连接可被C12.22 IP节点等效地用于发送和接收C12.22消息。这是推荐的默认操作模式，因为ANSI C12.22要求传输网络可靠且无连接（根据无连接模式ACSE）。因此，ANSI C12.22定义了对等应用程序关联，而不是对等连接。
It is known that some C12.22 implementations have been deployed in which TCP is used for uni-directional traffic flow. For these types of implementations, an established TCP connection SHALL be used by the initiator of that connection to send C12.22 Messages and by the
众所周知，已经部署了一些C12.22实现，其中TCP用于单向流量。对于这些类型的实现，已建立的TCP连接应由该连接的发起方用于发送C12.22消息，并由
target node (that accepted the connection) to receive C12.22 Messages. If a C12.22 IP Node wishes to send a C12.22 Message to a peer C12.22 IP Node, it MUST establish and use a new TCP connection, or use an existing TCP connection that it had previously initiated, for its outbound uni-directional traffic flow.
接收C12.22消息的目标节点（接受连接）。如果C12.22 IP节点希望向对等C12.22 IP节点发送C12.22消息，则必须为其出站单向流量建立并使用新的TCP连接，或使用其先前启动的现有TCP连接。
For increased interoperability, the initiator of the connection SHOULD accept incoming C12.22 Messages on that connection in case the target node attempts to use the connection for bi-directional traffic flow.
为了提高互操作性，如果目标节点试图使用连接进行双向通信流，连接的发起方应在该连接上接受传入的C12.22消息。
Uni-directional use of TCP is a special mode of operation; it is NOT RECOMMENDED because multiple one-way channel communication is not described by ANSI C12.22, and it utilizes one-half of the TCP connection capability. As a result, it doubles the number of TCP connections used to communicate C12.22 Messages and thus could become a burden when a large number of connections are required.
单向使用TCP是一种特殊的操作模式；不建议这样做，因为ANSI C12.22没有描述多个单向通道通信，并且它利用了TCP连接能力的一半。因此，它将用于通信C12.22消息的TCP连接数量增加了一倍，因此在需要大量连接时可能会成为负担。
A C12.22 IP Node's use of broadcast/multicast is based on its capabilities as defined in its configuration parameters (flags) and as expressed in the Node's accepted registration attributes [1] (<connection-type>.BROADCAST_AND_MULTICAST_SUPPORTED). The mapping of the C12.22 IP Node's Broadcast/Multicast parameter (flag) to IP broadcast/multicast usage is defined in Table 2.
C12.22 IP节点对广播/多播的使用基于其配置参数（标志）中定义的功能以及节点可接受的注册属性[1]（<connection type>.broadcast\u和\u multicast\u SUPPORTED）中表示的功能。表2中定义了C12.22 IP节点的广播/多播参数（标志）到IP广播/多播使用的映射。
C12.22 Broadcast and IP Broadcast/Multicast Supported
Multicast Supported
Flag
---------------------- ----------------------------------------------
0 The C12.22 IP Node does not accept IP
broadcast, and it does not accept IP multicast
messages.
1 The C12.22 IP Node accepts both IP broadcast
(IPv4 only) and IP multicast messages (IPv4
and IPv6).
C12.22 Broadcast and IP Broadcast/Multicast Supported
Multicast Supported
Flag
---------------------- ----------------------------------------------
0 The C12.22 IP Node does not accept IP
broadcast, and it does not accept IP multicast
messages.
1 The C12.22 IP Node accepts both IP broadcast
(IPv4 only) and IP multicast messages (IPv4
and IPv6).
Table 2: C12.22 to IP Broadcast/Multicast Mapping
表2:C12.22到IP广播/多播映射
If a C12.22 IP Node is configured to accept IP broadcast and multicast messages, it SHALL join the "All C1222 Nodes" multicast group (see Section 4.6, "IP Multicast", above), and SHALL use the default port 1153. In addition, it SHALL accept IP network directed or limited (local scope) broadcast messages sent to port 1153. Note that successful communication using network directed broadcast requires configuration of network routers, which by default SHALL NOT forward directed broadcasts as per RFC 2644 [17].
如果C12.22 IP节点配置为接受IP广播和多播消息，则其应加入“所有C1222节点”多播组（见上文第4.6节“IP多播”），并应使用默认端口1153。此外，它应接受发送至端口1153的IP网络定向或有限（本地范围）广播消息。注意，使用网络定向广播的成功通信需要配置网络路由器，根据RFC 2644[17]，默认情况下，网络路由器不得转发定向广播。
An initiating C12.22 IP Node MAY send any C12.22 Message using UDP or TCP. However, in accordance with Section 5.3.2.4.12, "Resolve Service", of ANSI C12.22, it is RECOMMENDED that the C12.22 Resolve Request Message be transported using UDP/IP multicast when the Native IP Address of the Target C12.22 Node is not known. The use of UDP/IP multicast is preferred over the use of IP network directed or limited broadcast; therefore, when UDP/IP multicast is supported, its use is RECOMMENDED over network broadcast.
启动C12.22 IP节点可以使用UDP或TCP发送任何C12.22消息。但是，根据ANSI C12.22第5.3.2.4.12节“解析服务”，当目标C12.22节点的本机IP地址未知时，建议使用UDP/IP多播传输C12.22解析请求消息。使用UDP/IP多播优于使用IP网络定向或有限广播；因此，当支持UDP/IP多播时，建议通过网络广播使用它。
When sending via UDP a large C12.22 Message that exceeds the path MTU, the sender SHALL segment the ACSE APDU in accordance with the ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such that the size of the resulting IP datagram does not exceed the path MTU and thus avoids UDP packet fragmentation. The fundamental issue with fragmentation exists for both IPv4 and IPv6. Section 3.2 of RFC 5405 [18] provides additional guidelines for determining the appropriate UDP message size. When the path MTU is not known, the sender SHALL follow the guidelines stipulated in Section 3.2 of RFC 5405 [18]: for IPv4, use the smaller of 576 bytes and the first-hop MTU [19], and for IPv6, use 1280 bytes [20]. Sending large APDUs via UDP may lead to network congestion. For more information on avoiding network congestion see Section 5.6, "Congestion Control".
当通过UDP发送超过路径MTU的大型C12.22消息时，发送方应根据ANSI C12.22数据报分段和重组算法对ACSE APDU进行分段，以使生成的IP数据报的大小不超过路径MTU，从而避免UDP数据包分段。IPv4和IPv6都存在碎片化的根本问题。RFC 5405[18]第3.2节提供了确定适当UDP消息大小的附加指南。当路径MTU未知时，发送方应遵循RFC 5405[18]第3.2节规定的指南：对于IPv4，使用576字节和第一跳MTU[19]中较小的一个，对于IPv6，使用1280字节[20]。通过UDP发送大型APDU可能会导致网络拥塞。有关避免网络拥塞的更多信息，请参见第5.6节“拥塞控制”。
When a Target C12.22 IP Node receives a C12.22 Request Message from an initiating C12.22 IP Node, it SHALL send a C12.22 Response Message using the same transport protocol (i.e., TCP to TCP, UDP to UDP).
当目标C12.22 IP节点从发起C12.22 IP节点接收到C12.22请求消息时，它应使用相同的传输协议（即TCP到TCP、UDP到UDP）发送C12.22响应消息。
In the case of UDP, the target SHALL send the C12.22 Response Message to the source IP address and port number.
对于UDP，目标应向源IP地址和端口号发送C12.22响应消息。
The ANSI C12.22 standard provides a configuration parameter in the APDU's <calling-AE-qualifier>.URGENT attribute to mark a message as urgent. There are numerous IP-based technologies that enable enhanced levels of message delivery and quality of service. This specification does not define the technology to be used to send urgent messages over IP.
ANSI C12.22标准在APDU的<calling AE qualifier>紧急属性中提供了一个配置参数，用于将消息标记为紧急消息。有许多基于IP的技术可以提高消息传递级别和服务质量。本规范未定义用于通过IP发送紧急消息的技术。
Designers of unicast applications that implement the upper layers of C12.22 messaging over UDP SHOULD follow the congestion control guidelines in Section 3.1 of RFC 5405 [18].
通过UDP实现C12.22消息上层的单播应用程序的设计者应遵循RFC 5405[18]第3.1节中的拥塞控制指南。
For the transmission of C12.22 Messages that are greater than what the TCP initial window would be over a given Internet path, TCP SHOULD be used rather than UDP as the transport protocol. TCP's initial window depends on the maximum segment size (MSS), which in turn depends on the path MTU, and is computed according to formula (1) in RFC 3390 [21]. For unknown path MTUs, the smallest allowable MSS MUST be used, and the C12.22 Application SHOULD assume the maximum C12.22 Message size to be 2048 bytes. By using TCP, the C12.22 Application benefits from the built-in TCP congestion control mechanism.
对于在给定Internet路径上传输大于TCP初始窗口的C12.22消息，应使用TCP而不是UDP作为传输协议。TCP的初始窗口取决于最大段大小（MSS），而最大段大小又取决于路径MTU，并根据RFC 3390[21]中的公式（1）进行计算。对于未知路径MTU，必须使用允许的最小MSS，C12.22应用程序应假定最大C12.22消息大小为2048字节。通过使用TCP，C12.22应用程序受益于内置的TCP拥塞控制机制。
When UDP is the preferred transport mechanism, or when UDP multicast or broadcast are the preferred modes of communication, then the C12.22 Application SHOULD use C12.22 acknowledged Messages that are smaller than TCP's initial window over the return path, as computed by formula (1) in [21] and described above. The size of the C12.22 Message MAY be managed through the use of ANSI C12.22 EPSEM Partial Table Read/Write Service Requests and Responses.
当UDP是首选传输机制时，或者当UDP多播或广播是首选通信模式时，C12.22应用程序应使用C12.22确认消息，该消息小于TCP在返回路径上的初始窗口，如[21]中公式（1）所计算并如上所述。C12.22消息的大小可以通过使用ANSI C12.22 EPSEM部分表读/写服务请求和响应来管理。
The ANSI C12.22 Application Layer Security is defined in Section 5.3.4.13, "C12.22 Security Mechanism", of the ANSI C12.22 standard. The security mechanisms include provisions for message privacy and authentication, playback rejection, and message acceptance windows, as well as ANSI C12.19 [2] role-based data access and secured register mechanisms. The ANSI C12.22 Application Layer default security mechanism provides three options to choose from when sending C12.22 Messages:
ANSI C12.22应用层安全性在ANSI C12.22标准第5.3.4.13节“C12.22安全机制”中定义。安全机制包括对消息隐私和身份验证、回放拒绝和消息接受窗口的规定，以及ANSI C12.19[2]基于角色的数据访问和安全注册机制。ANSI C12.22应用层默认安全机制在发送C12.22消息时提供三个选项供选择：
1. Sending cleartext messages over the C12.22 Network [1], [5], which MAY result in altered C12.22 Messages and exposure to password sniffing attacks, as described in RFC 3552 [22].
1. 如RFC 3552[22]所述，通过C12.22网络发送明文信息[1]，[5]，可能会导致更改C12.22消息并暴露于密码嗅探攻击。
2. Sending of authenticated plaintext messages over the C12.22 Network [1], [5], which MAY result in password sniffing attacks as described in RFC 3552 [22].
2. 通过C12.22网络[1]，[5]发送经过身份验证的明文消息，这可能导致RFC 3552[22]中所述的密码嗅探攻击。
3. Sending of authenticated ciphertext over the C12.22 Network, providing for message and peer node authentication and privacy.
3. 通过C12.22网络发送经过身份验证的密文，提供消息和对等节点身份验证和隐私。
When option 1 is used, then it is RECOMMENDED that the network or transport layer provide authentication and confidentiality service. When option 2 is used, then it is RECOMMENDED that the network or transport layer provide confidentiality services. When option 3 is used, then no additional network or transport layer security services are necessary.
使用选项1时，建议网络或传输层提供身份验证和保密服务。使用选项2时，建议网络或传输层提供保密服务。如果使用选项3，则不需要额外的网络或传输层安全服务。
Additional transport or network layer security protocols are not required by ANSI C12.22, but they MAY be provided transparently by C12.22 IP Network Segment integrators (e.g., in C12.22 IP Relays) in order to improve on the security provisions cited above. However, any added transport security (e.g., Transport Layer Security (TLS), RFC 5246 [27]) or IP security (e.g., IPsec, RFC 4302 [25], RFC 4303 [26], RFC 5996 [28]) features SHALL act only to enhance (i.e., not be a substitute for, or an alteration of) the interoperable ANSI C12.22 and ANSI C12.19 security provisions, and SHALL NOT corrupt and SHALL NOT alter the C12.22 Message as presented by the C12.22 Application Layer.
ANSI C12.22不要求额外的传输或网络层安全协议，但C12.22 IP网段积分器（例如，在C12.22 IP中继中）可以透明地提供这些协议，以改进上述安全规定。但是，任何增加的传输安全性（例如，传输层安全性（TLS）、RFC 5246[27]）或IP安全性（例如，IPsec、RFC 4302[25]、RFC 4303[26]、RFC 5996[28]）功能只能用于增强（即，不能替代或更改）可互操作的ANSI C12.22和ANSI C12.19安全规定，并且不得损坏和改变C12.22应用层显示的C12.22消息。
The ANSI C12.22 [1] and ANSI C12.19 [2] standards provide for the transmission of keys and their storage in C12.19 End Devices (e.g., meters and head-end systems). The key management protocol (when and how keys are exchanged) is not described in the ANSI C12.22 [1] and ANSI C12.19 [2] standards, except to state that keys MAY not be readable from a C12.19 End Device (in response to a Read Service Request). It is RECOMMENDED that all C12.22 Nodes encrypt user information element key fields and passwords. It is also RECOMMENDED that all C12.22 Nodes mask user information element key fields and password fields of EPSEM Read Service Responses (e.g., by replacing all key and password bytes with zeros (0x00) or spaces (0x20)).
ANSI C12.22[1]和ANSI C12.19[2]标准规定了键的传输及其在C12.19终端设备（如仪表和前端系统）中的存储。ANSI C12.22[1]和ANSI C12.19[2]标准中未描述密钥管理协议（交换密钥的时间和方式），除非说明密钥可能无法从C12.19终端设备读取（响应读取服务请求）。建议所有C12.22节点加密用户信息元素密钥字段和密码。还建议所有C12.22节点屏蔽EPSEM读取服务响应的用户信息元素密钥字段和密码字段（例如，用零（0x00）或空格（0x20）替换所有密钥和密码字节）。
Legacy deployments exist that are not connected to the Internet, so there are some implementations that do not include security. It is likely that multi-homed C12.22 Nodes with interfaces to the Internet will exist in future deployments, so security mechanisms MUST be used by those C12.22 Nodes to ensure C12.22 Message authentication and confidentiality.
存在未连接到Internet的旧式部署，因此有些实施不包括安全性。在未来的部署中，可能会存在具有互联网接口的多宿C12.22节点，因此这些C12.22节点必须使用安全机制来确保C12.22消息的身份验证和机密性。
UDP and TCP port 1153, which is used for C12.22 communication over IP, is registered with IANA.
UDP和TCP端口1153用于通过IP进行C12.22通信，已向IANA注册。
Section 4.6, "IP Multicast", defines the use of multicast. The following multicast addresses have been registered by IANA for use by the ANSI C12.22 standard:
第4.6节“IP多播”定义了多播的使用。IANA已注册以下多播地址，供ANSI C12.22标准使用：
IPv4 -- "All C1222 Nodes" address 224.0.2.4
IPv4--“所有C1222节点”地址224.0.2.4
IPv6 -- "All C1222 Nodes" address FF0X::204
IPv6 -- "All C1222 Nodes" address FF0X::204
The authors wish to recognize Alexander Shulgin for providing valuable comments and for conducting feasibility testing in support of this work.
作者希望感谢Alexander Shulgin为支持这项工作提供了有价值的意见和进行可行性测试。
The following people have improved this document through thoughtful comments and suggestions: Fred Baker, Ralph Droms, Vijay Gurbani, Michael Stuber, Spencer Dawkins, Alfred Hoenes, Russ Housley, Paul Hoffman, Lars Eggert, and Sean Turner.
以下人员通过深思熟虑的评论和建议改进了本文件：弗雷德·贝克、拉尔夫·德罗姆斯、维杰·古巴尼、迈克尔·斯塔伯、斯宾塞·道金斯、阿尔弗雷德·霍恩斯、罗斯·霍斯利、保罗·霍夫曼、拉尔斯·艾格特和肖恩·特纳。
[1] ANSI, "Protocol Specification for Interfacing to Data Communication Networks", ANSI C12.22-2008, January 2009.
[1] ANSI，“数据通信网络接口协议规范”，ANSI C12.22-2008，2009年1月。
[2] ANSI, "Utility Industry End Device Data Tables", ANSI C12.19- 2008, February 2009.
[2] ANSI，“公用事业行业终端设备数据表”，ANSI C12.19-2008，2009年2月。
[3] IEEE, "Draft Standard for Utility Industry Metering Communication Protocol Application Layer (End Device Data Tables)", IEEE P1377-2010, October 2010.
[3] IEEE，“公用事业行业计量通信协议应用层（终端设备数据表）标准草案”，IEEE P1377-2010，2010年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] IEEE, "Standard for Local Area Network/Wide Area Network (LAN/ WAN) Node Communication Protocol to Complement the Utility Industry End Device Data Tables", IEEE P1703-2010, October 2010.
[5] IEEE，“补充公用事业行业终端设备数据表的局域网/广域网（LAN/WAN）节点通信协议标准”，IEEE P1703-2010，2010年10月。
[6] ISO/IEC, "Information Technology-Open Systems Interconnection-Connectionless Protocol for the Association Control Service Element: Protocol Specification", ISO/IEC 10035-1, 1995.
[6] ISO/IEC，“关联控制服务元件的信息技术开放系统互连无连接协议：协议规范”，ISO/IEC 10035-11995。
[7] ISO/IEC, "Information Technology-ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/ IEC 8825-1, 2002.
[7] ISO/IEC，“信息技术ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ISO/IEC 8825-12002。
[8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[8] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[9] 《传输控制协议》，标准7，RFC 793，1981年9月。
[10] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[10] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[11] Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[12] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[12] Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[13] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[13] Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 44432006年3月。
[14] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[14] Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，2006年8月。
[15] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[15] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[16] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[16] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[17] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[17] Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 26441999年8月。
[18] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[18] Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[19] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[19] Braden，R.，Ed.“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[20] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[20] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[21] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[21] 奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[22] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[22] Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[23] Measurement Canada, "Specification for Utility Industry Metering Communication Protocol Application Layer (End Device Data Tables)", Draft MC12.19, 2011.
[23] 加拿大计量局，“公用事业行业计量通信协议应用层规范（终端设备数据表）”，草案MC12.19，2011年。
[24] Measurement Canada, "Specification for Local Area Network/Wide Area Network (LAN/WAN) Node Communication Protocol to Complement the Utility Industry End Device Data Tables", Draft MC12.22, 2011.
[24] 加拿大计量局，“补充公用事业行业终端设备数据表的局域网/广域网（LAN/WAN）节点通信协议规范”，草案MC12.22，2011年。
[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[25] Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[26] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[27] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[27] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[28] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[28] Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Erenen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
Authors' Addresses
作者地址
Avygdor Moise Future DOS R&D Inc. #303 - 6707 Elbow Drive SW Calgary, Alberta T2V 0E5 Canada
Avygdor Moise Future DOS R&D Inc.#303-6707加拿大阿尔伯塔省卡尔加里西南肘道T2V 0E5
EMail: avy@fdos.ca
URI: http://www.fdos.ca
EMail: avy@fdos.ca
URI: http://www.fdos.ca
Jonathan Brodkin Future DOS R&D Inc. #303 - 6707 Elbow Drive SW Calgary, Alberta T2V 0E5 Canada
Jonathan Brodkin Future DOS R&D Inc.#303-6707加拿大阿尔伯塔省卡尔加里西南肘道T2V 0E5
EMail: jonathan.brodkin@fdos.ca
URI: http://www.fdos.ca
EMail: jonathan.brodkin@fdos.ca
URI: http://www.fdos.ca