ECRIT H. Schulzrinne Internet-Draft Columbia U. Intended status: Informational December 17, 2006 Expires:
February 8,June 20, 2007 August 7, 2006Location-to-URL Mapping Architecture and Framework draft-ietf-ecrit-mapping-arch-00draft-ietf-ecrit-mapping-arch-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 8,June 20, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs.URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. The architecture does not depend on using a specific protocol, but does require that protocols can summarize the coverage region of a node.Table of Contents 1. The Mapping Problem . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3. 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Introduction . . . . . . . . . . . . . . . . . . .. . . . . 5 4.14 4. Overview of Operation . . . . . . . .Architecture . . . . . . . . . . 5 4.2 Seekers: The Users of the Mapping System. . . . . . . . . 5 4.3 Trees: Authoritative Knowledge . . . . . . . . . . . . . . 6 4.4 Forest Guides: Finding the Right Tree . . . . . . . . . . 7 4.5 Resolvers: Finding Forest Guides and Caching Data . . . . 7 4.64.1. Minimal System Architecture . . . . . . . . . . . . . . . 76 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. 6 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Trees . . . . . . . . . . . . . . . .. 7 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8 7.17.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 7.27.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10 7.37.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11 7.410 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations .Configuring Service Numbers . . . . . . . . . . . . . . . . . 12 10. IANASecurity Considerations . . . . . . . . . . . . . . . . . . . . 1314 11. ReferencesIANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgments . . . . 13 11.1 Normative References. . . . . . . . . . . . . . . . . . 13 11.2 Informative. 15 13. References . . . . . . . . . . . . . . . . . 13 Author's Address. . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . 14 A. Configuring Emergency Dial Strings. . . . 15 13.2. Informative References . . . . . . . . . 14 B. Acknowledgments. . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 1. The Mapping Problem One of the central problems of providing emergency services to Internet systemsIt is often desirable to map geographic locationallow users to access a set of emergency services, represented by PSAPs, that can provide assistance forservice that particular location. This is a mapping problem, whereprovides a geographic locationcommon function, but is translated intoactually offered by a setvariety of URIs that allowlocal service providers. In many of these cases, the Internet systemservice provider chosen depends on the location of the person wishing to contact anaccess that service. Among the best-known public services of this kind is emergency calling, where emergency calls are routed to the most appropriate network entity.public safety answering point (PSAP), based on the caller's physical location. Other services, from food delivery to directory services mayand roadside assistance, also find such location-to-URI mappingsfollow this general pattern. This is a mapping problem , where a geographic location and a service identifier (URN)  is translated into a set of use.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 where the service is being provided from, 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 . The overall emergency calling architecture  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 describing services requires a distributed, scalable and highly resilient infrastructure. Authoritative knowledge about such mappings is distributed among a large number of autonomous entities that may have no direct knowledge of each other. In this document, we describe an architecture for such a global service. It allows significant freedom to combine and split functionality among actual servers and imposes few requirements as to who should operate particular services. Besides determining the PSAPservice URI, end systems also need to determine the local emergency dial strings.service numbers. As discussed in Appendix A,Section 9, the architecture described here can also address that problem. The architecture described below does not depend on a particular mapping protocol, but naturally assumes that such protocols provide certain features, such as the ability to discoverhere uses the coverage regionLocation-to-Service Translation (LoST)  protocol, although much of tree nodes. In this introduction, we describethe four participants indiscussion would also apply for other mapping protocols satisfying the system at a high level. Each role will later be introduced in more detail.mapping requirements . 2. Terminology In this document, the key words "MUST", "MUSTNOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119  and indicate requirement levels for compliant implementations. 3. Definitions [Note: The terminology below is still evolving and needs refinement.]In addition to the terms defined in ,, this document uses the following terms to describe LoST:LoST clients and servers: authoritative mapping server (AMS): ResolverAn authoritative mapping server (AMS) is a LoST server that can provide the authoritative answer to a particular set of queries, e.g., covering a set of PIDF-LO civic labels or a particular region described by a geometric shape. In some (rare) cases of territorial disputes, two resolvers may be authoritative for the same region. An AMS may redirect or forward a query to other AMS within the tree. caching resolver: A caching resolver is contacted by a seeker, consults a forest mapping server and then resolves the query using an appropriate tree.child: A child is a resolveran AMS that is authoritative for a subregion of a particular server.another AMS. A child can in turn be parent.parent for another AMS. (tree node) cluster: A node cluster is a group of resolver (servers)LoST servers that all share the same mapping information and return the same results for queries. Clusters provide redundancy and share query load. Clusters are fully-meshed, i.e., they all exchange updates with each other. complete:forest guide: A civic mapping region is considered complete if it covers a set of hierarchical labels in its entirety, i.e., there is no other resolver that covers parts of the same region. (A complete mapping may have children that cover strict subsets of this region.) For example, a region spanning the whole country is complete, but a region spanning only some of the streets in a city is not. forest guide: A forest guide has knowledge of the coverageforest guide has knowledge of the coverage region of all trees. mapping: A mapping is a short-hand for 'mapping from a location object to one or more URLs describing either another mapping server or the desired PSAP URLs.'service URLs'. parent: A mapping server that covers the region of all of its children. A mapping server without a parent is a root resolver. peer:resolver: A resolver maintains associations other resolvers, called peers. Peers synchronize their region maps.is contacted by a seeker, consults a forest mapping server and then resolves the query using an appropriate tree. seeker: The resolver, ESRP or end systemA seeker is a LoST client requesting a mapping. A seeker does not provide mapping services to others, but may cache results for its own use. region map: A data object describing a contiguous area covered by a resolver,an AMS, either as a subset of a civic address or a geometric object. root region map: A data object describing a contiguous area covered by a resolver, with no parent map.resolver: The server providing (part of) the mapping service.Resolvers cooperate to offer thecontact authoritative mapping serviceservers to seekers.answer queries by seekers, and may cache query results. tree: A tree consists of a self-contained hierarchy of authoritative mapping servers. Each tree exports its coverage region to the forest mapping servers. 4. Introduction 4.1Overview of OperationArchitecture In short, end users of the LoST-based  mapping mechanism, called seekers, contact resolvers that cache query results and know one or more "forest guides". Forest guides know the coverage region of trees and direct queries to the node at the top of the appropriate tree. Trees consist of authoritative mapping servers and maintain the authoritative mapping information. Figure 1 shows the interaction of the components. /-\ /-\ +-----+ +-----+ | S +******* R ********* FG *-----------------+ FG | \-/ \-/ | |* | | +--+--+ * +--+--+ | * | | * | | * | | * | /-\ +--+--+ * +--+--+ | R +------>+ FG +-----*-----------+ FG | \-/ | | * | | +--+--+ * +--+--+ | * | | * | | * | |*** ^ / \ / \ / \ / \ / \ / \ / \ / \ ----------- ----------- tree tree Architecture diagram, showing seekers (S), resolvers (R), forest guides (FG) and trees. The star (*) line indicates the flow of the query and responses in recursive mode. Figure 1 4.2 Seekers:The Usersmapping function for the world is divided among trees. The collection of trees may not cover the Mapping System Clients desiring mappingswhole world and trees are knownadded and removed as seekers. Thus, seekers arethe end usersorganization of themapping information. Examplesdata changes. We call the collection of such clients include SIP proxy servers or SIP end systems wishing to place an emergency call. Seekers provide location information describingtrees a small geographic area and obtain one or more URIs describingforest. There is no limit on the service. Seekers may need to obtain this information in several steps, i.e., they may obtain pointers to intermediate servers that lead them closer tonumber of trees within the final mapping. Seekers MAY cache query results for later use,forest, but otherwise have no obligations to other entities inthe system. 4.3 Trees: Authoritative Knowledge The architecture assumesauthor guesses that authoritative knowledge about the mapping data is distributed among many independent administrative entities, but clients (seekers) needingthe information may potentially need to find out mapping about any spot on earth. (Extensions to extra-terrestrial applications are left for future exploration.) Different typesnumber of services may divide responsibility differentlytrees will likely be somewhere between a few hundred and are independent ofa few thousand. The lower estimate would apply if each other. Each node participating incountry operates one tree. We assume that tree coverage information changes relatively slowly, on the order of less than one change per year per tree, although the system has authoritative knowledge about mappings within itsimposes no specific threshold. Tree coverage region, typically, but not necessarily, a contiguous geographic region described bywould change, for example, if a polygon in geospatial coordinatescountry is split or a set of civic address descriptors (e.g., "country = DE, A1 = Bavaria"). These coveragemerged or if two trees for different regions may be aligned with political boundaries, but thatbecome part of a larger tree. (On the other hand, information within a tree is not required. In most cases,likely to avoid confusion, only one nodechange much more frequently.) 4.1. Minimal System Architecture It is responsible forpossible to build a particular geographic or civic location, but thefunctioning system can also deal with cases where coverage regions overlap. The architecture assumes that knowledge about mappings is hierarchical, represented as a tree. Each tree node knows the coverage regionconsisting only of its childrenseekers and sends queries to the appropriate server "down" the tree. There are no assumptions about the coverage regionresolvers if these resolvers have other means of a tree.obtaining mapping data. For example, a tree could cover a single city, or a state/province or a whole country. Nodes withincompany acting as a tree needmapping service provider could collect mapping records manually and make them available to loosely coordinatetheir operation, butcustomers through the resolver. While feasible as a starting point, such an architecture is unlikely to scale globally. Among other problems, it becomes very hard for providers of authoritative data to ensure that all such providers have up-to-date information. If new trees are set up, they do not needwould somehow make themselves known to these providers. Such a mechanism would be operated by the same administrator. Thus,similar to the mapping functionold "hosts.txt" mechanism for distributing host information in the world is divided among trees. The collection of trees may not coverearly Internet before DNS was developed. Below, we describe the whole world and treesoperation of each component in more detail. 5. Seeker Clients desiring location-to-service mappings are added and removedknown as the organizationseekers. Seekers are consumers of mapping data changes. We call the collection of trees a forest. There is no limit on the number of trees within the forest, butand originate LoST queries as LoST protocol clients. Seekers do not answer LoST queries. They contact either forest guides or resolvers to find the author picturesappropriate tree that the number of trees will likelycan authoritatively answer their questions. Seekers can be somewhere between a few hundred and a few thousand. The lower estimate would apply if each country operates one tree. We assume that tree coverageend systems or call routing entities such as SIP proxy servers. Seekers may need to obtain mapping information changes relatively slowly, on the order of a few changes per year per tree, althoughin several steps, i.e., they may obtain pointers to intermediate servers that lead them closer to the system imposesfinal mapping. Seekers MAY cache query results for later use, but otherwise have no specific threshold. (Toobligations to other entities in the system. Seekers need to be sure,able to identify appropriate resolvers. The mechanism for providing seekers with that information within a treeis likely to change much more frequently.) 4.4 Forest Guides: Findingdiffer depending on who operates the Right Tree Unfortunately, just having trees covering various regions ofresolvers. For example, if the world is not sufficient as a client ofvoice service provider operates the mapping protocol would not generally be able to keep trackresolver, it might include the location of allthe treesresolver in the forest. To facilitate orientation among the trees, we introduce a "forest guide". It isSIP configuration information it distributes to its user agents. An Internet access provider or enterprise can provide a server that keeps track of the coverage regions of the trees. For scalability and reliability, there will needpointer to bea large number of forest guides, all providingresolver via DHCP . In an ad-hoc or zero-configuration environment, appropriate service directories may advertise resolvers. Like other entities in the same information. A seekersystem, seekers can contact any forest guide and will thencache responses. This is particularly useful if the response describes the result for a civic or geospatial region, rather than just a point. For example, for mobile nodes, seekers would only have to update their resolution results when they leave the coverage area of a service provider, such as a PSAP for emergency services, and can avoid repeatedly polling for this information whenever the location information changes slightly. (Mobile nodes would also need a location update mechanism that is either local or triggered when they leave the current service area.) This will likely be directedof particular benefit for seekers representing a large user population, such as the outbound proxy in a corporate network. For example, rather than having to query separately for each cubicle, information provided by the right tree or, rarely, setauthoritative node may indicate that the whole campus is covered by the same service provider. Given this caching mechanism and cache lifetimes of trees. 4.5 Resolvers: Finding Forest Guidesseveral days, most mobile users traveling to and Caching Datafrom work would only need to obtain service area information along their commute route once during each cache lifetime. 6. Resolver A seeker can contact a forest guide (see below) directly, but may not be able to easily locate such a guide. In addition, seekers in the same geographic area may already have asked the same question. Thus, it makes sense to introduce another entity, known as a resolver,resolver in the architecture, that knows how to contact one or more forest guides and caches earlier queries to accelerate the response to mapping queries. 4.6 Minimal System Architecture It is possible to build a functioning system consisting only of seekersqueries and resolvers if these resolvers have other meansto improve the resiliency of obtaining mapping data. For example,the system. From a company acting asprotocol perspective, a mapping service provider could collect mapping records manually and make them available to their customers throughresolver acts in the resolver. While feasiblesame way as a starting point, such an architecture is unlikely to scale globally. Among other problems,seeker, except that it becomes very hardknows one or more forest guides. ISPs or VSPs would include the address of a suitable resolver in their configuration information, i.e., in SIP configuration for providersa VSP or DHCP  for an ISP. Resolvers are manually configured with the name of one or more forest guides. 7. Trees: Maintaining Authoritative Knowledge 7.1. Basic Operation The architecture assumes that authoritative knowledge about the mapping data is distributed among many independent administrative entities, but clients (seekers) needing the information may potentially need to ensure that all such providers have up-to-date information. If new treesfind out mapping about any spot on earth. (Extensions to extra-terrestrial applications are set up, they would somehow make themselves knownleft for future exploration.) Information is organized hierarchically, in a tree, with tree nodes representing larger geographic areas pointing to these providers. Suchseveral child nodes each representing a mechanism wouldsmaller area. Each tree node can be similar toa cluster of LoST servers that all contain the old "hosts.txt" mechanism for distributing hostsame information inand back up each other. Each tree can map a location described by civic and geographic coordinates for one type of service (such as 'sos.police', 'sos.fire' or 'counseling'), although nothing prevents re-using the early Internet. 5. Seeker Seekers are consumerssame tree for multiple different services. The collection of mapping dataall trees for one service is known as a forest. Each tree node cluster knows the coverage region of its children and originate queries. Seekers do not answer queries. They contact either forest guides or resolverssends queries to findthe appropriate server "down" the tree. Each such tree that cannode knows authoritatively answer their questions. As noted inabout the introduction, seekers canservice mappings for a particular region, typically, but not necessarily, contiguous. The region can be end systemsdescribed by a polygon in geospatial coordinates or call routing entities such as SIP proxy servers. Seekers need toa set of civic address descriptors (e.g., "country = DE, A1 = Bavaria"). These coverage regions may be able to identify appropriate resolvers. The mechanism for providing seekersaligned with political boundaries, but that informationis likely to differ depending on who operates the resolvers. For example, if the voice service provider operates the resolver, it might include the location of the resolver in the SIP configuration information it distributes to its user agents. An Internet access provider might provide a pointer to a resolver via DHCP.not required. In an ad-hoc or zero- configuration environment, appropriate service directories may advertise resolvers. For emergency calling, seekers could issue queries at boot time, periodically when cached information expires ormost cases, to avoid confusion, only when placing an emergency call. Itone cluster is probably unnecessary to continuously update mapping informationresponsible for seekers representing a small user population, e.g.,a single phoneparticular geographic or residential SIP proxy. Like other entities incivic location, but the system, seekerssystem can cache responses. This is particularly useful if the response describesalso deal with cases where coverage regions overlap. There are no assumptions about the result forcoverage region of a region, not justtree as a point.whole. For example, for mobile nodes, seekers would only havea tree could cover a single city, or a state/ province or a whole country. Nodes within a tree need to updateloosely coordinate their resolution results whenoperation, but they leave the coverage area of a PSAP and can avoid polling for this information. This will likely be of particular benefit for seekers representing a large user population, such as the outbound proxy in a corporate network. For example, rather than having to query separately for each cubicle, information provided by the authoritative node may indicate that the whole campus is covered by the same PSAP. 6. Resolver Resolvers mediate between seekers and forest guides. Their primary role is to avoid having seekers find forest guides on their own. Unlike forest guides, resolvers do not store worldwide coverage maps, but they may cache regions returned as part of query results. As noted earlier, seekers can contact forest guides directly. From a protocol perspective, a resolver acts in the same way as a seeker, except that it knows one or more forest guide. ISPs or VSPs would include the address of a suitable resolver in their configuration information, i.e., in SIP configuration for a VSP or DHCP for an ISP. Resolvers are manually configured with the name of one or more forest guides. 7. Trees 7.1 Basic Operation As noted in the introduction, trees are the authoritative source of mapping data. Each tree can map a location described by civic and geographic coordinates for one type of service (such as 'police' or 'fire'), although nothing prevents re-usingdo not need to be operated by the same tree for multiple different services. The collection of trees for one service is known as a forest.administrator. The tree architecture is roughly similar to the domain name system (DNS), except that delegation is not by label, but rather by region. (Naturally, DNS does not have the notion of forest guides.) One can also draw analogies to LDAP, when deployed in a distributed fashion. Tree nodes maintain two types of information, namely coverage regions and mappings. Coverage regions describe the region served by a child node in the tree and point to a child node for further resolution. Mappings contain an actual service URI leading to a PSAPservice provider or another signaling server representing a group of PSAPs. To provide redundancy, a mapping entry can also contain multiple URLs, indicating both primary and backup services. For example, itservice providers, which in turn might contain both a local PSAP and a state agency that takes over if the local PSAP fails. Unlike DNS NAPTR and SRV facilities, these can survive DNS failures and thus provide an additional, complementary mechanismfurther route signaling requests to introduce redundancy services.more servers covering smaller regions. Leaf nodes, i.e., nodes without children, only maintain mappings, while tree nodes above the leaf nodes only maintain coverage regions. An example for emergency services of a leaf node entry is shown below, indicating how queries for three towns are directed to different PSAPs. Queries for Englewood are directed to another LoST server instead. country A1 A2 A3 resource US NJ Bergen Leonia sip:email@example.com US NJ Bergen Fort Lee sip:firstname.lastname@example.org US NJ Bergen Teaneck sip:email@example.com US NJ Bergen Englewood lost:englewoodnj.gov .... Coverage regions are described by sets of polygons enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs a point- in-polygon operation to find the polygon that contains the query point. (More complicated geometric matching algorithms may be added in the future.) For example, a state-level tree node for New Jersey in the United States may contain the following coverage region entries, indicating that any query matching a location in Bergen County, for example, would be redirected or forwarded to the node located at bergen.nj.example.org. There is no requirement that all child nodes cover the same level within the civic hierarchy. As an example, in the table below, the city of Newark has decided to be listed directly within the state node, rather than through the county. Longest-match rules allow partial coverage, so that for queries for all other towns within Essex county would be directed to the county node for further resolution. In the example below, we use a fictitious URL scheme, 'rp', to identify the resolution protocol. In actual use, each entry would have one or more URLs pointing to resolution servers for different protocols. Each entry may also contain multiple URLs for the same protocol to indicate primary and backup services.C A1 A2 A3 resource US NJ Atlantic * rp://atlantic.nj.example.org/soslost:atlantic.nj.example.org/sos US NJ Bergen * rp://bergen.nj.example.org/soslost:bergen.nj.example.org/sos US NJ Monmouth * rp://monmouth.nj.example.org/soslost:monmouth.nj.example.org/sos US NJ Essex * rp://essex.nj.example.org/soslost:essex.nj.example.org/sos US NJ Essex Newark rp//newark.example.com/soslost:newark.example.com/sos .... Thus, there is no substantial difference between coverage region and mapping data. The only difference is that coverage regions return mapping protocolLoST URLs, while mapping entries contain PSAPservice URLs. Mapping entries may be specific down to the house or floor level or may only contain street-level information. For example, in the United States, civic mapping data for emergency services is generally limited to address ranges ("MSAG data"), so initial mapping databases may only contain street-level information. To automate operations, a suitable mapping protocol would thus need to be ablethe maintenance of trees, the LoST synchronization mechanism  allows nodes to query other nodes for theirmapping data and coverage region.regions. In the example above, the state-run node would query the county nodes and thus aggregateuse the coverage data.records returned to distribute incoming LoST queries to the county nodes. Conversely, nodes could also contact their parent nodes.nodes to tell them about their coverage region. There is some benefit of child nodes contacting their parents, as this allows changes in coverage region to propagate quickly up the tree. 7.27.2. Answering Queries Within a tree, the basic operation is straightforward: A query reaches the root of the tree. That node determines which coverage region matches that request and forwards the request to the URL indicated in the coverage region record, returning a response to the querier when it in turns receives an answer (recursion). Alternatively, the node returns the URL of that child node to the querier.querier (iteration). This process applies to each node, i.e., a node does not need to know whether the original query came from a parent node, a seeker, a forest guide or a resolver. For efficiency, a node MAY return region information instead of a point answer. Thus, instead of returning that a particular geospatial coordinate maps to a service or mapping URL, it MAY return a polygon indicating the region for which this answer would be returned, along with expiration time (time-to-live) information. The querying node can then cache this information for future use. For civic coordinates, trees may not include individual entriesmapping records for each floor, house number or street. To avoid giving the wrong indication that a particular location has been found valid, the protocol SHOULD return an indicationLoST can indicate which parts of the location information have actually been mapped. 7.3used to look up a mapping. 7.3. Overlapping Coverage Regions In some cases, coverage regions may overlap, either because there is a dispute as to who handles a particular geographic region or, more likely, since the resolution of the coverage map may not be sufficiently high. For example, a node may "shave some corners" off its polygon, so that its coverage region appears to overlap with its geographic neighbor. For civic coordinates, houses on the same street may be served by different PSAPs. The mapping mechanism needs to work even if a coverage map is imprecise or if there are disputes about coverage. The solution for overlapping coverage regions is relatively simple. If a query matches multiple coverage regions, the node returns all URLs, in redirection mode, or queries both children, if in recursive mode. If the overlapping coverage is caused by imprecise coverage maps, only one will return a result and the others will return an error indication. If the particular location is disputed territory, the response will contain all answers, leaving it to the querier to choose the preferred solution or trying to contact all services in turn. 7.47.4. Scaling and Reliability Since they provide authoritative information, tree nodes need to be highly reliable. Thus, while this document refers to tree nodes as logical entities within the tree, an actual implementation would likely replicate node information across several servers, forming a cluster. Each such node would have the same information. Standard techniques such as DNS SRV records can be used to select one of the servers. Replication within the cluster can use any suitable protocol mechanism, but a standardized incremental update mechanism makes it easier to spread those nodes across multiple independently- administered locations. The techniques developed for meshed SLP  are applicable here. 8. Forest Guides Forest guides distribute records describing the coverage region for trees. For authenticity, the records are digitally signed. They are used by resolvers and possibly seekers to findUnfortunately, just having trees covering various regions of the appropriate tree for a particular area. All forest guides should have consistent information, i.e.,world is not sufficient as a collectionclient of allthe coverage regionsmapping protocol would not generally be able to keep track of all the trees. A tree node attrees in the forest. To facilitate orientation among the trees, we introduce a "forest guide". It is a server that keeps track of the coverage regions of the trees. For scalability and reliability, there will need to be a large number of forest guides, all providing the same information. A seeker can contact any forest guide and will then be directed to the right tree or, rarely, set of trees. Forest guides do not provide mapping information themselves. Introducing forest guides avoids creating a global root, with the attendant management and control issues. Trees can also restrict their cooperation to parts of the information. For example, if country C does not recognize country T, C can propagate tree regions for all but T. For authenticity, the records SHOULD be digitally signed. They are used by resolvers and possibly seekers to find the appropriate tree for a particular area. All forest guides should have consistent information, i.e., a collection of all the coverage regions of all the trees. A tree node at the top of a tree can contact any forest guide and inject new coverage region information into the system. One would expect that each tree announces its coverage to more than one forest guide. Each forest guide peers with one or more other guides and distributes new coverage region announcements to all other guides. Forest guides fulfill a similar role to root servers in DNS. However, their number is likely to be larger, possibly counted in hundreds. They distribute information, signed for authenticity, offered by trees. Forest guides can, in principle, be operated by anybody, including voice service providers, Internet access providers, dedicated services providers and enterprises. As in routing, peering with other forest guides implies a certain amount of trust in the peer. Thus, peering is likely to require some negotiation between the administering parties concerned, rather than automatic configuration. The mechanism itself does not imply a particular policy as to who gets to advertise a particular coverage region. 9. Security ConsiderationsConfiguring Service Numbers The architecture addresses the following security issues, usually throughsection below is not directly related to the underlying transport security associations: Server impersonation: Seekers, cluster members and peers can assure themselvesproblem of the identitydetermining service location, but is an instance of the remote partymore generic problem solved by using the facilities in the underlying channel security mechanism,this architecture, namely mapping location information to service-related parameters, such as TLS. Query or query result corruption: To avoid that an attacker can modify the query or its result,service numbers. For the architecture RECOMMENDSforeseeable future, some user devices and software will emulate the useuser interface of channel security, such as TLS. Results SHOULD also be digitally signed, e.g., using XML digital signatures. Note, however, that simple origin assertion may not providea telephone, i.e., the end system with enough useful information as it has no goodonly way of knowing that a particular signer is authorizedto represententer call address information is via a particular geographic area. It might be necessary that certain well-known Certificate Authorities (CAs) vet sources12-button keypad with digits and the asterisk and hash symbol. These devices use service numbers to identify services. The best-known examples of mapping informationservice numbers are emergency numbers, such as 9-1-1 in North America and provide special certificates for that purpose. In1-1-2 in Europe. However, many cases, a seeker willother public and private service numbers have to trust itsbeen defined, ranging in the United States from 3-1-1 for non- emergency local resolvergovernment services to vet information4-1-1 for trustworthiness;directory assistance to various "800" numbers for anything from roadside assistance to legal services to home-delivery food. Such service numbers are likely to be used until essentially all communication devices feature IP connectivity and an alphanumeric keyboard. Unfortunately, for emergency services, more than 60 emergency numbers are in turn,use throughout the resolver may rely on trusted forest guidesworld, with many of those numbers serving non-emergency purposes elsewhere, e.g., identifying repair or directory services. Countries also occasionally change their emergency numbers to steer itconform to regional agreements. An example is the correct information. Region corruption: To avoid that a third party or an untrustworthy memberintroduction of "1-1-2" for countries in Europe. Thus, a server population introduces a region mapsystem that it is not authorized for, any node introducing a new region map MUST sign the object by encapsulatingallows devices to be used internationally to place calls needs to allow devices to discover service numbers automatically. In the data into a CMS wrapper. A recipient MUST verify, throughInternet-based system proposed here , these numbers are strictly used as a local policy mechanism, thathuman user interface mechanism and are generally not visible in call signaling messages, which carry the signing entity is indeed authorizedservice URN  instead. For the best user experience, systems should be able to speak for that region. Determining who can speak for a particular regiondiscover two sets of service numbers, namely those used in the user's home country and in the country the user is inherently difficult unless therecurrently visiting. The user is most likely to remember the former, but a small set of authorizing entities that participantscompanion borrowing a device in the mapping architecture can trust. Receiving systems should be particularly suspicious ifan existing region mapemergency, say, may only know the local emergency numbers. Determining home and local service numbers is replaced witha new one withconfiguration problem, but unfortunately, existing configuration mechanisms are ill-suited for this purpose. For example, a new mapping address. In many cases, trust willDHCP server might be mediated: A seeker will have a trust relationship withable to provide the local service numbers, but not the home numbers. When virtual private networks (VPNs) are used, even DHCP may provide numbers of uncertain origin, as a resolver. The resolver, in turn, willuser may contact a trusted forest guide. Additional threats that needto be addressed by operational measures include denial-of-service attacks. 10. IANA Considerations Since this document describes an architecture, not a protocol, it does not ask IANAthe home network or some local branch office of the corporate network. Similarly, SIP configuration  would be able to registerprovide the numbers valid at the location of the SIP service provider, but even a SIP service provider with national footprint may serve customers that are visiting any protocol constants. 11. References 11.1 Normative References  Bradner, S., "Key wordsnumber of other countries. Also, while initially there are likely to be only a few service numbers, e.g., for use in RFCsemergency services, the LoST architecture can be used to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  Gulbrandsen, A., Vixie, P.,support other services, as noted. Configuring every local DHCP or SIP configuration server with that information is likely to be error-prone and L. Esibov, "A DNS RRtedious. For these reasons, the LoST-based mapping architecture supports providing service numbers to end systems based on caller location. The mapping operation is almost exactly the same as for specifyingdetermining the locationservice URL. The mapping can be obtained either along with determining the service URL or separately. The major difference between the two requests is that service numbers often have much larger regions of services (DNS SRV)", RFC 2782, February 2000.  Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.  Rosen, B., "Dialstring parametervalidity than the service URL itself. Also, the service number is likely to be valid longer than the service URL. Finally, an end system may want to look up the service number for its home location, not just the Session Initiation Protocol Uniform Resource Identifier", draft-rosen-iptel-dialstring-04 (workcurrent (visited) location. 10. Security Considerations Security considerations for emergency services mapping are discussed in progress), June 2006. 11.2 Informative References  Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.  Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced Service Location Protocol (mSLP)", RFC 3528, April 2003.  Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.  Krochmal, M. and S. Cheshire, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-03 (work in progress), July 2005., while  Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-08 (work in progress), March 2006.  Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-10 (work in progress), June 2006. Author's Address Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: firstname.lastname@example.org URI: http://www.cs.columbia.edu Appendix A. Configuring Emergency Dial Strings The section below is not directlydiscusses issues related to the problem of determiningservice location, but is an instanceURN, one of the more generic problem solved by this architecture, namelyinputs into the mapping location information to URLs. Forprotocol. LoST-related security considerations are naturally discussed in the foreseeable future, some user devicesLoST  specification. The architecture addresses the following security issues, usually through the underlying transport security associations: Server impersonation: Seekers, resolvers, fellow tree guides and software will emulatecluster members can assure themselves of the user interfaceidentity of a telephone, i.e.,the only way to enter call address information is via a 12-button keypad with digits andremote party by using the asterisk and hash symbol. Also, emergency numbers are likely to be used until essentially all communication devices feature IP connectivity and an alphanumeric keyboard. Unfortunately, more than 60 emergency numbers arefacilities in use throughoutthe world, with many of those numbers serving non-emergency purposes elsewhere, e.g., identifying repairunderlying channel security mechanism, such as TLS. Query or directory services. Countries also occasionally change their emergency numbers to conform to regional agreements. An example isquery result corruption: To avoid that an attacker can modify the introductionquery or its result, the architecture RECOMMENDS the use of 112 for countries in Europe. Thus, a system that allows devices tochannel security, such as TLS. Results SHOULD also be used internationally to place emergency calls needs to allow devices to discover emergency numbers automatically. Indigitally signed, e.g., using XML digital signatures. Note, however, that simple origin assertion may not provide the end system proposed, these numbers are strictly of local significance and are generally not visible in call signaling messages. For simplicitywith enough useful information as it has no good way of presentation, this section assumesknowing that emergency numbers are valid throughouta country, rather than, say, be restrictedparticular signer is authorized to represent a particular city. This appears likely togeographic area. It might be true in countriesnecessary that have sufficiently advanced infrastructure to contemplate deploying IP-based emergency calling solutions. In addition, the solution proposed also works ifcertain countries do not use a national emergency number. There is no requirementwell-known Certificate Authorities (CAs) vet sources of mapping information and provide special certificates for that purpose. In many cases, a country uses a single emergency number for all emergency services, such as fire, police, or rescue. For the best user experience, systems should be ableseeker will have to discover two sets of numbers, namely those used in the user's home country andtrust its local resolver to vet information for trustworthiness; in turn, the country the user is currently visiting. The user is most likelyresolver may rely on trusted forest guides to steer it to rememberthe former, but a companion borrowing a device in an emergency may only know the local emergency numbers. Determining home and local emergency numbers iscorrect information. Region corruption: To avoid that a configuration problem, but unfortunately, existing configuration mechanisms are ill-suited for this purpose. For example,third party or an untrustworthy member of a DHCPserver might be able to provide the local emergency number, butpopulation introduces a region map that it is not the home numbers. When virtual private networks (VPNs) are used, even DHCP may provide numbers of uncertain origin, asauthorized for, any node introducing a user may contact to the home network or some local branch office of the corporate network. Similarly, SIP configuration would be able to provide the numbers valid atnew region map MUST sign the location ofobject by encapsulating the SIP service provider, but evendata into a SIP service provider with national footprint may serve customersCMS wrapper. A recipient MUST verify, through a local policy mechanism, that are visiting any number of other countries. Since dial strings are represented as URLs ,the problem of determining local and home emergency numberssigning entity is a problem of mapping locationsindeed authorized to speak for that region. Determining who can speak for a particular region is inherently difficult unless there is a small set of URLs, i.e., exactly the problemauthorizing entities that participants in the mapping architecture is solving already. The mapping operation is almost exactly the same as for determining the emergency service URL. The only difference is thatcan trust. Receiving systems should be particularly suspicious if an existing region map is replaced with a new one with a new mapping address. In many cases, trust will be mediated: A seeker knows the civic location at least to the country level, it will use a query where the PIDF-LO only includes the country code. If it only knows its geospatial location, it has to include that longitude and latitude. The seeker uses the service identifiers "dialstring.sos", "dialstring.sos.fire", etc. The resolver returns the appropriate set of URLs and, ifwill have a geospatial location was usedtrust relationship with a resolver. The resolver, in the query, the current region map for the country. Within the mapping system, emergency calling regions are global information, i.e., they are distributed using the forest guide replication mechanism described earlier. Thus, everyturn, will contact a trusted forest guide has access to all region mappings. This makes it possibleguide. Additional threats that need to be addressed by operational measures include denial-of-service attacks . 11. IANA Considerations Since this document describes an architecture, not a seeker canprotocol, it does not ask IANA to register any resolverprotocol constants. 12. Acknowledgments Richard Barnes, Jong Yul Kim, Andrew Newton, Murugaraj Shanmugam, Richard Stastny, and Hannes Tschofenig provided helpful comments. 13. References 13.1. Normative References  Bradner, S., "Key words for this information, reducing the privacy threatuse in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-ietf-ecrit-lost-02 (work in progress), October 2006. 13.2. Informative References  Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced Service Location Protocol (mSLP)", RFC 3528, April 2003.  Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-09 (work in progress), October 2006.  Schulzrinne, H., "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-00 (work in progress), December 2006.  Rosen, B., "Framework for Emergency Calling in Internet Multimedia", draft-ietf-ecrit-framework-00 (work in progress), October 2006.  Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of revealing its location outsideEmergency Calling", draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006.  Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-12 (work in progress), August 2006.  Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 (work in progress), July 2006.  Schulzrinne, H., "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-05 (work in progress), August 2006.  Schulzrinne, H., "Synchronizing Location-to-Service Translation (LoST) Servers", draft-schulzrinne-ecrit-lost-sync-00 (work in progress), November 2006. Author's Address Henning Schulzrinne Columbia University Department of an emergency call.Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: email@example.com URI: http://www.cs.columbia.edu Full Copyright Statement Copyright (C) The privacy threatInternet Society (2006). This document is further reduced by the long-lived nature ofsubject to the information, i.e.,rights, licenses and restrictions contained in almost all cases,BCP 78, and except as set forth therein, the seeker will have already cachedauthors retain all their rights. This document and the national boundaryinformation or country information on its first visit to the country. Appendix B. Acknowledgments Jong Yul Kim, Andrew Newton, Richard Stastny, Hannes Tschofenigcontained herein are provided helpful comments.on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property StatementThe IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.Acknowledgment Funding for the RFC Editor function is currentlyprovided by the Internet Society.IETF Administrative Support Activity (IASA).