Vous êtes sur la page 1sur 64

IMS DEFIS MIGRATOIRES ET CONCEPTION DU MISE EN UVRE D'UN SYSTEME DE NOMMAGE INTENTIONNEL

Sommaire
Parte I
IMS DEFIS MIGRATOIRES ET LA SOLUTIONS: VERS UNE ARCHITECTURE DE TELEPHONIE MULTIMEDIA AMELIORE Rsum 1. prsentation 2. L'architecture IMS 3. La promesse de l'IMS 4. Migration et mise en uvre dfis 5. META: Une solution relle pour IMS migrations 6. META lments de rseau 7. Surmonter les dfis: le META Avantage Meta Switch 9. conclusion

Parte II
LA CONCEPTION DU MISE EN UVRE D'UN SYSTEME DE NOMMAGE INTENTIONNEL Rsum 1. Introduction 2. Architecture du systme 2.1 Nom prescripteurs 2.2 Noms dcouverte 2.3 recherche de nom et de l'extraction 2.3.1 Nom des arbres 2.3.2 Nom de recherche 2.3.3 Extraction de nom 2.4 Rseau du rsolveur 2.5 L'quilibrage de charge et de mise l'chelle 3. Applications 3.1 Amnagement intrieur: un outil de dcouverte de service 3.2 Camra: un service de camra mobile 3.3 Printer: un utilitaire de l'imprimante d'quilibrage de charge 4. Mise en uvre 5. Analyse et valuation du rendement 5.1 Nom performances de recherche 5.1.1 Analyse 5.1.2 Les expriences 5.2 Nom performances de dcouverte 5.3 Performance Routing 6. travaux connexes 7. conclusions

Parte I IMS DEFIS

Rsum

Les transporteurs, les fournisseurs de services et les fournisseurs d'quipement ont t vantant les avantages de rseau convergence de nombreuses annes, mais la convergence est reste assez vasif dans la plupart des tlcoms rseaux. Le soussystme multimdia IP (IMS) vise aider les oprateurs dans ce processus, en fournissant un plan que les transporteurs peuvent suivre afin d'atteindre l'objectif insaisissable de la convergence des rseaux. En plus de bnficier les transporteurs, les consommateurs bnficieront galement de l'architecture IMS, comme IMS fournit une cadre pour la prestation de services facile et plus rapide avec une meilleure qualit, ce qui devrait fournir plus riche, plus services de communications accessibles. Ce Mmoire aborde l'architecture IMS, y compris de nombreux lments techniques trouvs dans l'IMS, certains des facteurs oprationnels pour la mise en uvre de l'IMS, ainsi que les nombreux dfis qui les transporteurs devront faire face la migration vers un avenir bas sur IMS. Enfin, on introduit la Meta Switch solution complte IMS, l'architecture de tlphonie multimdia-Enabled (META) qui permet l'IMS vision tout en abordant les questions de migration des transporteurs

1. INTRODUCTION

Le sous-systme multimdia IP (IMS) est une nouvelle architecture passionnante qui permettra aux transporteurs de combiner Applications et services la tlphonie sans fil et filaires bass sur Internet, ouvrant la voie la possibilit relle de la convergence des rseaux fixe / mobile. IMS est aussi, peut-tre tout aussi important, le plus plan dtaill ce jour pour la conception dune infrastructure flexible, ouvert, bas sur des paquets rseau qui prend en charge la fourniture de services multimdias et des applications la fois sur filaire et sans fil les rseaux d'accs. En dfinissant des interfaces ouvertes pour fonctions d'infrastructure communs tels que profil d'abonn donnes, la charge, l'authentification et le service de dclenchement, et en s'appuyant sur Internet technologies connexes telles que l'initiation de session Protocol (SIP) et extensible Markup Language (XML), IMS rduit radicalement les cots et complexit du dveloppement et le dploiement de nouvelles services. Les fonctions essentielles de l'IMS fournissent une plateforme pour la fourniture de toutes sortes multimdia applications et services de communications, y compris la voix et la tlphonie vido, la voix, le texte et la messagerie vido, les services bass sur la prsence et push-to-talk. En outre, le noyau IMS fonctions sont capables de fournir tous ces services un large ventail de dispositifs d'accs au cble, The 3GPP initiated IMS for packetrseaux sans fil fixes sans fil et mobiles, et l'itinrance entre et parmi ceux-ci rseaux. Cette universalit est la cl de l'norme appel d'IMS. 1.1 Pourquoi IMS? L'architecture IMS offre des avantages tant pour les fournisseurs de services et les consommateurs, en plus de les fournisseurs qui produisent le matriel qui fera l'IMS une ralit. Les principaux avantages de l'IMS sont aussi suit.

Un choix plus large de services - IMS utilise un ensemble de standard ouvert de protocoles entre les composants, et permet donc les fournisseurs de rseaux de pick and mix" les composants dans leur rseau IMS. En particulier, les fournisseurs de rseau peuvent slectionner les services d'application les plus appropris partir de plusieurs vendeurs, en fonction de leurs besoins spcifiques. Un choix plus large de services est clairement un avantage pour les utilisateurs finaux ainsi. Plus de choix devrait se traduire par une concurrence froce pour les abonns, qui devrait, son tour, entraner davantage de services moindre cot pour le consommateur. Les dveloppeurs de ces nouveaux services devraient galement voir une augmentation de la demande pour leurs produits. Les dlais de commercialisation rduits - Un fournisseur de rseau IMS-enabled n'est plus lie aux dlais et les fonctions des services offerts par leur fournisseur d'quipement primaire. Adoption du tueur apps "sera plus rapide pour les fournisseurs qui ont une infrastructure IMS dj en place. Les abonns bnficieront galement de cela, que les nouveaux services seront disponibles plus rapidement qu'ils ne l'taient prcdemment. Rsultats d'exploitation consolids - IMS spare les fonctions de base, telles que la facturation de services et gestion. Cela signifie que les systmes back-end n'ont besoin que d'tre intgr l'IMS infrastructure et non avec les services individuels. De nouveaux services peuvent tre dploys sans avoir former le personnel sur les aspects d'approvisionnement, de facturation et de gestion de ce nouveau service. Abonns, nous l'esprons bnficier de ces oprations rationalises sous la forme de prix plus bas pour services. La convergence fixe-mobile (FMC) - IMS est indpendante du transport des mdias sous-jacent. IMS- services applicatifs bass peuvent s'tendre sur les deux rseaux de tlphonie fixe et mobile, ainsi que VoIP, quoique le niveau de la fonction de l'utilisateur final dlivr puisse varier en fonction des capacits du systme d'extrmit. Comme l'industrie des tlcoms se consolide, il y a un besoin croissant pour cette application convergence de services. Les abonns profiteront certainement de FMC, que les mmes services seront disponibles sur la totalit de leurs dispositifs d'accs, plutt que le modle de service spcifique de l'appareil qui est actuellement la norme. Alors que tous les ci-dessus peuvent tre ralises dans d'autres architectures (par exemple, les implmentations propritaires peut permettre la convergence fixe mobile), IMS a acquis une reconnaissance gnralise de l'industrie comme le plus architecture lgante construit sur des standards ouverts.

Dploiement de solutions IMS compatibles se traduira par un plus large ventail de services pour l'utilisateur final, qui son tour accrotre client "collant" et sans fournisseur de rseau de rivaliser sur un produit "bit-pipe" base.

2. L'ARCHITECTURE IMS
2.1 Aperu

L'IMS est une architecture de communication en couches qui exploite une gamme de prexistante de l'industrie protocoles standards tels que Session Initiation Protocol (SIP), H.248 et SIGTRAN. Parmi ceux-ci, SIP est le plus important tant le protocole de signalisation utilis tout au long de l'IMS pour tout appel / session de contrle. Il est trs important de noter que les seuls dtails IMS plusieurs entits fonctionnelles (ou fonctions de service) qui sont les blocs de construction de l'infrastructure. Chacune de ces entits fonctionnelles a bien dfini ouvert interfaces qui leur sont associs afin de rendre plus facile pour les fournisseurs de services de dployer des solutions qui fournir la fonction ncessaire et / ou de l'interface entre les diffrentes parties du systme, ainsi que pour fournisseurs pour dvelopper des best of breed" solutions qui composent l'architecture (au moins en thorie). Signalisation et les chemins mdias ont t spars, similaire au rseau tlphonique SS7, et de nombreuses fonctions ont la fois une signalisation et composantes mdias qui leur sont associs. La norme IMS comprend des spcifications pour les interfaces avec les rseaux IP et les "legs" ligne fixe et rseaux sans fil. Pour les rseaux IP, IMS prend en charge les appels SIP de terminaux travers publiques ou les rseaux privs. Appels travers le rseau public utilisent une fonction de passerelle frontire (gnralement mis en uvre aujourd'hui dans les produits de contrleur de session en intgres) pour assurer le contrle ncessaire pour les appels IP d'itinraire par l'utilisateur de et / ou pare-feu de fournisseur. Les appels du rseau PSTN entrent dans le rseau IMS travers les canaux de SS7/TDM normales. A l'intrieur de lIMS nuage ces appels sont mapps vers le SIP commun et Temps rel protocoles (RTP) qui sont les mcanismes de signalisation sous-jacente et le transport du cur de rseau IMS. La figure 1 montre l'architecture IMS en dtail (avec quelques simplifications):

Figure : LArchitecture IMS

2.2 Le plan mdia Les utilisateurs finaux sont connects l'infrastructure IMS travers le plan mdia en utilisant une certaine forme de l'utilisateur quipement (UE). Cette UE est soit un terminal IMS (comme un combin sans fil 3G, WiFi-enabled PDA, ou une connexion haut dbit), ou plus probablement (au moins pour le proche avenir), un dispositif non-IMS que les interfaces l'infrastructure IMS via une passerelle. Il existe plusieurs types de passerelles dfinies au sein de l'IMS qui fournissent des terminaux non-IMS accs au domaine IMS ou interfonctionnement entre le RTPC et lIMS. Les lments cls du plan mdia IMS sont en outre dfinis ci-dessous. Rapport de la direction - Le Media Resource Fonction processeur est le nud de plan mdia de la ressource multimdia Fonction (MRF), et est responsable de la mise en uvre de toutes les fonctions relatives aux mdias, comme le jeu annonces, des confrences, ou de combiner de multiples flux de mdias dans une session. MGW - passerelles mdias fournissent conversion des flux RTP utiliss dans IMS royaume l'heure Procd de division d'multiplex temporel (TDM) utilis dans le rseau RTC ou rseau commutation de circuit.

BGF - La fonction Border Gateway est la fonction de plan mdia qui offre interfonctionnement entre les rseaux IPv4 et IPv6 et d'autres fonctions de scurit qui protgent le cur IMS. 2.3 Le plan de contrle Le plan de contrle est le domaine fonctionnel au sein de l'IMS qui permet d'offrir la session et le contrle des appels. Il agit comme un courtier de service", la remise vnements d'appels entrants pour les services d'application. Le contrle avion est galement connu comme le plan de signalisation, car c'est la couche o tous de la signalisation est effectue. CSCF - La fonction de contrle de session d'appel (CSCF) est le moteur de routage central et de la politique point d'application pour le rseau, et utilise le protocole SIP pour la commande d'appel. Ainsi que le routage des appels, le CSCF gre l'authentification initiale de l'abonn. Un service d'application qui reoit un message du CSCF sait que l'abonn a t provisionn pour recevoir ce service. Tout ce qu'il a faire est d'excuter les contrles spcifiques aux applications supplmentaires sur l'abonn. Le CSCF est galement clat en trois fonctions spcialises, connues sous le P-CSCF, I-CSCF et S-CSCF. P-CSCF - Le P-CSCF (Proxy) gre toutes les requtes SIP de signalisation vers / partir de fin utilisateur et les transmet, le cas chant. I-CSCF - Le I-CSCF (Interrogating) fournit des services de localisation pour quand un message ou service doit traverser plusieurs domaines IMS. S-CSCF - Le S-CSCF (Serving) achemine la signalisation SIP vers et partir abonns via Serveurs d'applications, selon les informations de profil de service pour chaque abonn qui s'est tenue en le Home Subscriber Server (HSS).

HSS - Le Home Subscriber Server (HSS) est l'une des fonctions les plus importantes dans l'ensemble Spcification IMS. Le HSS est une base de donnes centralise contenant tous les utilisateurs pertinents informations, telles que le lieu de dpart rseau, scurit de l'information, et des informations de profil d'utilisateur (Y compris les services pour lesquels l'utilisateur a souscrit et peut donc participer). Cette base de donnes centralise est important, car il limine le fardeau d'avoir reproduire cette information pour diffrents services et les diffrents types de rseaux d'accs. Par exemple, le mme abonn base de donnes est utilise pour les rseaux sans fil et filaires. Ceci est similaire pour les utilisateurs finaux ayant un Carnet d'adresses pour tous leurs appareils de communication, plutt que d'avoir crer des doublons pour PDA, les tlphones cellulaires, les ordinateurs personnels, les ordinateurs de travail, etc. Le S-CSCF et l'application

Serveurs communiquent avec le HSS en utilisant le protocole DIAMETER, qui est essentiellement une nouvelle Interface RADIUS de gnration. SLF - Le souscripteur Emplacement Fonction (SLF) est une base de donnes des adresses des utilisateurs de cartes de CSSS. Rseaux IMS qui n'ont qu'un seul HSS n'ont pas besoin d'un FSL. BGCF - La fonction de commande de passerelle de sortie (BGCF) est invoque lorsqu'une session doit quitter le domaine IMS et entrer dans le RTPC ou Circuit rseau commut. Les passerelles de signalisation et Media Gateways font partie de cette fonction. SGW - la passerelle de signalisation est fonction de la BGCF, et l'interface avec le plan de signalisation de RTPC, par exemple le rseau SS7. Les interfaces de SGW au cur de rseau IP via des protocoles SIGTRAN. MGCF - la fonction de commande de passerelle de mdia contrler les ressources dans les passerelles multimdias l'aide le protocole H.248 Media Gateway contrle. H.248 est galement connue sous le nom MEGACO. MRFC - Le contrleur de fonction de ressources multimdias est le nud de signalisation de la ressource multimdia Fonction (MRF). Le MRFC dispose d'une interface SIP pour le S-CSCF et met en uvre le H.248 protocole pour contrler le rapport de la direction sur le plan mdiatique. CCR - La ressource et la fonction de contrle d'accs garantit que les appareils sont autoriss utiliser le rseau et si la largeur de bande requise pour la session d'abonn est disponible dans l'accs rseau. BCF - La fonction de contrle des frontires est la fonction de plan de signalisation utilis pour appeler les services CAR, assure la scurit IMS signalisation noyau, et fournit galement l'interfonctionnement entre IPv6 et IPv4 rseaux. 2.4 Le plan d'application Le plan d'application est une caractristique trs importante de l'architecture IMS. Les transporteurs sont en mesure dacqurir un avantage concurrentiel significatif non seulement par ltendue des services quils offrent, mais aussi dans la faon dont rapidement ces services vont surle march. Si les services sont capables d'tre dployes plus rapidement, les transporteurs devraient tre en mesure de bnficient, surtout si tous les nouveaux services sont disponibles l'ensemble des abonns, indpendamment de l'accs Procd. Le plan d'application

IMS vise en faire une ralit. Il y a quelques diffrents types de serveurs d'applications dfinies dans le SGI. SIP-AS- Le SIP est un pur IMS App Server et il est prvu que la plupart, sinon la totalit, nouveau services dvelopps pour IMS seront construits sur ce type de serveur. OSA-SCS et IM-SSF serveurs d'applications - L'OSA et IM-SSF sont dfinis l'interface avec serveurs d'applications existants tels que les serveurs de cadres d'accs aux services ouverts et CAMEL (Applications personnalises pour rseau mobile Enhanced Logic). SCIM - la capacit Interaction Manager Service facilite l'interaction de deux ou plusieurs Capacits travers plusieurs serveurs d'application pour s'assurer que les services interagissent de concert.

3. La promesse d'IMS
3.1 Que ferez-IMS signifie pour les consommateurs? L'IMS est une architecture trs prometteur qui nous l'esprons rationaliser les oprations de rseau des oprateurs et permettre la convergence fixe / mobile, mais quoi d'autre faut-il apporter, en particulier pour les utilisateurs finaux? Aujourd'hui, les consommateurs ont des attentes diffrentes de leurs fournisseurs de communications. Il y a plus de choix pour les services de plusieurs fournisseurs de services que jamais auparavant. Les consommateurs sont moins fidles marques particulires que par le pass, et sont le choix de leurs fournisseurs sur d'autres critres, y compris services disponibles et les plus comptitifs prix. En outre, l'Internet haut dbit connexions ont soulev des consommateurs attentes sur la faon dont multimdia les demandes doivent tre livrs aux utilisateurs finaux, et cette exprience leur a fait prendre attentes quant la faon multimdia devraient tre bnfici de plus de connexions mobiles. IMS vise rendre l'Internet mobile une ralit, fournir aux consommateurs innovante, riche, services multimdia voix de mixage, vido et donnes avec qualit de service appropri Figure 2: les prise de dcideurs de demain devra (QoS). Les consommateurs auront galement plus choix sur comment, quand et o ils communiquer et sera en mesure de profiter itinrance transparente entre les appareils, les rseaux et les transporteurs.

En bref, la gnration de l'iPod" d'aujourd'hui seront en mesure de continuer communiquer de la mme manire qu'ils font aujourd'hui, mais au lieu d'utiliser plusieurs appareils pour des applications distinctes, ils vont utiliser plusieurs dispositifs pour les mmes applications. Quand ils doivent quitter une connexion rseau permanente, comme une maison ordinateur, au lieu de se dconnecter d'une session de messagerie instantane ils sont en plein milieu de la sance sera simplement transfr leur appareil mobile sans sauter un battement.

3.2 Que ferez-IMS moyenne pour les transporteurs?

Idalement, IMS bnficiera transporteurs bien des gards, y compris les oprations simplifies, un service plus rapide mise en uvre, l'augmentation des revenus, et le client rduit le taux de dsabonnement. Les rseaux des oprateurs d'aujourd'hui ont beaucoup de place pour l'optimisation, les services, le contrle des appels, des bases de donnes d'abonns, et les rseaux d'accs sont tous intgrs verticalement. Ces silos verticaux crent des licenciements au sein et les barrires entre une des rseaux du transporteur, et mme leurs organisations. L'effet de ces silos verticaux ont est souvent observe lors de la comparaison des services sans fil aux filaires services. Les mmes services ne sont gnralement pas disponibles (dans la plupart des cas) sur les deux rseaux. Voicemail cases sont spares, les bases de donnes de contact sont spares, et souvent, la facturation est encore spare, mme si les services sont obtenus partir du mme support. IMS aidera abattre ces murs en fournissant communs une logique de service pour tous les mcanismes d'accs. Du point de vue de la porteuse, davantage de ressources sont ncessaires pour grer et exploiter les disparates rseaux, ce qui est extrmement inefficace. Les mmes services doivent tre intgrs dans chacun des diffrents rseaux et le contrle des appels et des bases de donnes d'abonns sont galement reproduites. IMS vise amliorer l'efficacit du rseau de transport, en crant un environnement o une seule instance de commande d'appel et bases de donnes clients est ncessaire, ce qui devrait simplifier les oprations des transporteurs. En outre, comme les services sont indpendants de tout rseau d'accs particulier, les transporteurs devraient tre en mesure de mettre en uvre des services plus rapidement et tous les nouveaux services devraient tre disponibles l'ensemble des abonns quel que soit le ils choisissent d'accder l'infrastructure IMS. 3.3 Une architecture volutive Alors que la spcification IMS reprsente certainement une quantit importante de changement pour les rseaux des oprateurs, en ralit, une grande partie de cette transformation du rseau a t en cours depuis plusieurs annes maintenant. IMS est un l'architecture volutive, pas ncessairement un concept rvolutionnaire. De nombreux transporteurs ont dj modernis leurs rseaux pour tirer parti des technologies IP et Ethernet dans de multiples domaines du rseau, y compris l'accs au dernier mile, le transport, et des parties de commutation du rseau. Il est nombreuses raisons pour lesquelles les transporteurs sont de cette transition, y compris:

la concurrence d'autres transporteurs (compagnies satellites CLEC, cble et) conomies d'exploitation nouvelles opportunits de revenus (services triple-play) "Bord-out ventures CLEC au sein de leurs propres organisations. Ces transporteurs sont en bonne position pour poursuivre l'volution de leurs rseaux de legs TDM architectures l'avenir tous IMS. Cela ne veut pas dire que chaque pice d'quipement sur IP install dans les rseaux des oprateurs au cours des dernires annes est conformes IMS, parce que certainement ils ne sont pas. Certains des vendeurs auront plus de facilit mettre niveau leurs platesformes pour soutenir IMS, tandis que d'autres peuvent avoir simplement recommencer ou introduire de nouvelles plates-formes afin de soutenir IMS. Comme nous le verrons plus tard, le MetaSwitch prochaine gnration architecture de commutateur logiciel fournit un chemin trs lgant vers tout lavenir du IMS.

4. MIGRATION ET UVRE LES DFIS


4.1 Aperu

MISE

EN

Alors que l'IMS offre certainement beaucoup d'enthousiasme pour la prochaine gnration Rseaux IP, il reprsente aussi un dfi trs important. Il faudra plusieurs annes pour une fonctionnalit complte IMS raliser, avec beaucoup de bosses sur la route le long du chemin. En particulier, beaucoup des premiers IMS solutions arrivent sur le march ne rpondent pas efficacement la migration dfis que les entreprises, en particulier les oprateurs filaires, visage la migration de leurs rseaux existants vers une architecture IMS. Le sans-fil infrastructure est gnralement beaucoup plus jeune que la plupart des services filaires infrastructure, et peut donc fournir un chemin de mise niveau lisse pour IMS. Ainsi, alors que beaucoup de l'industrie est trs optimiste quant l'IMS, il y aura beaucoup de travail pour y arriver d'ici. Certains d'entre eux dfis de mise en uvre sont discuts ci-dessous. 4.2 Complexit Comme mentionn prcdemment, la spcification IMS dfinit uniquement les lments fonctionnels. Il ne dicte pas comment les lments fonctionnels doivent tre combines et mises en uvre par les nuds dans le rseau rel. Les vendeurs sont libres de combiner plusieurs lments dans un seul nud, ou au contraire, une entit fonctionnelle pourrait tre scinde en plusieurs nuds. Bien qu'il soit thoriquement possible, il est peu probable que les transporteurs allez vouloir une bote physique diffrent pour chaque bote fonctionnelle de l'IMS, il est donc extrmement important que toute solution IMS minimise la complexit de l'IMS pour la porteuse. MetaSwitch comprend cette complexit. 4.3 Interoprabilit Les transporteurs ne veulent pas que leurs rseaux de production des expriences de laboratoire. Les clients s'attendent un transporteur offrant de travailler, avec toutes les caractristiques d'exploitation comme annonc. Compte tenu de tous les lments fonctionnels qui composent l'IMS, il va de soi que l'interoprabilit du dispositif entre et parmi les fournisseurs solutions seront extrmement importantes et doivent tre une priorit pour la communaut des fournisseurs. MetaSwitch a une solide hritage dans ce domaine, aprs avoir mis au point une quantit importante

de l'interoprabilit des fournisseurs dans de nombreux domaines de la commutation de prochaine gnration, y compris SIP, MGCP, H.248, et une foule d'autres protocoles. 4.4 Les dfis de la migration Un dfi important auquel tous les transporteurs est la migration de leurs rseaux TDM traditionnels vers les rseaux IMS de l'avenir proche. Lorsque l'on considre combien de diffrents lments de rseau constituent un transporteur tailles de rseau, puis l'effort requis pour migrer ces lments de leur capacit actuelle une

infrastructure IMS-capable, cela finit par tre un dfi extrmement important. Figure 3 illustres divers composants dans les rseaux des oprateurs qui

subissent cette transformation. 4.5 Services hrits Mme s'il y a eu une bonne quantit d'accent sur interfonctionnement entre le RTPC ou les rseaux commutation de circuits et l'IMS, il y a encore quelques fonctionnalits et services qui ne sont pas hrits couverts l'intrieur de la spcification IMS. Ces services traditionnels seront toujours doivent tre pris en charge, il est donc trs important que tout IMS solution fournit galement des services traditionnels que les clients seront toujours la demande pour le proche avenir. Un exemple de ceci est multifrquence (MF) troncs. Il n'y a pas de provision pour MF troncs sein IMS. Certains diront que ces troncs MF Figure 4: Services traditionnels ont encore besoin d'tre pris devraient simplement tre migrs vers SS7/SIGTRAN et ISUP, Cependant, ce

serait aussi forcer une migration d'un nombre important dE-911 des appels d'urgence de scurit (PSAP), qui sont actuellement servi par des troncs MF. Une solution qui ne permet pas aux transporteurs de dsengager gracieusement des services traditionnels qu'ils offrent actuellement alors qu'ils mettent en uvre l'architecture IMS met transporteurs dans une position trs difficile. Comme nous le verrons plus loin dans la section suivante, la solution open softswitchs de MetaSwitch a t conu partir de le dpart de soutenir les services traditionnels, mais dispose d'une vritable architecture de la prochaine gnration qui permettra porteurs d'un chemin beaucoup plus facile IMS que la plupart des autres solutions trouves sur le march aujourd'hui.

5. META: Une solution relle pour IMS MIGRATION


5.1 Aperu de META Comme l'IMS est juste une architecture fonctionnelle, il est important de comprendre prcisment comment ces composants fonctionnels seront mises en uvre dans le rseau de tlcommunication relle. En effet, une question qui est frquemment poses sur IMS est "Qu'est-ce que IMS ressemble?" Gardant l'esprit les dfis importants auxquels sont confronts les oprateurs de tlphonie fixe en gracieusement leur migration rseaux l'avenir IMS, et la ncessit d'une solution relle la spcification IMS, MetaSwitch a construit un ensemble de solution base sur Considrant que les normes IMS spcifier un ensemble logique de composants fonctionnels pour les rseaux bass sur IP, META spcifie un mode de ralisation physique spcifique de ces normes. META fournit aux oprateurs filaires avec un chemin de migration en douceur vers IMS, soigneusement architectur pour assurer une mesure transition, tape par tape qui permet aux transporteurs d'voluer leur propre rythme. 5.2 M Multi Media-E nhanced META tire parti de la flexibilit du SIP et l'architecture IMS activer le contenu et des services riches. META propose SIP- interfaces base d'application et le contrle des appels, ainsi que H.248 commande de passerelle de mdia d'aujourd'hui, permettant aux transporteurs de mettre en uvre Services IMS dans leurs rseaux possdent aujourd'hui. Les utilisateurs finaux pourront profiter des nouveaux services multimdias, passionnants disponibles, et les oprateurs peuvent utiliser META pour apporter ces nouvelles fonctionnalits sur le march plus rapide. Plus important encore, la solution META permet aux services et fonctionnalits avances tre livrs l'hritage dispositifs servis par des infrastructures existantes, ainsi qu'aux dispositifs, plus capables rcentes (telles que la 3G tlphones mobiles ou IP), assurant prochaines fonctionnalits vocales de nouvelle gnration sont disponibles pour l'ensemble abonn base et la prservation de la valeur des actifs du rseau existant. 5.3 T Telephony Alors que les fonctions et services avancs sont essentiels la croissance et le maintien de la base d'abonns, la capacit de continuer fournir des services de

tlphonie vocale traditionnelle est tout aussi importante. Cette comprend la fourniture de services communs tels que 3-way appelant, renvoi d'appel, identification de l'appelant, etc., ainsi que moins frquent services tels que l'extension hors site, interphone maison, et autres services sotriques qui sont encore fournis par des services filaires transporteurs. En outre, il est toujours trs important de soutenir les interfaces de support existant afin de combler l'hritage PSTN au cur IMS. Ces interfaces comprennent ISUP et MF troncs, 911, CALEA, formats de facturation, T1 signalisation voie par voie, ISDNPRI, alarmes et autres. META assure transporteurs peuvent continuer soutenir leurs services traditionnels et des interfaces jusqu' ce qu'ils soient prts se dsengager gracieusement du offrant ces services ou ne plus avoir besoin de certaines interfaces hrites. 5.4 Un architecture Conu ds le dpart comme un modle de rseau ouvert, distribu, solutions de commutation logicielle MetaSwitch fournir un chemin de migration en douceur vers l'architecture IMS. Dot d'interfaces bases sur des standards et protocoles, ainsi que le contrle d'appels SIP et une sance de signalisation partout, META est l'industrie la plateforme la plus fiable pour la croissance dans les rseaux pure IMS. Tout aussi important, META est une plate-forme de classe transporteur qui a dj des annes d'interoprabilit prouve avec des centaines d'lments de rseau existants et bass sur IP, des tlphones SIP aux transporteurs boucle large bande Session Border Controller aux serveurs d'applications bases sur SIP. MetaSwitch a aussi des annes de VoIP bass sur une classe dploiements de rseaux 5, ce qui permet des centaines de transporteurs utilisant le MetaSwitch plate-forme de commutation logicielle l'hritage de livraison et les services de tlphonie de nouvelle gnration.

6. lments du rseau META

6.1 Aperu La solution META de MetaSwitch a une corrlation directe avec certains lments fonctionnels dans l'IMS l'architecture. Les sections suivantes dfinissent quels lments d'IMS sont pris en charge par les produits de META dans l' diffrentes couches de l'architecture IMS. IMS Fonctions d'avion d'application META application des lments plans

6.2 META dans le plan d'application Dans le plan de l'application, META permet aux transporteurs d'utiliser plusieurs types de serveurs d'application dans leur IMS rseaux. Le MetaSwitch CA9020 PSTN Feature Server fournit plus de 100 RTPC caractristiques la fois utilisateurs rsidentiels et d'affaires. Cela garantit que les transporteurs commencent mettre en uvre l'IMS architecture, tous les utilisateurs pourront toujours profiter des fonctionnalits et des services auxquels ils sont RTPC traditionnels habitus. LUC9000 systme de communications unifies permet MetaSwitch riches services, multimdia, et est mis en uvre l'aide d'une interface SIP standard dans le noyau IMS. Applications disponibles partir de le systme UC9000 incluent la messagerie unifie, Web Self-Care, Assistant de bureau, standard automatique, et Privacy Defender. MetaSwitch continue se dvelopper de nombreuses nouvelles fonctionnalits amliores pour lUC9000 gamme de produits. En outre, META prend en charge une interface SIP IMS-conforme la norme pour faciliter l'intgration de 3rd partie Serveurs d'applications, dont beaucoup ont dj t intgres avec succs. 6.3 META dans le plan de contrle

IMS contrle Fonctions d'avion

META lments plans de contrle

Dans le plan de contrle, MetaSwitch fournit une technologie cl qui rpond multiple plan de contrle IMS lments. Le MetaSwitch CA9020 agent d'appel combine plusieurs lments IMS, en fournissant l'IMS suivant fonctions: S-CSCF, MGCF, MRFC. Le CA9020 supports SIP, H.248 et SIGTRAN aujourd'hui. Peut-tre tout aussi important, le CA9020 est en mesure d'assurer une mdiation entre les services IMS et les abonns existants qui sont servis sur une infrastructure d'accs hritage, y compris GR-303, PRI, T1, MGCP et autres connexions nonIMS. Cela garantit que mme que les nouveaux services bass sur IMS sont disponible pour les abonns existants. Il permet galement aux oprateurs de migrer vers IMS leur propre rythme. Dans META, la base de donnes d'abonn est mise en uvre dans un Home Subscriber Server, qui communique avec le S-CSCF et serveurs d'applications via le protocole de diamtre. MetaSwitch volue ses solutions d'applications de contrle de session et de cette architecture, en s'appuyant sur le exprience que notre socit mre, connexion de donnes, a dploiement similaire mta-annuaire capacits en tiers one rseaux mondiaux de transport (voir la section 6 .6) . Tout comme les commutateurs logiciels ont volu au fil du temps un modle distribu, avec la commande d'appel indpendante des mdias la manipulation, la premire gnration de contrleurs de session en priphrie est de migrer vers un modle distribu. Llment de signalisation, connu dans META comme proxy de signalisation de bord, met en uvre passerelle frontire, l'application de la politique / le contrle des admissions et proxy / fonctions de contrle de session d'appel d'interrogation. La signalisation bord uvres de sollicitation de procurations en tandem avec le proxy mdias de bord (voir la section 6 .4) pour faire respecter la scurit au sein du rseau. Contrairement certaines

implmentations de commutateurs logiciels qui subsument cette fonction dans la commande (softswitchs) lment d'appel, MetaSwitch estime qu'il doit tre mis en uvre sur un systme externe, pour protger efficacement contre les attaques par dni de service et autres menaces de scurit.

IMS mdias Fonctions d'avion 6.4 META dans le plan mdia

META Mdias lments plans

Dans le plan mdia, META aborde media / passerelle de signalisation et des fonctions de proxy de mdias de pointe. META combine Media Gateway (MG) avec Media Resource Fonction Processor (RDRF) pour des cots, le traitement mdiatique hautement volutive efficace. Ceci est rendu possible par MetaSwitch de leader de l'industrie conception de la passerelle mdia qui combine des processeurs de signal numrique puissant avec passerelle multimdia interfaces sur une seule lame, mise l'chelle jusqu' 112 896 simultane (transcod et annulation d'cho) sances par rack 19 ". La sparation des fonctions de RDRF et MG dans les lments de rseau distincts serait rduire la densit et augmenter les cots grce l'ajout de composants de rseau inutiles. Quand il s'agit de passerelle de signalisation fonctionnalit (SG), META offre une flexibilit sur l'emplacement. Passerelles de signalisation ddis peuvent tre utiles o il y a une forte densit de trafic SS7, mais pour la plupart applications, il sera logique de Co-localiser les interfaces de signalisation l'intrieur du chssis de la passerelle des mdias. META soutient les deux approches, avec le choix en fonction des caractristiques du rseau du transporteur. Comme dcrit ci-dessus, le META bord Proxy mdias travaille dans la conjonction avec l'Edge Signalisation Proxy (dans le plan de contrle) pour renforcer la scurit. META intgre actuellement technologies des partenaires qui offrent cette fonctionnalit dans les dispositifs de contrleur de session en priphrie dvous, mais nous s'attendre ce que dans le long terme, il sera mis en place o il peut tre mis en uvre plus efficacement en le routeur de bord. Les rcentes annonces / acquisitions par des fournisseurs tels que Cisco et Juniper points en cette direction.

Le MetaSwitch 3510 et 2510 chssis peuvent tre configurs comme signalisation ou passerelles mdia, ou les deux combins 6.5 Gestion des lments META Le systme de gestion des lments MetaSwitch (EMS) est un composant cl de la solution de META, comme il fournit une interface de gestion complte et facile utiliser unifi pour tout le rseau META lments, y compris les passerelles de signalisation SG2510/SG3510, MG2510/MG3510 passerelles mdias et l'agent d'appel et CA9020 serveur de fonctions RTPC. Le MetaSwitch EMS fournit un outil facile utiliser l'interface utilisateur graphique (GUI) axe sur le client, ainsi que lInterfaces de provisionn bas sur XML conformes IMS pour une intgration directe au rseau existant systmes de gestion. En outre, alors que les rseaux migrent vers le paradigme de facturation IMS, pour soutenir formats de facturation traditionnels permet aux oprateurs de continuer assurer le recouvrement des recettes sur la base existante systmes. 6.6 Partenariats stratgiques Alors META fournit de nombreux composants fonctionnels ncessaires de l'architecture IMS, il y a quelques domaines qui ne sont pas fournis dans les META. C'est l que les solutions des partenaires importants de MetaSwitch programme entre en jeu. Notre objectif historique et continu sur les partenariats et l'interoprabilit ouverte, y compris la participation des groupes tels que IMS Forum et Forum Multi Service, de nous un leader en ont fait la prestation de travail multi fournisseurs de solutions VoIP, et cette exprience et de se concentrer servira bien nous dplacer l'avant avec les tests IMS. Notre partenaire fort est notre socit mre, connexion de donnes, le premier fournisseur de l'industrie piles de protocoles, rseaux, annuaires, messagerie, et d'autres logiciels pour les OEM et service Prestataires (voir Section 8) . MetaSwitch est en mesure de tirer parti de cette relation en intgrant les

donnes la technologie de connexion, par exemple SIP, H.248, et la messagerie unifie, dans son ensemble du produit. Avec IMS tant un domaine d'investissement majeur pour les quipes de dveloppement connexion de donnes et MetaSwitch, cette relation continuera d'tre une source de force que les nouvelles technologies deviennent disponibles.

7. VAINCRE LES ENJEUX: L'avantage de META


META fournit aux oprateurs un avantage significatif par rapport aux solutions IMS comptitifs. Alors que de nombreux offres concurrentes vantent leurs capacits IMS, ils peinent reconnatre les dfis importants que les transporteurs filaires sont confronts dans la migration de leurs rseaux traditionnels IMS. C'est l META offre sur la promesse d'IMS. META permet aux oprateurs de surmonter la migration dfis mentionns plus tt. Complexit - META est dj une plate-forme prouve sur le terrain, cohrent et largement dploy dans les prochains rseaux de nouvelle gnration pour les services IP-enabled. Il gre la complexit de l'IMS en rduisant dizaines des entits fonctionnelles logique un ensemble grable d'lments de rseau prouves, sans compromettre IMS conformit aux normes ou la flexibilit de dploiement. Interoprabilit - tests d'interoprabilit leader de l'industrie de MetaSwitch garantit des solutions partenaires qui compltent la solution IMS sont galement troitement intgr avec le reste de la solution. les dfis migratoires - META position unique des transporteurs avec la flexibilit ncessaire pour migrer leurs rseaux et des services leur propre rythme, sans les obliger mettre niveau d'autres rgions du rseau pour profiter des avantages des services de prochaine gnration. Dans le mme temps, META est ouvert, positions darchitecture base sur les standards transporteurs pour mettre en uvre la fonctionnalit IMS quand ils sont prts. Hritage services - un fort soutien de META pour les protocoles existants et des interfaces permet aux oprateurs de continuer fournir les services et interfaces ncessaires sur leurs rseaux comme ils migrent vers un Architecture IMS. META permet aux oprateurs de faonner leur propre avenir, sur leur propre calendrier, sans la crainte d'avoir se dsengager de services qui sont encore gnrer des revenus pour eux.

8. PROPOS MetaSwitch
Une division de Data Connexion, MetaSwitch tire parti de l'exprience de 25 annes fourniture de communications technologie et le soutien aux fournisseurs de services de premier plan comme Verizon, SBC et BT, et les grands fournisseurs d'quipements. Notre expertise ingale provient de succs le dveloppement de produits de calibre mondial, y compris le core protocoles (SIP, MGCP, Megaco/H.248, MPLS, routage IP, ...), applications (messagerie unifie, confrence, ...) et de la technologie de commutation de prochaine gnration. Le MetaSwitch classe 4/5 softswitchs est supports faciles dployer et permet d'offrir des services TDM, paquets et fiable sans qualit dans le les rseaux d'accs et l'pine dorsale. En collaboration avec le MetaSwitch UC9000 Unified Communications systme, il offre une gamme complte de services amliors d'abonns, la classe 4/5 les capacits et les larges l'interoprabilit des rseaux IMS. Data Connection est un implacablement rentable et stable priv entreprise, en crant la base pour les investissements long terme et croissance qui garantit notre capacit financer produit en cours investissement et offrir un soutien la clientle de premire classe. MetaSwitch opre partir de plus d'une douzaine de sites travers les tats-Unis y compris ses ventes, du marketing et primaires bureaux de soutien la clientle Alameda (Californie) et Reston(Virginia), dont le sige mondial Londres, Royaume-Uni. Technique de raccordement Rsultats du Pour de plus amples renseignements sur la faon MetaSwitch peut aider le service prestataires migrer avec succs aux rseaux VoIP et IMS bas, visitez www.metaswitch.com.

CONCLUSION
La spcification IP MultiMedia Subsystem prsente le plan le plus complet ce jour pour transporteurs architecturer leurs rseaux de prochaine gnration. Mme s'il y a certainement beaucoup plus de travail pour tre faire dans certains domaines, il est important de raliser que tout IMS est relativement nouveau, il intgre de nombreux les rcentes tlcommunications et les tendances de rseautage, tant d'ides au sein de SGI sont bien tablies. En raison l'lan significatif de l'industrie derrire IMS, de nombreux fournisseurs et les transporteurs alignent leurs produits et des solutions pour soutenir la spcification IMS. Alors il faudra encore plusieurs annes pour que le plein IMS vision devenir ralit, nous commenons dj voir premires implmentations d'lments IMS au sein des prochains rseaux d'oprateurs de nouvelle gnration. MetaSwitch offre une solution IMS leader de l'industrie sous la forme de mtadonnes. En plus d'tre une vritable solution de prochaine gnration qui offre un parcours global pour l'avenir IMS, META intgre les capacits ncessaires pour soutenir les anciens dispositifs et services de tlcommunications qui permettront aux oprateurs de migrer leurs rseaux un rythme qui fonctionne pour eux, pas un rythme qui leur dictait.

Parte II

Rsum
Cet article prsente la conception et la mise en uvre du systme intentionnel de nommage (INS), une dcouverte des ressources et du systme de localisation de service pour les rseaux dynamiques et mobiles des appareils et ordinateurs. Ces environnements ncessitent un systme de nommage qui est expressive, de dcrire et de faire des requtes bases sur les proprits spcifiques de services, adapts pour suivre les changements dus la mobilit et la performance, robuste, grer les checs, et facilement configurable. INS utilise un langage simple, bas sur les attributs et les valeurs de ses noms. Les applications utilisent le langage pour dcrire ce qu'ils recherchent (par exemple, leur intention), pas o trouver les choses (ie, pas les noms d'htes). INS met en uvre un mcanisme de liaison tardive qui intgre la rsolution de noms et le routage des messages, permettant aux clients de continuer communiquer avec nuds terminaux, mme si le nom d'aborder mappages changer alors qu'une session est en cours. Rsolveurs de l'INS auto configurer pour former un rseau de recouvrement au niveau des applications, qu'elles utilisent pour dcouvrir de nouveaux services, d'effectuer la liaison tardive, et de maintenir la cohrence faible des noms en utilisant le nom soft state changes et de mises jour. Nous analysons la performance des algorithmes et protocoles INS, les mesures actuelles d'une mise en uvre base sur Java, et dcrire trois applications que nous avons mis en place qui dmontrent la faisabilit et l'utilit de l'INS.

1 Introduction
Environnements de rseau du futur seront caractriss par une varit de dispositifs mobiles et sans fil en plus des ordinateurs usage gnral. Ces environnements affichent un degr de dynamisme ne voit pas ordinairement dans les rseaux filaires traditionnels en raison de la mobilit des nuds et des services ainsi que les fluctuations rapides de la performance. Il n'est gnralement pas le soutien pr configur pour dcrire, localiser et d'accder aux services disponibles sur ces rseaux htrognes mobiles. Alors que le problme de routage dans les rseaux mobiles paquet a t largement tudi, les fonctions importantes de l'exploration des ressources et de l'emplacement de service sont seulement rcemment commences recevoir des soins dans la communaut de la recherche. Nous croyons que c'est un problme important rsoudre car les cots de dploiement et la gestion d'une telle infrastructure de rseau est domin par des logiciels et la gestion des services, tout en diminuant les cots de matriel font quil nest pas cher mettre en rseau toutes sortes dappareils. Exemples d'applications dans des environnements comprennent l'envoi d'un emploi la plus proche (en fonction de la localisation gographique) et d'une imprimante moins charg, rcuprer des fichiers partir d'un mobile, serveur rpliqu bas sur les performances du rseau et de la charge du serveur, et la rcupration de l'image actuelle de toutes les camras mobiles dans une section particulire d'un btiment. Sur la base de mon environnement cible et applications, on identifie les objectifs de conception importants suivants pour un systme de nommage qui permet la dcouverte dynamique des ressources et de l'emplacement de service :

Expressivit. Le systme de nommage doit tre souple afin de traiter une grande varit de dispositifs et de services. Il doit permettre aux applications d'exprimer arbitraire des descriptions de service et des requtes.

Ractivit. Le systme de nommage doit s'adapter rapidement pour mettre fin nud et la mobilit des services, les fluctuations de performance, et d'autres facteurs qui peuvent entraner un changement dans le meilleur emplacement rseau d'un service.

Robustesse. Le systme de nommage doit tre souple pour ne citer dfaillances du rsolveur et d'un service ainsi que les incohrences dans l'tat interne des rsolveurs.

Configuration facile. Les rsolveurs de noms devraient se configurer avec un minimum d'intervention manuelle et le systme ne devrait pas exiger l'inscription manuelle des services. Le systme qui en rsulte devrait distribuer automatiquement une demande de charge de la rsolution parmi les rsolveurs.

La principale contribution de mon travail est la conception et la mise en uvre de lINS, un systme de nommage intentionnelle qui rpond aux objectifs ci-dessus. Parce que les applications dans notre environnement (comme dans beaucoup denvironnements distribus) ne savent souvent pas le meilleur emplacement rseau qui rpond leurs besoins d'information ou fonctionnalit, nous soutenons en faveur d'un schma de nommage intentionnel et l'architecture de rsolution dans lequel les applications dcrivent ce qu'ils recherchent, pas par o trouver. Rsolveurs de noms dans l'itinraire rseau demandes aux endroits appropris en maintenant une correspondance entre les descriptions de services et leurs emplacements rseau. INS ralise expressivit en utilisant un langage de nom intentionnel fond sur une hirarchie dattributs et de valeurs, ce qui permet nuds qui fournissent un service de dcrire prcisment ce qu'ils fournissent et les consommateurs pour dcrire facilement ce dont ils ont besoin. Noms bases sur les attributs et les valeurs ont t proposes auparavant dans d'autres contextes [5, 7, 13, 45] et nous nous appuyons sur les travaux antrieurs dans ce domaine dans la conception de notre langue de nommage. Alors que plusieurs langages de requtes complexes bass sur des attributs et de valeurs existent dans la littrature, la ntre est particulirement simple et dispose d'un petit ensemble d'oprateurs couramment utiliss, ce qui le rend lger et facile mettre en uvre, mme sur des priphriques pauvres. Nous concevons galement l'architecture de la rsolution de l'INS pour tre indpendante du langage spcifique utilis pour excuter des requtes, de sorte qu'il peut galement tre utilis dans le contexte d'autres langages de description de service. Une caractristique importante de notre environnement cible est la mobilit, o l'emplacement rseau (adresse IP) d'un changement de nuds finaux. Mobilit du nud peut se produire en raison de la mobilit physique ou lorsqu'un nud change le rseau utilis pour communiquer (par exemple, le passage dune connexion Ethernet cble un rseau frquence radio). Une autre forme de mobilit la mobilit des services, o les adresses rseau d'un service ne change pas, mais la cartographie nuds d'extrmit un changement de service en raison d'un changement dans les valeurs des attributs recherchs par les clients. En outre, notre environnement est dynamique en raison des fluctuations de performance que la charge sur les nuds de service et des sentiers dans les modifications du rseau, il en va de l'emplacement du meilleur nud pour servir chaque demande de client. Par consquent, INS devraient reflter les changements de performance dans les rsultats de la rsolution de nom. En INS, les clients utilisent un nom intentionnel pour demander un service sans numrer explicitement le nud d'extrmit (s) qui

servent en fin de compte la demande. Ce " niveau d'indirection " fournie par un nom intentionnel permet aux applications de continuer de faon transparente la communication avec les nuds dextrmit, mme si le mapping de nom la fin adresses de nuds peut changer au cours de la session, transparent pour le client.

Ainsi, INS supporte les applications mobiles, qui utilisent des noms intentionnels plutt que des adresses IP. INS ralise ractivit en intgrant la rsolution de noms et le routage des messages , les oprations qui ont traditionnellement t spare dans les architectures de rseau . Applications de l'INS bnficient de cette abstraction en utilisant une option de liaison tardive, o la liaison entre le nom et l'emplacement intentionnel de rseau ( s) est faite au moment de la remise du message plutt que sur demande du temps de rsolution . Cette liaison est au mieux depuis INS ne donne aucune garantie sur la livraison fiable des messages. Ainsi, INS utilise un nom intentionnel non seulement localiser les services, mais aussi pour router les messages vers les points d'extrmit appropries. Cette intgration conduit une mthode gnrale pour effectuer le routage au niveau des applications utilisant des noms, effectues par les applications, y compris des donnes avec la requte de rsolution de nom. Notre routage intgr et un systme de rsolution prvoit deux types de service de livraison de message en utilisant la liaison tardive. Une application peut demander qu'un message soit livr au nud de service "optimal" qui rpond un nom intentionnel donn, appel unicast intentionnel. Ici, la mtrique pour optimalit est l'application contrle et reflte une proprit du nud de services tels que la charge actuelle. Un deuxime type de livraison de message, multicast intentionnel, est utilis pour transmettre des donnes tous les nuds de service qui rpondent un nom donn, par exemple, le groupe de capteurs qui ont tous enregistr sous zro temprature. Ces deux services de livraison permettent INS pour atteindre anycast niveau de l'application et de multidiffusion. En accord avec le principe de bout en bout [37], nous quittons la couche rseau sous-jacente adressage et le routage de l'architecture IP inchange. Au contraire, notre approche de prestation de ces services est de couche comme un rseau superpos sur IP unicast. Le seul service de couche rseau que nous comptons sur IP unicast est, qui devient rapidement omniprsente dans environments1 mobiles et sans fil. Une autre raison de quitter le noyau infrastructure non modifi, c'est que souvent, un service de couche rseau ne correspond pas parfaitement aux exigences de la demande porte de main. En effet, l'excution anycast sur un critre de la couche rseau spcifique comme hop-count, la latence du rseau ou de la largeur de bande disponible, est inefficace du point de vue de nombreuses applications car elle n'optimise pas la mtrique prcise que les applications ncessitent. Par exemple,

une couche rseau tout cast [31] pour trouver le "meilleur" imprimante sur un tage d'un immeuble ne peut pas localiser les imprimantes les moins chargs. Pour y remdier, INS permet anycast intentionnelle base sur des mtriques applications contrles, o rsolveurs choisissent le moins de valeur selon une mtrique qui est significatif pour la publicit et par les applications.

Malgr permettant mtriques de routage application contrle, INS prsente un modle de service simple et bien dfini pour anycast intentionnelle et multicast. Contrairement lactif Larchitecture des rseaux [41, 46] et leur homologue de nommage, Active Name [43], o le code et services arbitraires peuvent tre injects dans le chemin de donnes pour personnaliser les fonctions d'un routeur IP ou le nom rsolveur, rsolveurs de l'INS ne courent pas de code arbitraire ni intgrer toute smantique spcifiques l'application dans l'architecture de routage et rsolution. Au lieu de cela, notre systme repose sur des noms structurs pour exprimer les paramtres de l'application. Cette dcision de quitter non modifie unicast IP est bas sur les difficults rencontres dans le dploiement d'autres postes IP, par exemple, la multidiffusion IP [12], les services garantis [10], et plus rcemment, les rseaux IP actives [46]. En ce sens, on peut considrer l'architecture de l'INS comme semblable en philosophie niveau de l'application [3] et le serveur Web unicast slection, qui ont rcemment gagn en popularit. INS utilise un rseau dcentralis de rsolveurs de dcouvrir les noms et messages ditinraire. Pour faciliter la configuration, rsolveurs de l'INS auto-configur dans un rseau de recouvrement au niveau des applications et les clients peuvent joindre l'un d'eux pour rsoudre leurs demandes et annoncer des services. Ces rsolveurs utilisent soft state [9] annonces priodiques de services dcouvrir Les noms et supprimer les entres qui n'ont pas t rafrachis par les services, liminant la ncessit de radier explicitement un service. Cette conception gre gracieusement checs de nuds d'extrmit et de services. Ils mettent galement en uvre l'quilibrage de charge et de charger algorithmes rejet, ce qui leur permet de bien l'chelle de plusieurs milliers de services. L'architecture de la rsolution de l'INS prsentes dans ce document fait trois contributions principales : ( i) il intgre rsolution et de routage , ce qui permet aux applications de grer de faon transparente nud et la mobilit des services et assure la communication du groupe flexible en utilisant un nom intentionnel que la poigne de groupe , (ii) son rsolveurs auto configurer dans un rseau de recouvrement et des algorithmes d'quilibrage de charge des entreprises de bien performer , et il maintient la cohrence faible parmi les rsolveurs rpliques en utilisant des changes de messages doux tatiques. Ces caractristiques le distinguent des autres propositions de dcouverte de service effectues dans le pass rcent , y compris l'IETF (Service Location Protocol SLP ) [ 44, 33] , Jini

dcouverte de service de Sun [21] , le Simple Service Discovery Protocol [19] , Universal Plug and jouer [42] , et le service de dcouverte de service de Berkeley [11] . Une caractristique importante de notre architecture est son potentiel de dploiement progressif et facile l'Internet, sans modifier ou supplanter le modle d'accs Internet existant. INS est destin aux rseaux dynamiques de l'ordre de quelques centaines quelques milliers de nuds, dont beaucoup pourraient tre mobile (par exemple, l'intrieur d'un seul domaine administratif, btiment, bureau

ou rseau domestique). Nous notons, toutefois, que l'architecture prsente dans cet article n'est pas directement applicable dans lInternet large zone. Nous sommes en train de dvelopper une architecture de rseau tendu pour complter cette architecture de l'INS de domaine intra. Cependant, malgr cette mise en garde, nos rsultats montrent que les performances de nos algorithmes de rsolution et les stratgies d'quilibrage de charge permettent un rseau de rsolveurs de l'INS l'chelle de plusieurs milliers de noms et de services. Nos rsultats exprimentaux montrent que le temps de dcouvrir de nouveaux noms int de l'ordre de quelques dizaines de millisecondes. Nous constatons que le temps de traiter les mises jour du nom est le goulot d'tranglement des performances dans de nombreux cas, et nous dcrivons une technique de partitionner l'espace de noms parmi les rsolveurs attnuer ce problme. Pour dmontrer l'utilit de l'INS , nous dcrivons son interface de programmation et la mise en uvre de trois applications : Plan d'tage , un outil de dcouverte de service bas sur la carte pour les services de localisation charge, appareil photo, une camra rseau mobile pour la surveillance distance et une imprimante , un utilitaire d'impression d'quilibrage de charge qui envoie des demandes d'impression de l'utilisateur de la meilleure imprimante en fonction des proprits telles que l'emplacement physique et la charge. Ces applications utilisent l'API de l'INS et de soutien la mobilit, la communication de groupe et l'emplacement du service, obtenir ces avantages sans aucun autre support prinstall (par exemple, Mobile IP [32], la multidiffusion IP [12], SLP [44], etc.) pour ces caractristiques. Le reste de ce Mmoire est organis comme suit. Nous dcrivons l'architecture de lINS dans la section 2, l'API et des applications la section 3, notre mise en uvre dans la Section 4, sa performance dans la section 5, les travaux connexes dans la section 6, et nos conclusions la section 7.

2 Architecture du systme
Applications de l'INS peut s'agir de services ou de clients : services offrent des fonctionnalits ou des donnes et la demande des clients et d'accder ces derniers. Rsolveurs Nom intentionnelles (INRS) acheminer les demandes des clients vers les services appropris, la mise en uvre des algorithmes et des protocoles qui peuvent tre mises en uvre mme sur des appareils de calcul appauvris simples. Tout appareil ou d'un ordinateur dans un rseau ad hoc peuvent potentiellement agir comme un rsolveur, et un rseau de cooprant rsolveurs propose un service de dcouverte de ressources l'ensemble du systme. DNP forment un rseau de recouvrement au niveau de l'application d'changer des descriptions de service et de construire un cache local sur la base de ces publicits. Chaque service fixe un INR et annonce une valeur description de service base sur des attributs et un contrle application mtrique. Chaque client communique avec un INR et demande un service en utilisant une expression de requte. Parce que des descriptions de service sont diffuses par le rseau de l'INR dans les meilleurs dlais, un nouveau service est connu pour les autres rsolveurs et travers eux aux clients. Quand un message arrive un INR, il est rsolu sur la base du nom de la destination. LINR prend une dcision de rsolution / de transfert, selon le service spcifique demand par l'application cliente. Si l'application a choisi la liaison anticipe (slectionn en utilisant l'indicateur prcoce obligatoire dans la demande), lINR retourne une liste d'adresses IP correspondant au nom. Ceci est similaire l'interface fournie par le [27] la plupart des autres systmes de dtection de services existants et de systme de noms de domaine Internet (DNS), et est utile lorsque les services sont relativement statiques. Quand il y a plusieurs adresses IP correspondant un nom, le client peut slectionner un nud d'extrmit avec le moins mtrique, qui est disponible partir du rsultat de la demande de rsolution. Cette rsolution mtrique base est plus riche que la rsolution DNS round robin. Applications de l'INS utiliser les deux options de reliure fin unicast intentionnelle et Multicast intentionnels grer les situations les plus dynamiques. Ici, les adresses rseau ne sont pas retournes au client, mais la place, l'INR avant le nom et la charge utile d'application associ directement aux nuds d'extrmit (par exemple, services). Si l'application des demandes de toute diffusion intentionnelle, les tunnels INR le message exactement un de la fin, les nuds de la liste qui a le moins mtrique. En INS, cette mesure ne reflte pas une couche rseau mtrique

comme hop-count utilis dans la couche rseau anycast [31], mais plutt INS permet aux applications de la publicit paramtres numriques spcifiques aux applications arbitraires tels que la charge moyenne . En multicast intentionnel, l'INR avant chaque message tous INRS hop prochaines associs au nom de la

destination. Le message est transmis le long de la superposition INR tous les nuds de destination finale qui correspondent au nom. INR auto configur dans un spanning tee superposition topologie du rseau, l'optimisation du dlai moyen entre la voix INR ennuyeux. Dans la construction de cette topologie overlay, nous utilisons des mesures dINR temps daller-retour. Le spanning tee est utilis pour diffuser des descriptions de service ainsi que les abonnements de rception. Contrairement d'autres rseaux de recouvrement qui entretiennent, voisins statiques prdfinis tels que la Figure 1. L'architecture du systme de nommage intentionnelle. Le coin suprieur gauche montre une application utilisant la liaison anticipe : l'application envoie un nom intentionnelle un INR doit tre rsolu (1), reoit l'emplacement rseau (2), et envoie les donnes directement l'application de destination (3). Le milieu gauche montre une application utilisant anycast intentionnel l'application envoie un nom intentionnel et les donnes un INR (4), qui tunnels exactement une des destinations qui a le moins mtrique (5). Le coin infrieur gauche montre une application utilisant la multidiffusion intentionnelle : l'application envoie un nom intentionnel et les donnes un INR, qui les transmet via le rseau INR toutes les applications de destination. Le coin infrieur droit montre une application annonant les noms intentionnels un INR. Les noms intentionnels commencent se propager travers le rseau INR. Une demande dcouvrir noms envoie une requte un INR (6), reoit un ensemble de noms qui correspondent au nom de la requte.

MBone [14] ou le 6Bone [17], l'INRS peut tre dclenche ou rsilis et ajustent automatiquement leurs relations de voisinage en fonction des conditions du rseau. Ils mettent galement en uvre des algorithmes d'quilibrage de charge pour un meilleur rendement, par frai nouveaux rsolveurs sur d'autres nuds lorsque le taux de requte entrante est lev et dlguer des portions de l'espace de noms aux instances nouvellement pondus. La figure 1 rsume l'architecture de lINS, illustrant la faon dont les applications interagissent et lINRS.

2.1 Nom prescripteurs INS met en uvre noms intentionnels en utilisant des expressions appel Name prescripteurs. Les clients utilisent le nom des prescripteurs dans leurs en-ttes de

message pour identifier les destinations souhaites (et les sources) de messages. Nom prescripteurs sont conus pour tre simples et faciles mettre en uvre. Les deux principales parties du nom prescripteur sont l'attribut et la valeur. Un attribut est une catgorie dans laquelle un objet peut tre class, par exemple son. Couleur Une valeur est la classification de l'objet l'intrieur de cette catgorie, par exemple, rouges. Attributs et les valeurs sont Strings2 de forme libre qui sont dfinis par les applications ; nom prescripteurs ne limitent pas les applications l'aide d'un ensemble fixe d'attributs et de valeurs. Ensemble, un attribut et sa valeur associe forment une paire attribut-valeur ou un pair av.

Un spcificateur de nom est une classification hirarchique des paires AV tels que l'AV- paire qui dpend d'un autre est un descendant de celui-ci. Par exemple, dans le nom exemple prescripteur montre la figure 2, un btiment appel Samsung n'a de sens que dans le contexte de la ville de Dakar, de sorte que le pair av dpend des paires Av. paire av qui sont orthogonales l'autre, mais dpend sur le mme pair av, sont frres et surs dans l'arbre. Par exemple, le type et la rsolution de donnes d'un appareil photo numrique peuvent tre slectionns indpendamment l'un de l'autre, et ne sont significatives que dans le cadre du service de l'appareil. Par consquent, les paires AV et sont orthogonales. Cet arrangement hirarchique rtrcit l'espace de recherche lors de la rsolution de nom, et rend plus facile comprendre nom prescripteurs. Une alternative plus simple aurait t de construire une hirarchie d'attributs, plutt que l'une des pairs av. Cela entranerait dpendant directement, plutt que cependant, il est aussi moins souple ; notre hirarchie actuelle permet attributs de l'enfant de varier en fonction de leur valeur de parent. Par exemple, a un enfant qui est tout, a un enfant qui est. Nom prescripteurs avoir une reprsentation (figure 3) qui est utilis quand ils sont inclus dans un message -tte pour dcrire la source et la destination du message. Cette reprsentation base sur des cordes a t choisi pour tre lisible pour aider la mise au point, dans l'esprit des autres protocoles bass sur une chane comme HTTP [16] et NNTP [22]. Niveaux d'imbrication sont signals par l'utilisation de supports (et) et les attributs et les valeurs sont spares par un signe () gaux. L'utilisation arbitraire d'espaces est autorise n'importe o dans le nom prescripteur, sauf en milieu dattribut et les jetons de valeur. Figure 2. Une vue graphique d'un nom par exemple prescripteur. Les cercles vides sont utiliss pour identifier les attributs, les cercles remplis de reprer les valeurs. L'arbre est agenc de telle sorte que les attributs dpendants sont les descendants et

les attributs orthogonaux sont frres et surs. Ce spcificateur de nom dcrit un appareil d'accs public dans le bureau ovale.

Figure 3. La reprsentation des fils du nom prescripteur exemple montre la figure 2, avec des sauts de ligne et d'espacement supplmentaire ajout pour amliorer la lisibilit.

En plus des matchs exacts, les nom-prescripteurs permettent galement wild-card correspondant de valeurs. Pour ce faire, la valeur est simplement remplac par le jeton joker (). Ainsi, pour construire un spcificateur de nom qui fait rfrence toutes les camras publiques fournissant 640x480 photos dans l'aile ouest du Samsung btiment, et pas seulement celui dans le Bureau ovale, une application remplace la valeur ' au nom prescripteur reprsent dans les figures 2 et 3. Nous sommes en train d'incorporer les oprateurs d'ingalit (, et) fournir des oprations de slection de gamme en nom - prescripteurs, afin d'augmenter les rsultats dcrits ci-dessus.

2.2 Noms dcouverte Services annoncent priodiquement leurs noms intentionnels au systme de dcrire ce qu'ils fournissent. Chaque INR l'coute de ces annonces priodiques sur un port bien connu pour dcouvrir les services fonctionnant diffrents nuds dextrmit. DNP rpliquent et forment un rseau de recouvrement entre eux, sur laquelle ils envoient les mises jour de noms valides dans le systme. Le protocole de dcouverte de nom traite les informations relatives au nom de l'tat souple [9, 35], associ une dure de vie. Cet tat est maintenu en vie ou rafrachi chaque fois nouvelle information soit disponible et vient est ignor lorsque aucune annonce rafrachissement est reu dans une vie. Les changements rapides dus la mobilit de nud se propagent rapidement dans le systme et de nouvelles informations remplacent automatiquement les anciens, obsoltes informations les informations obtenues en utilisant les annonces de service et des mises jour de l'INR pour les rsoudre. En plus de l'envoi des demandes de rglement, les clients peuvent dcouvrir des types particuliers de noms ou tous les noms connus dans le systme en envoyant un message de dcouverte de nom pour un INR, en prcisant un nom intentionnel de l'INR pour correspondre avec tous les noms qu'il connat. Ce mcanisme est utile pour les clients de bootstrap dans un nouvel environnement. INR diffuser des informations de nom entre eux en utilisant un protocole de routage qui inclut les mises jour priodiques et des mises jour dclenches leurs INRS

voisins. Chaque mise jour contient les informations suivantes sur un nom prescripteur :

Les adresses IP pour ce nom-prescripteur et un ensemble de paires pour chaque adresse IP. Le numro de port et de transport type (par exemple, HTTP [2], RTP [38], TCP [34], etc.) sont retourns au client pour lui permettre de mettre en uvre une liaison anticipe.

Une demande mtrique annonce pour intentionnelle toute fonte et la liaison anticipe qui reflte toute proprit que le service veut anycast routage sur, tels que le courant ou de la charge moyenne.

LINR Next- hop et la mtrique, actuellement l'INR INR latence d'allerretour dans le rseau de recouvrement de litinraire, utilis pour la multidiffusion intentionnel.

Un identifiant unique pour le speaker du nom appel le Annonceur ID, utilis pour diffrencier les noms identiques qui proviennent de deux applications diffrentes sur le mme nud.

INR utilisent des mises jour priodiques pour actualiser les entres de quart INR ennuyeux et d'inonder de manire fiable noms. Mises jour dclenches se produisent quand un INR reoit une mise jour d'un de ses voisins Bors (soit un INR ou d'un client ou d'un service) qui contient de nouvelles informations (par exemple, un nouvellement dcouvert nom - prescripteur) ou de l'information qui est diffrente de celle prcdemment connue (par exemple, une meilleure mtrique) Applications ncessitant 3.for multicast intentionnel, l'INRS en avant le nom et le message de la charge utile travers le rseau ddi l'ensemble des emplacements rseau qui annoncent un nom donn. Dans notre implmentation actuelle, l'INRS utilisent l' distribu algorithme de Bellman- Ford [1] pour calculer les arbres de plus court chemin ces nuds d'extrmit annonant le nom. Contrairement aux protocoles de routage traditionnels qui utilisent l'algorithme [26], l'architecture de lINS permet plusieurs noms identiques d'exister dans le systme. LAnnonceur ID unique assure que les routes des noms identiques peuvent tre diffrencies. Dans notre implmentation, applications gnrent un Annonceur ID par

concatnation de leur adresse IP avec leur temps de dmarrage, ce qui permet plusieurs instances de fonctionner sur le mme nud. 2.3 recherche de nom et de l'extraction L'activit centrale de lINR est de rsoudre le nom - prescripteurs leurs emplacements de rseau correspondants. Quand un message arrive un INR, lINR effectue une recherche sur le nom de destination - prescripteur en son nom-tree. La recherche renvoie un nom-enregistrement, qui inclut les adresses IP des destinations annonant le nom ainsi que d'un ensemble de routes INRS Next-

hop. Le processus de liaison en retard pour anycast et multicast ne change pas le nom - prescripteurs ou des donnes de quelque faon. En intgrant la rsolution de routage dans le processus de liaison en retard, INS permet une communication sans faille entre les clients et les services, mme si le nom demplacement des changements de cartographie au cours de la session. Le reste de cette section dcrit comment les noms sont stocks un INR, les recherches sont effectues sur un nom nouveau, et comment les noms sont extraits des mises jour priodiques ou dclenche dans le protocole de dcouverte de nom. 2.3.1 Nom des arbres Nom arbres sont une structure de donnes utilise pour stocker la correspondance entre le nom - prescripteurs et nom-records. Les informations que le Nom- dossiers contiennent sont les routes l'INRS Next-hop, les adresses IP des destinations finales possibles, la mtrique pour les itinraires, les mesures de fin de nud pour anycast intentionnel, et la date d'expiration du nom-enregistrement. La structure d'un arbre de noms ressemble beaucoup un nom-prescripteur. Comme un nom - prescripteur, il se compose de niveaux dattributs et de valeurs alternatif, mais contrairement un Nom-spcifier il peut y avoir plusieurs valeurs par attribut, puisque le nom - arbre est une superposition de tous les noms prescripteurs de l'INR connat. Chacun de ces nom-prescripteurs a un pointeur de chacun de ses feuilles valeurs un nom - enregistrement. La figure 4 illustre un exemple de nom - arbre, avec l'exemple de la figure 2 Nom-spcifier en gras. 2.3.2 Nom de recherche L'algorithme de recherche- NOM, illustr la figure 5, est utilis pour rcuprer le nom-records pour un nom - prescripteur particulier de larbre de noms ? L'ide principale derrire l'algorithme est qu'une srie d'appels rcursifs rduire le candidat

Nom record tabli par l'intersection avec l'ensemble nom - dossier comprenant les documents points par chaque feuille value node . Lorsque l'algorithme se termine, contient uniquement le nom - documents pertinents. L'algorithme commence par l'initialisation de l'ensemble des noms - dossiers possibles. Ensuite, pour chaque paire de av- la nom-spcifier, il trouve l'attribut nud correspondant dans le Figure 4. Une vue graphique partielle d'un exemple INR nom-tree. Le nom-arbre est constitu de couches d'attributs-nuds, qui contiennent des attributs orthogonaux, alternant et la valeur des nuds, qui contiennent des valeurs possibles.

Valeur nuds contiennent aussi des pointeurs vers tous les nom-records ils correspondent. La partie de l'arbre de noms correspondant l'exemple de nomprescripteur montre la figure 2 est en gras. Arbre de noms. Si la valeur du pair av est un joker, puis il calcule que l'union de tous les noms-dossiers dans le sous arbre enracin l'attribut-nud correspondant, et croise s. Si non, il trouve la valeur-nud correspondant au nom-tree. Si elle atteint une feuille soit le nom-prescripteur ou le nom d'arbre, l'algorithme croise les enregistrements de noms au niveau du nud de valeur correspondante. Sinon, il fait un appel rcursif pour calculer l'ensemble pertinent de l'arbre enracin la valeurnud correspondant, et croise avec qui. Cet algorithme utilise l'hypothse que les attributs omis correspondent aux jokers, ce qui est vrai pour les requtes et les publicits. Une belle proprit de l'algorithme est qu'il excute en une seule passe sans retour en arrire. Cela signifie galement que les jokers doivent tre utiliss que sur les valeurs des feuilles (les AV-paires aprs une wild-card va tre ignore). Section 5.1 analyse de cet algorithme et discute les rsultats exprimentaux de notre mise en uvre. Figure 5. L'algorithme de recherche-NAME. Cet algorithme recherche le nom spcificateur-N dans le nom d'arbre? Et renvoie tous les enregistrements de noms appropris. 2.3.3 Extraction de nom Pour envoyer des mises jour dINR voisins, un INR doit obtenir le nomprescripteurs de son nom d'arbre de transmission. Puisque le nom d'arbre est une superposition de tous le nom-prescripteurs de l'INR connat, extraction d'un seul nom-prescripteur est triviale.

L'algorithme GET-NOM, illustr la figure 6, est utilis pour rcuprer le nomprescripteurs pour une nom-record particulier? de l'arbre de noms? L'ide principale derrire l'algorithme est que le nom-prescripteur peut tre reconstruit tout en retraant le haut de la racine de l'arbre de noms du parent du nomenregistrement, et le greffage sur des parties du nom prescripteur qui ont dj t reconstruits. Tous les prix sont des nuds dans le nom d'arbre, Sont augmentes par une variable "PTR", qui est un pointeur vers l'av-paire correspondant au nom-spcificateur tant extrait. Initialement, tous les REE ont t fixs, car ils n'ont pas av paires correspondantes; (. PTR) le pointeur de la racine est dfini pour pointer vers un nouveau nom vide-prescripteur. Ensuite, pour chaque valeur du parent de l'algorithme trace vers le haut par le nom d'arbre. Si elle devient une partie de

Larbre de noms o il y a un pair av correspondante (". PTR! = Null), et il a un nom-prescripteur sous-arbre greffer sur (#! = Null), il le fait. Sinon, il cre la partie correspondante du nom-prescripteur, fixe ". PTR elle, greffons sur le cas chant, et poursuit la trace avec la valeur du parent Nombre d'" et le nouveau sousarbre. Figure 7 illustre un dans l'excution des progrs de l'algorithme. Figure 6. L'algorithme GET- NAME. Ces extraits de l'algorithme et renvoie le nom - prescripteur le nom-record au nom darbre. TRACE met en uvre la plupart des fonctionnalits, de traage partir d'une valeur de feuille jusqu' ce qu'il puisse greffer sur le nom spcificateur existant. 2.4 Rseau du rsolveur Pour propager les mises jour et les donnes s'attendre des services et des clients, l'INRS doivent tre organiss comme un rseau connect. Dans notre conception actuelle, ce rseau de recouvrement au niveau des applications est construit d'une manire distribue par l'INRS auto- configuration pour former un arbre couvrant en fonction des mesures qui refltent INR latence aller-retour. Les expriences menes par l'INRS pour obtenir cette mtrique sont appels INR - pings, qui consistent envoyer un petit nom entre INRS et mesurer le temps qu'il faut pour traiter ce message et obtenir une rponse. Une liste de INR actifs et candidats est maintenu par une entit bien connue dans le systme, appel le rsolveur d'espace de domaine (DSR). Le DSR peut tre considr comme une extension un serveur DNS pour le domaine administratif dans lequel nous sommes actuellement, et peut tre reproduit pour la tolrance aux pannes. Fumoirs en charge les requtes pour retourner l'INRS actuellement actives et candidat dans un domaine.

Quand un nouveau INR arrive, il contacte le DSR pour obtenir une liste de INRs actuellement actives. Le nouveau INR effectue ensuite un ensemble de INR - pings l'INRS actuellement actives et prend lun avec la valeur minimale pour tablir une relation de voisinage (ou pairs) avec. Si chaque INR fait cela, la topologie qui en rsulte est un arbre couvrant. Parce que la liste des INRs actifs sont maintenu par la DSR, et tous les autres INRs obtenir la mme liste, les conditions de course sont vites et on peut imposer un ordre linaire entre l'INRS actifs bass sur l'ordre dans lequel ils sont devenus actifs dans le rseau de recouvrement. Chaque INR sur la liste active, sauf le premier, prsente au moins un voisin en avant de celui-ci dans l'ordre linaire, et le diagramme obtenu est clairement reli par construction. En outre, chaque fois qu'un nud arrive aprs la premire, il scrute avec exactement un Figure 7. Une illustration d'une excution en cours de l'algorithme GET- NAME. Le nom - prescripteur en cours de cration est reprsent en gris sur la gauche,

tandis que l'arbre de nom, il est cr partir s'affiche en noir sur la droite. Les parties de larbre de noms qui sont encercles par des lignes pointilles sont les chemins travers larbre de noms qui ont t traces. Les flches en pointills sont utilises pour illustrer les affectations des variables PTR. Les flches paisses indiquent les parties des structures de donnes qui sont actuellement manipuls. Dans cet exemple, le fragment de spcification de nom enracin au n est greff sur Tx PTR, qui est une partie du nom - prescripteur principal. nud, de sorte que le nombre de liaisons formes dans un rseau n- nud est n- 1 . Tout graphe connexe avec n sommets et n- 1 liens doit tre un arbre. Bien sr, en dpit de chaque nud de prendre une dcision de minimisation locale de l'INR - pings, le spanning tree rsultant ne sera pas en gnral tre au minimum un. Nous travaillons actuellement sur l'amlioration de cet algorithme configuration en concevant une phase de relaxation qui change de manire asynchrone des relations de voisinage , terme, converger vers un arbre optimal en l'absence de mobilit. Nous notons galement que le spanning tree peut ne pas tre une topologie de superposition suffisamment robuste pour changer des noms et effectuer multicast intentionnel, car il dispose de plusieurs points de dfaillance uniques. Nous tudions actuellement d'autres algorithmes pour la construction de structures de recouvrement plus redondants.

2.5 L'quilibrage de charge et de mise l'chelle Il y a deux performances et l'volutivit ventuels goulots d'tranglement dans les recherches de systmes et le traitement de mise jour du nom. Pour manipuler des charges excessives lookup, nous permettons INRs pour frayer cas sur d'autres candidat (mais actuellement inactif) rsolveurs, et se tuent si elles ne sont pas charges. Pour frayer un INR sur un nud candidat, un INR obtient les

informations candidat - nud de la DSR. Un INR peut aussi se terminer si sa charge est infrieure un seuil, informer ses pairs et la DSR de cela. L'algorithme de superposition de spanning tree puis la figure 8. Un exemple de configuration li au processeur de lINS. Le processeur Pentium II est satur bien avant un lien 1Mbit / s. Les chiffres sont indiqus avec rafrachit passe toutes les 15 secondes. Sadapte ces changements dans la liste des INR active. Depuis INRs chang des informations avec d'autres rsolveurs nom sur une base priodique et galement via des mises jour dclenches, mise jour volutivit est une proccupation srieuse. Cest, aprs un point, le volume des mises jour de nom va commencer saturer soit la bande passante disponible ou de la capacit de traitement d'un nud de rsolution donn. Nous avons men plusieurs expriences pour comprendre les goulots d'tranglement dans notre conception. Alors que la bande passante du lien et du temps de traitement ncessaire pour le protocole de mise jour du nom

dpend de la taille du nom - prescripteurs et la complexit de l'arborescence des noms, nous avons trouv que le processus tait li au processeur dans toutes nos expriences. Sur notre application Java entre diffrentes machines Pentium II sous Linux RedHat 5.2 sur 1-5 Mbps liaisons sans fil, nous avons constat que pour un intervalle d'actualisation relativement rapide de 15 secondes avec des noms intentionnels 82 octets gnres alatoirement, le processeur tait satur avant de la bande passante consommation tait de 1 Mbps (figure 8). Nous avons galement constat que le traitement de nom dans le protocole de diffusion de nom a domin le traitement de recherche dans la plupart de nos expriences. Cela se produit parce que, dans cette conception, tous les rsolveurs doivent tre au courant de tous les noms dans le systme et ont traiter. Sur la base de ces expriences et une meilleure comprhension du goulot d'tranglement de l'chelle, nous dcrivons une solution qui soulage-il. L'ide est de partitionner l'espace en plusieurs espaces virtuels, en s'assurant que chaque rsolveur ne doit itinraire pour un sous-ensemble de l'ensemble des espaces virtuels actifs dans le systme. Conceptuellement, il y a maintenant un rseau de recouvrement de rsolution par l'espace virtuel (cependant, les superpositions de diffrents espaces virtuels peuvent s'tendre sur les mmes nuds du rsolveur) . Plus formellement, nous dfinissons un espace virtuel comme un ensemble d'applications spcifi par des noms qui partagent certaines caractristiques en commun. Par exemple, toutes les camras dans la construction de NE- 43 au MIT pourrait constituer la NE43 espace virtuel de la camra, et tous les appareils de la NE43 du btiment pourraient former la NE43 espace virtuel du btiment. Dans le premier cas, les noms (services) dans l'espace pourraient partager le service (gal " huis clos ") et " lieu " (gal NE- 43 MIT) attributs en commun, tandis que dans le second cas, ils tous partagent le mme emplacement.

Figure 9. Temps de mise jour priodique lorsque les noms sont diviss en deux espaces de taille gale. INS n'assume pas des noms despace virtuel dans le systme, mais ne ncessite que chaque nom de service, des espaces virtuels, il appartient (il peut appartenir plusieurs espaces virtuels aussi). Les clients et les applications peuvent interagir avec des services dans n'importe quel espace virtuel. Un INR sait quel espace virtuel d'une publicit ou requte appartient car il normalise un attribut bien connu, "vspace " par les applications qui peuvent exprimer le nom de leur espace virtuel. Les noms des deux espaces virtuels pour diffrents ensembles de services ne doivent pas entrer en collision, et nous sommes en train d'tudier les moyens de traiter de cette question. En interne, un INR stocke les noms des diffrents espaces virtuels, des arbres de noms figurant soi spar. Cloisonnement des espaces virtuels semble tre un promisingway de dlestage et d'amliorer considrablement l'volutivit de lINS, en particulier jusqu' plusieurs milliers de services. Sur la base de plusieurs expriences , nous avons constat que le temps de traitement requis pour les mises jour priodiques rduit proportionnellement quand on partage les noms dans diffrents espaces virtuels et ensuite les distribuer des rsolveurs distincts , comme le montre la figure 9. Si un INR reoit une demande d'un client rsoudre un espace virtuel, il ne route pour , il doit transmettre la demande un rsolveur qui le fait. Cela peut tre fait en mettant en cache les rsolveurs Pour un petit nombre d'espaces virtuels populaires, et si un cache se produit, l'envoi de la demande la DSR tre rsolues par un rsolveur appropri. En rsum, deux techniques simples promettent dintensifier la performance actuelle de lINS. Si un INR est trs charg en raison de la recherche de noms, il peut obtenir une liste dINR candidat et engendrer une nouvelle INR pour grer une partie de sa charge actuelle. Le protocole de configuration utilis par les clients pour choisir un INR par dfaut entranera certains d'entre eux de se dplacer lINR nouvellement engendr. Si un INR est charg cause du traitement mise jour, il est probable que tous les INRs dans cet espace virtuel sont galement chargs. Par consquent, la solution n'est pas de se reproduire un autre pour le mme espace, mais de dlguer un ou plusieurs espaces virtuels dun nouveau rseau dINR. Nos rsultats exprimentaux indiquent qu'il s'agit d'une approche prometteuse pour prendre et nous avons commenc appliquer cette ide.

3 Applications
Cette section dcrit l'API de l'INS et trois des applications, nous avons dvelopp l'utiliser que tirer parti de son soutien pour la dcouverte des ressources, la mobilit et la communication de groupe. Nous dcrivons plan de masse, un outil de dcouverte base sur la carte pour les services location dpendent, Camera, un rseau de camra mobile et une imprimante, un utilitaire d'impression d'quilibrage de charge. Une application utilise l'API pour crer un nom - prescripteur pour un service et d'annoncer priodiquement au rseau de lINR. Pour dcouvrir de nouveaux services, une application utilise lAPI pour envoyer un message de dcouverte pour un INR pour savoir quels sont les services qui correspondent un prnom - prescripteur ont t dcouverts par elle. Aprs la dcouverte de nom - prescripteurs, l'application communique avec les services correspondants en utilisant les fonctions API de construire un message. Applications choisissent anycast intentionnelle ou multicast intentionnel en rglant la livraison bit - drapeau dans l'entte du message, et contraignant tt ou tard en rglant le bit indicateur de liaison.

3.1 Amnagement intrieur: un outil de dcouverte de service Plan du salon est un outil de dcouverte de service qui montre comment les services bass sur la localisation divers peut tre dcouvert au moyen de lINS. Lorsque l'utilisateur dplace dans une nouvelle rgion, une carte de cette rgion apparat sur son cran comme un plan d'tage de l'immeuble. Floorplan ( plan d'tage) apprend de nouveaux services en envoyant un message de dcouverte pour un INR. Ce message contient un nom-prescripteur qui est utilis comme un filtre, et tout le nom - prescripteurs qui correspond elle est renvoye l'application. Floorplan utilise l'emplacement et informations de service contenues dans le revenu nom prescripteurs de dduire l'emplacement et le type de chaque service et afficher l'icne approprie. Un lment important du Plan d'tage est Locator, un serveur de localisation. Plutt que dintgrer directement les cartes de rgions, Floorplan rcupre les au besoin de Locator.

Cette rcupration se fait en envoyant une demande l'aide d'un nom-spcifier tels que: ????? ?? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? emplacement ? . En rponse, Locator rcupre la carte dsire et le renvoie l'instance de Floorplan requrant, en utilisant le nom intentionnel du demandeur pour acheminer le message. Comme les services sont annoncs ou time out, de nouvelles icnes sont affiches ou supprimes. En cliquant sur une icne invoque l'application approprie pour le service que reprsente licne. La mise en uvre du Plan d'tage dploy dans notre immeuble permet aux utilisateurs de dcouvrir une varit de services y compris les camras en rseau (section 3.2), imprimantes (section 3.3), et contrleurs de priphriques pour joueurs TV/MP3. Ces fournisseurs de services annoncent nom - prescripteurs en prcisant plusieurs de leurs attributs, y compris leur emplacement dans le btiment. Par exemple, une camra dans la salle 510 annonces le nom - prescripteur suit :

3.2 : Camera : un service de camra mobile Nous avons mis en place un service de l'appareil mobile, appareil photo, qui utilise INS. Il existe deux types d'entits dans Camera : metteurs et rcepteurs. Un rcepteur demande images de la camra que l'utilisateur a choisie (en plan) en envoyant des requtes un nom intentionnel qui le dcrit. Ces demandes sont transmises par l'INRS un metteur de la camra, qui renvoie une rponse avec l'image. Il existe deux modes de communication possibles entre les metteurs et les rcepteurs de camra. Le premier est un mode de requte-rponse, tandis que la seconde est une interaction suscription style qui utilise multicast intentionnel pour la communication de groupe. Dans le mode de demande-rponse, un rcepteur envoie une demande de l'image l'metteur d'intrt en dsignant de faon approprie ; l'metteur correspondant, son tour, renvoie l'image demande au rcepteur. Pour envoyer l'image que le demandeur, le transmetteur utilise l' ? ? domaine du rcepteur qui identifie de manire unique. Camra utilise pour continuer de faon transparente en prsence de nud ou un appareil photo mobilit.

Par exemple, un utilisateur qui veut demander une image provenant d'une camra dans la chambre 510 peut envoyer une requte destination RIN avec nom prescripteur : ????? ?? ????????????????????????? ?????#?$%? et la source de nom - prescripteur :

????? ?? ?????????????? ???????!????????"?#?$?%? L'metteur qui reoit cette requte renverra l'image de la source et la destination nom - prescripteurs invers par rapport ce qui prcde. L'attribut dans la destination nom - prescripteur se rfre l'emplacement de lmetteur ; l'attribut permet l'INRS de transmettre la rponse au rcepteur intress. Quand une camra mobile se dplace vers un emplacement rseau diffrent, il envoie une mise jour pour un INR annonant son nom du nouvel emplacement. Le protocole de dcouverte de nom garantit que les informations primes sont retires de larbre de noms, et les informations du nouveau nom qui reflte le nouvel emplacement du rseau sera bientt entrer en vigueur. Ainsi, tout changement dans l'emplacement rseau d'un service est rapidement suivi et actualises par lINRS, ce qui permet aux applications de continuer. En plus de cette mobilit du rseau, INS permet galement aux applications de grer la mobilit des services. Ici, un service comme une camra mobile se dplace d'un endroit un autre, et son emplacement rseau n'est pas (ncessairement) le changement. Cependant, son nom intentionnelle peut changer pour reflter son nouveau lieu ni de nouvelles proprits de ce nouvel environnement, il a observ, et il peut maintenant tre en mesure de fournir au client les informations qu'il cherche. Avec des noms intentionnelles, telles proprits spcifiques aux applications telles que l'emplacement physique peuvent tre exprimes et suivis. Appareil photo utilise multicast intentionnel pour permettre aux clients de communiquer avec des groupes de camras, et des camras pour communiquer avec des groupes dutilisateurs. Il tire parti de bien que le nom intentionnel peut tre utilis non seulement pour la description des services riches, mais galement de se rfrer un groupe de nuds de rseau qui partagent certaines proprits qui sont spcifies dans leurs noms.

Pour utiliser cette fonction, l'metteur de la camra envoie une image destine tous les utilisateurs abonns ses images en rglant le bit D - drapeau tous. Lorsque lINR est un nom-spcifier, il trouve tous les emplacements de rseau qui correspondent. Au lieu de transmettre les donnes seulement le meilleur d'entre eux, il envoie les donnes chaque INR saut suivant pour lequel il s'agit d'un emplacement de rseau associ. De mme, un utilisateur peut galement souscrire toutes les camras dans le btiment (ou une partie d'entre eux nomm par certains critres). Par exemple, un metteur de camra situe dans la salle 510 envoie ses images tous ses abonns la fois en utilisant la destination suivante nom - prescripteur : ????? ?? ?????????????? ?????????????????#?$?%? et rgler la livraison bit - drapeau de tous. L'utilisation de joker 4????5 se rfre tous les abonns, indpendamment de leurs papiers d'identit spcifiques. Lors de l'implmentation camra, nous avons remarqu qu'il serait utile de photos de cache plusieurs endroits dans le rseau, de sorte que les demandes n'ont pas revenir au serveur d'origine chaque fois. Pour ce faire, nous avons conu une extension application Independent INS qui permet de mettre en cache INRs paquets de donnes. Les noms intentionnels faites la conception de la mise en cache application Independent plutt simple. Avec les systmes de noms traditionnels chaque application dispose de ses propres noms opaques pour les units de donnes, et aujourd'hui est distribu systmes de mise en cache sont lis des applications spcifiques (par exemple, les caches Web). En revanche, les noms volontaires donnent un vocabulaire riche applications avec lesquelles le nom de leurs donnes, tout en conservant la structure de ces noms comprhensible sans aucune connaissance spcifique lapplication. Ainsi, les noms intentionnels peuvent tre utiliss comme une poigne pour un objet mis en cache. Bien sr, il est toujours ncessaire de fournir des informations supplmentaires pour dcrire si et pour combien de temps l'objet doit tre mis en cache, nous avons donc ajout un petit nombre de champs supplmentaires l'en-tte du message de l'INS transmettre cette information l'INRS.

3.3 Printer : un utilitaire de l'imprimante d'quilibrage de charge

L'application cliente de l'imprimante commence lorsque l'utilisateur clique sur une icne de l'imprimante sur l'cran plan dtage. L'application cliente de l'imprimante dispose de plusieurs fonctions. Il peut rcuprer une liste d'emplois qui se trouvent dans la file d'attente de l'imprimante, retirez un emploi choisi dans la file d'attente

que l'utilisateur possde la permission de le faire, et permettre lutilisateur d'envoyer des fichiers l'imprimante. Des soumissions de travaux l'imprimante peuvent tre faites de deux manires, l'une qui utilise

Unicast intentionnel de dcouvrir le meilleur Imprimante selon la localisation et les caractristiques de la charge. Le premier mode de soumission est le simple " soumettre emploi pour nommer , o le nom est le nom intentionnel de l'imprimante. Le second mode, qui est celle que nous trouvons utile dans l'utilisation au jour le jour, est de prsenter un travail bas sur l'emplacement de lutilisateur. Les serveurs dimpression, qui sont des procurations pour les imprimantes relles dans notre mise en uvre, modifier les paramtres qui sont rgulirement annoncs l'INRS en tenant compte de ltat derreur, le nombre demplois en file dattente, la longueur de chacun, etc. L'INRS gestion prvisionnelle des emplois l'imprimante actuellement moins charg en fonction de ces publicits , et d'informer l'utilisateur de l' imprimante choisie . La publicit d'une mtrique plus petite pour un moins imprimante charg et en utilisant unicast intentionnel permet imprimante effectue automatiquement quilibrer leur charge. Par exemple, pour envoyer un fichier vers l'imprimante moins charg dans la salle 517, le client de l'imprimante envoie le fichier la destination suivante nomprescripteur: ???? ? ? ? ? ? ??? ? ??? ? ???? ?? ? ? ?? ?? ??? #? $? ? et dfinit la livraison bit-drapeau pour tout. Notez que le nom de l'imprimante est omis dessein. En utilisant anycast intentionnel, INRS choisir automatiquement l'itinraire qui a la meilleure mtrique pour l'imprimante spcifie nomprescripteur, ce qui correspond l'imprimante moins charg dans la chambre 517.

4 Mise en uvre
Nous avons mis en place INS et test l'aide dun certain nombre dapplications, y compris ceux dcrits dans la section prcdente. Notre mise en uvre de l'INR est en Java, afin de profiter de sa portabilit multiplateforme, les clients et les services , cependant, ne sont pas contraints d'tre crit en Java. Dans cette section, nous prsentons les dtails de deux aspects de lINS : l'architecture d'un nud INR, et les formats de paquets pour intentionnel noms. INRs utilisent UDP pour communiquer les uns avec les autres. Lors d'un INR, le 2?? ? Objet gre toutes les ressources du rseau. Il maintient l' 2??) ? ? qui est utilis pour rsoudre un nom intentionnelle son nom - enregistrement correspondant, un 2??????? ? ? ? qui reoit tous les messages entrants, et un ????? ??

*??

? de transmettre des messages INRS et applications. En outre, un 2 ? ? ? ? ? ? ? , ? ? ? module implmente le protocole de dcouverte de nom, et un 2?????

?? ????

? application fournit une interface graphique pour contrler et dboguer le systme et afficher le nom darbre. Au niveau du client, un

???????? ?? ?? ? dtecte les mouvements de rseau et reliaisons le socket UDP si les changements d'adresse IP, transparente pour les applications. La mise en uvre INR se compose d'environ 8500 lignes de code Java , dont environ 2500 lignes sont pour l'API de l'INS . L'API facilite considrablement le dveloppement dapplications, par exemple, les applications de FloorplanDirections et appareil photo prsentes dans la section 3 ont chacun mis en uvre en moins de 400 lignes de code Java (y compris les services et le code client, mais l'exclusion de linterface utilisateur graphique), et l'imprimante demande en moins de 1000 lignes. La figure 10 montre le format de paquet de l'INS pour les noms intentionnels. Le bit indicateur de liaison (B) est utilis pour dterminer si la liaison prcoce ou tardive doit tre utilise, tandis que le bit indicateur de livraison (D) est utilis pour dterminer si anycast intentionnel ou la livraison multicast doivent tre utiliss. Parce nom - prescripteurs sont de longueur variable, l'en-tte contient des pointeurs vers la source nom - prescripteur, destination nom - prescripteur, et des donnes, qui donnent des dcalages depuis le dbut du paquet. Ceci permet lagent de transfert d'un INR de trouver la fin du nom, prescripteurs, sans avoir les analyser. RIN ne traitent pas les donnes dapplication. En outre, un saut limite diminutions sur le terrain chaque saut et limite le nombre de sauts qu'un message peut parcourir dans la superposition. Le champ de dure de vie du cache donne la dure de vie des donnes de ce paquet peuvent tre mis en cache pour, d'une valeur de zro cache interdisant. Figure 10. Le format de message d'en-tte de lINS. Figure 11. Un uniformment augment nom -tree. Notez que =? ?

profondeur de l'arbre ? ? = ? cet arbre.

5 Analyse des performances et valuation


Dans cette section, nous analysons les performances du nom algorithme de recherche de l'INS et de prsenter les rsultats de nos expriences avec l'algorithme de recherche et protocole de dcouverte de nom. Ces expriences ont toutes t effectues en utilisant off -the-shelf Intel Pentium II 450 MHz ordinateurs avec un cache de 512 Ko et 128 Mo de RAM, fonctionnant sous Red Hat Linux 5.2 ou Windows NT Server 4.0, avec notre logiciel construit en utilisant Sun, AOS version Java 1.1 .7 . Les nuds du rseau sont connects via des liaisons sans fil RF compris entre 1 et 5 Mbps.

5.1 Nom performances de recherche 5.1.1 Analyse Pour comprendre comment les chelles de l'INS avec l'augmentation de la charge de recherche, il est important d'analyser la performance de l'algorithme de recherche. Nous analysons le pire moment de l'excution de l'algorithme en fonction de la complexit du nouveau nom - prescripteur et le nom darbre. Pour simplifier lanalyse, nous supposons que le nom - prescripteurs crotre de manire uniforme dans les dimensions suivantes (illustr dans la figure 11) : Dans chaque invocation, l'algorithme parcourt les attributs dans le nom - prescripteur, de trouver l'attribut et la valeur correspondante de larbre de noms et de faire un appel rcursif. Ainsi, le temps de marche est donn par la rcurrence : o ? ? et reprsenter le temps de trouver l'attribut et de valeur, respectivement. Pour linstant, supposons que cela prend du temps pour le cas de base : Si la recherche linaire est utilise pour trouver les attributs et les valeurs, la dure serait: parce que ? ? ? ? ? et ? ? ? dans ce cas.

Cependant, en utilisant une table de hachage simple pour trouver ces rduit le temps d'excution :

De l'analyse qui prcde, il semble que le ? facteur peut souffrir de problmes d'chelle si ? grossit . Toutefois, les deux ? et, l'chelle la complexit d'une seule application associe avec le nom - prescripteur. Il y a seulement autant d'attributs ou les niveaux un nom - prescripteur en tant que concepteur d'application doit dcrire les objets qui sont utiliss par l'application. Par consquent, nous prvoyons que ce sera quasi- constante et relativement faible, en effet, toutes nos applications actuelles ont cette proprit leur nom - prescripteurs. Le cot du scnario de base, ? , Est le cot dune opration d'intersection entre l'ensemble d'entres de routes la feuille de larbre de noms et la route ensemble cible actuelle. Prenant l'intersection des deux ensembles de taille # ? et #

prend ??? ??#? # ? temps, si les deux jeux sont tris (comme dans notre application) . Dans le pire des cas, la valeur de ? est de l'ordre de la taille de lensemble universel de entres de route ( ? ? ? ?), mais elle est gnralement beaucoup plus petits . Malheureusement, une analyse de cas en moyenne ? est difficile raliser analytiquement, car il dpend du nombre et de la distribution des noms. 5.1.2 Les expriences

Pour dterminer exprimentalement le nom performances de recherche de notre (dsaccord) implmentation Java d'un INR, nous avons construit un grand hasard arbre de noms, et chronomtr le temps qu'il a fallu pour effectuer 1000 oprations de recherche au hasard sur l'arbre.

Larbre de noms et le nom - prescripteurs ont t choisis de manire uniforme avec les mmes paramtres que dans lanalyse de la section 5.1. Nous avons fait varier , le nombre de noms distincts dans l'arborescence , et les temps de lookup mesures . Nous avons limit la taille du tas maximum de l'interprteur Java 64 Mb et fix l'allocation initiale de ce montant pour viter les artefacts provenant d'autres l'allocation de mmoire de la machine. La gamme de nos expriences a t limite par la mmoire ncessaire pour stocker les noms distincts d'tre regard vers le haut ( partie de l'appareil exprimental) plutt que le nom d'arbre lui-mme (ce qui est beaucoup plus compact). Nous avons corrig les paramtres ? ? ? ? ,??? , ? ? ? , et ??? Et vari de 100 14300 par incrments de 100. Nos rsultats sont prsents dans la figure 12. Pour ce nom -tree Figure 12 . Les performances de recherche Nom -tree. Ce graphique montre comment les performances de recherche arbre de noms d'un INR varie en fonction du nombre de noms dans son arbre de noms . et le nom - prescripteur la structure, notre performance est pass d'un maximum d'environ 900 recherches par seconde un minimum d'environ 700 recherches par seconde. Cette exprience nous a donn une ide concrte de la faon dont le scnario de base affecte les performances. Pour la mme exprience, nous avons galement enregistr la quantit de mmoire alloue par Java lexprience, ce montant devrait tre suprieur la taille relle arbre de noms que dune quantit constante. Les chanes que nous avons utiliss pour les noms d'attribut et de valeur avait qu'un seul (Unicode) caractre ou 16 bits de long, ainsi que la mmoire est reprsentatif de ce qu'est un encodage plus compact des attributs et des valeurs permettrait datteindre. Toutefois, la croissance de larbre de noms resterait le mme, puisque, aprs les mille premiers noms sont dans l'arborescence de nom (o le graphique des courbes partir de zro) tous les attributs et les valeurs qui existent sont stocks dans le nom darbre, et utilisation

de la mmoire supplmentaire ne vient que de pointeurs supplmentaires et le nom -records. Nos rsultats sont prsents dans la figure 13. La quantit de mmoire alloue larbre de noms est pass approximativement de 0,5 mga-octets 4 mga-octets que le nombre de noms a t augment. Nous croyons que cette magnitude orderof des performances de recherche est suffisant pour intra Domain dploiement, en raison de la rpartition de charge fourni en ayant plusieurs DNP et le paralllisme inhrent recherches de noms indpendants.

5.2 Nom performances de dcouverte Cette section montre que l'INS est sensible au changement et de dynamisme dans les services et les nuds, en discutant de la performance du protocole de dcouverte de nom. Nous avons mesur les performances de l'INS dans la dcouverte de nouveaux fournisseurs de services, qui annoncent leur existence par le nom - prescripteurs. La figure 14 montre le temps de la dcouverte d'un nouveau moyen Name-spcifier en fonction de , le nombre de sauts dans le rseau de l'INR du nouveau nom. Quand un INR observe un nom - prescripteur nouveau d'un service de publicit, il traite le message de mise jour et effectue une opration de recherche sur le nom d'arbre pour voir si un Name-spcifier avec le mme Annonceur ID existe dj. Si elle ne trouve pas, il greffe le nom spcificateur sur son nom Figure 13. Taille Nom-tree. Ce graphique montre comment la taille arbre de noms varie selon le nombre de nom. Figure 14. Le temps de la dcouverte d'un nouveau nom de rseau. Ce graphique montre que le temps de dcouvrir un nouveau nom de rseau est linaire dans le nombre dINR houblon. arbre et propage une mise jour dclenche ses voisins. Ainsi, le temps de dcouverte de nom dans un rseau de DNP et des liens identiques ? ? ? ? ? ? ? ? ?? ?? ? ? ? , O? est la recherche temps ? ? C'est le moment de greffe, ? ? ? est le temps de traitement de mise jour, et ?

est le retard de rseau unidirectionnelle entre deux nuds quelconques. Cest, nom temps de dcouverte doit tre linaire dans le nombre de sauts. La question exprimental est ce que la pente de la droite, c'est parce que dtermine INS sensible est dans le suivi des modifications. Dans nos expriences, la structure de larbre de noms sur chaque INR tait relativement constante, sauf pour les nouvelles greffes, car nous n'tions pas en

Cours d'excution d'autres applications dans le systme pendant les mesures. Ainsi, les temps lookup et de la greffe un INR et les autres taient peu prs les mmes. Comme le montre la figure 14, ? ? est en effet linaire en , avec une pente de moins de 10 ms / hop . Cela implique que les temps de dcouverte typiques y a seulement quelques dizaines de millisecondes, et domines par des retards de transmission du rseau.

5.3 Performance Routing En plus des expriences de lookup et de dcouverte, nous avons galement mesur les performances de l'ensemble du systme lorsque les deux se produisent simultanment. Pour ces expriences, nous avons envoy une rafale Figure 15. Temps de traitement et par INR routage pour un clatement de 100 paquets, dans le intra -INR, inter -INR, et les cas de l'espace inter Virtual d' une centaine de messages de 586 octets , se sont runis partir de l'application Appareil photo , entre 15 secondes d'intervalle de mise jour priodiques. La source de spcification de nom et de l'adresse de destination a t gnre alatoirement, en moyenne 82 octets de long. Les rsultats sont prsents dans la figure 15. Pour le cas o lmetteur et le rcepteur sont sur le mme nud, le traitement et le temps d'acheminement varie quelque peu avec la taille arbre de noms pour l'espace virtuel donn, de 3,1 ms par paquet de 250 noms 19 ms par paquet de 5000 noms. Ceci est partiellement d la vitesse des recherches arbre de noms, mais c'est aussi un artefact du code de prestation de en dapplication actuel, qui arrive varier linairement avec le nombre de noms. Nous observons une ligne flatter par l'examen des donnes de paquets destins un INR distance dans le nom d'arbre du mme espace virtuel. Pour la plupart, le temps de traitement Next-hop est d'environ 9,8 ms par paquet lors de lclatement. Dans ce cas, les recherches arbre de noms se produisent encore, mais le code de livraison de bout en application n'est pas invoqu. Cela donne une meilleure indication de la recherche pure et la performance de transfert.

Lorsque le bnficiaire rside dans un espace virtuel diffrent sur un autre nud, on observe un temps peu prs constant de 381 ms rsoudre et de la voie de

l'clatement de 100 messages. Cette fois stable provient du nud n'ayant aucune connaissance de l'espace virtuel fin, sauf pour une adresse INR Next- hop, qui est demand et mis en cache partir de la DSR lors du premier accs, qui il peut envoyer des paquets.

6 Travaux connexes
Une nomination souple et le systme de rsolution pour la dcouverte de ressources, tel que celui fourni par lINS, est bien adapt aux environnements de rseaux dynamiques. INS utilise un simple, expressive langue de nom, machines liaison tardive qui intgre rsolution et de routage pour anycast intentionnelle et protocoles de multidiffusion, soft-state nom diffusion de robustesse, et un rseau de rsolution auto-configuration. INS vise complter, et non remplacer lInternet DNS qui mappe les noms d'htes en adresses IP. Les noms DNS sont strictement hirarchique, alors que les noms de l'INS utilisent une plus ex-base sur les attributs nant langue. Contrairement DNS, le nom propagation dans INS ressemble un protocole de routage, l'coute d'effectuer des mises jour rapides. En INS, les noms proviennent et sont rafrachies par des applications qui annoncent eux. Cela permet le partage de sort [9] entre les noms et les services correspondants si un nud fournissant un service se bloque, il va galement cesser d'annoncer que service. Dans DNS, rsolveurs forment un rseau de superposition statique constitu de serveur de nom du client, le serveur racine, et les serveurs de noms de domaine au propritaire de la route et de rsoudre les demandes, contrairement la superposition d'auto-configuration INS. Il y a eu une certaine activit rcente dcouverte de service pour les rseaux htrognes d'appareils. Sun Jini [21] fournit un cadre pour le calcul distribu spontane en formant une fdration d'appareils en rseau " via Remote message Invocation de Java (RMI). Jini n'aborde pas comment la dcouverte des ressources va travailler dans un environnement dynamique ou lorsque les services ne parviennent pas, et peut bnficier de l'INS comme ressource systme dcouverte. Universal plug- and-play [42] utilise un sous-ensemble de XML pour dcrire les ressources fournies par les appareils et, comme Jini, peuvent bnficier de lINS comme un systme de dcouverte. Le Service Location Protocol (SLP) [44, 33] facilite la dcouverte et l'utilisation des ressources du rseau htrognes utilisant des agents d'annuaire centralis. Le Service de dcouverte Berkeley (SDS) [11] tend cette notion des communications scurises et authentifies et une structure hirarchique fixe pour un fonctionnement tendu. Contrairement Jini, SLP, et le SDS, INS poignes dynamisme via une liaison tardive, fournit anycast intentionnelle et services de multidiffusion, a rsolveurs auto- configuration et ne pas compter sur IP multicast pour effectuer la dcouverte. De nombreux services d'annuaire attribut base ont t proposs dans le pass. Lannuaire distribu X.500

[7, 36] par le CCITT (maintenant l'UIT -T) facilite la dcouverte de ressources en utilisant un seul espace de noms global avec l'entretien dcentralis. INS diffre de X.500 dans ses objectifs et mcanismes permettant d'atteindre la ractivit et

l'expressivit ; INS permet la liaison tardive et utilise le nom de diffusion douce tat. Le rseau de rsolution de l'INS est galement diffrent de la hirarchie statique X.500. Ces diffrences tiennent des diffrences dans notre environnement, ce qui est un dynamique et mobile rseau avec peu d'infrastructures pr-configur. En plus de la richesse de la littrature classique sur la dnomination dans les systmes distribus (par exemple, Grapevine [4] , Name Service mondial [23] , etc. ) , il y a eu quelques recherches rcentes dans nommage et de rsolution tendu. Par exemple, Vahdat et al. [43] prsentent un systme dActive-Names, qui permettent aux applications de dfinir calcul arbitraire qui s'excute sur les noms rsolveurs. INS et ActiveNames partagent des objectifs communs, mais diffrent considrablement dans leur faon de les atteindre. En particulier, l'INS ne ncessite pas de code mobile, comptant plutt sur un schma de nommage simple mais expressive pour permettre aux applications d'exprimer l'intention et la liaison tardive pour tre sensible au changement. En outre, INS met en uvre un rseau de rsolution auto-configuration base sur les performances du rseau. Une proposition tt pour dcoupler les noms de lieux de l'objet a t dcrit dans un article de O'Toole et Gifford [28], o ils dcrivent un contenu schma de nommage et son application aux systmes de fichiers smantiques [18]. Leur conception et l'application des noms de contenu est trs diffrente de la ntre, mais la philosophie sous-jacente est similaire. Le systme Discovery [39] est un systme de document dcouverte base sur HTTP qui utilise le routage de transmettre une requte vers les serveurs qui contiennent le rsultat de la requte. Discovery est centre sur les documents et utilise des processus parallles pour rechercher des serveurs et fusionner les rsultats. Oki et al. Introduire lInformation Bus [30] pour permettre aux applications de communiquer en dcrivant l'objet des donnes souhaites, sans savoir qui est les fournisseurs. D'autres projets avec une saveur semblable comprennent Malan et al. De Salamandre [25] et les SmartSockets de Talarian [40]. Ceux-ci utilisent un schma de nommage plat, ne prennent pas en charge la liaison tardive, et ont configur statiquement rsolveurs. Lide de sparer les noms de lieux du rseau a galement t propose par Jacobson dans le contexte de multidiffusion base de caches Web auto-configuration [20]. Estrin et al. Construire sur ce point, l'exploration d'une approche diffusion base la diffusion des donnes dans les rseaux de capteurs en utilisant les attributs de donnes instancier tat de transmission au niveau des

nuds de capteurs [15]. Notre schma de nommage intentionnel a certaines caractristiques en commun avec ces propositions, mais il en diffre dans les dtails de la rsolution, la liaison tardive et les processus de diffusion de nom, ainsi que l'architecture globale du rsolveur. Le DistributedDirector de Cisco [8] rsout une

URL l'adresse IP du serveur " plus proche , base sur la proximit client et la latence lien client- serveur. Contrairement INS, DistributedDirector n'est pas un cadre gnral pour la dnomination et de la rsolution et n'intgre pas la rsolution et le routage. En outre, chaque rsolveur est indpendant dans DistributedDirector, alors qu'ils forment un rseau de recouvrement cooprer dans INS. " Les Espaces T " d'IBM [24] permettre la communication entre des applications dans un rseau en fournissant une base de donnes lgre, sur lequel les nuds du rseau peuvent effectuer des requtes. Cependant, ce systme a t optimis pour les applications client-serveur relativement statiques plutt que dynamique pour la communication peer- topeer, et utilise une base de donnes centrale pour maintenir les mappages de tuple. D'autres architectures orientes objet pour l'informatique distribue sont CORBA de l'OMG [29] et le Service de ngociation ANSA [13], o les serveurs fdrs rsoudre les demandes de rglement des clients. En conservant la connectivit rseau au cours de la mobilit ncessite un niveau d'indirection pour que le trafic l'hte mobile peut tre redirige vers son emplacement actuel. Mobile IP [32] utilise un agent d'accueil dans le domaine de la maison de lhte mobile cet effet. Avec INS, le niveau d'adressage indirect pour localiser les services mobiles et les utilisateurs est obtenu en utilisant le systme de nommage intentionnel, puisque tout le trafic vers le service mobile serait pass par le processus de rsolution de nom. L'intgration troite de nommer et de transmission permet une connectivit rseau a continu dans le visage de la mobilit des services et protocoles de dcouverte de l'architecture de lINS dcentralise et le nom d'amliorer la robustesse. Un certain nombre de protocoles pour ad hoc ou infrastructure sans routage ont t rcemment proposs (par exemple, [6]). Ces protocoles sont essentiels pour permettre la connectivit IP, mais ne fournissent pas la fonctionnalit de dcouverte de ressources.

7 Conclusions
Dans ce Mmoire, nous avons tabli la ncessit d'un schma de nommage intentionnel, o les applications dcrivent ce qu'ils recherchent, pas o trouver les donnes. Nos objectifs de conception taient expressivit, la ractivit, la robustesse et la facilit de configuration. Nous avons prsent la conception, la ralisation et l'valuation d'un systme de nommage intentionnelle (INS) qui rpond ces objectifs. INS utilise un langage de nommage simple, bas sur les attributs et les valeurs atteindre l'expressivit, intgre la rsolution de noms et de routage des messages pour permettre aux applications d'tre sensible l'volution de la mobilit et de performance, utilise annonces de service priodiques et des protocoles de diffusion doux nom tatiques entre rsolveurs rpliques assurer la robustesse , et dploie le nom d'auto-configuration rsolveurs faciliter la configuration .

Le modle de service de l'INS prend en charge trois types de rsolution : fixation prcoce, lorsqu'une demande peut obtenir une liste des adresses IP correspondant un nom, et deux formes de liaison tardive : anycast intentionnelle et dlibre de multidiffusion. Intentionnelles envoi la cantonade en avant un message au "meilleur" nud satisfaire une requte tout en optimisant une mtrique application contrle et dlibre avant multicast un message tous les noms satisfaisant une requte. Nous avons prsent la conception et l'analyse d'un algorithme efficace pour la recherche de noms et les mesures de notre mise en uvre , qui montrent que l'application Java peut effectuer entre plusieurs centaines de recherches par seconde

( pour le nom - prescripteurs complexe ) quelques milliers de recherches par seconde. Nous avons valu le protocole de dcouverte de nom et a dmontr quINS pourraient diffuser des informations sur les nouveaux noms de dizaines de millisecondes. Nous avons galement mesur le temps, le traitement des mises jour de nom, analys les goulets d'tranglement de mise lchelle, et nous avons

trouv que le partitionnement d'espace de noms est une technique pratique pour amliorer l'volutivit de lINS.

Notre exprience avec l'INS nous a convaincus que l'utilisation de noms intentionnels ayant une liaison tardive est un moyen utile de dcouvrir des ressources dans les rseaux dynamiques, mobiles, et simplifie la mise en uvre d'applications. Nous soulignons quINS permet aux applications de suivre efficacement les attributs de donnes dynamiques, car le choix des attributs utiliser dans name-specifiers est compltement sous l'application de contrle. Nous pensons donc que l'INS a le potentiel de devenir une partie intgrante du dispositif avenir et les rseaux de capteurs o dcentralise, la dcouverte de ressources facilement configurable est essentielle. Il reste quelques domaines de recherche importants avant les avantages de lINS peuvent tre ralises. Tout d'abord, nous devons largir soigneusement l'ensemble des oprateurs supports dans le processus de rsolution, incorporant des matchs de gamme en plus de correspondances exactes d'attributs et de valeurs. Deuximement, l'architecture de lINS actuel est conu pour le dploiement intradomaine. Nous dveloppons activement une architecture tendue l'chelle INS pour rseaux tendus. Troisimement, les protocoles de dcouverte de nom doivent tre accordes utiliser la bande passante de manire efficace tout en diffusant des noms, certains noms sont plus phmres ou plus importants que dautres, ce qui implique que tous les noms ne doivent pas tre traits de manire gale par le protocole de diffusion douce - Etat [35]. Et peut-tre plus important encore, nous devons intgrer des mcanismes de scurit dans l'architecture de nommage avant un dploiement plus large chelle. En fin de compte, les avantages de l'INS sont en facilitant le dveloppement dapplications et de services utiles, et nous mettent en uvre d'autres applications dmontrer les avantages de l'INS et de caractriser la classe d'applications qui facilite INS.

Vous aimerez peut-être aussi