LoST - irtlab/lost GitHub Wiki

Many internet applications and protocols must dynamically locate the entities providing a particular service. The Domain Name System (DNS)[RFC 1035] is the most commonly used protocol for this purpose. DNS can map hierarchical service identifiers to service providers using a combination of resource records [RFC 2782, RFC 2915, RFC 3401]. Thus, DNS provides a means to discover service implementations by the service's identity.

Some applications need to dynamically discover services by combining the service's identity and the requestor's location. The location information could be geographic coordinates or a civic address. Consider an emergency calling application where the caller dials 911 and expects to reach a nearby answering service that serves his or her current location.

Location-to-Service Translation Protocol (LoST) [RFC 5222] is a HTTP-XML protocol for mapping service identifiers and location in the form of geographic coordinates or a civic address to entities that provide the service for the client's location. The protocol was designed for emergency communications with (fixed and mobile) phones as clients but could be useful in cyber-physical systems, where programs often operate on geographically addressed devices. Unlike DNS-based service discovery, LoST considers the client's location when selecting the appropriate mapping. The protocol was initially designed to determine the most appropriate emergency call answer point based on the caller's location. Incorporating geographic or civic location in the mapping process allows LoST to resolve services that are not necessarily closest to the client with respect to the network topology.

The LoST protocol uses HTTP to transport requests and responses and XML to encode data. Geographic and civic coordinates are encoded in a subset of the Presence Information Data Format Location Object (PIDF-LO) [RFC 4119, RFC 5139, RFC 5491, RFC 7459]. The PIDF-LO format uses a subset of the Geography Markup Language (GML) [GML] to convey geographic location. The civic address format was initially defined in [RFC 4776]. The LoST protocol provides three primary functions: find service by location, obtain a service boundary, and list supported services at a server or location. The LoST protocol provides recursive and iterative resolving and support for caching.

The LoST specification only defines the syntax and semantics of requests and responses between a client and a LoST server. It does not specify how to design a scalable service supporting the LoST protocol. Two related RFCs [RFC 5582,RFC 6739] propose a global, scalable, resilient, and administratively-distributed service architecture for the LoST protocol. In the architecture, LoST servers are organized in trees according to their coverage regions, where the coverage region of a server higher up in the tree covers the coverage regions of its children. A separate tree for each pair of service type and location profile is created. Designated servers known as forest guides keep track of all existing trees. The client then accesses such service through a resolver that keeps track and maintains trust with the forest guides.

The LoST protocol is extensible. Two extensions have been defined so far. RFC 6197 [RFC 6197] specifies how a LoST server communicates the service boundary of a listed service to the client. RFC 6451 [RFC 6451] defines additional mapping parameters to allow a LoST client to obtain $N$ nearest services, services within a distance $X$, or list services that serve a particular location or area. This extension makes the LoST framework applicable in other application domains, e.g., discovering the nearest restaurants or restaurants that serve a particular area.

⚠️ **GitHub.com Fallback** ⚠️