The ICCP Protocol Stack: OSI Over TCP/IP Explained

The first time you capture ICCP traffic in Wireshark, the protocol column reads like an archaeology dig: TCP, then TPKT, then COTP, then Session, Presentation, ACSE, MMS. Seven layers deep before a single power system value appears. This article explains what each layer does, why the stack looks like this, and — since this is where commissioning time actually goes — what has to match at each layer before two control centers can talk.

The stack is fixed by IEC 60870-6-702, the TASE.2 functional profile. Everything below is verified against it, with the QOS and priority material from IEC 60870-6-503.

Why ICCP carries a full OSI upper stack

ICCP was born in the early 1990s, when the industry direction was OSI networking. TASE.2 was specified as an OSI application, complete with presentation and session layers, expecting to run over OSI transport and networks that never conquered the world. TCP/IP did.

The fix was pragmatic: keep the entire OSI upper stack untouched and slide TCP/IP underneath it using RFC 2126, “ISO Transport Service on top of TCP” — ITOT. The OSI layers never notice. The result is the hybrid you see on the wire today, and it’s the same arrangement IEC 61850 MMS uses, which is why the two protocols share port 102, share vendor library code, and share Wireshark dissectors.

Is it elegant? No. Is it stable and universally implemented? Completely. Here it is, bottom-up.

Layer by layer, from the wire

IP — IPv4 mandatory

The profile is blunt: the lower layers shall be based on TCP/IP, and IPv4 implementation is mandatory. IPv6 is simply not addressed by the 2014 profile. In practice ICCP runs over private routed WANs — MPLS, utility-owned fiber, occasionally IPsec tunnels — and the addressing plan between two organizations is part of the link agreement.

The network layer also carries the QOS marking. The standard points to the ToS byte as defined by RFC 2474 and RFC 3168 — six bits of DSCP for per-hop priority treatment, two bits of ECN for congestion signaling — and requires end systems to encode it on transmitted packets. More on where the priority value comes from below.

Has to match / has to work: plain IP reachability between the ICCP server addresses, through every firewall on the path, in both directions. Long-lived TCP means any firewall with aggressive idle timeouts on the path will eventually kill healthy associations.

TCP and ITOT — RFC 2126, port 102

Above TCP sits ITOT per RFC 2126, which delivers the ISO transport service over a TCP connection. On the wire this shows as two thin sublayers: TPKT framing (a 4-byte header marking packet boundaries in the TCP stream) and COTP, the ISO 8073 connection-oriented transport protocol, running its class 0 handshake inside the TCP session.

The well-known port is 102 for non-secured connections and 3782 for TLS-secured ICCP, both registered with IANA — the same pair IEC 61850 MMS uses. If your organization runs both protocols, the destination IP, not the port, tells them apart.

COTP is where the first ICCP-specific addressing appears: the calling and called TSELs (transport selectors), short byte strings that must match what the peer expects.

Has to match: TCP port, and both TSEL values. A COTP connection refused right after the TCP handshake almost always means a TSEL mismatch.

Session — ISO 8327, version 2, duplex

The OSI session layer negotiated in ICCP is deliberately minimal. The profile requires session protocol version 2 and the duplex functional unit — full two-way simultaneous data — and marks essentially everything else out of scope: no expedited data, no typed data, no synchronization points, no activity management, no reuse of the transport connection. The session layer’s practical job in ICCP is carrying its selector and getting out of the way.

Has to match: calling and called SSELs (session selectors).

Presentation — ISO 8823 and ASN.1 BER

The presentation layer is where the bytes get their meaning: it negotiates the abstract syntaxes (ACSE, MMS) and their transfer syntax — ASN.1 Basic Encoding Rules. Every MMS message on an ICCP link is BER-encoded, which is why raw captures look like nested TLV structures rather than readable fields.

The profile requires the kernel functional unit in normal mode and adds three options on top of the base AMM11 profile: default context negotiation, default context name, and simply encoded data support. Context management and restoration are left out.

Has to match: calling and called PSELs (presentation selectors).

ACSE — the association layer

The Association Control Service Element (ISO 8650) establishes and tears down the application association. Four APDUs do the work: AARQ (associate request), AARE (associate response), RLRQ/RLRE (orderly release), ABRT (abort). Two profile details deserve attention.

First, the authentication functional unit is mandatory in the profile’s ACSE tables, and the AARQ/AARE parameter lists include ACSE user authentication per IEC/TS 62351-4. Support for the mechanism is required equipment; whether authentication is actually enforced on a given link is configuration. This is the layer where ICCP security lives when it’s turned on.

Second, ACSE is where the application addressing rides: the calling and called AP titles and AE qualifiers, which are exactly the identifiers the TASE.2 server checks against its bilateral table before admitting the client. The profile requires AE title form 2 (object identifier and integer) for sending, with form 1 accepted on receipt.

One more note from the profile: there is no requirement for either party to ever terminate an association. A healthy ICCP association stays up until the underlying connection is lost. Treat association drops as events worth alarming.

Has to match: AP title and AE qualifier, against the peer’s bilateral table. This is check number one and two of the bilateral table validation sequence.

MMS — the workhorse

MMS (ISO 9506) provides the actual services: Initiate, Read, Write, InformationReport, GetNameList, the named variable list operations, Conclude. TASE.2 operations map onto these one for one — a Get Data Value is an MMS Read, a transfer report arrives as an InformationReport. The MMS abort service, notably, is provided by ACSE.

The profile constrains MMS hard, in two directions. Identifiers are restricted to BasicIdentifier, at most 32 characters, and should not start with a digit; strings are restricted to the ISO 646 character set. And the service surface is cut to the bone: of the 86+ services MMS defines, everything TASE.2 doesn’t need — domain management, program invocation, semaphores, journals, file access, event management, operator communication — is marked excluded, meaning the implementation shall behave as if those services don’t exist. The stated reason is security: a smaller surface to attack, a smaller stack to validate.

What survives is roughly the environment management set (Initiate, Conclude, Reject), the variable access set (Read, Write, InformationReport, GetVariableAccessAttributes, the three named variable list services), GetNameList, and Identify. That short list carries every ICCP link in the world.

TASE.2 — the semantics

At the top, TASE.2 itself: the object models, bilateral table enforcement, transfer set condition monitoring, device control logic. Covered across the rest of this cluster; the point here is only that TASE.2 defines no encoding of its own. Every TASE.2 concept becomes MMS named variables and service calls, and everything below MMS is transport plumbing.

The five values that must match

Collecting the addressing from all layers, a peer’s “ICCP address” is a five-part tuple plus the IP endpoint:

Layer	Value	Typical form
Transport (COTP)	TSEL	Short hex/byte string, e.g. 0001
Session	SSEL	Short byte string, e.g. 0001
Presentation	PSEL	Short byte string, e.g. 00000001
ACSE	AP title	Object identifier, e.g. 1.1.999.1
ACSE	AE qualifier	Integer, e.g. 12

Both directions matter: your calling values must match what the peer’s bilateral table authorizes, and your configuration of their called values must match what their server presents. Exchange all five per endpoint, in writing, before commissioning. The CIM bilateral table exchange profile carries exactly these values in its ISOUpperLayer and TCP_AccessPoint classes — the standard acknowledging that this tuple is half the battle.

A field rule that saves hours: selector mismatches fail fast and low (COTP or session refusal right after TCP connects), application reference mismatches fail at ACSE with an association rejection, and bilateral table content problems fail late (association up, operations rejected). Where in the stack it dies tells you what to fix.

QOS and priority: agreed, never negotiated

ICCP’s quality-of-service model is unusual enough to trip up network engineers, so it’s worth stating plainly.

The bilateral agreement assigns a QOS value to each association the two centers will employ. Different traffic classes get different associations: the standard’s own example priority table ranges from controls (short, high priority, one-to-two-second response) down through schedules and reports to long file transfers. A link carrying both real-time data and bulk exchange would run them on separate associations with separate priorities.

The mechanism is strictly a priori. TASE.2 does not negotiate priority — the value is agreed between the centers in advance, handed to the transport layer per connection, and the standard explicitly prohibits the transport provider from changing it. When no priority is agreed, a default applies, and every system in the network must be configured with the same default.

From there it flows downhill: transport conveys non-default priority to IP per data unit, IP marks the packets, and the DSCP field signals the per-hop behavior to every router on the path. Congestion control is mandatory at the transport layer for conforming end systems.

The practical translation for the network team: ICCP QOS is your standard DSCP-based scheme, but the marking policy comes from a signed agreement between two companies, not from a router template. Align the DSCP plan across both organizations’ networks, or the priority evaporates at the interconnect.

Security across the stack

Two hooks, two layers. At the transport boundary, TLS on port 3782 protects the connection; at the application layer, ACSE authentication per IEC 62351-4 proves who is associating. The base stack without them offers no confidentiality and no authentication beyond the bilateral table’s identity check. The profile made the ACSE authentication machinery mandatory to implement and the 62351-4 usage optional to deploy — so capability is there in any conforming modern implementation, and turning it on is a configuration and agreement matter, not a procurement one. A dedicated article on securing ICCP links will cover the details.

FAQ