title: Link Layer Discovery Protocol
text: # Link Layer Discovery Protocol
  
  The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link layer protocol used by network devices for advertising their identity, capabilities, and neighbors on a local area network based on IEEE 802 technology, principally wired Ethernet. The protocol is formally referred to by the IEEE as Station and Media Access Control Connectivity Discovery specified in IEEE 802.1AB with additional support in IEEE 802.3 section 6 clause 79.
  
  LLDP performs functions similar to several proprietary protocols, such as Cisco Discovery Protocol, Foundry Discovery Protocol, Nortel Discovery Protocol and Link Layer Topology Discovery.
  
  ## Information gathered
  
  Information gathered with LLDP can be stored in the device management information base (MIB) and queried with the Simple Network Management Protocol (SNMP) as specified in RFC 2922. The topology of an LLDP-enabled network can be discovered by crawling the hosts and querying this database. Information that may be retrieved include:
  
  * System name and description
  * Port name and description
  * VLAN name
  * IP management address
  * System capabilities (switching, routing, etc.)
  * MAC/PHY information
  * MDI power
  * Link aggregation
  
  ## Applications
  
  The Link Layer Discovery Protocol may be used as a component in network management and network monitoring applications.
  
  One such example is its use in data center bridging requirements. The Data Center Bridging Capabilities Exchange Protocol (DCBX) is a discovery and capability exchange protocol that is used for conveying capabilities and configuration of the above features between neighbors to ensure consistent configuration across the network.
  
  LLDP is used to advertise power over Ethernet capabilities and requirements and negotiate power delivery.
  
  ### Media endpoint discovery extension
  
  Media Endpoint Discovery is an enhancement of LLDP, known as LLDP-MED, that provides the following facilities:
  
  * Auto-discovery of LAN policies (such as VLAN, Layer 2 Priority and Differentiated services (Diffserv) settings) enabling plug and play networking.
  * Device location discovery to allow creation of location databases and, in the case of Voice over Internet Protocol (VoIP), Enhanced 911 services.
  * Extended and automated power management of Power over Ethernet (PoE) end points.
  * Inventory management, allowing network administrators to track their network devices, and determine their characteristics (manufacturer, software and hardware versions, serial or asset number).
  
  The LLDP-MED protocol extension was formally approved and published as the standard ANSI/TIA-1057 by the Telecommunications Industry Association (TIA) in April 2006.
  
  ## System Capability Codes
  
  | Code | Capability |
  | - | - |
  | B | Bridge (Switch) |
  | C | DOCSIS Cable Device |
  | O | Other |
  | P | Repeater |
  | R | Router |
  | S | Station |
  | T | Telephone |
  | W | WLAN Access Point |
  
  ## Frame structure
  
  LLDP information is sent by devices from each of their interfaces at a fixed interval, in the form of an Ethernet frame. Each frame contains one LLDP Data Unit (LLDPDU). Each LLDPDU is a sequence of type–length–value (TLV) structures.
  
  The Ethernet frame used in LLDP typically has its destination MAC address set to a special multicast address that 802.1D-compliant bridges do not forward. Other multicast and unicast destination addresses are permitted. The EtherType field is set to 0x88cc.
  
  Each LLDP frame starts with the following mandatory TLVs: Chassis ID, Port ID, and Time-to-Live. The mandatory TLVs are followed by any number of optional TLVs. The frame optionally ends with a special TLV, named end of LLDPDU in which both the type and length fields are 0.
  
  Accordingly, an Ethernet frame containing an LLDPDU has the following structure:
  
  LLDP Ethernet frame structure :
  
  | Preamble | Destination MAC | Source MAC | Ethertype | Chassis ID TLV | Port ID TLV | Time to live TLV | Optional TLVs | Optional End of LLDPDU TLV | Frame check sequence |
  | - | - | - | - | - | - | - | - | - | - |
  | | 01:80:c2:00:00:0e, or 01:80:c2:00:00:03, or 01:80:c2:00:00:00 | Station's address | 0x88CC | Type=1 | Type=2 | Type=3 | Zero or more complete TLVs | Type=0, Length=0 | |
  
  Each of the TLV components has the following basic structure:
  
  TLV structure :
  
  | Type | Length | Value |
  | - | - | - |
  | 7 bits | 9 bits | 0-511 octets |
  
  TLV type values :
  
  | TLV type | TLV name | Usage in LLDPDU |
  | - | - | - |
  | 0 | End of LLDPDU | Optional |
  | 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 |
  | 9–126 | Reserved | - |
  | 127 | Custom TLVs | Optional |
  
  Custom TLVs are supported via a TLV type 127. The value of a custom TLV starts with a 24-bit organizationally unique identifier and a 1 byte organizationally specific subtype followed by data. The basic format for an organizationally specific TLV is shown below:
  
  Organizationally specific TLV :
  
  | Type | Length | Organizationally unique identifier (OUI) | Organizationally defined subtype | Organizationally defined information string |
  | - | - | - | - | - |
  | 7 bits—127 | 9 bits | 24 bits | 8 bits | 0-507 octets |
  
  According to IEEE Std 802.1AB, §9.6.1.3, "The Organizationally Unique Identifier shall contain the organization's OUI as defined in IEEE Std 802-2001." Each organization is responsible for managing their subtypes.
  
  