Location-to-URL Mapping Architecture and Framework
RFC 5582

Network Working Group                                     H. Schulzrinne
Request for Comments: 5582                                   Columbia U.
Category: Informational                                   September 2009

           Location-to-URL Mapping Architecture and Framework

Abstract

This document describes an architecture for a global, scalable,
resilient, and administratively distributed system for mapping
geographic location information to URLs, using the Location-to-Service
Translation (LoST) protocol.  The architecture generalizes well-known
approaches found in hierarchical lookup systems such as DNS.

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Schulzrinne                  Informational                      [Page 1]
RFC 5582                        MapArch                   September 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview of Architecture . . . . . . . . . . . . . . . . . . .  4
     4.1.  The Principal Components . . . . . . . . . . . . . . . . .  4
     4.2.  Minimal System Architecture  . . . . . . . . . . . . . . .  6
   5.  Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Trees: Maintaining Authoritative Knowledge . . . . . . . . . .  8
     7.1.  Basic Operation  . . . . . . . . . . . . . . . . . . . . .  8
     7.2.  Answering Queries  . . . . . . . . . . . . . . . . . . . . 10
     7.3.  Overlapping Coverage Regions . . . . . . . . . . . . . . . 11
     7.4.  Scaling and Reliability  . . . . . . . . . . . . . . . . . 11
   8.  Forest Guides  . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Configuring Service Numbers  . . . . . . . . . . . . . . . . . 13
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     12.2. Informative References . . . . . . . . . . . . . . . . . . 16

1.  Introduction

   It is often desirable to allow users to access a service that
   provides a common function but that is actually offered by a variety
   of local service providers.  In many of these cases, the service
   provider chosen depends on the location of the person wishing to
   access that service.  Among the best-known public services of this
   kind is emergency calling, where emergency calls are routed to the
   most appropriate public safety answering point (PSAP) based on the
   caller's physical location.  Other services, from food delivery to
   directory services and roadside assistance, also follow this general
   pattern.  This is a mapping problem [RFC5012], where a geographic
   location and a service identifier [RFC5031] is translated into a set
   of URIs, the service URIs, that allow the Internet system to contact
   an appropriate network entity that provides the service.

   The caller does not need to know from where the service is being
   provided, and the location of the service provider may change over
   time, e.g., to deal with temporary overloads, failures in the primary
   service provider location, or long-term changes in system
   architecture.  For emergency services, this problem is described in
   more detail in [ECRIT-FRAME].

Schulzrinne                  Informational                      [Page 2]
RFC 5582                        MapArch                   September 2009

   The overall emergency calling architecture [ECRIT-FRAME] separates
   mapping from placing calls or otherwise invoking the service, so the
   same mechanism can be used to verify that a mapping exists ("address
   validation") or to obtain test service URIs.

   Mapping locations to URIs that describe services requires a
   distributed, scalable, and highly resilient infrastructure.
   Authoritative knowledge about such mappings is distributed among a