Link Layer Discovery Protocol

Overview

There is a need for a standardized way of representing the physical network connections pertaining to a given management domain. A standardized discovery mechanism is also required to increase the likelihood of multi-vendor interoperability of such physical topology management information.

Link Layer Discovery Protocol

The Link Layer Discovery Protocol (LLDP) is a media independent protocol intended to be run on all IEEE 802 devices, allowing a LLDP agent to learn higher layer management reachability and connection endpoint information from adjacent devices.

LLDP runs on all 802 media. Additionally the protocol runs over the data-link layer only, allowing two systems running different network layer protocols to learn about each other.

Each device configured with an active LLDP Agent sends periodic messages to the Slow Protocols multicast MAC address as specificed by Std 802.3, 2000 Edition Annex 43B. The device sends the periodic messages on all physical interfaces enabled for LLDP transmission, and listens for LLDP messages on the same set on interfaces. Each LLDP message contains information identifying the source port as a connection endpoint identifier. It also contains at least one network address which can be used by an NMS to reach a management agent on the device (via the indicated source port). Each LLDP message contains a configurable time-to-live value, which tells the recipient LLDP agent when to discard each element of learned topology information.

Frame Encapsulation

An LLDP PDU is encapsulated within an 802 frame that cooresponds to frame formatted to meet the requirements of an 802 Slow Protocol as defined by Std 802.3, 2000 Edition, Annex 43B. The format is shown in the following figure:

Slow Protocols Multicast DA

The Slow Protocols Multicast destination address is 01-80-C2-00-00-02. This address is within the range reserved by ISO/IEC 15802-3 (MAC Bridges) for link-constrained protocols and will not be forwarded by conformant MAC bridges.

Station SA

The source MAC address of the sending station

Slow Protocols Type

The Slow Protocols Type field encoding of the Length/Type field is 88-09

Subtype

The Slow Protocols Subtype field is TBD. All reserved fields shall be set to zero.

LLDP Message Format

The basic LLDP protocol data unit consists of a header, followed by a variable number of Type-Length-Value (TLV) attributes. A single LLDP PDU is transmitted in a single 802 media frame.

LLDP Header Format

The LLDP header is a 4 byte header, in network byte order, containing 3 fields, as shown in figure.

Version

The LLDP protocol version number, set to 0x01 for this version of the protocol.

Flags

The LLDP flags field provide for future header extensions and keep the header word-aligned for easier processing. No flag definition bits are defined at this time. This field must be set to zero in all version 1 LLDP messages.

Time to Live

The number of seconds the information in this LLDP message should be regarded as valid by the recipient. Agents of the PTOPO MIB must not return MIB information based on expired LLDP messages. The valid range is 0 to 65535 for this field.

TLV Format

Following the LLDP header are a variable number of TLVs, depending on implementation and maximum message size.

A 2 byte type field identifies the specific TLV, and a 2 byte length, in octets, indicates the length of the value field contained in the TLV. A TLV shall always start on a 4 octet boundary. Pad octets are placed at the end of the previous TLV in order to align the next TLV. These pad octets are not counted in the length field of the TLV.

Type

The integer value identifying the type of information contained in the value field.

Length

The length, in octets, of the value field to follow.

Value

A variable-length octet-string containing the instance-specific information for this TLV.

Standard TLV Definitions

The mandatory LLDP TLVs allow for a LLDP agent to support the PTOPO MIB for connections terminating on the local chassis. Optional TLVs allow for vendor specific extensions.

The following table summarizes the TLVs defined in this document.

Chassis ID

The Chassis ID is a mandatory TLV which identifies the chassis component of the endpoint identifier associated with the transmitting LLDP agent.

The Chassis ID fields are defined as follows:

Chassis ID Type: This field identifies the format and source of the chassis identifier string. It is an enumerator defined by the PtopoChassisIdType object from RFC2922

Chassis ID String: The binary string containing the actual chassis identifier for this device. The source of this field is defined by PtopoChassisId from RFC2922.

Port ID

The Port ID is a mandatory TLV which identifies the port component of the endpoint identifier associated with the transmitting LLDP agent. If the specified port is an IEEE 802.3 Repeater port, then this TLV is optional.

The Port ID fields are defined as follows:

Port ID Type: This field identifies the format and source of the port identifier string. It is an enumerator defined by the PtopoPortIdType object from RFC2922

Port ID String: The binary string containing the actual port identifier for the port which this LLDP PDU was transmitted. The source and format of this field is defined by PtopoPortId from RFC2922.

Management Address

The Management Address is a mandatory TLV which identifies a network address associated with the local LLDP agent, which can be used to reach the agent on the port identified in the Port ID TLV. The value field of this TLV has the following record format:

The Management Address fields are defined as follows:

IANA Address Family: The enumerated value for the network address type identified in this TLV. This enumeration is defined in the “Assigned Numbers” RFC [RFC3232] and the ianaAddressFamilyNumbers object.

Address Length: The number of octets contained in the address string to follow.

Address: The binary string containing the network management address for this TLV.

Vendor-Specific

This TLV is available to allow vendors to support their own extended attributes not suitable for general usage. The information conveyed in the TLV MUST not affect the operation of the LLDP protocol.

LLDP agents not equipped to interpret the vendor-specific information sent by other LLDP agents MUST ignore it (although it may be reported). LLPD agents which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

A summary of the Vendor-Specific TLV format is shown below. The fields are transmitted from left to right.

Vendor-Id: The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the "Assigned Numbers" RFC [RFC3232].

String: The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. Multiple subattributes MAY be encoded within a single Vendor-Specific TLV, although they do not have to be.

Protocol Operation

An active LLDP Agent must perform the following tasks:

• transmit LLDP messages
• process received LLDP messages
• maintain an instance of the LLDP MIB
• maintain an instance of the PTOPO MIB
• maintain appropriate ifEntry and/or entPhysicalEntry instances
• implement ifAlias and/or entPhysicalAlias MIB objects

Protocol Initialization

Upon system reinitialization, the following tasks are performed by the LLDP agent:

Non-volatile configuration for the LLDP MIB is retrieved if applicable, otherwise appropriate default values are assigned to all LLDP configuration variables.

If LLDPAdminStatus is equal to 'disabled(2)', then LLDP initialization is terminated (until such time that the LLDPAdminStatus object is set to 'enabled(1)'), otherwise continue.

Internal (implementation-specific) data structures are initialized such that appropriate local physical topology information and LLDP transmission parameters are set.

Message Encoding

This section does not assume a particular buffering strategy, and such details are omitted.

Header Fields

The version field is set to one (0x01). The flags field is set to zero (0x00).

The time-to-live field is set to the value obtained by the following formula:

TTL = min(65535, (LLDPMessageTxInterval * LLDPMessageTxHoldMultiplier))

TLVs

Each message must contain one instance of each of the mandatory LLDP TLV elements. Additional TLV data elements may be added as maximum frame size permits.

The mandatory TLVs include: Chassis ID, Port ID (optional for repeaters) and Management Address.

Message Transmission

LLDP agents must follow the rules for Slow Protocols transmission as defined by Std 802.3, 2000 Edition, Annex 43B. In addition to these rules, an active LLDP agent must transmit a LLDP message out each appropriate port, once each message interval, as determined by the LLDPMessageTxInterval MIB object, subject to the restriction of transmission rules for Slow Protocols. Messages transmitted on repeater devices may be sent for each repeater backplane, once per message interval. Actual transmission intervals should be jittered to prevent synchronization effects.

Note that the agent must suppress the transmission of multiple LLDP messages during a single message interval, in the event message transmission cannot be restricted to a single port, but rather a group of ports (e.g., a repeater device).

In this case, a single port in the port group should be selected (in an implementation-specific manner) to represent the port group. Note that an agent is encouraged to represent port groups as 'backplanes', in the entPhysicalTable of the Entity MIB, rather than individual ports in either the Entity MIB or Interfaces MIB.

Regarding the transmission of a single LLDP message, for the indicated physical interface contained in the local system:

The LLDP agent checks for the existence of a LLDPSuppressEntry for the port. If an entry exists then this port is skipped, otherwise continue.

The LLDP message is encapsulated as appropriate for the port.

The MAC header is filled in with appropriate SA and DA and EtherType fields as defined above.

The frame is transmitted or passed to a lower layer for transmission.

The LLDPStatsOutPkts counter is incremented for the indicated local port.

Message Forwarding

As indicated by the operation of Slow Protocols, LLDP agents should not forward LLDP messages received on any port. However, some devices, such as repeaters, cannot examine each frame received on an interface or port. Such a device will allow LLDP messages to be retransmitted on one or more local ports, and will transmit its own LLDP messages on those ports as well. These agents are termed 'forwarding' LLDP agents.

LLDP agents located on devices which examine each frame before retransmitting it (e.g., routers and bridges), are expected to process received LLDP messages and not retransmit them on any local port. These agents are termed 'non-forwarding' LLDP agents.

An NMS may find physical topology information about the same physical port, represented by several LLDP agents. This may occur for one of several reasons, including a mixture of forwarding and non-forwarding LLDP agents within a network.

Received Message Processing

An active LLDP agent must process LLDP messages received on each appropriate port, as such messages arrive. Before LLDP specific receive rules are executed, the frame is subject to the receive processing rules of Slow Protocols defined in Std 802.3, 2000 Edition, Annex 43B.

The following sections refer to the reception of a single LLDP message, for the indicated physical interface contained in the local system:

Header Fields

The LLDP message and the chassis/port indices associated with the receiving port are retrieved.

The LLDP version and flags field are checked. The version should equal one (0x01) and the flags should equal zero (0x00). If not, the LLDPStatsInErrors counter for the receiving port is incremented and processing is terminated; otherwise continue.

TLVs

The TLV portion of the message is decoded. If this portion of the LLDP message is not properly encoded, as defined above, then the LLDPStatsInErrors counter for the receiving port is incremented, and processing is terminated; otherwise continue.

The list of TLV elements is examined. The agent must skip and ignore PDU data elements unknown to the agent. If any of the mandatory data elements are missing, then the LLDPStatsInErrors counter for the receiving port is incremented, and processing is terminated; otherwise continue.

The LLDPStatsInGoodPkts counter is incremented for the receiving port.

PTOPO MIB Update

If the time-to-live field in the LLDP message header is zero then execute this interface shutdown procedure, described below. Processing of the LLDP message is now complete.

If the time-to-live field is non-zero, then the appropriate ptopoConnEntry is found or created, based on the data elements included in the LLDP message. If the indicated entry is dynamic (i.e., ptopoConnIsStatic is true), then the current sysUpTime value is stored in the ptopoConnLastVerifyTime field for the entry.

If a ptopoConnEntry of one type was replaced with an entry of a different type, then the ptopoConnTabReplaces counter is incremented.

If any ptopoConnEntry was added or deleted, or if information other than the ptopoConnLastVerifyTime changed for any entry due to the processing of this LLDP message, then the ptopoLastChangeTime object is set with the current sysUpTime, and a ptopoConfigChange trap event is generated.

Interface Shutdown Procedure

A special procedure exists for the case in which a LLDP agent knows a particular port is about to become non-operational.

Note that the LLDPSuppressTable has precedence over these procedures, and they are only executed if the indicated interface is not specified in the LLDPSuppressTable.

If any entries are deleted as a result of these procedures, the ptopoConnTabDeletes counter is incremented for each deleted entry.

LLDP Shutdown Transmission

In the event an interface, currently configured with LLDP message transmission enabled, either becomes disabled for LLDP activity, or the interface is administratively disabled, a final LLDP message is transmitted with a time to live value of zero (before the interface is disabled).

In the event the LLDPOperStatus is transitioning to the disabled state, then this shutdown procedure should be executed for all local interfaces.

LLDP Shutdown Reception

After reception of a valid LLDP message with a time-to-live value equal to zero, the LLDP Agent must remove all information in the PTOPO MIB learned from the particular LLDP agent, which is associated with the indicated remote connection endpoint.

References

[1] https://www.ieee802.org/1/files/public/docs2002/lldp-protocol-00.pdf