Groupe de travail Réseau	J. Kempf, NTT DoCoMo USA Labs	
Request for Comments : 3105	G. Montenegro, Sun Microsystems	
Catégorie : Expérimentale	octobre 2001	
Traduction Claude Brière de L’Isle		

Trouver un serveur RSIP avec SLP

Statut de ce mémoire
Le présent mémoire définit un protocole expérimental pour la communauté de l’Internet. Il ne spécifie en aucune façon une norme de l’Internet. Des discussions et suggestions pour son amélioration sont demandées. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright 
Copyright (C) The Internet Society (2001). Tous droits réservés.

Note de l’IESG
L’IESG note que l’ensemble de documents décrivant la technologie RSIP implique des changements significatifs des hôtes et des routeurs pour une mise en œuvre complète. De plus, le flottement des numéros d’accès peut causer des problèmes à certaines applications, empêchant un hôte à capacité RSIP d’interopérer de façon transparente avec les applications existantes dans certains cas (par exemple, IPsec). Finalement, il peut y avoir des complexités de fonctionnement significatives associées à l’utilisation de RSIP. Certaines de ces complications et d’autres sont mentionnées à la section 6 de la RFC3102, ainsi que dans les appendices de la RFC3104. En conséquence, les coûts et avantages de l’utilisation de RSIP devraient être soigneusement soupesés par rapport à d’autres moyens de suppléer au manque d’adresses.

Résumé
Le présent document contient un gabarit de type de service SLP qui décrit les annonces faites par les serveurs RSIP pour leurs services. Le protocole de localisation de service (SLP, Service Location Protocol) est un protocole en cours de normalisation par l’IETF spécifiquement conçu pour permettre aux clients de trouver les serveurs qui offrent des services particuliers. Comme les clients IP spécifiques de domaine (RSIP, Realm Specific IP) exigent un mécanisme pour découvrir les serveurs RSIP, SLP est un candidat naturel pour une solution. Le gabarit de type de service est la base d’une définition standard par l’autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) des annonces offertes par les serveurs RSIP, une étape importante vers l’interopérabilité.

Table des Matières
1. Introduction	1
2. Conventions de notation	2
3. Terminologie	2
4. Utilisation de SLP pour la découverte de service RSIP	2
5. Utilisation des portées pour l’approvisionnement de serveur	3
6. Équilibrage de charge	4
7. Gabarit de type de service RSIP	4
8. Considérations pour la sécurité	5
9. Résumé	5
Références	5
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6

1.	Introduction

IP spécifique de domaine (RSIP) [7] permet à un client RSIP dans un domaine d’emprunter des adresses et autres ressources à un autre domaine. Il fait cela en engageant un échange de protocole RSIP [1] avec un serveur RSIP. Le protocole RSIP exige du serveur RSIP qu’il ait une présence permanente sur les deux domaines.

Il y a diverses façons traditionnelles dont un client RSIP peut arriver à localiser le serveur RSIP approprié. Cependant, le protocole de localisation de service (SLP) [2], [11] est un protocole en cours de normalisation par l’IETF qui est spécifiquement conçu pour faciliter la localisation des services et de leurs serveurs par les clients. SLP fournit un certain nombre de caractéristiques qui simplifient la localisation des serveurs RSIP. Dans le présent document, on décrit comment les clients RSIP peuvent utiliser SLP pour découvrir les serveurs RSIP.

2.	Conventions de notation

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la RFC2119 [4].

3.	Terminologie

On reproduit ici un peu de la terminologie SLP de [2] pour les lecteurs qui ne seraient pas familiers avec SLP.

Agent d’utilisateur (UA, User Agent)
Un processus qui fonctionne au nom de l’utilisateur pour établir le contact avec un service. L’UA restitue les informations de service à partir des agents de service ou des agents de répertoire.

Agent de service (SA, Service Agent)
Un processus qui fonctionne au nom d’un ou plusieurs services pour annoncer les services.

Agent de répertoire  (DA, Directory Agent)
Un processus qui collecte les annonces de service. Il ne peut y avoir qu’un seul DA présent par hôte.

Type de service
Chaque type de service a une chaîne unique de type de service.

Autorité de dénomination
C’est l’agence ou groupe qui catalogue les types de service et les attributs. L’autorité de dénomination par défaut est l’IANA.

Portée (Scope)
Un ensemble de services, constituant normalement un groupe administratif logique.

Annonce de service
Un URL, des attributs, et une durée de vie (indiquant pendant combien de temps l’annonce est valide) fournissant des informations d’accès au service et une description des capacités d’un service particulier.

4.	Utilisation de SLP pour la découverte de service RSIP

SLP fournit le cadre dans lequel les clients et serveurs RSIP prennent contact. On décrit ici comment un serveur et un client RSIP se trouvent l’un l’autre à l’aide de SLP :

1.	Le serveur RSIP met en œuvre un agent de service (SA) SLP tandis que le client RSIP met en œuvre un agent d’utilisateur (UA) SLP.

2.	Le SA RSIP construit une annonce de service consistant en un URL de service, des attributs et une durée de vie. L’URL a un type de service "service:rsip", et les attributs définis selon le gabarit de la Section 7.

3.	Si un agent de répertoire (DA) SLP est trouvé, le SA contacte le DA et enregistre l’annonce. Si aucun DA n’est trouvé, le SA entretient l’annonce lui-même, répondant directement aux interrogations en diffusion groupée des UA.

4.	Lorsque le client RSIP demande des informations de contact pour un serveur RSIP, l’UA contacte le DA en utilisant l’envoi individuel ou le SA en utilisant la diffusion groupée. L’agent d’utilisateur inclut une interrogation sur la base des attributs pour indiquer les caractéristiques du serveur qu’il demande.

5.	Une fois que l’UA a le nom de l’hôte ou l’adresse du serveur RSIP ainsi que le numéro d’accès, il peut commencer la négociation en utilisant le protocole RSIP.

Cette procédure est exactement la même pour toute paire client/serveur qui met en œuvre SLP et n’est pas spécifique de RSIP.

De nombreux protocoles utilisent diverses méthodes traditionnelles pour la découverte de services. Ces méthodes incluent la configuration statique, les protocoles construits spécialement pour la découverte, des caractéristiques particulières dans le protocole lui-même, les enregistrements de ressource (RR) SRV du DNS [5], ou DHCP [6]. SLP fournit un certain nombre d’avantages sur ces méthodes traditionnelles :

1.	La découverte des services à l’aide de SLP est dynamique, tandis que nombre des méthodes traditionnelles ne permettent qu’une découverte statique ou faiblement dynamique (c’est-à-dire, difficile à mettre à jour). Les clients ne découvrent que les services qui sont en fait actifs avec SLP. De plus, si à la suite d’une découverte initiale un serveur a une défaillance, le client peut relancer une interrogation SLP et obtenir un nouveau serveur. Du côté du serveur, aucune base de données ne doit être mise à jour pour fournir la découverte dynamique  ; les serveurs s’annoncent eux-mêmes.

2.	SLP n’exige pas de configuration par un tiers. Seul le serveur qui offre le service et le client qui le cherche sont obligés de connaître les détails de ce type de service particulier.

3.	SLP permet aux clients de spécifier les attributs qui décrivent le serveur désiré. Un client découvre les serveurs qui satisfont un ensemble d’exigences spécifiques. Cela réduit la quantité de trafic réseau impliqué dans le choix d’un serveur lorsque le nombre de choix possibles est grand.

4.	SLP contient un certain nombre de mécanismes d’adaptation (les DA, les portées, l’algorithme de convergence de diffusion groupée) qui facilitent le déploiement dans les grands réseaux d’entreprise tout comme dans de plus petits réseaux.

5.	Utilisation des portées pour l’approvisionnement de serveur

Une caractéristique particulière de la conception de SLP qui est utile pour RSIP est la portée. Les portées dans SLP sont un mécanisme pour fournir l’accès à des annonces de services particuliers. Un administrateur alloue des UA et des SA à des portées particulières pour assurer que les UA ne trouvent des SA que dans ces portées. Les portées ne sont cependant pas un mécanisme de contrôle d’accès pour le service lui-même. Les UA de l’extérieur de la portée peuvent quand même accéder aux services dans une portée particulière (sauf si le service lui-même assure le contrôle d’accès) ils ne seront simplement pas capables de trouver les services en utilisant SLP.

Les portées sont utiles pour la fourniture des annonces de service RSIP parce que elles permettent à un administrateur de système de lier des clients RSIP particuliers à des serveurs RSIP spécifiques. Par exemple, si on considère l’architecture de réseau décrite au paragraphe 4.2.1 de [7]. Il est recommandé aux clients RSIP de trouver le serveur RSIP "le plus proche", mais on ne spécifie pas exactement comment cela devrait être fait. SLP fournit un moyen pour que les administrateurs de système spécifient précisément dans quel domaine réside un client RSIP, en liant le domaine à une portée SLP. Le diagramme du paragraphe 14.1 de la RFC3102 est reproduit ici, avec les portées SLP incluses pour illustrer comment les clients pourraient être dirigés sur les bons serveurs RSIP.

                                +-----------+
                                |           |
                                |  Serveur  |
                                |   RSIP    +---- 10.0.0.0/8
                                |     B     |   Portée SLP : B
                                |           |
                                +-----+-----+
                                      |
                                      | 10.0.1.0/24
                       +-----------+  | (149.112.240.0/25)
                       |           |  |
       149.112.240.0/24|   Serveur +--+
       ----------------+    RSIP   |    Portée SLP : A
                       |      A    +--+
                       |           |  |
                       +-----------+  | 10.0.2.0/24
                                      | (149.112.240.128/25)
                                      |
                                +-----+-----+
                                |           |
                                |  Serveur  |
                                |   RSIP    +---- 10.0.0.0/8
                                |     C     |    Portée SLP : C
                                |           |
                                +-----------+

Les clients sur le réseau 10.0.0.0/8 du haut sont configurés à utiliser la portée SLP B, tandis que les clients sur le réseau 10.0.0.0/8 du bas sont configurés à utiliser la portée SLP C. Les serveurs RSIP B et C (comme clients du serveur A) utilisent SLP pour localiser le serveur RSIP A, comme le font les autres clients RSIP sur les sous-réseaux 10.0.1.0/24 et 10.0.2.0/24. Au sein de ces deux sous-réseaux, tous les clients ont leur portées configurées pour être A.

Noter que spécifier une portée SLP particulière pour les clients RSIP ne restreint pas la portée SLP pour les autres services annoncés par SLP. Les UA SLP peuvent être configurés pour plusieurs portées, de sorte que la portée configurée pour l’impression peut être différente de la portée configurée pour le service RSIP.

Comme les portées SLP sont configurées à travers une option DHCP [8], ainsi qu’avec l’adresse IP, les administrateurs de système peuvent facilement commuter une grappe d’une machine d’un domaine à un autre en changeant simplement l’allocation de la portée et de l’adresse IP sur le serveur DHCP. Par exemple, dans l’architecture ci-dessus, supposons qu’un administrateur du système veuille retirer le serveur RSIP B afin que les clients qui sont sur le sous-réseau 10.0.0.0/8 soient directement sur le sous-réseau 10.0.1.0/24. Ces clients communiquent maintenant avec le serveur RSIP A. En changeant simplement les allocations d’adresse et la configuration de la portée de ces clients sur le serveur DHCP, on peut effectivement changer le domaine.

6.	Équilibrage de charge

Bien que par lui-même SLP ne contienne aucune disposition spécifique pour l’équilibrage de charge, celui-ci peut facilement être mis en œuvre en utilisant SLP. La seule exigence est que le gabarit de type de service spécifie un attribut indiquant la charge du serveur. Dans le cas de RSIP, le gabarit de type de service de la Section 7 contient un tel attribut. L’attribut indique le nombre de sessions client RSIP actuellement prises en charge par le serveur.

Afin de réaliser l’équilibrage de charge, le serveur RSIP doit mettre à jour périodiquement son annonce de service lorsque de nouvelles connexions sont acceptées. Un client RSIP qui cherche à trouver le serveur qui a la plus forte charge effectue la série d’opérations SLP suivantes.

1.	Comme à la Section 4, le client produit une demande de service SLP et collecte tous les URL de service retournés.

2.	Pour chaque URL de service, le client effectue une demande d’attribut SLP pour l’attribut LOAD. Les valeurs entières de charge sont retournées.

3.	Le client trie les chiffres de charge retournés et choisit l’URL qui a le moindre nombre de connexions. Le client établit sa session RSIP avec ce serveur.

À cause des délais du réseau, cette procédure ne garantit pas qu’un client va toujours obtenir une connexion avec le serveur le plus légèrement chargé, mais cela donne une forte probabilité que le serveur choisi ait une charge plus légère.

Une procédure similaire est utilisée dans [9] pour équilibrer la charge d’accès aux serveurs telnet TN3270E.

7.	Gabarit de type de service RSIP

Nom des soumettants :	James Kempf <james@docomolabs-usa.com>
	Gabriel Montenegro <gab@sun.com>

 Langage du gabarit de service : fr

Considérations de sécurité :
Les clients RSIP peuvent utiliser le protocole de localisation de service pour trouver les serveurs RSIP qui ont des caractéristiques de sécurité particulières. Si l’accès sécurisé à de telles informations est requis, la sécurité SLP devrait être utilisée.

Texte du gabarit :
----------------------Le gabarit commence ici -------------------------
type-de-gabarit = rsip

version-de-gabarit = 0.0

description-du-gabarit=
Le type service:rsip fournit des annonces pour les clients qui cherchent des serveurs IP spécifiques d’un domaine (RSIP). Les serveurs RSIP utilisent le protocole IP spécifique de domaine pour gérer les adresses et autres ressources d’un domaine au nom d’un client dans un autre domaine.

gabarit-de-syntaxe-d’URL=
; Aucune informations supplémentaires de chemin d’URL requises. Un exemple d’URL de service
; pour un serveur RSIP est : service:rsip://gateway.mydomain:4455

prise-en-charge-de-IPsec = BOOLÉEN O
#Vrai si le serveur prend en charge IPsec selon [10]

prise-en-charge-de-ike = BOOLÉEN O
#Vrai si le serveur prend en charge IKE selon [10]

type-tunnel = CHAINE L M O
IP-IP
# Les méthodes de tunnelage prises en charge par le serveur RSIP. Les clients devraient inclure cet attribut dans une interrogation afin qu’ils obtiennent un serveur offrant une méthode de tunnelage qu’ils prennent en charge. La valeur par défaut est IP-IP. Les valeurs sont actuellement restreintes à IP-IP, L2TP, GRE et AUCUNE. Un serveur peut prendre en charge plusieurs types de tunnel.
IP-IP,L2TP,GRE,AUCUNE

transport = CHAINE L M O
TCP
# C’est le transport utilisé par le protocole RSIP lui-même.
TCP,UDP

charge = ENTIER O
# Si le serveur prend en charge l’équilibrage de charge, cet attribut devrait être réglé à un entier de 0 à 100. 0 est la plus faible indication de charge et 100 la plus forte. Les clients peuvent demander cet attribut et obtenir les informations de charge, à partir de quoi ils peuvent prendre des décisions intelligentes sur le serveur à utiliser.
----------------------Le gabarit se termine ici---------------------

8.	Considérations pour la sécurité

Les gabarits de type de service fournissent des informations qui sont utilisées pour interpréter les informations obtenues par les clients au moyen de SLP. Si le gabarit RSIP est modifié ou si un faux gabarit est distribué, les serveurs RSIP peuvent ne pas s’enregistrer correctement, ou les clients RSIP peuvent n’être pas capables d’interpréter les informations de service.

SLP fournit un mécanisme d’authentification pour que les UA s’assurent que les annonces de service ne viennent que de SA de confiance [2]. Si la confiance est un problème, en  particulier par rapport aux informations recherchées par le client sur la prise en charge de IPsec et de IKE, alors l’authentification SLP devrait être activée dans le réseau.

9.	Résumé

Le présent document décrit comment SLP peut être utilisé par les clients RSIP pour trouver les serveurs RSIP. Un gabarit de type de service pour un type de service SLP RSIP est présenté. De plus, sont données quelques techniques pour fournir l’accès aux annonces de service pour les serveurs passerelle particuliers, et pour l’équilibrage de charge à l’aide de SLP. Le résultat devrait permettre la fourniture du service RSIP qui est considérablement plus dynamique et robuste que lorsque sont utilisés les mécanismes traditionnels de découverte de service.

Références

[1]	[RFC3103] M. Borella et autres, "IP spécifique de domaine : Spécification du protocole", octobre 2001. (Exp.)

[2]	[RFC2608] E. Guttman et autres, "Protocole de localisation de service, version 2", juin 1999. (MàJ par RFC3224) (P.S.)

[3]	[RFC2609] E. Guttman, C. Perkins, J. Kempf, "Schémas service: et gabarits de service", juin 1999. (P.S.)

[4]	[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars  1997.

[5]	[RFC2052] A. Gulbrandsen, P. Vixie, "Enregistrement DNS pour spécifier la localisation de services (DNS SRV)", octobre 1996. (Obsolète, voir RFC2782) (Expérimentale)

[6]	[RFC2131] R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (Màj par RFC3396 et 4361)

[7]	[RFC3102] M. Borella et autres, "IP spécifique de domaine : le cadre", octobre 2001. (Expérimentale)

[8]	[RFC2610] C. Perkins, E. Guttman, "Options DHCP pour le protocole de localisation de service", juin 1999. (P.S.)

[9]	[RFC3049] J. Naugle et autres, "Localisation de service et équilibrage de session TN3270E", janvier 2001. (P.S.)

[10]	[RFC3104] G. Montenegro, M. Borella, "Prise en charge par RSIP d'IPsec de bout en bout", octobre 2001. (Exp.)

[11]	E. Guttman, "Service Location Protocol: Automatic Discovery of IP Network Services," IEEE Internet Computing, Juillet/août 1999. Disponible à : http://computer.org/internet/ic1999/w4toc.htm 

Adresse des auteurs

Les questions sur le présent document peuvent être adressées à :

James Kempf	Gabriel E. Montenegro	
NTT DoCoMo USA Labs	Sun Microsystems	
181 Metro Drive, Suite 300	Laboratories, Europe	
San Jose, CA	29, chemin du Vieux Chene	
95110	38240 Meylan	
téléphone : 408-451-4711	France	
mél : james@docomolabs-usa.com 	téléphone : +33 476 18 80 45	
	mél : gab@sun.com 	

Déclaration complète de droits de reproduction

Copyright (c) The Internet Society (1999). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent et paragraphe soient inclus dans toutes les copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society, ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.