The Flexible LIS-ALE Protocol (FLAP)


The Flexible LIS-ALE Protocol (FLAP) was designed to provide a framework for reporting location measurements.

image from book
The Blocks Extensible Exchange Protocol

The BEEP protocol, despite its unfortunate name, represents years of protocol design. The stated goals for BEEP were to provide a framework for connection-oriented, asynchronous protocols that support the request and response-style exchanges. BEEP uses the "best" of the IETF standards offerings (TCP, TLS, SASL, and MIME) to achieve those goals.

Different uses of BEEP are separated into channels, each of which runs independently of the others, permitting multiple sessions within the one TCP connection. Each channel uses a single BEEP profile, which is a specific application usage. FLAP is defined as a BEEP profile.

image from book

It is useful to realize that at any point along the location determination chain, one piece of information is known and the other is required. FLAP names the known component terminal information-that is, the information identifies a particular terminal. The unknown part relates to how the terminal accesses the network. This is called access information. The ALE is responsible for providing access information when given terminal information.

For example, if an ALE in an Ethernet switch is queried, it can provide a link between a MAC address and/or IP address (terminal information) and a switch and port (access information).

The distinction between terminal and access information is a simplification that can be thought of as a key-value pair. The link between these values is provided by the ALE. FLAP provides a framework for reporting this link between terminal and access information.

FLAP is defined as a BEEP profile (see References 1 and 2). BEEP is a protocol framework that provides bidirectional, asynchronous communication between two entities-in this case, a LIS and ALE. BEEP is based on TCP, with support for Transport Layer Security (TLS) where additional security is required.

In the spirit of keeping all configuration data centralized, the LIS initiates the BEEP connection. The only configuration that may be required at the ALE is that which permits the authentication of the LIS. Using the Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (see Reference 3) means that all maintenance effort is kept at the LIS.

Extensions

FLAP uses XML-formatted messages so that it can be easily extended to accommodate different access network technologies. The base specification does not proscribe what specific terminal and access information will look like, except to provide start and end times for access information. Terminal and access elements provide a generic container that can be redefined depending on the access network technology. A technology extension defines what information is required for each of the terminal and access elements for that technology.

Vendor extensions are added on top of technology extensions and allow for enhancements to FLAP that are specific to particular ALEs or networks. Vendor extensions can be used for proprietary methods of improving the speed, accuracy, or security of location determination.

Both technology and vendor extensions are distinguished using namespaces for XML. Each extension is uniquely identified by a URN that is recognized by the LIS. The following message uses the Ethernet extension with additional vendor extension parameters:

 <ntfy xsi:type="enet:ntfy"       xmlns:vnd1="http://www.example.com/flap/terminal/hw"        xmlns:vnd2="http://www.example.com/flap/access/skew">   <enet:terminal     <ip>192.168.0.1</ip>     <enet:hwaddr>12:34:56:78:90:ab</enet:hwaddr>     <vnd1:hw revision="1.2"/>   </enet:terminal>   <enet:access time="2005-04-14T10:51:23.000+10:00">     <enet:switch><ip>192.168.0.1</ip></enet:switch>     <enet:port>4</enet:port>     <vnd2:skew>0.5127</vnd2:skew>   </enet:access> </ntfy> 

The preceding example shows a notification from an Ethernet ALE. A terminal is identified by its IP and MAC address, along with a vendor extension that identifies a hardware revision. Measurement information includes a time, along with identification of the switch by IP address and the port of attachment. A second vendor extension, named "skew" carries the value 0.5127.

FLAP Messages

FLAP allows different ALE types to report location measurements as best suits them. The five FLAP message types can be used to convey location measurements both asyn-chronously and synchronously.

Notification

The recommended approach is to have an ALE report location measurements as network circumstances change. The Notification message can be generated by the ALE when it detects a terminal entering the network, a terminal moving within the network, or a terminal leaving the network. Figure 3.4 shows the standard usage for a Notification message.

image from book
Figure 3.4: An ALE sends a Notification message to indicate a change in the network.

Notification messages use the BEEP MSG/RPY exchange; such notifications are acknowledged with an empty RPY frame.

The following shows a BEEP frame that contains a simple request. This request comes from an ALE that provides measurements from a DHCP server:

 MSG 1 0 . 406 395 Content-Type: application/xml <ntfy xsi:type="dhcp:ntfy">   <dhcp:terminal>     <ip>192.168.2.10</ip>     <dhcp:hwaddr>01020304050a</dhcp:hwaddr>   </dhcp:terminal>   <dhcp:access time="2005-04-15T14:02:25.160+10:00"                expires="2005-04-15T16:02:25.160+10:00">     <dhcp:relay>192.168.2.1</dhcp:relay>     <dhcp:circuit-id>03</dhcp:circuit-id>   </dhcp:access> </ntfy> END 

The notification includes information about the terminal along with DHCP relay (see Reference 4) information that the LIS can use to locate the terminal. The LIS acknowledges this notification with the following empty BEEP frame:

 RPY 1 0 . 63 0 END 

Resynchronization

Network or system outages are inevitable in virtually any system, particularly one that is intended for continuous usage. Resynchronization enhances the robustness and reliability of LIS and ALE communications by providing the LIS with a means to quickly determine the current state of the ALE at startup time and after an outage.

Resynchronization uses the BEEP MSG/ANS exchange, which allows for multiple responses to a single request. A Resynchronization Request from a LIS can result in any number of Resynchronization Response messages being sent by the ALE. Each Resynchronization Response contains information about a single terminal and network attachment. Figure 3.5 shows the Resynchronization procedure.

image from book
Figure 3.5: A Resynchronization Request triggers multiple Resynchronization Responses.

A Resynchronization procedure can be used in two ways: a full Resynchronization is used at startup time, or after a long outage; and a partial Resynchronization can be used for short outages caused by a transitory fault, or a communications error.

When a LIS starts, it will probably not have any useful information about the state of the network. The full Resynchronization procedure provides the current state of all network attachments that the ALE can monitor.

After a short outage in either the LIS or the LIS to ALE link, the LIS can use the partial (or "since") Resynchronization procedure to request all notifications that it might have missed. The partial Resynchronization Request includes a start time, which triggers different behavior at the ALE.

The partial Resynchronization differs from a full Resynchronization because the LIS already has some information about the state of the network-the ALE only needs to provide the changes that have occurred since the indicated time. In effect, the ALE needs to send all the Notification messages it would have sent during the request period. This usage differs because responses to this sort of request include terminals leaving the network sector.

Partial Resynchronization is an optimization that reduces the impact of temporary outages. If this mode is not supported, the LIS can purge its current state and use the full Resynchronization.

The following Resynchronization message is sent by the LIS. The since attribute indicates to the ALE that this is a partial Resynchronization starting at the given time.

 MSG 1 0 . 0 108 Content-Type: application/xml <sync since="2005-04-15T14:51:21.000+10:00"       xsi:type="dhcp:sync"/> END 

The ALE responds to this request by providing a number of responses, each contained in a separate BEEP frame, followed by a NUL frame:

 ANS 1 0 . 0 411 Content-Type: application/xml <syncr result="200" xsi:type="dhcp:syncr">   <dhcp:terminal>     <ip>192.168.2.11</ip>     <dhcp:hwaddr>01020304050b</dhcp:hwaddr>   </dhcp:terminal>   <dhcp:access time="2005-04-15T15:01:10.991+10:00"                expires="2005-04-15T17:01:10.991+10:00">     <dhcp:relay>192.168.2.1</dhcp:relay>     <dhcp:circuit-id>02</dhcp:circuit-id>   </dhcp:access> </syncr> END ANS 1 0 . 411 253 Content-Type: application/xml <syncr result="201" xsi:type="dhcp:syncr">   <dhcp:terminal>     <ip>192.168.2.12</ip>     <dhcp:hwaddr>01020304050c</dhcp:hwaddr>   </dhcp:terminal>   <dhcp:access time="2005-04-15T15:17:57.521+10:00"/> </syncr> END NUL 1 0 . 664 0 END 

The absence of access information indicates that the terminal left the network, while the NUL frame indicates the end of the sequence of results.

These messages require that the ALE perform tasks beyond just reporting changes in the network. In order to support these messages, the ALE needs to maintain certain information. For the first usage, the full resynchronization, the ALE needs to maintain an image of the current state of the network sector.

The second usage, partial resynchronization, requires that the ALE also remember the most recent Notification messages it has sent, or might have sent. The ALE effectively buffers messages for the period of time that it intends to provide a partial re-synchronization for; the number of messages, and the total time permitted, is limited by how much storage there is available for this feature. If an ALE is unable to provide sufficient history for a partial resynchronization, this is indicated to the LIS. The LIS then purges its existing state for that ALE and attempts a full resynchronization.

Lightweight ALE implementations can avoid storing any additional information, providing that they support the Access Query, which can be used by the LIS to build an image of state. However, this option increases the impact of an outage by requiring more messaging to recover state after the outage.

Access Query

The Access Query is a synchronous query that is provided to deal with limitations of ALE implementations. A direct request to the ALE can be used as a check, or to provide more recent information. A LIS can asynchronously probe for an ALE measurement at the moment it needs to do location determination.

The Access Query exchange is useful where the ALE doesn't support a reporting capability, or it only has a limited reporting capability. It is also useful where the access network is highly dynamic since location measurements in highly mobile networks can change too dynamically for notification methods to be practical. For example, radio signal strength can change constantly, even when the target is stationary. One consequence of Access Query is that in a network with multiple ALEs, without some form of notification, the LIS might have to query several ALEs before it can find the correct one.

The Access Query is sent by the LIS, and includes terminal information only. The ALE provides access information for that terminal in the response, as shown in Figure 3.6.

image from book
Figure 3.6: An Access Query is the synchronous method for retrieving ALE data.

The following Access Query includes information about a particular terminal:

 MSG 1 0 . 63 176 Content-Type: application/xml <aq xsi:type="dhcp:aq">   <dhcp:terminal>     <ip>192.168.2.10</ip>     <dhcp:hwaddr>01020304050a</dhcp:hwaddr>   </dhcp:terminal> </aq> END 

The response to this message does not necessarily contain any terminal information:

 RPY 1 0 . 801 294 Content-Type: application/xml <aqr result="200" xsi:type="dhcp:aqr">   <dhcp:access time="2005-04-15T14:02:25.160+10:00"                expires="2005-04-15T16:02:25.160+10:00">     <dhcp:relay>192.168.2.1</dhcp:relay>     <dhcp:circuit-id>03</dhcp:circuit-id>   </dhcp:access> </aqr> END 

The Access Query procedure can be used in a number of ways to address the shortcomings of ALEs with limited functionality. Therefore, an Access Query can be used to check that a terminal is still attached to a network sector.

If an ALE does not generate Notification messages, an Access Query can be used to retrieve measurements. The LIS can poll for information from the ALE, or request information on demand. Using Access Query in this fashion can consume a large amount of network resources, therefore it isn't recommended.

LIS to ALE Notifications

In some cases, the LIS might detect that a particular terminal has moved out of the network sector monitored by an ALE before the ALE detects this change. This might be reported to the LIS by another ALE. For instance, DHCP is not particularly good at recognizing that a terminal has left the network. DHCP clients are not obliged to notify the server when they leave the network, so many do not.

In this case, a LIS-to-ALE, or downstream, Notification message can be sent to the ALE. This message is optional, and is provided as a courtesy to the ALE. The ALE can use this message as a trigger to release any resources it has committed in monitoring that terminal and to update any state it maintains. The downstream notification also prevents the ALE from erroneously reporting the presence of the terminal.



IP Location
IP Location
ISBN: 0072263776
EAN: 2147483647
Year: 2004
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net