An introduction to
LLDP
Link Layer Discovery Protocol
Device Discovery: Important Now More Than Ever
One of the deficiencies of factory floor systems is that, unlike IT systems, there is no ability built into factory floor devices to allow a supervisory system to identify the devices on a network, their configuration and what capabilities they have, information that is especially important to the maintainability of a plant floor network.
In the IT world, network pings and System Network Maintenance Protocol (SNMP) provide this functionality. Network pings are messages sent to every possible address to determine who exists. New devices can be discovered by comparing the list of devices responding to the ping to the list of known devices. For detailed information on an enterprise device, enterprise network tools use the SNMP protocol to interrogate devices to learn the device type, get real-time status updates on attributes like printer toner, read configuration and monitor the operation of a device. SNMP is built into most every enterprise network device.
There is currently no capability like this for the factory floor. The Link Layer Discovery Protocol (LLDP), originally designed for enterprise IT networks, is now being promoted by both the ODVA and Profinet International (PI) to address this deficiency. LLDP is an industry-standard, vendor-neutral method to allow networked devices from different vendors to advertise identity, capabilities and other useful characteristic information.
PROFINET was the very first factory floor technology to make LLDP a required component of every device. The ODVA is planning to make it mandatory later in 2022. Support for the Link Layer Discovery Protocol will be required for all EtherNet/IP devices in 2022 or 2023. Device vendors building EtherNet/IP devices should immediately begin to incorporate LLDP into their devices.
What Do You Need to Know?
LLDP is a Layer 21 protocol, detailed in IEEE 802.1AB-2005, that replaces several proprietary protocols implemented by individual vendors and supported only on their equipment. Discovery of devices and configuration information is difficult in a system using heterogeneous devices. The LLDP was introduced by the Internet Engineering Task Force (IETF) to standardize a vendor-neutral mechanism for exchanging device information.
The typical information that is gathered using LLDP includes a number of items particular to devices like routers and switches on enterprise networks.
- System name and description
- Port name and description
- VLAN name and identifier
- IP network management address
- Capabilities of the device (for example, switch, router, or server)
- MAC address and physical layer information
- Power information
- Link aggregation information
There is also a portion of the LLDP messaging protocol that provides custom data fields so information about factory floor devices can be tailored even further.
The LLDP-enabled devices contain an LLDP agent. The agent periodically sends broadcast messages advertising the device information. Often, that information is stored in Management Information Databases (MIBs) located on a factory floor server. Factory floor network tools can access that database using SNMP to provide detailed network topology and architecture information for factory floor networks.
What Are the Details?
Managing these plant floor networks is becoming more difficult every day. The topology of factory floor networks are much more diversified than enterprise IT networks. Plus, the configurations of factory floor devices is more complicated and unique than enterprise devices.
To maintain these more complicated networks, manufacturers increasingly need tools to automatically obtain the topology, configuration and status of their diverse set of devices. LLDP does exactly that. LLDP can identify devices, connections between devices and provide detailed configuration data, and it provides manufacturers with a single place to view device configuration data for a network.
The LLDP Protocol is formally referred to by the IEEE as the Station and Media Access Control Connectivity Discovery and is specified in IEEE 802.1AB with additional support in IEEE 802.3 section 6 clause 79.
The base messaging unit of an LLDP message is a Protocol Data Unit (PDU). PDUs are encapsulated inside an Ethernet frame and transmitted at fixed intervals to all ports that support LLDP. Each frame consists of one and only one LLDP Data Unit (LLDPDU). Each LLDPDU consists of a sequence of attributes known as type-length-value (TLV) data structures.
LLDPDUs are transmitted in a special Ethernet frame identified by MAC address (01:80:C2:00:00:0E) and Ethertype (0x88CC). This MAC address is an “LLDP Multicast” address. It is in the range of addresses that is constrained to a local network. Messages in this MAC address range are never propagated outside the network by switches and routers. Any device on the network can capture LLDP messages and deliver them to an application.
Attributes are how LLDP organizes device information. They are transmitted in an LLDP frame using a standardized data format known as a Type-Length-Value (TLV) structure. Each LLDP frame begins with a set of mandatory TLV data structures followed by any number of optional TLVs. The frame ends with the LLDPDU end of frame TLV.
A TLV structure is composed of a type field of 7 bits, a length field of 9 bits and a value field of 0 to 511 octets. The type and length fields of the TLV data structure are 0 in the final PDU.
The type field identifies the contents of the PDU to the receiver.
Type | Name | Usage |
0 | Last PDU | Mandatory |
1 | Chassis ID | Mandatory |
2 | Port ID | Mandatory |
3 | Time to Live | Mandatory |
4 | Port Description | Optional |
5 | System Name | Optional |
6 | System Description | Optional |
7 | System Capabilities | Optional |
8 | Management Address | Optional |
127 | Custom TLVs | Optional |
The mandatory attributes (chassis ID, port ID and time-to-live) are transmitted in every LLDP frame. Other TLV frames, including custom TLVs (used to transfer specific device data) can be included at the discretion of the device publishing the TLV frame.
LLDP OPERATION
LLDP is a one-way protocol. A device enabled for LLDP sends periodic advertisements of its information in LLDP frames to a receiving device. Devices are identified using a combination of the chassis ID and port ID. A receiving device saves the information about a neighboring device for a certain period of time, specified in the time-to-live TLV, and then removes the information when the time period expires. Below are some additional operational characteristics of LLDP devices.
- LLDP operates independently in either a transmit or a receive mode. Devices can simply transmit LLDP frames, maintain information about neighboring devices or collect complete information about the local network.
- LLDP uses only untagged frames with transmission speeds of less than 5 frames per second.
- LLDP packets are transmitted on:
- The packet update frequency expires. The default frequency is 30 seconds.
- On a value change in a value in the device.
- On activation of the LLDP interface (3 frames are sent on activation).
- TLVs with invalid values are ignored.
- TLVs with a Time-to-Live value of 0 are interpreted as directive to automatically purge the information for the transmitting device. This is a shutdown LLDPDUs and typically sent prior to a port becoming inoperable.
- LLDP frame with malformed mandatory TLVs are ignored.
ETHERNET/IP INTERFACE
The EtherNet/IP Specification provides definitions for an LLDP Management Object (0x109) and an LLDP Data Table Object (0x10A) to determine how EtherNet/IP devices use TLVs to communicate information. More information about these two objects is below.
- LLDP Management Object
- Description – The LLDP Management Object describes the administrative details for the LLDP protocol. It exists whenever LLDP is implemented on an object.
- Instances – There is only one instance even when LLDP messages are published on multiple Ethernet ports.
- Instance Attributes – The LLDP Management Object supports five attributes, found in the chart below.
Attribute | Name | Get/Set | Required/Optional | Description |
1 | LLDP Enable | Set | Required | Structure indicating status of LLDP |
2 | Message Transmit Interval | Set | Required | The interval in seconds that LLDP messages are produced by the interface |
3 | Message Transmit Hold | Set | Required | Multiplier of the transmit interval to determine the Time-to-Live value |
4 | LLDP Data Store | Get | Optional | Mechanism that is used to retrieve data from the LLDP data store |
5 | Last Change | Get | Optional | Count in seconds from last time anything in local LLDP database was changed |
- Class Packages – The are no class specific attributes in the LLDP Management Object.
- Common Services – The LLDP Management Object supports several common services including Get Attribute All and Get/Set Single Attribute.
- Object Specific Services – The LLDP Management Object supports no object-specific services.
- Behaviors – The is no specific behavior specific for the LLDP Management object.
- The LLDP Data Table Object
- Description – The LLDP Data Table Object contains the list of all adjacent and active LLDP devices. The Data Table Object exists if both, LLDP is implemented on the device and the SNMP LLDP MIB is not implemented. If there are no neighboring devices, none of the instance attributes are available.
- Instances – A minimum of eight instances of the Data Table Object must be supported, one for each active LLDP devices discovered on the network. A total of 48 instances is recommended. Instances are created as devices are found and removed when devices are no longer publishing LLDP messages.
- Instance Attributes – The LLDP Data Table Object supports the following attributes.
Attribute | Name | Get/Set | Required/Conditional | Description |
1 | Link Instance Number | Get | Required | The instance number of the local Ethernet Link Object where this device was found |
2 | MAC Address | Get | Required | The MAC address of the neighboring device |
3 | Interface Label | Get | Required | The CIP Interface label information |
4 | Time to Live | Get | Required | The number of seconds the neighboring information for this device is valid |
5 | System Capabilities | Get | Required | A bitmap of the system capabilities |
6 | IPv4 Management Address | Get | Required | The IPv4 Management address of the device associated with this instance |
7 | CIP Identification | Get | Required | CIP Identification Time-to-Live |
8 | Additional Ethernet Capabilities | Get | Required | Time-to-Live Presumption support from neighboring devices |
9 | Last Change | Get | Optional | A count in seconds indicating the time since any attribute in this instance changed. |
10 | Position ID | Get | Conditional | Position ID for the device position for In-Cabinet EtherNet/IP |
11 | PHY Configuration | Get | Conditional | PHY configuration settings for In-cabinet EtherNet/IP |
- Class Attributes – Two class specific attributes must be supported. The Max Instances attribute specifies the largest instance number currently available. The Number of Instances attribute specifies the total number of active instances.
- Common Services – The LLDP Management object supports several common services including Get Attribute All and Get/Set Single Attribute.
- Object Specific Services – The LLDP Management Object supports no object-specific services.
- Behaviors – The is no specific behavior specific for the LLDP Management object.
As you can see, LLDP is a significant step forward for EtherNet/IP. As ODVA points out:
“EtherNet/IP, including CIP Security, has been enhanced to include constrained device definitions. Furthermore, the addition of the option to use Link Layer Discovery Protocol (LLDP) will enable nodes and infrastructure to detect other devices in near proximity, and for the physical network topology to be discovered and visualized. As a required component for TSN [Time Sensitive Networking], the addition of LLDP lays the groundwork for easier adoption of TSN into the EtherNet/IP Specification.”
1Layer 2 is the networking layer where devices send messages to each other using a MacID address discovered using Address Resolution Protocol (ARP) messages that convert an IP Address into a MacID address.