Location Determination in Enterprise Networks

The previous section described two common enterprise network access technologies and topologies. This section will look at ways in which data can be measured and used to determine the physical location of a device connected to an enterprise network.

Bridge MIB Interrogations

Most edge switches are referred to as "managed switches"-that is, they support an interface that allows the switch configuration to be set and the performance of the switch to be monitored remotely using the Simple Network Management Protocol (SNMP). One of the pieces of information that a managed switch keeps is a current list of all MAC addresses connected to each port on the switch. This information is generally accessible through what is referred to as the bridge Management Information Base (MIB), which is defined in Reference 4 (see Figure 5.4). By accessing the bridge MIB of a particular switch, it is possible for an ALE to see all client hardware (MAC) addresses connected to the switch and what physical interface (port) they are connected on. This MAC information can then be used by the LIS to determine where a particular device is. The LIS will do this by maintaining a "wire map" database that relates switch ports to location-typically, the office location that is at the other end of the UTP Ethernet cable and that is plugged into a specific switch port. The location can be stored as a civic address and/or a geodetic lat/long.

Figure 5.4: An SNMP bridge MIB ALE.

In general, an ALE will be expected to poll the edge switches from time to time using SNMP GET messages. Often, a switch can be configured to provide an event in the form of an SNMP trap to indicate that an Ethernet link has gone up or down. Using this SNMP trap information, it may be possible to reduce the amount of polling required. It would be unwise to eliminate polling completely since SNMP uses UDP as a transport protocol and the arrival of messages is not guaranteed.

Static IP-to-MAC LIS Provisioning

The basic bridge MIB location determination mechanism allows the LIS to determine the location of a device based on a MAC address by tying it to a specific switch on a specific port. One problem with this approach occurs when a device tries to acquire its location, and the device is in a different IP subnet to the LIS, with potentially one or more layer-3 IP routers separating the device and the LIS. The problem is that the MAC address of the requesting device is not readily available to the LIS since it doesn't propagate through the layer-3 routers.

One way to overcome this is shown in Figure 5.5. Here, a static IP address is assigned to each device, and the IP-to-MAC address mapping is statically provisioned into the LIS. Static mappings for switch-port-to-location mappings are also provisioned into the LIS. The LIS now receives FLAP messages from the ALE periodically providing switch-port-MAC mappings that the LIS keeps in a dynamic table. As shown in Figure 5.5, this then allows the LIS to map IP address to location by following the chain of IP to MAC, MAC to switch and port, and then switch and port to location.

Figure 5.5: LIS static provisioning.

There are several downsides to this approach, the most significant being the need to do static IP address allocations when otherwise they would not be required. The other significant downside to this approach is what happens when the LIS doesn't have the MAC-to-switch and port mapping when a device requests its location. In this case, the LIS has to ask the ALE for the information, and in the basic form the ALE will only understand MAC addresses. If the network is small, then the ALE may just go out and poll all switches and ports for this information. If the network is large, this is impractical and mechanisms to speed up searches are required.

The search can be sped up by reducing the number of switches that need to be polled. One way is to not support dynamics in the network at all and simply hard-code MAC-to-location in the LIS. This does, however, make terminal movements awkward. Another way to do this is to have the ALE understand additional network configuration data such as which IP subnets are associated with which switches. In this situation, the LIS can pass down MAC and IP to the ALE when requesting network measurements, and the ALE can use the IP address to short-list the number of switches to poll. An alternative approach to providing additional configuration in the ALE is to include an ALE in each subnet and allow the LIS, based on IP address, to determine which ALE to query. Ultimately, the best approach is for the ALE to reside in the switch and for it to provide asynchronous notifications to the LIS. This results in the LIS only needing to search the network for the device's information when a notification has been missed or not received.

ARP Table-Assisted Bridge MIB Location Determination

In the configurations posed so far, the LIS has had to have static IP address-to-MAC address provisioning, something that is becoming less and less common in enterprise networks for general host connectivity. As was stated earlier, if the enterprise wants to use bridge MIB location determination methods and operate a LIS that is not in the same subnet as location requesting devices, then a mechanism to resolve the IP-to-MAC address mapping is required, or the requesting device cannot be readily identified by the LIS.

One device in a local subnet that always knows the IP address-to-MAC address mapping is the layer-3 router. A router keeps this information in its Address Resolution Protocol (ARP) table and this allows it to map IP address to MAC address for the purpose of routing messages (see Figure 5.6). In most cases, the ARP tables in a router are accessible through an SNMP MIB, so an ALE knowing the IP address of the requesting client can easily identify the router to query.

Figure 5.6: ARP table polling.

Location determination in this setup goes something like this:

1. A host requests its location from the LIS.

2. The LIS sends a measurement request to the ALE asking for measurements to do with IP address 192.168.222.5.

3. The ALE uses a subnet map to determine the correct layer-3 router, then requests its ARP table.

4. The ALE gets the ARP table, and determines the MAC address corresponding to the IP address 192.168.222.5-in this case, 1f0436a034ab.

5. From the router and client IP address information, the ALE knows which switch or switches to request MAC table information for.

6. The ALE queries various switches for the MAC and finds MAC address 1f0436a034ab attached to port 2 or switch B.

7. The ALE sends back a FLAP message containing the IP address, MAC address, and switch and port information.

8. The LIS uses the switch and port information to look up the location.

It should be noted that in the preceding steps there are two distinct ALE functions, one to determine the IP address-to-MAC address mapping, and a second function to determine the switch and port on which the MAC address resides. These functions may be performed by two different ALEs, in which case the LIS would need to launch two separate FLAP requests. Alternatively, the LIS may receive FLAP notification messages for each of the events. In either case, the LIS needs to correlate the data to determine location.

This approach is impractical to perform in real time given the amount of data required to be processed. It is useful in situations where location requests from the LIS can be batched, so that hitting the ARP table yields many results, reducing the network load and search space, and the corresponding data can then be cached for near-term requests. This type of situation is not uncommon in enterprises where devices can move but do not move frequently, or moves can be tied closely to the time of the batched updates.

DHCP-Assisted Bridge MIB Location Determination

While a layer-3 router for a subnet must keep ARP tables for routing purposes, as was described in the previous section, sorting through them in real time in a network of any size will likely prove problematic. There is, however, another node that can usually provide IP address-to-MAC address mappings: the DHCP server, (see Figure 5.7.)

Figure 5.7: DHCP-assisted IP-to-MAC binding.

In this scenario, a DHCP ALE, or interface to an ALE, provides the IP-to-MAC address bindings that were provided previously by trawling through the router ARP tables in the earlier example. Where the ALE is not integrated into the DHCP server, the DHCP server may be interrogated using an external interface such as that proposed in Dynamic Host Configuration Protocol Leasequery (see Reference 5).

So the location determination steps become the following:

1. A host requests its location from the LIS.

2. The LIS sends a measurement request to the ALE asking for measurements to do with IP address 192.168.222.5.

3. The ALE has the IP-to-MAC binding from the DHCP server; alternatively, the ALE may request this from the DHCP server.

4. From the client IP address information, the ALE knows which switch or switches to request MAC table information for.

5. The ALE queries various switches and finds MAC address 1f0436a034ab attached to port 2 or switch B.

6. The ALE sends back a FLAP message containing the IP address, MAC address, and switch and port information.

7. The LIS uses the switch and port information to look up the location.

A DHCP Leasequery ALE

The previous section mentioned the existence of the DHCP lease query specification (see Reference 5). Here, we will describe how this protocol can be used to create an ALE. This section will assume that the LIS has identified the FLAP terminal/key as being the IP address, and therefore the returned access element will be the MAC address. That is, the DHCP lease query will include an IP address and needs a MAC address in the response.

The fields for the lease query message from the ALE to the DHCP server are described next:

1. Set the DHCP header with the following parameters:

   • op = 1

   • giaddr = IP address of the ALE

   • htype = 0

   • hlen = 0

   • chaddr = 0

   • ciaddr = Terminal IP address (the one we are looking for)

2. Include DHCP option 53 (message type) in the request with a value of 10, indicating a DHCPLEASEQUERY message.

The DHCP server will respond with one of three messages:

• DHCPLEASEUNASSIGNED message, indicating that the DHCP server knows about the IP address but it is not currently allocated to a terminal.

• DHCPLEASEUNKNOWN message, indicating that the DHCP server knows nothing about the IP address at all.

• DHCPLEASEACTIVE message, indicating that the DHCP server has an active lease for the IP address. This message will also contain the corresponding MAC address.

The ALE will send various FLAP errors to the LIS in the event that either a DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN message is received from the DHCP server. When a DHCPLEASEACTIVE message is received, the ALE will need to extract the MAC address from the htype, hlen, and chaddr header. For Ethernet, the htype and hlen fields will be 1 and 6, respectively, and the chaddr field will contain the actual MAC address in the first six octets.

The FLAP specification for the DHCP Lease query ALE support (see Figure 5.8) is provided in Appendix A. Sample message stanzas for the access query and access query response messages are provided next.

 <aq xsi:type="dhcp-lq:aq">   <dhcp-lq:terminal>     <ip>192.168.222.5</ip>   </dhcp-lq:terminal> </aq> <aqr result="200" xsi:type="dhcp-lq:aqr">   <dhcp-lq:access time="2005-04-15T14:02:25.160+10:00"                   expires="2005-04-15T16:02:25.160+10:00">     <dhcp-lq:hwaddr>1f0436a034ab</dhcp-lq:hwaddr>   </dhcp-lq:access> </aqr> 

Figure 5.8: DHCP Lease Query ALE.

DHCP Relay Location Determination

DHCP can be used to determine location through the use of a DHCP relay (option 82) defined in Reference 3. DHCP relay agents are deployed in networks where DHCP clients reside in different subnets to the DHCP server. They are required in these networks because DHCP requests are made using IP broadcasts and layer-3 routers will not pass broadcast traffic, so a means to deliver these messages to a DHCP server is required. Originally, DHCP relay-agent functions resided only in layer-3 routers and high-end switching nodes; however, it is a function that is becoming more and more prevalent in mid- to lower-end switching devices also.

A DHCP relay-agent intercepts DHCP broadcast messages and adds additional information before directly addressing the message to a known DHCP server as a unicast UDP packet. The DHCP relay-agent will look at the content of the intercepted message and, depending on the presence or absence of certain parameters, either add information or pass the message on to the DHCP server unmodified. Specifically, if the DHCP message does not have the giaddr header parameter set, the relay will set this parameter to be the IP address of the relay-agent (or IP address of the incoming interface if there is more than one). This functionality is defined in Reference 6.

 NOTE: Reference 3 supports relay-agents adding location measurement data but not setting giaddr in trusted networks. However, many enterprise switches implementing DHCP relay set the giaddr field.

The relay-agent may also append data to more precisely specify the interface and port on which the request arrived. It is this information that is defined in 3 and that is useful for location determination.

Reference 3 defines DHCP option 82, which is comprised of two sub-options: sub-option 1, the Agent Circuit ID; and sub-option 2, the Agent Remote ID. Sub-option 1, the Agent Circuit ID, is used to encode the identifier for the circuit on which the agent intercepted the client DHCP request. In the case of an enterprise-based Ethernet-managed switch, this would be the Ethernet port. Reference 3 provides a number of other examples to which the Agent Circuit ID may apply.

Sub-option 2, the Agent Remote ID, is designed to uniquely identify something at the other end of a permanent circuit that is terminated at the relay. Consequently, an Agent Remote ID must be globally unique. Examples of the Agent Remote ID are telephone number, MAC address, or a fully qualified user name ([e-mail]). This reference also provides several other examples for Agent Remote ID.

One of the intended uses of the DHCP relay option data was to aid DHCP servers supporting a large number of geographically diverse hosts in making decisions about what configuration data to provide to which hosts. An unintended side effect of this functionality is that it can also aid network nodes that need to determine the physical locations of end hosts.

The precision of location determination using DHCP relay-agent data is dependent on how close to the edge network-for instance, the point of actual network attachment by a host-is to the DHCP relay-agent. As stated earlier, many older edge switches do not support DHCP relay functionality and defer it to larger switches and routers further into the core network (see Figure 5.9). Obviously, the further into the core, and the larger the area serviced, the less precise the yielded location will be since it must define a larger area to address all possibly connected hosts.

Figure 5.9: A DHCP relay in the core network.

Conversely, enabling relays at the very edges of the network directly where hosts attach can yield relatively precise location information, providing that wiremap databases correlating switch and Circuit-ID information to locations are kept up-to-date (see Figure 5.10).

Figure 5.10: A DHCP relay in the edge switch.

DHCP Relay Information Considerations

While DHCP relay-agent information may seem the perfect solution to location determination in the enterprise environment, it is not without its drawbacks. Some of these drawbacks are described in the subsequent sections.

Interpreting Relay-Agent Information

Reference 3 uses explicit language on how to interpret data transported in the Agent Circuit ID and Agent Remote ID fields, and this is an important note to anyone considering building or operating an LIS. These fields must be treated as literal strings-in other words, do not parse them in an attempt to extract specific tokens; data either match absolutely or they do not match at all.

DHCP Servers and Relay Information

Not all DHCP servers make use of DHCP relay data, and like all other DHCP options, if the server doesn't understand the data, the option is ignored. One of the most commonly used DHCP servers in enterprise environments today does not provide support for DHCP option 82. In addition to this, providing support for option 82 may be limited to configuration data assignment and may not extend to keeping the data in the lease database. Where the data is kept in the database, it can be retrieved using the DHCP lease query function described earlier. Some DHCP servers, such as the one provided with a Windows 2003 server, while not providing direct support for some options, do provide an extensive API, allowing adjunct functions to make use of this data.

Challenges or DHCP Methods in Wireless Networks

One other consideration that must be taken into account is using DHCP location determination in networks where a host may be mobile-a large WiFi network such as may be found on a university campus or in a large hotel. The problem in these situations is that DHCP relays are generally only in the communications loop at initial configuration time. Once a lease is established between a host and a DHCP server, messages are unicast-that is, they are exchanged directly between the client and the DHCP server. This makes it impossible to use relay information to keep tabs on a moving host.

The DHCP server identifier override sub-option describes a way in which a DHCP relay-agent can remain in the loop between the client and DHCP server for precisely the purpose of continuing to provide relay location measurements (see Reference 7). In this configuration, the client host must renew its lease or request a new configuration from the DHCP server in order for the relay-agent to provide the updated measurements. This may be a suitable compromise in many situations, particularly if the area of roaming can be encompassed by a single DHCP relay-agent. There are, however, still drawbacks with this approach, for example, if the host roams to an access point that is connected to a different switch/relay, then the measurements provided will be incorrect. These are not problems with the DHCP server identifier override sub-option or related concepts, so much as problems that may be encountered when trying to use it specifically to provide location determination measurements in certain network configurations.

The larger problems are more to do with the nature of mobile clients and DHCP client implementations. As stated, the DHCP server identifier override sub-option specification requires DHCP clients to do something-renew their lease or request configuration data-before the new location measurements are sent to the DHCP server. Lease times are generally, though not always, quite long, so relying on lease renewal is probably not a good approach for mobile devices. Assuming that the client can detect that it has changed access points, often it may not be able to; the client needs to do something like request network configuration data to ensure that network measurements are propagated to the DHCP server. A number of the more common DHCP client implementations, Windows XP among them, have a propensity to cache DHCP option configuration data. Requests for network data are responded to from cache, with actual requests to the network sent for options only when the cached data are deemed to be stale. This is actually consistent with the notion that network configuration data generally doesn't change too much, and highlights the problem of likening physical location information, which may change frequently, with network configuration information that does not.

A DHCP ALE

Thus far, we have described how information received by a DHCP server can aid in location determination. This section will describe how this information can be retrieved from a DHCP server and subsequently sent to a LIS using FLAP.

There are two basic approaches that will be discussed. The first approach is to incorporate the ALE functionality directly into the DHCP server. The second approach is to extend the DHCP Lease Query ALE described in the previous section titled "A DHCP Leasequery ALE."

On first impressions, a solution that requires modification to the DHCP server sounds complex and undesirable. However, certain environments, such as Windows XP, cater specifically for application developers that need to extend network server capabilities. In this environment, it is relatively easy to write a library that links to the DHCP server through the Windows-provided API, and extract the data required to send to the LIS. Indeed, for Windows, it is necessary since DHCP relay-agent data are not stored in the lease database, and the lease query functionality is not supported.

The second approach is to modify the DHCP lease query ALE to support returning the DHCP relay agent data associated with the DHCP lease. This mechanism is acceptable providing that the DHCP server supports the DHCP relay-agent option, stores relay-agent information in the lease database, and also supports the DHCP lease query protocol. Unfortunately, many DHCP servers do not support this.

The LIS-to-ALE queries and ALE-to-LIS notifications are the same regardless of which implementation is used. The key differences in the approaches lie in how the ALE extracts the data from the DHCP server. Where the ALE is coupled with the DHCP server directly, perhaps using an API, then the data extraction is internal and will not be discussed further. Where the ALE uses the lease query interface to extract relay data, Figure 5.8 changes to that shown in Figure 5.11.

Figure 5.11: A DHCP Lease Query ALE extension.

The main difference here is that the ALE includes DHCP option 55 with a value of 82 in its request to the DHCP server, which indicates that the ALE is interested in DHCP relay-agent information. The DHCP server will include the DHCP relay-agent information in its response. However, DHCP option 82 sub-option 1, the Circuit-ID, must contain sufficient information to uniquely identify the switch and port within the access network, but it may not. This is because Reference 5 does not provide a way to obtain the address of the initial gateway that supplied the circuit information. This information was provided by the gateway in the giaddr field of the initial DHCP request, but this field cannot be used to communicate the gateway address in the lease query response because it is required to identify where the lease query response should be sent. Consequently, care must be taken when constructing an ALE in this manner to ensure that the preceding limitation is addressed.