Device Replacement/Network Replication are some of the most important procedures in Industrial Automation. So far Ethernet/IP Industrial automation networks lacked simple unified strategy for performing these procedures. This paper presents an algorithm which uses LLDP and DHCP protocols to accomplish Device Replacement/Network Rollout where address assignment is accomplished purely via topology information. This approach has fewer restrictions that some other Device Replacement protocols in other Ethernet Fieldbuses and therefore saves cost due to reduced number of manual steps.

1. Future Device Replacement/Network Rollout strategies in Ethernet/IP
By Roman Glistvain
Abstract
Device Replacement/Network Replication are some of the most important procedures in Industrial
Automation. So far Ethernet/IP Industrial automation networks lacked simple unified strategy for
performing these procedures. This paper presents an algorithm which uses LLDP and DHCP protocols to
accomplish Device Replacement/Network Rollout where address assignment is accomplished purely via
topology information. This approach has fewer restrictions that some other Device Replacement
protocols in other Ethernet Fieldbuses and therefore saves cost due to reduced number of manual
steps.
Introduction
Automation projects consist of a large number of electrical and mechanical components networked
together. Electrical components contain sensors, network stations, control equipment. In order to
ensure reliable operation, it is expected that different parts of equipment can be replaced very quickly in
case of failure. Otherwise, the downtime could become significant and reduce factory profits.
It is also desirable for machine developers to build identical machines consisting of networked
components (network rollout) as quickly as possible to reduce labor costs.
Both of these issues can be addressed by reducing the amount of manual configuration during the
device replacement/network rollout. Ideally it should be possible to connect various network
components together like LEGO blocks and they should be operating on the network without having to
configure each such component.
In order to communicate with the controller each network station has to have a unique address which
both the station and controller know about. When a station is replaced, the new station needs to
acquire the same address as the old station in order to work transparently with the controller.
In traditional bus networks (CAN, RS485), the station address had to be assigned manually to each
station. This is because in a bus network, there is no way to deterministically determine an identity
information that both controller and network station agree on.
In point-to-point networks (IO Link, RS232) , connection topology makes it possible to deterministically
identify each station based on the physical connection map and therefore assign unique identities to
each station which can be replicated automatically to replacement stations.
In Ethernet/IP networks the address is the IP address of the device. Quick reconfiguration of the IP
address on the replacement block is crucial for reducing downtime. Since today’s Switched Ethernet
networks are point-to-point networks, it is possible to perform automatic IP address recovery using
topology information during device replacement/network rollout.

2. Recommended approach
Today Ethernet networks are no longer bus networks. Most Ethernet networks today are implemented
using Ethernet switches which make them a point-to-point topology. When all the nodes on the network
support LLDP, it is possible to uniquely identify each node on the network using a physical connectivity
map and that information can be used to construct a topological map of the network segment that can
be used for device replacement/network replication.
Let’s examine different algorithms that can be used to collect topology information, perform identical
network rollout, Device Replacement, Normal Startup using the topology below:
Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node3 BOOTP
Desired IP: 192.168.1.9
Node4/switch DHCP
Desired IP: 192.168.1.10
Node 5 BOOTP
Desired IP: 192.168.1.11
Node 6 DHCP
Desired IP: 192.168.1.212
Node 5 BOOTP
Desired IP: 192.168.1.12
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1
p2 p1 p1
p2
p3
p1
p2
p1
p2
p1
p2
p1
p2 p1
Collecting Topology information
1) Start topology discovery from the “Smart DHCP Server node”
2) Collect the following information from its neighbors directly through LLDP:
a. IP address of each neighbor,
b. port number where this neighbor is connected to,
c. (sometimes optional) Product Information of the neighbor (Vendor ID, Product Code,
Product type, Software Revision, Number of Ethernet ports) – subset of the electronic
key.
If the neighbor is on a different subnet – its information is dropped.

3. Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
p1 p2p1
p2
p1
p2
LLDP
3) Check if the neighbor information is not present in the topology map (not visited before)
a. Record this information in the topology map on the “Smart DHCP Server” if this is a new
node.
4) Once that is done, use the IP address of each neighbor to connect to them (via SNMP or
Ethernet/IP) and collect the same information of its neighbors:
Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1
p2
p1
p2 p1
LLDP
SNMP or
Ethernet/IP
5) Record this information in the topology map on the “Smart DHCP Server”.
6) Apply the same procedure above to all nodes discovered through LLDP of neighbors

4. Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node3 BOOTP
Desired IP: 192.168.1.9
Node4/switch DHCP
Desired IP: 192.168.1.10
Node 5 BOOTP
Desired IP: 192.168.1.11
Node 6 DHCP
Desired IP: 192.168.1.212
Node 5 BOOTP
Desired IP: 192.168.1.12
p1
p2
p3
p2 p1 p1
p2
p3
p1
p2
p1
p2
LLDP
LLDP
SNMP or
Ethernet/IP
7) Once the procedure above completes, the topology map is created. It is possible that the
topology size is large and the user can interrupt the procedure in the middle to prune to
topology information and potentially designate topology boundaries where the scan should be
limited to.
8) The network topology diagram can be stored in electronic form (e.g file, table) usable in
software program on “Smart DHCP Server” node.
Network Rollout (this algorithm is the basic building block of other algorithms below)
1) Assume the diagram above (from step 9) is loaded into the “Smart DHCP Server”
(192.1568.1.5).
2) When the network above starts up, only devices with static IP addresses would be visible on IP
network.
a. All the remaining stations are sending BOOTP/DHCP requests with the only identifying
information is the MAC address of these stations.
3) The Network Rollout algorithm starts with the “root” node. At first, the root node is the “Smart
DHCP Server node”.
4) Smart DHCP server runs the following algorithm
a. Clear up the DHCP server assignment table (no assignments can be made)

5. Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node3 BOOTP
Desired IP: 192.168.1.9
Node4/switch DHCP
Desired IP: 192.168.1.10
Node 5 BOOTP
Desired IP: 192.168.1.11
Node 6 DHCP
Desired IP: 192.168.1.212
Node 5 BOOTP
Desired IP: 192.168.1.12
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1
p2 p1 p1
p2
p3
p1
p2
p1
p2
p1
p2
p1
p2 p1
DHCP
(ignored)
DHCP
(ignored)
b. Wait until LLDP information from neighbors is available and extract LLDP information
from ports of the root node (e.g ports 1..4 of “Smart DHCP Server node”)
i. LLDP information is collected directly due to the fact that root node (e.g “Smart
DHCP Server” node) is directly connected to its neighbor nodes.
ii. Make sure that LLDP information matches node description in the topology
map.
c. Add DHCP table entry for each port (with no IP address assigned) containing:
i. IP addresses of neighbor (from topology table above)
ii. MAC address of the neighbor received in the LLDP frame on the corresponding
port.
Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1p1
p2
p1
p2 p1
DHCP (assign
neighbors for
ports 1..4)
LLDP (from ports 1..4)
DHCP (ignore everyone else)

6. d. Once IP addresses are assigned and network child modules are accessible via TCPIP
i. Poll Child modules (via SNMP or Ethernet/IP) until they indicate that LLDP
information from their children is available.
ii. Collect LLDP information from its neighbors (in case of 192.168.1.17 – the
neighbors are 192.168.1.5 and 192.168.1.18). The LLDP information contains
MAC address and Management IP address.
1. Make sure that LLDP information matches node description in the
topology map.
iii. Add DHCP table entry for each port where the IP address is not yet assigned:
1. IP addresses of neighbor (from topology table above)
2. MAC address of the neighbor received in the LLDP frame on the
corresponding port.
Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1p1
p2
p1
p2 p1
LLDP
DHCP (assign)
LLDPSNMP or
Ethernet/IP
SNMP or
Ethernet/IP
3. Repeat the process above for all detected devices until the entire
network is up and running based on the stored topology information.

7. Device Replacement
The following is the definition “reachability”: Node “K” is reachable from Node “A” if and of only if there
is a path “P” through “N nodes” between “A” and “K” where the path “P” in the real network matches
the same path “P” through the same “N nodes” in topology map.
A B C
K
Topology map
D E
F
A B C
K
Real Network
E
1) “Smart DHCP server” is constantly polling the state of topology
a. Making sure that topology information in the real network matches to the stored
topology.
2) If an inconsistency is detected – find the last “reachable” node “K” from the “Smart DHCP
Server” after which the inconsistency is present.

8. a. If a node mismatch is detected between real network and topology – error is reported
b. If a new compatible node is present after specific port on node “K”, run the “Network
Rollout” algorithm above starting with the step 4.d where the “root node” is set to “K”.
Node2 Static IP
192.168.1.8
Node3 BOOTP
Desired IP: 192.168.1.9
Node4/switch DHCP
Desired IP: 192.168.1.10
Node 5 BOOTP
Desired IP: 192.168.1.11
Node 6 DHCP
Desired IP: 192.168.1.212
Node 5 BOOTP
Desired IP: 192.168.1.12
p2 p1 p2 p1 p1
p2
p3
p1
p2
p1
p2
Last reachable
node
Normal Network Startup:
1) If the nodes are set to “static ip” after “Network Rollout” – all nodes will start with static IP
addresses.
2) If nodes are set to remain in “DHCP/BootP” Run network replication algorithm above.
a. Upon every network startup, all appropriate nodes are running DHCP/BootP client
program to reacquire the IP address.
b. The convergence time should be very quick since parallel branches of the network can
be handled in parallel.

9. Workarounds for various issues
The algorithm is fairly simple. However, there are a number of issues which would prevent quick IP
assignment.
Problem 1:
There is no way for “Smart DHCP server” to perform assignment of IP address until neighbor information
of a specific node is extracted (MAC address, some product description). “Smart DHCP Server” is going
to ignore DHCP Discover/BootP Requests until the neighbor information is acquired.
Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node3 BOOTP
Desired IP: 192.168.1.9
Node4/switch DHCP
Desired IP: 192.168.1.10
Node 5 BOOTP
Desired IP: 192.168.1.11
Node 6 DHCP
Desired IP: 192.168.1.212
Node 5 BOOTP
Desired IP: 192.168.1.12
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1
p2 p1 p1
p2
p3
p1
p2
p1
p2
p1
p2
p1
p2 p1
DHCP
(ignored)
DHCP
(ignored)
It can take a long time for nodes to retransmit BootP/DHCP Requests which would make the “Network
Rollout” algorithm very slow (especially in Line/Ring topologies).
Since the “Network Rollout” algorithm serves as a building block of Device Replacement, Network
Replication, Normal Startup, it could become unfeasible with a large enough network.
To avoid this problem, Smart DHCP server “buffers DHCP/BootP Requests” even though it doesn’t have
an assignment entry for them at that point.

10. Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1p1
p2
p1
p2 p1
DHCP (assign
neighbors for
ports 1..4)
LLDP (from ports 1..4)
DHCP/BootP
(store all other requests into
the buffer and don’t respond
to them)
Instead of discarding all unknown DHCP requests (which don’t have a mapping information inside the IP
assignment table), buffer enough information from the request to be able to reconstruct IP address
assignment response once the LLDP information is available. The request is not going to be responded
to right away but the response would be delayed until the LLDP data is transferred to the Smart DHCP
server. Once the LLDP data is transferred (directly via LLDP for direct neighbors of “Smart DHCP Server
node” or via SNMP (or Ethernet/IP) for other nodes) the “Smart DHCP server node” would immediately
issue DHCP Offer/BootP response frame constructed from the information available in the DHCP
Request buffer.
Smart DHCP Server/
Network node
Staic IP 192.168.1.5
Node1 DHCP
Desired IP: 192.168.1.7
Node2 Static IP
192.168.1.8
Node8 DHCP
Desired IP: 192.168.1.15
Node9 BOOTP
Desired IP: 192.168.1.17
p1
Other node
Static IP
192.168.1.6
p4
p2
p3
Node10 BOOTP
Desired IP: 192.168.1.18
p1 p2 p2 p1p1
p2
p1
p2 p1
LLDP
LLDPSNMP or
Ethernet/IP
SNMP or
Ethernet/IP
Send BootP response without
waiting for the new BootP request
based on the
MAC address in the previous
BootP request stored in the DHCP
request buffer
The algorithm for buffering DHCP/BootP requests is the following:
1) When a new DHCP/BootP Discovery frame arrives:
a. Buffer into “DHCP_Request_buffer”: timestamp, MAC address, request type(DHCP
Discover/BootP), transaction ID, requested options (and any other information required
to construct a response).

11. 2) When neighbor information is available for a new node that matches the product information in
Topology map:
a. Search “DHCP_Request_buffer” for a MAC address that matches the new node MAC
address.
b. Find the node information in topology and establish mapping between MAC/IP.
c. Construct DHCP Offer/BootP Response to the node and complete DHCP/BootP exchange
assigning appropriate IP address from the topology map.
d. The “DHCP_Request_buffer” entry can be deleted as the lease is infinite and when the
node starts up it will restart DHCP sequence.
This way the IP assignment time for the complete network could be very short. It is assumed that
different network branches stemming from different ports on the same switch can be assigned in
parallel.
Problem 2:
Another issue with this approach is ACD. With ACD, it is assumed that the station will not allow IP based
access to the device until the IP address was probed. This could delay each IP assignment by ~800ms. A
number of workarounds are possible:
1) (preferred)Disable DHCP after the initial network rollout/Device Replacement
a. 800ms per device delay will still be experienced the first time.
b. The Smart DHCP server can still determine wrong connectivity of devices (e.g station
with a static IP is in the wrong place in the topology)
2) “Smart DHCP Server” will send Disable ACD command to all affected nodes after execution of
“Network Rollout” algorithm (which is part of Device Replacement/normal start)
a. 800ms per device delay will still be experienced the first time.
3) Some other way to disable ACD on new device
a. Enable QC without disabling AutoNegotiate/AutoMDIX
b. Custom mode of operation (e.g bypass initial probing similar to QuickConnect)
c. Custom option in DHCP/BootP which bypasses (e.g bypass initial probing similar to
QuickConnect)
It might be preferable to disable DHCP/BootP after running “Network Rollout” algorithm on a new node.
The reason is that when a node goes faulty, the replacement node may not be available right away and
rather than having the entire network down, it might be preferable to connect cables around the failed
node – violating topology map (provided that the machine can function without the failed node for
some time). When the replacement node is received, plugging it into the right place in topology will
automatically trigger the Device Replacement algorithm and the proper network will be reestablished.

12. Extensions of this algorithm which make it attractive for industrial networks
Extension 1:
In today’s industrial Ethernet networks, device replacement is only possible if the replaced device is
plugged to the same ports as specified in the topology map:
Node2 Static IP
192.168.1.8
Node3 BOOTP
Desired IP: 192.168.1.9
Node4/switch DHCP
Desired IP: 192.168.1.10
p2 p1 p2 p1 p1
p2
p3
Device Being
Replaced/Device in
the Replicated
network
If the topology map specified the connectivity diagram above, the replacement device needs to be
connected exactly like above (Node2 P1-> Node3 P2, Node4 P1 -> Node3 P1).
It can not be connected in an alternative way (Node2 P1-> Node3 P1, Node4 P1 -> Node3 P2).
This could be a challenge if the majority of devices are line/ring topology devices and replacing a device
would require consulting with the topology map instead of simply plugging the device in the place of the
old device (regardless of the cabling order).
It would be a nice property if the device replacement/network rollout algorithm would allow “relaxed
connectivity” requirements in Line/Ring topologies:
Node2 Static IP
192.168.1.8
Node3 BOOTP
Desired IP: 192.168.1.9
Node4/switch DHCP
Desired IP: 192.168.1.10
p2 p1 p2 p1 p1
p2
p3
Device Being
Replaced/Device in
the Replicated
network
Node2 Static IP
192.168.1.8
Node3 BOOTP
Desired IP: 192.168.1.9
p2
Node4/switch DHCP
Desired IP: 192.168.1.10
p2 p1 p2p1 p1
p3
Device Being
Replaced/Device in
the Replicated
network

13. The following is the modification to the algorithm which makes it possible to have “relaxed connectivity”
requirements in Line/Ring topologies.
When performing “Network Rollout” Algorithm:
1) When IP address is assigned to a new node via DHCP/BootP
a. Smart DHCP server collects the information about its neighbors.
b. It knows the MAC address of the “previous” node that was assigned IP address and
therefore it can derive the port number of the “next” node (MAC address was not seen
yet) in the Line/Ring topology. This approach defines “assignment direction vector” in
Line/Ring topologies.
i. It is assumed that the “relaxed connectivity” doesn’t apply to “Smart DHCP
Server” node even if it is a 2 port device. It also doesn’t apply to devices which
have more than 2 ports.
Extension 2:
Support for Ring topologies:
1) When Ring is broken, then loop is broken and Network Rollout algorithm proceeds as usual.
2) When Ring is operational, it is assumed that LLDP frames pass through both ports of the ring
supervisor. In that case the Network Rollout algorithm proceeds normally
a. seeing a node that was visited before would stop the “Network Rollout” in a specific
branch of the network containing the ring.
3) The “Assignment direction vector” could be different in the ring depending if the ring is broken
or if the ring is operational.
Extension 3:
It is possible to have infrastructure nodes (multi-port Ethernet switches) which don’t support
Ethernet/IP but support LLDP/SNMP. These nodes are assumed to start in DHCP mode. In this case, the
“number of Ethernet ports” extracted via SNMP can be used to determine if the replacement node is
compatible or not (it needs to match to the device in the stored topology).
Extension 4:
Support for 2 port devices that don’t support LLDP. It is assumed that such devices pass LLDP frames
transparently between switch ports. It is also assumed that the address information in these nodes is set
through some other means.

14. Conclusion
The Device Replacement/Network Rollout algorithm described above implements one of the most
important features which is currently missing in Ethernet/IP Industrial networks.
It can work with any node implementing LLDP and Ethernet/IP where the node can be configured to be
DHCP/BootP client.
This algorithm is more flexible than some other Ethernet Device Replacement protocols on other
industrial networks:
1) It has “relaxed connectivity” requirements when it comes to line/ring topologies which can
considerably simplify Device Replacement.
2) It can mix 2 port devices which implement LLDP and the ones which don’t – making it possible to
use some legacy devices in the network.
“Smart DHCP Sever node” can be integrated into any network node (PLC or any other node). This makes
it possible to offload a number of processing functions from the PLC thus reducing cost.