4.14.2 LLDP LLDP-MED Configuration

The LLDP-MED Configuration page allows you to configure the LLDP-MED. This function applies to VoIP devices which support LLDP-MED.

Figure 4-67. LLDP-MED Configuration

The list of parameters is as follows:

  • Fast start repeat count: Rapid startup and Emergency Call Service Location Identification Discovery of endpoints is a critically important aspect of VoIP systems in general. In addition, it is best to advertise only those pieces of information which are specifically relevant to particular endpoint types (for example, only advertise the voice network policy to permitted voice-capable devices), to conserve the limited LLDPU space, and to reduce security and system integrity issues that can come with inappropriate knowledge of the network policy.

    Therefore, LLDP-MED defines an LLDP-MED Fast Start interaction between the protocol and the application layers on top of the protocol, to achieve these related properties. Initially, a Network Connectivity Device only transmits LLDP TLVs in an LLDPDU. Only after an LLDP-MED Endpoint Device is detected, an LLDP-MED capable Network Connectivity Device starts to advertise LLDP-MED TLVs in outgoing LLDPDUs on the associated interface. The LLDP-MED application temporarily speeds up the transmission of the LLDPDU to start within a second, when a new LLDP-MED neighbor is detected to share the LLDP-MED information as fast as possible to new neighbors.

    As there is a risk of an LLDP frame being lost during transmission between neighbors, it is recommended to repeat the fast start transmission multiple times to increase the possibility of the neighbors receiving the LLDP frame. With Fast start repeat count, it is possible to specify the number of times the fast start transmission is repeated. The recommended value is four times, given that four LLDP frames with a 1 second interval are transmitted, when an LLDP frame with new information is received.

    Note: LLDP-MED and the LLDP-MED Fast Start mechanism is only intended to run on links between LLDP-MED Network Connectivity Devices and Endpoint Devices and does not apply to links between LAN infrastructure elements, including Network Connectivity Devices or other types of links.
  • LLDP-MED Interface Configuration
    • Interface: The interface name to which the configuration applies
    • Transmit TLVs Capabilities: When checked, the switch's capabilities are included in LLDP-MED information transmitted
    • Transmit TLVs Policies: When checked, the configured policies for the interface are included in LLDP-MED information transmitted
    • Transmit TLVs Location: When checked, the configured location information for the switch is included in LLDP-MED information transmitted
    • Transmit TLVs PoE: When checked, the configured PoE information for the interface is included in LLDP-MED information transmitted
    • Device Type: Any LLDP-MED Device is operating as a specific type of LLDP-MED Device, which may be either a Network Connectivity Device or a specific Class of Endpoint Device. A Network Connectivity Device is a LLDP-MED Device that provides access to the IEEE 802 based LAN infrastructure for LLDP-MED Endpoint Devices. An LLDP-MED Network Connectivity Device is a LAN access device based on any of the following technologies:
      • LAN Switch/Router
      • IEEE 802.1 Bridge
      • IEEE 802.3 Repeater (included for historical reasons)
      • IEEE 802.11 Wireless Access Point
      • Any device that supports the IEEE 802.1AB and MED extensions that can relay IEEE 802 frames through any method

      An Endpoint Device is a LLDP-MED Device that sits at the network edge and provides some aspect of IP communications service, based on IEEE 802 LAN technology.

      The main difference between a Network Connectivity Device and an Endpoint Device is that only an Endpoint Device can start the LLDP-MED information exchange.

      Even though a switch must always be a Network Connectivity Device, it is possible to configure it to act as an Endpoint Device and thereby start the LLDP-MED information exchange (when two Network Connectivity Devices are connected).

  • Coordinates Location

    • Latitude: Latitude must be normalized to within 0–90 degrees with a maximum of four digits. It is possible to specify the direction to either North of the equator or South of the equator.

    • Longitude: Longitude must be normalized to within 0–180 degrees with a maximum of four digits. It is possible to specify the direction to either East of the prime meridian or West of the prime meridian.

    • Altitude: Altitude must be normalized to within −2097151.9 to 2097151.9 with a maximum of 1 digit. It is possible to select between two altitude types (floors or meters).
      • Meters: Representing meters of Altitude defined by the vertical datum specified
      • Floors: Representing altitude in a form more relevant in buildings which have different floor-to-floor dimensions. An altitude = 0.0 is meaningful even outside a building and represents ground level at the given latitude and longitude. Inside a building, 0.0 represents the floor level associated with ground level at the main entrance.
    • Map Datum: The Map Datum is used for the coordinates given in these options:
      • WGS84 (Geographical 3D): World Geodesic System 1984, CRS Code 4327, Prime Meridian Name: Greenwich
      • NAD83/NAVD88: North American Datum 1983, CRS Code 4269, Prime Meridian Name: Greenwich. The associated vertical datum is the North American Vertical Datum of 1988 (NAVD88). This datum pair is to be used when referencing locations on land, not near tidal water (which uses Datum = NAD83/MLLW).
      • NAD83/MLLW: North American Datum 1983, CRS Code 4269, Prime Meridian Name: Greenwich. The associated vertical datum is Mean Lower Low Water (MLLW). This datum pair is to be used when referencing locations on water/sea/ocean.

  • Civic Address Location: IETF Geopriv Civic Address based Location Configuration Information (Civic Address LCI). The total number of characters for the combined civic address information must not exceed 250 characters. A couple of notes to the limitation of 250 characters.

    If more than one civic address location is used, each of the additional civic address locations uses two extra characters in addition to the civic address location text.

    The two-letter country code is not part of the 250 characters limitation.

    • Country code: The two-letter ISO 3166 country code in capital ASCII letters. For example, DK, DE, or US.
    • StateL National subdivisions (state, canton, region, province, prefecture)
    • Country: County, parish, gun (Japan), district
    • City: City, township, shi (Japan). For example, Copenhagen.
    • City district: City division, borough, city district, ward, chou (Japan)
    • Block: Neighborhood, block
    • Street: Street. For example, Poppelvej.
    • Leading street direction: Street. For example, Poppelvej.
    • Trailing street suffix: Trailing street suffix. For example, SW.
    • Street suffix: Street suffix. For example, Ave, Platz.
    • House no.: House number. For example, 21.
    • House no. suffix: House number suffix. For example, A, 1/2.
    • Landmark: Landmark or vanity address. For example, Columbia University.
    • Additional location information: Additional location information. For example, South Wing.
    • Name: Name (residence and office occupant). For example, Flemming Jahn.
    • Zip code: Postal/zip code. For example, 2791.
    • Building: Building (structure). For example, Low Library.
    • Apartment: Unit (Apartment, suite). For example, Apt 42.
    • Floor: Floor. For example, 4.
    • Room no.: Room number. For example, 450F.
    • Place type: Place type. For example, Office.
    • Postal community name: Postal community name. For example, Leonia.
    • P.O. Box: Post office box (P.O. BOX). For example, 12345.
    • Additional Code: Additional code. For example, 1320300003.
  • Emergency Call Services: For example, E911 and so on, as defined by TIA or NENA.

    • Emergency Call Service: ELIN identifier data format is defined to carry the ELIN identifier as used during emergency call setup to a traditional CAMA or ISDN trunk-based PSAP. This format consists of a numerical digit string, corresponding to the ELIN to be used for emergency calling.

      Network Policy Discovery enables the efficient discovery and diagnosis of mismatch issues with the VLAN configuration, along with the associated Layer 2 and Layer 3 attributes, which apply for a set of specific protocol applications on that port. Improper network policy configurations are a very significant issue in VoIP environments that frequently result in voice quality degradation or loss of service.

      Policies are only intended for use with applications that have specific real-time network policy requirements, such as interactive voice and/or video services. The network policy attributes advertised are:

      • Layer 2 VLAN ID (IEEE 802.1Q-2003)
      • Layer 2 priority value (IEEE 802.1D-2004)
      • Layer 3 Diffserv code point (DSCP) value (IETF RFC 2474)

      This network policy is potentially advertised and associated with multiple sets of application types supported on a given port. The application types specifically addressed are:

      1. Voice
      2. Guest Voice
      3. Softphone Voice
      4. Video Conferencing
      5. Streaming Video
      6. Control/Signaling (conditionally supports a separate network policy for the preceding media types).

      A large network may support multiple VoIP policies across the entire organization, and different policies per application type. LLDP-MED allows multiple policies to be advertised per port, each corresponding to a different application type. Different ports on the same Network Connectivity Device may advertise different sets of policies, based on the authenticated user identity or port configuration.

      Note: LLDP-MED is not intended to run on links other than between Network Connectivity Devices and Endpoints, and therefore does not need to advertise the multitude of network policies that frequently run on an aggregated link interior to the LAN.
    • Delete: Check to delete the policy. It is deleted during the next save.
    • Policy ID: ID for the policy. This is auto generated and used when selecting the policies that are mapped to the specific interfaces.
    • Application Type: Following are the uses of the application types:
      • Voice: For use by dedicated IP Telephony handsets and other similar appliances supporting interactive voice services. These devices are typically deployed on a separate VLAN for ease of deployment and enhanced security by isolation from data applications.
      • Voice Signaling (conditional): For use in network topologies that require a different policy for the voice signaling than for the voice media. This application type must not be advertised if all the same network policies apply as those advertised in the Voice application policy.
      • Guest Voice: Support a separate limited feature-set voice service for guest users and visitors with their own IP Telephony handsets and other similar appliances supporting interactive voice services.
      • Guest Voice Signaling (conditional): For use in network topologies that require a different policy for the guest voice signaling than for the guest voice media. This application type must not be advertised if all the same network policies apply as those advertised in the Guest Voice application policy.
      • Softphone Voice: For use by softphone applications on typical data centric devices, such as PCs or laptops. This class of endpoints frequently does not support multiple VLANs, if at all, and are typically configured to use an untagged VLAN or a single tagged data specific VLAN. When a network policy is defined for use with an untagged VLAN (see Tagged flag), then the L2 priority field is ignored and only the DSCP value has relevance.
      • Video Conferencing: For use by dedicated Video Conferencing equipment and other similar appliances supporting real-time interactive video/audio services
      • Streaming Video: For use by broadcast or multicast-based on content distribution and other similar applications supporting streaming video services that require specific network policy treatment. Video applications relying on TCP with buffering would not be an intended use of this application type.
      • Video Signaling (conditional): For use in network topologies that require a separate policy for the video signaling than for the video media. This application type must not be advertised if all the same network policies apply as those advertised in the Video Conferencing application policy.
    • Tag: Tag indicates if the specified application type is using a tagged or an untagged VLAN
      • Untagged: Indicates that the device is using an untagged frame format and as such does not include a tag header as defined by IEEE 802.1Q-2003. In this case, both the VLAN ID and the Layer 2 priority fields are ignored and only the DSCP value has relevance.
      • Tagged: Indicates that the device is using the IEEE 802.1Q tagged frame format, and that both the VLAN ID and the Layer 2 priority values are being used, as well as the DSCP value. The tagged format includes an additional field, known as the tag header. The tagged frame format also includes priority tagged frames as defined by IEEE 802.1Q-2003.
    • VLAN ID: VLAN Identifier (VID) for the interface, as defined in IEEE 802.1Q-2003
    • L2 Priority: L2 Priority is the Layer 2 priority to be used for the specified application type. L2 Priority may specify one of eight priority levels (0−7), as defined by IEEE 802.1D-2004. A value of 0 represents use of the default priority as defined in IEEE 802.1D-2004.
    • DSCP: DSCP value is used to provide Diffserv node behavior for the specified application type as defined in IETF RFC 2474. DSCP may contain one of 64 code point values (0–63). A value of 0 represents use of the default DSCP value as defined in RFC 2475.
  • Policies Interface Configuration: Every interface may advertise a unique set of network policies or different attributes for the same network policies, based on the authenticated user identity or interface configuration.
    • Interface: The interface name to which the configuration applies
    • Policy ID: The set of policies that shall apply to a given interface. The set of policies is selected by check marking the checkboxes that correspond to the policies.