PP6: LoST, location based routing, and application Infrastructure.

[Lisa Dusseault <[e-mail]>]

LoST, location based routing, and application Infrastructure.
Ted Hardie

Work done in the ECRIT working group to support location-based  
routing of emergency calls has resulted
in LoST (A Location to Service Translation protocol).  The current  
draft, draft-ietf-ecrit-lost,  will be revised
in the next few weeks to handle Last Call comments, and then  
submitted to the IESG.  Assuming there is
no major architectural issues raised, it will become part of the  
toolkit available for applications.  This position
paper discusses who might use it and why.

Basic LoST protocol transactions start with  a location expressed in  
XML (using either a civic or geolocation profile)
and a service URN; one or more contact URIs is returned along with  
the  boundaries for which that contact URI
is valid, if that information is available.  The protocol also  
supports getting the service boundaries as a direct
query, as well as a request to list the services supported.  LoST  
servers are identified using U-NAPTR, and there
is a mechanism for tree traversal and referral for finding the server  
authoritative for a particular location, service
tuple.

The infrastructure deployment needed for a new LoST service currently  
involves registering an appropriate service
URN, deploying the servers which map locations to specific URIs, and  
making clients aware of the service.  While
clients can discover supported services using the listService  
command, this carries no direct information about the
nature of the service, so some out-of-band information channel is  
needed to explain the value of any new service.

It also requires that the service be delivered in a way that has  
location-specific catchment areas.  Delivery of
emergency services has this because of a mapping of PSAPs (public  
safety access points) and emergency responders
to specific areas by public safety officials.  Some other industries  
have delineated areas which are associated with specific
providers.  In the U.S., for example, Major League Baseball has  
delineated areas which are associated with specific teams;
while anyone can be a fan of any team from anywhere, there are rules  
which relate to specific territories and a default
team for that territory.  In most cases, though, this is not done  
through industry-scale cooperative agreements; a particular
provider may divide up the territory associated with their stores,  
but the same division is unlikely to hold for other providers,
absent regulation.  So Pizza Igloo and Pizza Lean-to are both likely  
to divide up their territories, but the division will likely
not match.  Taxi services, on the other hand, might match because of  
licensing regulations, but this is likely due to the
aggregation of specific local licenses rather than an industry-wide  
delineation or large catchment-area assignment.

There are three main branches of deployment, in other words.  The  
first is for services where catchment areas have
been assigned by jurisdiction, as PSAPs are assigned.  Identifying  
the post office responsible for mail delivery to
a specific address, for example, would be jurisdictionally  
determined.  The second is for services delivered by specific
branches of a single provider.  These might be physical services (the  
Pizza Lean-to which will deliver to an address)
or online services (World of Statecraft might offer to associate new  
players with political parties forming in their local
areas in order to foster team creation, even though the team's  
efforts in WoS would not be locally bound).  The third is
deployment using aggregators who determine what services from various  
providers are available in specific areas
and make that available; such an aggregator might get the service  
areas for Pizza Lean-to, Pizza Igloo, and Pizza Yurt,
then provide any salient contact URIs when a lookup for pizza  
services occurs.

An architectural problem which arises with each of these three models  
sharing a protocol is a strong possibility of namespace
partition at the URN level.  For the jurisdictional services like sos  
or postal, it is easy to see how to resolve what the service
names should be and how registration can proceed.  But should it be  
urn:service:pizza or urn:service:food.delivery.pizza?
Should individual providers' lost services be urn:service:Pizza- 
Leanto.delivery or urn:service:food.delivery.Pizza-Leanto?
Having IANA organize this set of namespaces for all services which  
might be delivered anywhere seems like a non-starter.
Having a small set of widely agreed services registered under  
urn:service seems possible, but IANA doesn't have the time,
attention, or expertise to act as Linnaeus to the service world.  
That, in turn, tends to imply that there will be multiple
trees, each run by a different organization, if LoST becomes common;  
the other option, of course, is that LoST stays in
the jurisdictional space and other mechanisms become popular for the  
other two.

Practically speaking, the tuple of location and any service- 
identifying URI is sufficient once an appropriate LoST server
has been found, so the problem devolves to one of configuration/ 
discovery.   That problem, though, could hit us hard
in retaining user control.  Current location-based service delivery  
mechanisms have a strong flavor of provider lock-in,
especially on the ISP side; moving to LoST could move to a more fully  
independent LBS industry, but that will not
work if the only LoST server discovery mechanisms rely on ISP  
deployments to maintain.   Further work on discovery,
in other words, may be needed to maintain end-user independence of  
operator control.