Groupe de travail Réseau	J. Luciani, Bay Networks	
Request for Comments : 2335	avril 1998	
Catégorie : Sur la voie de la normalisation 	Traduction Claude Brière de L'Isle	

Service NHRP réparti utilisant SCSP

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

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

Résumé
Le présent document décrit une méthode pour distribuer un service de résolution du prochain bond multi accès sans diffusion (NBMA, non-broadcast multi-access) (NHRP, NBMA Next Hop Resolution) au sein d'un sous-réseau logiquement indépendant (LIS, Logically Independent Subnet) [RFC2332]. Cette méthode utilise le protocole de synchronisation d'antémémoire de serveur (SCSP, Server Cache Synchronization Protocol) [RFC2334] pour synchroniser les bases de données d'information de client détenues par les serveurs NHRP (NHS, serveur NHRP) au sein d'un LIS.
Table des matières
1. Introduction	1
2. Vue d'ensemble	2
3. Format de la partie spécifique NHRP d'enregistrement CSA	2
4. Valeurs pour la partie indépendante du protocole SCSP	4
4.1 Valeurs pour la "partie commune obligatoire" de SCSP	4
4.2 Valeurs pour "l'enregistrement CSAS" de SCSP	4
5. Considérations sur la sécurité	4
Références	4
Remerciements	4
Adresse de l'auteur	4
Déclaration complète de droits de reproduction	5

 	1.	Introduction

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

Les clients NHRP (NHC, NHRP Client) enregistrent leur existence et les informations d'accessibilité auprès des serveurs NHRP. Il peut y avoir plusieurs NHS dans un certain sous réseau IP logique (LIS, Logical IP Subnet). Les NHC ne s'enregistrent pas nécessairement auprès de tous les NHS dans un LIS ; cependant, tous les NHC doivent être capables d'interroger au moins un NHS sur tout NHC dans le LIS. Donc, le contenu des bases de données NHS dans un LIS doit être synchronisé à travers le LIS. Le protocole de synchronisation d'antémémoire de serveur (SCSP) résout le problème généralisé de synchronisation de serveur/duplication d'antémémoire pour les bases de données réparties et donc SCSP peut être appliqué au problème de la synchronisation de base de données de NHS au sein du LIS.

SCSP est défini en deux parties : la partie indépendante du protocole et la partie spécifique du protocole client/serveur. La partie indépendante du protocole est définie dans la [RFC2334] tandis que le présent document spécifie la partie spécifique du protocole client/serveur où NHRP est le protocole client/serveur.

Le présent document est séparé de la [RFC2334] parce qu'on a estimé qu'il était souhaitable de permettre que la spécification de la partie spécifique du protocole client/serveur pour NHRP progresse indépendamment de la spécification indépendante du protocole.

 	2.	Vue d'ensemble

Tous les NHS qui appartiennent à un sous réseau IP logique (LIS, Logical IP Subnet) [RFC2332] sont dits appartenir à un groupe serveur (SG, Server Group). Un SG est identifié, sans surprise, par son identifiant de SG (SGID) qui est contenu dans un champ dans tous les paquets SCSP. Tous les paquets SCSP contiennent aussi un champ Identifiant de protocole (PID, Protocol ID). Ce champ PID est réglé à 0x0002 pour signifier que SCSP synchronise les bases de données de NHS par opposition à synchroniser des bases de données d'autres protocoles (voir au paragraphe B.2.0.1 de la [RFC2334] pour les détails). En général, les PID pour SCSP vont être alloués par l'IANA comme décrit à la Section C de la [RFC2334]. Dans le cas de NHRP, la spécification spécifique du protocole client/serveur a été écrite initialement en même temps que SCSP, et donc un PID=0x0002 a été alloué par l'auteur.

SCSP ne fixe pas d'exigence topologique pour un SG NHRP. Évidemment, le graphe résultant des NHS doit cependant s'étendre sur l'ensemble des NHS à synchroniser. Pour plus d'informations sur la partie indépendante du protocole client/serveur de SCSP, le lecteur est invité à voir la [RFC2334].

Quand un SG utilise SCSP pour la synchronisation, un NHC va s'enregistrer auprès d'un seul NHS, mais le NHC PEUT utiliser tout NHS dans le SG. Quand un NHC souhaite quitter un SG, il DOIT faire une des choses suivantes : 1) le NHC DOIT envoyer une demande de purge de NHRP pour lui-même en demandant une réponse, et il DOIT attendre une réponse de purge de NHRP, 2) le NHC DOIT garder l'identifiant de demande qu'il a utilisé lors de son enregistrement dans une RAM non volatile et utiliser un identifiant de demande plus grand que celui sauvegardé lors du réenregistrement, ou 3) le NHC NE DOIT PAS se réenregistrer pendant un délai égal au temps de garde spécifié dans l'enregistrement précédent. Il est nécessaire de faire une des actions ci-dessus afin d'empêcher le cas improbable de concurrence de se produire durant une mise à jour. Dans le cas d'utilisation de la méthode 2, le NHS auprès duquel le NHC s'est enregistré utilise son identifiant comme OID et l'identifiant de demande provenant du NHC comme numéro de séquence d'annonce d'état d'antémémoire (CSA, Cache State Advertisement) dans l'enregistrement CSA(S).

 	3.	Format de la partie spécifique NHRP d'enregistrement CSA

Les enregistrements CSA dans SCSP contiennent une "partie spécifique de protocole client/serveur" qui contient les informations non indépendantes de protocole pour l'entrée d'antémémoire d'un certain serveur.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Numéro de famille d'adresses |  Type de protocole NHRP       |
+---------------+---------------+---------------+---------------+
|                             Snap                              |
+---------------+---------------+---------------+---------------+
|     Snap      | Num vers NHRP |            Fanions            |
+---------------+---------------+---------------+---------------+
|                      Identifiant de demande                   |
+---------------+---------------+---------------+---------------+
|    État       | Long. préfixe |         non utilisé           |
+---------------+---------------+---------------+---------------+
| Unité de transmission maximum |       Temps de garde          |
+---------------+---------------+---------------+---------------+
| T/L adr client| T/L s.adr cl. |Lg proto client|  Préférence   |
+---------------+---------------+---------------+---------------+
|          Adresse de sous réseau client (longueur variable)    |
+---------------+---------------+---------------+---------------+
|     Sous adresse de sous réseau client (longueur variable)    |
+---------------+---------------+---------------+---------------+
|        Adresse de protocole client (longueur variable)        |
+---------------+---------------+---------------+---------------+

Les six champs suivants contiennent les valeurs spécifiées dans l'en-tête commun de la partie obligatoire d'un paquet de demande d'enregistrement NHRP ou demande de purge NHRP qui a causé la création/suppression/modification/mise à jour /etc. d'une entrée d'antémémoire du NHS.

Numéro de famille d'adresses :  définit le type des adresses de "couche de liaison" qui sont portées. Ce numéro est pris dans la liste des "numéros de famille d'adresses' spécifiée dans la [RFC1700]. Ce champ est le même que celui qui serait fourni dans le champ ar$afn dans un paquet NHRP.

Type de protocole NHRP : ce champ est le même que celui qui serait fourni dans le champ ar$pro.type dans un paquet NHRP.

Snap  : ce champ est le même que celui qui serait fourni dans le champ ar$pro.snap dans un paquet NHRP.

Num vers NHRP : ce champ indique quelle version de protocole générique de transposition et gestion d'adresses est représentée dans ce message. Ce champ contient 0x01 pour la version 1 du protocole NHRP. Ce champ est le même que celui qui serait fourni dans le champ ar$op.version dans un paquet NHRP.

Fanions  : les fanions définis sont les suivants :

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|A|      non utilisé          |
+-+-+-----------+---------------+

U : c'est le bit Unicité.
A : Établi à 1, ce bit spécifie que l'entrée d'antémémoire a été créée par suite d'une interaction de client ATMARP avec le NHS.

Identifiant de demande  : ce champ contient la valeur d'identifiant de demande placée dans l'entrée d'antémémoire du NHS par suite d'une demande d'enregistrement NHRP. Ce NHS est celui qui cause un événement de synchronisation.

État  : ce champ contient une valeur qui représente le nouvel état du client.
0 - Client enregistré et disponible.
1 - Client réenregistré.
2 - Client purgé.
3 – Pas ces données de client dans l'antémémoire du serveur.

Noter qu'une fin de temporisation d'une entrée d'antémémoire ne cause pas l'envoi d'un enregistrement CSA parce que, si tout fonctionne correctement, alors tous les NHS ont leur entrée d'antémémoire qui arrive en fin de temporisation au même moment. Donc, les NHS individuels vont effectuer les actions nécessaires appropriées.

Les dix champs suivants contiennent les valeurs spécifiées dans ou déduites de l'entrée d'informations client (CIE, Client Information Entry) d'un paquet Demande d'enregistrement NHRP ou Demande de purge NHRP qui a causé la création/suppression/modification/mise à jour /etc. d'une entrée d'antémémoire du NHS.

Longueur de préfixe  : ce champ contient la valeur de la longueur du préfixe d'adresse de couche inter réseau couverte par l'entrée d'antémémoire en train d'être synchronisée.

Unité maximum de transmission : ce champ contient une valeur fournie par ou déduite des informations dans la CIE du paquet Demande d'enregistrement NHRP.

Temps de garde  : le champ Temps de garde spécifie le nombre de secondes restantes pendant lequel les informations de prochain bond NBMA spécifiées dans la CIE de la demande d'enregistrement NHRP sont considérées être valides par le NHS qui initie l'événement de synchronisation.

T/L adresse client  : Type & longueur de l'adresse du prochain bond NBMA (voir la [RFC2332]).

T/L  sous adresse client : Type & longueur de la sous adresse du prochain bond NBMA (voir la [RFC2332]).

Lg proto client   : ce champ contient la longueur en octets de l'adresse du protocole client.

Préférence  : ce champ spécifie la valeur de préférence à utiliser pour les informations de prochain bond NBMA spécifiées.

Adresse de sous réseau client  : c'est l'adresse NBMA du client.

Sous adresse de sous réseau client  : c'est la sous adresse NBMA du client..

Adresse de protocole client : c'est l'adresse de couche inter réseautage du client.

 	4.	Valeurs pour la partie indépendante du protocole SCSP

Les paragraphes qui suivent donnent les valeurs des champs de la partie indépendante du protocole SCSP des divers messages SCSP.

 	4.1	Valeurs pour la "partie commune obligatoire" de SCSP
Identifiant de protocole = 0x0002
Longueur d'identifiant de l'envoyeur = 0x04
Longueur d'identifiant de receveur = 0x04

Voir au paragraphe B.2.0.1 de la [RFC2334] la description détaillée de ces champs.

 	4.2	Valeurs pour "l'enregistrement CSAS" de SCSP
Longueur de clé d'antémémoire = 0x04
Longueur d'identifiant d'origine = 0x04

Voir au paragraphe B.2.0.2 de la [RFC2334] la description détaillée de ces champs.

 	5.	Considérations sur la sécurité

Les considérations petinentes sur la sécurité sont documentées dans les [RFC2332] et [RFC2334].

 	Références

[RFC1700]	J. Reynolds et J. Postel, "Numéros alloués", STD 2, octobre 1994. (Historique, voir www.iana.org))

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

[RFC2332]	J. Luciani et autres, "Protocole de résolution du prochain bond NBMA (NHRP)", avril 1998. (P.S.)

[RFC2334]	J. Luciani et autres, "Protocole de synchronisation d'antémémoire de serveur (SCSP) - NBMA", avril 1998. (P.S.)

 	Remerciements

Je tiens à remercier (sans ordre particulier) Maxine Burns de ISR et Joel Halpern de Newbridge. Merci aussi aux membres du groupe de travail ION de l'IETF, dont la relecture et la discussion de ce document a été précieuse.

 	Adresse de l'auteur
James V. Luciani
Bay Networks, Inc.
3 Federal Street, BL3-03
Billerica, MA  01821
USA
téléphone : +1-978-916-4734
mél : luciani@baynetworks.com 

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1998). 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 paragraphe soient inclus dans toutes telles 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 ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.