Groupe de travail Réseau	H. Schulzrinne, Columbia U.	
Request for Comments : 5582	septembre 2009	
Catégorie : Information	Traduction Claude Brière de L'Isle	

Architecture et cadre de transposition de localisation en URL

Résumé
Le présent document décrit une architecture pour un système mondial, adaptable, résiliant, et réparti administrativement pour transposer les informations de localisation géographique en URL, en utilisant le protocole de traduction de localisation en service (LoST, Location-to-Service Translation). L'architecture généralise les approches bien connues des systèmes de recherches hiérarchiques comme le DNS.
(La présente traduction incorpore les errata 2041,2042 et 2043)

Statut du présent mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 
Table des matières
1. Introduction	1
2. Terminologie	2
3. Définitions	2
4. Vue d'ensemble de l'architecture	3
4.1 Principaux composants	3
4.2 Architecture de système minimal	4
5. Chercheur	4
6. Résolveur	5
7. Arborescences : maintien d'une connaissance d'autorité	5
7.1 Fonctionnement de base	5
7.2 Réponse aux interrogations	6
7.3 Chevauchement des régions de couverture	7
7.4 Échelle et fiabilité	7
8. Guides des arborescences	7
9. Configuration des numéros de service	8
10. Considérations sur la sécurité	9
11. Remerciements	9
12. Références	10
12.1 Références normatives	10
12.2 Références pour information	10
Adresse de l'auteur	11
 	1.	Introduction

Il est souvent souhaitable de permettre aux utilisateurs d'accéder à un service qui fournit une fonction commune mais qui est en fait offert par divers fournisseurs de service locaux. Dans de nombreux cas, le fournisseur de service choisi dépend de la localisation de la personne qui souhaite accéder à ce service. Parmi les services publics les plus connus de cette sorte est l'appel d'urgence, où les appels d'urgence sont acheminés au point de réponse de sécurité publique (PSAP, Public Safety Answering Point) le plus approprié sur la base de la localisation physique de l'appelant. D'autres services, de la livraison d'aliments aux services d'annuaire et à l'assistance routière, suivent aussi ce schéma général. C'est un problème de transposition [RFC5012], où une localisation géographique et un identifiant de service [RFC5031] sont traduits en un ensemble d'URI, les URI de service, qui permet au système Internet de contacter une entité réseau appropriée qui fournit le service.

L'appelant n'a pas besoin de savoir d'où le service est fourni, et la localisation du fournisseur de service peut changer au fil du temps, par exemple, pour faire face à des surcharges temporaires, des défaillances chez le principal fournisseur de localisation de service, ou des changements à long terme dans l'architecture du système. Pour les services d'urgence, ce problème est décrit plus en détails dans la [RFC6443].

L'architecture globale de l'appel d'urgence [RFC6443] sépare la transposition du placement des appels des autres invocations du service, de sorte que le même mécanisme peut être utilisé pour vérifier qu'une transposition existe ("validation d'adresse") ou pour obtenir des URI de service d'essai.

La transposition des localisations en URI qui décrivent les services exige une infrastructure répartie, adaptable, et très résiliente. La connaissance d'autorité sur de telles transpositions est distribuée entre un grand nombre d'entités autonomes qui peuvent n'avoir pas de connaissance directe de chacune des autres. Dans le présent document, on décrit une architecture pour un tel service global. Elle permet une liberté significative pour combiner et partager les fonctionnalités entre les serveurs réels et impose peu d'exigences sur qui devrait faire fonctionner les services particuliers.

À côté de déterminer l'URI de service, les systèmes d'extrémité ont aussi besoin de déterminer les numéros de service locaux. Comme discuté à la Section 9, l'architecture décrite ici peut aussi traiter ce problème.

L'architecture décrite ici utilise le protocole de traduction de localisation en service (LoST, Location-to-Service Translation) [RFC5222], bien que beaucoup de la discussion s'applique aussi à d'autres protocoles de transposition satisfaisant les exigences de transposition [RFC5012].

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119] et indiquent le niveau d'exigence pour les mises en œuvre conformes.

 	3.	Définitions

En plus des termes définis dans la [RFC5012], le présent document utilise les termes suivants pour décrire les clients et serveurs LoST :

Serveur de transposition d'autorité (AMS, Authoritative Mapping Server) est un serveur LoST qui peut fournir la réponse d'autorité à un ensemble particulier d'interrogations, par exemple, couvrant un ensemble d'étiquettes civiles d'objet de localisation d'informations de données d'informations de présence (PIDF-LO, Presence Information Data Information Location Object) ou une région particulière décrite par une forme géométrique. Dans certains cas (rares) de disputes territoriales, deux résolveurs peuvent être d'autorité pour la même region. Un AMS peut rediriger ou transmettre une interrogation à un autre AMS dans l'arborescence.

Fils : un fils est un AMS qui est d'autorité pour une sous région d'un autre AMS. Un fils peut à son tour être parent d'un autre AMS.

Grappe (de nœuds d'arborescence) : une grappe de nœuds est un groupe de serveurs LoST qui partagent tous les mêmes informations de transposition et retournent le même résultat aux interrogations. Les grappes fournissent une redondance et partagent la charge d'interrogations. Les grappes sont pleinement maillées, c'est-à-dire, elles échangent toutes les mises à jour les unes avec les autres.

Région de couverture : la région de couverture d'un AMS est la région géographique au sein de laquelle l'AMS est capable de réponse d'autorité aux interrogations de transposition. Les régions de couverture sont généralement, mais pas nécessairement, contiguës et peuvent être représentées comme un sous ensemble d'une adresse civile ou d'un objet géométrique.

Guide forestier (FG, forest guide) : il a connaissance de la région de couverture des arborescences pour un service de niveau supérieur particulier.

Transposition : c'est l'abrégé pour "transposition d'un objet de localisation en un autre serveur de transposition ou en l'URI de service désiré".

Parent : un serveur de transposition qui couvre la région de tous ses fils. Un serveur de transposition sans parent est un AMS racine.

Résolveur : un résolveur est contacté par un chercheur, consulte un guide forestier, et ensuite résout l'interrogation en utilisant une arborescence appropriée. Les résolveurs peuvent mettre en antémémoire les résultats des interrogations.

Chercheur : c'est un client LoST qui demande une transposition. Un chercheur ne fournit pas de services de transposition aux autres mais peut mettre en antémémoire les résultats pour son propre usage.

Arborescence : elle consiste en une hiérarchie interne de serveurs de transposition d'autorité pour un service particulier. Chaque arborescence exporte sa région de couverture au guide forestier.

 	4.	Vue d'ensemble de l'architecture
 	4.1	Principaux composants
L'architecture de transposition distingue quatre rôles logiques : les chercheurs, les résolveurs, les serveurs de transposition d'autorité (AMS), et les guides forestiers (FG). Les utilisateurs finaux du mécanisme de transposition fondé sur LoST [RFC5222], appelés des chercheurs, contactent les résolveurs qui mettent en antémémoire les résultats d'interrogations et connaissent un ou plusieurs guides forestiers. Les guides forestiers forment le niveau supérieur d'une hiérarchie conceptuelle, avec une ou plusieurs arborescences fournissant un service de résolution hiérarchique pour les différentes régions géographiques. Les guides forestiers connaissent la région géographique de couverture de toutes ou presque toutes les arborescences et dirigent les interrogations sur le nœud au sommet de l'arborescence appropriée. Les arborescences consistent en serveurs de transposition d'autorité et maintiennent les informations de transposition d'autorité.

Les chercheurs, résolveurs, serveurs de transposition d'autorité, et guides forestiers communiquent tous en utilisant LoST ; bien sûr, il est probable que, dans bien des cas, le même logiciel peut opérer comme résolveur, serveur de transposition d'autorité, et guide forestier. En plus du protocole de base d'interrogation LoST [RFC5222], un protocole de synchronisation [RFC6739] peut être utilisé pour échanger des informations entre les guides forestiers ou pour pousser les informations de couverture d'un nœud d'arborescence à son parent.

Les chercheurs peuvent faire partie de systèmes d'extrémité de voix sur IP (VoIP, Voice over IP) ou autres, ou de mandataires SIP ou fonctions similaires d'acheminement d'appel.

La Figure 1 montre l'interaction des composants. Les lignes qui indiquent la connexion entre les guides forestiers sont des connexions logiques, indiquant qu'elles synchronisent leurs informations via le protocole de synchronisation [RFC6739].

          /-\        /-\        +-----+                 +-----+
         | S +******* R *********  FG *-----------------+  FG |
          \-/        \-/        |     |*                |     |
                                +--+--+  *              +--+--+
                                   |      *                |
                                   |       *               |
                                   |        *              |
                                   |        *              |
                     /-\        +--+--+     *           +--+--+
                    | R +------>+  FG +-----*-----------+  FG |
                     \-/        |     |     *           |     |
                                +--+--+    *            +--+--+
                                   |      *                |
                                   |     *                 |
                                   |    *                  |
                                   |***                    ^
                                  / \                     / \
                                 /   \                   /   \
                                /     \                 /     \
                               /       \               /       \
                              -----------             -----------
                              arborescence            arborescence

Diagramme de l'architecture, montrant les chercheurs (S), les résolveurs (R), les guides forestiers (FG), et les arborescences. La ligne "*" indique le flux des interrogations et réponses en mode récurrent, tandis que les lignes indiquent les relations de synchronisation.

Figure 1

La fonction de transposition pour le monde est divisée en arborescences. La collection des arborescences ne peut pas couvrir le monde entier, et les arborescences sont ajoutées et supprimées lorsque l'organisation des données de transposition change. On appelle la collection des arborescences une forêt. Il n'y a pas de limite au nombre d'arborescences dans la forêt, mais l'auteur estime que le nombre d'arborescences va probablement être quelque part entre quelques centaines et quelques milliers. La plus basse estimation s'appliquerait si chaque pays utilise une arborescence, la plus haute si différentes  organisations gouvernementales ou privées dans un pays utilisent des arborescences indépendantes. On suppose que les informations de couverture changent relativement lentement, de l'ordre de moins d'un changement par an par arborescence, bien que le système n'impose pas de seuil spécifique. La couverture d'arborescence changerait, par exemple, si un pays est partagé ou fusionné ou si deux arborescences pour des régions différentes deviennent des parties d'une plus grande arborescence. (D'un autre côté, les informations dans une arborescence vont probablement changer plus fréquemment.)

 	4.2	Architecture de système minimal
Il est possible de construire un système fonctionnel consistant seulement en chercheurs et résolveurs si ces résolveurs ont d'autres moyens d'obtenir les données de transposition. Par exemple, une entreprise agissant comme fournisseur de service de transposition pourrait collecter manuellement des enregistrements de transposition et les rendre disponibles à ses consommateurs à travers le résolveur. Bien que faisable comme point de départ, une telle architecture a peu de chances de s'adapter mondialement. Entre autres problèmes, il devient très difficile aux fournisseurs de données d'autorité de s'assurer que tous ces fournisseurs aient des informations à jour. Si de nouvelles arborescences sont établies, elles vont se faire connaître à ces fournisseurs. Un tel mécanisme serait similaire au vieux mécanisme "hosts.txt" pour distribuer les informations d'hôtes dans l'ancien Internet d'avant le développement du DNS.

On décrit ci-dessous le fonctionnement de chaque composant plus en détail.

 	5.	Chercheur

Les clients qui désirent des transpositions de localisation en service sont appelés des chercheurs. Les chercheurs sont des consommateurs de données de transposition et génèrent des interrogations LoST comme clients de protocole LoST. Les chercheurs ne répondent pas aux interrogations LoST. Ils contactent des guides forestiers ou des résolveurs pour trouver l'arborescence appropriée qui peut faire une réponse d'autorité à leurs questions. Les chercheurs peuvent être des systèmes d'extrémité comme des agents d'utilisateur SIP, ou des entités d'acheminement d'appel comme des serveurs mandataires SIP.

Les chercheurs peuvent avoir besoin d'obtenir des informations de transposition en plusieurs étapes, c'est-à-dire, ils peuvent obtenir des pointeurs sur des serveurs intermédiaires qui les conduisent plus près de la transposition finale. Les chercheurs  PEUVENT mettre en antémémoire les résultats pour une utilisation ultérieure mais n'ont autrement aucune obligation envers les autres entités du système.

Les chercheurs doivent être capables d'identifier les résolveurs appropriés. Le mécanisme pour fournir cette information aux chercheurs va probablement différer selon l'opérateur des résolveurs. Par exemple, si le fournisseur de services vocaux fait fonctionner le résolveur, il pourrait inclure la localisation du résolveur dans les informations de configuration SIP qu'il distribue à ses agents d'utilisateur. Un fournisseur d'accès Internet (FAI) ou une entreprise peut fournir un pointeur sur un résolveur via DHCP [RFC5223]. Dans un environnement ad hoc ou de configuration zéro, les répertoires de services appropriés peuvent annoncer les résolveurs.

Comme les autres entités dans le système, les chercheurs peuvent mettre les réponses en antémémoire. Ceci est particulièrement utile si la réponse décrit le résultat pour une région civile ou géospatiale, plutôt que juste un point. Par exemple, pour les nœuds mobiles, les chercheurs vont seulement devoir mettre à jour leurs résultats de résolution quand ils quittent la zone de couverture d'un fournisseur de service, comme un PSAP pour les services d'urgence, et peuvent éviter de répéter les interrogations sur cette information chaque fois que les informations de localisation changent légèrement. (Les nœuds mobiles auront aussi besoin d'un mécanisme de mise à jour de localisation local ou déclenché quand ils quittent la zone de service actuelle.) Cela va probablement être d'un bénéfice particulier pour les chercheurs qui représentent une grande population d'utilisateurs, comme le mandataire sortant d'un réseau d'entreprise. Par exemple, plutôt que d'avoir à interroger séparément pour chaque département, les informations fournies par le nœud d'autorité peuvent indiquer que tout le campus est couvert par le même fournisseur de service.

Étant donné ce mécanisme de mise en antémémoire et des durées de vie d'antémémoire de plusieurs jours, la plupart des utilisateurs mobiles qui voyagent de et vers leur travail vont seulement avoir besoin d'obtenir les informations de zone de service le long de leur chemin de commutation une fois durant chaque durée de vie d'antémémoire.

 	6.	Résolveur

Un chercheur peut contacter un guide forestier (voir ci-dessous) directement, mais peut ne pas être capable de localiser facilement un tel guide. De plus, les chercheurs dans la même zone géographique peuvent déjà avoir posé la même question. Donc, il y a du sens à introduire une autre entité, appelé un résolveur dans l'architecture, qui sait comment contacter un ou plusieurs guides forestiers et qui met en antémémoire les interrogations antérieures pour accélérer la réponse aux interrogations de transposition et améliorer la résilience du système. Chaque résolveur peut décider de façon autonome quels FG utiliser, avec éventuellement des choix différents pour chaque service de niveau supérieur.

Les FAI ou les fournisseurs de services vocaux (VSP, Voice Service Provider) peuvent inclure l'adresse d'un résolveur convenable dans leurs informations de configuration, par exemple, dans la configuration SIP pour un VSP ou DHCP [RFC5223] pour un FAI. Les résolveurs sont configurés manuellement avec le nom d'un ou plusieurs guides forestiers.

 	7.	Arborescences : maintien d'une connaissance d'autorité
 	7.1	Fonctionnement de base
L'architecture suppose que la connaissance d'autorité sur les données de la transposition est distribuée parmi de nombreuses entités administratives indépendantes, mais les clients (chercheurs) peuvent potentiellement devoir découvrir les informations de transposition pour n'importe quel point sur terre. (Les extensions aux applications extra terrestres sont laissées pour une future exploration.) Les informations sont organisées hiérarchiquement dans une arborescence, avec les nœuds de l'arborescence représentant de plus grandes zones géographiques pointant sur plusieurs nœuds fils, représentant chacun une plus petite zone. Chaque nœud de l'arborescence peut être une grappe de serveurs LoST qui tous contiennent les mêmes informations et servent de secours à chaque autre.

Chaque arborescence peut transposer une localisation décrite par des coordonnées civiles et/ou géographiques pour un type de service (comme "sos.police", "sos.incendie" ou "assistance") bien que rien n'empêche de réutiliser les même serveurs pour plusieurs services différents. La collection de toutes les arborescences pour un service est appelée une forêt.

Chaque arborescence racine annonce sa région de couverture à un ou plusieurs guides forestiers.

Chaque grappe de nœuds d'arborescence connaît la région de couverture de ses fils et envoie des interrogations au serveur appropriée "en descendant" l'arborescence. Chacun de ces nœuds de l'arborescence connaît les transpositions de service d'autorité pour une région particulière, normalement, mais pas nécessairement, contiguë. La région peut être décrite par une des formes de la spécification LoST exprimée en coordonnées géospatiales, comme des cercles ou des polygones, ou un ensemble de descripteurs d'adresse civile (par exemple, "pays = DE, A1 = Bavière"). Ces régions de couverture peuvent être alignées avec des frontières politiques, mais ce n'est pas exigé. Dans la plupart des cas, pour éviter des confusions, seulement une grappe est responsable pour une localisation géographique ou civile particulière, mais le système peut aussi traiter des cas où les régions de couverture se chevauchent.

Il n'y a pas d'hypothèses sur la région de couverture d'une arborescence comme un tout. Par exemple, une arborescence pourrait couvrir une seule ville, un état/province, ou tout un pays. Les nœuds au sein d'une arborescence ont besoin de coordonner vaguement leur fonctionnement, mais ils n'ont pas besoin d'être gérés par le même administrateur.

L'architecture d'arborescence est en gros similaire au système des noms de domaine (DNS) sauf que la délégation n'est pas par étiquettes mais plutôt par régions. (Naturellement, le DNS n'a pas de notion de guides forestiers.) On peut aussi faire des analogies avec le protocole léger d'accès à un répertoire (LDAP, Lightweight Directory Access Protocol) quand il est déployé de façon répartie.

Les nœuds d'arborescence maintiennent deux types d'informations -- à savoir, les régions de couverture et les transpositions. Les régions de couverture décrivent la région desservie par un nœud fils dans l'arborescence et pointent sur un nœud fils pour plus de résolution. Les transpositions contiennent un URI de service réel menant à un fournisseur de service ou à un autre serveur de signalisation représentant un groupe de fournisseurs de service, qui à leur tour pourraient acheminer les demandes de signalisation à plus de serveurs couvrant de plus petites régions.

Les nœuds d'extrémité, c'est-à-dire, les nœuds sans fils, maintiennent seulement les transpositions, tandis que les nœuds d'arborescence au-dessus des nœuds d'extrémité maintiennent seulement les régions de couverture. Un exemple d'une entrée de nœud d'extrémité pour les services d'urgence est montré ci-dessous, indiquant comment les interrogations pour trois villes sont dirigées sur des PSAP différents. Les interrogations pour Englewood sont dirigées sur un autre serveur LoST.

Pays         A1 A2            A3            ressource ou serveur LoST
 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
 ....

Les régions de couverture sont décrites par des ensembles de formes compatibles avec LoST incluant les zones géographiques contiguës ou par des descripteurs énumérant les groupes de localisations civiles. Pour les premières, le serveur LoST effectue la même opération de correspondance décrite au paragraphe 12.2 de la spécification LoST [RFC5222] pour trouver l'arborescence ou l'AMS.

Comme exemple de localisation civile, un nœud d'arborescence de niveau état pour le New Jersey au États Unis peut contenir les entrées de région de couverture montrées ci-dessous, indiquant que toute interrogation correspondant à une localisation dans le comté de Bergen, par exemple, va être redirigé ou transmis au nœud situé à bergen.nj.exemple.org.

Il n'est pas exigé que tous les nœuds fils couvrent le même niveau au sein de la hiérarchie civile. Par exemple, dans le tableau ci-dessous, la ville de Newark a décidé d'être mentionnée directement au sein du nœud d'état, plutôt que par le comté. Les règles de plus longue correspondance permettent une couverture partielle afin que les interrogations pour toutes les autres villes dans le comté d'Essex soient dirigées sur le nœud du comté pour plus de résolution.

Pays         A1 A2            A3            Nom du serveur LoST
 US        NJ Atlantic        *              atlantic.nj.exemple.org/sos
 US        NJ Bergen         *               bergen.nj.exemple.org/sos
 US        NJ Monmouth   *               monmouth.nj.exemple.org/sos
 US        NJ Essex            *              essex.nj.exemple.org/sos
 US        NJ Essex        Newark       newark.exemple.com/sos
 ....

Donc, il n'y a pas de différence substantielle entre la région de couverture et les données de transposition. La seule différence est que les régions de couverture retournent les noms des serveurs LoST, tandis que les entrées de transposition contiennent les URI de services. Les entrées de transposition peuvent être spécifiques jusqu'au niveau de la maison ou de l'étage ou peuvent contenir seulement des informations du niveau de la rue. Par exemple, aux États Unis, les données de transposition civiles pour les services d'urgence sont généralement limitées à des gammes d'adresses ("données MSAG") de sorte que les bases de données de transposition initiales peuvent seulement contenir des informations du niveau de la rue.

Pour automatiser la maintenance des arborescences, le mécanisme de synchronisation de LoST [RFC6739] permet aux nœuds d'interroger d'autres nœuds sur les données de transposition et les régions de couverture, au sein d'une grappe et à travers les différents niveaux de hiérarchie dans une arborescence. Dans l'exemple ci-dessus, le nœud géré par l'état interrogerait les nœuds de comté et utiliserait les enregistrements retournés pour distribuer les interrogations LoST entrantes aux nœuds de comté. À l'inverse, les nœuds pourraient aussi contacter leurs nœuds parents pour leur dire leur région de couverture. Il y a des avantages à ce que les nœuds fils contactent leurs parents, car cela permet que des changements dans les régions de couverture se propagent rapidement jusqu'en haut de l'arborescence.

 	7.2	Réponse aux interrogations
Au sein d'une arborescence, le fonctionnement de base est direct. Une interrogation atteint la racine de l'arborescence. Ce nœud détermine quelle région de couverture correspond à cette demande et transmet la demande au serveur indiqué dans l'enregistrement de région de couverture, retournant une réponse à l'interrogateur quand il reçoit à son tour une réponse (récurrence). Autrement, le nœud retourne la chaîne unique d'application (nom de serveur) de ce nœud fils à l'interrogateur (itération). Ce processus s'applique à chaque nœud, c'est-à-dire, un nœud n'a pas besoin de savoir si l'interrogation originale venait d'un nœud parent, d'un chercheur, d'un guide forestier, ou d'un résolveur.

Pour être efficace, un nœud PEUT retourner des informations de région au lieu d'une réponse d'un point. Donc, au lieu de retourner qu'une coordonnée géospatiale particulière se transpose en un URI de service ou un nom de serveur, il PEUT retourner un polygone indiquant la région pour laquelle cette réponse va être retournée, avec les informations d'heure d'expiration (durée de vie). Le nœud interrogateur peut alors mettre ces informations en antémémoire pour une future utilisation.

Pour les coordonnées civiles, les arborescences ne peuvent pas inclure des enregistrements de transposition individuels pour chaque étage, numéro de maison, ou rue. Pour éviter de donner une fausse indication qu'une localisation particulière a été trouvée valide, LoST peut indiquer quelles parties des informations de localisation ont réellement été utilisées pour chercher une transposition.

 	7.3	Chevauchement des régions de couverture
Dans certains cas, les régions de couverture peuvent se chevaucher, soit parce que il y a un conflit sur qui porte sur une région géographique particulière, soit plus probablement, parce que la résolution de la carte de couverture ne peut pas être suffisamment précise. Par exemple, un nœud peut "raser certains coins" de son polygone de sorte que sa région de couverture paraît se chevaucher avec celle de son voisin géographique. Pour les coordonnées civiles, les maisons sur la même rue peuvent être servies par différents PSAP. Le mécanisme de transposition doit fonctionner même si une carte de couverture est imprécise ou si ils y a des conflits sur la couverture.

La solution pour les chevauchements de régions de couverture est relativement simple. Si une interrogation correspond à plusieurs régions de couverture, le nœud retourne tous les URL ou noms de serveurs, en mode redirection, ou les interrogations des deux fils, si on est en mode récurrent. Si le chevauchement de couverture est causé par des cartes de couverture imprécises, seulement une va retourner un résultat et les autres vont retourner une indication d'erreur. Si la localisation particulière est un territoire contesté, la réponse va contenir toutes les réponses, laissant à l'interrogateur le choix de la solution préférée ou d'essayer de contacter tous les services tour à tour.

 	7.4	Échelle et fiabilité
Comme ils fournissent des informations d'autorité, les nœuds d'arborescence doivent être très fiables. Donc, alors que le présent document se réfère aux nœuds d'arborescence comme à des entités logiques au sein de l'arborescence, une mise en œuvre réelle va probablement dupliquer les informations de nœud sur plusieurs serveurs, formant une grappe. Chacun de ces nœuds va avoir les mêmes informations. Des techniques standard comme les enregistrements SRV du DNS peuvent être utilisées pour choisir un des serveurs. La duplication au sein de la grappe peut utiliser tout mécanisme de protocole convenable, mais un mécanisme de mise à jour incrémentaire normalisé rend plus facile d'étaler ces nœuds à travers plusieurs localisations administrées de façon indépendante. Les techniques développées pour le protocole de localisation de service (SLP, Service Location Protocol) [RFC3528] maillé sont applicables ici.

 	8.	Guides des arborescences

Malheureusement, avoir juste des arborescences couvrant diverses régions du monde n'est pas suffisant, car un client du protocole de transposition ne va généralement pas être capable de garder trace de toutes les arborescences dans la forêt. Pour faciliter l'orientation parmi les arborescences, on introduit un guide forestier (FG), qui garde trace des régions de couverture de toutes les arborescences pour un service. Pour l'adaptabilité et la fiabilité, il va devoir y avoir un grand nombre de guides forestiers, fournissant tous les mêmes informations. Un chercheur peut contacter un guide forestier  convenable et sera alors dirigé sur la bonne arborescence ou, rarement, ensemble d'arborescences. Les guides forestiers ne fournissent pas eux-mêmes les informations de transposition, mais plutôt redirigent sur les serveurs de transposition. Dans certaines configurations, tous les guides forestiers ne peuvent pas fournir les mêmes informations, pour des raisons de politique.

Les guides forestiers remplissent un rôle similaire à celui des serveurs racines dans le DNS. Ils distribuent les informations, signées pour l'authenticité, offertes par les arborescences. Cependant, introduire des guides forestiers évite de créer une racine globale, avec les problèmes de gestion et de contrôle qui en découlent.

Cependant, à la différence des serveurs racines du DNS, les guides forestiers peuvent offrir des informations différentes sur la base de la politique locale. Les guides forestiers peuvent aussi restreindre leur synchronisation de données à des parties des informations. Par exemple, si le pays C ne reconnaît pas le pays T, C peut propager des régions d'arborescence pour tous sauf T.

Pour l'authenticité, les régions de couverture DEVRAIENT être signées numériquement par les autorités responsables de la région, comme discuté plus en détails à la Section 10. Elles sont utilisées par les résolveurs et éventuellement par les chercheurs pour trouver l'arborescence appropriée pour une zone particulière. Tous les guides forestiers devraient avoir des informations cohérentes, c'est-à-dire, une collection de toutes les régions de couverture de toutes les arborescences. Un nœud d'arborescence au sommet d'une arborescence peut contacter tout guide forestier et injecter de nouvelles informations de couverture de région dans le système. On s'attend à ce que chaque arborescence annonce sa couverture à plus d'un guide forestier. Chaque guide forestier échange du trafic avec un ou plusieurs autres guides et distribue les nouvelles annonces de région de couverture aux autres guides. Du fait de la politique et peut-être de raisons de politique, tous les guides forestiers ne peuvent pas partager les mêmes données de région de couverture.

Les guides forestiers peuvent, en principe, être gérés par n'importe qui, incluant des fournisseurs de service vocal, des fournisseurs d'accès Internet, des fournisseurs de services dédiés, et des entreprises.

Comme dans l'acheminement, l'échange de trafic avec les autres guides forestiers implique une certaine quantité de confiance dans l'homologue. Donc, l'échange de trafic va probablement exiger des négociations entre les parties administrantes concernées, plutôt qu'une configuration automatique. Le mécanisme lui-même n'implique pas une politique particulière sur qui doit annoncer une région de couverture particulière.

 	9.	Configuration des numéros de service

La présente section n'est pas en relation directe avec le problème de la détermination de la localisation de service mais est une instance du problème plus générique résolu par cette architecture -- à savoir, la transposition des informations de localisation en paramètres relatifs au service, comme les numéros de service.

Dans l'avenir prévisible, certains appareils et logiciels d'utilisateur vont émuler l'interface d'utilisateur d'un téléphone, c'est-à-dire, la seule façon d'entrer les informations d'adresse d'appel est via un clavier de 12 boutons avec des chiffres et les symboles étoile et dièse. Ces appareils utilisent les numéros de service pour identifier les services. Les exemples les plus connus de numéros de service sont les numéros d'urgence, comme le 9-1-1 en Amérique du Nord et le 1-1-2 en Europe. Cependant, de nombreux autres numéros de service publics et privés ont été définis, allant aux États Unis du 3-1-1 pour les services gouvernementaux locaux non d'urgence, au 4-1-1 pour l'assistance à l'annuaire, aux divers numéros "800" pour tout ce qui va de l'assistance routière aux services juridiques et la livraison de nourriture à domicile.

De tels numéros de service vont probablement être utilisés jusqu'à ce que essentiellement tous les appareils de communication proposent la connexité IP et un clavier alphanumérique. Malheureusement, pour les services d'urgence, plus de 60 numéros d'urgence sont utilisé tout autour du monde, avec beaucoup de ces numéros qui servent à autre chose que des numéros d'urgence ailleurs, par exemple, à identifier des services de réparation ou d'annuaire. Les pays changent aussi occasionnellement leurs numéros d'urgence pour se conformer à des accords régionaux. Un exemple est l'introduction du "1-1-2" dans les pays d'Europe.

Donc, un système qui permet aux appareils d'être utilisés internationalement pour passer des appels doit permettre aux appareils de découvrir automatiquement les numéros de service. Dans le système fondé sur l'Internet proposé dans la [RFC6443], ces numéros sont strictement utilisés comme un mécanisme d'interface d'utilisateur humain et sont généralement non visibles dans les messages de signalisation d'appel, qui portent à la place l'URN de service [RFC5031].

Pour une meilleure expérience d'utilisateur, les systèmes devraient être capables de découvrir deux ensembles de numéros de service -- à savoir, ceux utilisés dans le pays de rattachement de l'utilisateur et ceux utilisés dans le pays que l'utilisateur visite actuellement. L'utilisateur va probablement se souvenir des premiers, mais un accompagnant qui emprunte un appareil en cas d'urgence peut seulement connaître les numéros d'urgence locaux.

Déterminer les numéros de service de rattachement et locaux est un problème de configuration, mais malheureusement, les mécanismes de configuration existants sont mal adaptés pour cela. Par exemple, un serveur DHCP pourrait être capable de donner les numéros de service locaux mais pas les numéros du lieu de rattachement. Quand des réseaux privés virtuels  (VPN, virtual private network) sont utilisés, même DHCP peut fournir des numéros d'origine incertaine, car un utilisateur peut contacter le réseau de rattachement ou un bureau local du réseau d'entreprise. De même, la configuration SIP [RFC6080] serait capable de fournir des numéros valides à la localisation du fournisseur de service SIP, mais même un fournisseur de service SIP avec une empreinte nationale peut servir des consommateurs qui visitent n'importe quel autre pays.

Aussi, bien qu'initialement il ne va probablement y avoir que quelques numéros de service, par exemple, pour les services d'urgence, l'architecture LoST peut être utilisée pour prendre en charge d'autres services, comme on l'a noté. Configurer chaque serveur local de configuration DHCP ou SIP avec ces informations serait probablement enclin à l'erreur et fastidieux.

Pour ces raisons, l'architecture de transposition fondée sur LoST prend en charge la fourniture des numéros de service aux systèmes d'extrémité sur la base de la localisation de l'appelant. L'opération de transposition est presque exactement la même que pour déterminer l'URL de service. La transposition peut être obtenue avec l'URL de service. La différence majeure entre les deux demandes est que les numéros de service ont souvent des régions de validité beaucoup plus grandes que l'URL de service lui-même. Aussi, le numéro de service va probablement être valide plus longtemps que l'URL de service. Finalement, un système d'extrémité peut vouloir chercher le numéro de service pour sa localisation de rattachement, pas juste pour sa localisation actuelle (visitée).

 	10.	Considérations sur la sécurité

Les considérations de sécurité pour les transpositions de services d'urgence sont discutées dans la [RFC5069], tandis que la [RFC5031] discute les questions relatives à l'URN de service, une des entrées au protocole de transposition. Les considérations de sécurité relatives à LoST sont naturellement discutées dans la spécification de LoST [RFC5222].

L'architecture traite les questions de sécurité suivantes, généralement à travers les associations de sécurité de transport sous-jacentes :

Travestissement de serveur : les chercheurs, résolveurs, guides forestiers, et membres de grappes peuvent s'assurer de l'identité de la partie distante en utilisant les facilités du mécanisme de sécurité du canal sous-jacent, comme la sécurité de la couche transport (TLS, Transport Layer Security) [RFC5246].

Corruption de l'interrogation ou de son résultat : pour éviter la possibilité qu'un attaquant modifie l'interrogation ou son résultat, l'architecture RECOMMANDE l'utilisation de la sécurité du canal, comme TLS. Les résultats DEVRAIENT aussi être signés numériquement, par exemple, en utilisant des signatures numériques XML [XMLDSIG]. Noter cependant que la simple assertion d'origine ne peut pas fournir au système d'extrémité assez d'informations utiles car il n'a pas de bon moyen de savoir qu'un signataire particulier est autorisé à représenter une zone géographique particulière. Il pourrait être nécessaire que certaines autorités de certification (CA, Certificate Authority) bien connues valident les sources d'informations de transposition et fournissent des certificats spéciaux à cette fin. Dans de nombreux cas, un chercheur va devoir faire confiance à son résolveur local pour valider que les informations sont dignes de confiance ; à son tour, le résolveur peut s'appuyer sur des guides forestiers de confiance pour le diriger sur les informations correctes.

Corruption de la région de couverture : pour éviter la possibilité qu'un tiers ou un membre non fiable d'une population de serveurs prétendant à la région de couverture pour laquelle il n'est pas autorisé, tout nœud introduisant une nouvelle frontière de service DOIT signer l'objet en protégeant les données avec une signature numérique XML [XMLDSIG]. Un receveur DOIT vérifier, par un mécanisme de politique locale, que l'entité signataire est bien autorisée à parler pour cette région. Déterminer qui peut parler pour une région particulière est par nature difficile sauf si il y a un petit ensemble d'entités autorisées auxquelles les participants à l'architecture de transposition peuvent se fier. Les systèmes receveurs devraient être particulièrement soupçonneux si une région de couverture existante est remplacée par une nouvelle avec une nouvelle adresse de transposition. Dans de nombreux cas, la confiance va être médiatisée : un charcheur va avoir une relation de confiance avec un résolveur, et le résolveur, à son tour, va contacter un guide forestier de confiance.

Les menaces supplémentaires qui devraient être traitées par des mesures opérationnelles incluent des attaques de déni de service [PHONE-BCP].

 	11.	Remerciements

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, et Karl Heinz Wolf ont fourni d'utiles commentaires.

 	12.	Références
 	12.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC5031]	H. Schulzrinne, "Nom de ressource uniforme (URN) pour services d'urgence et autres services bien connus", janvier  2008. (P.S.) (MàJ par RFC7163)

[RFC5222]	T. Hardie et autres, "LoST : un protocole de traduction de localisation en service", août 2008. (P.S. ; MàJ par RFC8917, 9036)

[RFC5223]	H. Schulzrinne et autres, "Découverte des serveurs de traduction de localisation en service (LoST) avec le protocole de configuration dynamique d'hôte (DHCP)", août 2008. (P.S.)

 	12.2	Références pour information

[PHONE-BCP]	Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Travail en cours, mars 2009.

[RFC3528]	W. Zhao et autres, "Protocole de localisation de service à maillage amélioré (mSLP)", avril 2003. (Expérimentale)

[RFC5012]	H. Schulzrinne, R. Marshall, éd., "Exigences pour la résolution de contexte d'urgence avec les technologies de l'Internet", janvier 2008. (Information)

[RFC5069]	T. Taylor et autres, "Menaces sur la sécurité et exigences pour le marquage et la transposition d'appels d'urgence", janvier  2008. (Information)

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; remplacée par la RFC8446)

[RFC6080]	D. Petrie, S. Channabasappa, éd., "Cadre pour la livraison de profil d'agent d'utilisateur du protocole d'initialisation de session", mars 2011, DOI 10.17487/RFC6080. (P. S.)

[RFC6443]	B. Rosen, H. Schulzrinne, J. Polk, A. Newton, "Cadre pour les appels d’urgence qui utilisent l’Internet multi supports", décembre 2011. (Information)

[RFC6739]	H. Schulzrinne, H. Tschofenig, "Synchronisation des frontières de service et des éléments <transposition> sur la base du protocole de traduction de localisation en service (LoST)", octobre 2012. (Expérimental)

[XMLDSIG]	Solo, D., Eastlake, D., and J. Reagle, "XML-Signature Syntax and Processing", World Wide Web Consortium FirstEdition REC-xmldsig-core-20020212, février 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.

 	Adresse de l'auteur

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY  10027
US

téléphone : +1 212 939 7004
mél : hgs+ecrit@cs.columbia.edu
URI : http://www.cs.columbia.edu