Network Working Group A. Moise
Internet-Draft J. Brodkin
Intended Status: Informational Future DOS R&D Inc.
Expires: November 15, 2010 May 15, 2010
ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP
draft-c1222-transport-over-ip-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 15, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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.
Moise & Brodkin Expires November 15, 2010 [Page 1]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
Table of Contents
1. Introduction....................................................2
1.1. Terminology................................................3
1.2. Definitions................................................3
2. The C12.22 IP Network Segment...................................6
2.1. Composition of a C12.22 IP Network Segment.................6
2.2. Native IP Address..........................................7
2.3. Encoding of Native IP Addresses............................7
2.4. Standardized Port Numbers..................................8
2.5. Use of UDP Source Port 0...................................9
2.6. IP Multicast...............................................9
2.7. IP Broadcast..............................................11
2.8. Encoding of Multicast and Broadcast Addresses.............11
3. IP Message Transport...........................................13
3.1. C12.22 Connection Types and TCP/UDP Transport Modes.......13
3.2. IP Message Transport Details..............................14
3.2.1. TCP and UDP Port Use.................................14
3.2.2. Active-listen UDP (CL=1, CL Accept=0)................14
3.2.3. Passive-listen UDP (CL=1, CL Accept=1)...............15
3.2.4. Active-OPENs TCP Mode (CO=1, CO Accept=0)............15
3.2.5. Passive-OPENs TCP Mode (CO=1, CO Accept=1)...........16
3.2.6. TCP and C12.22 Message Directionality................16
3.3. Using IP Broadcast/Multicast..............................17
3.4. Transport Protocol Decisions..............................18
3.4.1. Unicast Versus Multicast Versus Broadcast............18
3.4.2. Sending Large C12.22 APDUs Using UDP.................18
3.4.3. Choice of Protocol for C12.22 Response APDUs.........18
3.5. Quality of Service........................................18
4. Security Considerations........................................19
5. IANA Considerations............................................19
6. References.....................................................19
6.1. Normative References......................................19
6.2. Informative References....................................21
7. Acknowledgments................................................21
8. Authors' Addresses.............................................22
1. Introduction
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 SmartGrid. The messaging services are tailored for, but not
limited to, the exchange of the data Tables Elements defined and co-
published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [4].
Moise & Brodkin Expires November 15, 2010 [Page 2]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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 and the IP networking.
1.1. Terminology
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 [5].
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 is based on the ANSI C12.22-2008 [1] and ANSI
C12.19-2008 [2] definitions as revised by IEEE 1703-2009 [6] and IEEE
1377-2010 [3].
1.2. Definitions
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 [6], and MC12.22 [7] protocol.
Terms prefixed by C12.22 or C12.19, which are not defined here, can
be resolved in [1] [6] [7] or [2] [3] [4].
ACSE
Association Control Service Element. In the context of this
specification and of [1], ACSEs are encoded per ISO/IEC 10035-1
[8] using the ASN.1 BER [9].
Active-listen UDP
Active-listen UDP is a temporary process used by a local C12.22
IP Node to expect and receive incoming C12.22 Messages from a
foreign C12.22 IP Node using the UDP protocol. The local C12.22
IP Node SHALL solicit the incoming C12.22 Messages from the
foreign C12.22 IP Node using the foreign C12.22 IP Node's
registered Native IP Address. The local C12.22 IP Node MAY exit
Active-listen UDP process 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 SHALL receive all C12.22
Response Messages solicited from the foreign C12.22 IP Node that
Moise & Brodkin Expires November 15, 2010 [Page 3]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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 TCP
Active-OPEN TCP is a process used by a local C12.22 IP Node to
establish a TCP connection with a fully-specified foreign C12.22
IP Node using the TCP protocol and the foreign C12.22 IP Node's
registered Native IP Address. The Active-OPEN TCP process is
identical to "local active OPEN" defined in [11].
APDU
Application Protocol Data Unit. In the context of the ANSI
C12.22 Application, it is an ACSE C12.22 Message.
ACSE PDU
ACSE Protocol Data Unit; same as APDU.
ApTitle
An ANSI C12.22 Application-process Title. An ApTitle is a name
for a system-independent application activity that exposes
application services to the application agent; e.g., a set of
application service elements that together perform all or part of
the communication aspects of an application process. An ApTitle
is encoded as a unique registered (as per [1]) object identifier.
C12.22 IP Node
A C12.22 Node that is located on a C12.22 IP Network Segment and
communicates using the IP protocol.
C12.22 IP Network Segment
A collection of all C12.22 IP Nodes that implement the IP-based
protocols, as defined in this specification, and can communicate
with each other using IP routers, switches, and bridges and
without the use of a C12.22 Relay.
C12.22 IP Relay
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.
Moise & Brodkin Expires November 15, 2010 [Page 4]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
C12.22 Message
An APDU that is also a fully assembled or a segment of a C12.22
Request Message or a C12.22 Response Message. The C12.22 Message
described in this specification MUST be encoded using [9].
C12.22 Request Message
A fully assembled C12.22 APDU that contains an ACSE user
information element, which includes one or more EPSEM service
requests.
C12.22 Response Message
A fully assembled C12.22 Message APDU that contains an ACSE user
information element, which includes one or more EPSEM service
responses.
Connection
A logical and physical binding between two or more users of a
service (ref. [1]).
EPSEM
Extended Protocol Specification for Electronic Metering. EPSEM
defines structures and services used to encode multiple requests
and responses for use by devices such as gas, water, electricity,
and related electronic modules or appliances.
Initiating C12.22 IP Node
A temporary role of a C12.22 IP Node in which it initiates the
transmission of a C12.22 Request Message.
Native Address
The term Native Address refers to the network address of a C12.22
Node on its C12.22 Network Segment. In this specification, the
Native Address is the IP address plus the associated port number
used in communications by a C12.22 IP Node on the C12.22 IP
Network Segment.
Native IP Address
The binary IP address and the OPTIONAL port number used by a
C12.22 IP Node to encode a Native Address in a C12.22 Message or
in a C12.19 Table Element of an IP Node interface.
Moise & Brodkin Expires November 15, 2010 [Page 5]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
Passive-listen UDP
Passive-listen UDP is a process used by a local C12.22 IP Node to
expect and receive incoming C12.22 Messages from any foreign
C12.22 IP Node using the UDP protocol. When the Passive-listed
UDP process is active, the local C12.22 IP Node SHALL accept all
C12.22 Messages that arrive at the local port number that was
registered by the local C12.22 IP Node.
Passive-OPEN TCP
Passive-OPEN TCP is a process used by a local C12.22 IP Node that
wants to establish a TCP connection with an unspecified foreign
C12.22 IP Node using the TCP protocol. 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 process is identical to "local
passive OPEN" defined in [11].
Responding C12.22 IP Node
A temporary role of a C12.22 IP Node in which it responds to the
reception of a C12.22 Request Message.
Target C12.22 IP Node
The C12.22 IP Node that is the destination for a C12.22 Message.
2. The C12.22 IP Network Segment
This section defines the characteristics of the C12.22 IP Network
Segment.
2.1. Composition of a C12.22 IP Network Segment
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.
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 and the same
network and transport protocols in accordance with this
specification.
Moise & Brodkin Expires November 15, 2010 [Page 6]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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.
2.2. Native IP Address
The IP address and the port number of a C12.22 IP Node on a C12.22 IP
Network Segment are collectively referred to as the Native IP
Address.
When the Native Address of a C12.22 IP Node is communicated within
the payload of a C12.22 Message it SHALL be encoded as described in
Section 2.3. Encoding of Native IP Addresses.
The IP address of the C12.22 IP Node SHOULD 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 2.4. Standardized Port
Numbers).
The IP address MAY be hard-coded, manually entered, or allocated
automatically and/or dynamically by an IP network mechanism such as
DHCP. 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.
2.3. Encoding of Native IP Addresses
ANSI C12.22 defines binary fields for encoding a C12.22 Native
Address for transport within C12.22 Messages. In this RFC the fields
SHALL contain an IPv4 or an IPv6 binary native IP network address
that is followed by an OPTIONAL two-byte TCP or UDP port number.
ANSI C12.22 allows these fields to be conveyed in select ANSI C12.22
service elements (e.g., ANSI C12.22 Registration Service <native-
address> parameter, 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> parameter, ANSI C12.22 Resolve Service response
<local-address-length>, and ANSI C12.19 ACT_NETWORK_TBL Element
NATIVE_ADDRESS_LEN).
The binary Native IP Address fields SHALL be encoded in network byte
order as shown in Figure 1.
Moise & Brodkin Expires November 15, 2010 [Page 7]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
Actual Native IP Address (ADDR) and Port (P)
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-
IPv4 | 4 | | ADDR4 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 + port | 6 | | ADDR4 | P |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 |16 | | ADDR6 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 + port |18 | | ADDR6 | P |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Encoding of the Native IP Addresses for ANSI C12.22
When an ANSI C12.22 Native Address is encoded in ANSI C12.19 Tables'
BINARY data Elements then the size of the native address Element is
defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (See [1] [2] Table
121). 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.
2.4. Standardized Port Numbers
IANA (Internet Assigned Numbers Authority) has assigned port 1153 for
UDP [10] and TCP [11] C12.22 IP Messages.
By default, C12.22 IP Nodes SHALL send all C12.22 Application
Association initiation message requests set with 1153 as the
destination port number.
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.
Moise & Brodkin Expires November 15, 2010 [Page 8]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
Any IP firewalls or Access Control Lists (ACLs) shielding a C12.22
device MUST be configured to forward UDP and TCP traffic destined to
port 1153 and other ports that are assigned and registered by the LAN
administrator, in order to maintain the continuity of the C12.22 IP
Network Segment.
2.5. Use of UDP Source Port 0
Although [10] 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.
Further details of C12.22 IP Node's use of UDP, and of TCP, are given
in Section 3. IP Message Transport.
2.6. IP Multicast
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 uses IP Multicast to send a
C12.22 Message that contains an EPSEM Resolve Service Request on the
IP LAN.
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.
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 IGMP
version 1 (IGMPv1) [12] 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 [13].
Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14]
possibly within ICMPv6 RFC 4443 [15]) to report membership.
Moise & Brodkin Expires November 15, 2010 [Page 9]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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 [16]) along with IGMPv1 (RFC 1112 [12]) as a minimum
for IPv4, or MLDv2 for IPv6 (RFC 3810 [14]). It is RECOMMENDED that
they implement IGMPv3 [13]. 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.
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, the IP Version 6 Addressing Architecture [17].
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 3.3. Using IP Broadcast/Multicast) SHALL join the global
scope multicast address, FF0E::204, as well as all of the assigned,
reduced scope, multicast addresses:
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 is RECOMMENDED in order to limit
unnecessary propagation of C12.22 IP multicast Messages.
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:
1. Starting with the smallest (local-most) scope, link-local (or a
pre-configured scope), send the C12.22 EPSEM Resolve Service
Request for C12.22 IP Relay discovery.
2. Listen for a response from a C12.22 IP Relay; then:
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.
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.
Moise & Brodkin Expires November 15, 2010 [Page 10]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
A C12.22 IPv6 Relay SHALL use the global scope for any C12.22 message
destined for the global Internet.
This specification does not preclude the use of the unassigned scope
values defined in [17]; those scope values MAY be used on a private
basis, or through mutual operating agreements.
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[18]. 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.
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. A TTL threshold
SHOULD be defined and configured on all border routers linking the
administrative domain to the global Internet such that the routers
forward on their Internet interfaces only those 224.0.2.4 multicast
packets that have a TTL exceeding the threshold value.
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. A
C12.22 IPv4 Relay SHOULD use a TTL that exceeds the threshold for any
C12.22 message destined for the global Internet.
2.7. IP Broadcast
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, and specifies a minimum requirement in Section 2.8.
Encoding of Multicast and Broadcast Addresses.
2.8. Encoding of Multicast and Broadcast Addresses
ANSI C12.22 Tables provide binary Elements for encoding a Native
Broadcast or Multicast Address for transport within a C12.22 Message.
The encoding of these Table Elements is identical to that defined is
Section 2.3. Encoding of Native IP Addresses. These fields SHALL be
used as shown in Figure 2.
Moise & Brodkin Expires November 15, 2010 [Page 11]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
Actual IP Address (ADDR) and Port (P)
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast | 4 | |BADDR4 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast | 6 | |BADDR4 | P |
+Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast | 4 | |MADDR4 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast | 6 | |MADDR4 | P |
+Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast |16 | | MADDR6 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast |18 | | MADDR6 | P |
+Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encoding of broadcast/multicast native IP addresses
The IPv4 and IPv6 multicast addresses, MADDR4 and MADDR6,
respectively, are those assigned by IANA for use by ANSI C12.22.
When a broadcast/multicast Native IP Address is encoded in 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 [1] [2] Table 121). 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
broadcast/multicast 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.
Moise & Brodkin Expires November 15, 2010 [Page 12]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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.
3. IP Message Transport
This section defines a C12.22 Node's usage of the Connection-Oriented
(CO) and Connectionless (CL) transport layer protocols, TCP and UDP,
respectively.
3.1. C12.22 Connection Types and TCP/UDP Transport Modes
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]:
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 type of TCP and
UDP transports that a C12.22 Node MAY support is defined in Table 1.
Table 1: C12.22 Node Parameters to IP Transport Mapping
CL CO CL Accept CO Accept
Flag Flag Flag Flag IP Transport Mode Supported
---- ---- ---- ---- --------------------------------------
0 0 x x Invalid
0 1 0 0 TCP, Active-OPENs
0 1 0 1 TCP, Passive- and Active-OPENs
0 1 1 0 Invalid
0 1 1 1 Invalid
1 0 0 0 UDP, Active-listen
1 0 0 1 Invalid
1 0 1 0 UDP, Passive- and Active-listen
1 0 1 1 Invalid
1 1 0 0 UDP, Active-listen; TCP Active-OPENs
1 1 0 1 UDP, Active-listen;
TCP, Passive- and Active-OPENs
1 1 1 0 UDP, Passive- and Active-listen;
TCP, Active-OPENs
1 1 1 1 UDP, Passive- and Active-listen;
TCP, Passive- and Active-OPENs
--------------------------------------------------------------------
Moise & Brodkin Expires November 15, 2010 [Page 13]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
Every C12.22 IP Node MUST support at least one of unicast CO or CL
operating capabilities (as advertized in Decade 12, Network Tables
[1], where available, and as registered using the C12.22 Registration
Service [1]).
3.2. IP Message Transport Details
3.2.1. TCP and UDP Port Use
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).
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).
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).
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).
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.
6. A C12.22 IP Node that implements [CL=1] MAY set the source
port number in outbound UDP C12.22 Messages to a different UDP
source port number if the target UDP C12.22 IP Node is
reachable using direct messaging (as defined in [1]).
7. 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.
8. All C12.22 IP Nodes SHOULD use port 1153 in their Native IP
Address when registering.
3.2.2. Active-listen UDP (CL=1, CL Accept=0)
Moise & Brodkin Expires November 15, 2010 [Page 14]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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.
The C12.22 IP Node MAY enter the Active-listen UDP process by
initiating an unsolicited UDP transmission to a Target C12.22 IP
Node, which is expected to implement the Passive-listen UDP mode.
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.
3.2.3. Passive-listen UDP (CL=1, CL Accept=1)
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-listen UDP transmissions to other C12.22 IP Nodes that
implement the Passive-listen UDP mode.
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.
All C12.22 IP Relays SHALL support the Passive-listen UDP mode.
C12.22 Authentication Hosts and C12.22 Notification Hosts that
implement UDP SHALL support Passive-listen UDP mode. For all other
C12.22 IP Nodes, Passive-listen UDP mode is the RECOMMENDED mode when
implementing UDP.
3.2.4. Active-OPENs TCP Mode (CO=1, CO Accept=0)
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-OPENs TCP mode.
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
Moise & Brodkin Expires November 15, 2010 [Page 15]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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]).
3.2.5. Passive-OPENs TCP Mode (CO=1, CO Accept=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-
OPENs TCP connections to other C12.22 IP Nodes that implement the
Passive-OPENs TCP mode.
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]).
All C12.22 IP Relays SHALL support the Passive-OPENs TCP mode.
C12.22 Authentication Hosts and C12.22 Notification Hosts that
implement TCP SHALL support Passive-OPENs TCP mode. For all other
C12.22 IP Nodes, Passive-OPENs TCP mode is the RECOMMENDED mode when
implementing TCP.
3.2.6. TCP and C12.22 Message Directionality
C12.22 IP Nodes MAY use TCP in one of two ways: bi-directional
traffic flow or uni-directional traffic flow.
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.
Moise & Brodkin Expires November 15, 2010 [Page 16]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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 (who 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.
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.
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 is required.
While this mode of operation is not explicitly supported in the ANSI
C12.22 standard, it MAY be made possible through mutual operating
agreements. The means by which nodes are configured to enact the
uni-directional use of TCP is not defined in this specification or in
the ANSI C12.22 standard; it is left for future consideration.
3.3. Using IP Broadcast/Multicast
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.
Table 2: C12.22 to IP Broadcast/Multicast Mapping
C12.22 Broadcast and
Multicast Supported
Flag IP Broadcast/Multicast Supported
---- -------------------------------------------------
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).
Moise & Brodkin Expires November 15, 2010 [Page 17]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
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 2.6. IP Multicast), 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 are not supposed
to forward directed broadcasts as per RFC 2644 [19].
3.4. Transport Protocol Decisions
3.4.1. Unicast Versus Multicast Versus Broadcast
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, this specification RECOMMENDEDS 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.
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.
3.4.2. Sending Large C12.22 APDUs Using UDP
When sending a large C12.22 Message via UDP, whereby the ACSE PDU
size exceeds the UDP datagram maximum data length (65527 bytes), the
initiating C12.22 IP Node SHALL segment the ACSE PDU in accordance
with ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such
that each APDU segment fits within the UDP data field.
3.4.3. Choice of Protocol for C12.22 Response APDUs
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).
In the case of UDP, the target SHALL send the C12.22 Response Message
to the source IP address and port number.
3.5. Quality of Service
The ANSI C12.22 standard provides a configuration parameter in the
APDU's <calling-AE-qualifier>.URGENT 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 messaged over IP.
Moise & Brodkin Expires November 15, 2010 [Page 18]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
4. Security Considerations
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 AES-128/EAX 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. Additional Transport or Network
layer security protocols are not required but MAY be provided
transparently by network integrators. However, any added Transport
or IP Network layer security features SHALL act only to enhance and
preserve (i.e., not be a substitute for, or an alteration of) the
ANSI C12.22 and ANSI C12.19 (interoperable) security provisions.
5. IANA Considerations
UDP and TCP port 1153, which is used for C12.22 communication over
IP, is registered with IANA.
Section 2.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:
IPv4 - "All C1222 Nodes" address 224.0.2.4
IPv6 - "All C1222 Nodes" address FF0X::204
6. References
6.1. Normative References
[1] ANSI, "Protocol Specification for Interfacing to Data
Communication Networks", ANSI C12.22-2008, approved January
9, 2009.
[2] ANSI, "Utility Industry End Device Data Tables", ANSI C12.19-
2008, approved February 24, 2009.
[3] IEEE, "Draft Standard for Utility Industry Metering
Communication Protocol Application Layer (End Device Data
Tables)", IEEE P1377/D4, May 2010.
[4] Measurement Canada, "Draft Specification for Utility Industry
Metering Communication Protocol Application Layer (End Device
Data Tables)", MC12.19, 2010.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Moise & Brodkin Expires November 15, 2010 [Page 19]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
[6] IEEE, "Standard for Local Area Network/Wide Area Network
(LAN/WAN) Node Communication Protocol to Complement the
Utility Industry End Device Data Tables", IEEE 1703/D5,
revised May 2010.
[7] Measurement Canada, "Draft Specification for Local Area
Network/Wide Area Network (LAN/WAN) Node Communication
Protocol to Complement the Utility Industry End Device Data
Tables", MC12.22, 2010.
[8] ISO/IEC, "Information Technology-Open Systems
Interconnection-Connectionless Protocol for the Association
Control Service Element: Protocol Specification", ISO/IEC
10035-1, 1995.
[9] 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.
[10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[11] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[12] Deering, S.E., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[13] Cain, B., Deering, S., Kouvelas, I., Fenner, B., Thyagarajan,
A., "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
[14] Vida, R., Costa, L., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[15] Conta, A., Deering, S., Gupta, M., "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 4443, March 2006.
[16] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) ", RFC 4601, August 2006.
[17] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Moise & Brodkin Expires November 15, 2010 [Page 20]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
[18] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[19] Senie, D., "Changing the Default for Directed Broadcasts in
Routers", BCP 34, RFC 2644, August 1999.
6.2. Informative References
[Will be added as appropriate]
7. Acknowledgments
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, Vijay Gurbani, Alfred Hoenes
and Michael Stuber.
Moise & Brodkin Expires November 15, 2010 [Page 21]
Internet Draft draft-c1222-transport-over-ip-03.txt May 2010
8. Authors' Addresses
Avygdor Moise
Future DOS R&D Inc.
#303 - 6707 Elbow Drive SW
Calgary, Alberta, T2V 0E5
Canada
Email: avy@fdos.ca
Jonathan Brodkin
Future DOS R&D Inc.
#303 - 6707 Elbow Drive SW
Calgary, Alberta, T2V 0E5
Canada
Email: jonathan.brodkin@fdos.ca
Moise & Brodkin Expires November 15, 2010 [Page 22]
