Enterprise Location Considerations


This section will look at issues that need to be taken into account when introducing a LIS into an enterprise. It will describe such things as Network Address Translation (NAT), VPNs, and data management.

NATs, Firewalls, and VPNs

Network Address Translations (NATs), firewalls, and Virtual Private Networks (VPNs) are generally problematic because they alter or disguise the identity of end-points connected to the network. NATs are designed to translate from localized private address spaces into more publicly routable IP addresses. Firewalls, which often employ NATs, are designed to restrict the flow of certain types of traffic. While VPNs are designed specifically to make hosts residing on remote networks appear as though they are residing on the local enterprise network. These problems are not insurmountable, providing thought is given as to where and how location determination and acquisition are to occur.

VPNs are most easily addressed by ensuring that the local access network determines and provides location to the end-point prior to the end-point establishing a VPN back to the enterprise. For this to work effectively, the end-point needs to be location-capable. While it is technically possible to support nomadic non-location-capable devices through VPNs, the complexities and practicalities make it infeasible, as extensive changes to VPN servers and other network nodes both in the enterprise and the public network would be required.

NATs are a little more problematic since many hosts with discrete IP addresses, that may also be geographically diverse, may reside behind a single IP address attributed to a Network Address Translation device. In many cases, the most practical thing to do is to add a LIS inside the domain controlled by the NAT. This is the same approach that is applied to many local services such as DHCP servers, web servers, and DNS servers within enterprises today. In other cases, where the geographically served area of the enterprise is small, it may be fine for all hosts behind the NAT to be attributed with the same location. Home offices and small shop fronts where Internet connectivity is achieved through DSL or cable modems are a good example of where a single location is suitable.

Where putting a full LIS behind the NAT doesn't make sense-where there is a centralized corporate infrastructure team-then a Gateway LIS can be employed to perform a relay function, and relay location requests to the central office LIS (see Figure 5.17).

image from book
Figure 5.17: A Gateway LIS operating as a relay.

The steps for location determination and acquisition in this model are:

  1. Softphone connects to the local office network.

  2. ALE measurements are passed to the local Gateway LIS if required.

  3. Softphone requests location from the local Gateway LIS, and assumes a simple HELD protocol GET, which might look like:

     <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held"/> 

  4. The Gateway LIS forwards the request, plus any measurement data to the central LIS. This request would look something similar to:

     <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held"                  responseTime="2" signed="true">    <locationType>       geodetic    </locationType>    <heldDevice           xmlns="http:/sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">       <dhcp>          <giaddr>192.168.5.9</giaddr>          <agentID>4E6574676561722D31</agentID>          <circuitID>30312F3530</circuitID>       </dhcp>    </heldDevice> </locationRequest> 

  5. The central LIS determines the location and returns a PIDF-LO to the Gateway LIS.

     <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf"    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"    xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"    entity="pres:user76@remote.office.example.com">    <tuple >      <status>        <gp:geopriv>           <gp:location-info>              <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"                  xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"                  xmlns:gml="http://www.opengis.net/gml">                  <gml:pos>                      42.5463 -73.2512                  </gml:pos>                  <gml:radius uom="urn:ogc:def:uom:EPSG::9001">                      850.24                  </gml:radius>              </gs:Circle>           </gp:location-info>           <gp:usage-rules>              <gp:retransmission-allowed>yes</gp:retransmission-allowed>           </gp:usage-rules>           <gp:method>dhcp</gp:method>        </gp:geopriv>      </status>      <timestamp>2003-06-22T20:57:29Z</timestamp>    </tuple> </presence> 

  6. The Gateway LIS returns the location to the softphone.

There may be some benefits in including a default location that the local Gateway LIS can return to all clients in the event that the central LIS is unreachable. Such a precaution certainly guards against central LIS failure, but may be less useful where link failures to the central office occur, particularly if the local office is dependent on the central office for all outbound communication and, in any case, is a LIS implementation-specific detail.

Data Management

The key to determining and providing accurate location in any environment is ensuring that information relating to the configuration of the network is correct. Ensuring that this information is correct has been a major hurdle in the deployment of accurate location services for cellular operators the world over, and has resulted in significant changes in work practices to maintain data integrity across networks. This same problem will impact IT work practices for IP telephony devices, if legal obligations come into effect requiring accurate emergency call location within enterprises or, indeed, where accurate location becomes an important aspect of the enterprises applications.

Many IT departments have strict controls and integral knowledge of phone extension placements. This stems in part from the connection-oriented nature of phones, and the convenience of staff not needing to change extension numbers simply because they move desks. In some parts of the United States, legislation mandates that certain types of premises must report locations of no larger than a certain size (8000 sq. ft. in one instance) in the event of an emergency. Such policies have resulted in PABX manufacturers supporting the grouping of phone extensions that are in physical proximity to one another.

Often, the controls and data management associated with the placement of telephone extensions is not extended to recordkeeping practices for Ethernet and data ports in enterprise environments. As IP devices within the enterprise become telephony-enabled, this lack of accurate recordkeeping represents a gap in the knowledge required to determine and provide accurate location information. This is particularly true in environments that employ practices such as hot desking and require staff to use softphone applications tied to their laptop or PC. In these scenarios, a staff member may be anywhere within the building and an extension number is not tied to a physical location as it was with a more traditional phone system. To address these issues, accurate records of switch-port terminations and other data records will need to be maintained, and this data will need to be propagated into the LIS in a timely fashion. Ideally, applications will evolve that allow IT staff to enter this information directly into the LIS, and the LIS can serve as a record of data interconnection as well as an operating database for terminal location acquisition.



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