RFC 6142
ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP
RFC 6142: ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP 🎀
Okay bestie, the header deets: this is RFC 6142, written by A. Moise and J. Brodkin from Future DOS R&D Inc. It's from the Internet Engineering Task Force (IETF) and the category is Informational. ISSN is 2070-1721 and it was published in March 2011. The title block doesn't list anything it obsoletes or updates. 💅
Table of Contents 📑
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................3
4. The C12.22 IP Network Segment ...................................6
4.1. Composition of a C12.22 IP Network Segment .................6
4.2. Native IP Address ..........................................7
4.3. Encoding of Native IP Addresses ............................7
4.4. Standardized Port Numbers ..................................9
4.5. Use of UDP Source Port 0 ...................................9
4.6. IP Multicast ..............................................10
4.7. IP Broadcast ..............................................12
4.8. Encoding of Multicast and Broadcast Addresses .............12
5. IP Message Transport ...........................................14
5.1. C12.22 Connection Types and TCP/UDP Transport Modes .......14
5.2. IP Message Transport Details ..............................15
5.2.1. TCP and UDP Port Use ...............................15
5.2.2. Active-OPEN UDP Mode (CL=1, CL Accept=0) ...........16
5.2.3. Passive-OPEN UDP Mode (CL=1, CL Accept=1) ..........17
5.2.4. Active-OPEN TCP Mode (CO=1, CO Accept=0) ...........17
5.2.5. Passive-OPEN TCP Mode (CO=1, CO Accept=1) ..........18
5.2.6. TCP and C12.22 Message Directionality ..............18
5.3. Using IP Broadcast/Multicast ..............................19
5.4. Transport Protocol Decisions ..............................20
5.4.1. Unicast Versus Multicast Versus Broadcast ..........20
5.4.2. Sending Large C12.22 APDUs Using UDP ...............20
5.4.3. Choice of Protocol for C12.22 Response APDUs .......20
5.5. Quality of Service ........................................20
5.6. Congestion Control ........................................21
6. Security Considerations ........................................21
7. IANA Considerations ............................................23
8. Acknowledgments ................................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................25Abstract 🦋
This RFC gives you a framework for sending ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages over an IP network. It's giving blueprint ✨
It is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups, okay? It was made by people who were actually in those groups, and they built on what they knew from several proprietary C12.22-over-IP implementations. The content is basically a consensus rollup of those implementations, so it's a group project with main character energy 🫶
Status of This Memo 🌸
This one is not an Internet Standards Track spec. It's published for informational purposes, so no official standard vibes here 🙈
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full story 📖
If you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc6142. ✨
Copyright Notice 💜
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please actually read those, because they lay out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. Be careful with that one 🔥
1. Introduction ✨
The ANSI C12.22 standard [1] gives you a set of application layer messaging services for the enterprise and End Device parts of an Advanced Metering Infrastructure (AMI) for the Smart Grid. These services are tailored for, but not limited to, exchanging the Data Table Elements that are defined and co-published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [23]. These standards were developed jointly by ANSI (ANSI C12.22 and ANSI C12.19), IEEE (IEEE 1377 and IEEE 1703), and Measurement Canada (MC12.19 and MC12.22). So many cooks 👑
ANSI C12.22 is an application level messaging protocol, and it may be transported over any underlying transport network. This RFC defines the requirements for sending ANSI C12.22 Messages over the TCP and UDP transports on IP networks. In this setup, the OSI Session, Presentation, and Application Layers of ANSI C12.22 get collapsed into one single Application Layer. It's giving streamlined 🧚
More specifically, this RFC applies to the operational details of Section 5, "C12.22 Node to C12.22 Network Segment Details", of ANSI C12.22. It covers mapping, encoding, and interpreting ANSI C12.19 Device Network Table Elements and Native Addresses for use on IP networks. That's the whole tea ☕
2. 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 [4]. Those are the only capitalized ones that carry requirement weight, so keep an eye on them 👀
Throughout this document we say things like "ANSI C12.22" or "ANSI C12.19," as in "C12.22 Relay" or "ANSI C12.19 Device." These terms are interchangeable with "IEEE 1703 Relay" and "IEEE 1377 Device," respectively. Lowkey confusing at first, but it's just naming drift 🦋
The newer versions of the Utility End Device communication standards were developed under the auspices of ANSI C12 SC17 WG1 and ANSI C12 SC17 WG2. So the terminology here builds on the ANSI C12.22-2008 [1] and ANSI C12.19-2008 [2] definitions, as revised by IEEE 1703-2010 [5] and IEEE 1377-2010 [3]. It's a whole glow-up, periodt 💖
3. Definitions ✨
okay so this section is basically the glossary, and it's SO important bestie 💅 It defines the roles that participants (actors) play in, and the objects of, the ANSI C12.22 [1], IEEE 1703 [5], and MC12.22 [24] protocol. Any terms starting with "C12.22" or "C12.19" that aren't defined here can be looked up in [1], [5], [24] or in [2], [3], [23]. 🧚
ACSE
Association Control Service Element. In this spec and in [1], ACSEs get encoded per ISO/IEC 10035-1 [6] using the ASN.1 Basic Encoding Rules (BER) [7]. 🎀
Active-OPEN UDP
Active-OPEN UDP is a state a local C12.22 IP Node uses to wait for and catch incoming C12.22 Messages that it asked for from a foreign C12.22 IP Node over UDP. The local node MAY leave this state once it has gotten all the C12.22 Messages it was expecting, or once a C12.22 Message timeout has happened. 💀 It also catches all the C12.22 Response Messages that the foreign node sends back to the local port number matching the source port number it used when asking. 🦋
Active-OPEN TCP
Active-OPEN TCP is a state a local C12.22 IP Node uses to set up a TCP connection with a fully specified foreign C12.22 IP Node, using TCP and that foreign node's registered Native IP Address. Honestly it's identical to a local "Active-OPEN" as defined in [9]. 🌸
APDU
Application Protocol Data Unit. In the ANSI C12.22 Application, an APDU is an ACSE C12.22 Message. 💖
ACSE APDU
ACSE Application Protocol Data Unit. It's the same thing as an APDU, so no new drama here 🙄✨
ApTitle
An ANSI C12.22 Application-process Title. An ApTitle is a name for a system-independent application activity that shows application services to the application agent. Think of a set of application service elements that work together to handle all or part of the communication side of an application process. 👑 An ApTitle gets encoded as a unique registered object identifier (as per [1]).
C12.22 IP Node
A C12.22 Node that lives on a C12.22 IP Network Segment and talks using the Internet Protocol. 🧚
C12.22 IP Network Segment
A group of all the C12.22 IP Nodes that use the IP-based protocols defined in this spec. They can all talk to each other through IP routers, switches, and bridges, without needing a C12.22 Relay. 🌈
C12.22 IP Relay
A C12.22 IP Node that does the jobs of a C12.22 Relay. It acts as a bridge between a C12.22 IP Network Segment and an adjacent C12.22 Network Segment. 🍓
C12.22 Message
This one is a big deal 🔥 A C12.22 Message is either an ACSE APDU that's fully assembled, or a segment of a C12.22 Request Message, or a segment of a C12.22 Response Message. Any C12.22 Message described in this spec MUST be encoded using [7]. No skipping this step, bestie.
C12.22 Request Message
A fully assembled C12.22 APDU that holds an ACSE user-information element, which includes one or more EPSEM Service Requests. 💅
C12.22 Response Message
A fully assembled C12.22 APDU that holds 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 [1]. It's giving linked-up energy 🫶
EPSEM
Extended Protocol Specification for Electronic Metering. EPSEM defines the structures and services used to encode multiple requests and responses for devices like gas, water, and electricity meters, plus related electronic modules or appliances. ⚡
Initiating C12.22 IP Node
A role a C12.22 IP Node plays when it starts sending a C12.22 Request Message. It's the one making the first move 🦋
Native Address
"Native Address" means the transport address that can be used to reach a C12.22 Node on its C12.22 Network Segment [1]. In this spec, the Native Address refers to the Native IP Address. 🎀
Passive-OPEN UDP
Passive-OPEN UDP is a state a local C12.22 IP Node uses to wait for and receive incoming C12.22 Messages from any foreign C12.22 IP Node over UDP. While this state is active, the local node accepts all C12.22 Messages that arrive at the local port number it registered. 🌸
Passive-OPEN TCP
Passive-OPEN TCP is a state a local C12.22 IP Node uses when it wants to set up a TCP connection with an unspecified foreign C12.22 IP Node. In this case, any foreign C12.22 IP Node MAY connect to the local node, as long as the local port matches the port the foreign node used. It's identical to the "local passive OPEN" defined in [9]. 🧚
Responding C12.22 IP Node
A role a C12.22 IP Node plays when it responds to receiving a C12.22 Request Message. 💜
Target C12.22 IP Node
The C12.22 IP Node that's the destination for a C12.22 Message. 🎯
4. The C12.22 IP Network Segment ✨
okay now we're getting into the good stuff 🤩 This section defines what the C12.22 IP Network Segment is actually like.
4.1. Composition of a C12.22 IP Network Segment
A C12.22 Network Segment is a group of C12.22 Nodes that can talk to each other directly, without having to forward C12.22 Messages through a C12.22 Relay. Direct and no middleman, iconic 💅
A C12.22 IP Network Segment is made up of C12.22 IP Nodes plus the network infrastructure that lets any one node reach all the other nodes on the same segment. Every C12.22 IP Node on the segment uses the same IP address encoding scheme (shown in Figures 1 and 2) and the same network and transport protocols, following this spec. Consistency is everything, periodt 🎀
There's no size limit on a C12.22 IP Network Segment. It MAY be as small as a single LAN or subnet, or it MAY include lots of different LANs and WANs linked together by routers, bridges, and switches. The segment MAY be totally private, or it MAY include communication across the global Internet 🌈
4.2. Native IP Address
"Native IP Address" means a Native Address that MAY be used to reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP Address includes the binary IP address, plus an OPTIONAL port number, which MAY be followed by an OPTIONAL protocol identifier. The Native IP Address SHALL be encoded as described in Section 4.3, "Encoding of Native IP Addresses". 🧚
The IP address of the C12.22 IP Node MUST be configured before the node tries to send or receive any C12.22 Message on its C12.22 IP Network Segment. Real talk, that's a hard rule 😭 If the controlling application doesn't explicitly configure the port number, it SHALL be set to the default port number, 1153 (see Section 4.4, "Standardized Port Numbers", below). 🍓
It's beyond the scope of this spec to define how configuration works, what the configuration parameters are, or any administrative controls a system administrator might want to use to assign an IP address. That's their whole vibe, not ours 💅
4.3. Encoding of Native IP Addresses
ANSI C12.22 defines binary fields for encoding a C12.22 Native Address, so it can be transported inside C12.22 Messages and stored in C12.19 Device Tables. In this RFC, these fields SHALL contain a binary native IP address, either IPv4 or IPv6, followed by an OPTIONAL two-byte TCP or UDP port number. When that port number is present, it MAY be followed by an OPTIONAL one-byte transport protocol identifier ("Protocol" for IPv4 or "Next Header" for IPv6). 🦋
The transport protocol identifier SHALL be set to 17 (0x11) for UDP transport, or to 6 (0x06) for TCP transport, or it SHALL be left not set (absent) for both UDP and TCP transports. The transport protocol values SHALL also be consistent with the C12.22 Node's registered attributes. See the Connectionless (CL) and Connection-Oriented (CO) flags in Section 5.1, "C12.22 Connection Types and TCP/UDP Transport Modes", below. Consistency check, bestie ✨
ANSI C12.22 lets the Native Address fields be carried in certain ANSI C12.22 EPSEM service elements. Examples are the ANSI C12.22 Registration Service <native-address>, the ANSI C12.22 Resolve Service response <local-address>, and the ANSI C12.19 INTERFACE_CTRL_TBL Element NATIVE_ADDRESS. The length of the C12.22 Native Address is marked by an ANSI C12.22 address length field, such as the ANSI C12.22 Registration Service <address-length>, the ANSI C12.22 Resolve Service response <local-address-length>, and the ANSI C12.19 ACT_NETWORK_TBL Element NATIVE_ADDRESS_LEN. 🌸
The ANSI C12.22 Registration Service only lets you record one Native Address per registered ApTitle. So a C12.22 IP Node that wants to register different port numbers for UDP and TCP MUST register twice, using different ApTitles. Two identities for two vibes 👯♀️
The binary Native IP Address fields SHALL be encoded in network byte order, as shown in Figure 1. 🎀
IP Address (ADDR), Port (P), Transport (T)
Address
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 4 | ADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4+Port 6 | ADDR4 | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4+Port 7 | ADDR4 | P |T|
+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 16 | ADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6+Port 18 | ADDR6 | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6+Port 19 | ADDR6 | P |T|
+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Encoding of the Native IP Addresses for ANSI C12.22
When an ANSI C12.22 Native Address gets encoded in the ANSI C12.19 Tables' BINARY data Elements, the size of the Native Address Element is set by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (see Table 121 of [1], and [2]). That's the actual number of octets placed inside the C12.19 BINARY Element. This value is shared by all of the C12.22 Node's interfaces, including the non-IP ones that don't follow this spec. Because of that, ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than the length needed to encode a Native IP Address per Figure 1, but it SHALL NOT be smaller than that length. When it's bigger, the C12.22 Native IP Address SHALL be padded with zero (0) to fill the Table's BINARY data Element. 🧸
In cases where the Native IP Address length doesn't exactly match any of the Address Lengths listed in Figure 1, the actual Address Length SHALL be determined by stripping all the trailing binary zeros (0x00). Then the Address Length gets bumped up to the next largest value shown in Figure 1. Math with vibes 🧮💖
4.4. Standardized Port Numbers 🧚
okay so IANA (Internet Assigned Numbers Authority) gave port 1153 to C12.22 IP Messages over both UDP [8] and TCP [9] 🎀
by default, C12.22 IP Nodes SHALL send every C12.22 Application association initiation message request with 1153 as the destination port number 💅
to keep everything interoperable, all C12.22 IP Relays and Master Relays SHALL monitor and accept UDP and TCP messages aimed at port 1153 🫶
and any IP firewalls or Access Control Lists (ACLs) shielding C12.22 Nodes and the IP network MUST be configured to forward UDP and TCP traffic to port 1153, plus any other ports the network administrator has assigned and registered. this is how the C12.22 IP Network Segment stays connected 🔥
4.5. Use of UDP Source Port 0 🌸
so RFC 768 [8] technically lets a source port be zero (0), but ngl, C12.22 IP Nodes SHALL NOT send datagrams on UDP with the source port set to zero 🙈 a C12.22 IP Node SHALL ignore any C12.22 Message that comes from source port 0, and it SHALL NOT respond to it either 💀
more details on how a C12.22 IP Node uses UDP and TCP are in Section 5, "IP Message Transport", below ✨
4.6. IP Multicast 🦋
okay this part is giving main character energy 👑 besides unicast, the ANSI C12.22 protocol needs the network to support a multicast message delivery service. when C12.22 IP Nodes MUST perform Native IP Address discovery (like finding the Native IP Address of C12.22 IP Relays that provide a route out of the C12.22 IP Network Segment, or finding the Native IP Address of a C12.22 IP Master Relay on the C12.22 IP Network), they use IP multicast to send a C12.22 Message containing an EPSEM Resolve Service Request on the IP LAN 🧚
IP multicast is also super useful when a C12.22 Host needs to read a bunch of C12.22 Nodes (like meters) that share a common C12.22 multicast group ApTitle. with IP multicast, the C12.22 Host MAY send a C12.22 Message containing an EPSEM Read Service Request that reaches every C12.22 Node on the C12.22 IP Network Segment 💜
so for all of that, all C12.22 IP Relays and Master Relays SHALL support IP multicast, and it is RECOMMENDED that all C12.22 Nodes support IP multicast too 🌈 any IPv4 C12.22 IP Node that supports IP multicast SHALL use the Internet Group Management Protocol version 1 (IGMPv1) [10] as a minimum to report (aka request) membership in the C12.22 multicast group to its local router(s). it is RECOMMENDED that C12.22 IP Nodes implement IGMPv3 [11] 🎀
any IPv6 C12.22 IP Node that supports IP multicast SHALL use Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [12]) to report membership, possibly inside ICMPv6 (RFC 4443 [13]) 🫧
routers that connect C12.22 IP Nodes on the C12.22 IP Network Segment MUST support Protocol Independent Multicast - Sparse Mode (PIM-SM) (RFC 4601 [14]) along with IGMPv1 (RFC 1112 [10]) as a minimum for IPv4, or MLDv2 for IPv6 (RFC 3810 [12]). it is RECOMMENDED that they implement IGMPv3 [11] too. this spec doesn't define how to pick an initial Rendezvous Point (RP) for the C12.22 multicast group, whether to use shared or source trees, or how inter-domain multicast routing works. that's outside the scope here 🙈
IANA registered the "All C1222 Nodes" multicast group and assigned the IPv4 multicast address 224.0.2.4 and the IPv6 multicast address FF0X::204, where X is the Scope field as defined in RFC 4291, "IP Version 6 Addressing Architecture" [15] ✨
for IPv6, all C12.22 IP Relays, C12.22 IP Master Relays, and all C12.22 IP Nodes configured to support broadcast and multicast (see Section 5.3, "Using IP Broadcast/Multicast", below) SHALL join the global-scope multicast address FF0E::204, plus 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 starting IP multicast messages to reach another C12.22 IP Node on the C12.22 Network. this keeps the sender from spreading C12.22 IP Multicast Messages further than they need to go 🌸
to find the minimum scope needed to reach the closest C12.22 IP Relay on the C12.22 Node's IP Network Segment, this spec RECOMMENDS these simple steps:
- Starting with the smallest (local-most) scope (i.e., link-local scope or another pre-configured scope), send the C12.22 EPSEM Resolve Service Request to discover a C12.22 IP Relay.
- 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, record the scope level as the minimum scope to use on the node's C12.22 IP Network Segment.
a C12.22 IPv6 Node that starts any EPSEM Service Request SHOULD use the minimum scope necessary to reach its Target C12.22 IP Nodes. a C12.22 IPv6 Relay SHALL use the global scope for any C12.22 Message headed for the global Internet 💖
this spec doesn't stop anyone from using the unassigned scope values defined in [15]. those scope values MAY be used privately or through mutual operating agreements 🫶
for IPv4, all C12.22 IP Relays, C12.22 IP Master Relays, and all C12.22 IP Nodes configured to support broadcast/multicast SHALL join the assigned multicast address 224.0.2.4. this global address doesn't do the kind of scoping we just talked about for IPv6, and it isn't compatible with the administratively scoped IP multicast spec in RFC 2365 [16]. so a different technique is needed to limit the spread of C12.22 IP Multicast Messages. one option is the Time-to-Live (TTL) attribute in the IP packet header. the C12.22 protocol doesn't manage this attribute 🦋
to use that technique, an administrative domain MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in that administrative domain SHOULD be configured with a TTL big enough to reach that C12.22 IP Relay 🧚
a C12.22 IPv4 Node that starts any C12.22 Request Message SHOULD use the minimum TTL needed to reach its Target C12.22 IP Nodes 🌈
4.7. IP Broadcast 🌈
ok so IP broadcast usually isn't a good swap for multicast in a C12.22 IP Network Segment. it isn't supported in IPv6, and in IPv4 it has limited scope 🙃 this spec still doesn't block using IP network directed or limited/local scope broadcast (address 255.255.255.255) inside a controlled management domain (as per RFC 2644 [17]) 🫧
4.8. Encoding of Multicast and Broadcast Addresses 💖
the ANSI C12.22 Tables have BINARY Elements for encoding a broadcast or multicast Native IP Address to send inside a C12.22 Message. encoding these Table Elements works the same as in Section 4.3, "Encoding of Native IP Addresses". these fields SHALL be used as shown in Figure 2 🎀
IP Address (ADDR), Port (P), Transport (T)
Address
Length Octet
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 4 |BADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 6 |BADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Broadcast 7 |BADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 4 |MADDR4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 6 |MADDR4 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 7 |MADDR4 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 16 | MADDR6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 18 | MADDR6 | P |
+Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast 19 | MADDR6 | P |T|
+Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encoding of Broadcast/Multicast Native IP Addressesthe IPv4 and IPv6 multicast addresses (MADDR4 and MADDR6) are the ones IANA assigned for ANSI C12.22 use 🧚
when a broadcast/multicast Native IP Address gets encoded in the ANSI C12.19 Tables' BINARY data Elements, the size of the Native Address Element that gets sent is set by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (see Table 121 of [1], and [2]). that's the actual number of octets that go inside the C12.19 BINARY Element. this value is shared by all of the C12.22 Node's interfaces, including the non-IP ones (which don't follow this spec), so ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than the length needed to encode a broadcast/multicast Native IP Address per Figure 2, but it SHALL NOT be smaller. when it's bigger, the C12.22 Native IP Address SHALL be padded with zero (0) to fill the Table's BINARY data Element 🫶
the IPv4 network directed broadcast address can be worked out by doing a bitwise OR between the bit complement of the target IP subnet's subnet mask and the IP address of any host on that subnet 🍓
5. IP Message Transport 👑
this section lays out how a C12.22 Node uses the Connection-Oriented (CO) and Connectionless (CL) transport layer protocols, which are TCP and UDP respectively 💜
5.1. C12.22 Connection Types and TCP/UDP Transport Modes 🎀
okay so a C12.22 IP Node's TCP and UDP behavior depends on what it's registered to do ✨ Those capabilities live in its configuration parameters (flags) and show up in its 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 connection-type parameters map to the IP-based transport variants a C12.22 Node MAY support, and that mapping is laid out in Table 1 🦋
+------+------+----------+----------+-------------------------------+
| CL | CO | CL | CO | IP Transport Mode Supported |
| Flag | Flag | Accept | Accept | |
| | | Flag | Flag | |
+------+------+----------+----------+-------------------------------+
| 0 | 0 | x | x | Invalid |
| 0 | 1 | 0 | 0 | TCP, Active-OPEN |
| 0 | 1 | 0 | 1 | TCP, Passive- and Active-OPEN |
| 0 | 1 | 1 | 0 | Invalid |
| 0 | 1 | 1 | 1 | Invalid |
| 1 | 0 | 0 | 0 | UDP, Active-OPEN |
| 1 | 0 | 0 | 1 | Invalid |
| 1 | 0 | 1 | 0 | UDP, Passive- and Active-OPEN |
| 1 | 0 | 1 | 1 | Invalid |
| 1 | 1 | 0 | 0 | UDP, Active-OPEN; TCP |
| | | | | Active-OPEN |
| 1 | 1 | 0 | 1 | UDP, Active-OPEN; TCP, |
| | | | | Passive- and Active-OPEN |
| 1 | 1 | 1 | 0 | UDP, Passive- and |
| | | | | Active-OPEN; TCP, Active-OPEN |
| 1 | 1 | 1 | 1 | UDP, Passive- and |
| | | | | Active-OPEN; TCP, Passive- |
| | | | | and Active-OPEN |
+------+------+----------+----------+-------------------------------+Table 1: C12.22 Node Parameters to IP Transport Mapping
Now the big rule 💅 Every C12.22 IP Node MUST support at least one of the unicast CO or CL operating capabilities. You can see those advertised in Decade 12, "Node Network Control Tables" [1] where that's available, and you register them through the C12.22 Registration Service [1]. No skipping this one, bestie 🙈
5.2. IP Message Transport Details 🧚
5.2.1. TCP and UDP Port Use 💖
General rules, let's go:
- A C12.22 IP Node that implements
[CL Accept=1]SHALL receive incoming UDP C12.22 Messages on its registered Native IP Address (IP address and port number). - A C12.22 IP Node that implements
[CO Accept=1]SHALL receive incoming TCP connections on its registered Native IP Address (IP address and port number). - A C12.22 IP Relay that forwards a UDP C12.22 Message to a C12.22 IP Node on the C12.22 IP Network Segment SHALL send the C12.22 Message to the C12.22 IP Node's registered Native IP Address (IP address and port number).
- A C12.22 IP Relay that forwards a TCP C12.22 Message to a C12.22 IP Node on the C12.22 IP Network Segment MAY use an established TCP connection to that C12.22 IP Node, or it SHALL establish a new TCP connection to the C12.22 IP Node's registered Native IP Address (IP address and port number).
- A C12.22 IP Node that implements
[CL=1]SHOULD set the source port number in outbound UDP C12.22 Messages to its registered port number. When the target UDP C12.22 IP Node is reachable using direct messaging (as defined in [1]), the C12.22 IP Node MAY set the source port number to a UDP port number that is different than its registered port number. - When the registered Native IP Address of a C12.22 IP Node does not include the OPTIONAL port number, then port 1153 SHALL be assumed and used as the registered port number.
- All C12.22 IP Nodes SHOULD use port 1153 in their Native IP Address when registering.
5.2.2. Active-OPEN UDP Mode (CL=1, CL Accept=0) 🌸
A C12.22 IP Node that supports this mode SHALL NOT monitor for unsolicited incoming C12.22 Messages via UDP. So the node literally can't receive unsolicited C12.22 Messages over UDP. It's giving send-only energy 📤
The C12.22 IP Node MAY enter the Active-OPEN UDP state by starting an unsolicited UDP transmission to a Target C12.22 IP Node, which is expected to implement the Passive-OPEN UDP mode.
C12.22 IP Nodes SHOULD use their registered UDP port number as the source port number for all UDP C12.22 IP Messages. If they aren't registered yet, they SHOULD use port 1153 as the source port number instead 🦋
5.2.3. Passive-OPEN UDP Mode (CL=1, CL Accept=1) 👑
A C12.22 IP Node in this mode SHALL be capable of receiving solicited and unsolicited C12.22 Messages from other C12.22 IP Nodes. The C12.22 Node MAY change the port number it monitors by using the <native-address> parameter of the ANSI C12.22 Registration Service. The C12.22 IP Node MAY also start unsolicited Active-OPEN UDP transmissions to other C12.22 IP Nodes that implement the Passive-OPEN UDP mode.
When operating in this mode, the C12.22 IP Nodes SHALL use their registered UDP port number as the source port number for all UDP C12.22 IP Messages.
All C12.22 IP Relays SHALL support the Passive-OPEN UDP mode. C12.22 Authentication Hosts and C12.22 Notification Hosts that implement UDP SHALL support the Passive-OPEN UDP mode too. For all other C12.22 IP Nodes, the Passive-OPEN UDP mode is the RECOMMENDED mode when implementing UDP ✨
5.2.4. Active-OPEN TCP Mode (CO=1, CO Accept=0) 🍓
A C12.22 IP Node that supports this mode SHALL NOT monitor for inbound TCP connections. That means the node can't accept incoming connections over TCP at all 🙃 The C12.22 IP Node MAY start TCP connections to Target C12.22 IP Nodes, which are expected to implement the Passive-OPEN TCP mode.
In this mode, C12.22 Messages exchanged by a pair of associated C12.22 IP Nodes can only travel through the TCP connections that the Active-OPEN node initiated. If a connection is lost or closed, that SHALL NOT automatically end the C12.22 associations between the peer nodes. To keep exchanging C12.22 Messages without losing the association, the initiating C12.22 IP Node MAY re-establish new TCP connections with the peer node, or use the existing connections to the peer node. Whether the associations actually end depends on C12.22 Application timeout attributes and C12.22 link management services (such as Procedure 25, "Network Interface Control" [1]) 🧠
5.2.5. Passive-OPEN TCP Mode (CO=1, CO Accept=1) 💜
A C12.22 IP Node in this mode SHALL monitor and accept incoming TCP connections. The C12.22 Node MAY change the port number it monitors by using the <native-address> parameter of the ANSI C12.22 Registration Service. The C12.22 IP Node MAY also start Active-OPEN TCP connections to other C12.22 IP Nodes that implement the Passive-OPEN TCP mode.
In this mode, C12.22 Messages exchanged by a pair of associated C12.22 IP Nodes can arrive through any of the TCP connections that either node established. If a connection is lost or closed, that SHALL NOT automatically end the C12.22 associations between the peer nodes. To keep exchanging C12.22 Messages without losing the association, either C12.22 IP Node MAY re-establish new TCP connections with the peer node, or use the existing connections to the peer node. As before, the association ending depends on C12.22 Application timeout attributes and C12.22 link management services (such as Procedure 25, "Network Interface Control" [1]) 🫶
C12.22 Authentication Hosts and C12.22 Notification Hosts that implement TCP SHALL support Passive-OPEN TCP mode, and all C12.22 IP Relays SHALL support it too. For all other C12.22 IP Nodes, Passive-OPEN TCP mode is the RECOMMENDED mode when implementing TCP 💅
5.2.6. TCP and C12.22 Message Directionality 🌈
C12.22 IP Nodes MAY use TCP in one of two ways: bi-directional traffic flow or uni-directional traffic flow.
When TCP connections are used, either direction works. Any new or established TCP connection between the two C12.22 IP Nodes MAY be used equally by them to send and to receive C12.22 Messages. This is the RECOMMENDED and default mode of operation, because ANSI C12.22 requires the transport network to be reliable and connectionless (per connectionless-mode ACSE). That's why ANSI C12.22 defines peer-to-peer application associations and not peer-to-peer connections ✨
Some C12.22 implementations are known to have been deployed with TCP used for uni-directional traffic flow. For those, an established TCP connection SHALL be used by the initiator of that connection to send C12.22 Messages, and by the target node (the one that accepted the connection) to receive them. If a C12.22 IP Node wants to send a C12.22 Message to a peer C12.22 IP Node, it MUST establish and use a new TCP connection, or use an existing TCP connection it had previously initiated, for its outbound uni-directional traffic flow 🙈
For better interoperability, the initiator of the connection SHOULD accept incoming C12.22 Messages on that connection, just in case the target node tries to use it for bi-directional traffic flow 🫶
Uni-directional use of TCP is a special mode, and it is NOT RECOMMENDED. ANSI C12.22 doesn't describe multiple one-way channel communication, and it uses up one half of the TCP connection capability. So it doubles the number of TCP connections needed to communicate C12.22 Messages, which can turn into a real burden when a lot of connections are required 😭
5.3. Using IP Broadcast/Multicast ✨
okay so a C12.22 IP Node figures out its broadcast/multicast vibe from its capabilities, which live in its configuration parameters (flags) and its accepted registration attributes [1] (<connection-type>.BROADCAST_AND_MULTICAST_SUPPORTED). the way the Broadcast/Multicast flag maps to actual IP broadcast/multicast usage is laid out in Table 2 💅
C12.22 Broadcast and IP Broadcast/Multicast Supported
Multicast Supported
Flag
---------------------- ----------------------------------------------
0 The C12.22 IP Node does not accept IP
broadcast, and it does not accept IP multicast
messages.
1 The C12.22 IP Node accepts both IP broadcast
(IPv4 only) and IP multicast messages (IPv4
and IPv6).
Table 2: C12.22 to IP Broadcast/Multicast MappingIf a C12.22 IP Node is set up to accept IP broadcast and multicast messages, it SHALL join the "All C1222 Nodes" multicast group (see Section 4.6, "IP Multicast", above), and SHALL use the default port 1153. It also SHALL accept IP network directed or limited (local scope) broadcast messages sent to port 1153. ngl, network directed broadcast only works if the network routers are configured for it, because by default they SHALL NOT forward directed broadcasts as per RFC 2644 [17] 🙈
5.4. Transport Protocol Decisions 🦋
5.4.1. Unicast Versus Multicast Versus Broadcast
An initiating C12.22 IP Node MAY send any C12.22 Message using UDP or TCP. Still, in line with Section 5.3.2.4.12, "Resolve Service", of ANSI C12.22, it is RECOMMENDED that the C12.22 Resolve Request Message go out using UDP/IP multicast when the Native IP Address of the Target C12.22 Node is not known. UDP/IP multicast is the preferred option over IP network directed or limited broadcast, so when UDP/IP multicast is supported, its use is RECOMMENDED over network broadcast. Multicast is the main character here 👑
5.4.2. Sending Large C12.22 APDUs Using UDP
When sending a large C12.22 Message over UDP that exceeds the path MTU, the sender SHALL segment the ACSE APDU following the ANSI C12.22 Datagram Segmentation and Reassembly algorithm. The resulting IP datagram size has to stay within the path MTU so it avoids UDP packet fragmentation. Fragmentation is a problem for both IPv4 and IPv6, fr fr 💀 Section 3.2 of RFC 5405 [18] gives more guidance on picking the right UDP message size. When the path MTU is not known, the sender SHALL follow the guidelines in Section 3.2 of RFC 5405 [18]: for IPv4, use the smaller of 576 bytes and the first-hop MTU [19], and for IPv6, use 1280 bytes [20]. Sending large APDUs over UDP may lead to network congestion, so check out Section 5.6, "Congestion Control" for how to avoid that 🌸
5.4.3. Choice of Protocol for C12.22 Response APDUs
When a Target C12.22 IP Node gets 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 (so TCP to TCP, UDP to UDP). 🫶
If it's UDP, the target SHALL send the C12.22 Response Message back to the source IP address and port number.
5.5. Quality of Service 🎀
The ANSI C12.22 standard gives you a configuration parameter in the APDU's <calling-AE-qualifier>.URGENT attribute to mark a message as urgent. There are a bunch of IP-based technologies that deliver better message delivery and quality of service levels. This specification doesn't define which technology to use for sending urgent messages over IP, so that's a whole separate convo 🧚
5.6. Congestion Control 🌈
Designers of unicast applications that run the upper layers of C12.22 messaging over UDP SHOULD follow the congestion control guidelines in Section 3.1 of RFC 5405 [18].
For C12.22 Messages bigger than what the TCP initial window would be over a given Internet path, TCP SHOULD be used instead of UDP as the transport protocol. TCP's initial window depends on the maximum segment size (MSS), which depends on the path MTU, and it's computed with formula (1) in RFC 3390 [21]. For unknown path MTUs, the smallest allowable MSS MUST be used, and the C12.22 Application SHOULD assume the maximum C12.22 Message size to be 2048 bytes. Using TCP means the C12.22 Application gets the built-in TCP congestion control mechanism for free, which is so iconic 😭
When UDP is the preferred transport, or when UDP multicast or broadcast are the preferred modes of communication, the C12.22 Application SHOULD use C12.22 acknowledged Messages that are smaller than TCP's initial window over the return path, as computed by formula (1) in [21] and described above. The size of the C12.22 Message MAY be managed through ANSI C12.22 EPSEM Partial Table Read/Write Service Requests and Responses.
6. 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 message privacy and authentication, playback rejection, and message acceptance windows, plus ANSI C12.19 [2] role-based data access and secured register mechanisms. The ANSI C12.22 Application Layer default security mechanism gives you three options when sending C12.22 Messages:
- Sending cleartext messages over the C12.22 Network [1], [5], which MAY result in altered C12.22 Messages and exposure to password sniffing attacks, as described in RFC 3552 [22].
- Sending authenticated plaintext messages over the C12.22 Network [1], [5], which MAY result in password sniffing attacks as described in RFC 3552 [22].
- Sending authenticated ciphertext over the C12.22 Network, providing message and peer node authentication and privacy.
When option 1 is used, it is RECOMMENDED that the network or transport layer provide authentication and confidentiality services. When option 2 is used, it is RECOMMENDED that the network or transport layer provide confidentiality services. When option 3 is used, no additional network or transport layer security services are necessary. 🔐
Additional transport or network layer security protocols are not required by ANSI C12.22, but they MAY be provided transparently by C12.22 IP Network Segment integrators (e.g., in C12.22 IP Relays) to improve on the security provisions cited above. However, any added transport security (e.g., Transport Layer Security (TLS), RFC 5246 [27]) or IP security (e.g., IPsec, RFC 4302 [25], RFC 4303 [26], RFC 5996 [28]) features SHALL act only to enhance (i.e., not be a substitute for, or an alteration of) the interoperable ANSI C12.22 and ANSI C12.19 security provisions. They SHALL NOT corrupt and SHALL NOT alter the C12.22 Message as presented by the C12.22 Application Layer. Hands off the message, bestie 🙅♀️
The ANSI C12.22 [1] and ANSI C12.19 [2] standards provide for the transmission of keys and their storage in C12.19 End Devices (e.g., meters and head-end systems). The key management protocol (when and how keys are exchanged) is not described in the ANSI C12.22 [1] and ANSI C12.19 [2] standards, except to say that keys MAY not be readable from a C12.19 End Device (in response to a Read Service Request). It is RECOMMENDED that all C12.22 Nodes encrypt user information element key fields and passwords. It is also RECOMMENDED that all C12.22 Nodes mask user information element key fields and password fields of EPSEM Read Service Responses (e.g., by replacing all key and password bytes with zeros (0x00) or spaces (0x20)).
Some legacy deployments aren't connected to the Internet, so some implementations don't include security. Multi-homed C12.22 Nodes with interfaces to the Internet will likely show up in future deployments, so security mechanisms MUST be used by those C12.22 Nodes to ensure C12.22 Message authentication and confidentiality. This part is SERIOUS, no cap ⚠️
7. IANA Considerations 📝
UDP and TCP port 1153, which is used for C12.22 communication over IP, is registered with IANA.
Section 4.6, "IP Multicast", defines the use of multicast. IANA has registered the following multicast addresses for use by the ANSI C12.22 standard:
IPv4 -- "All C1222 Nodes" address 224.0.2.4
IPv6 -- "All C1222 Nodes" address FF0X::2048. Acknowledgments 💜
The authors want to give a huge shoutout to Alexander Shulgin for providing valuable comments and running feasibility testing for this work 🙌
The following people made this document better with thoughtful comments and suggestions: Fred Baker, Ralph Droms, Vijay Gurbani, Michael Stuber, Spencer Dawkins, Alfred Hoenes, Russ Housley, Paul Hoffman, Lars Eggert, and Sean Turner. iykyk, they're the real ones 🍓
9. References 📚
9.1. Normative References 💖
These are the receipts, bestie 🧾✨ Every doc the spec leans on lives here, so you can go check them yourself.
[1] ANSI, "Protocol Specification for Interfacing to Data Communication Networks", ANSI C12.22-2008, January 2009.
[2] ANSI, "Utility Industry End Device Data Tables", ANSI C12.19-2008, February 2009.
[3] IEEE, "Draft Standard for Utility Industry Metering Communication Protocol Application Layer (End Device Data Tables)", IEEE P1377-2010, October 2010.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] IEEE, "Standard for Local Area Network/Wide Area Network (LAN/WAN) Node Communication Protocol to Complement the Utility Industry End Device Data Tables", IEEE P1703-2010, October 2010.
[6] ISO/IEC, "Information Technology-Open Systems Interconnection-Connectionless Protocol for the Association Control Service Element: Protocol Specification", ISO/IEC 10035-1, 1995.
[7] ISO/IEC, "Information Technology-ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1, 2002.
[8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[10] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[12] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[13] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[14] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[15] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[16] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[17] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[18] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[19] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[20] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[21] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[22] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
9.2. Informative References 🦋
These ones are the background reading 📚 Good to know, but the spec isn't leaning on them the same way.
[23] Measurement Canada, "Specification for Utility Industry Metering Communication Protocol Application Layer (End Device Data Tables)", Draft MC12.19, 2011.
[24] Measurement Canada, "Specification for Local Area Network/Wide Area Network (LAN/WAN) Node Communication Protocol to Complement the Utility Industry End Device Data Tables", Draft MC12.22, 2011.
[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[27] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[28] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
Authors' Addresses 🎀
The brains behind it, lowkey iconic 👑
Avygdor Moise
Future DOS R&D Inc.
#303 - 6707 Elbow Drive SW
Calgary, Alberta T2V 0E5
Canada
EMail: avy@fdos.ca
URI: http://www.fdos.caJonathan Brodkin
Future DOS R&D Inc.
#303 - 6707 Elbow Drive SW
Calgary, Alberta T2V 0E5
Canada
EMail: jonathan.brodkin@fdos.ca
URI: http://www.fdos.ca📦 where this page comes from
- ietf: rfc6142 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms