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.
この文書では、ロケーション・ツー・サービス翻訳（LOST）プロトコルを使用して、URLへの地理的位置情報をマッピングするための、グローバルスケーラブルな、弾性、及び管理分散システムのためのアーキテクチャを説明しています。アーキテクチャは、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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
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.
これにより、ユーザーは、共通の機能を提供しますが、それは実際に現地のサービスプロバイダーのさまざまなによって提供されるサービスにアクセスできるようにすることが望ましい場合が多いです。これらのケースの多くでは、選択したサービスプロバイダは、そのサービスにアクセスすることを希望する人の場所によって異なります。この種の最もよく知られている公共サービスの中に緊急コールが発信者の物理的な位置に基づいて、最も適切な公共安全応答ポイント（PSAP）にルーティングされている緊急呼び出しは、あります。その他のサービスには、ディレクトリサービスと道端での援助に食品配信から、また、この一般的なパターンに従ってください。これは、地理的位置とサービス識別子[RFC5031]はインターネットシステムがサービスを提供する適切なネットワークエンティティに連絡することを可能にするのURI、サービスURIの組に変換されるマッピングの問題[RFC5012]です。
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].
呼び出し側は、サービスが提供されている場所から知っている必要はありません。また、サービスプロバイダの場所は、システムの一時的な過負荷、主要サービスプロバイダーの場所の障害、または長期的な変化に対応するために、例えば、時間の経過とともに変化することがあり建築。緊急サービスでは、この問題は、[ECRIT-FRAME]に詳細に記載されています。
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.
全体的な緊急呼び出しアーキテクチャ[ECRIT-FRAME]は電話をかけるか、そうでなければサービスを呼び出すからマッピングを分離するため、同じメカニズムがマッピングは（「アドレス検証」）が存在することを確認するために、または試験サービスのURIを取得するために使用することができます。
Mapping locations to URIs that describe 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.
サービスを記述するURIへのマッピングの場所が分散し、スケーラブルで、高弾性のインフラストラクチャが必要です。このようなマッピングについての権威知識が互いのは直接の知識を持っていないかもしれ自律多数のエンティティ間に分散されます。この文書では、我々は、このようなグローバルサービスのためのアーキテクチャについて説明します。それは重要な自由は、実際のサーバー間での機能を組み合わせて分割することを可能にすると、特定のサービスを操作する必要があります誰にといくつかの要件を課します。
Besides determining the service URI, end systems also need to determine the local service numbers. As discussed in Section 9, the architecture described here can also address that problem.
サービスURIを決定するだけでなく、エンドシステムは、ローカルサービス番号を決定する必要があります。第9章で説明したように、ここで説明するアーキテクチャは、その問題に対処することができます。
The architecture described here uses the Location-to-Service Translation (LoST) [RFC5222] protocol, although much of the discussion would also apply for other mapping protocols satisfying the mapping requirements [RFC5012].
議論の多くはまた、マッピング要件[RFC5012]を満たす他のマッピングプロトコルに適用されるが、ここで説明したアーキテクチャは、ロケーション・ツー・サービス翻訳（LOST）[RFC5222]プロトコルを使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載され、対応する実装の要求レベルを示すものと解釈されます。
In addition to the terms defined in [RFC5012], this document uses the following terms to describe LoST clients and servers:
[RFC5012]で定義された用語に加えて、この文書が失われ、クライアントとサーバーを記述するために、次の用語を使用します。
authoritative mapping server (AMS): An 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 Presence Information Data Information Location Object (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 another AMS within the tree.
権威マッピングサーバ（AMS）：権威マッピングサーバ（AMS）は、プレゼンス情報データの情報の場所オブジェクト（PIDF-LO）のセット市民のラベルをカバーし、例えば、クエリの特定のセットに正式な答えを提供することができます失われたサーバーでありますまたは幾何学的形状によって記載された特定の領域。領土紛争のいくつかの（まれな）ケースでは、二つのレゾルバは、同じ領域の権威であってもよいです。 AMSは、リダイレクトまたはツリー内の別のAMSにクエリを転送することができます。
child: A child is an AMS that is authoritative for a subregion of another AMS. A child can in turn be parent for another AMS.
子供：子供が別のAMSの部分領域に対して権限のあるAMSです。子供は今度は別のAMSのための親になることができます。
(tree node) cluster: A node cluster is a group of 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.
（ツリーノード）クラスタ：ノードクラスタすべて同じマッピング情報を共有し、クエリのために同じ結果を返す失われたサーバーのグループです。クラスタは、冗長性と共有クエリ負荷を提供しています。クラスタは、互いに即ち、それらはすべて交換更新を完全に噛合されています。
coverage region: The coverage region of an AMS is the geographic region within which the AMS is able to authoritatively answer mapping queries. Coverage regions are generally, but not necessarily, contiguous and may be represented as either a subset of a civic address or a geometric object.
カバーエリア：AMSのカバレッジ領域は、AMSが正式マッピングの問い合わせに答えることができるしている範囲内の地理的な領域です。カバレッジ領域は一般に、必ずしもそうではないが、連続及び市民アドレスのサブセットまたは幾何学的オブジェクトのいずれかとして表すことができます。
forest guide (FG): A forest guide (FG) has knowledge of the coverage region of trees for a particular top-level service.
森林ガイド（FG）：森林ガイド（FG）は、特定のトップレベルのサービスのための木のカバレッジ領域の知識を有しています。
mapping: A mapping is a short-hand for 'mapping from a location object to either another mapping server or the desired service URLs'.
マッピング：マッピングは「別のマッピングサーバ又は所望のサービスのURLのいずれかに位置オブジェクトからマッピング」の短手です。
parent: A mapping server that covers the region of all of its children. A mapping server without a parent is a root AMS.
親：子の全ての領域を覆うマッピングサーバ。親なしのマッピングサーバはルートAMSです。
resolver: A resolver is contacted by a seeker, consults a forest mapping server, and then resolves the query using an appropriate tree. Resolvers may cache query results.
リゾルバ：リゾルバがシーカーによって接触されるが、森林のマッピングサーバを参照し、適切なツリーを使用してクエリを解決します。リゾルバは、クエリの結果をキャッシュすることがあります。
seeker: A 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.
シーカー：シーカーは、マッピングを要求して失われたクライアントです。求職者は、他人へのマッピングサービスを提供していませんが、自身の使用のために結果をキャッシュすることができます。
tree: A tree consists of a self-contained hierarchy of authoritative mapping servers for a particular service. Each tree exports its coverage region to the forest mapping servers.
ツリー：ツリーは、特定のサービスのための権威マッピングサーバの自己完結型の階層で構成されています。それぞれの木は森のマッピングサーバにそのカバー範囲をエクスポートします。
The mapping architecture distinguishes four logical roles: seekers, resolvers, authoritative mapping servers (AMS), and forest guides (FGs). End users of the LoST-based [RFC5222] mapping mechanism, called seekers, contact resolvers that cache query results and know one or more forest guides. Forest guides form the top level of a conceptual hierarchy, with one or more trees providing a hierarchical resolution service for different geographic regions. Forest guides know the geographic coverage region of all or almost all 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.
求職者、リゾルバ、権威マッピングサーバ（AMS）、および森林ガイドFGS（）：マッピングアーキテクチャは、4つの論理の役割を区別します。エンド失わベース[RFC5222]マッピングメカニズムの利用者、と呼ばれる求職者、キャッシュクエリの結果とは、1つまたは複数の森林ガイドを知って接触リゾルバ。森林ガイドは、一つ以上のツリーが異なる地理的領域のための階層的な解決サービスを提供して、概念階層の最上位レベルを形成します。森のガイドは、適切なツリーの最上位ノードにすべて、またはほとんどすべての木との直接クエリの地理的カバレッジ領域とを知っています。木は権威マッピングサーバで構成され、正式なマッピング情報を維持します。
Seekers, resolvers, authoritative mapping servers, and forest guides all communicate using LoST; indeed, it is likely that, in many cases, the same software can operate as a resolver, authoritative mapping server, and forest guide. In addition to the basic LoST query protocol [RFC5222], a synchronization protocol [LOST-SYNC] may be used to exchange information between forest guides or to push coverage information from a tree node to its parent.
すべての失われたを使用して通信求職者、リゾルバ、権威マッピングサーバ、および森林ガイド。確かに、多くの場合、同じソフトウェアはリゾルバ、権威マッピングサーバ、および森林ガイドとして動作することができ、可能性が高いです。基本的な失われたクエリプロトコル[RFC5222]に加えて、同期プロトコル[LOST-SYNC]は森林ガイドとの間で情報を交換するために、またはその親にツリーノードからカバレッジ情報をプッシュするために使用することができます。
Seekers may be part of Voice over IP (VoIP) or other end systems, or of SIP proxies or similar call routing functions.
求職者は、IP（VOIP）または他のエンド・システム上、またはSIPプロキシまたは類似のコールルーティング機能の声の一部であってもよいです。
Figure 1 shows the interaction of the components. The lines indicating the connection between the forest guides are logical connections, indicating that they are synchronizing their information via the synchronization protocol [LOST-SYNC].
図1は、コンポーネントの相互作用を示します。森林ガイドとの間の接続を示す線は、それらが同期プロトコル[LOST-SYNC]を介して、それらの情報を同期していることを示し、論理接続です。
/-\ /-\ +-----+ +-----+
| 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, while the lines indicate synchronization relationships.
シーカー（S）、レゾルバ（R）、森林ガイド（FG）、及び木を示すアーキテクチャ図。行が同期関係を示しながら、スター（*）の行は、再帰モードでのクエリと応答の流れを示しています。
Figure 1
図1
The mapping function for the world is divided among trees. The collection of trees may not cover the whole world, and trees are added and removed as the organization of mapping data changes. We call the collection of trees a forest. There is no limit on the number of trees within the forest, but the author guesses that the number of trees will likely be somewhere between a few hundred and a few thousand. The lower estimate would apply if each country operates one tree, the higher if different governmental or private organizations within a country operate independent trees. We assume that tree coverage information changes relatively slowly, on the order of less than one change per year per tree, although the system imposes no specific threshold. Tree coverage would change, for example, if a country is split or merged or if two trees for different regions become part of a larger tree. (On the other hand, information within a tree is likely to change much more frequently.)
世界のためのマッピング機能は、木々の間で分割されます。木々のコレクションは、全世界をカバーしていないこと、そして木が追加され、マッピングデータの変更の組織として削除されます。私たちは、木のコレクション森を呼び出します。そこ森の中の木の数に制限はありませんが、著者は木の数はおそらく数百と数千人の間のどこかになると推測します。それぞれの国には一本の木、国内の異なる政府や民間団体が作動した場合に高い独立したツリーを操作すると下の推定値が適用されます。我々は、システムが何も特定のしきい値を課していないが、木のカバレッジ情報は、木あたり年間未満の変化のために、比較的ゆっくりと変化していることを前提としています。さまざまな地域のための2本の木が大きく、ツリーの一部になる場合は、ツリーカバレッジは国が分割またはマージされた場合、例えば、変更したりします。 （一方で、ツリー内の情報は、はるかに頻繁に変更する可能性があります。）
It is possible to build a functioning system consisting only of seekers and resolvers if these resolvers have other means of obtaining mapping data. For example, a company acting as a mapping service provider could collect mapping records manually and make them available to their customers 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 would somehow make themselves known to these providers. Such a mechanism would be similar to the old "hosts.txt" mechanism for distributing host information in the early Internet before DNS was developed.
これらのレゾルバは、マッピングデータを得るための他の手段を持っている場合のみ、求職者とリゾルバのからなる機能システムを構築することが可能です。たとえば、マッピングサービスプロバイダとして機能する同社は、手動でマッピングレコードを収集でき、リゾルバを通じて顧客が使用できるようにします。出発点として実現可能な一方で、このようなアーキテクチャは、グローバルに拡大することはほとんどありません。他の問題の中でも、そのようなすべてのプロバイダが最新の情報を持っていることを確実にするために正式なデータの提供のために非常に困難になります。新しい木が設定されている場合、彼らは何とかこれらのプロバイダに自身が既知になるだろう。このようなメカニズムは、DNSが開発された前の早いインターネットにホスト情報を配信するための古い「HOSTS.TXT」メカニズムと同様です。
Below, we describe the operation of each component in more detail.
以下に、我々はより詳細に各構成要素の動作を説明します。
Clients desiring location-to-service mappings are known as seekers. Seekers are consumers of mapping data and originate LoST queries as LoST protocol clients. Seekers do not answer LoST queries. They contact either forest guides or resolvers to find the appropriate tree that can authoritatively answer their questions. Seekers can be end systems such as SIP user agents, or call routing entities such as SIP proxy servers.
場所・ツー・サービスのマッピングを希望するクライアントは、求職者として知られています。求職者は、マッピングデータの消費者であり、失われたプロトコルのクライアントとして失われたクエリを発信します。求職者は、失われたクエリに応答しません。彼らは正式に彼らの質問に答えることができ、適切な木を見つけるために、森林ガイドやリゾルバのいずれかにご連絡ください。求職者は、SIPユーザエージェントとしてエンドシステム、またはそのようなSIPプロキシサーバなどのルーティング・エンティティを呼び出すことができます。
Seekers may need to obtain mapping information in several steps, i.e., they may obtain pointers to intermediate servers that lead them closer to the final mapping. Seekers MAY cache query results for later use but otherwise have no obligations to other entities in the system.
求職者は、すなわち、彼らは近い最終マッピングにそれらを導く中間サーバへのポインタを得ることができる、いくつかのステップにマッピング情報を取得する必要があるかもしれません。求職者は、後で使用するためにクエリ結果をキャッシュするが、そうでない場合は、システム内の他のエンティティへの義務を有していなくてもよいです。
Seekers need to be able to identify appropriate resolvers. The mechanism for providing seekers with that information is 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 or enterprise can provide a pointer to a resolver via DHCP [RFC5223]. In an ad hoc or zero-configuration environment, appropriate service directories may advertise resolvers.
求職者は、適切なリゾルバを識別できるようにする必要があります。その情報と求職者を提供するためのメカニズムは、リゾルバを運営者によって異なりする可能性があります。音声サービスプロバイダはレゾルバを操作した場合、例えば、それは、そのユーザエージェントに配信するSIP構成情報にレゾルバの位置を含み得ます。インターネットアクセスプロバイダまたは企業は、DHCP [RFC5223]を介して、リゾルバへのポインタを提供することができます。アドホックまたはゼロコンフィギュレーション環境では、適切なサービスのディレクトリは、リゾルバを宣伝します。
Like other entities in the system, seekers can cache 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 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 service provider.
システム内の他のエンティティと同様に、求職者は応答をキャッシュすることができます。応答ではなく単に点より、市民または地理空間領域のために結果を記載する場合、これは特に有用です。例えば、モバイルノードのために、求職者は、彼らがサービスプロバイダーのカバレッジエリアを離れる場合にのみ、このような緊急サービスのためのPSAPとして、その解決の結果を更新しなければならない、と位置情報がわずかに変化するたびに繰り返し、この情報のポーリングを回避することができます。 （モバイルノードは、ローカルまたはそれらが現在のサービスエリアを去るときにトリガーのいずれかである位置更新メカニズムを必要とする。）これは、おそらく、そのような企業ネットワークにおけるアウトバウンドプロキシとして大きなユーザ人口を表す求職者のための特に有益であろう。たとえば、むしろ各小部屋のために別々に照会することよりも、権威ノードによって提供される情報は、全キャンパスは同じサービスプロバイダによって覆われていることを示すことができます。
Given this caching mechanism and cache lifetimes of several days, most mobile users traveling to and from work would only need to obtain service area information along their commute route once during each cache lifetime.
このキャッシュ機構と数日間のキャッシュ寿命を考えると、仕事にしてから旅行するほとんどのモバイルユーザーは、各キャッシュの有効期間中に一度自分の通勤経路に沿っサービスエリア情報を取得する必要があります。
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 in the architecture, that knows how to contact one or more forest guides and that caches earlier queries to accelerate the response to mapping queries and to improve the resiliency of the system. Each resolver can decide autonomously which FGs to use, with possibly different choices for each top-level service.
シーカー（下記参照）を直接森林ガイドに接触することができるが、容易にそのようなガイドを見つけることができないかもしれません。また、同じ地理的エリア内の求職者は、すでに同じ質問をしている可能性があります。したがって、それは、一つ以上の森林ガイドを連絡する方法を知っている、それがマッピングのクエリに対する応答を加速するために、システムの回復力を向上させるために、以前のクエリをキャッシュアーキテクチャのリゾルバとして知られている別のエンティティを、導入する意味があります。各リゾルバは各トップレベルのサービスのために、おそらく異なる選択肢が、使用するFGSどの自律的に決定することができます。
ISPs or Voice Service Providers (VSPs) may include the address of a suitable resolver in their configuration information, e.g., in SIP configuration for a VSP or DHCP [RFC5223] for an ISP. Resolvers are manually configured with the name of one or more forest guides.
ISPや音声サービスプロバイダ（のVSP）はISPのためにVSPまたはDHCP [RFC5223]のためのSIPの構成において、例えば、その設定情報に適したレゾルバのアドレスを含んでいてもよいです。リゾルバは、手動で一つ以上の森林ガイドの名で構成されています。
The architecture assumes that authoritative knowledge about the mapping data is distributed among many independent administrative entities, but clients (seekers) may potentially need to find out mapping information for any spot on earth. (Extensions to extra-terrestrial applications are left for future exploration.) Information is organized hierarchically, in a tree, with tree nodes representing larger geographic areas pointing to several child nodes, each representing a smaller area. Each tree node can be a cluster of LoST servers that all contain the same information and back up each other.
アーキテクチャは、マッピングデータに関する信頼できる知識が多くの独立行政エンティティ間で分散されていることを前提としていますが、クライアント（求職者）は、潜在的に、地球上の任意の地点のマッピング情報を見つけるために必要があるかもしれません。 （地球外のアプリケーションへの拡張は、将来の探査のために残されている。）の情報は、階層的に編成され、ツリーに、いくつかの子ノードを指す大きな地理的エリアを表すツリーノードと、それぞれがより小さな領域を表します。各ツリーノードはすべて同じ情報が含まれて失われたサーバのクラスタも、お互いをバックアップすることができます。
Each tree can map a location described by either civic or geographic coordinates, but not both, for one type of service (such as 'sos.police', 'sos.fire' or 'counseling') and one location profile, although nothing prevents re-using the same servers for multiple, different services or both types of coordinates. The collection of all trees for one service and location profile is known as a forest.
各ツリーは、1つのロケーション・プロファイル（例えば「sos.police」、「sos.fire」または「カウンセリング」のような）サービスのいずれかのタイプのために、いずれかの市民または地理座標によって記述される場所をマップではなく、両方でき何も防止ものの再使用して、複数の、異なるサービスのために同じサーバーまたは座標の両方のタイプを。 1つのサービスと場所のプロファイルのすべての木のコレクションは森として知られています。
Each tree root announces its coverage region to one or more forest guides.
各ツリーのルートは、一つ以上の森林ガイドにそのカバー範囲を発表しました。
Each tree node cluster knows the coverage region of its children and sends queries to the appropriate server "down" the tree. Each such tree node knows authoritatively about the service mappings for a particular region, typically, but not necessarily, contiguous. The region can be described by any of the shapes in the LoST specification expressed in geospatial coordinates, such as circles or polygons, or a set of civic address descriptors (e.g., "country = DE, A1 = Bavaria"). These coverage regions may be aligned with political boundaries, but that is not required. In most cases, to avoid confusion, only one cluster is responsible for a particular geographic or civic location, but the system can also deal with cases where coverage regions overlap.
各ツリーノードのクラスタは、その子のカバレッジ地域を知っているし、適切なサーバー「ダウン」ツリーにクエリを送信します。そのようなそれぞれのツリーノードは、一般的に、必ずしも必要ではないが、連続した、特定の地域のためのサービスのマッピングについて正式に知っています。領域は、円や多角形などの地理空間座標で表現さ失われた仕様、または市民アドレス記述子（例えば、「国= DE、A1 =バイエルン」）のセット内の図形のいずれかによって記述することができます。これらのカバレッジ領域は、政治的な境界で整列させることができるが、それは必要とされていません。ほとんどの場合、混乱を避けるために、唯一つのクラスタは、特定の地理的または市民の位置を担っているが、システムはまた、カバレッジ領域が重複する場合に対処することができます。
There are no assumptions about the coverage region of a tree as a whole. For example, a tree could cover a single city, a state/ province, or a whole country. Nodes within a tree need to loosely coordinate their operation, but they do not need to be operated by the same 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 the Lightweight Directory Access Protocol (LDAP) when deployed in a distributed fashion.
その代表団は、ラベルではなく、地域によるものです除きツリーアーキテクチャは、ドメインネームシステム（DNS）とほぼ同じです。 （当然のことながら、DNSは、森林ガイドの概念を持っていません。）1つはまた、分散方式で展開のLDAP（Lightweight Directory Access Protocol）にアナロジーを描くことができます。
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 service provider or another signaling server representing a group of service providers, which in turn might further route signaling requests to more servers covering smaller regions.
すなわち、カバレッジ領域とマッピング - ツリーノードは、2つのタイプの情報を維持します。カバレッジ領域は、さらに解像度の子ノードにツリー点における子ノードによってサービスされる領域を記述する。マッピングは、順番に小さい領域をカバーする複数のサーバに要求をシグナリング経路をさらに可能性があるサービスプロバイダまたはサービスプロバイダのグループを表す別のシグナリング・サーバに至る実際のサービスURIを含みます。
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.
リーフノード上記ツリーノードのみのカバレッジ領域を維持しながら、リーフノード、すなわち、ノードは、子供のいない、のみ、マッピングを維持します。リーフ・ノード・エントリの緊急サービスのための例では、3つの町のためのクエリが異なるのPSAPに向けられているかを示す、以下に示されています。イングルウッドのためのクエリは、代わりに別の失われたサーバーに送られます。
country A1 A2 A3 resource or LoST server US NJ Bergen Leonia sip:psap@leonianj.gov US NJ Bergen Fort Lee sip:emergency@fortleenj.org US NJ Bergen Teaneck sip:police@teanecknjgov.org US NJ Bergen Englewood englewoodnj.gov ....
国A1 A2 A3リソースまたは失われたサーバー米国ニュージャージー州ベルゲンレオニアのSIP：psap@leonianj.gov米国ニュージャージー州フォートリーベルゲンのSIP：US NJベルゲンティーネックの一口をemergency@fortleenj.org：police@teanecknjgov.org米国ニュージャージー州イングルウッドベルゲンenglewoodnj.gov。 ...
Coverage regions are described by sets of LoST-compatible shapes enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs the same matching operation as described in Section 12.2 of the LoST specification [RFC5222] to find the tree or AMS.
カバレッジ領域は、隣接地域を囲む失わ互換形状のセットによってまたは市民位置のグループを列挙記述子によって記述されています。ツリーまたはAMSを見つけるために、失われた仕様[RFC5222]のセクション12.2で説明したように、前者の場合は、失われたサーバは、同一の整合動作を行います。
As a civic location example, a state-level tree node for New Jersey in the United States may contain the coverage region entries shown below, 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.
都市ロケーション例として、米国ニュージャージーための状態レベルツリーノードはベルゲン郡の位置に一致する任意のクエリは、例えば、ノードにリダイレクトまたは転送されることを示す、以下に示すカバレッジ領域のエントリを含んでいてもよいです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 queries for all other towns within Essex county would be directed to the county node for further resolution.
すべての子ノードは、市民の階層内の同じレベルをカバーする必要はありません。一例として、以下の表に、ニューアーク市はなく郡を通るよりも、状態ノード内で直接記載されていることを決定しました。エセックス郡内のすべての他の町のためのクエリがさらに解決郡ノードに向けられるように最長一致ルールは、部分的な被覆を可能にします。
C A1 A2 A3 LoST server name US NJ Atlantic * atlantic.nj.example.org/sos US NJ Bergen * bergen.nj.example.org/sos US NJ Monmouth * monmouth.nj.example.org/sos US NJ Essex * essex.nj.example.org/sos US NJ Essex Newark newark.example.com/sos ....
C A1 A2 A3は、*米国ニュージャージー州モンマス* monmouth.nj.example.org/sos米国ニュージャージー州エセックスbergen.nj.example.org/sos米国ニュージャージー州ベルゲン* atlantic.nj.example.org/sosサーバー名、米国ニュージャージー州の大西洋*を失いましたessex.nj.example.org/sos米国ニュージャージー州エセックス州ニューアークのnewark.example.com/sos ....
Thus, there is no substantial difference between coverage region and mapping data. The only difference is that coverage regions return names of LoST servers, while mapping entries contain service 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.
したがって、カバレッジ領域とマッピングデータとの間に実質的な差はありません。唯一の違いは、マッピングエントリは、サービスのURLが含まれていながら、カバレッジ領域は、失われたサーバーの名前を返すということです。マッピングエントリはHOUSE-または床レベルまで特定することができるのみストリートレベルの情報を含んでいてもよいです。例えば、緊急サービスのための米国、市民のマッピングデータで、一般的にアドレス範囲（「MSAGデータ」）に限定されるので、初期マッピングデータベースは、ストリートレベルの情報のみを含んでいてもよいです。
To automate the maintenance of trees, the LoST synchronization mechanism [LOST-SYNC] allows nodes to query other nodes for mapping data and coverage regions, both within a cluster and across different hierarchy levels in a tree. In the example above, the state-run node would query the county nodes and use the records returned to distribute incoming LoST queries to the county nodes. Conversely, nodes could also contact their parent nodes to tell them about their coverage region. There is some benefit of child nodes contacting their parents, as this allows changes in coverage regions to propagate quickly up the tree.
木の維持、失われた同期化機構[LOST-SYNC]を自動化することは、ノードがクラスタ内およびツリー内の異なる階層レベル間の両方、マッピングデータとカバレッジ領域について、他のノードを照会することを可能にします。上記の例では、国営ノードは郡ノードを照会し、レコードを使用する郡のノードに入ってくる失われたクエリを配布するために戻りました。逆に、ノードはまた、そのカバー範囲について、それらを伝えるために彼らの親ノードに連絡ができます。これは、カバレッジ領域の変化ツリーまで急速に伝播することを可能にするよう両親に連絡子ノードのいくつかの利点があります。
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 server indicated in the coverage region record, returning a response to the querier when it in turn receives an answer (recursion). Alternatively, the node returns the application unique string (server name) of that child node to the 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 URL or server name, 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.
効率化のために、ノードは、地域情報の代わりに、ポイントの答えを返してもよいです。したがって、代わりに特定の地理空間は、サービスのURLまたはサーバー名にマップを調整することを返すのは、有効期限（生存時間）の情報と共に、この答えが返されることになるための領域を示すポリゴンを返す場合があります。クエリノードは、将来の使用のために、この情報をキャッシュすることができます。
For civic coordinates, trees may not include individual mapping records for each floor, house number, or street. To avoid giving the wrong indication that a particular location has been found valid, LoST can indicate which parts of the location information have actually been used to look up a mapping.
市民の座標について、木々は、個々の各フロアのマッピングレコード、家屋番号、または通りを含まなくてもよいです。特定の場所が有効で発見されたという間違った表示を与えないようにするには、失われたが、位置情報の一部は、実際のマッピングをルックアップするために使用されているかを示すことができます。
In some cases, coverage regions may overlap, either because there is a dispute as to who handles a particular geographic region or, more likely, because 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.
いくつかのケースでは、カバレッジ領域が重複していてもよい、いずれかのカバレッジマップの分解能が十分に高くないかもしれないので、特定の地理的領域、またはより可能性を取り扱う者へのような論争があるからです。そのカバレージ領域は、その地理的隣接して重なるように表示されるように、例えば、ノードは、そのポリゴンオフ「いくつかのコーナーを削る」ことができます。市民の座標については、同じ通りの家屋が異なるのPSAPによって提供することができます。マッピングメカニズムは、カバレッジマップが不正確またはカバレッジに関する紛争が存在する場合であっても動作する必要があります。
The solution for overlapping coverage regions is relatively simple. If a query matches multiple coverage regions, the node returns all URLs or server names, 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 try to contact all services in turn.
カバレッジ領域が重複するためのソリューションは比較的簡単です。クエリが複数のカバレッジ領域と一致する場合、ノードは、リダイレクトモードでは、すべてのURLまたはサーバー名を返す、または再帰モードであれば、両方の子供を照会します。重複カバレッジが不正確なカバレッジマップによって引き起こされている場合、一方だけが結果を返しますし、他の人はエラー表示を返します。特定の場所を領土に異議を唱えている場合は、応答が推奨されるソリューションを選択するか、順番にすべてのサービスを連絡しようとするクエリアにそれを残して、すべての答えが含まれています。
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 the meshed Service Location Protocol (SLP) [RFC3528] are applicable here.
彼らは信頼できる情報を提供しているので、ツリーノードは、高い信頼性が必要です。この文書は、ツリー内の論理エンティティとしてツリーノードを指しつつ、実際の実装は、おそらくクラスタを形成し、いくつかのサーバー間でノード情報を複製することになります。ような各ノードは、同じ情報を持っているでしょう。そのようなDNS SRVレコードなどの標準的な技術は、サーバのいずれかを選択するために使用することができます。クラスタ内のレプリケーションは、任意の適切なプロトコル機構を使用することができるが、標準化され、増分更新機構は、簡単に複数の独立投与ロケーションにわたってそれらのノードを分散させることができます。噛合サービスロケーションプロトコル（SLP）[RFC3528]のために開発された技術は、ここで適用可能です。
Unfortunately, just having trees covering various regions of the world is not sufficient, as a client of the mapping protocol would not generally be able to keep track of all the trees in the forest. To facilitate orientation among the trees, we introduce a forest guide (FG), which keeps track of the coverage regions of all the trees for one service and location profile. For scalability and reliability, there will need to be a large number of forest guides, all providing the same information. A seeker can contact a suitable forest guide and will then be directed to the right tree or, rarely, set of trees. Forest guides do not provide mapping information themselves, but rather redirect to mapping servers. In some configurations, not all forest guides may provide the same information, due to policy reasons.
マッピングプロトコルのクライアントは、一般的に、フォレスト内のすべての木を追跡することはできません残念ながら、世界の様々な地域をカバーするだけの持つ木は、十分ではありません。木々の間の向きを容易にするために、我々は一つのサービスと場所のプロファイルのすべての木のカバレッジ領域を追跡し、森林ガイド（FG）を、ご紹介します。拡張性と信頼性のために、すべて同じ情報を提供し、森林ガイドの多数があることが必要になります。求職者は、適切な森林ガイドに連絡することができますし、右側の木に向けていないか、めったに、木々の設定されます。森のガイドは、マッピング情報そのものを提供ではなく、マッピングサーバにリダイレクトされません。いくつかの構成ではなく、すべての森林ガイドが原因政策上の理由に、同じ情報を提供することができます。
Forest guides fulfill a similar role to root servers in DNS. They distribute information, signed for authenticity, offered by trees. However, introducing forest guides avoids creating a global root, with the attendant management and control issues.
森のガイドは、DNSのルートサーバへの同様の役割を果たしています。彼らは木々が提供する信頼性のために署名情報を、配布します。しかし、森のガイドを導入することは係員管理と制御の問題で、世界的なルートを作成避けることができます。
However, unlike DNS root servers, forest guides may offer different information based on local policy. Forest guides can also restrict their data synchronization to parts of the information. For example, if country C does not recognize country T, C can propagate tree regions for all but T.
しかし、DNSルートサーバーとは異なり、森林ガイドは、ローカルポリシーに基づいて、異なる情報を提供することがあります。森のガイドは、情報の部分に自分のデータ同期を制限することができます。国C国Tを認識しない場合たとえば、Cはすべてのために木の領域を伝播するが、T.できます
For authenticity, the coverage regions SHOULD be digitally signed by the authorities responsible for the region, as discussed in more detail in Section 10. 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 other guides. Due to policy and maybe political reasons, not all forest guides may share the same coverage region data.
彼らは、特定の領域のために適切な木を見つけるためにリゾルバおよびおそらくシーカーにより使用されている第10章でより詳細に説明するように真偽については、カバレッジ領域をデジタル領域に責任当局によって署名されるべきです。すべての森林ガイドは、すなわち、すべての木のすべてのカバレッジ領域のコレクションを一貫性のある情報を持っている必要があります。ツリーの最上部にあるツリーノードは、任意の森林ガイドに接触し、システムに新しいカバレッジ領域情報を注入することができます。一つは、各ツリーが複数の森林ガイドにその適用範囲を発表することを期待します。各森林ガイドは、一つ以上の他のガイドで同僚や他のガイドへの新規カバレッジ領域のアナウンスを配布しています。政策と多分政治的な理由には、すべてではない森のガイドは、同じカバレッジ領域のデータを共有する場合があります。
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.
ルーティングのように、他の森林ガイドとのピアリングは、ピアの信頼のある量を意味しています。このように、ピアリングではなく、自動設定よりも、関係当事者間の投与いくつかの交渉を必要とする可能性が高いです。メカニズム自体は、特定のカバレッジ地域を宣伝するために誰のように、特定のポリシーを意味するものではありません。
The section below is not directly related to the problem of determining service location but is an instance of the more generic problem solved by this architecture -- namely, mapping location information to service-related parameters, such as service numbers.
そのようなサービスの数などのサービス関連パラメータに、すなわち、マッピング位置情報 - 以下のセクションでは、直接サービスの場所を決定する問題に関係なく、このアーキテクチャによって解決より一般的な問題のインスタンスではありません。
For the foreseeable future, some user devices and software will emulate the user interface of a telephone, i.e., the only way to enter call address information is via a 12-button keypad with digits and the asterisk and hash symbols. These devices use service numbers to identify services. The best-known examples of service numbers are emergency numbers, such as 9-1-1 in North America and 1-1-2 in Europe. However, many other public and private service numbers have been defined, ranging in the United States from 3-1-1 for non-emergency local government services to 4-1-1 for directory assistance, to various "800" numbers for anything from roadside assistance to legal services to home-delivery food.
近い将来のために、いくつかのユーザデバイスとソフトウェアが、電話のユーザーインターフェイスをエミュレートします、すなわち、コールアドレス情報を入力する唯一の方法は、数字とアスタリスクとハッシュ記号付き12ボタンのキーパッドを介しています。これらのデバイスは、サービスを識別するためのサービス番号を使用します。サービス番号の最もよく知られた例としては、北米や欧州では1-1-2で9-1-1のように緊急電話番号、です。しかし、他の多くの公共および民間のサービス番号はから何のために様々な「800」の数字に、ディレクトリアシスタントのために4-1-1に非緊急地方自治体サービスのための3-1-1から米国に至るまで、定義されています宅配食品への法的サービスへの道端での援助。
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 use throughout the world, 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 conform to regional agreements. An example is the introduction of "1-1-2" for countries in Europe.
基本的にすべての通信機器がIP接続と英数字キーボードを備えていますまで、このようなサービスの番号が使用される可能性があります。残念ながら、緊急サービスのために、60の以上の緊急番号は、例えば、修理またはディレクトリサービスを識別し、他の場所で非緊急目的にサービスを提供するこれらの数字の多くは、世界中で使用されています。国はまた、時折地域協定に準拠するように彼らの緊急電話番号を変更します。例では、ヨーロッパでは国のために、「1-1-2」の紹介です。
Thus, a system that allows devices to be used internationally to place calls needs to allow devices to discover service numbers automatically. In the Internet-based system proposed in [ECRIT-FRAME], these numbers are strictly used as a human-user interface mechanism and are generally not visible in call signaling messages, which carry the service URN [RFC5031] instead.
このように、デバイスが電話をかけるために、国際的に使用することができるシステムは、デバイスが自動的にサービス番号を発見できるようにする必要があります。 [ECRIT-FRAME]で提案されているインターネットベースのシステムでは、これらの数値は、厳密に人間のユーザインターフェース機構として使用され、代わりにサービスURN [RFC5031]を運ぶ呼シグナリングメッセージに一般見えません。
For the best user experience, systems should be able to discover two sets of service numbers -- namely, those used in the user's home country and those used in the country the user is currently visiting. The user is most likely to remember the former, but a companion borrowing a device in an emergency, say, may only know the local emergency numbers.
つまり、ユーザのホーム国で使用されているものと、ユーザーが現在訪問している国で使用されているもの - 最高のユーザーエクスペリエンスのために、システムは、サービス番号の二組を発見することができるはずです。ユーザーは、かつてのを覚えている可能性が最も高いですが、緊急時にデバイスを借りコンパニオンは、たとえば、ローカルのみの緊急番号を知っているかもしれません。
Determining home and local service numbers is a configuration problem, but unfortunately, existing configuration mechanisms are ill-suited for this purpose. For example, a DHCP server might be able 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 user may contact the home network or some local branch office of the corporate network. Similarly, SIP configuration [CONFIG-FRAME] would be able to provide the numbers valid at the location of the SIP service provider, but even a SIP service provider with a national footprint may serve customers that are visiting any number of other countries.
家の決定およびローカルサービス番号は、構成の問題であるが、残念ながら、既存の設定の仕組みは、この目的のためには不向きです。たとえば、DHCPサーバは、ローカルサービス番号ではなく、自宅の番号を提供することができるかもしれません。仮想プライベートネットワーク（VPN）を使用する場合、ユーザは、ホームネットワークや企業ネットワークの一部の地域の支店に連絡し得るような、でもDHCPは、原因不明の番号を提供することができます。同様に、SIPの設定[CONFIG-FRAME]はSIPサービスプロバイダの場所で有効な数字を提供することができるだろうが、国民のフットプリントでも、SIPサービスプロバイダは、他の国の任意の数を訪問している顧客にサービスを提供します。
Also, while initially there are likely to be only a few service numbers, e.g., for emergency services, the LoST architecture can be used to support other services, as noted. Configuring every local DHCP or SIP configuration server with that information is likely to be error-prone and tedious.
最初はごく少数サービス番号がある可能性が高い一方で述べたようにまた、例えば、緊急サービスのために、失われたアーキテクチャは、他のサービスをサポートするために使用することができます。その情報に基づいて、すべてのローカルDHCPまたはSIPコンフィギュレーションサーバを設定すると、エラーが発生しやすいと面倒になりそうです。
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 determining the service URL. The mapping can be obtained along with the service URL. The major difference between the two requests is that service numbers often have much larger regions of validity 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 its current (visited) location.
これらの理由から、失われたベースのマッピングアーキテクチャは、発信者の位置に基づいてシステムを終了するサービス番号を提供しサポートしています。マッピング操作はほぼ正確にサービスのURLを決定するためのと同じです。マッピングは、サービスのURLと一緒に取得することができます。 2つの要求間の主な違いは、サービス番号は、多くの場合、サービスURL自体より妥当性の非常に大きな領域を持っているということです。また、サービスの数は、長いサービスURLより有効である可能性が高いです。最後に、エンドシステムは、そのホームの場所だけではなく、その（訪問）現在位置のためのサービス番号を検索することもできます。
Security considerations for emergency services mapping are discussed in [RFC5069], while [RFC5031] discusses issues related to the service URN, one of the inputs into the mapping protocol. LoST-related security considerations are naturally discussed in the LoST specification [RFC5222].
[RFC5031]は、サービスURN、マッピングプロトコルへの入力のいずれかに関連する問題を議論しながら、緊急サービスのマッピングのためのセキュリティの考慮事項は、[RFC5069]で議論されています。失われた関連のセキュリティ問題は、当然失わ仕様[RFC5222]に記載されています。
The architecture addresses the following security issues, usually through the underlying transport security associations:
アーキテクチャは、通常、基本的なトランスポート・セキュリティ協会を通じて、次のようなセキュリティ上の問題に対処します。
server impersonation: Seekers, resolvers, fellow tree guides, and cluster members can assure themselves of the identity of the remote party by using the facilities in the underlying channel security mechanism, such as Transport Layer Security (TLS) [RFC5246].
サーバーの偽装：求職者、リゾルバ、仲間の木ガイド、およびクラスタメンバーは、このようなトランスポート層セキュリティ（TLS）[RFC5246]として基本となるチャネルのセキュリティ・メカニズムの施設を利用して相手の身元の自分自身を確保することができます。
query or query result corruption: To avoid the possibility of an attacker modifying the query or its result, the architecture RECOMMENDS the use of channel security, such as TLS. Results SHOULD also be digitally signed, e.g., using XML digital signatures [W3C.REC-xmldsig-core-20020212]. Note, however, that simple origin assertion may not provide the end system with enough useful information as it has no good way of knowing that a particular signer is authorized to represent a particular geographic area. It might be necessary that certain well-known Certificate Authorities (CAs) vet sources of mapping information and provide special certificates for that purpose. In many cases, a seeker will have to trust its local resolver to vet information for trustworthiness; in turn, the resolver may rely on trusted forest guides to steer it to the correct information.
クエリまたはクエリ結果破損クエリまたはその結果を変更する攻撃者の可能性を回避するために、アーキテクチャは、TLSなどのチャネルセキュリティの使用を推奨しています。結果はまた、デジタル[W3C.REC-XMLDSIGコア-20020212] XMLデジタル署名を使用して、例えば、署名されるべきです。それは特定の署名者は、特定の地理的領域を表すために許可されていることを知る良い方法を持っていないような単純な原点アサーションが十分に有用な情報をエンドシステムを提供することができないこと、しかし、注意してください。マッピング情報の特定のよく知られた証明機関（CA）獣医源とは、その目的のために特別な証明書を提供することが必要かもしれません。多くの場合、求職者は、信頼性のための獣医情報へのローカルリゾルバを信頼する必要があります。今度は、リゾルバは正しい情報にそれを操縦するために、信頼できる森林ガイドに依拠することができます。
coverage region corruption: To avoid the possibility of a third party or an untrustworthy member of a server population claiming a coverage region that it is not authorized for, any node introducing a new service boundary MUST sign the object by protecting the data with an XML digital signature [W3C.REC-xmldsig-core-20020212]. A recipient MUST verify, through a local policy mechanism, that the signing entity is indeed authorized to speak for that region. Determining who can speak for a particular region is inherently difficult unless there is a small set of authorizing entities that participants in the mapping architecture can trust. Receiving systems should be particularly suspicious if an existing coverage region is replaced with a new one with a new mapping address. In many cases, trust will be mediated: a seeker will have a trust relationship with a resolver, and the resolver, in turn, will contact a trusted forest guide.
カバレッジ領域汚職：第三者またはそれがために許可されていないカバー範囲を主張するサーバー群の信頼できないメンバーの可能性を回避するためには、新しいサービスの境界を導入する任意のノードは、XMLデジタルでデータを保護することにより、オブジェクトに署名する必要があります署名[W3C.REC-XMLDSIGコア-20020212]。受信者は、署名エンティティが実際にその地域のために話すことを許可されていることを、ローカルポリシー機構を介して、確かめなければなりません。マッピングアーキテクチャの参加者が信頼できるエンティティを許可する小さなセットがない限り、特定の地域のために話すことができる人決定することは本質的に困難です。既存のカバレッジ領域は新しいマッピングアドレスを使用して新しいものに交換された場合の受信システムは、特に不審にする必要があります。多くの場合、信頼が媒介されます：シーカーはリゾルバとの信頼関係を持つことになり、レゾルバは、順番に、信頼されたフォレストガイドをご連絡いたします。
Additional threats that need to be addressed by operational measures include denial-of-service attacks [PHONE-BCP].
運用対策によって対処する必要がある追加の脅威は、サービス拒否攻撃[PHONE-BCP]を含んでいます。
Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson, Schida Schubert, Murugaraj Shanmugam, Richard Stastny, Hannes Tschofenig, and Karl Heinz Wolf provided helpful comments.
ヤリArkko、リチャード・バーンズ、カレン・ジェニングス、ジョンユル・キム、オトマールレンドル、マットLepinski、クリス・ニューマン、アンドリュー・ニュートン、ジョンピーターソン、Schidaシューベルト、Murugaraj Shanmugam、リチャードStastny、ハンネスTschofenig、そしてカール・ハインツ・ウルフは、役に立つコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031] Schulzrinneと、H.、 "ユニフォームリソース名救急およびその他のよく知られているサービスのための（URN）"、RFC 5031、2008年1月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]ハーディ、T.、ニュートン、A.、Schulzrinneと、H.、およびH. Tschofenig、 "失われた：場所・ツー・サービス翻訳・プロトコル"、RFC 5222、2008年8月。
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
[RFC5223] Schulzrinneと、H.、ポーク、J.、およびH. Tschofenig、RFC 5223、2008年8月 "動的ホスト構成プロトコルを（DHCP）を使用する場所・ツー・サービス翻訳（LOST）サーバーの検出"。
[CONFIG-FRAME] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, February 2008.
[CONFIG-FRAME] Channabasappa、S.、「セッション開始プロトコルユーザエージェントプロファイル配信のためのフレームワーク」、進歩、2008年2月に作業。
[ECRIT-FRAME] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", Work in Progress, March 2009.
[ECRIT-FRAME]ローゼン、B.、Schulzrinneと、H.、ポーク、J.、およびA.ニュートン、 "インターネットマルチメディアを使用して緊急コールのためのフレームワーク" が進歩、2009年3月での作業。
[LOST-SYNC] Schulzrinne, H. and H. Tschofenig, "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Work in Progress, March 2009.
[LOST-SYNC] Schulzrinneと、H.およびH. Tschofenig、 "同期の場所・ツー・サービス翻訳（LOST）プロトコルベースのサービスの境界とマッピング要素"、進歩、2009年3月での作業。
[PHONE-BCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, March 2009.
[PHONE-BCP]ローゼン、B.とJ.ポーク、「緊急コールのサポートにおける通信サービスのための最も良い現在の練習」、進歩、2009年3月での作業。
[RFC3528] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced Service Location Protocol (mSLP)", RFC 3528, April 2003.
[RFC3528]趙、W.、Schulzrinneと、H.、およびE.ガットマン、 "メッシュ強化サービスロケーションプロトコル（MSLP）"、RFC 3528、2003年4月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinneと、H.とR.マーシャル、 "インターネット技術との緊急コンテキスト解決のための要件"、RFC 5012、2008年1月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]テイラー、T.、Tschofenig、H.、Schulzrinneと、H.、およびM・シャンミューガム、 "セキュリティの脅威と緊急マーキングコールとマッピングのための要件"、RFC 5069、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[W3C.REC-xmldsig-core-20020212] Solo, D., Eastlake, D., and J. Reagle, "XML-Signature Syntax and Processing", World Wide Web Consortium FirstEdition REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[W3C.REC-XMLDSIG-コア-20020212]ソロ、D.、イーストレイク、D.、およびJ. Reagle、 "XML-署名構文と処理"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XMLDSIGコア-20020212、2002年2月、<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>。
Author's Address
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs+ecrit@cs.columbia.edu URI：http://www.cs.columbia.edu