[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 6142

Network Working Group                                          A. Moise
Internet-Draft                                               J. Brodkin
Intended Status: Informational                           Future DOS R&D
Expires: March 15, 2010                              September 15, 2009

          ANSI C12.22, IEEE 1703 and MC1222 Transport Over IP

               draft-c1222-transport-over-ip-01.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 March 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 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 March 15, 2010                [Page 1]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 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.................5
      2.2. Native IP 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..............................................10
      2.8. Encoding of Multicast and Broadcast Addresses.............10
   3. IP Message Transport...........................................12
      3.1. C12.22 Connection Types and TCP/UDP Transport Modes.......12
         3.1.1. IP Message Transport Details.........................13
            3.1.1.1. Single-channel UDP..............................13
            3.1.1.2. Multi-channel UDP...............................13
            3.1.1.3. Single-channel TCP..............................14
            3.1.1.4. Multi-channel TCP...............................14
            3.1.1.5. TCP and C12.22 Message Directionality...........14
      3.2. Using IP Broadcast/Multicast..............................15
      3.3. Transport Protocol Decisions..............................16
         3.3.1. Unicast Versus Multicast Versus Broadcast............16
         3.3.2. Sending Large C12.22 APDUs Using UDP.................16
         3.3.3. Choice of Protocol for C12.22 Response APDUs.........16
      3.4. Quality of Service........................................17
   4. Security Considerations........................................17
   5. IANA Considerations............................................17
   6. References.....................................................18
      6.1. Normative References......................................18
      6.2. Informative References....................................19
   7. Acknowledgments................................................19
   8. Authors' Addresses.............................................20

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].

   ANSI C12.22, which is an application-level messaging protocol, may be
   transported over any underlying transport network.  This RFC defines



Moise & Brodkin          Expires March 15, 2010                [Page 2]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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.

   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



Moise & Brodkin          Expires March 15, 2010                [Page 3]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

      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.

   Connection

      A logical and physical binding between two or more users of a
      service (ref. [1]).







Moise & Brodkin          Expires March 15, 2010                [Page 4]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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 is the originator 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.

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



Moise & Brodkin          Expires March 15, 2010                [Page 5]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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.

   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 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 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 in network byte order and interpreted as shown in
   Figure 1.






Moise & Brodkin          Expires March 15, 2010                [Page 6]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 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 March 15, 2010                [Page 7]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 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
   either a non-zero value or to zero.  If the sender's source port in
   the UDP header contains a non-zero value then replies SHOULD be sent
   to that port number.  If the sender's source port in the UDP header
   contains a zero (0) value, it is an indication to the receiving
   target node that any responses to the C12.22 Message initiator SHALL
   be sent to the initiator's registered port number, or if the port
   number was not registered (not specified in the ANSI C12.22 EPSEM
   Registration Service), then it SHALL be sent to the default port
   (1153).

   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 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 efficiently read 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



Moise & Brodkin          Expires March 15, 2010                [Page 8]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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.

   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 Nodes, including C12.22 IP Relays and C12.22
   IP Master Relays, 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.













Moise & Brodkin          Expires March 15, 2010                [Page 9]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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.

   An IPv6 C12.22 IP Notification Host or other similar node, through
   which, for example, an EPSEM Read Service Request is initiated,
   SHOULD use the minimum scope needed to reach its target set of C12.22
   IP Nodes.  A C12.22 IP 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.

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 directed 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 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. Encoding of
   Native Addresses.  These fields SHALL be used and interpreted as
   shown in Figure 2.









Moise & Brodkin          Expires March 15, 2010               [Page 10]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 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 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 March 15, 2010               [Page 11]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 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





Moise & Brodkin          Expires March 15, 2010               [Page 12]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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.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 Native IP Address (thus port number) may be
   changed on a per-node basis via the 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.






Moise & Brodkin          Expires March 15, 2010               [Page 13]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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.

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 TCP connection
   established by 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 TCP 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 Native IP 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 Native IP 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 one of two ways: bi-directional
   traffic flow or uni-directional traffic flow.

   When TCP connections are used bi-directionally, 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 ANSI
   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.




Moise & Brodkin          Expires March 15, 2010               [Page 14]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   It is known that some C12.22 implementations have been deployed using
   uni-directional TCP.  When used uni-directionally, an established TCP
   connection SHALL be used by the initiator of that connection to send
   C12.22 APDUs and by the target node (who accepted the connection) to
   receive C12.22 APDUs.  If the target wishes to send a C12.22 APDU
   back to the initiator, in uni-directional mode, it MUST establish a
   new uni-directional TCP connection or use an existing uni-directional
   TCP connection that it had previously initiated.

   It is RECOMMENDED, for increased interoperability, that the initiator
   of the connection also accepts incoming C12.22 APDUs on that
   connection in case the target node attempts to use the connection bi-
   directionally.

   Uni-directional TCP is a special mode of operation; it is NOT
   RECOMMENDED because dual one-way channel communication mode is not a
   mode that is supported 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
   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.

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 it does not accept IP multicast messages.
           1           The C12.22 IP Node accepts both IP broadcast and
                       IP multicast messages.





Moise & Brodkin          Expires March 15, 2010               [Page 15]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   If a C12.22 IP Node is configured to accept IP broadcast and
   multicast messages, it SHALL join the "All C1222 Nodes" multicast
   group, 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;
   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 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.

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;





Moise & Brodkin          Expires March 15, 2010               [Page 16]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   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.

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










Moise & Brodkin          Expires March 15, 2010               [Page 17]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

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.

   [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.




Moise & Brodkin          Expires March 15, 2010               [Page 18]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

   [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.

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.





















Moise & Brodkin          Expires March 15, 2010               [Page 19]


Internet Draft     draft-c1222-transport-over-ip-01.txt   September 2009

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 March 15, 2010               [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/