EE Times - Tutorial on the Link Layer Discovery Protocol
http://www.eetimes.com/document.asp?doc_id=1272069&print=yes
Design How-To
Tutorial on the Link Layer Discovery Protocol Manikantan Srinivasan, Net-O2 Technologies 2/1/2005 10:00 AM EST 1 Comment Tweet
0
Share
The harmonious operation of the various networking devices in a LAN requires correct and valid configuration of the protocols and applications that are enabled in these devices. As the numbers and type of devices enabled in a LAN steadily increase, it is difficult for a network or IT manager to statically monitor and configure each device on a network. At the same time, it takes IT managers a significant amount of time to find and rectify configuration problems. An emerging standard, dubbed the IEEE 802.1AB Link Layer Discovery Protocol (LLDP), provides a solution for the configuration issues caused by expanding LANs. This article describes the motivation for LLDP, some sample misconfiguration scenarios, and details the various aspects of LLDP. VLAN Misconfiguration Examples VLANs enable a LAN to be partitioned based on functional requirements while maintaining connectivity across all devices on the network. A set of devices that are part of an IP subnet must belong to one particular VLAN. The ports that form part of the same VLAN are assigned to the same permanent VLAN identifier (PVID). Untagged data packets (i.e. packets that do not carry a VLAN identifier as part of the Ethernet header) received at a networking device port are associated with the VLAN identified by the received port's PVID. The PVID value is significant to the local system. If ports that belong to a VLAN are not assigned the same PVID, data exchange across VLANs suffers. Figure 1 shows a sample misconfigured VLAN. Data packet originated from H1 (to H4) received at Port I1of Switch S1 is associated with VLAN 3. The data is forwarded on Port I2 of Switch S1 as an untagged packet. When the data packet is received at Port I1of Switch S2, it is associated with VLAN 4. The data is not forwarded further by Switch S2 causing a disruption in connectivity.
1 of 7
2/2/2014 11:27 AM
EE Times - Tutorial on the Link Layer Discovery Protocol
http://www.eetimes.com/document.asp?doc_id=1272069&print=yes
Figure 1: Sample LAN with misconfigured devices. Misconfiguration can also occur in port- and protocol-based VLAN (PPVLAN) architectures. PPVLANs enable untagged packets received at a port to be associated with different VLANs. The VLAN classification is based on the packet encapsulation type (frame header) and the protocol type of the data carried in the packet. Potentially there can be many VLANs that are classified based on the port and protocol group combination. An administrator configuring PPVLANs in a networking device must be aware of the classification configured in the other networking devices in the LAN. A consistent classification is required across the LAN to enable a continuous VLAN. It is a challenge to an administrator to be aware of PPVLAN configurations in other devices before configuring a particular device. Link Aggregation Misconfiguration Examples Aggregation of links to enable higher bandwidth data paths is a common design in today's network deployments. The links are aggregated either statically or dynamically. Static aggregation of links can cause potential configuration issues. A device may consider a set of links as aggregated while its partner device at the other end of the aggregated link may not consider them as aggregated. The link aggregation control protocol (IEEE 802.3-2002 Clause 43) enables dynamic aggregation of links. LACP may not enable the expected link aggregation, if the required link aggregation parameters are misconfigured. Solution for Consistent Configuration Devices in a LAN maintain their operation related configuration information in the form of management information bases (MIBs) that are typically accessible via SNMP. By enabling devices in a LAN to become aware of other devices' configuration information, misconfiguration problems can be avoided. When two devices discover that they are misconfigured, the misconfiguration can be rectified using suitable applications. LLDP enables devices in a LAN to exchange their configured information. The method used by applications to resolve a configuration mismatch is not covered by LLDP and is implementation specific. Let's take a closer look at LLDP. LLDP Agent A LAN device that implements LLDP supports an LLDP agent. The LLDP agent architecture is described easily in terms of SNMP MIBs (Figure 2). The local LAN device's information
2 of 7
2/2/2014 11:27 AM
EE Times - Tutorial on the Link Layer Discovery Protocol
http://www.eetimes.com/document.asp?doc_id=1272069&print=yes
transmitted by an LLDP agent is stored in the LLDP local system MIB. In case the local LAN device transmits any organization specific information in the form of type, length and value (TLV), the organization-associated values are stored in LLDP's organizationally defined local device LLDP MIB extensions.
Figure 2: LLDP agent block diagram. Currently, LLDP data units (LLDPDUs) carry IEEE 802.1 and 802.3 related information in the organizationally defined TLVs. In a local device, the information related to other devices are known as remote system information. The LLDP MIB maintains the remote system's LLDP specific information. Organizationally defined remote device LLDP MIB extensions maintain the remote system's organization specific protocol information, which includes remote system's associated 802.1 and 802.3 protocol information. Though the LLDP architecture is based on SNMP and MIBs, an LLDP implementation is not required to support SNMP for storage and retrieval of the system data. The information conveyed as part of LLDPDUs are derived from other standard MIBs supported in a device such as: The Physical Topology (PTOPO) MIB (RFC 2922) The Entity MIB (RFC 2737) The Interfaces MIB (RFC 2863) Power Ethernet MIB (RFC 3621) Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) (RFC 3636) Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions (RFC 2674) LLDP Agent Operation An LLDP agent operates in any one of the following three modes: 1. Transmit-only mode: The agent can only transmit the information about the capabilities and the current status of the local system. 2. Receive-only mode: The agent can only receive information about the capabilities and the current status of the remote systems. 3. Transmit and receive mode: The agent can transmit the local system capabilities and status information and receive remote system's capabilities and status information. LLDP agent operation is typically implemented as two modules: the LLDP transmit module and LLDP receive module. While it is not mandatory to implement two separate modules, the
3 of 7
2/2/2014 11:27 AM
EE Times - Tutorial on the Link Layer Discovery Protocol
http://www.eetimes.com/document.asp?doc_id=1272069&print=yes
two-module approach is recommended as part of the standard. The LLDP transmit module, when enabled, sends the local device's information at regular intervals. The information is transmitted using appropriate TLVs. Whenever the transmit module is disabled, it transmits an LLDPDU with a time-to-live (TTL) TLV containing "0" in the information field. This enables the remote devices to remove the information associated with this local device in their databases. The LLDP receive module, when enabled, receives the remote device's information and updates the remote system's LLDP MIB database. When new information or updated information is received, the receive module initiates a timer for the valid duration indicated by the TTL TLV in the received LLDPDU. The remote system's information is removed from the database when an LLDPDU is received with TTL TLV containing "0" in its information field. A device might have limited database space to maintain its neighbor information. This occurs when a device has a large number of neighbors. The mechanism to remove old neighbor information from the MIB database and update new neighbor information is implementation specific. Transmission, Reception and Structure Details LLDP operates in a one-way direction. Thus, information in LLDPDUs flows from one device to another. LLDPDUs are not exchanged as information requests by one device and response sent by another device. The other devices do not acknowledge LLDP information received from a device. LLDP information associated with a device is identified with the device's media service access point (MSAP) identifier. LLDPDUs are transmitted and received using the support provided by LLDP/LSAP and LLC in a device. An LLDPDU is identified based on the Ethertype (Hexa-decimal 88-CC) value carried in the MAC header. LLDPDUs are transmitted with a multicast destination address specially identified for LLDPDU. The LLDP_Multicast address is 01-80-C2-00-00-OE. LLDPDUs carry information in the form of short variable-length information elements. Each of these elements (TLVs) contains type, length and value fields. Type identifies the kind of information, length identifies the length of the information in octets, and value contains the actual information. Each LLDPDU contains four mandatory TLVs and optional TLVs as determined by the LLDP agent that originates the LLDPDU (Figure 3). The mandatory TLV's information contains the LAN device's MSAP identifier and the time period for the validity of the LAN device's associated information. The mandatory TLVs contained in a LLDPDU are: Chassis ID TLV: Identifies the 802 LAN device's chassis. This forms the chassis component of the LAN device's MSAP identifier. PortID TLV: Identifies the port from which the LLDPDU is transmitted. This forms the port component of the LAN device's MSAP identifier. TTL TLV: Indicates how long (in seconds) the LAN device's information received in the LLDPDU is to be treated as valid information. Non-zero information indicates the device's information is to be updated in the LLDP remote system MIB. A value of 0 indicates the information associated with the LAN device is no longer valid and should be removed from the MIB. End of LLDPDU TLV: Indicates the end of TLVs in the LLDPDU.
4 of 7
2/2/2014 11:27 AM
EE Times - Tutorial on the Link Layer Discovery Protocol
http://www.eetimes.com/document.asp?doc_id=1272069&print=yes
Figure 3: LLDPDU structure and key LLDPDU TLV formats. In an LLDPDU, the chassis ID, port ID, and TTL TLV are the first three TLVs. The optional TLVs are placed after the TTL TLV. The end of LLDPDU TLV is placed last. Figure 3 above provides the LLDPDU structure and the mandatory LLDPDU TLV structure details. Refer 1
802.1AB for other TLV structure details.
Optional TLVs The optional TLVs defined as part of LLDP are grouped into the following three sets: Basic Management TLV Set This set includes the following five TLVs: 1. Port description TLV: Provides a description of the port in an alpha-numeric format. The value equals the ifDescr object, if the LAN device supports RFC 2863. 2. System name TLV: Provides the system's assigned name in an alpha-numeric format. The value equals the sysName object, if the LAN device supports RFC 3418. 3. System description TLV: Provides a description of the network entity in an alphanumeric format. This includes system's name and versions of hardware, operating system and networking software supported in the device. The value equals the sysDescr object, if the LAN device supports RFC 3418. 4. System capabilities TLV: Indicates the primary function(s) of the device and whether or
5 of 7
2/2/2014 11:27 AM
EE Times - Tutorial on the Link Layer Discovery Protocol
http://www.eetimes.com/document.asp?doc_id=1272069&print=yes
not these functions are enabled in the device. The capabilities are indicated by two octects. Bits 0 through 7 indicate Other, Repeater, Bridge, WLAN AP, Router, Telephone, DOCSIS cable device and Station respectively. Bits 8 through 15 are reserved. 5. Management address TLV: Indicates the addresses of the local LLDP agent. Other remote managers can use this address to obtain information related to the local device. IEEE 802.1 Organizationally Specific TLV Set This group includes the following four TLVs: 1. Port VLANID TLV: Indicates the PVID that will be associated with an untagged or priority tagged data frame received on the VLAN port. 2. PPVLAN ID TLV: Indicates the PPVID that will be associated with an untagged or priority tagged data frame received on the VLAN port. The TLV supports a "flags" field, which indicates whether the port is capable of supporting port and protocol based VLANs and whether one or more PPVLANs are enabled. The number of PPVLAN ID TLVs in a LLDPDU corresponds to the number of the PPVLANs enabled at the port. 3. VLAN name TLV: Indicates the assigned name of any VLAN at the device. The value equals the dot1QVLANStaticName object, if the LAN device supports RFC 2674. The number of VLAN name TLVs in a LLDPDU corresponds to the number of VLANs enabled at the port. 4. Protocol identity TLV: Indicates the set of protocols that are accessible at the device's port. The protocol identity field in the TLV contains n octets after the layer 2 address that can enable the receiving device to recognize the protocol. For example, a device that wishes to advertise spanning tree protocols will include at least eight octets: 802.3 length (two octets), LLC addresses (two octets), 802.3 control (one octet), protocol ID (two octets), and the protocol version (one octet). IEEE 802.3 Organizationally Specific TLV Set This set includes the following four TLVs: 1. MAC/PHY configuration/status TLV: Indicates duplex and bit rate capability and the current duplex and bit rate settings of the sending device. It also indicates whether the current settings are due to auto-negotiation or due to manual configuration. 2. Power via media dependent interface (MDI) TLV: Indicates the power support capabilities of the LAN device. 3. Link aggregation TLV: Indicates whether the link (associated with the port on which the LLDPDU is transmitted) can be aggregated. It also indicates whether the link is currently aggregated and provides the aggregated port identifier if the link is aggregated. 4. Maximum frame size TLV: Indicates the maximum frame size capability of the devices MAC and PHY implementation. LLDP Application Examples 1. Use of VLAN ID TLV: Assume the switches S1 and S2 in Figure 1 support LLDP and have the ability to send organizational specific TLVs. S1 will send in its LLDPDU, a VLAN ID TLV with value 3 because VLAN 3 is associated with the Port I2. S2 will send in its LLDPDU, a VLAN ID TLV with value 4 because VLAN 4 is associated with the Port I1. The switches can now recognize a misconfiguration. With a suitable management application, either switch S1 or S2 can now reconfigure their VLAN. 2. LLDP-MED: The Telecommunication Industry Association (TIA) is currently working on extending LLDP for supporting and sharing information between media devices. Today's networks support many VoIP devices such as IP telephone, media gateways, and media servers. VoIP-related extensions to LLDP known as LLDP — Media Endpoint Discovery 2
(LLDP-MED) enables media devices to transmit and receive media related information.
6 of 7
2/2/2014 11:27 AM
EE Times - Tutorial on the Link Layer Discovery Protocol
http://www.eetimes.com/document.asp?doc_id=1272069&print=yes
In addition to expanding the LLDP TLVs, LLDP-MED requires certain optional LLDP TLVs to be transmitted as mandatory information by media endpoints. One such TLV is MAC/PHY configuration/status TLV. In addition to these changes, LLDP-MED has extended some of the LLDP TLVs for carrying additional information. One such TLV is power via MDI TLV. LLDP-MED is in the early stages of its development. Wrap Up LANs currently support a high density of devices with multiple applications. A harmonious operation among these devices require correct configuration of their supporting protocols. LLDP from IEEE enables LAN devices to inform each other about their configurations. A misconfiguration can be easily detected and with suitable configuration management can be rectified. LLDP, currently a draft standard (Draft 13), is expected to become an IEEE ratified standard. LLDP-MED from TIA is an extension to LLDP, designed for effective and easier VoIP deployments. LLDP-MED is an example that demonstrates the versatility of LLDP architecture and the ability to easily apply LLDP. References 1. Draft Standard for Local and Metropolitan Networks: Station and Media Access Control Connectivity Discovery, IEEE P802.1AB/D13, December, 2004. 2. LLDP Media Endpoint Discovery — Draft v2004-02, TR41.4-04-11-009, TIA ENGINEERING SUBCOMMITTEE, TR 41 CONTRIBUTION, 29 October, 2004. About the Author Manikantan Srinivasan is the engineering manager at Net-O2 Technologies. He has an ME (Computer Science & Engineering) from the Indian Institute of Science, Bangalore, India and a B.Sc in Physics and Electronics from the University of Bangalore, India. Manikantan can be reached at
[email protected]. EMAIL THIS PRINT COMMENT
More Related Links China Bets on Homegrown OS Qualcomm Beats Its Own Expectation in Q413 Earnings Lenovo Snags Motorola for $2.9B Tablet Growth Slowing, Says IDC Slideshow: Facebook Drives Open Hardware Copyright © 2014 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service
7 of 7
2/2/2014 11:27 AM
