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
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-オーバー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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。のセクション4.eで説明したように、コードのコンポーネントは、簡素化されたBSDライセンスのテキストを含める必要があり、この文書から抽出されました
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
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は、TCP経由でANSI C12.22メッセージの送信を規制する要件を定義し、（ANSI C12.22のOSIセッション、プレゼンテーション、およびアプリケーション層は、単一のアプリケーション層に縮小されていることによって）UDPは、IPネットワークに転送します。
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の、「C12.22ネットワークセグメントの詳細にC12.22ノード」、第5の動作の詳細に適用され、マッピングを覆い、符号化、および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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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]のACSは、ISO / IEC 10035から1ごとに符号化される[6] ASN.1基本符号化規則（BER）を使用して[7]。
Active-OPEN UDP
アクティブOPEN 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.
アクティブOPEN UDPを期待し、それがUDPを使用して、外国C12.22 IPノードから募り、着信C12.22メッセージを受信するローカルC12.22 IPノードによって使用される状態です。それは予想C12.22メッセージのすべてを受信したかC12.22メッセージのタイムアウトが発生したときに、ローカルC12.22 IPノードは、Active-OPEN UDPの状態を出ることができます。ローカルC12.22 IPノードは、外国C12.22からC12.22メッセージを募るために使用される送信元ポート番号と一致するローカルポート番号に到着する外国C12.22 IPノードから募っすべてC12.22応答メッセージを受信しますIPノード。
Active-OPEN TCP
アクティブOPEN 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].
アクティブOPEN TCPはTCPと外国C12.22 IPノードの登録ネイティブIPアドレスを使用して、完全に指定された外国C12.22 IPノードとのTCP接続を確立するためにローカルC12.22 IPノードによって使用される状態です。 [9]で定義されるようにアクティブオープンTCP状態は、ローカル「アクティブオープン」と同一です。
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.
一つ以上のEPSEMサービス要求を含む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.
一つ以上のEPSEMサービス応答を含むACSEユーザ情報要素が含まれている完全に組み立てC12.22 APDU、。
Connection
接続
A logical and physical binding between two or more users of a service [1].
論理サービスの2人の以上のユーザ間の結合の物理[1]。
EPSEM
Epsey
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.
用語「ネイティブアドレスは、」[1]そのC12.22ネットワークセグメント上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.
パッシブオープンUDPは、UDPを使用して、任意の外国C12.22 IPノードからの着信C12.22メッセージを期待して受信するローカルC12.22 IPノードによって使用される状態です。パッシブオープン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はTCPを使用して、不特定の外国C12.22 IPノードとのTCPコネクションを確立することを望んでいる地元のC12.22 IPノードによって使用される状態です。この場合、任意の外国C12.22 IPノードは限りローカルポートが外国C12.22 IPノードが使用するポートに一致するようローカルC12.22 IPノードに接続することができます。パッシブオープンTCP状態は「ローカルパッシブOPEN」は、[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 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ノードと同じセグメント上の他のすべてのノードに到達するためにいずれかのノードを可能にするネットワーク・インフラストラクチャを含みます。 C12.22 IPネットワークセグメント上のすべてC12.22 IPノードは、この仕様に応じて、同じネットワークおよびトランスポートプロトコル（図1及び2当たり）同じIPアドレス符号化方式を採用しています。
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アドレス、およびオプションのプロトコル識別子が続いてもよいオプションのポート番号を含みます。 4.3節で後述のようにネイティブのIPアドレスは、「ネイティブ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では、フィールドは、任意の2バイトのTCPやUDPのポート番号が続いているIPv4またはIPv6のバイナリネイティブIPアドレスを含まなければなりません。 TCPまたはUDPポート番号、存在する場合は、OPTIONAL一バイトのトランスポート・プロトコル識別子（IPv4またはIPv6の「次ヘッダ」の「プロトコル」）を行ってもよいです。トランスポート・プロトコル識別子をUDP及びTCPトランスポートの両方にUDPトランスポートのために17（0x11を）に設定し、又は6（0x06の）TCPトランスポートのために、またはしないように（不在）に設定しなければなりません。トランスポートプロトコルの値は（以下、「C12.22接続タイプおよびTCP / UDPトランスポート・モード」、コネクションレス（CL）とセクション5.1での接続指向（CO）のフラグを参照してください）C12.22ノードの登録属性と一致しなければなりません。
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 INTERFACE_CTRL_TBL要素NATIVE_ADDRESS）。 C12.22ネイティブアドレスの長さは、ANSI C12.22のアドレス長フィールド（例えば、ANSI C12.22登録サービス<アドレスの長さ>、ANSI C12.22で修飾されたサービス応答<ローカルアドレスの長さを>解決、およびANSI C12.19 ACT_NETWORK_TBL要素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を記録する唯一のネイティブ住所。このため、UDPとTCPのために異なるポート番号を登録したいC12.22 IPノードは異なるApTitlesを使用して二回登録する必要があります。
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表BINARYデータ要素で符号化されたときに、ネイティブAddress要素のサイズはACT_NETWORK_TBL.NATIVE_ADDRESS_LENによって定義される（表121を参照の[1]及び[2]）。これはC12.19 BINARY要素の内側に配置されているオクテットの実際の数です。この値は（したがって、この仕様に準拠しない）ベースのIPでないものを含むC12.22ノードのインタフェースの全てに共通です。このため、ACT_NETWORK_TBL.NATIVE_ADDRESS_LENがより大きくてもよい、と、これが事実である場合には、図1にあたり、ネイティブIPアドレスを符号化するために必要な実際の長さより小さくしてはならない、C12.22ネイティブIPアドレスが埋められますゼロ（0）表のBINARYデータ要素を埋めるために。
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に記載されているアドレスの長さのいずれにも一致しない場合において、実際のアドレスの長さは、すべての後続のバイナリゼロ（0×00）を剥離した後、次の最大値に上向きにアドレス長を調整することによって決定しなければなりません図1に示されています。
IANA (Internet Assigned Numbers Authority) has assigned port 1153 for UDP [8] and TCP [9] C12.22 IP Messages.
IANA（Internet Assigned Numbers Authority）は、[8]およびTCP UDPのための[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.
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.
UDPのC12.22 IPノードの使用、および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ノードはC12.22 IPネットワークセグメント、またはネイティブの発見のうち、ルートを提供C12.22 IPリレーのネイティブIPアドレスのネイティブIPアドレスの検出（例えば、発見を行う必要がある場合にはC12.22 IPネットワーク上のC12.22 IPマスターリレー）のIPアドレスは、C12.22 IPノードがIP LAN上のEPSEM解決サービス要求が含まれているC12.22メッセージを送信するためにIPマルチキャストを使用します。
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.
IPマルチキャストはC12.22ホストが共通C12.22マルチキャストグループApTitleで構成されC12.22ノードの多数（例えば、メートル）を読み取る必要があるとき、例えば、も望ましいです。 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ノードは、（そのローカルルータにC12.22マルチキャストグループ内（すなわち、リクエスト）メンバーシップを報告するには、最低でも[10]インターネットグループ管理プロトコルバージョン1（IGMPv1レポート）を使用しなければなりません秒）。 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ノードがメンバーシップを報告するために、（RFC 4443 [13]）、おそらくICMPv6の内マルチキャストリスナ探索バージョン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.
最小値としてのIGMPv1（RFC 1112 [10]）と共にスパースモード（PIM-SM）（RFC 4601 [14]） - C12.22 IPネットワークセグメント上の相互接続C12.22 IPノードは、プロトコル独立マルチキャストをサポートしなければならないルータ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ノード」マルチキャストグループが登録されている、及び、「IPバージョン6 RFC 4291で定義されるように224.0.2.4のIPv4マルチキャストアドレスとFF0X :: 204、Xは、スコープフィールドを表すのIPv6マルチキャストアドレスが割り当てられていますアドレス指定アーキテクチャ」[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ノードがブロードキャストおよびマルチキャストをサポートするように設定は（以下、「IPブロードキャスト/マルチキャストを使用する」、5.3節を参照）global-に参加するものとスコープマルチキャストアドレス、FF0E :: 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.
C12.22ネットワーク上の別のC12.22 IPノードに到達するために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.最小（ローカル最も）範囲（すなわち、リンクローカルスコープまたは他の事前構成されたスコープ）から出発し、C12.22 IPリレー発見の目的のためにC12.22 EPSEM解決サービス要求を送信します。
A. If no response is received, assign the next wider scope
level, then repeat steps (1) and (2) at the newly assigned
scope.
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のための上述したスコープの種類を提供しておらず、管理[16] RFC 2365にIPマルチキャスト仕様スコープと互換性があります。したがって、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ノードを含まなければなりません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アドレスを符号化するためBINARY要素を提供します。これらの表要素の符号化は、セクション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表BINARYデータ要素で符号化された場合、送信ネイティブAddress要素のサイズはACT_NETWORK_TBL.NATIVE_ADDRESS_LENによって定義される（表121を参照の[1]及び[2]） 。これはC12.19 BINARY要素の内側に配置されているオクテットの実際の数です。この値は（したがって、この仕様に準拠しない）ベースのIPでないものを含むC12.22ノードのインタフェースの全てに共通です。このため、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.
それぞれ、TCPとUDP - このセクションでは、C12.22ノードの接続指向（CO）の使用とコネクションレス（CL）トランスポート層プロトコルを定義します。
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]:
その構成パラメータ（フラグ）およびノードの受け入れ登録属性で表現されるよう定義されるようなTCPおよびUDPのC12.22 IPノードの使用は、その登録された機能に基づいている[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：IPトランスポートのマッピングにC12.22ノードのパラメータ
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ノードが[ディケイド12でアドバタイズ[1]、利用可能な場合、（「ノードネットワーク制御表の」ユニキャストCO又はCL操作機能の少なくとも一つをサポートし、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).
【CLが受け入れ= 1]、その登録されたネイティブIPアドレス（IPアドレス及びポート番号）で着信UDP C12.22メッセージを受けなければならない器具1. A C12.22 IPノード。
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).
[COが受け入れ= 1]、その登録されたネイティブIPアドレス（IPアドレス及びポート番号）上の着信TCP接続を受けなければならない器具2 A C12.22 IPノード。
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).
C12.22 IPネットワークセグメント上C12.22 IPノードにUDP C12.22メッセージを転送します3. A C12.22 IPリレーは、（C12.22 IPノードの登録ネイティブIPアドレスにC12.22メッセージを送信しなければなりません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).
C12.22 IPネットワークセグメント上C12.22 IPノードにTCP C12.22メッセージを転送する4. A 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.
用具[CL = 1]は、その登録されたポート番号に発信UDP C12.22メッセージの送信元ポート番号を設定すべきである。5. A C12.22 IPノード。ターゲットUDP C12.22 IPノードは、C12.22 IPノードが登録されているポート番号とは異なるUDPポート番号を送信元ポート番号を設定してもよい（[1]で定義されるように）直接メッセージを使用して到達可能である場合。
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.
C12.22 IPノードの登録ネイティブIPアドレスは、ポート1153が登録されているポート番号と仮定し、使用しなければならない、オプションのポート番号が含まれていない6。
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送信を開始することで、Active-OPEN 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ノードへの迷惑のActive-OPEN 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モードをサポートします。 UDPはパッシブオープンUDPモードをサポートする実装C12.22認証ホストとC12.22通知ホスト。 UDPを実装する際に、他の全てのC12.22 IPノードの場合、パッシブオープン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ノードへのActive-OPEN 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モードをサポートするTCPを実装C12.22認証ホストとC12.22通知ホスト。 TCPを実装する際に、他の全てのC12.22 IPノードの場合、パッシブオープン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接続が使用されている場合は、2つのC12.22 IPノード間の任意の新規または確立されたTCP接続が送信するとC12.22メッセージを受信するC12.22 IPノードで同等に使用されるかもしれません。 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 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 IPノードにC12.22メッセージを送信したい場合は、それが確立し、新しいTCP接続を使用するか、またはそれ以前にその発信ユニのために、開始したことを、既存のTCP接続を使用する必要があります-directionalトラフィックフロー。
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]（<接続タイプ> .BROADCAST_AND_MULTICAST_SUPPORTED）。 IPブロードキャスト/マルチキャストの使用にC12.22 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：IPブロードキャスト/マルチキャストへのマッピングC12.22
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ブロードキャストおよびマルチキャストメッセージを受け付けるように構成されている場合、それは、（上記セクション4.6、「IPマルチキャスト」を参照してください）「すべてのC1222ノード」マルチキャストグループに参加するものとし、ではデフォルトのポート1153を使用しなければなりませんまた、ネットワークを使用して成功した通信は、ブロードキャストは、デフォルトで前方にRFC 2644に従って放送を向けられていないものとネットワークルータの構成[17]を必要と向かうことポート1153注意に送信されたIPネットワークが指向又は限定（ローカルスコープ）ブロードキャストメッセージを受け入れるSHALL 。
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メッセージを送信することができます。しかし、第5.3.2.4.12に従って、ANSI C12.22の、「サービスの解決」、C12.22の解決要求メッセージはUDP / IPマルチキャストを使用して転送することを推奨されている場合、ターゲットC12のネイティブIPアドレス0.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メッセージを送信する場合、送信者は、得られたIPデータグラムのサイズを超えないようにANSI C12.22データグラム分割と再構成アルゴリズムに従ってセグメントACSE APDUを、SHALLパスMTUので、UDPパケットの断片化を回避することができます。フラグメンテーションとの根本的な問題は、IPv4とIPv6の両方のために存在します。 RFC 5405のセクション3.2 [18]適切なUDPメッセージサイズを決定するための追加の指針を提供します。パスMTUが知られていない場合、送信者は[18] RFC 5405のセクション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要求メッセージを受信すると、それが同じトランスポートプロトコル（UDPにTCP、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の<呼び出し-AE-修飾子> .URGENT属性に設定パラメータを提供します。メッセージ配信やサービスの品質の高レベルを可能にする、多数の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の初期ウィンドウは、順番にパスMTUに依存する最大セグメントサイズ（MSS）に依存し、RFC 3390 [21]式（1）に従って計算されます。未知の経路のMTUのために、最小許容MSSを使用しなければなりません、そしてC12.22出願は、2048バイトに最大C12.22メッセージサイズを想定すべきです。 TCPを使用することで、内蔵されたTCPの輻輳制御機構からC12.22アプリケーションの利点。
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の初期ウィンドウよりも小さいメッセージを認識したときに（1）[21]で上述しました。 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メッセージを送信するときから選択する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. [22] [1]、[5]、RFC 3552に記載されるように、改変されたC12.22メッセージおよび攻撃をスニッフィングパスワードへの暴露をもたらす可能性がある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. RFC 3552 [22]に記載されているように[1]、[5]、パスワード盗聴攻撃をもたらす可能性があるC12.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]）の特徴はSHALL追加しました相互運用可能ANSI C12.22およびANSI C12.19セキュリティ対策（すなわち、代用、またはの変更ではない）、および強化するためにのみ行動破損してはならず、C12が提示するようC12.22メッセージを変更しないもの0.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キーはC12.19エンドデバイスから読み取り可能ではないかもしれない状態に以外[2]標準（読むサービスリクエストに応答して）。すべてのC12.22のノードは、ユーザ情報要素のキーフィールドとパスワードを暗号化することが推奨されます。また、推奨されるEPSEM読むサービス応答の全てC12.22ノードマスクユーザ情報要素キーフィールドおよびパスワードフィールド（例えば、ゼロ（0×00）またはスペース（とすべてのキーおよびパスワードのバイトを置き換えることによっては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
IPv6の - "すべてのC1222ノード" アドレス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.
フレッド・ベイカー、ラルフDroms、ビジェイGurbani、マイケルStuber、スペンサードーキンスアルフレッドHoenes、ラスHousley、ポール・ホフマン、ラースエッゲルト、とショーン・ターナー：次の人は思慮深いコメントと提案を通してこのドキュメントを改善しています。
[1] ANSI, "Protocol Specification for Interfacing to Data Communication Networks", ANSI C12.22-2008, January 2009.
、ANSI C12.22-2008、2009年1月[1] ANSI、 "データ通信ネットワークへのインタフェースのためのプロトコル仕様"。
[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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）"、ISO / IEC 8825から1、2002。
[8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[8]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[9]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[10] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[10]デアリング、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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ビダ、R.、エド。、およびL.コスタ、エド。、 "マルチキャストリスナ発見バージョン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]コンタ、A.、デアリング、S.、およびM.グプタ、エド。、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様について"、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]フェナー、B.、ハンドリー、M.、ホルブルック、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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[16] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[16]マイヤー、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]エッゲルト、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]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[20] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[20]デアリング、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.パートリッジ、RFC 3390、2002年10月 "TCPの初期ウィンドウを増やします"。
[22] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
、BCP 72、RFC 3552、2003年7月[22]レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"。
[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]測定カナダ、ドラフトMC12.22、2011年「ユーティリティ産業エンドデバイスのデータテーブルを補完するために、ローカルエリアネットワーク/ワイドエリアネットワーク（LAN / WAN）ノード通信プロトコルの仕様」。
[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[25]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[26]ケント、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン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
6707エルボードライブSWカルガリー、アルバータT2V 0E5カナダ - Avygdorモイーズ今後DOS R＆D社の＃303
EMail: avy@fdos.ca URI: http://www.fdos.ca
電子メール：URI avy@fdos.ca：http://www.fdos.ca
Jonathan Brodkin Future DOS R&D Inc. #303 - 6707 Elbow Drive SW Calgary, Alberta T2V 0E5 Canada
ジョナサンBrodkin今後DOS R＆D社の＃303から6707エルボードライブSWカルガリー、アルバータT2V 0E5カナダ
EMail: jonathan.brodkin@fdos.ca URI: http://www.fdos.ca
電子メール：jonathan.brodkin@fdos.ca URI：http://www.fdos.ca