LLDP-MED is, as the name suggests, based on the Link Layer Discovery Protocol or LLDP; LLDP-MED is a refinement aimed specifically at dealing with some of the issues that arise in VOIP.
LLDP-MED is a protocol used to communicate between switch ports and endpoint devices, and as the variety of endpoints grows in IP networks--thanks primarily to VOIP, video, and all the usage scenarios that these media bring--LLDP-MED will be an important way for the network to keep track of endpoints and treat different endpoints in appropriate ways depending on what the endpoint is and does. (You can find a PDF of the full standard here.)
The final standard is actually more than 2 years old, but it's just now getting more attention. With IP voice and video at small scale in most rollouts, there wasn't a strong need to automate the treatment of endpoints, but the benefit becomes clearer when you're dealing with tens or hundreds of thousands of endpoints.
Manfred Arndt explained that LLDP-MED provides for auto-provisioning phones such that they are automatically placed in the voice VLAN when connected to the network; they also are configured with the correct QOS tagging and location information for E-911 purposes.
In addition, LLDP-MED will have a role to play as network managers begin to take a more refined, granular approach to powering the network. LLDP-MED allows for negotiation with the PoE source such that the PoE source delivers just how much power the phone needs; under the 802.3af PoE standard, a PoE source can deliver either 4, 7 or 15 Watts, so if a device requires more than 7 Watts but less than 15 Watts, it still has to draw the full 15 Watts; according to Manfred Arndt, ProCurve (and presumably other vendors) will be able to deliver LLDP-MED-based powering control such that, if a phone requires 7.5 Watts, the system can deliver 7.5 Watts.
A couple of other parts of the standard seemed noteworthy to me:
Endpoint Move Detection Notification
Endpoint move detection notification enables Network Connectivity Devices [i.e., switches, etc.] to efficiently notify their associated VoIP management application(s) of VoIP device moves, using SNMP or similar means. ... In a VoIP environment, the procedure for endpoint move detection is often based upon an SNMP management application, or similar, periodically polling the network connectivity devices. LinkUp and LinkDown notifications from the network devices [i.e., endpoints] are used to improve the performance of the database updates, by letting the management application know proactively about endpoint moves and changes.However; a large portion of LinkUp/LinkDown and similar notifications can be due to endpoint system reboots or power failures where the endpoint port location did not actually change. Also, many LinkUp/LinkDown notifications may not be related to any endpoint involved in the VoIP system (e.g. may be a printer, PC, etc), hence may not be of any direct interest to the VoIP management application. Even though the endpoint port location did not change, the VoIP management application must respond to the link state notification events from the network device, triggered due to a temporary link loss, and poll the network device to check for location change.
The LLDP-MED mechanism provided in this Standard allows for significantly reduced overhead in device move tracking by providing VoIP-device-specific information only to the VoIP management application, and by providing key information in the notification itself. (Note however that this mechanism cannot entirely eliminate the need for periodic polling the of network connectivity devices, to audit current information, due to the non-guaranteed delivery properties of UDP, generally used as the transport for SNMP.)
However; a large portion of LinkUp/LinkDown and similar notifications can be due to endpoint system reboots or power failures where the endpoint port location did not actually change. Also, many LinkUp/LinkDown notifications may not be related to any endpoint involved in the VoIP system (e.g. may be a printer, PC, etc), hence may not be of any direct interest to the VoIP management application. Even though the endpoint port location did not change, the VoIP management application must respond to the link state notification events from the network device, triggered due to a temporary link loss, and poll the network device to check for location change.
The LLDP-MED mechanism provided in this Standard allows for significantly reduced overhead in device move tracking by providing VoIP-device-specific information only to the VoIP management application, and by providing key information in the notification itself. (Note however that this mechanism cannot entirely eliminate the need for periodic polling the of network connectivity devices, to audit current information, due to the non-guaranteed delivery properties of UDP, generally used as the transport for SNMP.)
And here's the section on power:
Extended Power Via MDI Discovery
Extended Power Via MDI Discovery enables detailed power information to be advertised by Media Endpoints and Network Connectivity Devices. Information provided from the Endpoint Device to the Network Connectivity Device includes:Endpoint Device power requirement, in fractions of Watts, in current configuration; The Endpoint Device's power priority (which the Network Connectivity Device may use to prioritize which devices will remain in service during power shortages); Whether or not the Endpoint is currently operating from an external power source. Information provided from the Network Connectivity Device to the Endpoint Device includes:
Power availability from the Network Connectivity Device, in fractions of Watts; Current power state of the Network Connectivity Device, including whether it is currently operating from primary power or is on backup power (backup power may indicate to the Endpoint Device that it should move to a power conservation mode).
Another key section will be more important as enterprises roll out IPT more widely, and as, over time, those deployments inevitably become more diverse than the homogenous environment that may exist in limited pilots:
Inventory Management Discovery
Inventory Management Discovery enables tracking and identification of endpoint inventory-related attributes such as manufacturer, model, software version and other pertinent information. The information advertised by the Endpoint is based on the IETF Entity MIB, RFC 2737 [20].[The LLDP-MED specs] provide a way of feeding the Endpoint inventory information to the Network Connectivity Devices, allowing for those to become an on-line repository of basic inventory information for connected VoIP Endpoints, while restricting the need for implementing SNMP agents only to the Network Connectivity Devices [switches,etc.]. This is especially important for inventory management of IP Phones, the majority of which lack support of management protocols such as SNMP, due to cost and complexity pressures that are likely to persist for some time to come. The solution is also more scalable since the management application can receive information from the LLDP-MED MIB in the network Connectivity Device instead of querying SNMP agents in the much larger numbers of Endpoint agents.
Information provided from the Network Connectivity Device to the Endpoint Device includes:
Another key section will be more important as enterprises roll out IPT more widely, and as, over time, those deployments inevitably become more diverse than the homogenous environment that may exist in limited pilots:
Inventory Management Discovery
Inventory Management Discovery enables tracking and identification of endpoint inventory-related attributes such as manufacturer, model, software version and other pertinent information. The information advertised by the Endpoint is based on the IETF Entity MIB, RFC 2737 [20].[The LLDP-MED specs] provide a way of feeding the Endpoint inventory information to the Network Connectivity Devices, allowing for those to become an on-line repository of basic inventory information for connected VoIP Endpoints, while restricting the need for implementing SNMP agents only to the Network Connectivity Devices [switches,etc.]. This is especially important for inventory management of IP Phones, the majority of which lack support of management protocols such as SNMP, due to cost and complexity pressures that are likely to persist for some time to come. The solution is also more scalable since the management application can receive information from the LLDP-MED MIB in the network Connectivity Device instead of querying SNMP agents in the much larger numbers of Endpoint agents.
Information provided from the Network Connectivity Device to the Endpoint Device includes:
Another key section will be more important as enterprises roll out IPT more widely, and as, over time, those deployments inevitably become more diverse than the homogenous environment that may exist in limited pilots:
Inventory Management Discovery
Inventory Management Discovery enables tracking and identification of endpoint inventory-related attributes such as manufacturer, model, software version and other pertinent information. The information advertised by the Endpoint is based on the IETF Entity MIB, RFC 2737 [20].[The LLDP-MED specs] provide a way of feeding the Endpoint inventory information to the Network Connectivity Devices, allowing for those to become an on-line repository of basic inventory information for connected VoIP Endpoints, while restricting the need for implementing SNMP agents only to the Network Connectivity Devices [switches,etc.]. This is especially important for inventory management of IP Phones, the majority of which lack support of management protocols such as SNMP, due to cost and complexity pressures that are likely to persist for some time to come. The solution is also more scalable since the management application can receive information from the LLDP-MED MIB in the network Connectivity Device instead of querying SNMP agents in the much larger numbers of Endpoint agents.
Another key section will be more important as enterprises roll out IPT more widely, and as, over time, those deployments inevitably become more diverse than the homogenous environment that may exist in limited pilots:
Inventory Management Discovery
Inventory Management Discovery enables tracking and identification of endpoint inventory-related attributes such as manufacturer, model, software version and other pertinent information. The information advertised by the Endpoint is based on the IETF Entity MIB, RFC 2737 [20].[The LLDP-MED specs] provide a way of feeding the Endpoint inventory information to the Network Connectivity Devices, allowing for those to become an on-line repository of basic inventory information for connected VoIP Endpoints, while restricting the need for implementing SNMP agents only to the Network Connectivity Devices [switches,etc.]. This is especially important for inventory management of IP Phones, the majority of which lack support of management protocols such as SNMP, due to cost and complexity pressures that are likely to persist for some time to come. The solution is also more scalable since the management application can receive information from the LLDP-MED MIB in the network Connectivity Device instead of querying SNMP agents in the much larger numbers of Endpoint agents.
[The LLDP-MED specs] provide a way of feeding the Endpoint inventory information to the Network Connectivity Devices, allowing for those to become an on-line repository of basic inventory information for connected VoIP Endpoints, while restricting the need for implementing SNMP agents only to the Network Connectivity Devices [switches,etc.]. This is especially important for inventory management of IP Phones, the majority of which lack support of management protocols such as SNMP, due to cost and complexity pressures that are likely to persist for some time to come. The solution is also more scalable since the management application can receive information from the LLDP-MED MIB in the network Connectivity Device instead of querying SNMP agents in the much larger numbers of Endpoint agents.
