idnits 2.17.1 draft-c1222-transport-over-ip-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 15, 2010) is 5094 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. '11') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4601 (ref. '16') (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Moise 3 Internet-Draft J. Brodkin 4 Intended Status: Informational Future DOS R&D Inc. 5 Expires: November 15, 2010 May 15, 2010 7 ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP 9 draft-c1222-transport-over-ip-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 15, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/ 49 MC12.22 Advanced Metering Infrastructure (AMI) Application-Layer 50 Messages on an IP network. 52 Table of Contents 54 1. Introduction....................................................2 55 1.1. Terminology................................................3 56 1.2. Definitions................................................3 57 2. The C12.22 IP Network Segment...................................6 58 2.1. Composition of a C12.22 IP Network Segment.................6 59 2.2. Native IP Address..........................................7 60 2.3. Encoding of Native IP Addresses............................7 61 2.4. Standardized Port Numbers..................................8 62 2.5. Use of UDP Source Port 0...................................9 63 2.6. IP Multicast...............................................9 64 2.7. IP Broadcast..............................................11 65 2.8. Encoding of Multicast and Broadcast Addresses.............11 66 3. IP Message Transport...........................................13 67 3.1. C12.22 Connection Types and TCP/UDP Transport Modes.......13 68 3.2. IP Message Transport Details..............................14 69 3.2.1. TCP and UDP Port Use.................................14 70 3.2.2. Active-listen UDP (CL=1, CL Accept=0)................14 71 3.2.3. Passive-listen UDP (CL=1, CL Accept=1)...............15 72 3.2.4. Active-OPENs TCP Mode (CO=1, CO Accept=0)............15 73 3.2.5. Passive-OPENs TCP Mode (CO=1, CO Accept=1)...........16 74 3.2.6. TCP and C12.22 Message Directionality................16 75 3.3. Using IP Broadcast/Multicast..............................17 76 3.4. Transport Protocol Decisions..............................18 77 3.4.1. Unicast Versus Multicast Versus Broadcast............18 78 3.4.2. Sending Large C12.22 APDUs Using UDP.................18 79 3.4.3. Choice of Protocol for C12.22 Response APDUs.........18 80 3.5. Quality of Service........................................18 81 4. Security Considerations........................................19 82 5. IANA Considerations............................................19 83 6. References.....................................................19 84 6.1. Normative References......................................19 85 6.2. Informative References....................................21 86 7. Acknowledgments................................................21 87 8. Authors' Addresses.............................................22 89 1. Introduction 91 The ANSI C12.22 standard [1] provides a set of application layer 92 messaging services that are applicable for the enterprise and End 93 Device components of an Advanced Metering Infrastructure (AMI) for 94 the SmartGrid. The messaging services are tailored for, but not 95 limited to, the exchange of the data Tables Elements defined and co- 96 published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [4]. 98 ANSI C12.22, which is an application-level messaging protocol, may be 99 transported over any underlying transport network. This RFC defines 100 the requirements governing the transmission of ANSI C12.22 Messages 101 via the TCP and UDP transports and the IP networking. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [5]. 109 Throughout this document we use terms like ANSI C12.22 or ANSI 110 C12.19, as in C12.22 Relay or ANSI C12.19 Device. These terms are 111 interchangeable with the terms IEEE 1703 Relay and IEEE 1377 Device, 112 respectively. However, the recent versions of the Utility End Device 113 communication standards were developed under the auspices of ANSI C12 114 SC17 WG1 and ANSI C12 SC17 WG2. For that reason, the terminology 115 used in this document is based on the ANSI C12.22-2008 [1] and ANSI 116 C12.19-2008 [2] definitions as revised by IEEE 1703-2009 [6] and IEEE 117 1377-2010 [3]. 119 1.2. Definitions 121 This specification uses a number of terms to refer to the roles 122 played by participants (actors) in, and objects of, the ANSI C12.22 123 [1], IEEE 1703 [6], and MC12.22 [7] protocol. 125 Terms prefixed by C12.22 or C12.19, which are not defined here, can 126 be resolved in [1] [6] [7] or [2] [3] [4]. 128 ACSE 130 Association Control Service Element. In the context of this 131 specification and of [1], ACSEs are encoded per ISO/IEC 10035-1 132 [8] using the ASN.1 BER [9]. 134 Active-listen UDP 136 Active-listen UDP is a temporary process used by a local C12.22 137 IP Node to expect and receive incoming C12.22 Messages from a 138 foreign C12.22 IP Node using the UDP protocol. The local C12.22 139 IP Node SHALL solicit the incoming C12.22 Messages from the 140 foreign C12.22 IP Node using the foreign C12.22 IP Node's 141 registered Native IP Address. The local C12.22 IP Node MAY exit 142 Active-listen UDP process when it has received all of the 143 expected C12.22 Messages or a C12.22 Message timeout has 144 occurred. The local C12.22 IP Node SHALL receive all C12.22 145 Response Messages solicited from the foreign C12.22 IP Node that 146 arrive at the local port number that matches the source port 147 number used to solicit the C12.22 Messages from the foreign 148 C12.22 IP Node. 150 Active-OPEN TCP 152 Active-OPEN TCP is a process used by a local C12.22 IP Node to 153 establish a TCP connection with a fully-specified foreign C12.22 154 IP Node using the TCP protocol and the foreign C12.22 IP Node's 155 registered Native IP Address. The Active-OPEN TCP process is 156 identical to "local active OPEN" defined in [11]. 158 APDU 160 Application Protocol Data Unit. In the context of the ANSI 161 C12.22 Application, it is an ACSE C12.22 Message. 163 ACSE PDU 165 ACSE Protocol Data Unit; same as APDU. 167 ApTitle 169 An ANSI C12.22 Application-process Title. An ApTitle is a name 170 for a system-independent application activity that exposes 171 application services to the application agent; e.g., a set of 172 application service elements that together perform all or part of 173 the communication aspects of an application process. An ApTitle 174 is encoded as a unique registered (as per [1]) object identifier. 176 C12.22 IP Node 178 A C12.22 Node that is located on a C12.22 IP Network Segment and 179 communicates using the IP protocol. 181 C12.22 IP Network Segment 183 A collection of all C12.22 IP Nodes that implement the IP-based 184 protocols, as defined in this specification, and can communicate 185 with each other using IP routers, switches, and bridges and 186 without the use of a C12.22 Relay. 188 C12.22 IP Relay 190 A C12.22 IP Node that performs the functions of a C12.22 Relay. 191 A C12.22 IP Relay acts as a bridge between a C12.22 IP Network 192 Segment and an adjacent, C12.22 Network Segment. 194 C12.22 Message 196 An APDU that is also a fully assembled or a segment of a C12.22 197 Request Message or a C12.22 Response Message. The C12.22 Message 198 described in this specification MUST be encoded using [9]. 200 C12.22 Request Message 202 A fully assembled C12.22 APDU that contains an ACSE user 203 information element, which includes one or more EPSEM service 204 requests. 206 C12.22 Response Message 208 A fully assembled C12.22 Message APDU that contains an ACSE user 209 information element, which includes one or more EPSEM service 210 responses. 212 Connection 214 A logical and physical binding between two or more users of a 215 service (ref. [1]). 217 EPSEM 219 Extended Protocol Specification for Electronic Metering. EPSEM 220 defines structures and services used to encode multiple requests 221 and responses for use by devices such as gas, water, electricity, 222 and related electronic modules or appliances. 224 Initiating C12.22 IP Node 226 A temporary role of a C12.22 IP Node in which it initiates the 227 transmission of a C12.22 Request Message. 229 Native Address 231 The term Native Address refers to the network address of a C12.22 232 Node on its C12.22 Network Segment. In this specification, the 233 Native Address is the IP address plus the associated port number 234 used in communications by a C12.22 IP Node on the C12.22 IP 235 Network Segment. 237 Native IP Address 239 The binary IP address and the OPTIONAL port number used by a 240 C12.22 IP Node to encode a Native Address in a C12.22 Message or 241 in a C12.19 Table Element of an IP Node interface. 243 Passive-listen UDP 245 Passive-listen UDP is a process used by a local C12.22 IP Node to 246 expect and receive incoming C12.22 Messages from any foreign 247 C12.22 IP Node using the UDP protocol. When the Passive-listed 248 UDP process is active, the local C12.22 IP Node SHALL accept all 249 C12.22 Messages that arrive at the local port number that was 250 registered by the local C12.22 IP Node. 252 Passive-OPEN TCP 254 Passive-OPEN TCP is a process used by a local C12.22 IP Node that 255 wants to establish a TCP connection with an unspecified foreign 256 C12.22 IP Node using the TCP protocol. In this case any foreign 257 C12.22 IP Node MAY connect to the local C12.22 IP Node as long as 258 the local port matches the port used by the foreign C12.22 IP 259 Node. The Passive-OPEN TCP process is identical to "local 260 passive OPEN" defined in [11]. 262 Responding C12.22 IP Node 264 A temporary role of a C12.22 IP Node in which it responds to the 265 reception of a C12.22 Request Message. 267 Target C12.22 IP Node 269 The C12.22 IP Node that is the destination for a C12.22 Message. 271 2. The C12.22 IP Network Segment 273 This section defines the characteristics of the C12.22 IP Network 274 Segment. 276 2.1. Composition of a C12.22 IP Network Segment 278 A C12.22 Network Segment is a collection of C12.22 Nodes that can 279 communicate with each other directly - without having to forward 280 C12.22 Messages through a C12.22 Relay. 282 A C12.22 IP Network Segment comprises C12.22 IP Nodes and the network 283 infrastructure that enables any one node to reach all other nodes on 284 the same segment. All C12.22 IP Nodes on the C12.22 IP Network 285 Segment employ the same IP address encoding scheme and the same 286 network and transport protocols in accordance with this 287 specification. 289 There is no restriction on the size of a C12.22 IP Network Segment. 290 It MAY be as small as a single LAN or subnet, or it MAY include 291 numerous, heterogeneous LANs and WANs connected by routers, bridges, 292 and switches. The C12.22 IP Network Segment MAY be completely 293 private, or include communication across the global Internet. 295 2.2. Native IP Address 297 The IP address and the port number of a C12.22 IP Node on a C12.22 IP 298 Network Segment are collectively referred to as the Native IP 299 Address. 301 When the Native Address of a C12.22 IP Node is communicated within 302 the payload of a C12.22 Message it SHALL be encoded as described in 303 Section 2.3. Encoding of Native IP Addresses. 305 The IP address of the C12.22 IP Node SHOULD be configured before the 306 C12.22 IP Node attempts to send or receive any C12.22 Message on its 307 C12.22 IP Network Segment. If the port number is not explicitly 308 configured by the controlling application, it SHALL be set to the 309 default port number, 1153 (see Section 2.4. Standardized Port 310 Numbers). 312 The IP address MAY be hard-coded, manually entered, or allocated 313 automatically and/or dynamically by an IP network mechanism such as 314 DHCP. It is beyond the scope of this specification to define the 315 method of configuration, the configuration parameters, or any 316 administrative controls that the system administrator may wish to 317 implement. 319 2.3. Encoding of Native IP Addresses 321 ANSI C12.22 defines binary fields for encoding a C12.22 Native 322 Address for transport within C12.22 Messages. In this RFC the fields 323 SHALL contain an IPv4 or an IPv6 binary native IP network address 324 that is followed by an OPTIONAL two-byte TCP or UDP port number. 325 ANSI C12.22 allows these fields to be conveyed in select ANSI C12.22 326 service elements (e.g., ANSI C12.22 Registration Service parameter, ANSI C12.22 Resolve Service response , and ANSI C12.19 INTERFACE_CTRL_TBL Element NATIVE_ADDRESS). 329 The length of the C12.22 Native Address is qualified by an ANSI 330 C12.22 address length field (e.g., ANSI C12.22 Registration Service 331 parameter, ANSI C12.22 Resolve Service response 332 , and ANSI C12.19 ACT_NETWORK_TBL Element 333 NATIVE_ADDRESS_LEN). 335 The binary Native IP Address fields SHALL be encoded in network byte 336 order as shown in Figure 1. 338 Actual Native IP Address (ADDR) and Port (P) 339 Length Octet 340 0 1 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 342 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+- 343 IPv4 | 4 | | ADDR4 | 344 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 IPv4 + port | 6 | | ADDR4 | P | 348 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 IPv6 |16 | | ADDR6 | 352 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 IPv6 + port |18 | | ADDR6 | P | 356 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Figure 1: Encoding of the Native IP Addresses for ANSI C12.22 360 When an ANSI C12.22 Native Address is encoded in ANSI C12.19 Tables' 361 BINARY data Elements then the size of the native address Element is 362 defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (See [1] [2] Table 363 121). This is the actual number of octets that are placed inside the 364 C12.19 BINARY Element. This value is common to all of the C12.22 365 Node's interfaces, including those that are not IP based (thus not 366 conforming to this specification). For this reason the 367 ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than, and SHALL NOT 368 be smaller than, the actual length needed to encode a Native IP 369 Address per Figure 1. When this is the case, the C12.22 Native IP 370 Address SHALL be padded with zero (0) to fill the Table's BINARY data 371 Element. 373 2.4. Standardized Port Numbers 375 IANA (Internet Assigned Numbers Authority) has assigned port 1153 for 376 UDP [10] and TCP [11] C12.22 IP Messages. 378 By default, C12.22 IP Nodes SHALL send all C12.22 Application 379 Association initiation message requests set with 1153 as the 380 destination port number. 382 To ensure interoperability among C12.22 IP Nodes, all C12.22 IP 383 Relays and Master Relays SHALL monitor and accept UDP and TCP 384 messages destined to port 1153. 386 Any IP firewalls or Access Control Lists (ACLs) shielding a C12.22 387 device MUST be configured to forward UDP and TCP traffic destined to 388 port 1153 and other ports that are assigned and registered by the LAN 389 administrator, in order to maintain the continuity of the C12.22 IP 390 Network Segment. 392 2.5. Use of UDP Source Port 0 394 Although [10] allows for a source port number of zero (0), C12.22 IP 395 Nodes SHALL NOT send datagrams on UDP with the source port set to 396 zero. A C12.22 IP Node SHALL ignore and SHALL NOT respond to any 397 C12.22 Message that it receives from source port 0. 399 Further details of C12.22 IP Node's use of UDP, and of TCP, are given 400 in Section 3. IP Message Transport. 402 2.6. IP Multicast 404 In addition to unicast, the ANSI C12.22 protocol requires the support 405 of a multicast message delivery service from the network. In cases 406 where C12.22 IP Nodes MUST perform Native IP Address discovery (e.g., 407 the discovery of the Native IP Address of C12.22 IP Relays that 408 provide a route out of the C12.22 IP Network Segment, or the 409 discovery of the Native IP Address of a C12.22 IP Master Relay on the 410 C12.22 IP Network), the C12.22 IP Nodes uses IP Multicast to send a 411 C12.22 Message that contains an EPSEM Resolve Service Request on the 412 IP LAN. 414 IP multicast is also desirable, for example, when a C12.22 Host needs 415 to read a multitude of C12.22 Nodes (e.g., meters) that are 416 configured with a common C12.22 multicast group ApTitle. Using IP 417 multicast, the C12.22 Host MAY send a C12.22 Message containing an 418 EPSEM Read Service Request that reaches all C12.22 Nodes on the 419 C12.22 IP Network Segment. 421 For these reasons, all C12.22 IP Relays and Master Relays SHALL 422 support IP multicast and it is RECOMMENDED that all C12.22 Nodes 423 support IP multicast. Any IPv4 C12.22 IP Node that supports IP 424 multicast SHALL use the Internet Group Management Protocol IGMP 425 version 1 (IGMPv1) [12] as a minimum, to report (i.e., request) 426 membership in the C12.22 multicast group to its local router(s). It 427 is RECOMMENDED that C12.22 IP Nodes implement IGMPv3 [13]. 429 Any IPv6 C12.22 IP Node that supports IP multicast SHALL use 430 Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14] 431 possibly within ICMPv6 RFC 4443 [15]) to report membership. 433 Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network 434 Segment, MUST support Protocol Independent Multicast Sparse Mode (PIM 435 SM) (RFC 4601 [16]) along with IGMPv1 (RFC 1112 [12]) as a minimum 436 for IPv4, or MLDv2 for IPv6 (RFC 3810 [14]). It is RECOMMENDED that 437 they implement IGMPv3 [13]. It is beyond the scope of this 438 specification to define the mechanism for selecting an initial 439 Rendezvous Point (RP) for the C12.22 multicast group, the use of 440 shared versus source trees, or the mechanism for inter-domain 441 multicast routing. 443 IANA has registered the "All C1222 Nodes" multicast group, and has 444 assigned the IPv4 multicast address of 224.0.2.4 and the IPv6 445 multicast address of FF0X::204, where X represents the Scope field as 446 defined in RFC 4291, the IP Version 6 Addressing Architecture [17]. 448 For IPv6, all C12.22 IP Relays, C12.22 IP Master Relays, and all 449 C12.22 IP Nodes configured to support broadcast and multicast (see 450 Section 3.3. Using IP Broadcast/Multicast) SHALL join the global 451 scope multicast address, FF0E::204, as well as all of the assigned, 452 reduced scope, multicast addresses: 454 link-local - FF02::204; 455 admin-local - FF04::204; 456 site-local - FF05::204; and 457 organization-local - FF08::204. 459 IPv6 C12.22 IP Nodes SHOULD use the minimum scope needed, when 460 initiating IP multicast messages to reach another C12.22 IP Node on 461 the C12.22 Network. This practice is RECOMMENDED in order to limit 462 unnecessary propagation of C12.22 IP multicast Messages. 464 To determine the minimum scope required to reach the closest C12.22 465 IP Relay on the C12.22 Node's IP Network Segment, this specification 466 RECOMMENDS the following simple steps: 468 1. Starting with the smallest (local-most) scope, link-local (or a 469 pre-configured scope), send the C12.22 EPSEM Resolve Service 470 Request for C12.22 IP Relay discovery. 471 2. Listen for a response from a C12.22 IP Relay; then: 472 a. If no response is received, assign the next wider scope 473 level, then repeat steps (1) and (2) at the newly 474 assigned scope. 475 b. If a response is received then record the scope level as 476 the minimum scope to use on the node's C12.22 IP Network 477 Segment. 479 A C12.22 IPv6 Node that initiates any EPSEM Service Request SHOULD 480 use the minimum scope necessary to reach its target C12.22 IP Nodes. 482 A C12.22 IPv6 Relay SHALL use the global scope for any C12.22 message 483 destined for the global Internet. 485 This specification does not preclude the use of the unassigned scope 486 values defined in [17]; those scope values MAY be used on a private 487 basis, or through mutual operating agreements. 489 For IPv4, all C12.22 IP Relays, C12.22 IP Master Relays, and all 490 C12.22 IP Nodes configured to support broadcast/multicast SHALL join 491 the assigned multicast address of 224.0.2.4. This global address 492 does not provide for the type of scoping discussed above for IPv6, 493 nor is it compatible with the administratively scoped IP multicast 494 specification in RFC 2365[18]. Therefore, a different technique to 495 limit the propagation of C12.22 IP multicast Messages is needed. One 496 available technique to control IPv4 multicast scope is through the 497 use of the Time-to-Live (TTL) attribute in the IP packet header. 499 In the implementation of this technique, an administrative domain 500 MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in 501 the administrative domain SHOULD be configured with a TTL 502 sufficiently large to reach that C12.22 IP Relay. A TTL threshold 503 SHOULD be defined and configured on all border routers linking the 504 administrative domain to the global Internet such that the routers 505 forward on their Internet interfaces only those 224.0.2.4 multicast 506 packets that have a TTL exceeding the threshold value. 508 A C12.22 IPv4 Node that initiates any C12.22 Request Message SHOULD 509 use the minimum TTL needed to reach its target C12.22 IP Nodes. A 510 C12.22 IPv4 Relay SHOULD use a TTL that exceeds the threshold for any 511 C12.22 message destined for the global Internet. 513 2.7. IP Broadcast 515 IP broadcast is not generally suitable as a replacement for, or an 516 alternative to multicast in a C12.22 IP Network Segment. IP 517 broadcast is not supported in IPv6 and it suffers from limited scope 518 in IPv4. This specification, however, does not preclude the use of 519 IP network directed or limited/local scope (address 255.255.255.255) 520 broadcast, and specifies a minimum requirement in Section 2.8. 521 Encoding of Multicast and Broadcast Addresses. 523 2.8. Encoding of Multicast and Broadcast Addresses 525 ANSI C12.22 Tables provide binary Elements for encoding a Native 526 Broadcast or Multicast Address for transport within a C12.22 Message. 527 The encoding of these Table Elements is identical to that defined is 528 Section 2.3. Encoding of Native IP Addresses. These fields SHALL be 529 used as shown in Figure 2. 531 Actual IP Address (ADDR) and Port (P) 532 Length Octet 533 0 1 534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 535 IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Broadcast | 4 | |BADDR4 | 537 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Broadcast | 6 | |BADDR4 | P | 541 +Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Multicast | 4 | |MADDR4 | 545 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 IPv4 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Multicast | 6 | |MADDR4 | P | 549 +Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 IPv6 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Multicast |16 | | MADDR6 | 553 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 IPv6 +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Multicast |18 | | MADDR6 | P | 557 +Port +---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 2: Encoding of broadcast/multicast native IP addresses 561 The IPv4 and IPv6 multicast addresses, MADDR4 and MADDR6, 562 respectively, are those assigned by IANA for use by ANSI C12.22. 564 When a broadcast/multicast Native IP Address is encoded in ANSI 565 C12.19 Tables' BINARY data Elements the size of the Native Address 566 Element transmitted is defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN 567 (See [1] [2] Table 121). This is the actual number of octets that 568 are placed inside the C12.19 BINARY Element. This value is common to 569 all of the C12.22 Node's interfaces, including those that are not IP 570 based (thus not conforming to this specification). For this reason 571 the ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than, and SHALL 572 NOT be smaller than, the actual length needed to encode a native IP 573 broadcast/multicast address per Figure 2. When this is the case, the 574 C12.22 Native IP Address SHALL be padded with zero (0) to fill the 575 Table's BINARY data Element. 577 The IPv4 network directed broadcast address can be computed by 578 performing a bitwise OR between the bit complement of the subnet mask 579 of the target IP subnet and the IP address of any host on that IP 580 subnet. 582 3. IP Message Transport 584 This section defines a C12.22 Node's usage of the Connection-Oriented 585 (CO) and Connectionless (CL) transport layer protocols, TCP and UDP, 586 respectively. 588 3.1. C12.22 Connection Types and TCP/UDP Transport Modes 590 A C12.22 IP Node's use of TCP and UDP is based on its registered 591 capabilities as defined in its configuration parameters (flags) and 592 as expressed in the Node's accepted registration attributes [1]: 594 CL Flag = .CONNECTIONLESS_MODE_SUPPORTED; 595 CL Accept Flag = .ACCEPT_CONNECTIONLESS; 596 CO Flag = .CONNECTION_MODE_SUPPORTED; and 597 CO Accept Flag = .ACCEPT_CONNECTIONS. 599 The mapping of the connection-type parameters to the type of TCP and 600 UDP transports that a C12.22 Node MAY support is defined in Table 1. 602 Table 1: C12.22 Node Parameters to IP Transport Mapping 604 CL CO CL Accept CO Accept 605 Flag Flag Flag Flag IP Transport Mode Supported 606 ---- ---- ---- ---- -------------------------------------- 607 0 0 x x Invalid 608 0 1 0 0 TCP, Active-OPENs 609 0 1 0 1 TCP, Passive- and Active-OPENs 610 0 1 1 0 Invalid 611 0 1 1 1 Invalid 612 1 0 0 0 UDP, Active-listen 613 1 0 0 1 Invalid 614 1 0 1 0 UDP, Passive- and Active-listen 615 1 0 1 1 Invalid 616 1 1 0 0 UDP, Active-listen; TCP Active-OPENs 617 1 1 0 1 UDP, Active-listen; 618 TCP, Passive- and Active-OPENs 619 1 1 1 0 UDP, Passive- and Active-listen; 620 TCP, Active-OPENs 621 1 1 1 1 UDP, Passive- and Active-listen; 622 TCP, Passive- and Active-OPENs 623 -------------------------------------------------------------------- 624 Every C12.22 IP Node MUST support at least one of unicast CO or CL 625 operating capabilities (as advertized in Decade 12, Network Tables 626 [1], where available, and as registered using the C12.22 Registration 627 Service [1]). 629 3.2. IP Message Transport Details 631 3.2.1. TCP and UDP Port Use 633 General rules: 635 1. A C12.22 IP Node that implements [CL Accept=1] SHALL receive 636 incoming UDP C12.22 Messages on its registered Native IP 637 Address (IP address and port number). 639 2. A C12.22 IP Node that implements [CO Accept=1] SHALL receive 640 incoming TCP connections on its registered Native IP Address 641 (IP address and port number). 643 3. A C12.22 IP Relay that forwards a UDP C12.22 Message to a 644 C12.22 IP Node on the C12.22 IP Network Segment SHALL send the 645 C12.22 Message to the C12.22 IP Node's registered Native IP 646 Address (IP address and port number). 648 4. A C12.22 IP Relay that forwards a TCP C12.22 Message to a 649 C12.22 IP Node on the C12.22 IP Network Segment MAY use an 650 established TCP connection to that C12.22 IP Node, or it SHALL 651 establish a new TCP connection to the C12.22 IP Node's 652 registered Native IP Address (IP address and port number). 654 5. A C12.22 IP Node that implements [CL=1] SHOULD set the source 655 port number in outbound UDP C12.22 Messages to its registered 656 port number. 658 6. A C12.22 IP Node that implements [CL=1] MAY set the source 659 port number in outbound UDP C12.22 Messages to a different UDP 660 source port number if the target UDP C12.22 IP Node is 661 reachable using direct messaging (as defined in [1]). 663 7. When the registered Native IP Address of a C12.22 IP Node does 664 not include the OPTIONAL port number, then port 1153 SHALL be 665 assumed and used as the registered port number. 667 8. All C12.22 IP Nodes SHOULD use port 1153 in their Native IP 668 Address when registering. 670 3.2.2. Active-listen UDP (CL=1, CL Accept=0) 671 A C12.22 IP Node that supports this mode SHALL NOT monitor for 672 unsolicited incoming C12.22 Messages via UDP. As a result, the 673 C12.22 IP Node is incapable of receiving unsolicited C12.22 Messages 674 using UDP. 676 The C12.22 IP Node MAY enter the Active-listen UDP process by 677 initiating an unsolicited UDP transmission to a Target C12.22 IP 678 Node, which is expected to implement the Passive-listen UDP mode. 680 C12.22 IP Nodes SHOULD use their registered UDP port number, or if 681 not yet registered then they SHOULD use port 1153, as the source port 682 number for all UDP C12.22 IP Messages. 684 3.2.3. Passive-listen UDP (CL=1, CL Accept=1) 686 A C12.22 IP Node that operates in this mode SHALL be capable of 687 receiving solicited and unsolicited C12.22 Messages from other C12.22 688 IP Nodes. The C12.22 Node MAY change the port number that it 689 monitors by using the parameter of the ANSI C12.22 690 Registration Service. The C12.22 IP Node MAY initiate unsolicited 691 Active-listen UDP transmissions to other C12.22 IP Nodes that 692 implement the Passive-listen UDP mode. 694 When operating in this mode, the C12.22 IP Nodes SHALL use their 695 registered UDP port number as the source port number for all UDP 696 C12.22 IP Messages. 698 All C12.22 IP Relays SHALL support the Passive-listen UDP mode. 699 C12.22 Authentication Hosts and C12.22 Notification Hosts that 700 implement UDP SHALL support Passive-listen UDP mode. For all other 701 C12.22 IP Nodes, Passive-listen UDP mode is the RECOMMENDED mode when 702 implementing UDP. 704 3.2.4. Active-OPENs TCP Mode (CO=1, CO Accept=0) 706 A C12.22 IP Node that supports this mode SHALL NOT monitor for 707 inbound TCP connections. As a result, the node is incapable of 708 accepting incoming connections via TCP. The C12.22 IP Node MAY 709 initiate TCP connections to Target C12.22 IP Nodes, which are 710 expected to implement the Passive-OPENs TCP mode. 712 In this mode, C12.22 Messages exchanged by a pair of associated 713 C12.22 IP Nodes can only be communicated through any of the TCP 714 connections that were initiated by the C12.22 IP Node that implements 715 this mode. The loss or closure of a connection SHALL NOT 716 automatically result in the termination of the C12.22 associations 717 between the peer nodes. In order to continue exchanging C12.22 718 Messages without loss of association, the initiating C12.22 IP Node 719 MAY re-establish new TCP connections with the peer node, or use 720 existing connections to the peer node. The termination of the C12.22 721 Application associations is dependent upon C12.22 application timeout 722 attributes and C12.22 link management services (such as Procedure 25 723 Network Interface Control [1]). 725 3.2.5. Passive-OPENs TCP Mode (CO=1, CO Accept=1) 727 A C12.22 IP Node that operates in this mode SHALL monitor and accept 728 incoming TCP connections. The C12.22 Node May change the port number 729 that it monitors by using the parameter of the ANSI 730 C12.22 Registration Service. The C12.22 IP Node MAY initiate Active- 731 OPENs TCP connections to other C12.22 IP Nodes that implement the 732 Passive-OPENs TCP mode. 734 In this mode, C12.22 Messages exchanged by a pair of associated 735 C12.22 IP Nodes can arrive through any of the TCP connections that 736 were established by either node. The loss or closure of a connection 737 SHALL NOT automatically result in the termination of the C12.22 738 associations between the peer nodes. In order to continue exchanging 739 C12.22 Messages without loss of association, either C12.22 IP Node 740 MAY re-establish new TCP connections with the peer node, or use 741 existing connections to the peer node. The termination of the C12.22 742 Application associations is dependent upon C12.22 application timeout 743 attributes and C12.22 link management services (such as Procedure 25 744 Network Interface Control [1]). 746 All C12.22 IP Relays SHALL support the Passive-OPENs TCP mode. 747 C12.22 Authentication Hosts and C12.22 Notification Hosts that 748 implement TCP SHALL support Passive-OPENs TCP mode. For all other 749 C12.22 IP Nodes, Passive-OPENs TCP mode is the RECOMMENDED mode when 750 implementing TCP. 752 3.2.6. TCP and C12.22 Message Directionality 754 C12.22 IP Nodes MAY use TCP in one of two ways: bi-directional 755 traffic flow or uni-directional traffic flow. 757 When TCP connections are used, any new or established TCP connection 758 between the two C12.22 IP Nodes MAY be used equivalently by the 759 C12.22 IP Nodes to send and to receive C12.22 Messages. This is the 760 RECOMMENDED and default mode of operation, because ANSI C12.22 761 requires the transport network to be reliable and connectionless (per 762 connectionless-mode ACSE). For this reason ANSI C12.22 defines peer- 763 to-peer application associations and not peer-to-peer connections. 765 It is known that some C12.22 implementations have been deployed in 766 which TCP is used for uni-directional traffic flow. For these types 767 of implementations, an established TCP connection SHALL be used by 768 the initiator of that connection to send C12.22 Messages and by the 769 target node (who accepted the connection) to receive C12.22 Messages. 770 If a C12.22 IP Node wishes to send a C12.22 Message to a peer C12.22 771 IP Node, it MUST establish and use a new TCP connection or use an 772 existing TCP connection that it had previously initiated, for its 773 outbound uni-directional traffic flow. 775 For increased interoperability, the initiator of the connection 776 SHOULD accept incoming C12.22 Messages on that connection in case the 777 target node attempts to use the connection for bi-directional traffic 778 flow. 780 Uni-directional use of TCP is a special mode of operation; it is NOT 781 RECOMMENDED because multiple one-way channel communication is not 782 described by ANSI C12.22, and it utilizes one-half of the TCP 783 connection capability. As a result it doubles the number of TCP 784 connections used to communicate C12.22 Messages, and thus could 785 become a burden when a large number of connections is required. 786 While this mode of operation is not explicitly supported in the ANSI 787 C12.22 standard, it MAY be made possible through mutual operating 788 agreements. The means by which nodes are configured to enact the 789 uni-directional use of TCP is not defined in this specification or in 790 the ANSI C12.22 standard; it is left for future consideration. 792 3.3. Using IP Broadcast/Multicast 794 A C12.22 IP Node's use of Broadcast/Multicast is based on its 795 capabilities as defined in its configuration parameters (flags) and 796 as expressed in the Node's accepted registration attributes [1] 797 (.BROADCAST_AND_MULTICAST_SUPPORTED). The mapping 798 of the C12.22 IP Node's Broadcast/Multicast parameter (flag) to IP 799 Broadcast/Multicast usage is defined in Table 2. 801 Table 2: C12.22 to IP Broadcast/Multicast Mapping 803 C12.22 Broadcast and 804 Multicast Supported 805 Flag IP Broadcast/Multicast Supported 806 ---- ------------------------------------------------- 807 0 The C12.22 IP Node does not accept IP broadcast 808 and it does not accept IP multicast messages. 809 1 The C12.22 IP Node accepts both IP broadcast 810 (IPv4 only) and IP multicast messages (IPv4 and 811 IPv6). 813 If a C12.22 IP Node is configured to accept IP broadcast and 814 multicast messages, it SHALL join the "All C1222 Nodes" multicast 815 group (see Section 2.6. IP Multicast), and SHALL use the default port 816 1153. In addition it SHALL accept IP Network directed or limited 817 (local scope) broadcast messages sent to port 1153. Note that 818 successful communication using network directed broadcast requires 819 configuration of network routers, which by default are not supposed 820 to forward directed broadcasts as per RFC 2644 [19]. 822 3.4. Transport Protocol Decisions 824 3.4.1. Unicast Versus Multicast Versus Broadcast 826 An initiating C12.22 IP Node MAY send any C12.22 Message using UDP or 827 TCP. However, in accordance with Section 5.3.2.4.12, Resolve 828 Service, of ANSI C12.22, this specification RECOMMENDEDS that the 829 C12.22 Resolve Request message be transported using UDP/IP multicast 830 when the Native IP Address of the Target C12.22 Node is not known. 831 Use of UDP/IP multicast is preferred over the use of IP network 832 directed or limited broadcast; therefore when UDP/IP multicast is 833 supported its use is RECOMMENDED over network broadcast. 835 3.4.2. Sending Large C12.22 APDUs Using UDP 837 When sending a large C12.22 Message via UDP, whereby the ACSE PDU 838 size exceeds the UDP datagram maximum data length (65527 bytes), the 839 initiating C12.22 IP Node SHALL segment the ACSE PDU in accordance 840 with ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such 841 that each APDU segment fits within the UDP data field. 843 3.4.3. Choice of Protocol for C12.22 Response APDUs 845 When a Target C12.22 IP Node receives a C12.22 Request Message from 846 an initiating C12.22 IP Node, it SHALL send a C12.22 Response Message 847 using the same transport protocol (i.e., TCP to TCP, UDP to UDP). 849 In the case of UDP, the target SHALL send the C12.22 Response Message 850 to the source IP address and port number. 852 3.5. Quality of Service 854 The ANSI C12.22 standard provides a configuration parameter in the 855 APDU's .URGENT to mark a message as urgent. 856 There are numerous IP-based technologies that enable enhanced levels 857 of message delivery and quality of service. This specification does 858 not define the technology to be used to send urgent messaged over IP. 860 4. Security Considerations 862 The ANSI C12.22 Application layer security is defined in Section 863 5.3.4.13, C12.22 Security Mechanism, of the ANSI C12.22 standard. 864 The security mechanisms include provisions for AES-128/EAX message 865 privacy and authentication, playback rejection, and message 866 acceptance windows as well as ANSI C12.19 [2] role-based data access 867 and secured register mechanisms. Additional Transport or Network 868 layer security protocols are not required but MAY be provided 869 transparently by network integrators. However, any added Transport 870 or IP Network layer security features SHALL act only to enhance and 871 preserve (i.e., not be a substitute for, or an alteration of) the 872 ANSI C12.22 and ANSI C12.19 (interoperable) security provisions. 874 5. IANA Considerations 876 UDP and TCP port 1153, which is used for C12.22 communication over 877 IP, is registered with IANA. 879 Section 2.6. IP Multicast defines the use of multicast. The 880 following multicast addresses have been registered by IANA for use by 881 the ANSI C12.22 standard: 883 IPv4 - "All C1222 Nodes" address 224.0.2.4 885 IPv6 - "All C1222 Nodes" address FF0X::204 887 6. References 889 6.1. Normative References 891 [1] ANSI, "Protocol Specification for Interfacing to Data 892 Communication Networks", ANSI C12.22-2008, approved January 893 9, 2009. 895 [2] ANSI, "Utility Industry End Device Data Tables", ANSI C12.19- 896 2008, approved February 24, 2009. 898 [3] IEEE, "Draft Standard for Utility Industry Metering 899 Communication Protocol Application Layer (End Device Data 900 Tables)", IEEE P1377/D4, May 2010. 902 [4] Measurement Canada, "Draft Specification for Utility Industry 903 Metering Communication Protocol Application Layer (End Device 904 Data Tables)", MC12.19, 2010. 906 [5] Bradner, S., "Key words for use in RFCs to Indicate 907 Requirement Levels", BCP 14, RFC 2119, March 1997. 909 [6] IEEE, "Standard for Local Area Network/Wide Area Network 910 (LAN/WAN) Node Communication Protocol to Complement the 911 Utility Industry End Device Data Tables", IEEE 1703/D5, 912 revised May 2010. 914 [7] Measurement Canada, "Draft Specification for Local Area 915 Network/Wide Area Network (LAN/WAN) Node Communication 916 Protocol to Complement the Utility Industry End Device Data 917 Tables", MC12.22, 2010. 919 [8] ISO/IEC, "Information Technology-Open Systems 920 Interconnection-Connectionless Protocol for the Association 921 Control Service Element: Protocol Specification", ISO/IEC 922 10035-1, 1995. 924 [9] ISO/IEC, "Information Technology-ASN.1 Encoding Rules: 925 Specification of Basic Encoding Rules (BER), Canonical 926 Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 927 ISO/IEC 8825-1, 2002. 929 [10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 930 1980. 932 [11] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 933 September 1981. 935 [12] Deering, S.E., "Host extensions for IP multicasting", STD 5, 936 RFC 1112, August 1989. 938 [13] Cain, B., Deering, S., Kouvelas, I., Fenner, B., Thyagarajan, 939 A., "Internet Group Management Protocol, Version 3", RFC 940 3376, October 2002. 942 [14] Vida, R., Costa, L., "Multicast Listener Discovery Version 2 943 (MLDv2) for IPv6", RFC 3810, June 2004. 945 [15] Conta, A., Deering, S., Gupta, M., "Internet Control Message 946 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 947 Specification", RFC 4443, March 2006. 949 [16] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 950 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 951 Protocol Specification (Revised) ", RFC 4601, August 2006. 953 [17] Hinden, R., Deering, S., "IP Version 6 Addressing 954 Architecture", RFC 4291, February 2006. 956 [18] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 957 RFC 2365, July 1998. 959 [19] Senie, D., "Changing the Default for Directed Broadcasts in 960 Routers", BCP 34, RFC 2644, August 1999. 962 6.2. Informative References 964 [Will be added as appropriate] 966 7. Acknowledgments 968 The authors wish to recognize Alexander Shulgin for providing 969 valuable comments and for conducting feasibility testing in support 970 of this work. 972 The following people have improved this document through thoughtful 973 comments and suggestions: Fred Baker, Vijay Gurbani, Alfred Hoenes 974 and Michael Stuber. 976 8. Authors' Addresses 978 Avygdor Moise 979 Future DOS R&D Inc. 980 #303 - 6707 Elbow Drive SW 981 Calgary, Alberta, T2V 0E5 982 Canada 984 Email: avy@fdos.ca 986 Jonathan Brodkin 987 Future DOS R&D Inc. 988 #303 - 6707 Elbow Drive SW 989 Calgary, Alberta, T2V 0E5 990 Canada 992 Email: jonathan.brodkin@fdos.ca