 |
|
|
|
The goal of this application note is to present the LLDP and LLDP-MED protocols, their history, their structure, their
usage and their implementation on ProCurve switches and on the IP phones of the most known telephony vendors.
» Return to top
|
|
|
|
|
|
LLDP is a vendor-neutral layer 2 protocol. A device on a LAN segment employs LLDP to advertise its identity and
capabilities, and it also receives this layer 2 information from other devices. LLDP is ideal for use in a multi-vendor
environment.
2.1 History of LLDP
Before LLDP, several proprietary discovery protocols existed: Cisco Discovery Protocol (CDP), Nortel Discovery
Protocol, Foundry Discovery Protocol, etc. None of these protocols could interoperate with any others.
In 1996, an IETF working group (PTOPO MIB, the Physical Topology MIB Working Group) addressed this problem, focusing on creating a common framework and model for describing physical topology. They completed an informational MIB (RFC 2922, Physical Topology MIB, published Sept 2000), but didn’t progress to the discovery protocol.
The subject resurfaced at the IEEE in January 2002. Driven largely by Paul Congdon (ProCurve/HP), research resumed where the IETF effort had left off. Finally, in 2005, IEEE 802.1AB, the Link Layer Discovery Protocol (LLDP), was ratified. This was followed by draft 802.3at, an extension for L2 power classification for Power over Ethernet.
ProCurve was the first in the industry to support LLDP and now supports this protocol on the vast majority of our networking products.
» Return to top
2.2 How does LLDP work?
LLDP defines a standard method for Ethernet network devices such as switches, routers, wireless LAN access points
and other devices such as IP phones to advertise information about themselves to other nodes on the network and
store the information they discover. Details such as device configuration, device capabilities and device identification
can be advertised using this protocol.
Figure 1. LLDP gives all devices on the network a common language for identifying and transmitting information about themselves
LLDP is a one-way neighbor discovery protocol with periodic transmissions. LLDP frames are not forwarded, but constrained to a single link. These frames contain formatted TLVs (type length values) which carry a variety of information:
- Globally unique system and port identification
- Time-to-Live information for aging purposes
- Optional system capabilities (e.g., router, IP phone, wireless AP)
- Optional system name and description
- Optional management address (both IPv4 and IPv6)
- Organizational extensions
The receiver stores information in an SNMP management information base (MIB), and the receiver ages the MIB to
ensure only valid network data is available. Management applications can harness the power of LLDP via this SNMP
database.
Each LLDP-enabled device contains one or several LLDP agents. An LLDP agent consists of:
- An LLDP state machine, which controls Tx and Rx of frames and contains state machine control variables.
- Local MIB, which holds locally configured data; data may also be supplied or modified by management applications.
- Remote MIBs, which hold and age data received from the far end, and which are available for management applications use.
Figure 2. SNMP management information bases (MIBs) hold information about network devices
The LLDP agent interferes with entity MIBs, which are not directly part of LLDP.
» Return to top
2.3 The LLDP frame
An LLDP frame contains the LLDP multicast address (6 bytes: 01-80-C2-00-00-0E) as the destination address, the
MAC address (6 bytes), the LLDP Ethertype (2 bytes), the LLDPU (data + padding) and FCS.
The LLDPU field contains the TLVs: Chassis ID, port ID, TTL, etc.
Figure 3. LLDP frame format and LLDPDU format
» Return to top
2.4 Main applications of LLDP
LLDP is primarily used for:
- Network management: LLDP simplifies and enhances the ability of network management tools in multivendor environments. LLDP enables discovery of accurate physical network topologies, even in a multi-VLAN environment. And LLDP ensures proper aging, so only valid network device data is presented.
- Network inventory: LLDP is able to get information about the system name, system description (device full name, firmware version, operating system), system capabilities (e.g., switch, router, access point), and management address.
- Network troubleshooting: An accurate topology simplifies troubleshooting of enterprise networks. LLDP works at Layer 2, so it can discover devices with misconfigured or unreachable IP addresses, and (with IEEE 802.3 extension) detect speed and duplex mismatches.
» Return to top
|
|
|
|
|
|
LLDP-MED is an extension to LLDP that allows discovery of devices such as IP telephones. It is especially useful in
converged networks by providing policy, power, location and inventory data.
3.1 History of LLDP-MED
While LLDP can provide base discovery capabilities, it is not adequate for use by IP telephony and video. These devices require a protocol that offers features such as plug-and-play provisioning, simplified management and accurate network topology, precise device tracking for use by Emergency Call Service, and rapid identification and troubleshooting of call quality issues. VoIP, moreover, needs specific inventory management. Another challenge is that the protocol must allow IP telephony systems from different vendors to interoperate on one network.
In early 2004, ProCurve approached Mitel and several other leading vendors to extend LLDP to address these additional needs. In April, 2006, the TIA (Telecommunications Industry Association) standard, co-authored by Mitel, ProCurve, Avaya and Enterasys, was selected and published as ANSI/TIA-1057. ProCurve was the first in the industry to support LLDP-MED, followed by a majority of the other network industry players, including Avaya, Extreme, Mitel, Shoretel, Foundry, Nortel and 3Com.
According to Paul Congdon, ProCurve Chief Technology Officer and HP Fellow, "The LLDP-MED standard is an important milestone toward simplifying the deployment and management of multi-vendor VoIP environments. This supports our long-standing belief that networks should be based on open industry standards — to enable the market and give customers the choice to select best-in-breed solutions. There should be no proprietary restrictions."
» Return to top
3.2 Structure of the LLDP-MED protocol
The LLDP-MED frame contains several types of TLV entries, including civic address location ID, network policy and
extended power-via-MDI. Figure 4 shows a typical TLV, this one for LLDP-MED location.
Figure 4. LLDP-MED location TLV
The location format can be a civic address or an ELIN (Emergency Line Information Number, a specific callback
number that represents an area in an multiline telephone system).
» Return to top
3.3 Benefits of using LLDP-MED
In a converged network, LLDP-MED provides the following benefits:
- Interoperability: LLDP-MED offers vendor-independent management capabilities, enabling different convergence endpoints to interoperate on one network.
- Automatic deployment of network policies: With LLDP-MED, administrators can automatically deploy voice or video VLAN, Layer 2, and Layer 3 QoS policies.
- Location services: LLDP-MED allows deploying location services, including Emergency Call Service (ECS).
- Detailed inventory management capabilities: For each converged device, LLDP-MED can supply model, manufacturer, firmware and asset information.
- Advanced PoE: LLDP-MED enables advanced Power over Ethernet capabilities, including fine-grained power management.
- IP telephony network troubleshooting: LLDP-MED enables detection of speed and duplex mismatches, and of improper static voice policy configurations.
- More security: LLDP-MED runs after 802.1X, to prevent unauthenticated devices from gaining access to the network.
» Return to top
|
|
|
|
|
|
This illustrates commands for configuring LLDP and LLDP-MED on ProCurve switches.
4.1 Start and stop LLDP-MED
The voice command enables LLDP-MED on a particular VLAN. For example:
To start or stop LLDP globally on the device:
LLDP is enabled by default.
4.2 Enable notifications
To enable notifications on a port:
Where X represents the port number.
To enable LLDP-MED topology change notification:
Where X represents the port.
» Return to top
4.3 Advertise TLVs
To configure the TLVs to be advertised, specify a port number for configuration, followed by a configuration command:
Among the MED TLV list you can advertise the following TLVs:
- Capabilities: This TLV enables the switch to determine which LLDP-MED TLVs can be discovered by a connected endpoint, and the device class (1, 2, or 3) for the connected endpoint.
This TLV also enables an LLDP-MED endpoint to discover what LLDP-MED TLVs the switch port currently supports.
- Network_policy: This TLV enables the switch port to advertise its configured network policies (voice VLAN, layer 2 QoS, and layer 3 QoS), and allows LLDP-MED endpoint devices to auto-configure the voice network policy advertised by the switch. This also enables the use of SNMP applications to troubleshoot statically configured endpoint network policy mismatches.
Network policy is only advertised for ports that are configured as members of the voice VLAN.
- Location_id: This TLV enables the switch port to advertise its configured location data (if any). Location can be written in 3 formats:
- Civic: Physical data such as city, street, building.
- ELIN: North American emergency number.
- Coordinate-based location: Location (altitude, longitude, latitude) configured by an SNMP application.
- PoE: This TLV enables the switch port to advertise its current PoE (Power over Ethernet) state and to read the PoE requirements advertised by the LLDP-MED endpoint device connected to the port. It includes the following data:
- Power type: Power-sourcing entity (PSE) or powered device (PD).
- Power source: PSE, local, or PSE/local.
- Power priority: Priority configured on the switch port or on the MED endpoint.
- Power value: Total power (in watts) that the switch port can deliver or that the MED endpoint requires.
» Return to top
4.4 View power data
To view the current power data for a LLDP-MED device:
» Return to top
4.5 Perform fine-grained power management
LLDP-MED allows fine-grained power-management. To control Power-over-Ethernet allocation, three methods exist: default, by class, and by value.
Power allocation by usage: Usage is the default method. By default, a device allocated to a switch port is allocated 17 watts of power.
Power allocation by class: Class is an option that enables setting the power allocated to a port to the maximum power for the class. This option uses the power ramp-up signature of the PD to identify its class.
For example, to allocate power by class for ports A6 -A8:
Power allocation by value: The value option enables manually specifying the power level for a port, from 1 watt to 17 watts, in 1-watt increments. For example:
Or in interface context:
On ProCurve ProVision switches (3500yl, 5400zl, 8212zl), LLDP-MED can be used to allocate just the right amount of
power necessary for the media endpoint. When LLDP is enabled, the information about the power usage of the
powered device is available and the switch can then comply with or ignore this information. The default configuration
is for PoE information to be ignored if detected through LLDP.
To enable LLDP detection, use the command poe-lldp-detect. For example:
Or in interface context:
» Return to top
|
|
|
|
|
|
LLDP-MED-enabled devices can be classified in three groups, called classes:
Class 1 (generic endpoint devices): These devices offer the basic LLDP discovery services, network policy advertisement (VLAN ID, Layer 2/802.1p priority, and Layer 3/DSCP priority), and PoE management. This class includes devices such as IP call controllers and communication-related servers.
Class 2 (media endpoint devices): These devices offer all Class 1 features, plus media streaming capability. They include devices such as voice/media gateways, conference bridges, and media servers.
Class 3 (communication devices): These devices are typically IP phones or end-user devices that otherwise support IP media. They offer all Class 1 and Class 2 features, plus location identification and emergency 911 capability, layer 2 switch support, and device information management.
Some examples of telephony vendors who support LLDP-MED include:
- Cisco: LLDP-MED is supported in the following models since release 8.3(3): 7906G, 7911G, 7931G, 7941G/7941G-GE, 7942G, 7945G, 7961G/7961G-GE, 7962G, 7965G, 7970G/7971G-GE, and 7975G.
- Avaya: LLDP-MED is supported on 9600 and 4600 series.
- Mitel: LLDP-MED is supported on all IP phones since ICP release 7.0 (release 2.0.0.19 for phones).
- Nortel: LLDP-MED is supported on Models i2001, i2002, i2004, i2007, 1120E, and 1140E.
- Aastra: Models 53i, 55i, 57i should officially support LLDP-MED in Autumn 2008. (Beta versions of these models have already been tested on ProCurve switches.)
» Return to top
|
|
|
