Network Working Group A. Moise
Internet-Draft J. Brodkin
Intended Status: Informational Future DOS R&D
Expires: February 21, 2010 August 21, 2009
ANSI C12.22, IEEE 1703 and MC1222 Transport Over IP
draft-c1222-transport-over-ip-00.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 February 21, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
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/
MC1222 Advanced Metering Infrastructure (AMI) Application-Layer
Messages on an IP network.
Moise & Brodkin Expires February 21, 2010 [Page 1]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
Table of Contents
1. Introduction.....................................................2
1.1. Terminology.................................................3
1.2. Definitions.................................................3
2. The C12.22 IP Network Segment....................................5
2.1. Composition of a C12.22 IP Network Segment..................6
2.2. IP Native Address...........................................6
2.3. Encoding of Native Addresses................................6
2.4. Standardized Port Numbers...................................7
2.5. Use of UDP Source Port 0....................................8
2.6. IP Multicast................................................8
2.7. IP Broadcast................................................9
2.8. Encoding of Multicast and Broadcast Addresses...............9
3. IP Message Transport............................................11
3.1. C12.22 Connection Types and TCP/UDP Transport Modes........11
3.1.1. IP Message Transport Details..........................12
3.1.1.1. Single-channel UDP...............................12
3.1.1.2. Multi-channel UDP................................12
3.1.1.3. Single-channel TCP...............................13
3.1.1.4. Multi-channel TCP................................13
3.1.1.5. TCP and C12.22 Message Directionality............13
3.2. Using IP Broadcast/Multicast...............................14
3.3. Transport Protocol Decisions...............................14
3.3.1. Unicast Versus Multicast Versus Broadcast.............14
3.3.2. Sending Large C12.22 APDUs Using UDP..................15
3.3.3. Choice of Protocol for C12.22 Response APDUs..........15
3.4. Quality of Service.........................................15
4. Security Considerations.........................................16
5. IANA Considerations.............................................16
6. References......................................................16
6.1. Normative References.......................................16
6.2. Informative References.....................................17
7. Acknowledgments.................................................18
8. Authors' Addresses..............................................19
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/D1 [3], and MC1219 [4].
Moise & Brodkin Expires February 21, 2010 [Page 2]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
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 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-2009 [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 MC1222 [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].
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.
Moise & Brodkin Expires February 21, 2010 [Page 3]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
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 an 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.
C12.22 Message
An APDU that is also 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.
Moise & Brodkin Expires February 21, 2010 [Page 4]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
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 Message that contains a C12.22 EPSEM
Service Request.
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.
Responding C12.22 IP Node
A temporary role of a C12.22 IP Node in which it responds to the
transmission of a C12.22 Message that contained a C12.22 EPSEM
Service Request.
Source C12.22 IP Node
The C12.22 IP Node that originates of a C12.22 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.
Moise & Brodkin Expires February 21, 2010 [Page 5]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
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 the 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.
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. IP Native Address
The IP address and the port number used by a C12.22 Node on a C12.22
Network Segment is referred to as a Native Address. The Native
Address of a C12.22 IP Node SHALL include an IP Address (version 4 or
version 6) and an optional port number, which is assumed to be zero
if not present. The IP address of the C12.22 IP Node SHOULD be
configured before the node attempts to send or receive any C12.22
Message on its C12.22 IP Network Segment.
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 Addresses
ANSI C12.22 defines a field for encoding a C12.22 Native Address for
transport within C12.22 Messages. The field consists of up to 20-
octets of a binary native network address field (e.g., C12.22
Registration Service <native-address> parameter), whose extent is
qualified by an address length field (e.g., C12.22 Registration
Service <address-length> parameter). Binary native address fields
SHALL be encoded network byte order and interpreted as shown in
Figure 1.
Moise & Brodkin Expires February 21, 2010 [Page 6]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
Actual Native IP Address (ADDR) and Port (P)
Length (Up to 20 octets)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 | 4+| | ADDR4 | 0 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 + port | 6+| | ADDR4 | P | 0 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 |16+| | ADDR6 | 0 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 + port |18+| | ADDR6 | P | 0 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Encoding of the native IP addresses for ANSI C12.22
The notation n+ in the Actual Length field indicates n or more,
octets, to a maximum of 20 octets. The port number, P, is OPTIONAL,
and when not present it SHALL be assumed to be zero (0). IPv6
addresses SHALL NOT contain all zeros (0) in octet offset positions 6
through 15 when the port number (P) is absent or is set to zero (0).
When a Native Address is encoded in ANSI C12.19 Tables' BINARY data
Elements then the size of the native address Element transmitted is
defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (See [1] [2] Table
121). It is the actual number of octets that are placed inside the
C12.19 BINARY Element. This value is common across all of the node's
interfaces, including those that are not IP based (thus not
conforming to this specification). The encoding of the native
address of C12.19 BINARY Elements SHALL conform to Figure 1. When
ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN is greater than the actual native
address required to encode a native IP address, then all trailing
octets shall be set to zero (0).
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.
Moise & Brodkin Expires February 21, 2010 [Page 7]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
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.
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
When sending messages via UDP, the sender MAY set the source port to
zero. According to the User Datagram Protocol [10], the Source Port
is an optional field. When meaningful, it indicates the port of the
sending process to which a reply SHOULD be addressed in the absence
of any other information. If not used, a value of zero is inserted.
In the context of this specification, the use of UDP port zero (0) is
an indication to the target that any responses to a C12.22 Request
Message SHALL be sent to the requester's registered port number, or
if unknown, then it SHALL be sent to the default port: 1153.
2.6. IP Multicast
In addition to unicast, the ANSI C12.22 protocol requires the support
of a multicast message delivery services from the network. In the
cases where C12.22 IP Nodes MUST perform IP address discovery (e.g.,
the discovery of the IP address of C12.22 IP Relays that provide a
route out of the C12.22 IP Network Segment, or the discovery of the
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 efficiently a multitude of C12.22 Nodes (e.g., meters),
configured with a common C12.22 multicast group ApTitle. Using IP
multicast, the C12.22 sends one 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
Moise & Brodkin Expires February 21, 2010 [Page 8]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
is RECOMMENDED that C12.22 IP Nodes implement IGMPv3 [13].
Implementation of IGMPv3 [14] is OPTIONAL.
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.
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 IGMPv2. 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.
The requirements of this section indicate a need for an IPv4 and an
IPv6 multicast address to be dedicated for ANSI C12.22 use. See
Section 5 IANA Considerations.
2.7. IP Broadcast
IP broadcast is not generally suitable as a replacement or an
alternative for 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 directed broadcast, and specifies a minimum requirement in
Section 2.8.
2.8. Encoding of Multicast and Broadcast Addresses
ANSI C12.22 Tables provide Elements for encoding a Native Broadcast
or Multicast Address for transport within a C12.22 Message. The
Elements consist of up to 20-octets. The encoding of these Table
Elements is identical to that defined is Section 2.3. These fields
SHALL be used and interpreted as shown in Figure 2.
Moise & Brodkin Expires February 21, 2010 [Page 9]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
Actual IP Address (ADDR) and Port (P)
Length (up to 20 octets)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast | 4+| |BADDR4 | 0 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast | 6+| |BADDR4 | P | 0 |
+Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast | 4+| |MADDR4 | 0 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast | 6+| |MADDR4 | P | 0 |
+Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast |16+| | MADDR6 | 0 |
+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast |18+| | MADDR6 | P | 0 |
+Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encoding of broadcast/multicast native IP addresses
The notation n+ in the Actual Length field indicates n or more,
octets, to a maximum of 20 octets. The IPv4 and IPv6 multicast
addresses, MADDR4 and MADDR6, respectively, are those to be assigned
by IANA for use by ANSI C12.22. IPv6 multicast IP addresses SHALL
NOT contain all zeros (0) in octet offset positions 6 through 15 when
the port number (P) is absent or is set to zero (0).
When a broadcast/multicast Native Address is encoded in ANSI C12.19
Tables' BINARY data Elements then the size of the native address
Element transmitted is defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN
(See [1] [2] Table 121). It is the actual number of octets that are
placed inside the C12.19 BINARY Element. This value is common across
all of the node's interfaces, including those that are not IP based
(thus not conforming to this specification). The encoding of the
native broadcast/multicast address of C12.19 BINARY Elements SHALL
conform to Figure 2. When ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN is
greater than the actual native address required to encode a native
Moise & Brodkin Expires February 21, 2010 [Page 10]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
broadcast/multicast address, then all trailing octets shall be set to
zero (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.
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 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 IP transport that the node supports 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 configuration
0 1 0 0 Single-channel TCP. UDP not supported
0 1 0 1 Multi-channel TCP. UDP not supported
0 1 1 0 Invalid configuration
0 1 1 1 Invalid configuration
1 0 0 0 Single-channel UDP. TCP not supported
1 0 0 1 Invalid configuration
1 0 1 0 Multi-channel UDP. TCP not supported
1 0 1 1 Invalid configuration
1 1 0 0 Single-channel UDP and TCP
1 1 0 1 Single-channel UDP, Multi-channel TCP
1 1 1 0 Single-channel TCP, Multi-channel UDP
1 1 1 1 Multi-channel UDP and TCP
Every C12.22 IP Node MUST support at least one of unicast CO or CL
operating capabilities (as advertized in Decade 12, Network Tables
Moise & Brodkin Expires February 21, 2010 [Page 11]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
[1], where available, and as registered using the C12.22 Registration
Service [1]).
3.1.1. IP Message Transport Details
3.1.1.1. Single-channel UDP
A C12.22 IP Node that operates in this mode SHALL NOT monitor UDP
Port 1153. As a result, the node is incapable of receiving
unsolicited C12.22 Request Messages from other C12.22 Nodes using
UDP.
A transaction in this mode is characterized by an initiating C12.22
IP Node sending a C12.22 Request message to a target C12.22 IP Node,
followed by the target node sending a C12.22 Response message back to
the initiating node, addressing the message to the source IP address
and source port in the C12.22 Request Message.
When the source port in the C12.22 Request Message is set to
zero (0), the C12.22 Response Message SHALL be sent to the port that
was registered for the originating node (per ANSI C12.22 Registration
Service, in which the initiating node MAY include within the C12.22
EPSEM Service Request, an IP address and port), or to the default
port, 1153, if the native address was not registered. Further
details are provided in Section 3.3. , Transport Protocol Decisions.
3.1.1.2. Multi-channel UDP
A C12.22 IP Node that supports this mode monitors by default UDP Port
1153 and thus is capable of receiving unsolicited C12.22 messages.
The default monitored LAN IP native address (thus port number) may be
changed on a per-node basis via ANSI C12.22 Registration Service, in
which the registering node MAY include within the C12.22 EPSEM
Service Request, an alternate IP address and port to be registered.
When an initiating C12.22 IP Node is configured for multi-channel
UDP, it SHOULD expect that the response from the target node MAY
arrive on UDP Port 1153, unless otherwise specified by the EPSEM
Registration Service for the initiating C12.22 IP Node. To enable
the initiating node to communicate this expectation to the target
node, this specification RECOMMENDS that the initiating node use port
1153 as the source port in its UDP request message. Further details
are provided in Section 3.3. Transport Protocol Decisions.
All C12.22 IP Relays SHALL support Multi-channel UDP. Of the two UDP
modes, Multi-channel UDP is the RECOMMENDED mode for all other C12.22
IP Nodes.
Moise & Brodkin Expires February 21, 2010 [Page 12]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
3.1.1.3. Single-channel TCP
In this mode, C12.22 Request and Response Messages between a pair of
C12.22 IP Nodes can only arrive through one established TCP
connection from the Initiating C12.22 IP Node. The loss or closure
of the connection SHALL NOT automatically result in the termination
of the C12.22 associations between the peer nodes. The termination
of the associations is dependent upon C12.22 application timeout
attributes. The C12.22 Host SHALL implement Multi-channel IP in
order to accept incoming connections (See Section 3.1.1.4. Multi-
channel TCP for details). A C12.22 IP Node that supports this mode
monitors by default TCP Port 1153 and thus is capable of receiving
unsolicited TCP connections.
The default monitored LAN IP native address (thus port number) MAY be
changed on a per-node basis via ANSI C12.22 Registration Service, in
which the registering node MAY include within the C12.22 EPSEM
Service Request, an alternate IP address and port to be registered
and used to establish a TCP connection.
3.1.1.4. Multi-channel TCP
In this mode, C12.22 Request and Response Messages between a pair of
C12.22 IP Nodes can arrive through multiple established TCP
connections. The monitored LAN IP native addresses, and thus port
numbers, are defined in the previous section.
All C12.22 IP Relays SHALL support Multi-channel TCP. For all other
C12.22 IP Nodes, Multi-channel TCP is the RECOMMENDED mode.
3.1.1.5. TCP and C12.22 Message Directionality
C12.22 IP Nodes MAY use TCP in a one of two ways: bi-directional
traffic flow or uni-directional traffic flow.
When used bi-directionally, any established TCP connection MAY be
used to send and received C12.22 APDUs. This is the RECOMMENDED and
default mode operation, because ANSI C12.22 requires the Transport
network to be reliable and connectionless (per connectionless-mode
ACSE). ANSI C12.22 implements peer-to-peer Application Association
and not peer-to-peer connections.
It is known that some C12.22 implementations have been deployed using
uni-directionally TCP. When used uni-directionally, an established
TCP connection SHALL be used by the initiator of that connection
strictly to send C12.22 APDUs and by the target node (who accepted
the connection) strictly to received C12.22 APDUs. It is
Moise & Brodkin Expires February 21, 2010 [Page 13]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
RECOMMENDED, for increased interoperability, that the initiator of
the connection also accepts incoming C12.22 APDUs on that connection.
Uni-directional TCP is a special mode of operation; it is not the
RECOMMENDED mode of operation because it is not defined in ANSI
C12.22. While this mode of operation is not explicitly supported in
the C12.22 standard, it MAY be made possible through mutual operating
agreements. The means by which nodes are configured to enact the
uni-directional TCP messaging protocol is not defined in this
specification or in the C12.22 standard; it is left for future
consideration by ANSI C12.22 configuration.
3.2. 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 IP multicast messages
1 The C12.22 IP Node accepts IP broadcast and IP
multicast messages
If a C12.22 IP Node is configured to accept IP broadcast and
multicast messages, it SHALL join the multicast group whose address
is assigned by IANA, and SHALL use the default port 1153. In
addition it shall accept IP Network directed broadcast messages sent
to port 1153.
3.3. Transport Protocol Decisions
3.3.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, it is RECOMMENDED that the C12.22 Resolve
Request message be transported using UDP/IP multicast when the Native
Address of the target C12.22 Node is not known. Use of UDP/IP
multicast is preferred over the use of IP Network directed broadcast;
Moise & Brodkin Expires February 21, 2010 [Page 14]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
therefore when UDP/IP multicast is supported its use is RECOMMENDED
over network broadcast.
3.3.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 maximum transmission unit (MTU), then 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 MTU.
3.3.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, with the destination port assigned as
follows:
If source port is non-zero then send the response to source port;
Otherwise, when the source port is zero and the initiating source
Node's port number is not registered or the registration attribute
<address-length> of the parameter <native-address> is set to zero
(0), then send the response to port 1153;
Otherwise, when the source port is zero and the initiating source
Node's registered port number is not zero, then send the response to
the registered port number;
Otherwise, when the source port is zero and the source Node's
registered port number is zero or cannot be determined, then send the
response to port 1153.
It is RECOMMENDED that the source port always be set to the
registered port number value instead of setting it to zero (0).
3.4. 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 February 21, 2010 [Page 15]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
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 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 by the C12.22 standard, is
already registered with IANA.
Based on the requirements in this RFC, and the need to globally route
C12.22 messages through the Internet, this specification requests
IANA to assign one IPv4 and one IPv6 multicast address for C12.22
communication over IP.
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/D1, June 2009.
[4] Measurement Canada, "Specification for Utility Industry
Metering Communication Protocol Application Layer (End Device
Data Tables)", MC1219, 2009.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Moise & Brodkin Expires February 21, 2010 [Page 16]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
[6] IEEE, "Draft Standard for Local Area Network/Wide Area
Network (LAN/WAN) Node Communication Protocol to Complement
the Utility Industry End Device Data Tables", IEEE 1703/D4,
March 2009.
[7] Measurement Canada, "Specification for Local Area
Network/Wide Area Network (LAN/WAN) Node Communication
Protocol to Complement the Utility Industry End Device Data
Tables", MC1222, 2009.
[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.
6.2. Informative References
[Will be added as appropriate]
Moise & Brodkin Expires February 21, 2010 [Page 17]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
7. Acknowledgments
The authors wish to recognize Alexander Shulgin for providing
valuable comments and for conducting feasibility testing in support
of this work.
Moise & Brodkin Expires February 21, 2010 [Page 18]
Internet Draft draft-c1222-transport-over-ip-00.txt August 2009
8. Authors' Addresses
Avygdor Moise
FutureDOS R&D Inc.
#303 - 6707 Elbow Drive SW
Calgary, Alberta, T2V 0E5
Canada
Email: avy@fdos.ca
Jonathan Brodkin
FutureDOS R&D Inc.
#303 - 6707 Elbow Drive SW
Calgary, Alberta, T2V 0E5
Canada
Email: jonathan.brodkin@fdos.ca
Moise & Brodkin Expires February 21, 2010 [Page 19]
