The Integration of Time-Sensitive Networking into
EtherNet/IP™ Technologies
Mark Hantel
Architect and Senior Project Engineer
Rockwell Automation
Jordon Woods
Strategic Technologist
Analog Devices, Inc.
Presented at the ODVA
2022 Industry Conference & 21st Annual Meeting
March 9, 2022
San Diego, California, USA
Abstract
Time-sensitive networking (TSN) technologies represent a potentially disruptive force in the automationindustry. TSN impacts basic layer 2 networking and network management by providing standardized
approaches for deterministic network performance. To address this trend, ODVA’s TRB has established acommittee comprised of industry experts familiar with TSN. This paper will share some of the committee’sfindings to date including, the motivation for adopting TSN technologies, the application of TSN to various
industrial use cases, the impact of TSN on bridges and end stations, the mapping of CIP connections to
TSN streams and the application of TSN to existing CIP technologies including CIP Sync™, CIP
Motion™, and DLR.
Keywords
TSN, Time-Sensitive Networking, CIP™, EtherNet/IP. Time Synchronization, Scheduled Traffic, QoS.
Definition of terms (optional)
Term
Bridge (From IEEE 802.1Q-2018
3.23)

Definition
A multiple-port Device that includes Media AccessControl (MAC) Bridge or Virtual Local Area Network(VLAN) Bridge component functionality and that
supports a claim of conformance to Clause 5 of IEEE
Std 802.1Q-2018 for system behavior.
A multiple-port Device that includes both Bridge
features and End Station features. These are twofunctional elements according to IEEE 802.1 andIEC/IEEE 60802.

Bridging/Bridged End Station

2022 ODVA Industry Conference

1©2022 ODVA, Inc.

Term
End Station

Definition
A functional unit in an IEEE 802 network that acts asa source of, and/or destination for, link layer data
traffic carried on the network.
A device with two or more Ethernet based ports
accessible by the user.
A device with only one Ethernet based port
accessible by the user
Synchronized time in a network clock derived from agPTP domain that is traceable to an ARB timescaleor to the PTP timescale.

Multiple-Port (or Multi-Port) Device
Single-Port Device
Working ClockIntroduction
TSN is an abbreviation for Time Sensitive Networking. TSN is a collection of techniques that run on
Ethernet networks which ensure critical packets are delivered when and where they are expected.
The promise of TSN is to provide more predictable network performance, with higher utilization, whileallowing multiple time-critical applications with different priorities guaranteed network access.
Three basic techniques embody Time Sensitive Networking:•••Time Synchronization: All devices that participate in TSN communication have a common
understanding of time. IEEE Std. 802.1AS-2020 is the time protocol that anchors TSN.
Scheduling and Traffic Shaping: All devices that participate in real-time (TSN) communication
adhere to the same rules in processing and forwarding communication packets.
Selection of communication paths, path reservations and fault tolerance: All devices thatparticipate in real-time (TSN) communications adhere to the same rules in selecting
communication paths, reserving bandwidth and time slots, possibly utilizing more than one
communication path to ensure fault tolerance.

Each technique can be used on its own and is mostly self-sufficient. When used together TSN is
expected to reach its full potential as a communications system.
While the above are techniques to create a time sensitive network, the ability to share network
configuration with a Centralized Network Controller and other centralized configuration entities provides
the language to configure the communications between devices in a common manner. This sharedcommunications configuration is novel for a converged ecosystem of industrial fieldbuses.
EtherNet/IP, the dominant industrial Ethernet variant today, may need to embrace TSN to ensure that its
core values can continue to be delivered in customer networks. This document provides guidance on theimpact of TSN in EtherNet/IP networks while also identifying opportunities for EtherNet/IP to deliver
greater value when used with TSN. Finally, we draw the reader’s attention to the joint IEEE/IEC project,
IEC/IEEE 60802. This standard defines time-sensitive networking profiles for industrial automation. The
profiles select features, options, configurations, defaults, protocols, and procedures of bridges, end
stations, and LANs to build industrial automation networks.
Scope of The Document
This document presents a recommended high-level approach for incorporating TSN capability into
EtherNet/IP. The purpose of the document is to identify the major technical aspects and decision points
for EtherNet/IP with respect to TSN and should be considered as input to the specification development
process.
2022 ODVA Industry Conference2©2022 ODVA, Inc.

CIP Architecture with TSN
TSN as defined by IEC/IEEE 60802 will be introduced in ODVA technologies as an optional andbackwards compatible Data Link Layer for the EtherNet/IP implementation of CIP.

Figure 1 – Where TSN fits in the overall CIP architecture

Role of IEC/IEEE 60802
IEC/IEEE 60802 is a joint project of IEC SC65C/WG9 and IEEE 802.1 to define TSN profiles for industrial
automation. This joint work will provide a jointly developed standard that is both an IEC and an IEEE
standard, i.e., a dual logo standard.
This standard defines time-sensitive networking profiles for industrial automation. The profiles selectfeatures, options, configurations, defaults, protocols, and procedures of bridges, end stations, and LANs
to build industrial automation networks.
IEEE 802.1 Time-Sensitive Networking (TSN) gives an opportunity for multiple industrial ethernet variants
to coexist on a single LAN in a user facility. TSN is the foundation to extend the interoperability andconnectivity offered by traditional ethernet in industrial applications on converged networks tosimultaneously support operations technology traffic and other traffic. However, the breadth of choices in
the use of the TSN features puts at risk the interoperability of products designed for a particular market.
The specification of the use of TSN features in industrial networking scenarios via TSN profiles isbeneficial for vendors offering and/or developing TSN products as well as for the users of industrial
automation technologies.
2022 ODVA Industry Conference

3©2022 ODVA, Inc.

Applications of TSN for the Industrial Space
Four TSN network access models that can coexist with each-other are currently under discussion in
IEC/IEEE 60802. These include:
1. Free Running Network: An application that may be synchronized to a working clock with bridges
that do not implement scheduling. A Centralized Network Controller (CNC) is used for
configuration and worst-case latency simulation (the longest transmission time between senderand receiver). Traffic is sent via TSN streams. Preemption may be implemented.
2. End Station Scheduling: An application that is synchronized to the working clock, andschedules its’ transmissions based on direction from the CNC. Bridges are free running. Traffic issent via TSN streams. Preemption may be implemented.
3. Network Scheduling – Class Based: An application that is synchronized to the working clock
and schedules each of its traffic classes transmissions based on direction from the CNC. Bridges
implement 802.1Qbv scheduling in a class-based manner. Traffic is sent via TSN streams.
Preemption may be implemented.
4. Network Scheduling – Stream Based: An application that is synchronized to the working clock
and schedules individual stream transmissions based on direction from the CNC. Bridges
implement 802.1Qbv scheduling in a stream-class based manner. Traffic is sent via TSN
streams. Preemption may be implemented.
At the present time it is unknown which models may survive into the published IEC/IEEE 60802
specification. We should assume that EtherNet/IP specifications will need to enable use of all of thesurviving models.

Assumptions on what IEC/IEEE 60802 will deliver
1. The profile will allow time sensitive traffic from multiple industrial fieldbuses to fairly coexist on asingle converged network.
2. Multiple TSN domains may be implemented in a converged network with different TSN
capabilities required to meet the needs of different applications.
3. A bridge and an end station are two separate functions that may be in a single box. For the
purposes of IEC/IEEE 60802, a bridged end station is a specific type of bridge with a single
management entity that includes end station functionality.
4. Bridges will be VLAN aware.
a. EtherNet/IP defines VLAN awareness as an option today.
5. IEEE 802.1AS-2020 will be the time sync protocol.
a. EtherNet/IP has standardized on the IEEE 1588 default profile today.
6. There will be at least two conformance classes for end stations, and at least one for bridges.
a. Specific conformance testing will be defined for IEC/IEEE 60802 mandated
functionalities.
7. There will be a bridge conformance class where IEEE 802.1Qbv is mandatory.
a. This adds new silicon and software requirements to bridges.
2022 ODVA Industry Conference

4©2022 ODVA, Inc.

8. There will be an end station conformance class where IEEE 802.1Qbv is optional, and one where
it is mandatory.
a. This potentially adds new silicon and software requirements to end stations.
9. NETCONF with YANG will be the default network configuration protocol.
a. NETCONF adds software complexity to every bridge.
10. Preemption will be mandatory (for certain data rates) for one conformance class, it will be optional
for another conformance class.
a. This requirement potentially adds new silicon requirements to devices.
11. LLDP will be mandatory.
a. LLDP has recently been added to EtherNet/IP Standards.
12. There will be a conformance class where at least 4 queues are mandatory for end stations. There
will be a conformance class where 8 queues will be mandatory. Still under discussion.
a. This adds silicon complexity to devices.
13. There will not be a strict mapping of traffic types to queues.
14. A centralized management entity will be mandatory; however stream reservations may be either
centralized or distributed.
ODVA should not publish TSN extensions to the EtherNet/IP specifications until IEC/IEEE 60802 hasbeen published and the Market Advisory Council has validated the consequences on existing
EtherNet/IP installations of the final specification.

Outcomes of EtherNet/IP TSN Extensions
If ODVA adopts TSN as part of the EtherNet/IP specification, then it must ensure the following outcomes:••

Commercial parity with other industrial protocols that are defining TSN usage and adoption sothat EtherNet/IP implementations do not suffer a competitive disadvantage against otherindustrial ethernet implementations.
Enable convergence with other applications and protocols that adopt TSN for a common layer 2
enabling EtherNet/IP to receive equitable quality of service considerations.

High Level Requirements for EtherNet/IP
The TSN data link layer for EtherNet/IP will be built on industry standards including IEEE 802.1Q-2018
with amendments, IEEE 802.1CB and IEC/IEEE 60802.
TSN should be an optionally applied new Application Profile for EtherNet/IP as defined in Volume 2 of theCommon Industrial Protocol. A device implementing the new Application Profile must be backwards
compatible with existing EtherNet/IP implementations. EtherNet/IP implementing systems and theirdevices may choose to natively implement the TSN Application Profile or use one or multiple gateways toenable converged communication over a TSN network. Both native implementations and implementations
through (a) gateway(s) must provide and allow equitable network level access with other IEC/IEEE
60802-compliant devices.

2022 ODVA Industry Conference

5©2022 ODVA, Inc.

Existing EtherNet/IP devices may work with TSN networks without change, recognizing their relative
Quality of Service on the wire will be degraded when compared to a non-TSN network unless network
management reserves bandwidth explicitly for them. The ability to converge non-TSN EtherNet/IP devices
on a TSN network must be maintained.

EtherNet/IP
Originator

EtherNet/IP
Originator

TSN Network

EtherNet/IP Target

TSN Gateway(s)TSN Network

TSN Gateway(s)EtherNet/IP w/ TSN
Originator

TSN Network

EtherNet/IP w/ TSN
TargetEtherNet/IP Target

Figure 2 - EtherNet/IP Requirements
TSN must not change existing EtherNet/IP user workflows, however it is recognized that TSN introduces
an additional layer of complexity that needs to be added to current user workflows. Complexity visible toan end user should be minimized where possible, and plainly explained where it must be visible.
Use Cases
The layered design of EtherNet/IP makes it possible to use TSN features. EtherNet/IP will use IEEE 802
LANs with TSN features and infrastructure to provide functionality needed for industrial automation
applications, such as control, IO exchange, diagnostics, and monitoring.
EtherNet/IP provides a foundation for the main building blocks of Smart factories. As explained in “Use
Cases IEC/IEEE 60802”, Examples of these building blocks are:
1. PLCs/PACs: EtherNet/IP based PLC devices can function as an Adapter or Scanner (master),
responsible for exchanging IO with devices (sensors or drives). PLCs could also perform thefunction of an adapter for diagnostics when attached to a SCADA.
2. I/O Devices (Sensors, Actuators, etc.), and Drives: EtherNet/IP based I/O will run as an Adapter
exchanging data on an isochronous, cyclic or sporadic basis with the PLC
3. EtherNet/IP can also act as a gateway for other fieldbus protocols such as Modbus.
4. HMI as an EtherNet/IP scanner.
In the following subsections, some of the use cases will be explored and existing features in EtherNet/IP
will be highlighted to satisfy these use cases. In addition, features which need to be explored or added to
EtherNet/IP will be called out to allow EtherNet/IP to take full advantage of TSN. The use cases are notmeant to be exhaustive; the objective is merely to initiate the investigation of features needed to fully
support the use cases.

2022 ODVA Industry Conference

6©2022 ODVA, Inc.

Isochronous Control Loops with guaranteed low latency:
EtherNet/IP should support all IEC/IEEE 60802 conformant isochronous control loop models. Currently
isochronous control loops can be TSN prioritized using synchronized network access, class-basedscheduling and stream-class based scheduling. EtherNet/IP specifications for CIP Motion should define
operation of CIP Motion for each TSN prioritization mechanism.
Cyclic Control Loops with bounded latency
EtherNet/IP will provide IO communication using implicit messaging with production triggers set to cyclic.
EtherNet/IP should support all IEC/IEEE 60802 conformant cyclic control loop models. Currently cyclic
control loops can be TSN prioritized using synchronized network access, class-based scheduling andstream-class based scheduling. Each TSN prioritization mechanism enabled by 60802 should be detailedin EtherNet/IP specifications.
Sequence of Events
Record time stamped events for the whole plant with known maximum deviation to the grandmaster timein the range from 1 μs to 100 μs (Source: IEC/IEEE 60802 use cases).
Existing features of EtherNet/IP such as implicit messaging can be used. Careful consideration should begiven to explore the overlap of CIP Sync and EtherNet/IP over TSN. Analysis of what can be reused andacquired from CIP Sync should be done. Creating new EtherNet/IP APIs (objects and features) andutilizing existing APIs to obtain the current time from 802.1AS should be considered. QoS parameters
should be used to be sure that these events are transmitted at the required urgency.
It is expected that when 802.1AS support is added to EtherNet/IP, Sequence of Events applications
should work on a TSN Network. It is further anticipated that while this traffic can coexist with preemptive
and scheduled traffic, SoE application traffic should be at a lower priority relative to preemptive andscheduled traffic. Therefore, once mechanisms are provided to transmit EtherNet/IP traffic via TSN
streams, SoE application traffic should be examined and mapped onto a TSN stream with appropriate
overall priority.
Machine to Machine/Controller to Controller (M2M/C2C) Communication:
This use case uses CIP Explicit messaging (Class 3 or unconnected) or CIP Implicit Messaging (Class0/1) mechanisms for communication. Once mechanisms are provided to transmit EtherNet/IP traffic via
TSN streams, CIP Explicit Messaging and CIP Implicit Messaging will need to be prioritized appropriately
for the M2M/C2C use case.
A particular consideration for M2M communication is TSN interdomain communication. If two TSN
domains have different management mechanisms, either compatible prioritization mechanisms must be
selected, or translation functions need to be defined at the edge. TSN interdomain communication is still
the subject of frequent discussions in the IEEE/IEC 60802 working group and it may not be covered in thefirst edition of IEC/IEEE 60802. As of now these communications can only be considered as boundary
requirements to the CNCs of the respective interacting domains. (See “High-Level Approach of TSN In
EtherNet/IP” on Page 9 for more detail on the TSN Domain concept)
Security
EtherNet/IP security support should be explored for both configuration plane and data plane. As
explained in CIP Volume 8, there should be optional support for confidentiality, integrity, availability andauthenticity. The NETCONF protocol uses SSH/TLS for transport security and is a reasonable solution for
network control plane security. CIP Security™ is anticipated to layer on top of TSN for application data
security with no additional work needed. It should be noted that time sync is not secured and is a gap. It is
2022 ODVA Industry Conference

7©2022 ODVA, Inc.

anticipated that direction for control plane security will come from IEC/IEEE 60802. A form of control
plane security must be agreed to and implemented.

Redundancy and High Availability
EtherNet/IP communication provides functionality such as redundant controllers that could be utilized by
the Industrial application to provide redundancy and high availability. Furthermore, network redundancy
can be provided today via DLR, PRP, or HSR for EtherNet/IP Networks. IEC/IEEE 60802 allows thesefeatures and further defines 802.1CB as stream-based redundancy.
Co-Existence with Other Industrial Protocols
Discussions regarding TSN often refer to interoperability. However, interoperability may be achieved on
different levels and in terms of application protocols, it is more appropriate to use the term coexistence.
Figure 3 shows three areas, which need to be covered:-network configuration (managed objects according to IEEE definitions), andstream configuration and establishment, andapplication configuration.

The three areas mutually affect each other (see Figure 3).
Application configuration is not expected to be part of the IEC/IEEE 60802 profile, but common network
management, path establishment and stream configuration methods are vital to the coexistence of
application protocols.
The selections made by the IEC/IEEE 60802 profile covers IEEE 802 defined layer 2 and the selected
protocols to configure layer 2. Applications make use of upper layers as well, but these are out of scope
for the profile.
Stream establishment is initiated by applications to allow data exchange between applications. The
applications are the source of requirements, which shall be fulfilled by network configuration and stream
configuration and establishment.

m
en
t

ts

Co

en

ns
tra

m
re

in

ui

ts

/R

eq

eq

ui

/R
ts

re

in

tra

ns

Application
Model andConfigurationCos

Co-operation (2ndlevel interoperability)

Network
configuration

Constraints/Requirements

Streamconfiguration andestablishment

Co-existence (1stlevel interoperability)
Figure 3 – Principle of interoperation
2022 ODVA Industry Conference

8©2022 ODVA, Inc.

Stated another way, it is not expected that EtherNet/IP devices will communicate directly with devices
running OPC-UA. However, it is a requirement that OPC communications shares the wire with
EtherNet/IP communications.

High-Level Approach of TSN In EtherNet/IP

Figure 4 - Workflow Discussion

The workflow of TSN with EtherNet/IP can start before device acquisition or wiring ever takes place. The
workflow must scale to fit the needs of both machine builders and end integrators. To start, a logicalgrouping of applications for the network scope, otherwise known as things that share significant
infrastructure or need to talk to one another in a time sensitive manner should be developed. This
grouping is placed under the network administration of a single CNC and it is then identified as a TSN
domain. A digital version of the applications running over a TSN domain would be created that could be
as simple as a file such as a Rockwell Automation Logix Designer file of a single application or ascomplex as a full factory floor with input from numerous parties.
Offline TSN Data sheets will be provided by IEC/IEEE 60802 and can serve two functions. First, they canconvey functionality of compliant infrastructure. Second, they can act as a method of conveying
application requirements to a network.
This application level digital twin has the requirement of conveying application requirements to acentralized network controller (CNC) function in terms of number of streams, payload size, frame intervaland jitter tolerance. This data can be conveyed via data sheets if the application programming function(s)and CNC function are in two different pieces of software or devices.
The CNC function will also take as an input the network topology design that is created as a separate
exercise for a network that hasn’t been created yet, or via crawling an existing network with techniquessuch as LLDP. TSN Data sheets for compliant infrastructure will be provided to enumerate TSN
capabilities of offline infrastructure while the User Network Interface (UNI) in the CNC function will gather
TSN capabilities of online infrastructure.
The CNC function will combine the application requirements with the network capabilities and perform
network calculus, scheduling, or both to validate that the TSN domain can meet the requirements of all
applications defined at calculation time. If the network is unable to meet the needs of all applications thecentralized network controller function will prompt the user where issues need to be addressed.
2022 ODVA Industry Conference

9©2022 ODVA, Inc.

Provided a TSN domain passes validation, network configuration will be pushed down from the CNC
function to the infrastructure and end stations through remote management. The infrastructure and end
stations will synchronize to the selected grandmaster clock and provide an indication that they havesynchronized. A user will be able to then run their application(s) at will and the network configuration will
be saved to non-volatile memory of devices. The absence of an online CNC makes the network static.
The online presence of CNC capabilities should not be taken as an implication that changes will be bumpless, unless enough overprovisioning is in place."
Any streams that go out of the TSN domain under consideration will be modeled as an application
requirement TSN data sheet for input to the next TSN domain if directly connected without brownfield
infrastructure in between.

TSN Models and Model Assumptions
Scheduling
Scheduling has been introduced into IEEE 802.1Q through the original amendment known as 802.1Qbv.
This technology adds a gate to the end of each egress port queue on a bridge. The state of this gate iscontrolled by a time-based list known as a gate control list.
The number of gate control lists can be minimized to enable a prioritization mechanism known as classbased scheduling or maximized to enable a prioritization mechanism known as stream-class basedscheduling.
One application of class-based scheduling uses 3 gate control lists, one for isochronous traffic, one forcyclic traffic and one for all other traffic types. A network cycle will be divided up into three parts where
isochronous traffic has unimpeded access to the wire for one part of the cycle, isochronous and cyclictraffic has unimpeded access to the wire for another part of the cycle, and standard QoS prioritized trafficwith all queues open for the final part of the cycle.
One application of stream-class based scheduling uses up to 256 gate control events. A CNC computes
an optimal schedule for traffic transmission and assigns each stream its’ own queue and gate control
events in each bridge. This will allow a known delivery time at each bridge for each stream, and allow
highly engineered traffic to flow seamlessly through a time sensitive network.

2022 ODVA Industry Conference

10©2022 ODVA, Inc.

Figure 5 - Scheduling based on IEEE802.1Qbv
End Station Scheduling

Scheduling can either be applied in a bridge, or in an end station. The application of it in an end station
will allow the wire to be shared fairly through constrained (and prioritized) ingress to a network.
This approach can be applied to an industrial network without scheduling the bridge egress queues. If
the transmission function of each application on a TSN domain can be controlled, the worst-case delays
for each application on that TSN domain can be minimized, and overall bandwidth utilization can beincreased.
Network Management
High level management is outside the scope of the current EtherNet/IP specifications, and this model will
not change with TSN. EtherNet/IP over TSN will require network management to be in place, and will
normatively reference interfaces to network management, while not defining network management.

Requirements for End Stations
End Station: A device attached to a local area network (LAN) or metropolitan area network (MAN), whichacts as a source of, and/or destination for, traffic carried on the LAN or MAN.

2022 ODVA Industry Conference

11©2022 ODVA, Inc.

Figure 6 - The End station

Theory of Operation
From the perspective of the end station, TSN models do not significantly differ. The end station must
implement protocols necessary to communicate requirements with its network management which
include: LLDP and CUC communication.
The end station must be able to provide a specification of its traffic requirements via CIP in terms of traffic
type, period (RPI), payload size, correlated stream requirements and jitter tolerance to the CUC. In return
it will receive a start-of-cycle time, transmission period and offset to adhere to.
An End Station implementation shall conform to the following hardware and operation requirements
specified in IEC/IEEE 60802:
Hardware Requirements
1. An End station shall support the Ethernet Physical Interface (PHY) and Media AccessController (MAC) features.
Hardware Options:
2. An End station may support the Ethernet Physical Interface (PHY) and Media AccessController (MAC) features.
3. An End station may support the Advanced Physical Layer (two-wire) and Power over Data
Lines (PoDL) features.
4. An End station may support the Port-Based Network Access Control features.
5. An End station may Support the End station features.
2022 ODVA Industry Conference

12©2022 ODVA, Inc.

6. An End station may Support the Conformance Class A features.
7. An End station may Support the Conformance Class B features.
8. At least one of 6 or 7 must be selected.
Operation Requirements:
1. An End station shall support the Link Layer Discovery Protocol (LLDP) features.
2. An End station shall support the Time Synchronization features.
Operation Options:3. An End station may support the Link Layer Discovery Protocol (LLDP) features.
4. An End station may support the Time Synchronization features.
5. An End station may support the Layer 2 Network Security features.
6. An End station may Support the End station features.
7. An End station may Support the Conformance Class A features.
8. An End station may Support the Conformance Class B features.
9. At least one of 7 or 8 must be selected.

Requirements for Bridges
Bridge: A multiple-port Device that includes Media Access Control (MAC) Bridge or Virtual Local Area
Network (VLAN) Bridge component functionality and that supports a claim of conformance to the following
selected IEEE 802.1Q specifications.

Figure 7 - The Bridge

2022 ODVA Industry Conference

13©2022 ODVA, Inc.

Theory of Operation:
These models of TSN operation are currently being vetted in the IEC/IEEE 60802 community:
a. Free Running Network
b. Synchronized Network Accessc. Class Based Scheduled Networks
d. Stream-Class Based Scheduled Networks
From the perspective of the bridge, these models differ significantly. If models a & b are selected thebridge does not need to support enhancements for scheduled networks. However, bridges must still
maintain features such as common time, preemption and QoS mechanisms. Bridges must also
implement protocols necessary to communicate capabilities and configuration with its network
management which include: LLDP and CNC communication.
A Bridge implementation shall conform to the following hardware and operation requirements:
Hardware Requirements
1. A Bridge shall support the Ethernet Physical Interface (PHY) and Media Access Controller(MAC) features.
2. A Bridge shall support the VLAN Bridge Component features.
3. A Bridge shall support The Customer VLAN (C-VLAN) Bridge features.
4. A Bridge shall provide the ability to disable Priority Based Flow control, if supported.
Hardware Options:
1. A Bridge may support the Ethernet Physical Interface (PHY) and Media Access Controller(MAC) features.
2. A Bridge may support the Advanced Physical Layer (two-wire) and Power over Data Lines(PoDL) features.
3. A Bridge may support the Port-Based Network Access Control features.
4. A Bridge may Support the Bridge features.
5. A Bridge may Support the Conformance Class A features.
6. A Bridge may Support the Conformance Class B features.
Operation Requirements
1. A Bridge shall support the Link Layer Discovery Protocol (LLDP) features.
2. A Bridge shall support the Time Synchronization features.
Operation Options
1. A Bridge may support the Link Layer Discovery Protocol (LLDP) features.
2. A Bridge may support the Time Synchronization features.
3. A Bridge may support the Layer 2 Network Security features.
4. A Bridge may Support the Bridge features.
5. A Bridge may Support the Conformance Class A features.
6. A Bridge may Support the Conformance Class B features.

Requirements for Bridged End Stations
Bridging/Bridged End Station: A multiple-port Device that includes both Bridge features and End
Station features;
From the ODVA perspective, a bridged end station definition has been left up to the user to implement,with partial conformance statements for things such as DLR. TSN adoption would significantly change
this model. IEC/IEEE 60802 is referencing a bridged end station implementation, and this profile will be
updated to include specifications for it as applicable.
2022 ODVA Industry Conference

14©2022 ODVA, Inc.

Figure 8 - The Bridged End station
Theory of Operation:
A bridged end station is thought of as an IA device with one or more bridge units, and one or more end
station units associated with a bridge. This allows for modeling according to the current 802.1Q
specifications.
A Bridged End station implementation shall conform to the following hardware and operation
requirements:
Hardware Requirements
1. A Bridge shall support the Ethernet Physical Interface (PHY) and Media Access Controller(MAC) features specified in the IEC/IEEE 60802 specification.
2. A Bridge shall support the VLAN Bridge Component features specified in the IEC/IEEE
60802 specification.
3. A Bridge shall support The Customer VLAN (C-VLAN) Bridge features specified in the
IEC/IEEE 60802 specification.
4. A Bridge shall provide the ability to disable Priority Based Flow control, if supported, as
specified in the IEC/IEEE 60802 specification.
Hardware Options:
1. A Bridge may support the Ethernet Physical Interface (PHY) and Media Access Controller(MAC) features specified in the IEC/IEEE 60802 specification.
2. A Bridge may support the Advanced Physical Layer (two-wire) and Power over Data Lines(PoDL) features specified in the IEC/IEEE 60802 specification.
2022 ODVA Industry Conference

15©2022 ODVA, Inc.

3. A Bridge may support the Port-Based Network Access Control features specified in the
IEC/IEEE 60802 specification.
4. A Bridge may Support the Bridge options specified in the IEC/IEEE 60802 specification.
5. A Bridge may Support the Conformance Class A options specified in the IEC/IEEE 60802
specification.
6. A Bridge may Support the Conformance Class B options specified in the IEC/IEEE 60802
specification.
Operation Requirements
1. A Bridge shall support the Link Layer Discovery Protocol (LLDP) features specified in the
IEC/IEEE 60802 specification.
2. A Bridge shall support the Time Synchronization features specified in the IEC/IEEE 60802
specification.
Operation Options
1. A Bridge may support the Link Layer Discovery Protocol (LLDP) options specified in the
IEC/IEEE 60802 specification.
2. A Bridge may support the Time Synchronization options specified in the IEC/IEEE 60802
specification.
3. A Bridge may support the Layer 2 Network Security options specified in the IEC/IEEE
60802 specification.
4. A Bridge may Support the Bridge options specified in the IEC/IEEE 60802 specification.
5. A Bridge may Support the Conformance Class A options specified in the IEC/IEEE 60802
specification.
6. A Bridge may Support the Conformance Class B options specified in the IEC/IEEE 60802
specification.

QoS for TSN
The identification of QoS for TSN streams uses Destination Multicast MAC, PCP, and VLAN-ID. The
combined identification parameters provide high flexibility when configuring TSN Streams. In contrast,
Ethernet QoS in EtherNet/IP uses defined PCP values. A static mapping has been defined between the
CIP Priority Tag and the PCP part of IEEE 802.1Q. CIP provides no means to the end-user to change thismapping, besides disabling it (which is the default). EtherNet/IP currently doesn’t define use of the VLANID part of IEEE 802.1Q.
The CIP Priority Tag, that’s chosen based on the CIP Connection type (explicit or implicit) and theintended traffic use (motion, safety, IO, or messaging), is communicated between the originator and thetarget during connection establishment. The two endpoints agree on the predefined PCP settings for the
CIP Connection. CIP today supports four different priorities; this might be limiting if the full flexibility of
TSN streams are intended to be utilized. The CIP Priority is an attribute of the connection configurationand is a defined member within the Forward_Open. This CIP Priority will have to be expanded orredefined in some manner in order to allow for the CIP connection being established to identify with the
TSN streams it shall utilize.
Information about all configured TSN streams within a TSN capable device will have to be made available
to the CIP portion of a device. Using standard CIP interfaces will also allow CIP clients and CIP
configuration tools to make use of this information. Making use of this would allow the CIP configuration
tools to map CIP connections to TSN streams that previously were created within the TSN domain andintended to be used to transport different types of CIP traffic.

2022 ODVA Industry Conference

16©2022 ODVA, Inc.

Device Level Ring (DLR)
The Device Level Ring (DLR) protocol provides a means for detecting, managing and recovering fromfaults in a ring-based network. A DLR network consists of an active Ring Supervisor and any number ofRing Nodes. Ring nodes incorporate embedded switch technology with at least two external ports. The
Ring Supervisor is responsible for generating a “beacon” at regular intervals. These beacons traverse thering in both directions. The Ring Supervisor also sends announce frames on both ports once per second.
Announce frames allow ring nodes that are unable to process the high-speed beacon frames toparticipate in fault detection and ring recovery.
The Ring Supervisor must be capable of blocking DLR and other network traffic to avoid infinite
propagation of these frames through the ring (Network storm). Faults are detected when beacon traffic isinterrupted, and link/node failure is detected by adjacent nodes. The DLR protocol contains several fault
detection and ring recovery mechanisms.

Figure 9 - Simple DLR Ring
Implementation of DLR imposes certain requirements upon the supporting network infrastructure. DLR
does not inherently exclude the use of devices which do not support the DLR protocol in a DLR-enabled
network. It is expected that legacy devices and other considerations will frequently dictate the use of suchdevices in a DLR network. However, the use of these devices in a DLR network may significantly affect
DLR operation and performance. Inclusion of non-DLR devices in a DLR network is not discussed further
in this paper. For further information regarding the use of non-DLR devices in a DLR network see
PUB00316R2 - Guidelines for Using Device Level Ring (DLR) with EtherNet/IP.
DLR is a layer 2 protocol and can coexist with TSN however the impact of scheduled traffic will need tobe evaluated further.
2022 ODVA Industry Conference

17©2022 ODVA, Inc.

PRP Topology
The Parallel Redundancy Protocol (PRP) is designed to provide seamless recovery in case of single
failure of an inter-bridge link or bridge in the network. This protocol based on the duplication of the LAN
and duplication of the transmitted information.

Figure 10 - PRP Topology
Further improvements in recovery time require managing of redundancy in the end nodes, by equipping
the end nodes with several, redundant communication links. In general, doubly attached Bridged End
stations (M01-Mx) provide sufficient redundancy.
For time-critical applications, the parallel operation of disjoint networks provides seamless recovery, but
requires the duplication of the network.
The Bridged End station is a DANP. A DANP is attached to two independent Local Area Networks(LANs) of similar topology (LAN_A and LAN_B) which operate in parallel. One DANP (a source) sends
the same frame over both LANs to another DANP (Destination) who receives it from both LANs,
consumes the first frame and discards the duplicate.
The mechanism of duplicate generation and rejection can be implemented by a Red-Box. The Red-box
functionality is performed by devices GA1 and Mx in this network example. A Red-Box does the transition
between a Singly Attached Node (SAN) and the doubled LANs (LAN_A and LAN_B). The Red-Box
mimics the SANs connected behind it (called VDAN or virtual DANs) and multicasts supervision frameson their behalf. The Red-Box is itself a DANP and has its own IP address for management purposes, but
it may also perform application functions.
Basic HSR Topology
The High-availability Seamless Redundancy (HSR) protocol is designed to provide seamless recovery incase of single failure of an inter-device link which are based on the duplication of the transmitted
information.
Further improvements in recovery time require managing of redundancy in the end nodes, by equipping
the Bridged End stations with several, redundant communication links. In general, doubly attached end
nodes provide enough redundancy.

2022 ODVA Industry Conference

18©2022 ODVA, Inc.

Figure 11 - Basic HSR Topology
Nodes within the ring are restricted to be HSR-capable bridging nodes, thus avoiding the use of dedicatedswitches. This reduces the network to one Ring with no Switches thus reducing the cost of the network.
Singly Attached Nodes (SANs) such as laptops or printers cannot be attached directly to the ring but needattachment through a Redundancy Box (RedBox) [S01, M03, M04, Mx].
In an HSR network, Doubly Attached Nodes with HSR Protocol or DANH, are arranged as a ring. A node
within an HSR ring is restricted to HSR capable bridging nodes. This avoids the use of dedicated bridges.
Each DANH has two identical interfaces, port A and port B. For each frame, the source node sends one
copy over each of its two ports. The source node removes the frames it injected into the ring. Each node
(between source and destination) relays a frame it receives from port A to port B and vice-versa, except if
already forwarded. The destination node consumes the first frame of a pair and discards the duplicate. If
the ring is broken, frames still arrive over the intact path, with no impact on the application. Loss of a pathis easily detected since duplicates cease to arrive.
RSTP
Rapid Spanning Tree Protocol (RSTP) is an option for loop prevention and high availability described in
CIP Volume 2. The protocol will become mandatory for TSN as defined in IEC/IEEE 60802.
Mesh Topologies & 802.1CB
The Mesh Topology is a Complex High Availability network architecture that will contain numerous
interconnected Ethernet Switches and Devices. These High Availability topology architectures will be
used to describe Time Sensitive Network (TSN) operation and features as described in the IEEE 802.1CB
Standard.
Time Sync Implications and Recommendations
Time Synchronization is a necessary and core part of a Time Sensitive Network. The timesynchronization protocol that will be normative to the IEC/IEEE 60802 industrial profile for TSN will be
802.1AS-2020.

2022 ODVA Industry Conference

19©2022 ODVA, Inc.

CIP Sync is based on the end-to-end delay mechanism which is the default profile of IEEE1588.
802.1AS-2020 is based on the peer-to-peer delay mechanism which is inherently incompatible with CIP
Sync.
CIP Motion Use of Time Synchronization
Time Synchronization is a critical enabler to achieve precision motion control in CIP Motion systems. As
described elsewhere in this paper, 802.1AS-2020 is the time synchronization protocol required for TSN
network operation. The TSN committee recommends that the CIP Motion device profile specify
conditional support for both the ‘IEEE 802.1AS PTP Profile’ and the ‘CIP Sync PTP Default Profile‘.
Operation on a TSN network (or not) determines which time synchronization profile is used. Future work
is to assess how supporting the 802.1AS profile affects CIP Motion time synchronization aspects such as
establishing synchronization and recovering from a loss of synchronization. Devices currently supportingthe 1588 Default profile will require development effort to support the 802.1AS peer-peer transparent
clock mechanism. See “An Approach to CIP Motion on TSN Networks” for more information.
CIP Motion on a TSN Network
Use of a TSN network requires that motion devices using Deadline QoS support data egress per adefined TSN schedule. Motion devices with embedded bridges will require embedded switches with timecontrolled output gating. Configuration and operation of this switch is only relevant to CIP Motion for
coordination between application execution and internal data transfer through the network stack so that
motion data is queued in the switch and ready for egress at the scheduled time.
Existing CIP Motion has no dependency on the order of C2D and D2C frames. CIP Motion on a TSN
network would also have no dependency on frame order so class-based scheduling is preferred overstream-based scheduling. (Stream based scheduling being scheduling the network path of specifictalkers and listeners). There is no benefit to scheduling network access between two specific CIP Motion
endpoints relative to existing CIP Motion. Scheduling streams is an unnecessary and burdensome
requirement.
A characteristic of TSN operation with Qbv enhanced scheduling is that Layer 2 switch queues of a given
priority remain active for a time window defined by the Qbv schedule. Queues are controlled by gatesthat are opened and closed per the Qbv schedule. This allows frames tagged with the given priority totraverse the network through all hops from talkers to listeners in one cycle of gating all the queues in thecommunication path (i.e. one network cycle). With class-based scheduling of CIP Motion traffic, the time
window must accommodate the maximum number of CIP Motion packets in any specific network update
cycle, plus the maximum transfer delay of the communication path. The gating schedule of all switches in
the communication path must be identical and allow transfer of all the packets between talkers andlisteners without regard to network topology or packet order. The CNC must determine Qbv schedulingand configure all the end stations/bridges.
Incorporating non-TSN EtherNet/IP devices
EtherNet/IP Devices that do not implement the TSN profile can still operate over a TSN network.
Two methods can be used for inclusion:
1. As TSN is an extension to standards-based Ethernet, non-TSN EtherNet/IP devices willcontinue to work over a TSN network, but at a degraded level of performance. A TSN domainedge port will map non-TSN traffic into a specific queue. This queue will generally be prioritizedlower than TSN traffic unless management gives specific priority considerations to it. At thispoint there is no distinction between non-TSN industrial control traffic, and other types of trafficsuch as print jobs or web communication.
2022 ODVA Industry Conference20©2022 ODVA, Inc.

2. A TSN domain edge port can be configured as a TSN gateway. This will map non-TSN
EtherNet/IP traffic onto TSN streams and give equal quality of service considerations
throughout the network. The TSN gateway will have buffering capabilities that take into
consideration the time sensitivity of the application, non-TSN network jitter, and TSN network
timeslot availability.
CONFORMANCE APPROACH AND IMPLICATIONSThe TSN committee recognizes that for IEC/IEEE 60802 to be successful, implementers and ODVA willneed to perform conformance testing to validate conformant implementations.
ODVA management representatives, conformance testing representatives and TSN committee
representatives will need to be involved in the process of creating a conformance organization for
IEC/IEEE 60802 TSN along with representatives from other industrial standards organizations.
Success in this organization is based on the following metrics:••••

IEC/IEEE 60802 conformance testing must be able to take place at ODVA, or by ODVA
designees in conjunction with EtherNet/IP testing
The duration of IEC/IEEE 60802 conformance testing must be appropriate relative to the overall
EtherNet/IP testing.
The cost of becoming an IEC/IEEE 60802-conformance test lab and performing certification if a
IEC/IEEE 60802 mark is developed must be reasonable.
Lab certification and peer lab assessment must strike a balance to not be too onerous, but alsoachieve strict conformance for tested devices.

References
•
•

•
•

•

•

Use Cases IEC/IEEE 60802, https://www.ieee802.org/1/files/public/docs2018/60802-industrialuse-cases-0918-v13.pdf
TSN Influences on ODVA Technologies: IEEE-802.1, Avnu, IETF
https://www.odva.org/wp-content/uploads/2021/09/2017-ODVAConference_Zuponcic_Hantel_Klecka_Didier_TSN_Influences_on_ODVA_Technologies_FINAL.
pdf
QoS - Application of TSN to EtherNet/IP Networks
https://www.odva.org/wp-content/uploads/2021/09/2017-ODVAConference_Woods_Zuponcic_QoS-Application_of_TSN_to_EtherNetIP_Networks_FINAL.pdf
High Availability in EtherNet/IP Systems Using Frame Replication and Elimination for Reliability(FRER) as defined in the TSN Standard IEEE 802.1CB-2017https://www.odva.org/wp-content/uploads/2021/09/Paper-9_2018-ODVAConference_Ditzel_TSN_Redundancy_FINAL.pdf
The Comparison/Contrast of TSN Frame Replication and Elimination for Reliability (FRER)
and Parallel Redundancy Protocol (PRP)
https://www.odva.org/wp-content/uploads/2020/05/2020-ODVAConference_TSN_FRER_PRP_Ditzel_Final.pdf
An Approach to CIP Motion on TSN Networks
https://www.odva.org/wp-content/uploads/2020/05/2020-ODVA-Conference_CIP-MotionTSN_Brooks_Yu_Woods_Didier_Final.pdf******************************************************************************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible useof ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader and2022 ODVA Industry Conference

21©2022 ODVA, Inc.

those responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,and recommendations expressed herein for intended use. Copyright ©2022 ODVA, Inc. All rights reserved. For permission to
reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840
FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP
Safety, CIP Sync, CIP Security, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All othertrademarks are property of their respective owners.

2022 ODVA Industry Conference22©2022 ODVA, Inc.