UAFX defines the use of the LLDP protocol for IA-stations to announce themselves to their peers for device and topology discovery. By default, announcements from a UAFX Station contain, among others, the management address(es) and system capabilities (see 7.3.2.2.4).

For adaptability of the operational behaviour and the announced information of LLDP, all UAFX Stations support the LLDP local system YANG (see 7.3.2.2.5). UAFX Stations that include a Bridge Component also receive and store LLDP announcement information received from their peers in the LLDP remote systems YANG.

A remote management protocol (see 7.2) is used between the TDE and IA-stations to query the local system YANG and remote systems YANG. The management address information in the retrieved remote systems YANG allows the TDE to discover and query new IA-stations. The correlation of an IA-station’s local system data with a neighbouring IA-station’s remote systems data enables the TDE to discover the physical network topology.

Figure 18 illustrates an example network showing the LLDP agents and their management in a UAFX Station consisting of a single End Station Component, an IA-station, and a UAFX Station with an End Station Component and a Bridge Component.

Figure 18 – Usage example of LLDP in UAFX

A UAFX Station shall implement LLDP according to IEEE Std 802.1AB-2016, 5.3, following the definitions in 7.3.2.2.

LLDP defines several operational parameters that control the protocol behaviour (see IEEE Std 802.1AB2016, 10.5.1). These parameter definitions apply to all external ports of a UAFX Station.

NOTE According to IEEE Std 802.1AB2016, 9.1.1 c), changes to the local system that impact information exchanged via LLDP immediately trigger the transmission of an LLDPDU to communicate the local changes as quickly as possible to any neighbouring systems.

A UAFX Station shall support LLDP transmit mode (adminStatus enabledTxOnly) on an external End Station Component port and may support transmit and receive mode (adminStatus enabledRxTx) on that port (see IEEE Std 802.1AB-2016, 10.5.1).

A UAFX Station shall support LLDP transmit and receive mode (adminStatus enabledRxTx) on an external Bridge Component port (see IEEE Std 802.1AB-2016, 10.5.1).

The destination address shall be the nearest bridge group MAC address, i.e. 01-80-C2-00-00-0E, to limit the scope of LLDPDU propagation to a single physical link (see IEEE Std 802.1AB2016, 7.1 item a).

It is recommended that LLDPDUs be transmitted using the traffic class associated with Network Control as defined in Table 1 and derived from 6.4.3.

NOTE IEEE 802.1AB-2016 defines LLDPDUs to be transmitted untagged, i.e., frames do not carry priority information for traffic class selection. At the same time, IEEE 802.1AB-2016 neither specifies a well-defined device-internal priority nor management capabilities for the configuration of the traffic class to be used for the transmission of LLDPDUs.

A UAFX Station transmitting LLDPDUs shall include the LLDP TLVs selected in this sub-clause. A UAFX Station receiving LLDPDUs shall process LLDPDUs and include the information in the LLDP Remote System’s YANG.

Each transmitted LLDPDU shall contain the following LLDP TLVs defined in IEEE 802.1AB-2016, 8.5:

• exactly one Chassis ID TLV, as defined in 7.3.2.2.4.2,
• exactly one Port ID TLV, as defined in 7.3.2.2.4.3,
• exactly one Time To Live TLV,
• exactly one System Capabilities TLV, as defined in chapter 7.3.2.2.4.4,
• one or more Management Address TLVs, as defined in 7.3.2.2.4.5, and
• zero or more additional TLVs not listed in this requirement.

NOTE The concatenation of the Chassis ID and Port ID fields enables the recipient of an LLDPDU to identify the sending LLDP agent/port.

The Chassis ID field shall contain the same value for all transmitted LLDPDUs independent from the transmitting port of the UAFX Station, i.e., be a non-volatile, UAFX Station-unique identifier.

The Chassis ID subtype field should contain subtype 4, indicating that the Chassis ID field contains a MAC address to achieve the Chassis ID's desired deployment-wide uniqueness. For UAFX Stations with multiple unique MAC addresses, any one of the UAFX Station’s MAC addresses may be used and shall be the same for all external ports of that UAFX Station.

The Port ID field shall contain the same value for all transmitted LLDPDUs for a given external port, i.e., be a non-volatile, UAFX Station-unique identifier of the LLDPDU-transmitting port.

The Port ID subtype field should contain subtype 5, indicating that the Port ID field contains the interface name (name) according to IETF RFC 8343.

A UAFX Station consisting of only one or more End Station Components shall set the system and enabled capabilities fields to Station Only (i.e., bit 8 set to “1”) for all transmitted LLDPDUs.

A UAFX Station with at least one End Station Component and at least one Bridge Component shall set the system and enabled capabilities fields to Station Only (i.e., bit 8 set to “1”) and C-VLAN component (i.e., bit 9 set to “1”) for all transmitted LLDPDUs.

NOTEThe combination of the Station Only and C-VLAN component flags is used as a marker indicating to the TDE that the internal structure of the UAFX Station consists of multiple components. This is a deliberate deviation from a footnote in IEEE Std 802.1AB2016, Table 8-4.

A UAFX Station supporting remote management shall announce at least one IPv4 address by which its management entity (see 7.2.2) can be reached.

A UAFX Station supporting remote management (see 7.2) shall implement LLDP management according to IEEE 802.1ABcu-2021, 5.3 Item o).

A UAFX Station supporting the remote systems YANG shall be able to store information from at least one neighbour per external port. Receiving LLDPDUs from more neighbours than supported on a given port shall result in the last one received being saved to the remote systems YANG as described in IEEE Std 802.1AB2016, 9.2.7.7.5.