[要約] RFC 6142は、ANSI C12.22、IEEE 1703、およびMC12.22のIPトランスポートに関する仕様をまとめたものです。このRFCの目的は、これらの規格をIPネットワーク上で使用するためのプロトコル仕様を提供することです。
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 Advanced Metering Infrastructure（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化された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
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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].
このドキュメント全体で、「C12.22リレー」または「ANSI C12.19デバイス」のように、「ANSI 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]ごとにエンコードされます。
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からのC12.22メッセージを求めるために使用されるソースポート番号に一致するローカルポート番号に到達する外国のC12.22 IPノードから求められたすべてのC12.22応答メッセージを受信します。IPノード。
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
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
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ネットワークセグメントに配置され、インターネットプロトコルを使用して通信する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.
この仕様で定義されているIPベースのプロトコルを実装し、IPルーター、スイッチ、ブリッジを使用してC12.22リレーを使用せずに互いに通信できるすべてのC12.22 IPノードのコレクション。
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.
ACSEユーザー情報要素を含む完全に組み立てられたC12.22 APDU。
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.
1つ以上のEpsemサービス応答を含むACSEユーザー情報要素を含む完全に組み立てられたC12.22 APDU。
Connection
繋がり
A logical and physical binding between two or more users of a service [1].
サービスの2人以上のユーザー間の論理的および物理的結合[1]。
EPSEM
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リクエストメッセージの送信を開始するC12.22 IPノードの役割。
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ネットワークセグメント[1]でC12.22ノードに到達するために使用できる輸送アドレスを指します。この仕様では、ネイティブアドレスはネイティブ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.
Passive-Open 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].
Passive-Open TCPは、TCPを使用して不特定の外国C12.22 IPノードとTCP接続を確立したいローカルC12.22 IPノードで使用される状態です。この場合、外国の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リクエストメッセージの受信に応答するC12.22 IPノードの役割。
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 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ノードと、1つのノードが同じセグメント上の他のすべてのノードに到達できるようにするネットワークインフラストラクチャで構成されています。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とワンが含まれる場合があります。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.19デバイステーブルでのストレージのC12.22ネイティブアドレスをエンコードするバイナリフィールドを定義します。このRFCでは、フィールドにはIPv4またはIPv6バイナリネイティブIPアドレスが含まれ、その後にオプションの2バイトTCPまたはUDPポート番号が続きます。TCPまたはUDPポート番号は、存在する場合、オプションの1バイトトランスポートプロトコル識別子（IPv4の「プロトコル」またはIPv6の「次のヘッダー」）が続く場合があります。輸送プロトコル識別子は、UDP輸送の場合は17（0x11）、またはTCP輸送の場合は6（0x06）に設定するか、UDP輸送とTCP輸送の両方で設定されていない（存在しない）。トランスポートプロトコル値は、セクション5.1、「C12.22接続タイプおよびTCP/UDP輸送モード」のC12.22ノードの登録属性（Connectionless（CL）およびConnectionOriented（CO）Flagsを参照）と一致するものとします。
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登録サービス<Native-Address>、ANSI C12.22サービス応答<Local-Address>、およびAnsi C12.22で伝達できます。ANSI C12.19 interface_ctrl_tbl要素native_address）。C12.22ネイティブアドレスの長さは、ANSI C12.22アドレスの長さフィールドによって適格です（例：ANSI C12.22登録サービス<アドレスレングス>、ANSI C12.22解決サービス応答<ローカルアドレス - レングス>、およびANSI C12.19 ACT_NETWORK_TBL Element Native_Address_Len）。
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登録サービスでは、登録された各Aptitleで1つのネイティブアドレスのみを記録することができます。このため、UDPおよびTCPに異なるポート番号を登録したいC12.22 IPノードは、異なるアプリットルを使用して2回登録する必要があります。
The binary Native IP Address fields SHALL be encoded in network byte order, as shown in Figure 1.
図1に示すように、バイナリネイティブIPアドレスフィールドは、ネットワークバイトの順序でエンコードされなければなりません。
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 7 | ADDR4 | P |T|
+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 16 | ADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6+Port 18 | ADDR6 | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]の表121を参照）。これは、C12.19バイナリ要素内に配置された実際のオクテットの数です。この値は、IPベースではないものを含むすべてのC12.22ノードのインターフェイスに共通しています（したがって、この仕様に準拠していません）。このため、ACT_NETWORK_TBL.NIVET_ADDRESS_LENは、図1.の場合、ネイティブ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ノードは、宛先ポート番号として1153設定されたすべてのC12.22アプリケーションアソシエーションの開始メッセージリクエストを送信するものとします。
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.
IPファイアウォールまたはアクセス制御リスト（ACLS）シールドC12.22ノードとIPネットワークは、ポート1153およびネットワーク管理者によって割り当てられ登録されているポート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.
Unicastに加えて、ANSI C12.22プロトコルでは、ネットワークからのマルチキャストメッセージ配信サービスのサポートが必要です。C12.22 IPノードがネイティブIPアドレス発見を実行する必要がある場合（たとえば、C12.22 IPネットワークセグメントからルートを提供するC12.22 IPリレーのネイティブIPアドレスの発見、またはネイティブの発見C12.22 IPマスターリレーのIPアドレスC12.22 IPネットワーク）、C12.22 IPノードはIPマルチキャストを使用して、IP LANにEPSEM Resolveサービス要求を含むC12.22メッセージを送信します。
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ホストは、C12.22 IPネットワークセグメントのすべてのC12.22ノードに到達するEPSEM読み取りサービス要求を含む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ノードは、インターネットグループ管理プロトコル1（IGMPV1）[10]を最小限に使用して、C12.22マルチキャストグループのメンバーシップをローカルルーターに報告（リクエスト）するものとします（リクエスト）。s）。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ノードは、おそらくICMPv6（RFC 4443 [13]）内で、メンバーシップを報告するために、マルチキャストリスナーディスカバリーバージョン2（MLDV2）（RFC 3810 [12]）を使用するものとします。
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のC12.22 IPノードを相互接続するルーターは、C12.22 IPネットワークセグメントをサポートする必要があります。IPv6のIPv4または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は「All C1222ノード」マルチキャストグループを登録し、224.0.2.4のIPv4マルチキャストアドレスとFF0X :: 204のIPv6マルチキャストアドレスを割り当てました。ここで、XはRFC 4291で定義されているスコープフィールドを表します。アーキテクチャへの対処」[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;および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.
IPv6 C12.22 IPノードは、IPマルチキャストメッセージを開始してC12.22ネットワークで別の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. 最小の（ローカル）スコープ（つまり、リンクローカルスコープまたは別の事前に構成されたスコープ）から始めて、C12.22 IPリレー発見を目的としてC12.22 Epsem Resolveサービスリクエストを送信します。
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 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.
IPv4の場合、すべてのC12.22 IPリレー、C12.22 IPマスターリレー、およびブロードキャスト/マルチキャストをサポートするように構成されたすべてのC12.22 IPノードは、224.0.2.4の割り当てられたマルチキャストアドレスに参加するものとします。このグローバルアドレスは、IPv6について上記のスコープのタイプを提供しておらず、RFC 2365の管理上スコープIPマルチキャスト仕様と互換性もありません[16]。したがって、C12.22 IPマルチキャストメッセージの伝播を制限する別の手法が必要です。IPv4マルチキャストスコープを制御するための利用可能な手法の1つは、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.
この手法の実装では、管理ドメインには少なくとも1つのC12.22 IPリレーを含める必要があり、管理ドメイン内のすべてのC12.22 IPノードは、そのC12.22 IPリレーに到達するために十分に大きいTTLで構成する必要があります。
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ネットワークセグメントのマルチキャストの代替または代替品として適していません。IPブロードキャストはIPv6ではサポートされておらず、IPv4の範囲が限られています。ただし、この仕様は、制御された管理ドメイン内で放送されるIPネットワーク指向/ローカルスコープ（アドレス255.255.255.255）の使用を排除するものではありません（RFC 2644 [17]）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 6 |BADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 7 |BADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 4 |MADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 6 |MADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 7 |MADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 16 | MADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 18 | MADDR6 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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）は、ANSI C12.22が使用するためにIANAによって割り当てられたものです。
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]の表121を参照、[2]）。これは、C12.19バイナリ要素内に配置された実際のオクテットの数です。この値は、IPベースではないものを含むすべてのC12.22ノードのインターフェイスに共通しています（したがって、この仕様に準拠していません）。このため、Act_network_tbl.native_address_lenは、ブロードキャスト/マルチキャストネイティブIPアドレスをエンコードするために必要な実際の長さよりも大きく、図2. 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）およびConnectionLess（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.
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.
C12.22ノードがサポートできるIPベースの輸送バリアントへの接続タイプパラメーターのマッピングは、表1に定義されています。
+------+------+----------+----------+-------------------------------+
| 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動作機能の少なくとも1つをサポートする必要があります（10年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. C12.2222 IPネットワークセグメントのC12.22 IPノードにUDP C12.22メッセージを転送するC12.22 IPリレーは、C12.22 IPノードの登録ネイティブIPアドレス（IPアドレス）にC12.22メッセージを送信するものとします。およびポート番号）。
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 Nodeに転送するC12.22 IPリレーは、C12.22 IPネットワークセグメントのC12.22 IPノードにそのC12.22 IPノードに確立されたTCP接続を使用するか、新しいTCPを確立する場合があります。C12.22 IPノードの登録ネイティブIPアドレス（IPアドレスとポート番号）への接続。
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ノードは、パッシブオープンUDPモードを実装すると予想されるターゲットC12.22 IPノードへの未承諾UDP伝送を開始することにより、アクティブオープン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ポート番号を使用するか、まだ登録されていない場合は、すべてのUDP C12.22 IPメッセージのソースポート番号としてポート1153を使用する必要があります。
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登録サービスの<ネイティブアドレス>パラメーターを使用して、モニターするポート番号を変更する場合があります。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 C12.22 IPメッセージのソースポート番号として登録されたUDPポート番号を使用するものとします。
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モードをサポートするものとします。C12.22認証ホストとC12.22 UDPを実装するC12.22通知ホストは、パッシブオープンUDPモードをサポートするものとします。他のすべてのC12.22 IPノードの場合、Passive-Open 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ノードは、パッシブオープン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登録サービスの<ネイティブアドレス>パラメーターを使用して、モニターするポート番号を変更する場合があります。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 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モードをサポートするものとします。C12.22認証ホストとC12.22 TCPを実装するC12.22通知ホストは、パッシブオープンTCPモードをサポートするものとします。他のすべてのC12.22 IPノードの場合、Passive-Open 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ノードは、2方向の交通流または一方向の交通流の2つの方法のいずれかで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接続を使用する場合、2つのC12.22 IPノード間の新しいまたは確立されたTCP接続をC12.22 IPノードによって同等に使用して、C12.22メッセージを送信および受信することができます。ANSI C12.22では、トランスポートネットワークが信頼性が高くてコネクションレスであることが必要なため、これは推奨されたデフォルトの動作モードです。このため、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 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の実装が展開されており、TCPが一方向のトラフィックフローに使用されていることが知られています。これらのタイプの実装では、確立されたTCP接続が、C12.22メッセージを送信するためにその接続のイニシエーターによって使用され、ターゲットノード（接続を受け入れた）がC12.22メッセージを受信する必要があります。C12.22 IPノードがC12.22メッセージをピアC12.22 IPノードに送信したい場合、新しいTCP接続を確立および使用するか、以前に開始した既存のTCP接続を使用して、アウトバウンドUNIに対して使用する必要があります。 - 方向の交通流。
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接続の数を2倍にするため、多数の接続が必要な場合に負担になる可能性があります。
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_and_multicast_supported）で表されます。C12.22 IPノードのブロードキャスト/マルチキャストパラメーター（FLAG）からIPブロードキャスト/マルチキャスト使用量のマッピングを表2に示します。
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を使用するものとします。さらに、IPネットワーク指示または制限（ローカルスコープ）ポート1153に送信されたブロードキャストメッセージを受け入れるものとします。ネットワーク向けブロードキャストを使用した通信の成功には、ネットワークルーターの構成が必要であることに注意してください。。
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、「Resolve Service」に従って、ターゲットC12のネイティブIPアドレスがUDP/IPマルチキャストを使用してC12.22 Resolve Requestメッセージを輸送することをお勧めします。.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".
PATH MTUを超える大きなC12.22メッセージをUDP経由で送信する場合、送信者はANSI C12.22データグラムのセグメンテーションと再組み立てアルゴリズムに従ってACSE APDUをセグメント化するものとします。Path MTUであるため、UDPパケットの断片化を回避します。断片化の基本的な問題は、IPv4とIPv6の両方に存在します。RFC 5405 [18]のセクション3.2は、適切なUDPメッセージサイズを決定するための追加のガイドラインを提供します。PATH MTUが不明な場合、送信者はRFC 5405のセクション3.2 [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からUDPからUDPへのTCP）を使用して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.
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アプリケーションは、式で計算されたように、リターンパス上のTCPの初期ウィンドウよりも小さいC12.22の確認されたメッセージを使用する必要があります。（1）[21]および上記の説明。C12.22メッセージのサイズは、ANSI C12.22 Epsem Partial Table読み取り/書き込みサービスのリクエストと応答を使用して管理できます。
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メッセージを送信するときに選択できる3つのオプションを提供します。
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]を介してクリアテキストメッセージを送信します。
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セキュリティ条項を強化する（つまり、代わりに、または変更の代わりではない）のみ行動します。.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.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.
インターネットに接続されていないレガシーの展開が存在するため、セキュリティを含まない実装がいくつかあります。インターネットへのインターフェイスを備えたマルチホームのC12.22ノードが将来の展開に存在する可能性が高いため、C12.22メッセージの認証と機密性を確保するために、これらのC12.22ノードでセキュリティメカニズムを使用する必要があります。
UDP and TCP port 1153, which is used for C12.22 communication over IP, is registered with IANA.
IPを介したC12.22通信に使用されるUDPおよびTCPポート1153は、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マルチキャスト」は、マルチキャストの使用を定義しています。以下のマルチキャストアドレスは、ANSI C12.22標準で使用するためにIANAによって登録されています。
IPv4 -- "All C1222 Nodes" address 224.0.2.4
IPv4-「すべてのC1222ノード」アドレス224.0.2.4
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.
著者は、貴重なコメントを提供し、この作業をサポートする実現可能性テストを実施したことで、アレクサンダーシュルギンを認識したいと考えています。
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-1、1995。
[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-1、2002。
[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] Postel、J。、「トランスミッションコントロールプロトコル」、STD 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。、「Multicastリスナーディスカバリーバージョン2（MLDV2）のIPv6」、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 4443、2006年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。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年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 2644、1999年8月。
[18] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[18] Eggert、L。and G. Fairhurst、「アプリケーションデザイナー向けのUnicast 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。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[20] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[20] Deering、S。and 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] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、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。and 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] 測定カナダ、「ユーティリティ業界のメーター通信プロトコルアプリケーションレイヤー（エンドデバイスデータテーブル）の仕様」、Draft 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）ノード通信プロトコルの仕様、ユーティリティ業界のエンドデバイスデータテーブルを補完する」、Draft 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。、「セキュリティペイロード（ESP）のカプセル化IP」、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、「The Transport Layer Security（TLS）Protocolバージョン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. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年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 ELBOW DRIVE SW CALGARY、ALBERTA T2V 0E5 CANADA
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
ジョナサンブロドキンフューチャーDOS R＆D Inc.＃303-6707 ELBOW DRIVE SW CALGARY、ALBERTA T2V 0E5 CANADA
EMail: jonathan.brodkin@fdos.ca
URI: http://www.fdos.ca