Every CIP I/O connection has a transport class — a single nibble in the Forward_Open Transport Class Trigger byte that decides how the connection behaves. Class 0, Class 1, Class 2, Class 3 — engineers see these terms in Studio 5000, in Wireshark captures, in product documentation — but rarely with a clear explanation of what each one actually does or when to use it.
This article fixes that. It explains every CIP transport class, the complete Transport Class Trigger byte, the production triggers that go with it, and the practical differences engineers need to make sense of real-world EtherNet/IP installations.
Built from ODVA Volume 1 Section 3-4 and Volume 2 Section 3-2. For broader CIP context, see the CIP Protocol Complete Guide and the CIP Forward_Open Service Explained article.
What CIP transport classes are in one paragraph
CIP transport classes are a small enumeration (0 through 6) that define how a connection’s data exchange behaves — whether it’s unidirectional or bidirectional, whether it uses sequence numbers, and how the producer and consumer relate. The class is one of three fields in the Transport Class Trigger byte sent in every Forward_Open request, along with the Direction (Client/Server) and Production Trigger (Cyclic/Change-of-State/Application Object). Class 0 and Class 1 are unidirectional cyclic I/O (used over UDP for EtherNet/IP). Class 2 and Class 3 are bidirectional acknowledged transports (used over TCP for connected explicit messaging). Classes 4, 5, and 6 exist in the spec but are reserved for non-EtherNet/IP transports.
The Transport Class Trigger byte
The Transport Class Trigger field is a single BYTE that appears in every Forward_Open request and is also stored as Attribute 3 of the Connection Object. Per Volume 1 Figure 3-4.2, the 8 bits are divided into three fields:
| Bits | Field | Values |
|---|---|---|
| 7 | Direction | 0 = Client, 1 = Server |
| 6-4 | Production Trigger | 0 = Cyclic, 1 = Change-of-State, 2 = Application Object Triggered, 3-7 = Reserved |
| 3-0 | Transport Class | 0, 1, 2, 3, 4, 5, 6 = Transport class number. F = Reserved |
So a Transport Class Trigger byte value of 0x01 decodes as:
- Direction bit (7) = 0 → Client
- Production Trigger (bits 6-4) = 000 → Cyclic
- Transport Class (bits 3-0) = 0001 → Class 1
That single byte (0x01) configures a “Client, Cyclic, Class 1” connection — the most common configuration for typical EtherNet/IP unicast I/O.
A few more decoded examples:
| Byte value | Decoded meaning |
|---|---|
| 0x00 | Client, Cyclic, Class 0 (multicast producer) |
| 0x01 | Client, Cyclic, Class 1 (unicast I/O) |
| 0x03 | Client, Cyclic, Class 3 (connected explicit messaging) |
| 0x10 | Client, Change-of-State, Class 0 |
| 0x11 | Client, Change-of-State, Class 1 |
| 0x20 | Client, Application Object Triggered, Class 0 |
| 0x83 | Server, X (ignored), Class 3 |
| 0x82 | Server, X (ignored), Class 2 |
When you see these bytes in a Wireshark capture, you can decode them on the spot.
The Direction bit — Client vs Server
Per Volume 1 Table 3-4.12:
| Value | Role | Behavior |
|---|---|---|
| 0 | Client | Initiates the production. The Production Trigger bits define when the Client produces. Client connections with Cyclic or Change-of-State triggers produce immediately after transitioning to Established. |
| 1 | Server | Reacts to transmissions from the Client. The Production Trigger bits are IGNORED for Server endpoints. The only way a Server produces is in response to a Client’s production (and only for Class 2/3, which are bidirectional). |
For a typical PLC-to-I/O-block connection:
- The PLC’s outgoing direction (sending outputs to the I/O block) is Client
- The I/O block’s outgoing direction (sending inputs back to PLC) is also Client (it produces on its own schedule)
Note: in EtherNet/IP, a single Forward_Open sets up both directions of an I/O connection, and each direction has its own Transport Class Trigger. The two ends of the connection do NOT use the same Direction bit value — that would mean both produce or both consume.
The Production Trigger bits — when the Client produces
The Production Trigger is only meaningful when Direction = 0 (Client). It defines what causes the producer to send a packet:
| Value | Trigger | When the Client produces |
|---|---|---|
| 0 | Cyclic | When the Transmission Trigger Timer expires (every RPI) |
| 1 | Change-of-State | When the Application Object detects a change. The consumer may still expect periodic packets via expected_packet_rate to maintain the connection. |
| 2 | Application Object Triggered | The Application Object explicitly decides when to produce |
| 3-7 | Reserved | (Not used) |
Cyclic (most common)
Cyclic production sends a packet every RPI regardless of whether data has changed. This is the workhorse for industrial I/O — predictable timing, easy to analyze, fits the way PLCs scan.
For a 10 ms RPI, the producer sends a packet every 10 ms. Period. Whether anything changed or not. The consumer expects packets on this schedule and declares the connection dead if they stop arriving.
Change-of-State
Change-of-State production sends a packet only when the application detects a meaningful change. Useful for devices with mostly-static data — pushbuttons, infrequent alarms, configuration values that change rarely.
But there’s a subtlety: even change-of-state connections typically send a packet at the expected_packet_rate as a heartbeat, regardless of whether anything changed. Without this heartbeat, the consumer would declare the connection dead during long stretches of no changes. Change-of-State is really “send on change OR at the heartbeat interval, whichever comes first.”
Application Object Triggered
The Application Object explicitly schedules productions. Used in specialized cases where neither cyclic nor change-of-state semantics fit — synchronized motion, application-driven sampling, etc.
Most field devices use Cyclic. Some use Change-of-State for low-traffic devices. Application Object Triggered is rare.
The four transport classes engineers actually see
Per Volume 1 Table 3-4.14:
| Class | Direction model | Acknowledged? | Sequence count? | Typical use |
|---|---|---|---|---|
| 0 | Unidirectional (Client OR Server) | No | No | Multicast I/O production |
| 1 | Unidirectional (Client OR Server) | No | Yes (16-bit) | Unicast cyclic I/O |
| 2 | Bidirectional (Client AND Server) | Yes (positive acknowledge) | Yes (16-bit) | Connected explicit messaging |
| 3 | Bidirectional (Client AND Server) | Yes | Yes (16-bit) | Long-lived explicit messaging sessions |
| 4 | Non-blocking | n/a | n/a | Reserved, not used with EtherNet/IP |
| 5 | Non-blocking, fragmenting | n/a | n/a | Reserved, not used with EtherNet/IP |
| 6 | Multicast, fragmenting | n/a | n/a | Reserved, not used with EtherNet/IP |
Per Volume 2 Section 3-2.4: “The encapsulation protocol described in chapter 2 shall not be used to encapsulate CIP transport classes 4, 5 and 6.” So Classes 4, 5, and 6 are theoretical for EtherNet/IP. Real-world EtherNet/IP traffic uses only Classes 0, 1, 2, and 3.
Let’s walk through each one in depth.
Class 0 — fire and forget
Class 0 is unidirectional with no application-layer sequence number. The Client end of a Class 0 connection is a pure producer — it sends data and that’s it, no acknowledgment required. The Server end is a pure consumer — it accepts whatever the producer sends.
Spec behavior (Volume 1 Section 3-4.4.3.1):
“Based on the value within the Dir bit, this connection end-point will be a producing only OR consuming only end-point. Upon application of this Connection instance, the module instantiates either a Link Producer (Dir bit = Client) or a Link Consumer (Dir bit = Server).”
Key properties:
- No CIP transport sequence number in the payload — Class 0 has no application-layer mechanism to detect duplicates or gaps
- One direction only per connection instance — to get bidirectional flow, you need TWO Class 0 connections (one each way)
- No acknowledgment — producer just sends, consumer just receives
Typical use in EtherNet/IP: Multicast input production from a target device to multiple consumers. A drive produces its position feedback as Class 0 multicast; multiple PLCs subscribe and receive the same data. None of the PLCs need to acknowledge — the drive’s job is just to produce.
Wire-level form: UDP packets on port 2222 with the Sequenced Address Item (Type ID 0x8002) carrying a wire-level Connection ID + Sequence Number. The wire-level sequence number is still there (it’s part of the EtherNet/IP encapsulation, not the CIP transport class). The class-specific behavior is that the CIP transport packet itself has no sequence count header.
See our EtherNet/IP I/O Messaging on UDP Port 2222 Explained article for how Class 0 packets look on the wire.
Class 1 — sequenced unicast I/O
Class 1 is also unidirectional like Class 0 — one Client (producer) and one Server (consumer) per connection. But Class 1 prepends a 16-bit sequence count to every CIP transport packet.
Spec behavior (Volume 1 Section 3-4.4.3):
“A 16-bit sequence count value is prepended to all Class 1, 2, and 3 transports. This value is used to detect delivery of duplicate data packets. Sequence count values are initialized on the first message production and incremented on each subsequent new data production. A resend of old data shall not cause the sequence count to change, and a consumer shall ignore data when it is received with a duplicate sequence count.”
The sequence count lets the consumer:
- Detect duplicate packets (same sequence count = same data, ignore the duplicate)
- Distinguish “fresh” data from “kept-alive” data
Key properties:
- Sequence count in CIP transport header (16-bit, separate from the 32-bit wire-level sequence number)
- One direction per connection like Class 0
- No explicit acknowledgment — but consumer detects duplicates via sequence count
- Used over UDP in EtherNet/IP (port 2222)
Typical use in EtherNet/IP: Standard unicast I/O. A PLC sends Class 1 to its Point I/O block (outputs); the Point I/O block sends Class 1 back to the PLC (inputs). Each direction is its own Class 1 connection.
Why Class 1 over Class 0: the sequence count detects duplicate data. If the producer sends a packet, the consumer receives it, then the producer’s network buffer retransmits and the consumer receives it again — the second arrival has the same sequence count, so the consumer recognizes it as a duplicate and discards it. Class 0 has no such mechanism.
This is the most common transport class in EtherNet/IP. Almost every PLC-to-remote-drop I/O connection uses Class 1.
Class 2 — bidirectional acknowledged
Class 2 is bidirectional — a single Class 2 connection has both a Client and a Server endpoint, with both producing and consuming.
Spec behavior (Volume 1 Section 3-4.4.3.2):
“Indicates that the module will both produce AND consume across this connection. The Client end-point generates the first data production that is consumed by the Server, which causes the Server to return a production that is consumed by the Client.”
Class 2 is the request/response transport with positive acknowledgment. The Client sends a packet; the Server’s consumption causes it to produce a reply; the Client consumes the reply. Each direction is acknowledged by the next direction’s production.
Key properties:
- Bidirectional — both directions in one connection
- Acknowledged via reply production — Server’s production is the ack
- Sequence count in CIP transport header
- Used over TCP in EtherNet/IP (per Volume 2 Section 3-2.3)
Typical use in EtherNet/IP: Connected explicit messaging where guaranteed delivery and ordered acknowledgment matter. Less common than Class 3 in practice — most engineering tools use Class 3 instead for long-lived explicit sessions.
Class 3 — bidirectional with strict acknowledgment
Class 3 is similar to Class 2 — also bidirectional with acknowledged transport — but with stricter sequencing behavior. The spec’s behavior diagrams (Volume 1 Section 3-4.4.3.3 and Figure 3-4.5) show that Class 3’s reaction to consumption strictly follows the bidirectional acknowledged pattern.
Key properties:
- Bidirectional — Client request, Server reply
- Strictly acknowledged via reply production
- Sequence count in CIP transport header
- Used over TCP in EtherNet/IP
Typical use in EtherNet/IP: Long-lived connected explicit messaging sessions. When a configuration tool needs to perform many explicit transactions to a device, opening a Class 3 connection (via Forward_Open) and reusing it is more efficient than sending many UCMM-encapsulated explicit messages.
Rockwell’s MSG instruction in ladder logic, when configured for “Connected” messaging, uses a Class 3 connection underneath. The connection is opened once and reused for hundreds of message transactions, dramatically reducing per-message overhead.
Transport class comparison at a glance
| Property | Class 0 | Class 1 | Class 2 | Class 3 |
|---|---|---|---|---|
| Direction model | One-way | One-way | Two-way | Two-way |
| CIP transport sequence count | No | Yes (16-bit) | Yes (16-bit) | Yes (16-bit) |
| Acknowledgment | None | None | Implicit (via reply) | Implicit (via reply) |
| Duplicate detection at app layer | No | Yes (via seq count) | Yes (via seq count) | Yes (via seq count) |
| EtherNet/IP transport | UDP port 2222 | UDP port 2222 | TCP port 44818 | TCP port 44818 |
| Typical pattern | Multicast input production | Unicast cyclic I/O | Connected explicit (rare) | Connected explicit (common) |
| Number of connections for full bidirectional I/O | 2 (one each way) | 2 (one each way) | 1 | 1 |
Why Class 0/1 use UDP and Class 2/3 use TCP
The choice maps to the use case:
Classes 0 and 1 — cyclic I/O over UDP:
- I/O traffic is predictable and continuous
- Losing a single packet is acceptable (the next cyclic packet has fresh data)
- TCP overhead (handshake, retransmission, congestion control) would destroy real-time timing
- UDP gives the CIP transport layer full control over packet pacing
Classes 2 and 3 — explicit messaging over TCP:
- Explicit messages are discrete request/response transactions
- Losing a packet means losing a transaction — must retry
- TCP provides reliable delivery, ordering, and retry mechanics for free
- Slower than UDP but appropriate for non-real-time configuration traffic
Per Volume 2 Section 3-2.3: “CIP transport class 2 and class 3 connections shall be transmitted over a TCP connection using the encapsulation protocol defined in chapter 2.” This is mandatory for EtherNet/IP.
How the Transport Class Trigger appears in Forward_Open
When you look at a Forward_Open request in Wireshark, the Transport Class Trigger is one of the parameters in the Forward_Open body. Wireshark decodes it into named subfields:
Forward_Open Request
Priority/Time_tick: 0x07
Time-out_ticks: 201
O→T Connection ID: ...
T→O Connection ID: ...
Connection Serial Number: ...
Originator Vendor ID: 1
Originator Serial Number: ...
Connection Timeout Multiplier: ×16
...
O→T RPI: 10,000 µs
O→T Network Connection Parameters: ...
T→O RPI: 10,000 µs
T→O Network Connection Parameters: ...
Transport Class Trigger: 0x01
Direction: 0 (Client)
Production Trigger: 0 (Cyclic)
Transport Class: 1 (Class 1)
Connection Path Size: ...
Connection Path: ...A successful Forward_Open response then sets up the connection with the negotiated class. For a Class 0 or Class 1 connection, cyclic UDP packets start flowing on port 2222. For a Class 2 or Class 3 connection, the next CIP messages flow as connected explicit messages over the original TCP session via SendUnitData.
For full Forward_Open mechanics, see our CIP Forward_Open Service Explained article.
Common real-world configurations
The Transport Class Trigger byte combined with the connection’s purpose:
Point I/O block — exclusive owner connection:
- PLC → I/O block direction: TransportClass_trigger = 0x01 (Client, Cyclic, Class 1)
- I/O block → PLC direction: TransportClass_trigger = 0x01 (Client, Cyclic, Class 1)
- Both directions are Class 1 cyclic unicast
AC drive — speed feedback as multicast:
- PLC → drive (commands): 0x01 (Client, Cyclic, Class 1, unicast)
- Drive → PLCs (feedback): 0x00 (Client, Cyclic, Class 0, multicast)
- Output direction is Class 1; feedback direction is Class 0 because multiple PLCs may consume it
Listen-only connection from a secondary PLC:
- Secondary PLC subscribes to existing multicast: 0x00 (Class 0)
- No output direction (listen-only doesn’t send anything)
MSG instruction with Connected Messaging in Studio 5000:
- Forward_Open with TransportClass_trigger = 0x03 (Client, Cyclic, Class 3)
- The Class 3 connection then carries multiple SendUnitData messages over TCP
Sequence count vs wire-level sequence number — two different things
This is a common source of confusion:
| Sequence number | Layer | Size | Used by |
|---|---|---|---|
| Wire-level Sequence Number | EtherNet/IP encapsulation (Sequenced Address Item) | 32-bit | Class 0 and Class 1 over UDP |
| CIP Transport Sequence Count | CIP transport layer | 16-bit | Class 1, 2, and 3 |
Both are sequence numbers but they live at different layers. The wire-level Sequence Number (in the 0x8002 Sequenced Address Item) is part of EtherNet/IP framing and exists on every UDP I/O packet regardless of class. The CIP Transport Sequence Count is part of the CIP transport layer and exists only for Classes 1, 2, and 3 — Class 0 doesn’t have it.
A Class 1 UDP packet thus has TWO sequence numbers: a 32-bit wire-level one in the EtherNet/IP header and a 16-bit application-layer one in the CIP transport packet. A Class 0 UDP packet has only the wire-level 32-bit one.
For the wire-level mechanics, see our EtherNet/IP I/O Messaging on UDP Port 2222 Explained article.
Reading transport classes in Wireshark
Useful filters:
cip # All CIP traffic
cip.cm.transport_class == 0 # Class 0 only
cip.cm.transport_class == 1 # Class 1 only
cip.cm.transport_class == 2 # Class 2 only
cip.cm.transport_class == 3 # Class 3 only
cip.cm.transport_class != 1 # Anything other than Class 1
udp.port == 2222 # Class 0 and Class 1 I/O traffic
enip.command == 0x0070 # SendUnitData (Class 2/3 messaging over TCP)Wireshark’s CIP dissector parses the Transport Class Trigger byte into its constituent fields automatically when displayed under the Forward_Open request. Expand the Forward_Open in the packet detail to see Direction, Production Trigger, and Transport Class as labeled sub-fields.
For broader Wireshark workflows, see our Wireshark for EtherNet/IP guide.
Common transport-class-related errors
| Symptom | Likely cause | What to check |
|---|---|---|
| Forward_Open Extended Status 0x0103 | Transport class and trigger combination not supported by this device | Check device’s EDS [Connection Manager] section for supported combinations |
| Class 0 connection works, Class 1 fails | Device doesn’t support sequenced transport | Check Connection Manager attribute for supported classes |
| Class 3 explicit messaging slow | Each MSG instruction opens a fresh connection | Configure MSG for “Connected” to reuse a Class 3 connection |
| Listen-only connection rejected | Wrong transport class for listen-only role | Listen-only must be Class 0 multicast subscribe |
| Multicast traffic floods network | Class 0 multicast without IGMP snooping | Enable IGMP snooping on switches |
| Sequence count mismatch errors | Custom code mishandling 16-bit sequence rollover | Use modular arithmetic per spec |
For full Forward_Open error codes, see our CIP General Status Codes Reference, particularly the Extended Status section.
Frequently asked questions
What are CIP transport classes?
CIP transport classes are an enumeration (0-6) that define how a connection’s data exchange behaves — whether unidirectional or bidirectional, whether it uses acknowledgments, and whether sequence counts are required. The transport class is set during Forward_Open via the Transport Class Trigger byte. In EtherNet/IP, only Classes 0, 1, 2, and 3 are used; Classes 4, 5, and 6 are reserved for other transports.
What is the difference between CIP Class 0 and Class 1?
Class 0 has no CIP transport sequence number — it’s pure fire-and-forget production. Class 1 prepends a 16-bit sequence count to every packet, letting the consumer detect duplicate data. Both are unidirectional (Client OR Server endpoint) and both use UDP port 2222 in EtherNet/IP. Class 1 is the workhorse for typical unicast I/O; Class 0 is common for multicast input production from devices that share data with multiple consumers.
What is CIP transport Class 3 used for?
Class 3 is a bidirectional acknowledged transport used for connected explicit messaging. It carries CIP requests and replies over TCP (port 44818 in EtherNet/IP). The most common use is long-lived configuration sessions — Studio 5000’s MSG instructions configured for “Connected” messaging use Class 3 to open a persistent connection that can carry many transactions without per-message overhead.
What’s the difference between Class 0/1 and Class 2/3?
Classes 0 and 1 are unidirectional and use UDP — they’re for cyclic I/O where occasional packet loss is acceptable. Classes 2 and 3 are bidirectional acknowledged transports over TCP — they’re for explicit messaging where reliable delivery and ordering matter. The Direction bit in the Transport Class Trigger byte tells each endpoint whether to act as Client (producer) or Server (consumer). For Class 2/3, the Server’s reply production acts as the acknowledgment.
What is the Transport Class Trigger byte?
The Transport Class Trigger byte is a single BYTE in every Forward_Open request that encodes three fields: Direction (bit 7: 0=Client, 1=Server), Production Trigger (bits 6-4: 0=Cyclic, 1=Change-of-State, 2=Application Object), and Transport Class (bits 3-0: 0-6). For example, 0x01 means “Client, Cyclic, Class 1” — the most common configuration for unicast cyclic I/O.
What is the difference between Cyclic and Change-of-State production?
Cyclic production sends a packet every RPI regardless of whether data changed — predictable, easy to analyze, fits PLC scan models. Change-of-State production sends a packet only when the application detects a meaningful change, with a heartbeat at the expected_packet_rate to keep the connection alive. Cyclic is the workhorse for I/O; Change-of-State suits low-traffic devices where most data is static.
Why does EtherNet/IP not use transport Classes 4, 5, and 6?
Per Volume 2 Section 3-2.4: “The encapsulation protocol described in chapter 2 shall not be used to encapsulate CIP transport classes 4, 5 and 6.” These classes are reserved in the CIP spec for non-blocking and fragmenting transports that don’t fit the EtherNet/IP model. They exist for other CIP networks or future use but are not part of EtherNet/IP transport.
What does Direction = 1 (Server) mean for Production Trigger?
When Direction = 1 (Server), the Production Trigger bits are ignored. A Server endpoint reacts to transmissions from the Client — it does not initiate production based on a trigger. For Class 2/3 (bidirectional), the Server’s production happens automatically in response to the Client’s consumption. For Class 0/1 (unidirectional), a Server endpoint is purely a consumer and never produces.
How is the CIP transport sequence count different from the EtherNet/IP wire-level sequence number?
Two different sequence numbers at two different layers. The wire-level Sequence Number is a 32-bit value in the EtherNet/IP Sequenced Address Item (Type ID 0x8002) — part of UDP packet framing on port 2222. The CIP transport sequence count is a 16-bit value prepended to CIP transport packets for Classes 1, 2, and 3 — part of the CIP application layer. A Class 1 packet has both; a Class 0 packet has only the wire-level one.
What is Forward_Open Extended Status 0x0103?
Extended Status 0x0103 means “Transport class and trigger combination not supported.” The device received a Forward_Open whose Transport Class Trigger byte specified a combination the device doesn’t support. Common causes: device only supports Class 1 but the request asks for Class 0, or device’s Connection Manager rejects the combination of Direction + Trigger + Class. Check the device’s EDS file [Connection Manager] section to see which combinations are valid.
Where can I find the official CIP transport class specification?
The transport classes are defined in ODVA’s CIP Networks Library Volume 1: Common Industrial Protocol (CIP) Specification, Chapter 3 (Communication Object Classes), Section 3-4 (Connection Object). The Transport Class Trigger byte is documented in Section 3-4.4.3, and the behavior of each class with each Direction/Trigger combination is shown in Sections 3-4.4.3.1 through 3-4.4.3.9. Volume 2 Section 3-2 documents the EtherNet/IP-specific transport choices (Class 0/1 over UDP, Class 2/3 over TCP).
Can I use the same transport class for both directions of an I/O connection?
Yes, and it’s the most common case. A typical PLC-to-I/O-block exclusive owner connection uses Class 1 for both directions: O→T direction is Class 1 unicast (PLC sends outputs), T→O direction is Class 1 unicast (I/O block sends inputs). Each direction is its own logical connection with its own Connection ID, but both use Class 1. Mixing classes is also valid — for example, Class 1 for outputs and Class 0 multicast for inputs (so multiple PLCs can listen to the same input data).