Transcript LLDP & LLDP-MED Presentation

LLDP-MED Standards Update
TIA TR-41.4 – St. Petersburg
May 1, 2007
Manfred Arndt – [email protected]
© 2004 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
Standards related to LLDP-MED
Standards enhancing the use of IP Telephony in Enterprise networks
Including, but not limited to the following current activities:
• IEEE 802.1ab rev - Link Layer Discovery Protocol
• IEEE 802.3at - PoE Plus for up to 30W Power
• IEEE 802.11u - Interworking with External Networks
• IEEE 802.11v - Wireless Network Management / Physical Location
• IETF draft-ietf-ecrit-phonebcp - Emergency Services Best Practices
Recently completed related standards
• RFC 4675 - Virtual LAN and Priority Support
• ANSI/TIA-1057 - LLDP Media Endpoint Discovery
2
Enhanced IP Telephony
RFC 4675
ANSI/TIA1057
LDAP, AD, Flat File
RADIUS
User
DB
VLAN, QoS
IEEE 802.1X
multi-user
IEEE
802.3af /
at
IEEE
802.1AB,
ANSI/TIA1057
Open standard multi-vendor solution
1.
Power negotiation using 802.3af (802.3at for up to 30W)
2.
Secure authentication of phone and PC with a single network connection
3.
Dynamic assignment of tagged voice VLAN and untagged PC VLAN
4.
Auto-provision phone with voice VLAN, QoS policy, and E911 location
5.
Detailed Topology, IP Phone inventory management, and more...
3
802.1AB-2005 Limitation
Provider Bridges and IP Phones (with two-port MAC relay)
have identified a limitation with LLDP propagation
• Some TLVs only apply to direct physical links (e.g. speed/duplex)
• Provider bridges may want to advertise different TLVs for
different scope (e.g. customer vs. provider equipment)
Solution:
• LLDP-REV is defining multiple destination MAC addresses to
support LLDPDU propagation scope over different ranges, like
TPMR or S-Bridge
4
P802.1AB Rev Scope
P802.1AB revision PAR covers:
• Updates to support extended addressing model
– Define multiple destination addresses and indicate which
TLVs are sensitive to propagation
• New and developing 802 standards, such as 802.3at (PoE Plus)
• New information elements (TLVs) for 802.3at
• More rapid exchange of LLDP frames for timeliness of updates
– Fast Start for rapid discovery (similar as LLDP-MED)
– Burst Mode for rapid exchange (with rate-limit)
5
P802.3at (PoE Plus for up to 30W)
Use LLDP as basis for an efficient Layer-2 power management
protocol for enhanced power allocation, to include the following:
•
Fine-grain power negotiation (in 0.1W increments)
•
Ongoing dynamic re-negotiation (e.g. need more power for video call)
•
Power priority (e.g. must keep “red phone” alive)
•
Backup power conservation (e.g. extend UPS battery life during
disasters)
• Flexibility to extend behavior without having to replace hardware
Provides advanced capabilities with minimal complexity
Practical for both cost-restrained and feature rich endpoints
Proliferation of PoE endpoints expected
• Video cameras, Pan-Tilt-Zoom video cameras, WLAN Access Points
• Door locks, card access readers, clocks, etc.
• IP Phones, video phones and other communication devices
6
P802.3at (PoE Plus) Updates
November 2006
P802.3at accepted motion to use LLDP for L2 classification
• All PD (clients) shall support both L1 and L2 classification
• PSE may use L2 classification to support mid-span devices
• Relying on LLDP Rev burst mode changes to overcome previous
objections
March 2007
P802.3at accept motion to reference ANSI/TIA-1057 Extended
Power-Via-MDI TLV as minimal mandatory requirement for PD
• Mandate that all 802.3at PDs support LLDP-MED PoE frame
• Use reference to ANSI/TIA-1057
• Include informative descriptions & frame formats for neatness
7
P802.3at (PoE Plus) Next Steps
Write TLV extensions as part of 802.1AB revision
Appoint liaison to coordinate requirements with TIA and 802.1
• New TLV elements, for example:
– PD requested maximum power (over and above currently required)
– PSE available maximum power (over and above currently supplied)
• More rapid exchange of LLDP frames for timeliness of updates
Define behavior rules within 802.3at, describing management
entity interactions when PoE TLVs are sent and received
8
Applicability to VoWLAN
LLDP benefits
• LLDP operates above the MAC service layer, and as such can be easily
implemented, without requiring any driver modifications
• Reduced complexity with high interoperability potential
• Easily extensible for future needs
• Applicable to all IEEE 802 networks and would provide common interface across
many networking technologies for ECS capable software applications
LLDP applicability
• Industry accepted solution, already deployed in wired IP phones
• Believed all interfaces required for ECS location delivery are defined today
• Draft IETF Emergency Services Best Practices - all telephone and mobile
devices MUST support LLDP-MED location (DHCP snooping and L7 must also
be supported)
• As currently defined, LLDP-MED can provide physical location of AP, which is
suitable for many ECS requirements
LLDP Limitation
• LLDP is a multicast protocol, and as such is currently limited to advertise
attributes common to all stations in the same SSID broadcast domain
9
VoWLAN Location Considerations
Emergency Services
Wireless client would quickly discover new physical location on roaming
• Switches need physical location anyway, to support wired phones
• AP could auto-discover it’s physical location via LLDP from wired network
• For AP capable of higher accuracy
•
• 802.11 could advertise client specific location using LLDP-MED unicast mode
10
802.1AB Interim Meeting May 8-10
Proposed 802.1AB Rev “Unicast Mode” Ballot Comments:
In order to provide 802.11 WLAN data confidentiality, 802.11i uses unique
session keys for every association to create an encrypted “logical” port
between every client and AP for unicast traffic. Essentially, a single shared
physical AP segment consists of a number of distinct encrypted “logical”
ports. However; there is also a single “logical port” used for multicast and
broadcast traffic shared by all clients on the same SSID. As such, secure
communications over an 802.11i “logical” port requires using the individual
MAC address as the destination.
Given that LLDP-REV is defining multiple destination MAC addresses to support
LLDPDU propagation scope over different ranges, it seems like a natural
extension to provide a similar operating range capability to support running
LLDP over both the “logical” and “physical” ports for 802.11i.
To run LLDP over a single encrypted 802.11 “logical” port requires the use of
an individual MAC addresses as the destination address for LLDPDUs. A unique
set of TLVs can be advertised over the different ranges.
11