Groupe de travail Réseau |
J. Luciani, Bay Networks |
Request for Comments : 2332 |
D. Katz, cisco Systems |
Catégorie : En cours de normalisation |
D. Piscitello, Core Competence, Inc. |
|
B. Cole, Juniper Networks |
|
N. Doraswamy, Bay Networks |
Traduction Claude Brière de L'Isle |
avril 1998 |
Protocole NBMA de résolution du prochain bond (NHRP)
Statut de ce mémoire
Le présent document spécifie une proposition de norme de protocole 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 courante de "Normes officielles de protocoles de l'Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.
Notice de droits d'auteur
Copyright (C) The Internet Society (1998). Tous droits réservés.
Résumé
Le présent document décrit le protocole NBMA de résolution du prochain bond (NHRP, NBMA Next Hop Resolution Protocol). NHRP peut être utilisé par une station source (hôte ou routeur) connectée à un sous-réseau multi accès en non diffusion (NBMA, Non-Broadcast, Multi-Access) pour déterminer l'adresse de couche inter réseau et les adresses de sous-réseau NBMA du "prochain bond NBMA" vers une station de destination. Si la destination est connectée au sous-réseau NBMA, le prochain bond NBMA est alors la station de destination elle-même. Autrement, le prochain bond NBMA est le routeur de sortie du sous-réseau NBMA qui est le "plus proche" de la station de destination. NHRP est destiné à une utilisation dans un environnement de couche inter-réseau multi protocole sur des sous-réseaux NBMA.
Noter que alors que ce protocole a été développé pour être utilisé avec des sous-réseaux NBMA, il est possible, sinon vraisemblable, qu'il sera aussi appliqué à des sous-réseaux BMA. Cependant, cet usage de NHRP devra faire l'objet d'un complément d'étude.
Le présent document est destiné à être un surensemble fonctionnel du protocole NBMA de résolution d'adresse (NARP) documenté dans [1].
Le fonctionnement de NHRP comme moyen d'établir un chemin de transit à travers un sous-réseau NBMA entre deux routeurs sera traité dans un autre document (voir [13]).
Table des Matières
2.2 Généralités sur le protocole
5.2.1 Demande de résolution NHRP
5.2.2 Réponse de résolution NHRP
5.2.3 Demande d'enregistrement NHRP
5.2.4 Réponse d'enregistrement NHRP
5.2.7 Indication d'erreur NHRP
5.3.1 Extension d'adresse du répondant
5.3.2 Extension d'enregistrement NHS de transit de transmission NHRP
5.3.3 Extension d'enregistrement NHS de transit inverse NHRP
5.3.4 Extension d'authentification NHRP
6. Fonctionnement du protocole
6.1 Fonctionnement de routeur à routeur
6.2 Problème de la gestion des antémémoires
6.2.1 Exigences de la mise en antémémoire
6.2.2 Dynamique des informations mises en antémémoire
6.3 Utilisation du champ Longueur de préfixe d'un CIE
7. NHRP sur les réseaux BMA traditionnels
Déclaration complète de droits de reproduction
Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans [15].
Le protocole NBMA de résolution du prochain bond (NHRP, Next Hop Resolution Protocol) permet à une station source (hôte ou routeur), qui souhaite communiquer sur un sous-réseau de non diffusion, multi accès (NBMA, Non-Broadcast, Multi-Access) de déterminer les adresses de couche d'inter-réseautage et les adresses NBMA des "prochains bonds NBMA" convenables vers une station de destination. Un sous-réseau peut être en non diffusion parce qu'il ne prend pas techniquement en charge la diffusion (par exemple, un sous-réseau X.25) ou parce que la diffusion n'est pas praticable pour une raison ou pour une autre (par exemple, un groupe SMDS de diffusion groupée ou un Ethernet étendu serait trop grand). Si la destination est connectée au sous-réseau NBMA, le prochain bond NBMA est alors la station de destination elle-même. Autrement, le prochain bond NBMA est le routeur de sortie du sous-réseau NBMA qui est le "plus proche" de la station de destination.
Une façon de modéliser un réseau NBMA est d'utiliser la notion de sous-réseaux IP logiquement indépendants (LIS, logically independent subnetwork). Les LIS, tels que définis dans [3] et [4], ont les propriétés suivantes :
1) Tous les membres d'un LIS ont le même numéro de réseau/sous-réseau IP et le même gabarit d'adresse.
2) Tous les membres d'un LIS sont directement connectés au même sous-réseau NBMA.
3) Tous les hôtes et routeurs en-dehors du LIS sont accédés via un routeur.
4) Tous les membres d'un LIS accèdent les un aux autres directement (sans routeurs).
La résolution d'adresse telle que décrite dans [3] et [4] ne résout l'adresse de prochain bond que si la station de destination est un membre du même LIS que la station de source ; autrement, la station de source doit transmettre les paquets à un routeur qui est un membre de plusieurs LIS. Dans les configurations multi-LIS, la résolution d'adresse bond par bond peut n'être pas suffisante pour résoudre le "prochain bond NBMA" vers la station de destination, et les paquets IP peuvent avoir plusieurs bonds IP à travers le sous-réseau NBMA.
Une autre façon de modéliser NBMA est d'utiliser la notion de groupe d'adresses locales (LAG, Local Address Group) [10]. La différence essentielle entre les modèles LIS et LAG est que alors que dans le modèle LIS le résultat de la décision de transmission "locale/distante" est conduit purement par les informations d'adressage, avec le modèle LAG le résultat de cette décision est découplé des informations d'adressage et est couplé avec les caractéristiques de qualité de service et/ou de trafic. Avec le modèle LAG deux entités quelconques sur un réseau NBMA commun pourront établir une communication directe l'une avec l'autre, sans considération des adresses des entités.
La prise en charge du modèle LAG suppose l'existence d'un mécanisme qui permet à toute entité (c'est-à-dire, hôte ou routeur) connectée à un réseau NBMA de résoudre une adresse de couche inter réseautage en une adresse NBMA pour toute autre entité connectée au même réseau NBMA. Cette résolution aura lieu sans considération des allocations d'adresse à ces entités. Au sein des paramètres décrits dans le présent document, NHRP décrit un tel mécanisme. Par exemple, lorsque l'adresse de couche inter réseautage est de type IP, une fois que le prochain bond NBMA a été résolu, la source peut soit commencer à envoyer des paquets IP à la destination (dans un sous-réseau NBMA sans connexion tel que SMDS) soit établir d'abord une connexion avec la destination avec la bande passante désirée (dans un sous-réseau NBMA orienté connexion tel que ATM).
L'utilisation de NHRP peut être suffisante pour les hôtes qui font de la résolution d'adresse lorsque ces hôtes sont directement connectés à un sous-réseau NBMA, ce qui permet des mises en œuvre directes dans les stations NBMA. NHRP a aussi la capacité de déterminer le point de sortie d'un sous-réseau NBMA lorsque la destination n'est pas directement connectée au sous-réseau NBMA et que l'identité du routeur de sortie n'est pas apprise par d'autres méthodes (comme des protocoles d'acheminement). Des extensions facultatives à NHRP fournissent une robustesse et une capacité de diagnostic supplémentaires.
Des techniques de résolution d'adresse telles que décrites dans [3] et [4] peuvent être utilisées lorsque NHRP est déployé. Des serveurs et services ARP sur des sous-réseaux NBMA peuvent être nécessaires pour prendre en charge des hôtes qui ne sont pas capables de traiter d'autre modèle de communication que le modèle LIS, et les hôtes en place peuvent ne pas mettre en œuvre NHRP mais peuvent continuer de prendre en charge des variantes de ARP telles que celles décrites dans [3] et [4]. NHRP est destiné à réduire ou éliminer les bonds supplémentaires de routeur requis par le modèle LIS, et peut être déployé sans interférence avec les services ARP existants [14].
Le fonctionnement de NHRP pour établir des chemins de transit à travers des sous-réseaux NBMA entre deux routeurs exige des mécanismes supplémentaires pour éviter des boucles d'acheminement stables, et sera décrit dans un document distinct (voir [13]).
Le terme "réseau" est trop galvaudé et il prête particulièrement à confusion dans le contexte de NHRP. Nous utilisons les termes suivants :
Couche d'inter réseautage – c'est la couche indépendante du support (IP dans le cas des réseaux TCP/IP).
Couche de sous-réseau – c'est la couche qui dépend du support et est sous-jacente à la couche d'inter réseautage, y compris la technologie NBMA (ATM, X.25, SMDS, etc.)
Le terme "serveur", sauf mention contraire explicite, se réfère à un serveur de prochain bond (NHS, Next Hop Server). Un NHS est une entité qui effectue le service du protocole de résolution du prochain bond au sein du nuage NBMA. Un NHS est toujours étroitement couplé à une entité d'acheminement (routeur, serveur d'acheminement ou appareil de bordure) bine que l'inverse ne soit pas garanti car des développements omniprésents de cette fonctionnalité se produisent. Noter que la présence de routeurs intermédiaires qui ne sont pas couplés à une entité NHS peuvent empêcher l'utilisation de NHRP lorsque des stations de source et de destination sont sur des côtés différents de tels routeurs et donc de tels routeurs peuvent partager l'accessibilité à NHRP au sein d'un réseau NBMA.
Le terme "client", sauf mention contraire explicite, se réfère à un client de protocole de résolution du prochain bond (NHC, Next Hop Resolution Protocol Client). Un NHC est une entité qui initie des demandes NHRP de divers types afin d'obtenir l'accès au service NHRP.
Le terme "station" se réfère généralement à un hôte ou routeur qui contient une entité NHRP. À l'occasion, le terme station va décrire un "usager" du client NHRP ou de la fonctionnalité de service ; la différence d'usage est surtout sémantique.
2.2 Généralités sur le protocole
Dans cette section, on décrit brièvement comment une source S (qui peut être un routeur ou un hôte) utilise NHRP pour déterminer le "prochain bond NBMA" pour la destination D.
Pour des raisons administratives et de politique, un sous-réseau physique NBMA peut être partagé en plusieurs "sous-réseaux NBMA logiques" disjoints. Un sous-réseau NBMA logique est défini comme une collection d'hôtes et de routeurs qui partagent une connexité de sous-réseau non filtrée sur un sous-réseau NBMA. "Connexité de sous-réseau non filtrée" se réfère à l'absence de groupes fermés d'usagers, d'affichage d'adresse ou de dispositifs similaires qui peuvent être utilisés pour empêcher la communication directe entre des stations connectées au même sous-réseau NBMA. (Ci-après, sauf spécification contraire, on utilise le terme "sous-réseau NBMA" pour signifier sous-réseau NBMA *logique*.)
Placées au sein du sous-réseau NBMA se trouvent une ou plusieurs entités qui mettent en œuvre le protocole NHRP. De telles stations qui sont capables de répondre aux demandes de résolution NHRP sont appelées "serveurs de prochain bond " NHS, Next Hop Servers). Chaque NHS dessert un ensemble d'hôtes de destination, qui peuvent être directement connectés ou non au sous-réseau NBMA. Les NHS résolvent de façon coopérative le prochain bond NBMA au sein de leur sous-réseau logique NBMA. En plus de NHRP, les NHS peuvent prendre en charge le service ARP "classique" ; cependant, ceci fera l'objet d'un autre document [14].
Un NHS entretient une antémémoire qui contient les informations de résolution d'adresse de l'adresse de la couche de protocole en couche de sous-réseau NBMA. Cette antémémoire peut être construite à partir des informations obtenues des paquets Register de NHRP (voir aux paragraphes 5.2.3 et 5.2.4), à partir des paquets de demande/réponse de résolution NHRP, ou à partir de mécanismes qui sortent du domaine d'application du présent document (des exemples de tels mécanismes pourraient inclure ARP [3] et des tableaux préconfigurés). Le paragraphe 6.2 décrit plus en détails les questions de gestion d'antémémoire.
Pour qu'une station au sein d'un LIS donné évite de fournir la fonction NHS, il doit y avoir un ou plusieurs NHS au sein du sous-réseau NBMA qui fournissent les informations de résolution d'adresse d'autorité en son nom. Un tel NHS est dit "servir" la station. Une station sur un LIS qui n'a pas la fonction NHS et est un client du service NHRP est appelée client NHRP ou simplement NHC. Si un NHS servant doit être capable de fournie les informations de résolution d'adresse pour un NHC, il doit alors exister des NHS à chaque bond le long de tous les chemins entre le NHC qui fait la demande de résolution et le NHC de destination. La dernière entité NHRP le long du chemin est le NHS servant ; c'est-à-dire que les demandes de résolution NHRP ne sont pas transmises aux NHC de destination mais sont plutôt traitées par le NHS servant.
Un NHC entretient aussi une antémémoire des informations de résolution d'adresse d'adresse de protocole en NBMA. Cette antémémoire est remplie avec les informations obtenues des paquets de réponse de résolution NHRP, de la configuration manuelle, ou par des mécanismes qui sortent du domaine d'application du présent document.
Le protocole procède comme suit. Un événement survient qui déclanche le fait que la station S veut résoudre l'adresse NBMA d'un chemin vers D. Cela va très vraisemblablement se produire quand un paquet de données adressé à la station D va être émis à partir de la station S (soit parce que la station S est un hôte, soit que la station S est un routeur de transit), mais la résolution d'adresse pourrait aussi être déclanchée par d'autres moyens (un paquet de mise à jour de protocole d'acheminement, par exemple). La station S détermine d'abord le prochain bond pour la station D par le traitement d'acheminement normal (pour un hôte, le prochain bond peut être simplement le routeur par défaut ; pour les routeurs, c'est le "prochain bond" vers l'adresse de couche inter-réseau de destination ). Si les informations de résolution d'adresse de la destination sont déjà disponibles dans l'antémémoire de S, ces informations sont alors utilisées pour transmettre le paquet. Autrement, si le prochain bond est accessible par une de ses interfaces NBMA, S construit un paquet de demande de résolution NHRP (voir au paragraphe 5.2.1) contenant l'adresse de couche inter-réseau de la station D comme adresse de destination (cible), la propre adresse de couche inter-réseau de S comme adresse de source (initiateur de la demande de résolution du prochain bond), et les informations d'adressage NBMA de la station S. La station S peut aussi indiquer qu'elle préfère une réponse de résolution NHRP d'autorité (c'est-à-dire que la station S souhaite ne recevoir de réponse de résolution NHRP que d'un NHS servant le NHC de destination). La station S émet le paquet de demande de résolution NHRP vers la destination.
Si la demande de résolution NHRP est déclanchée par un paquet de données, S peut alors, tout en attendant une réponse de résolution NHRP, choisir de disposer le paquet de données d'une des façons suivantes :
(a) abandonner le paquet,
(b) conserver le paquet jusqu'à ce qu'arrive la réponse de résolution NHRP et qu'un chemin plus optimal soit disponible,
(c) transmettre le paquet le long du chemin vers D.
Le choix de la solution à retenir parmi celles ci-dessus est affaire de politique locale, bien que l'option (c) soit celle recommandée par défaut,car elle peut permettre aux données de s'écouler vers la destination pendant que l'adresse NBMA est en cours de résolution. Noter qu'une demande de résolution NHRP pour une destination donnée NE DOIVENT PAS être déclanchée sur chaque paquet.
Lorsque le NHS reçoit une demande de résolution NHRP, il est fait une vérification pour savoir si elle dessert la station D. Si le NHS ne dessert pas D, le NHS transmet la demande de résolution NHRP à un autre NHS. Les mécanismes pour déterminer comment transmettre la demande de résolution NHRP sont exposés à la Section 3.
Si ce NHS dessert D, le NHS résout les informations d'adresse NBMA de la station D, et génère une réponse de résolution NHRP positive au nom de D. Dans ce scénario, les réponses de résolution NHRP sont toujours marquées comme "d'autorité". Le paquet de réponse de résolution NHRP contient les informations de résolution d'adresse pour la station D, qui doivent être renvoyées à S. Noter que si la station D n'est pas sur le sous-réseau NBMA, l'adresse de couche inter-réseau du prochain bond sera celle du routeur de sortie par lequel sont transmis les paquets pour la station D.
Un NHS de transit qui reçoit une réponse de résolution NHRP peut mettre en antémémoire les informations de résolution d'adresse qui y sont contenues. À une demande de résolution NHRP ultérieure, ce NHS peut répondre avec les informations de résolution d'adresse de l'antémémoire, "qui ne sont pas d'autorité" si il est permis au NHS de le faire (voir aux paragraphes 5.2.2 et 6.2 des informations complémentaires sur les réponses de résolution NHRP d'autorité et celles qui ne sont pas d'autorité). Les réponses de résolution NHRP qui ne sont pas d'autorité se distinguent des réponses de résolution NHRP d'autorité de telle sorte que si une tentative de communication fondée sur des informations qui ne sont pas d 'autorité échoue, une station de source peut choisir d'envoyer une demande de résolution NHRP d'autorité. Les NHS NE DOIVENT PAS répondre aux demandes de résolution NHRP d'autorité par des informations tirées de l'antémémoire.
Si il est déterminé qu'aucun NHS dans le sous-réseau NBMA ne peut répondre à la demande de résolution NHRP pour D, une réponse de résolution NHRP négative (NAK) est retournée. Cela survient lorsque : (a) aucune information de résolution de prochain bond n'est disponible pour la station D à partir d'aucun NHS, ou (b) un NHS est incapable de transmettre la demande de résolution NHRP (par exemple, la connexité est perdue).
Les demandes d'enregistrement NHRP, les demandes de purge NHRP, les réponses de purge NHRP et les indications d'erreur NHRP suivent un chemin déterminé de la même façon que le suivent les demandes de résolution NHRP et les réponses de résolution NHRP. Précisément, les "demandes" et les "indications" suivent le chemin déterminé à partir de l'adresse du protocole de source (qui est l'adresse de la station à l'initiative de la communication) vers l'adresse du protocole de destination. Les "réponses", par ailleurs, suivent le chemin déterminé de l'adresse de protocole de destination vers l'adresse de protocole de source avec les exceptions suivantes : dans le cas d'une réponse d'enregistrement NHRP et dans le cas d'une demande de purge NHRP initié par un NHC, le paquet est toujours retourné via un VC direct (voir aux paragraphes 5.2.4 et 5.2.5) ; si il n'en existe pas, il DOIT en être créé un.
Les demandes NHRP et les réponses NHRP NE traversent PAS les frontières d'un sous-réseau NBMA, cependant des études complémentaires sont effectuées dans ce domaine (voir la Section 7). Et donc, le trafic de données de la couche internet entrant et sortant d'un sous-réseau NBMA traverse toujours un routeur de couche internet à sa frontière.
NHRP fournit facultativement un mécanisme pour envoyer une réponse de résolution NHRP qui contient des informations de résolution d'adresse agrégées. Par exemple, supposons que le routeur X est le prochain bond de la station S vers la station D et que X est un routeur de sortie pour toutes les stations qui partagent un préfixe d'adresse de couche inter-réseau avec la station D. Lorsque une réponse de résolution NHRP est générée en réponse à une demande de résolution NHRP, celui qui répond peut augmenter l'adresse de couche inter-réseau de la station D d'une longueur de préfixe (voir au paragraphe 5.2.0.1). Une demande de résolution NHRP ultérieure (non d'autorité) pour une destination qui partage avec D un préfixe d'adresse de couche inter-réseau (pour le nombre de bits spécifié dans la longueur de préfixe) peut être satisfaite avec ces informations d'antémémoire. Voir le paragraphe 6.2 sur les questions de mise en antémémoire.
Pour détecter de façon dynamique le filtrage de couche sous-réseau dans les sous-réseaux NBMA (par exemple, une facilité de groupe fermé d'usager X.25, ou des écrans d'adresse SMDS) pour retracer le chemin déterminé que prend un paquet NHRP, ou pour fournir la détection de boucle et les capacités de diagnostic, un "Route Record" (enregistrement de chemin) peut être inclus dans les paquets NHRP (voir aux paragraphes 5.3.2 et 5.3.3). Les extensions Route Record sont l'extension d'enregistrement NHS de transit direct NHRP et l' extension d'enregistrement NHS de transit inverse NHRP. Elles contiennent les adresses de couche inter-réseau (et de couche de sous-réseau) de tous les NHS intermédiaires entre respectivement source et destination et entre destination et source. Lorsque une station source est incapable de communiquer avec celui qui répond (par exemple, échec d'une tentative d'ouverture d'un SVC) elle peut tenter de la faire successivement avec les autres adresses de couche de sous-réseau dans l'extension d'enregistrement NHS de transit direct NHRP jusqu'à ce qu'elle réussisse (si la politique d'authentification permet une telle action). Cette approche peut trouver un point de sortie convenable en présence d'un filtrage de couche sous-réseau (qui peut être sensible à la source/destination, par exemple, sans nécessairement créer de sous-réseaux logiques NBMA séparés) ou d'un encombrement de couche sous-réseau (en particulier dans un support orienté connexion).
Les demandes de résolution NHRP traversent un ou plusieurs bonds au sein d'un sous-réseau NBMA avant d'atteindre la qui est supposée générer une réponse. Chaque station, y compris la station source, choisit un NHS du voisinage auquel il transmet la demande de résolution NHRP. La procédure de choix du NHS implique normalement d'appliquer une adresse de couche de protocole de destination au tableau d'acheminement de couche protocole qui cause le retour d'une décision d'acheminement. Cette décision d'acheminement est alors utilisée pour transmettre la demande de résolution NHRP au NHS d'aval. L'adresse de couche de protocole de destination précédemment mentionnée est portée au sein du paquet de demande de résolution NHRP. Noter que bien qu'une adresse de couche protocole ait été utilisée pour acquérir une décision d'acheminement, les paquets NHRP ne sont pas encapsulés au sein d'un en-tête de couche protocole mais sont plutôt portés à la couche NBMA en utilisant l'encapsulation décrite à la Section 5.
Chaque NHS/routeur examine le paquet de demande de résolution NHRP sur son chemin vers la destination. Chaque NHS que traverse le paquet NHRP sur son chemin vers sa destination peut modifier le paquet (par exemple, en mettant à jour l'extension Enregistrement vers l'avant). En ignorant les situations d'erreur, la demande de résolution NHRP arrive finalement à une station qui va générer une réponse de résolution NHRP. Cette station qui répond "dessert" la destination. La station qui répond génère une réponse de résolution NHRP en utilisant l'adresse de protocole de source de l'intérieur du paquet NHRP pour déterminer où devrait être envoyée la réponse de résolution NHRP.
¨plutôt que d'utiliser l'acheminement pour déterminer le prochain bond pour un paquet NHRP, un NHS peut utiliser d'autres moyens applicables (tels que des informations de configuration statiques ) afin de déterminer à quels NHS du voisinage transmettre le paquet de demande de résolution NHRP pour autant que ces autres moyens ne causent pas l'arrivée du paquet NHRP à un NHS qui ne serait pas le long du chemin déterminé. L'utilisation des informations de configuration statiques à cette fin sort du domaine d'application du présent document.
Le NHS qui sert à une destination particulière doit se tenir le long du chemin déterminé vers cette destination. En pratique, cela signifie que tous les routeurs de sortie doivent aussi servir de NHS pour les destinations au delà d'eux, et que les hôtes sur le sous-réseau NBMA sont desservis par des routeurs qui agissent aussi comme NHS. De même, cela implique que la transmission des paquets NHRP au sein d'un sous-réseau NBMA exige un déploiement de routeurs à capacité NHRP contigus. Il est important que, dans un LIS/LAG donné qui utilise NHRP, tous les NHS au sein du LIS/LAG ont au moins une certaine portion de leurs bases de données de résolution synchronisées de sorte qu'un paquet arrivant à un routeur/NHS dans un LIS/LAG donné sera transmis de la même façon qu'un paquet qui arrive sur un routeur/NHS différent pour le LIS/LAG donné. Une méthode, entre d'autres, est d'utiliser le protocole de synchronisation d'antémémoire de serveur (SCSP, Server Cache Synchronization Protocol) [12]. Il est RECOMMANDÉ que SCSP soit la méthode utilisée lorsque un LIS/LAG contient deux routeurs/NHS ou plus.
Durant la migration vers NHRP, on ne peut pas s'attendre à ce que tous les routeurs au sein du sous-réseau NBMA aient la capacité NHRP. Et donc, on peut s'attendre à ce que le trafic NHRP qu'il serait autrement nécessaire de transmettre par de tels routeurs soit abandonner du fait que le paquet NHRP n'est pas reconnu. Dans ce cas, NHRP ne sera pas capable d'établir de chemins de transit dont la découverte exige la traversée des routeur qui ne parlent pas NHRP. Si le client a essayé d'acquérir un chemin raccourci et y a échoué, le client devrait alors utiliser par défaut le chemin déterminé par la couche réseau.
Si une technologie NBMA offre un dispositif d'adressage de groupe, d'envoi à la cantonade ou de diffusion groupée, le NHC peut alors être configuré avec une telle adresse (appropriée au domaine d'acheminement à laquelle elle participe) qui serait allouée à tous les NHS desservant ce domaine d'acheminement. Cette adresse peut alors être utilisée pour établir une connexion initiale avec un NHS pour transmettre une demande d'enregistrement. Cette adresse ne peut pas être utilisée pour l'envoi de demandes NHRP. Le VC résultant ne peut être utilisé pour les demandes NHRP que si et seulement si la réponse d'enregistrement est reçue sur ce VC, indiquant par là qu'il se trouve avoir la diffusion à la cantonade connectée à un NHS qui dessert le LIS/LAG. Dans le cas de réseaux non orientés connexion, ou d'adresses de diffusion groupée (plutôt qu'à la cantonade) l'adresse NE DOIT PAS être utilisée pour l'envoi de demandes de résolution NHRP.
Lorsque un NHS "dessert" un NHC, le NHS DOIT envoyer les messages NHRP destinés au NHC directement au NHC. C'est à dire que le message NHRP NE DOIT PAS transiter par un NHS qui ne dessert pas le NHC lorsque le message NHRP est actuellement chez un NHS qui ne dessert pas le NHC (cela suppose, bien sûr, que le message NHRP est destiné au NHC). De plus, un NHS qui dessert un NHC DEVRAIT avoir une connexion direct de niveau NBMA avec ce NHC (par exemple, voir aux paragraphes 5.2.3 et 5.2.4).
À l'exception des demandes d'enregistrement NHRP (voir aux paragraphes 5.2.3 et 5.2.4 les détails du cas de demande d'enregistrement NHRP) un NHC DOIT envoyer les messages NHRP sur une connexion directe de niveau NBMA entre le NHS desservant et le NHC desservi.
Il peut n'être pas souhaitable de maintenir une connexité semi permanente de niveau NBMA entre le NHC et le NHS. Dans ce cas, lorsque la connexité de niveau NBMA est initialement établie entre le NHS et le NHC (comme décrit au paragraphe 5.2.4) l'adresse NBMA du NHS devrait être obtenue par la technologie de signalisation de niveau NBMA. Cette adresse devrait être mémorisée pour une future utilisation d'établissement des connexions de niveau NBMA suivantes. Une technique plus riche d'informations pour obtenir les informations d'adresse (et plus encore) du NHS desservant serait que le NHC inclue l'extension Adresse du répondant (voir au paragraphe 5.3.1) dans la demande d'enregistrement NHRP et de mémoriser les informations retournées au NHC dans l'extension Adresse du répondant qui est ensuite incluse dans la réponse d'enregistrement NHRP. Noter aussi que, en pratique, le routeur par défaut d'un client devrait aussi être son NHS ; et donc un client peut être capable de connaître l'adresse NBMA de son NHS à partir de la configuration dont il a déjà été exigé du client qu'il soit capable de la communiquer. De plus, comme mentionné à la Section 4, les NHC peuvent être configurés avec les informations d'adressage d'un ou plusieurs NHS.
Clients de prochain bond
Un NHC connecté à un sous-réseau NBMA PEUT être configuré avec la ou les adresses de protocole et la ou les adresses NBMA de son ou ses NHS. Le ou les NHS vont vraisemblablement aussi représenter les routeurs par défaut ou homologues du NHC, de sorte que leurs adresses NBMA peuvent être obtenues de la configuration existante du NHC. Si le NHC est rattaché à plusieurs sous-réseaux (y compris des sous-réseaux logiques NBMA) le NHC devrait aussi être configuré pour recevoir des informations d'acheminement de ce ou ces NHS et des routeurs homologues afin qu'il puisse déterminer quels réseaux de couche inter-réseau sont accessibles à travers quels sous-réseaux.
Serveurs de prochain bond
Un NHS est configuré avec la connaissance de ses propres adresses de couche inter-réseau et NBMA. Un NHS PEUT aussi être configuré avec un ensemble de préfixes d'adresse de couche inter-réseau qui correspondent aux adresses de couche inter-réseau des stations qu'il dessert. Les adresses NBMA des stations desservies par le NHS peuvent être apprises via les paquets d'enregistrement NHRP.
Si un NHC desservi est rattaché à plusieurs sous-réseaux, le routeur/serveur d'acheminement corésidant avec le NHS desservant peuvent aussi devoir être configurés pour annoncer les informations d'acheminement à de tels NHC.
Si un NHS agit comme un routeur de sortie pour les stations connectées à d'autres sous-réseaux que le sous-réseau NBMA, le NHS doit, en plus de cela, être configuré pour échanger des informations d'acheminement entre le sous-réseau NBMA et ces autres sous-réseaux.
Dans tous les cas, les informations d'acheminement sont échangées en utilisant des protocoles d'acheminement conventionnels intra domaine et/ou inter domaine.
Cette section décrit le format des paquets NHRP. Dans ce qui suit, sauf mention contraire explicite, le terme "demande" non qualifié se réfère de façon générique aux types de paquet NHRP qui sont des "demandes". De plus, sauf mention contraire explicite, le terme "réponse" non qualifié se réfère de façon générique aux types de paquet NHRP qui sont des "réponses".
Un paquet NHRP consiste en une partie fixe, une partie obligatoire et une partie extensions. La partie fixe est commune à tous les types de paquet NHRP. La partie obligatoire DOIT être présente, mais varie selon le type de paquet. La partie extensions varie aussi selon le type de paquet, et elle n'est pas nécessairement présente.
La longueur de la partie fixe est fixée à 20 octets. La longueur de la partie obligatoire est déterminée par le contenu du champ de décalage des extensions (ar$extoff). Si ar$extoff=0x0, la longueur de la partie obligatoire est égale à la longueur de paquet totale (ar$pktsz) moins 20, autrement, la longueur de la partie obligatoire est égale à $extoff moins 20. La longueur de la partie extensions est impliquée par ar$pktsz moins ar$extoff. Les NHS peuvent augmenter la taille d'un paquet NHRP par suite d'un processus d'extension, mais pas au delà de la taille maximum de paquet offerte du réseau NBMA.
Les paquets NHRP sont en fait membres d'une plus large classe de transposition d'adresse et de protocoles de gestion en cours de développement par l'IETF. Une encapsulation spécifique, fondée sur les formats natifs utilisés dans le réseau NBMA particulier sur lequel est porté NHRP indique le protocole générique de transposition et de gestion de l'IETF. Par exemple, les réseaux SMDS utilisent toujours l'encapsulation LLC/SNAP à la couche NBMA [4], et un paquet NHRP est précédé par l'encapsulation LLC/SNAP suivante :
[0xAA-AA-03] [0x00-00-5E] [0x00-03]
Les trois premiers octets sont LLC, indiquant que SNAP suit. La portion OUI de SNAP est le OUI de l'IANA, et la portion PID de SNAP identifie le protocole de transposition et de gestion. Un champ dans l'en-tête fixe qui suit l'encapsulation indique que c'est NHRP.
ATM utilise l'encapsulation LLC/SNAP de chaque paquet (y compris NHRP) ou n'utilise pas d'encapsulation sur les VC dédiés à un seul protocole (voir [7]). Le relais de trame et X.25 utilisent tous deux l'encapsulation NLPID/SNAP ou l'identification de NHRP, utilisant un NLPID de 0x0080 et le même contenu SNAP que ci-dessus (voir [8], [9]).
Les champs marqués "non utilisé" DOIVENT être réglés à zéro à l'émission, et ignorés à réception.
La plupart des types de paquet (ar$op.type) ont à la fois des champs indépendants du protocole de couche inter-réseau et des champs spécifiques du protocole. Les champs type de protocole/snap (ar$pro.type/snap) qualifient le format des champs spécifiques du protocole.
La partie fixe du paquet NHRP contient les éléments du paquet NHRP qui sont toujours présents et ne varient pas en taille selon le type du paquet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$afn | ar$pro.type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | ar$hopcnt | ar$pktsz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$chksum | ar$extoff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$op.version | ar$op.type | ar$shtl | ar$sstl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$afn
Définit le type des adresses de "couche de liaison" qui sont portées. Ce nombre est tiré de la liste 'numéro de famille d'adresse' spécifié dans [6]. Ce champ a des implications sur le codage de ar$shtl et ar$sstl comme décrit ci-dessous.
ar$pro.type
Ce champ est un entier non signé de 16 bits représentant l'espace numérique suivant :
0x0000 à 0x00FF |
Protocoles définis par les NLPID équivalents. |
0x0100 à 0x03FF |
Réservé pour utilisation future par l'IETF. |
0x0400 à 0x04FF |
Alloué pour utilisation par le forum ATM. |
0x0500 à 0x05FF |
Utilisation expérimentale/locale. |
0x0600 à 0xFFFF |
Protocoles définis par les Ethertypes équivalents. |
(Fondé sur l'observation que les Ethertypes valides ne sont jamais inférieur à 0x600,et que les NLPID ne sont jamais supérieurs à 0xFF.)
ar$pro.snap
Lorsque ar$pro.type a une valeur de 0x0080, une extension codée en SNAP est utilisée pour coder le type de protocole. Cette extension snap est placée dans le champ ar$pro.snap. Ceci est appelé l'identifiant de protocole de 'forme longue'. Si ar$pro != 0x0080, le champ ar$pro.snap DOIT alors être à zéro à l'émission et ignoré à réception. Le champ ar$pro.type identifie le protocole auquel on se réfère. Ceci est appelé l'identifiant de protocole de 'forme courte'.
Dans tous les cas, lorsque un protocole a un nombre alloué dans l'espace ar$pro.type (à l'exclusion de 0x0080) la forme courte DOIT être utilisée pour transmettre les messages NHRP ; c'est-à-dire, si les codages Ethertype ou NLPID existent, ils sont alors utilisés à l'émission plutôt que l'ethertype. Si les codages Ethertype et NLPID existent tous deux lors de l'émission de messages NHRP, le codage Ethertype DOIT être utilisé (ceci est cohérent avec le codage de la RFC 1483). Ainsi par exemple, les codages suivants existent pour IP :
SNAP : |
ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00 |
NLPID : |
ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00 |
Ethertype : |
ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00 |
et donc, comme le codage Ethertype existe, il est utilisé de préférence.
ar$hopcnt
Le compte de bonds indique le nombre maximum de NHS que le paquet NHRP est autorisé à traverser avant d'être éliminé. Ce champ est utilisé d'une façon similaire à celle dont un TTL est utilisé dans un paquet IP et il devrait être réglé en conséquence. Chaque NHS décrémente le TTL lorsque le paquet NHRP traverse le NHS sur le chemin vers le prochain bond le long du chemin déterminé vers la destination. Si un NHS reçoit un paquet NHRP qu'il transmettrait normalement vers un prochain bond et que le paquet contient un ar$hopcnt réglé à zéro, le NHS renvoie alors un message d'indication d'erreur à l'adresse de protocole de source déclarant que le compte de bonds est dépassé (voir au paragraphe 5.2.7) et le NHS abandonne le paquet erroné ; cependant, une indication d'erreur n'est jamais envoyée comme résultat de la réception d'une indication d'erreur. Lorsque un NHS répondant réplique à une demande NHRP, ce NHS place une valeur dans ar$hopcnt comme si il envoyait une demande de son propre chef.
ar$pktsz
La longueur totale du paquet NHRP, en octets (à l'exclusion de l'encapsulation de couche de liaison).
ar$chksum
La somme de contrôle IP standard sur le paquet NHRP entier en commençant à l'en-tête fixe. Si le paquet fait un nombre impair d'octets, ce calcul est alors effectué comme si un octet réglé à 0x00 était ajouté à la fin du paquet.
ar$extoff
Ce champ identifie l'existence et la localisation des extensions NHRP. Si ce champ est 0, aucune extension n'existe alors. Autrement, ce champ représente le décalage par rapport au début du paquet NHRP (c'est-à-dire, en commençant au champ ar$afn) de la première extension.
ar$op.version
Ce champ indique quelle version du protocole générique de transposition et gestion d'adresse est représentée par ce message.
0 |
protocole MARS [11]. |
1 |
NHRP comme défini dans le présent document. |
0x02 - 0xEF |
réservé pour utilisation future par l'IETF. |
0xF0 - 0xFE |
alloué pour l'usage du forum ATM. |
0xFF |
utilisation expérimentale/locale. |
ar$op.type
Lorsque ar$op.version == 1, c'est le type de paquet NHRP : demande de résolution NHRP (1), Réponse de résolution NHRP (2), Demande d'enregistrement NHRP (3), Réponse d'enregistrement NHRP (4), Demande de purge NHRP (5), Réponse de purge NHRP (6), ou Indication d'erreur NHRP (7). L'utilisation des types de paquet NHRP dans la gamme de 128 à 255 est réservée à la recherche ou au développement d'autres protocoles et sera administrée par l'IANA comme décrit à la Section 9.
ar$shtl
Type et longueur de l'adresse de source NBMA interprétée dans le contexte du 'numéro de famille d'adresse' [6] indiqué par ar$afn. Voir ci-dessous pour des précisions.
ar$sstl
Type et longueur de la sous adresse de source NBMA interprétée dans le contexte du 'numéro de famille d'adresse' [6] indiqué par ar$afn. Lorsque une technologie NBMA n'a pas de concept de sous adresse, la longueur de sous adresse est toujours codée ar$sstl = 0 et aucune mémorisation n'est allouée pour la sous adresse dans la partie obligatoire appropriée. Voir ci-dessous pour les détails.
Les champs type/longueur d'adresse de couche sous-réseau (par exemple, ar$shtl, Cli Addr T/L) et les champs type/longueur de sous adresse de couche réseau (par exemple, ar$sstl, Cli SAddr T/L) sont codés comme suit :
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| longueur |
+-+-+-+-+-+-+-+-+
Le bit de poids fort est réservé et DOIT être mis à zéro. Le second bit de poids fort (x) est un fanion qui indique si le format de l'adresse de référence est en :
- format NSAP (x = 0).
- format E.164 natif (x = 1).
Pour les technologies NBMA qui n'utilisent le format d'adresse ni NSAP ni E.164, x = 0 DEVRA être utilisé pour indiquer la forme native de la technologie NBMA particulière.
Si le réseau NBMA est ATM et si une sous adresse (par exemple, sous adresse de source NBMA, sous adresse de client NBMA) est à inclure dans une partie quelconque du paquet NHRP, ar$afn DOIT alors être réglé à 0x000F ; de plus, les champs type/longueur d'adresse de couche de sous-réseau (par exemple, ar$shtl, Cli Addr T/L) et les champs type/longueur de sous adresse de couche réseau (par exemple, ar$sstl, Cli SAddr T/L) DOIVENT être codés comme dans [11]. Si le réseau NBMA est ATM et si aucun champ de sous adresse n'est à inclure dans une partie du paquet NHRP, ar$afn PEUT alors être réglé à 0x0003 (NSAP) ou 0x0008 (E.164) selon le cas.
Les 6 bits de moindre poids sont une valeur d'entier non signé qui indique la longueur de l'adresse NBMA associée en octets. Si cette valeur est zéro, le fanion x est ignoré.
La partie obligatoire du paquet NHRP contient les informations spécifiques de l'opération (par exemple, demande/réponse de résolution NHRP, etc.) et des données de longueur variable qui sont pertinentes pour le type de paquet.
5.2.0.1 Format de la partie obligatoire
Les paragraphes 5.2.1 à 5.2.6 ont une partie obligatoire très similaire. Cette partie obligatoire comporte un en-tête commun et zéro, une ou plusieurs entrées d'informations client (CIE, Client Information Entry). Le paragraphe 5.2.7 a un format différent qui est spécifié ici.
L'en-tête commun ressemble à ce qui suit :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | Fanions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de demande |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de source NBMA (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sous-adresse de source NBMA (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de protocole de source (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de protocole de destination (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Et les CIE ont le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Lg de préfixe | non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unité de transmission maximum | Temps de garde |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Préférence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de client NBMA (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sous-adresse de client NBMA (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de protocole client (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Lg de préfixe | non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unité de transmission maximum | Temps de garde |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Préférence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de client NBMA (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sous-adresse de client NBMA (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de protocole client (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La signification des champs est la suivante :
Src Proto Len
Ce champ contient la longueur en octets de l'adresse de protocole de source.
Dst Proto Len
Ce champ contient la longueur en octets de l'adresse de protocole de destination.
Fanions
Ces fanions sont spécifiques du type de message donné et ils sont expliqués dans chaque paragraphe.
Identifiant de demande
Une valeur qui, lorsque elle est couplée à l'adresse de la source, procure un identifiant univoque pour les informations contenues dans un paquet "demande". Cette valeur est copiée directement d'un paquet "demande" dans la "réponse" associée. Lorsque l'envoyeur d'une "demande" reçoit une "réponse", il va comparer l'identifiant de demande et les informations d'adresse de source de la "réponse" reçue à celles trouvées dans sa liste de "demandes" en instance. Lorsque une correspondance est trouvée, la "demande" est alors considérée comme ayant été acquittée.
La valeur est tirée d'un compteur de 32 bits qui est incrémenté chaque fois qu'une nouvelle "demande" est transmise. La même valeur DOIT être utilisée lors du renvoi d'une "demande", c'est-à-dire, lorsque une "réplique" n'a pas été reçue pour une "demande" et un nouvel essai est envoyé après un intervalle approprié.
Il est RECOMMANDÉ que la valeur initiale de ce nombre soit 0. Un nœud PEUT réutiliser un numéro de séquence si et seulement si la réutilisation du numéro de séquence n'est pas empêché par l'utilisation d'une méthode particulière de synchronisation (par exemple, comme décrit dans l'Appendice A).
La forme d'adresse/sous adresse NBMA spécifiée ci-dessous permet une forme combinée E.164/NSAPA d'adressage NBMA. Pour les technologies NBMA sans concept de sous adresse, le champ sous adresse est toujours de longueur zéro et ar$sstl = 0.
Adresse de source NBMA
Le champ adresse de source NBMA est l'adresse de la station de source qui envoie la "demande". Si la longueur du champ tel que spécifié dans ar$shtl est 0, aucun espace de mémorisation n'est alloué pour cette adresse.
Sous-adresse de source NBMA
Le champ sous adresse de source NBMA est l'adresse de la station de source qui envoie la "demande". Si la longueur du champ spécifiée dans ar$sstl est 0, aucun espace de mémorisation n'est alloué pour cette adresse.
Pour les technologies NBMA qui ont une notion des "Adresses de l'appelant", les adresses de source NBMA ci-dessus sont les adresses utilisées lors de la signalisation d'un SVC.
Les "demandes" et "indications" suivent le chemin déterminé de l'adresse de protocole de source à l'adresse de protocole de destination. D'un autre côté, les "répliques" suivent le chemin déterminé de l'adresse de protocole de destination à l'adresse de protocole de source avec les exceptions suivantes : dans le cas d'une réponse d'enregistrement NHRP et dans celui d'une demande de purge NHRP à l'initiative du NHC, le paquet est toujours retourné via un VC direct (voir aux paragraphes 5.2.4 et 5.2.5).
Adresse de protocole de source
C'est l'adresse de protocole de la station qui envoie la "demande". C'est aussi l'adresse de protocole de la station vers laquelle un paquet "réplique" est envoyé.
Adresse de protocole de destination
C'est l'adresse de protocole de la station vers laquelle un paquet "demande" est envoyé.
Code
Ce champ est spécifique du message. Voir ci-dessous les paragraphes relatifs au message. En général, ce champ est un code de NAK ; c'est-à-dire que lorsque le champ est à 0 dans une réplique le paquet accuse alors réception d'une demande et si il contient une autre valeur, le paquet contient un accusé de réception négatif.
Longueur de préfixe
Ce champ est spécifique du message. Voir ci-dessous les paragraphes relatifs au message. En général, cependant, ce champ est utilisé pour indiquer que les informations portées dans un message NHRP appartiennent à une classe d'équivalence d'adresses de couche inter-réseau plutôt que juste à une seule adresse de couche inter-réseau spécifiée. Toutes les adresses de couche inter-réseau qui correspondent aux premières positions de "Longueur de préfixe" pour l'adresse de couche inter-réseau spécifique sont incluses dans la classe d'équivalence. Si ce champ est réglé à 0x00, ce champ DOIT alors être ignoré et aucune information d'équivalence n'est supposée (noter que 0x00 est donc équivalent à 0xFF).
Unité de transmission maximum
Ce champ donne l'unité de transmission maximum pour la station client pertinente. Si cette valeur est 0, soit est alors utilisée la MTU par défaut , soit c'est la MTU négociée via la signalisation si une telle négociation est possible pour ce NBMA.
Temps de garde
Le champ Temps de garde spécifie le nombre de secondes pendant lequel les informations de prochain bond NBMA spécifiées dans le CIE sont considérées valides. Les informations en antémémoire DEVRONT être éliminées à l'expiration du temps de garde. Ce champ doit être réglé à 0 sur un NAK.
Cli Addr T/L
Type et longueur de l'adresse NBMA de prochain bond spécifiée dans le CIE. Ce champ est interprété dans le contexte du 'numéro de famille d'adresse' [6] indiquée par ar$afn (par exemple, ar$afn=0x0003 pour ATM).
Cli SAddr T/L
Type et longueur de la sous adresse NBMA de prochain bond spécifiée dans le CIE. Ce champ est interprété dans le contexte du 'numéro de famille d'adresse' [6] indiquée par ar$afn (par exemple, ar$afn=0x0015 pour ATM donne à l'adresse une forme E.164 et à la sous adresse une adresse NSAP du forum ATM). Lorsque une technologie NBMA n'a pas le concept de sous adresse, la sous adresse est toujours nulle avec une longueur de 0. Lorsque la longueur d'adresse est spécifiée comme 0 aucun espace de mémorisation n'est alloué pour l'adresse.
Cli Proto Len
Ce champ contient la longueur en octets de l'adresse de protocole du client spécifiée dans le CIE.
Préférence
Ce champ spécifie les préférence pour l'utilisation du CIE spécifique par rapport aux autres CIE. Les plus fortes valeurs indique la plus haute préférence. L'action à entreprendre lorsque plusieurs CIE ont des valeurs de préférence égales ou la plus élevée est une affaire locale.
Adresse NBMA de client
C'st l'adresse NBMA du client.
Sous-adresse NBMA de client
C'est la sous adresse NBMA du client.
Adresse de protocole de client
C'est l'adresse de couche inter-réseau spécifiée du client.
Noter qu'un NHS peut mettre en antémémoire les informations de lien d'adresse de source provenant d'une demande de résolution NHRP si et seulement si les conditions décrites au paragraphe 6.2 sont satisfaites pour le NHS. Dans tous les autres cas, les informations de lien d'adresse de source qui apparaissent dans un message NHRP NE DOIVENT PAS être mises en antémémoire.
Le paquet de demande de résolution NHRP a un code de type de 1. Sa partie obligatoire est codée comme décrit au paragraphe 5.2.0.1 et la signification spécifique du message des champs est la suivante :
Fanions – Le champ fanions est codé comme suit :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Mis à 1 si la station qui envoie la demande de résolution NHRP est un routeur ; à 0 si c'est un hôte.
A
Ce bit est mis à 1 dans une demande de résolution NHRP si seules des informations de prochain bond d'autorité sont désirées et à 0 autrement. Voir le paragraphe Réponse de résolution NHRP ci-dessous pour des précisions sur le bit "A" et son usage.
D
Non utilisé (à 0 en émission).
U
C'est le bit d'unicité. Ce bit aide à la détection des adresses dupliquées . Lorsque ce bit est mis à1 dans une demande de résolution NHRP que une ou plusieurs entrées existent dans l'antémémoire NHS qui satisfont aux exigences de la demande de résolution NHRP, seule la CIE dans l'antémémoire du NHS qui a ce bit établi sera retournée. Noter que même si ce bit était établi au moment de l'enregistrement, il pourrait quand même y avoir plusieurs CIE qui satisfassent à la demande de résolution NHRP parce qu'un adresse entier peut être enregistré par l'utilisation de la longueur de préfixe dans le CIE et que l'adresse intéressante pourrait être au sein d'un tel sous réseau. Si le bit "d'unicité" est mis et si le NHS répondant a une ou plusieurs entrées d'antémémoire qui correspondent à la demande mais qu'aucune de ces entrées d'antémémoire n'a le bit "d'unicité" établi, la réponse de résolution NHRP retourne alors un code NAK de "13 – Un lien existe mais n'est pas unique" et aucun CIE n'est inclus. Si un client souhaite recevoir des entrées de prochain bond non uniques, le client doit alors avoir le bit "unicité" mis à zéro dans sa demande de résolution NHRP. Noter que quand ce bit est mis dans une demande d'enregistrement NHRP, seul un CIE peut être spécifié dans la demande d'enregistrement NHRP et ce CIE doit avoir le champ longueur de préfixe réglé à 0xFF.
S
Établi si la stabilité et la précision du lien entre l'adresse de protocole de source et les informations de source NBMA dans la demande de résolution NHRP sont garanties (par exemple, ces adresses sont celles d'un routeur d'entrée qui est connecté à un réseau Ethernet de bout ou le NHC est un hôte rattaché NBMA).
Zéro ou un CIE (voir au paragraphe 5.2.0.1) peut être spécifié dans une demande de résolution NHRP. Si un est spécifié, cette entrée porte alors les informations pertinentes pour le client à la source de la demande de résolution NHRP. L'usage du CIE dans la demande de résolution NHRP est décrit ci-dessous.
Longueur de préfixe
Si un CIE est spécifié dans la demande de résolution NHRP, le champ Longueur de préfixe peut alors être utilisé pour qualifier le plus long préfixe acceptable qui peut être utilisé pour satisfaire la demande de résolution NHRP. Dans le cas de demande/réponse de résolution NHRP, la longueur de préfixe spécifie la classe d'équivalence des adresses qui correspondent aux premières position de bits de "Longueur de préfixe" de l'adresse de protocole de destination. Si le bit "U" est mis dans l'en-tête commun, ce champ DOIT alors être réglé à 0xFF.
Unité de transmission maximum
Ce champ donne l'unité de transmission maximum pour la station de source. Une utilisation possible de ce champ dans le paquet de demande de résolution NHRP est pour demander une MTU cible pour la demande de résolution NHRP.
Temps de garde
Le temps de garde spécifié dans le seul CIE qu'il est permis d'inclure dans une demande de résolution NHRP est la durée pendant laquelle les informations de lien de l'adresse de source de la demande de résolution NHRP sont admises en antémémoire par les NHS de transit et répondants. Noter que ce champ ne peut avoir qu'une valeur positive si le bit S est mis.
Tous les autres champs dans le CIE DOIVENT être ignorés et DEVRAIENT être mis à 0.
L'adresse de protocole de destination dans l'en-tête commun de la partie obligatoire de ce message contient l'adresse de protocole de la station pour laquelle la résolution est désirée. Un NHC DOIT envoyer la demande de résolution NHRP directement à un de ses NHS desservant (voir à la Section 3 des informations complémentaires).
Le paquet Réponse de résolution NHRP a le code de type de 2. Les CIE qui correspondent aux entrées de prochain bond dans l'antémémoire d'un NHS satisfont aux critères de la demande de résolution NHRP. Sa partie obligatoire est codée comme décrit au paragraphe 5.2.0.1. La signification des champs spécifiques du message est la suivante :
Fanions –Le champ fanions est codé comme suit :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Copié de la demande de résolution NHRP. Mis à 1 si la demande de résolution NHRP vient d'un routeur ; à 0 si c'est d'un hôte.
A
Mis à 1 si le CIE de prochain bond dans la réponse de résolution NHRP est d'autorité ; à 0 si la réponse de résolution NHRP n'est pas d'autorité.
Lorsque un NHS reçoit une demande de résolution NHRP pour des informations d'autorité pour lesquelles il est la source d'autorité, il DOIT répondre par une réponse de résolution NHRP contenant tous, et seulement eux, les CIE de prochain bond qui sont contenus dans l'antémémoire du NHS et à la fois satisfont aux critères de la demande de résolution NHRP et sont des entrées d'autorité de l'antémémoire. Un NHS est une source d'autorité pour une demande de résolution NHRP si les informations dans l'antémémoire du NHS satisfont aux critères de la demande de résolution NHRP et si elles ont été obtenues par une demande d'enregistrement NHRP ou par la synchronisation avec un NHS qui a obtenu ces information par une demande d'enregistrement NHRP. Une entrée d'autorité d'antémémoire est celle qui est obtenue par une demande d'enregistrement NHRP ou par synchronisation avec un NHS qui a obtenu ces informations par une demande d'enregistrement NHRP.
Un NHS obtient des CIE qui ne sont pas d'autorité par une écoute de proximité des paquets NHRP autres que d'enregistrement NHRP qui sont dirigés sur lui. Une demande de résolution NHRP qui indique une demande d'informations qui ne sont pas d'autorité devrait causer une réponse de résolution NHRP qui contient toutes les entrées de l'antémémoire du NHS répondant (c'est-à-dire, à la fois d'autorité et celles qui ne le sont pas) qui correspondent aux critères spécifiés dans la demande.
D
Il est mis à 1 si l'association entre la destination et les informations associées de prochain bond incluses dans tous les CIE de la réponse de résolution NHRP est d'une stabilité garantie pour la durée de vie des informations (le temps de garde). C'est le cas si l'adresse de protocole du prochain bond dans un CIE identifie la destination (bien qu'elle puisse être d'une valeur différente de celle de l'adresse de destination si le système de destination a plusieurs adresses) ou si la destination n'est pas connectée directement au sous-réseau NBMA mais qu'il est garanti que le routeur de sortie pour cette destination sera stable (comme lorsque la destination est immédiatement adjacente au routeur de sortie à travers une interface non NBMA).
U
C'est le bit d'unicité. Voir au paragraphe Demande de résolution NHRP ci-dessus pour les détails. Lorsque ce bit est mis, un seul CIE est inclus car seul un lien unique devrait exister dans l'antémémoire du NHS.
S
Copié du message NHRP de demande de résolution.
Un ou plusieurs CIE sont spécifiés dans la réponse de résolution NHRP. Chaque CIE contient des informations de prochain bond NHRP que le NHS répondant a mis en antémémoire et qui correspondent aux paramètres spécifiés dans la demande de résolution NHRP. Si aucune correspondance n'est trouvée par le NHS qui produit la réponse de résolution NHRP, un seul CIE est alors inclus avec le code de CIE réglé de façon appropriée (voir ci-dessous) et tous les autres champs DOIVENT être ignorés et DEVRAIENT être mis à 0. Afin de faciliter l'utilisation de NHRP par des mises en œuvre de client minimales, le premier CIE DOIT contenir le prochain bond avec la plus forte valeur de préférence de sorte qu'une telle mise en œuvre n'ait besoin d'analyser qu'un seul CIE.
Code
Si ce champ est mis à zéro, ce paquet contient alors un accusé de réception positif de réponse de résolution NHRP. Si ce champ contient tout autre valeur, ce message contient un NAK de réponse de résolution NHRP qui signifie qu'un lien approprié de couche inter-réseau à adresse NBMA n'était pas disponible dans l'antémémoire du NHS répondant. Si la réponse de résolution NHRP contient une entrée d'informations de client avec un code de NAK autre que 0, elle NE DOIT PAS contenir alors d'autre CIE. Les codes de NAK actuellement définis sont les suivants :
4 – Administrativement interdit
Un NHS peut refuser une tentative de demande de résolution NHRP pour des raisons administratives (dues à des contraintes de politique ou d'état de l'acheminement). S'il en est ainsi, le NHS DOIT envoyer une réponse de résolution NHRP qui contient un code de NAK de 4.
5 – Ressources insuffisantes
Si un NHS ne peut pas servir une station du fait d'un manque de ressources (par exemple, il ne peut pas mémoriser suffisamment d'informations pour envoyer une purge si l'acheminement change, le NHS DOIT répondre avec un NAK de réponse de résolution NHRP qui contient un code de NAK de 5.
12 – Il n'existe pas de lien d'adresse de couche inter-réseau à adresse NBMA
Ce code déclare qu'il n'y a absolument aucun lien d'adresse de couche inter-réseau à adresse NBMA qui se trouve dans l'antémémoire du NHS répondant.
13 – Un lien existe mais il n'est pas unique
Ce code déclare qu'il y avait un ou plusieurs liens d'adresse de couche inter-réseau à adresse NBMA qui se trouvaient dans l'antémémoire du NHS répondant, cependant aucun d'eux n'avait le bit d'unicité mis.
Longueur de préfixe
Dans le cas de réponse de résolution NHRP, la longueur de préfixe spécifie la classe d'équivalence des adresses qui correspondent aux premières positions des bits de "Longueur de préfixe" de l'adresse de protocole de destination.
Temps de garde
Le temps de garde spécifié dans un CIE d'une réponse de résolution NHRP est la quantité de temps restant avant l'expiration des informations de client qui sont en antémémoire chez le NHS répondant. Ce n'est pas la valeur qui a été enregistrée par le client.
Le reste des champs du CIE pour chaque prochain bond est rempli lorsque ils sont définis à l'enregistrement du prochain bond chez le NHS répondant (ou un des serveurs synchronisés du NHS répondant) via la demande d'enregistrement NHRP.
Le partage de charge peut être effectué lorsque plus d'une entrée d'informations de client sont retournées à un demandeur lorsque des valeurs de préférence égales sont spécifiées. Aussi, des adresses de remplacement peuvent être utilisées dans le cas de défaillance de connexité dans le sous-réseau NBMA (comme un échec de tentative d'appel dans des sous-réseaux NBMA orientés connexion).
Toutes les extensions présentes dans le paquet de demande de résolution NHRP DOIVENT être présentes dans la réponse de résolution NHRP même si l'extension est non obligatoire.
Si un paquet de réponse de résolution NHRP non sollicité est reçu, une indication d'erreur de type Réponse de résolution NHRP invalide reçue DEVRAIT être envoyée en réponse.
Lorsque un NHS qui dessert un NHC donné reçoit une réponse de résolution NHRP destinée à ce NHC, le NHS DOIT alors envoyer la réponse de résolution NHRP directement au NHC (voir à la Section 3).
La demande d'enregistrement NHRP est envoyée d'une station à un NHS pour lui notifier les informations de NBMA de la station. Il a un code de type de 3. Chaque CIE correspond à des informations de prochain bond qui sont à mettre en antémémoire chez un NHS. La partie obligatoire d'une demande d'enregistrement NHRP est codée comme décrit au paragraphe 5.2.0.1. La signification des champs spécifique du message est la suivante :
Fanions – Le champ fanions est codé comme suit :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U
C'est le bit d'unicité. Lorsque il est mis dans une demande d'enregistrement NHRP, ce bit indique que l'enregistrement de l'adresse de protocole est unique dans les limites de l'ensemble des NHS synchronisés. Ce qualificatif de "unicité" DOIT être mémorisé dans l'antémémoire du NHS/NHC. Toute tentative d'enregistrer un lien entre l'adresse de protocole et une adresse NBMA lorsque ce bit est mis DOIT être rejetée avec un code de "14 – Adresse unique de couche inter-réseau déjà enregistrée" si le NHS répondant a déjà une entrée d'antémémoire pour l'adresse de protocole et si l'entrée d'antémémoire a le bit "unicité" établi. Un enregistrement d'une information de CIE est rejetée lorsque le CIE est retourné avec le champ Code réglé à autre chose que 0x00. Voir la description du bit d'unicité au paragraphe sur la demande de résolution NHRP ci-dessus pour des précisions. Lorsque ce bit est mis, un seul CIE PEUT être inclus dans la demande d'enregistrement NHRP.
Identifiant de demande
L'identifiant de demande a la même signification que décrit au paragraphe 5.2.0.1. Cependant, l'identifiant de demande pour les enregistrements NHRP qui est entretenu par chaque client DOIT être conservé dans une mémoire non volatile afin que lorsque un client a une défaillance et se réenregistre, il n'y ait pas d'incohérences dans la base de données du NHS. Afin de réduire la redondance associée à la mise à jour de la mémoire non volatile, la mise à jour réelle n'a pas besoin d'être faite à chaque incrément de l'identifiant de demande mais pourrait être fait, par exemple, tous les 50 ou 100 incréments. Dans ce scénario, lorsque un client a une défaillance et se réenreregistre, il sait ajouter 100 à la valeur de l'identifiant de demande dans la mémoire non volatile avant d'utiliser l'identifiant de demande pour des enregistrements ultérieurs.
Un ou plusieurs CIE sont spécifiés dans la demande d'enregistrement NHRP. Chaque CIE contient les informations de prochain bond qu'un client tente d'enregistrer auprès de ses serveurs. Généralement, tous les champs dans les CIE qui sont inclus dans les demandes d'enregistrement NHRP sont codés comme décrit au paragraphe 5.2.0.1. Cependant, si une station s'enregistre seulement elle-même avec la demande d'enregistrement NHRP, elle PEUT alors coder les champs Cli Addr T/L, Cli SAddr T/L, et Cli Proto Len à zéro ce qui signifie que les informations d'adresse client sont à prendre dans les informations de source de l'en-tête commun (voir au paragraphe 5.2.0.1). Ci-dessous sont données des précisions supplémentaires sur certains champs d'un CIE dans le contexte d'une demande d'enregistrement NHRP.
Code
Ce champ est mis à 0x00 dans les demandes d'enregistrement NHRP.
Longueur de préfixe
Ce champ peut être utilisé dans une demande d'enregistrement NHRP pour enregistrer les informations d'équivalence pour l'adresse de protocole client spécifiées dans le CIE d'une demande d'enregistrement NHRP. Dans le cas d'une demande d'enregistrement NHRP, la longueur de préfixe spécifie la classe d'équivalence des adresses qui correspondent aux premières positions de bits de "Longueur de préfixe" de l'adresse de protocole du client. Si le bit "U" est mis dans l'en-tête commun, ce champ DOIT alors être réglé à 0xFF.
La demande d'enregistrement NHRP est utilisée pour enregistrer les informations NHRP d'un NHC auprès de ses NHS. Si un NHC est configuré avec l'adresse de protocole d'un NHS desservant le NHC peut alors placer l'adresse de protocole du NHS dans le champ d'adresse de protocole de destination de l'en-tête commun de la demande d'enregistrement NHRP ; autrement, le NHC doit placer sa propre adresse de protocole dans le champ d'adresse de protocole de destination.
Lorsque un NHS reçoit une demande d'enregistrement NHRP qui a le champ d'adresse de protocole de destination réglé à une adresse qui appartient à un LIS/LAG desservi par le NHS, si le champ d'adresse de protocole de destination est égal au champ d'adresse de protocole de source (ce qui arrivera si le NHC a mis son adresse de protocole dans l'adresse de protocole de destination) ou si le champ d'adresse de protocole de destination est égal à l'adresse de protocole du NHS, le NHS traite alors la demande d'enregistrement NHRP après avoir procédé aux vérifications d'erreurs appropriées (y compris les vérifications de politique applicables).
Lorsque un NHS reçoit une demande d'enregistrement NHRP qui a le champ d'adresse de protocole de destination réglé à une adresse qui n'appartient pas à un LIS/LAG desservi par le NHS, le NHS transmet alors le paquet le long du chemin déterminé vers le LIS/LAG approprié.
Lorsque un NHS reçoit une demande d'enregistrement NHRP qui a le champ d'adresse de protocole de destination réglé à une adresse qui appartient à un LIS/LAG desservi par le NHS, si le champ d'adresse de protocole de destination n'est pas égal au champ d'adresse de protocole de source et si le champ d'adresse de protocole de destination n'est pas égal à l'adresse de protocole du NHS, celui –ci transmet alors le message au NHS approprié au sein du LIS/LAG comme spécifié par le champ d'adresse de protocole de destination.
Il est possible qu'une station mal configurée tente de s'enregistrer auprès du mauvais NHS (c'est-à-dire, un qui ne peut pas la desservir du fait de contraintes de politique ou d'état de l'acheminement). Si c'est le cas, le NHS DOIT répliquer avec un NAK de réponse d'enregistrement du type Cette adresse ne peut être desservie.
Si un NHS ne peut pas desservir une station du fait d'un manque de ressources, le NHS DOIT répliquer par un NAK de réponse d'enregistrement du type Débordement des enregistrements.
Afin de protéger les entrées d'enregistrement contre la suppression, la station DOIT renvoyer le paquet de demande d'enregistrement NHRP assez souvent pour rafraîchir l'enregistrement, même face à des pertes de paquet occasionnelles. Il est recommandé que le paquet de demande d'enregistrement NHRP soit envoyé à un intervalle égal à un tiers du temps de garde spécifié ici.
La réponse d'enregistrement NHRP est envoyée par un NHS à un client en réponse à la demande d'enregistrement NHRP de ce client. Si le champ Code d'un CIE dans la réponse d'enregistrement NHRP comporte autre chose que des zéros, la réponse d'enregistrement NHRP est alors un NAK ; autrement la réponse est un ACK. La réponse d'enregistrement NHRP a un code Type de 4.
Une réponse d'enregistrement NHRP est formée à partir d'une demande d'enregistrement NHRP en changeant le code de type à 4, en mettant à jour le champ Code du CIE, et en complétant les extensions appropriées si elles existent. La signification des champs spécifiques du message donnée ci-dessous.
Tenter d'enregistrer dans les CIE les informations d'une demande d'enregistrement NHRP peut échouer pour des raisons diverses. Si c'est le cas, chaque échec de tentative d'enregistrer les informations dans un CIE d'une demande d'enregistrement NHRP est enregistré dans la réponse d'enregistrement NHRP associée en réglant le champ Code du CIE au code d'erreur approprié, comme indiqué ci-dessous :
Code de CIE
0 – Enregistrement réussi
Les informations dans le CIE ont été bien enregistrées auprès du NHS.
4 – Administrativement interdit
Un NHS peut refuser une tentative de demande d'enregistrement NHRP pour des raisons administratives (du fait de contraintes de politique ou de l'état de l'acheminement). S'il en est ainsi, le NHS DOIT envoyer une réponse d'enregistrement NHRP qui contient un code NAK de 4.
5 – Ressources insuffisantes
Si un NHS ne peut pas desservir une station du fait d'un manque de ressources, le NHS DOIT répondre par un NAK de réponse d'enregistrement NHRP qui contient un code NAK de 5.
14 – Adresse unique de couche inter-réseau déjà enregistrée
Si un client essaye d'enregistrer un lien d'adresse de protocole à adresse NBMA avec le bit d'unicité mis alors que l'adresse de protocole existe déjà dans l'antémémoire du NHS, si cette entrée d'antémémoire a aussi le bit d'unicité mis, ce code NAK est retourné dans le CIE de la réponse d'enregistrement NHRP.
Du fait de l'existence possible d'un acheminement asymétrique, une réponse d'enregistrement NHRP peut n'être pas capable de suivre simplement le chemin déterminé en retour pour l'adresse de protocole de source spécifiée ans l'en-tête commun de la réponse d'enregistrement NHRP. Il en résulte qu'il DOIT exister une connexion directe de niveau NBMA entre le NHC et son NHS sur lequel envoyer la réponse d'enregistrement NHRP avant qu'une réponse d'enregistrement NHRP puisse être retournée au NHC. Si une telle connexion n'existe pas, le NHS doit en établir une avec le NHC en utilisant les informations NBMA de source fournies dans l'en-tête commun de la demande d'enregistrement NHRP.
Le paquet Demande de purge NHRP est envoyé afin d'invalider les informations de l'antémémoire dans une station. Le paquet Demande de purge NHRP a un code de type de 5. La partie obligatoire d'une demande de purge NHRP est codée comme décrit au paragraphe 5.2.0.1. La signification des champs spécifiques du message est la suivante :
Fanions – Le champ fanions est codé comme suit :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N
Lorsque il est mis, ce bit dit au receveur de la demande de purge NHRP que le demandeur ne s'attend pas à recevoir une réponse de purge NHRP. Si une réponse de purge NHRP non sollicitée est reçue par une station et que cette station est identifiée dans l'adresse de protocole de source du paquet, ce paquet doit alors être ignoré.
Un ou plusieurs CIE sont spécifiés dans la demande de purge NHRP. Chaque CIE contient les informations de prochain bond qui sont à purger dans l'antémémoire d'un NHS/NHC. Généralement, dans les CIE, tous les champs inclus dans les demandes de purge NHRP sont codés comme décrit au paragraphe 5.2.0.1. Ci-dessous figurent des précisions pour certains champs d'un CIE dans le contexte d'une demande de purge NHRP.
Code
Ce champ est réglé à 0x00 dans les demandes de purge NHRP.
Longueur de préfixe
Dans le cas des demandes de purge NHRP, la longueur de préfixe spécifie la classe d'équivalence des adresses qui correspondent aux premières positions de bits de "Longueur de préfixe" de l'adresse de protocole de client spécifiée dans le CIE. Toutes les informations de prochain bond qui contiennent une adresse de protocole qui correspond à un élément de cette classe d'équivalence sont à purger dans l'antémémoire du receveur.
Les champs unité de transmission maximum et préférence du CIE sont codés à zéro. Le temps de garde devrait être codé à zéro mais il peut être utile de fournit un temps de garde "court"à appliquer aux informations de prochain bond qui correspondent avant que ces informations ne soient purgées ; cet usage fera l'objet d'études ultérieures. Le champ d'adresse de protocole de client et le champ Cli Proto Len DOIVENT être remplis. L'adresse de protocole de client est remplis avec l'adresse de protocole à purger dans l'antémémoire de la station receveuse alors que le champ Cli Proto Len est réglé à la longueur de l'adresse de protocole du client purgé. Tous les champs restants dans le CIE PEUVEN être réglés à zéro bine que les informations de client NBMA (et les champs de longueur associés) PEUVENT être spécifiés pour réduire la portée de la demande de purge NHRP si le demandeur le désire. Cependant, le receveur d'une demande de purge NHRP peut choisir d'ignorer les informations de client NBMA si elles sont fournies.
Un paquet de demande de purge NHRP est envoyé d'un NHS à une station pour l'amener à supprimer les informations précédemment mises en antémémoire. Cela est fait lorsque les informations peuvent n'être plus valides (normalement lorsque le NHS a précédemment fourni les informations de prochain bond pour une station qui n'est pas directement connectée au sous-réseau NBMA, et le point de sortie de cette station peut avoir changé).
Un paquet de demande de purge NHRP peut aussi être envoyé d'un NHC à un NHS auprès duquel le NHC s'était précédemment enregistré. Cela permet à un NHC d'invalider son enregistrement auprès du NHRP avant qu'il arrive à expiration via temporisateur de garde. Si un NHC n'a pas connaissance de l'adresse de protocole d'un NHS de desserte, le NHC doit alors placer sa propre adresse de protocole dans le champ d'adresse de protocole de destination et transmettre le paquet le long du chemin déterminé. Autrement, le NHC doit placer l'adresse de protocole d'un NHS desservant dans ce champ.
Les NHS desservants peuvent avoir besoin d'envoyer une ou plusieurs nouvelles demandes de purge NHRP suite à la réception d'une purge d'un des NHC desservis car le NHS peut avoir précédemment répondu aux demandes de résolution NHRP pour ces informations NBMA du NHC. Ces purges sont "nouvelles" en ce qu'elles sont générées par le NHS et non par le NHC ; c'est-à-dire que, pour chaque NHC qui avait précédemment envoyé une demande de résolution NHRP pour les informations NBMA de NHC purgées, une demande de purge NHRP est envoyée qui contient les adresses de protocole de source/NBMA du NHS et l'adresse de protocole de destination du NHC qui a envoyé précédemment une demande de résolution NHRP avant la purge.
La station qui envoie la demande de purge NHRP PEUT périodiquement retransmettre la demande de purge NHRP jusqu'à ce qu'il soit accusé réception de la demande de purge NHRP ou jusqu'à ce que le temps de garde des informations en cours de purge soit expiré. Les stratégies de retransmission des demandes de purge NHRP sont une affaire locale.
Lorsque une station reçoit une demande de purge NHRP, elle DOIT éliminer toutes les informations précédemment mises en antémémoire qui correspondent aux informations dans les CIE.
Une réponse de purge NHRP DOIT être retournée pour la demande de purge NHRP même si la station n'a pas d'entrée d'antémémoire qui corresponde, en supposant que le bit "N" est à zéro dans la demande de purge NHRP.
Si la station souhaite rétablir la communication avec la destination peu après avoir reçu une demande de purge NHRP, elle devrait faire une demande de résolution NHRP d'autorité afin d'éviter les entrées d'antémémoire périmées qui pourraient être présentes dans des NHS intermédiaires (Voir au paragraphe 6.2.2.). Il est recommandé que les demandes de résolution NHRP d'autorité soient faites pour la durée du temps de garde des vieilles informations.
Le paquet de réponse de purge NHRP est envoyé afin que l'envoyeur d'une demande de purge NHRP s'assure que toutes les informations mises en antémémoire du type spécifié ont été purgées de la station qui envoie la réponse. La réponse de purge NHRP a le code de type de 6.
Une réponse de purge NHRP est formée à partir d'une demande de purge NHRP en changeant simplement le code de type de la demande en 6. Le paquet est alors retourné au demandeur après remplissage des extensions appropriées si elles existent.
L'indication d'erreur NHRP est utilisée pour transporter les indications d'erreur à l'envoyeur d'un paquet NHRP. Elle a un code de type de 7. La partie obligatoire a le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code d'erreur | décalage d'erreur |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse NBMA de source (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sous-adresse NBMA de source (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de protocole de source (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de protocole de destination (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contenu du paquet NHRP erroné (longueur variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len
Ce champ contient la longueur en octets de l'adresse de protocole de source.
Dst Proto Len
Ce champ contient la longueur en octets de l'adresse de protocole de destination.
Code d'erreur
C'est un code d'erreur qui indique le type d'erreur détectée, choisi dans la liste suivante :
1 – Extension non reconnue
Lorsque le bit obligatoire d'une extension est établi dans le paquet NHRP, le paquet NHRP ne peut être traité que si l'extension a été traitée. Le répondant DOIT retourner une indication d'erreur NHRP du type Extension non reconnue si il est incapable de traiter l'extension. Cependant, si un NHS de transit (un de deux qui ne va pas générer de réponse) détecte une extension non reconnue, il DEVRA ignorer l'extension.
3 – Boucle NHRP détectée
Une erreur Boucle détectée est générée lorsque il est déterminé que le paquet NHRP est transmis en boucle.
6 – Adresse de protocole inaccessible
Cette erreur survient lorsque un paquet se déplace le long du chemin déterminé et qu'il atteint un point tel que l'adresse de protocole qui l'intéresse est inaccessible.
7 – Erreur de protocole
Une erreur générique de traitement de paquet est survenue (par exemple, numéro de version invalide, type de protocole invalide, échec de somme de contrôle, etc.)
8 – Taille de DDU NHRP dépassée
Si la taille de la SDU du paquet NHRP excède la taille de la MTU du réseau NBMA, cette erreur est alors retournée.
9 – Extension invalide
Si un NHS trouve dans un paquet une extension qui est inappropriée au type de paquet, une erreur est renvoyée à l'expéditeur avec le code Extension invalide.
10 - Réponse de résolution NHRP invalide reçue
Si un client reçoit une réponse de résolution NHRP pour une demande de résolution du prochain bond qu'il pense n'avoir pas envoyée, un paquet d'erreur est envoyé à la station qui fait la réponse avec un code d'erreur Réponse invalide reçue.
11 – Échec d'authentification
Si un paquet reçu échoue à une vérification d'authentification, cette erreur est alors retournée.
15 – Compte des bonds dépassé
Le compte des bons qui était spécifié dans l'en-tête fixe d'un message NHRP a été dépassé.
Décalage d'erreur
Le décalage en octets dans le paquet NHRP original dans lequel l'erreur a été détectée. Ce décalage est calculé en commençant à l'en-tête fixe NHRP.
Adresse NBMA de source
Le champ adresse NBMA de source est l'adresse de la station qui observe l'erreur.
Sous-adresse NBMA de source
Le champ Sous-adresse NBMA de source est l'adresse de la station qui observe l'erreur. Si la longueur du champ telle que spécifiée dans ar$sstl est 0 aucun espace de mémorisation n'est alloué pour cette adresse.
Adresse de protocole de source
C'est l'adresse de protocole de la station qui a produit le paquet d'erreur.
Adresse de protocole de destination
C'est l'adresse de protocole de la station qui envoie le paquet qui se trouve être erroné.
Un paquet d'indication d'erreur NHRP NE DOIT JAMAIS être généré en réponse à un autre paquet d'indication d'erreur NHRP. Lorsque un paquet d'indication d'erreur NHRP est généré, le paquet NHRP en cause DEVRA être éliminé. En aucun cas plus d'un paquet d'indication d'erreur NHRP ne doit être généré pour un seul paquet NHRP.
Si un NHS voit sa propre adresse de protocole et son adresse NBMA dans les champs d'adresse de source NBMA et de protocole de source d'un paquet d'indication d'erreur NHRP en transit, le NHS doit abandonner le paquet en douceur et ne rien faire (ce scénario va se produire lorsque le paquet d'indication d'erreur NHRP se trouve lui-même en boucle).
Noter qu'aucune extension ne peut être ajoutée à une indication d'erreur NHRP.
La partie Extensions, si elle est présente, porte une ou plusieurs extensions en triplets {Type, Longueur, Valeur}.
Les extensions ont le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Longueur |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valeur.. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C
"Obligatoire." Si il est à zéro, et si le NHS ne reconnaît pas le code de type, l'extension peut être ignorée en toute sécurité. Si il est à 1, et si le NHS ne reconnaît pas le code de type, la "demande" NHRP est considérée comme une erreur. (Voir les détails ci-dessous.)
u
Non utilisé, doit être à zéro.
Type
C'est le code du type d'extension (voir ci-dessous). Le type d'extension n'est pas qualifié par le bit Obligatoire, mais il lui est orthogonal.
Longueur
La longueur en octets de la valeur (non inclus les champs Type et Longueur; une extension nulle aura seulement un en-tête d'extension et une longueur de zéro).
Lorsque des extensions existent, la liste des extensions est terminée par le TLV nul, avec Type = 0 et Longueur = 0.
Les extensions peuvent survenir dans n'importe quel ordre, mais un type d'extension particulier ne peut survenir qu'une seule fois dans le paquet NHRP sauf mention explicite contraire dans la définition des extensions. Par exemple, l'extension Fabricant prive peut survenir plusieurs fois dans un paquet afin de permettre de représenter des extensions qui ne partagent pas le même identifiant de fabricant. Il est RECOMMANDÉ qu'un fabricant donné n'inclue pas plus d'une extension de fabricant prive.
Un NHS NE DOIT PAS changer l'ordre des extensions. C'est à dire que l'ordre des extensions placées dans le paquet NHRP par un NHC (ou par un NHS quand un NHS est la source d'un paquet) DOIT être préservé lorsque le paquet se déplace entre les NHS. Les mises en œuvre minimales de NHC DOIVENT seulement reconnaître, mais pas nécessairement analyser, les extensions de fabricant privé et de Fin des extensions. Les extensions ne sont présentes dans une "réplique" que si elles étaient présentes dans la "demande" correspondante à l'exception des extensions de fabricant prive. La déclaration précédente n'est pas destinée à empêcher la création d'extensions seulement de NHS qui pourraient être ajoutée et retirées des paquets NHRP par le même NHS ; de telles extensions NE DOIVENT PAS être propagées aux NHC.
Le bit Obligatoire donne le moyen d'ajouter à l'ensemble des extensions. Si le bit est mis dans une extension, la station qui répond au message NHRP qui contient cette extension DOIT être capable de comprendre l'extension (dans ce cas, la station qui répond au message est la station qui produirait une réplique NHRP en réponse à une demande NHRP). Il en résulte que le répondant DOIT retourner une Indication d'erreur NHRP du type Extension non reconnue. Si le bit Obligatoire est à zéro, l'extension peut alors être ignorée en toute sécurité ; cependant, si une extension ignorée est dans une "demande" elle DOIT alors être retournée, inchangée, dans le type de paquet de "réponse" correspondant.
Si un NHS de transit (qui ne va pas générer de "réplique") détecte une extension non reconnue, il DEVRA ignorer l'extension. Si le bit Obligatoire est mis, le NHS de transit NE DOIT PAS mettre en antémémoire les informations contenues dans le paquet et NE DOIT PAS s'identifier comme routeur de sortie (dans les extensions Enregistrement vers l'avant ou Enregistrement vers l'arrière). Effectivement, cela signifie que si un NHS de transit rencontre une extension qu'il ne peut pas traiter et qui a le bit Obligatoire établi, ce NHS NE DOIT PAS participer d'une façon quelconque à l'échange de protocole autrement qu'en agissant comme agent de transmission.
L'espace des types d'extension NHRP est subdivisé pour encourager son utilisation en dehors de l'IETF.
0x0000 - 0x0FFF |
Réservé pour NHRP. |
0x1000 - 0x11FF |
Alloué au forum ATM. |
0x1200 - 0x37FF |
Réservé à l'IETF. |
0x3800 - 0x3FFF |
Utilisation expérimentale. |
L'IANA administrera les gammes réservées à l'IETF comme décrit à la Section 9. Les valeurs dans la gamme 'Utilisation expérimentale' n'ont qu'uns signification locale.
Obligatoire = 1
Type = 0
Longueur = 0
Lorsque des extensions existent, la liste des extensions se termine par le TLV Fin d'extension/Nul.
Obligatoire = 1
Type = 3
Longueur = variable
Cette extension est utilisée pour déterminer l'adresse du NHRP répondant ; c'est-à-dire, l'entité qui a généré le paquet de "réplique" approprié pour un paquet de "demande" donné. Dans le cas d'une demande de résolution NHRP, la station qui répond peut être différente (dans le cas de réponses mises en antémémoire) du système identifié dans le champ prochain bond de la réponse de résolution NHRP. De plus, cette extension peut aider à détecter des boucles dans le chemin de transmission NHRP.
Cette extension utilise un seul CIE dont la signification des champs spécifiques d'extension est établie comme suit :
Les champs Longueur de préfixe DOIVENT être mis à 0 et ignorés.
Code de CIE
5 – Ressources insuffisantes
Si celui qui répond à une demande de résolution NHRP est un point de sortie pour la cible de la demande de résolution d'adresse (c'est-à-dire, si c'est une des stations identifiées dans la liste des CIE dans une réponse de résolution NHRP) et si l'extension Adresse du répondant est incluse dans la demande de résolution NHRP et que des ressources insuffisantes pour établir un VC raccourci existent chez celui qui répond, le champ Code de l'extension d'adresse du répondant est réglé à 5 afin de dire au client qu'une tentative d'établissement d'un VC serait vraisemblablement vouée au rejet ; autrement, ce champ DOIT être codé comme un zéro. Les NHC PEUVENT utiliser ce champ pour influencer une tentative d'établissement d'un raccourci vers le routeur de sortie.
Unité de transmission maximum
Ce champ donne l'unité de transmission maximum préférée du répondant. Si cette valeur est 0, soit la MTU par défaut est utilisée, soit c'est la MTU négociée via la signalisation si une telle négociation est possible pour le NBMA en question.
Temps de garde
Le champ Temps de garde spécifie le nombre de secondes pendant lequel les informations de NBMA du répondant sont considérées comme valides. Les informations mises en antémémoire DEVRONT être éliminées à l'expiration du temps de garde.
Les informations "Adresse de client" sont en fait les informations de "Adresse du répondant" pour cette extension. Et donc, par exemple, Cli Addr T/L est le champ de type et longueur d'adresse NBMA du répondant.
Si un "demandeur" désire cette information, le "demandeur" DEVRA inclure cette extension avec une valeur de zéro. Noter que cela implique qu'aucun espace de mémorisation n'est alloué pour ces champs Temps de garde et Type/Longueur jusqu'à ce que la portion "Valeur" de l'extension soit remplie.
Si un NHS génère un paquet "réplique" en réponse à une "demande" contenant cette extension, le NHS DEVRA inclure cette extension, en mettant son adresse de protocole dans la "réplique". Si un NHS a plus d'une adresse de protocole, il DEVRA utiliser de façon cohérente la même adresse de protocole dans toutes les extensions Adresse du répondant, Enregistrement de NHS de transit vers l'avant et Enregistrement du NHS de transit vers l'arrière. Le choix de l'adresse de protocole à inclure dans cette extension est une affaire locale.
Si un paquet de réponse de résolution NHRP transmis par un NHS contient une adresse de protocole de ce NHS dans l'extension Adresse du répondant, ce NHS DEVRA générer une indication d'erreur NHRP du type "Boucle NHRP détectée" et éliminer la réponse de résolution NHRP.
Si un paquet de réponse de résolution NHRP est retourné par un NHS intermédiaire sur la base de données en antémémoire, il DEVRA placer sa propre adresse dans cette extension (la différenciant de l'adresse dans le champ Prochain bond).
Obligatoire = 1
Type = 4
Longueur = variable
L'enregistrement NHRP de NHS de transit vers l'avant contient une liste des NHS de transit par lesquels est passée une "demande". Chaque NHS DEVRA ajouter à l'extension un élément NHS de transit vers l'avant (comme spécifié ci-dessous) contenant son adresse de protocole. Le champ Longueur d'extension et le champ ar$chksum DEVRAONT être ajustés en conséquence.
Le NHS répondant, comme décrit au paragraphe 5.3.1, NE DEVA PAS mettre à jour cette extension.
De plus, les NHS qui veulent agir comme routeurs de sortie pour les paquets de la source vers la destination DEVRONT inclure des informations sur leur adresse NBMA.
Cette extension utilise un seul CIE par élément d'enregistrement de NHS avec la signification suivante des champs spécifiques de l'extension :
Les champs Longueur de préfixe DOIVENT être mis à 0 et ignorés.
Code de CIE
5 – Ressources insuffisantes
Si une demande de résolution NHRP contient une extension d'enregistrement NHRP de NHS de transit vers l'avant et que des ressources insuffisantes pour établir un VC raccourci existent chez le NHS de transit actuel, le champ Code de CIE pour l'extension d'enregistrement NHRP de NHS de transit vers l'avant est réglé à 5 afin de dire au client qu'une tentative d'établissement d'un VC serait vraisemblablement vouée au rejet ; autrement, ce champ DOIT être codé comme un zéro. Les NHC PEUVENT utiliser ce champ pour influencer une tentative d'établissement d'un raccourci comme décrit au paragraphe 2.2. Noter que l'extension d'enregistrement NHRP de NHS de transit vers l'arrière DOIT toujours avoir ce champ mis à zéro.
Unité de transmission maximum
Ce champ donne l'unité de transmission maximum préférée du NHS de transit. Si cette valeur est 0, soit la MTU par défaut est utilisée, soit c'est la MTU négociée via la signalisation si une telle négociation est possible pour le NBMA en question.
Temps de garde
Le champ Temps de garde spécifie le nombre de secondes pendant lequel les informations de NBMA du NHS de transit sont considérées comme valides. Les informations mises en antémémoire DEVRONT être éliminées à l'expiration du temps de garde.
Les informations "Adresse de client" sont en fait les informations de "Adresse du NHS de transit vers l'avant" pour cette extension. Et donc, par exemple, Cli Addr T/L est le champ de type et longueur d'adresse NBMA du NHS de transit.
Si un "demandeur" désire obtenir cette information, il DEVRA inclure cette extension avec une valeur de zéro. Noter que cela implique qu'aucun espace de mémorisation n'est alloué pour ces champs Temps de garde et Type/Longueur jusqu'à ce que la portion "Valeur" de l'extension soit remplie.
Si un NHS a plus d'une adresse de protocole, il DEVRA utiliser la même adresse de protocole de façon cohérente dans toutes les extensions Adresse du répondant, Enregistrement de NHS vers l'avant, et Enregistrement de NHS inverse. Le choix de l'adresse de protocole à inclure dans cette extension est une affaire locale.
Si une "demande" qui est transmise par un NHS contient l'adresse de protocole de ce NHS dans un des éléments du NHS de transit vers l'avant, le NHS DEVRA alors générer une indication d'erreur NHRP du type "Boucle NHRP détectée" et éliminer la "demande".
Obligatoire = 1
Type = 5
Longueur = variable
L'enregistrement NHS de transit inverse contient une liste de NHS de transit à travers lesquels une "réplique" est passée. Chaque NHS DEVRA ajouter à cette extension un élément NHS de transit inverse (comme spécifié ci-dessous) contenant son adresse de protocole. Le champ Longueur d'extension et le champ ar$chksum DEVRONT être ajustés en conséquence.
Le NHS répondant, comme décrit au paragraphe 5.3.1, NE DEVRA PAS mettre à jour cette extension.
De plus, les NHS qui veulent agir comme routeurs de sortie pour les paquets allant de la source à la destination DEVRONT inclure des informations sur leur adresse NBMA.
Cette extension utilise un seul CIE par élément d'enregistrement de NHS dont la signification des champs spécifiques de l'extension est réglée comme suit :
Les champs Code de CIE et Longueur de préfixe DOIVENT être mis à 0 et ignorés.
Unité de transmission maximum
Ce champ donne l'unité de transmission maximum préférée par le NHS de transit. Si cette valeur est 0 on utilise alors soit la MTU par défaut soit la MTU négociée via la signalisation si une telle négociation est possible pour le NBMA en question.
Temps de garde
Le champ Temps de garde spécifie le nombre de seconde pendant lequel les informations de NMBA du NHS de transit sont considérées comme valides. Les informations en antémémoire DEVRONT être éliminées à l'expiration du temps de garde.
Les informations de "Adresse du client" sont en fait les informations de "Adresse de NHS de transit inverse" pour cette extension. Et donc par exemple, Cli Addr T/L est le champ Type et Longueur d'adresse NBMA du NHS de transit.
Si un "demandeur" souhaite obtenir ces informations, il DEVRA inclure cette extension avec une longueur de zéro. Noter que cela implique qu'aucun espace de mémorisation n'est alloué aux champs Temps de garde et Type/Longueur jusqu'à ce que la portion "Valeur" de l'extension soit remplie.
Si un NHS a plus d'une adresse de protocole, il DEVRA utiliser la même adresse de protocole de façon cohérente dans toutes les extensions Adresse du répondant, Enregistrement de NHS vers l'avant, et Enregistrement de NHS inverse. Le choix de l'adresse de protocole à inclure dans cette extension est une affaire locale.
Si une "réplique" qui est transmise par un NHS contient l'adresse de protocole de ce NHS dans un des éléments du NHS de transit inverse, le NHS DEVRA alors générer une indication d'erreur NHRP du type "Boucle NHRP détectée" et éliminer la "réplique".
Noter que cette information peut être mise en antémémoire chez des NHS intermédiaires ; s'il en est ainsi, la valeur mise en antémémoire DEVRA être utilisée lors de la génération d'une réplique.
Obligatoire = 1 Type = 7 Longueur = variable
L'extension d'authentification NHRP est portée dans les paquets NHRP pour convoyer les informations d'authentification entre ceux qui parlent NHRP. L'extension d'authentification ne peut être incluse que dans une "demande" ou "réplique" NHRP.
L'authentification est toujours faite d'homologue à homologue bond NHRP par bond NHRP ; c'est-à-dire que l'extension d'authentification est régénérée à chaque bond. Si un paquet reçu échoue à l'essai d'authentification, la station DEVRA générer une indication d'erreur du type "Échec d'authentification" et éliminer le paquet. Note qu'un échec d'authentification possible est l'absence de l'extension d'authentification ; la présence ou l'absence de l'extension d'authentification est une affaire locale.
5.3.4.1 Format d'en-tête
L'en-tête d'authentification a le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Réservé |Indice param. de sécurité (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse de source..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-Données d'authentification.... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L'indice de paramètre de sécurité (SPI) peut être vu comme un indice dans un tableau qui conserve les clés et autres informations comme un algorithme de hachage. Source et destination communiquent soit hors ligne en utilisant des clés manuelles ou en ligne en utilisant un protocole de gestion de clés pour remplir ce tableau. L'entité NHRP qui envoie alloue toujours le SPI et les paramètres qui lui sont associés.
Adresse de source est un champ de longueur variable qui contient l'adresse allouée à l'interface de sortie. La longueur de l'adresse est obtenue du champ Longueur de protocole de source dans la partie obligatoire de l'en-tête NHRP. Le couple <spi, adresse de source> identifie de façon univoque la clé et les autres paramètres qui sont utilisés dans l'authentification.
La longueur du champ de données d'authentification dépend de l'algorithme de hachage utilisé. Le champ de données contient la clé de hachage calculée sur la charge utile NHRP entière. Le champ des données d'authentification est complété de zéros avant le calcul du hachage.
5.3.4.2 Négociation des paramètres SPI et Sécurité
Les SPI peuvent être négociés manuellement ou en utilisant un protocole de gestion de clés Internet. L'introduction manuelle des clés DOIT être acceptée. Les paramètres suivants sont associés au multiplet <SPI, src>- durée de vie, algorithme, clé. La durée de vie indique la durée en secondes pendant laquelle la clé est valide. Dans le cas d'introduction manuelle de la clé, cette durée peut être infinie. Aussi, afin de mieux prendre en charge l'introduction manuelle de la clé, il peut y avoir plusieurs multiplets actifs en même temps (la destination étant la même).
Algorithm spécifie l'algorithme de hachage sur lequel les deux entités se sont accordées. HMAC-MD5-128 [16] est l'algorithme par défaut. D'autres algorithmes PEUVENT être pris en charge en définissant de nouvelles valeurs. L'IANA allouera les numéros pour identifier l'algorithme utilisé comme décrit à la Section 9.
Tout protocole de gestion de clé standard de l'Internet PEUT ainsi être utilisé pour négocier le SPI et les paramètres.
5.3.4.3 Traitement de message
Au moment de l'ajout de l'en-tête d'extension d'authentification, la source fait une recherche dans un tableau pour aller chercher le SPI et les paramètres de sécurité sur la base de l'adresse de l'interface sortante. Si il n'y a pas d'entrées dans le tableau et si il n'y a pas de prise en charge de la gestion de clés, la source initie le protocole de gestion de clé pour aller chercher les paramètres nécessaires. La source construit la charge utile d'extension d'authentification et calcule le hachage en mettant à zéro le champ de données d'authentification. Le résultat est replacé dans le champ de données d'authentification qui avait été mis à zéro. Le champ d'adresse de source dans la charge utile est l'adresse IP allouées à l'interface sortante.
Si la gestion de clés n'est pas prise en charge et si l'authentification est obligatoire, le paquet est abandonné et cette information est enregistrée.
Du côté réception, la destination va chercher les paramètres sur la base du SPI et de l'adresse IP dans la charge utile d'extension d'authentification. Le champ des données d'authentification est extrait avant de mettre à zéro pour le calcul du hachage. Elle calcule le hachage sur la charge utile entière et si le hachage ne correspond pas, un "événement anormal" est survenu.
5.3.4.4 Considérations pour la sécurité
Il est important que les clés choisies soient fortes car la sécurité de tout le système dépend du choix approprié des clés et de la mise en œuvre correcte des algorithmes.
La sécurité est réalisée bond par bond. Les données reçues ne peuvent être de confiance que pour autant qu'on puisse se fier à toutes les entités du chemin parcouru. Une chaîne de confiance est établie entre les entités NHRP du chemin du message NHRP. Si la sécurité d'une entité NHRP est compromise, c'est la sécurité de tout le domaine NHRP qui est compromise.
L'intégrité des données couvre toute la charge utile NHRP. Cela garantit que le message n'a pas été modifié et authentifie aussi la source. Si l'extension d'authentification n'est pas utilisée ou si la sécurité est compromise, les entités NHRP sont alors susceptibles d'attaques par mystification, aussi bien actives que passives.
Il n'y a pas de mécanisme de chiffrement des messages. On suppose qu'un mécanisme standard de confidentialité de couche 3 sera utilisé pour chiffrer et déchiffrer les messages. Il est recommandé d'utiliser un protocole Internet standard de gestion de clés pour négocier les clés entre les voisins. La transmission des clés en clair, si d'autres méthodes de négociation sont utilisées, compromet complètement la sécurité.
Tout NHS est susceptible d'attaques de déni de service (DOS) qui font qu'il devient surchargé, empêchant les paquets légitimes d'être traités correctement. Un hôte pirate peut envoyer des paquets de demande et d'enregistrement au NHS du premier bond. Si l'option d'authentification n'est pas utilisée, le paquet d'enregistrement est transmis le long du chemin déterminé et exige d'être traité tout le long du chemin par chaque NHS. Si l'option d'authentification est utilisé, seul le NHS du premier bond est susceptible d'attaques de DOS (c'est-à-dire que les paquets non authentifiés seront éliminés plutôt que transmis). Si la sécurité d'un hôte est compromise (c'est-à-dire, sui les clés qu'il utilise pour communiquer avec un NHS sont divulguées), un hôte pirate peut envoyer les paquets NHRP au NHS du premier bond de l'hôte dont les clés ont été compromises, qui va alors les transmettre le long du chemin déterminé comme dans le cas de paquets non authentifiés. Cependant, cette attaque exige que l'hôte pirate ait le même NHS de premier bond que l'hôte compromis. Finalement, on devrait noter que les attaques de déni de service qui causent une consommation des ressources des routeurs sur le chemin déterminé en traitant les paquets NHRP sont aussi susceptibles d'attaques qui inondent de paquets la même destination que celle contenue dans le champ d'adresse de protocole de destination du paquet NHRP.
Obligatoire = 0
Type = 8
Longueur = variable
L'extension de fabricant privé NHRP est portée dans les paquets NHRP pour convoyer les informations de fabricant privé ou les extensions NHRP entre entités qui parlent NHRP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de fabricant | Données. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifiant de fabricant
Identifiant 802 de fabricant alloué par l'IEEE [6]
Données
Les octets restants après l'identifiant de fabricant dans la charge utile sont des données qui dépendent du fabricant.
Cette extension peut être ajoutée à tout paquet de "demande" ou "réplique" et c'est la seule extension qui peut être incluse plusieurs fois. Si le receveur ne traite pas cette extension, ou ne correspond pas à l'identifiant de fabricant de l'extension, celle-ci peut être complètement ignorée du receveur. Si une extension de fabricant privé est incluse dans une "demande", elle doit alors être copiée dans la "réplique" correspondante.
6. Fonctionnement du protocole
La présente section expose certaines considérations sur le fonctionnement de NHRP.
6.1 Fonctionnement de routeur à routeur
En pratique, les stations initiatrice et répondante peuvent être des hôtes ou des routeurs. Cependant, il y a une possibilité dans certaines conditions que surviennent une boucle d'acheminement stable si NHRP est utilisé entre deux routeurs. En particulier, tenter d'établir un chemin NHRP à travers une frontière où les informations utilisées pour le choix du chemin sont perdues peut résulter en une boucle d'acheminement. De telles situations incluent la perte des informations de vecteur de chemin BGP, l'interfonctionnement de plusieurs protocoles d'acheminement avec des métriques dissemblables (par exemple, RIP et OSPF), etc. Dans de telles circonstances, NHRP ne devrait pas être utilisé. Cette situation peut être évitée si il n'y a pas de chemins "détournés" entre les routeur d'entrée et de sortie en dehors du sous-réseau NBMA. Les mécanismes de protocole pour atténuer ces restrictions sont en cours d'étude.
En général il est préférable d'utiliser des mécanismes, si ils existent, dans les protocoles d'acheminement pour résoudre le point de sortie lorsque la destination se tient en-dehors du sous-réseau NBMA, car de tels mécanismes seront moins étroitement couplés à l'état du système d'acheminement et seront probablement moins susceptibles de créer des boucles.
6.2 Problème de la gestion des antémémoires
La gestion des antémémoires de NHRP dans la station de source, le NHS desservant la destination, et tous les NHS intermédiaires dépendent d'un certain nombre de facteurs.
Stations de source
Les stations de source DOIVENT mettre en antémémoire toutes les répliques de résolution NHRP reçues qu'ils utilisent activement. Elles doivent aussi mettre en antémémoire les entrées "incomplètes", c'est-à-dire, celles pour lesquelles une demande de résolution NHRP a été envoyé mais pour lesquelles une réponse de résolution NHRP n'a pas encore été reçue. Cela est nécessaire afin de préserver l'identifiant de demande pour les nouveaux essais, et fournir l'état nécessaire pour éviter de déclancher des demandes de résolution NHRP pour chaque paquet de données envoyé à la destination.
Les stations de source DOIVENT purger les information arrivées à expiration de leurs antémémoires. Les stations de source DOIVENT purger les informations d'antémémoire appropriées à réception d'un paquet de demande de purge NHRP.
Lorsque une station a un NHC et un NHS corésidents, le NHS corésident peut répliquer à des demandes de résolution NHRP provenant du NHC corésident avec des informations que la station a placé en antémémoire par suite des propres demandes de résolution NHRP du NHC corésident NHC pour autant que le NHS corésident suivent les règles des NHS de transit exposées plus haut.
NHS desservants
Le NHS qui dessert la destination (celui qui répond aux demandes de résolution NHRP d'autorité) DEVRAIT mettre en antémémoire les informations d'adresse de protocole provenant de toutes les demandes de résolution NHRP auxquelles il a répondu si les informations dans la réponse de résolution NHRP ont la possibilité de changer durant sa durée de vie (afin qu'un paquet de demande de purge NHRP puisse être produit). L'inter réseautage avec les informations de lien NBMA fournies par la station de source dans la demande de résolution NHRP peut aussi être mise en antémémoire si et seulement si le bit "S" est établi, si la demande de résolution NHRP a inclus un CIE avec le champ Temps de garde réglé à une valeur positive (c'est le temps de garde valide pour le line de source), et seulement pour une utilisation qui n'est pas d'autorité pour une période qui ne peut excéder le temps de garde.
NHS de transit
Un NHS de transit (qui se trouve sur le chemin NHRP entre la station de source et le NHS répondant) peut mettre en antémémoire les informations de lien de source contenues dans les paquets de demande de résolution NHRP qu'il transmet si et seulement si le bit "S" bit est établi, si la demande de résolution NHRP a inclus un CIE avec le champ Temps de garde supérieur à zéro (c'est le temps de garde valide pour le lien de source) et seulement pour une utilisation qui n'est pas d'autorité pour une période qui ne peut excéder le temps de garde.
Un NHS de transit peut mettre en antémémoire les informations de destination contenues dans un CIE de réponse de résolution NHRP si et seulement si le bit D est établi et alors seulement pour une utilisation qui n'est pas d'autorité et pour une période n'excédant pas la valeur du temps de garde contenue dans le CIE. Un NHS de transit NE DOIT PAS mettre en antémémoire les informations de lien de source contenues dans une réponse de résolution NHRP.
De plus, un NHS de transit DOIT éliminer toutes les informations en antémémoire lorsque le temps prescrit est arrivé à expiration. Il ne peut retourner les informations en antémémoire qu'en réponse à des demandes de résolution NHRP qui ne sont pas d'autorité.
Destinations connectées à NBMA
La fonction la plus basique de NHRP est celle de la simple résolution d'adresse NBMA de stations directement rattachées au sous-réseau NBMA. Ces transpositions sont normalement très statiques, et des temps de garde choisis de façon appropriée vont minimiser les problèmes dans le cas où l'adresse NBMA d'une station doit être changée. Les informations d'état vont causer une perte de connexité, qui peut être utilisée pour déclancher une demande de résolution NHRP d'autorité et outrepasser les anciennes données. Dans le pire des cas, la connexité va être défaillante jusqu'à ce que les entrées d'antémémoire arrivent en fin de vie.
Cela s'applique également aux informations marquées dans les réponse de résolution NHRP comme étant "stables" (via le bit "D").
Destinations hors du sous-réseau NBMA
Si la source d'une demande de résolution NHRP est un hôte et si la destination n'est pas directement rattachée au sous-réseau NBMA, et si le chemin vers cette destination n'est pas considérée comme "stable", la transposition de la destination peut être très dynamique (excepté dans le cas d'un sous-réseau où chaque destination est seulement à rattachement unique sur le sous-réseau NBMA). Comme telles; les informations en antémémoire vont très vraisemblablement se périmer. La conséquence d'informations périmées dans ce cas sera un chemin sous optimal (à moins que l'inter réseautage se soit partitionné ou que quelque autre défaillance d'acheminement soit survenue).
6.3 Utilisation du champ Longueur de préfixe d'un CIE
Une certaine attention doit être apportée à l'utilisation du champ Longueur de préfixe d'un CIE, en particulier en ce qui concerne la longueur du préfixe annoncée (et donc à la taille de la classe d'équivalence qu'il spécifie). En supposant que les routeurs sur le sous-réseau NBMA échangent les informations d'acheminement, il ne devrait pas être possible à un NHS de créer un trou noir en annonçant un trop grand ensemble de destinations, mais un acheminement sous optimale (par exemple, des bonds supplémentaires de couche internet à travers le NBMA) peuvent en résulter. Pour éviter cette situation, un NHS qui veut envoyer la longueur de préfixe DOIT respecter la règle suivante :
Le NHS examine les informations d'accessibilité de la couche réseau (NLRI, Network Layer Reachability Information) associées au chemin que le NHS utiliserait pour transmettre vers la destination (comme spécifié par l'adresse de couche inter-réseau de destination dans la demande de résolution NHRP), et extrairait de ces NLRI le plus court préfixe d'adresse tel que : (a) l'adresse de couche inter-réseau de destination (d'après la demande de résolution NHRP) est couverte par le préfixe, (b) le NHS n'a aucun chemin avec les NLRI qui forme un sous-ensemble de ce qui est couvert par le préfixe. Le préfixe peut alors être utilisé dans le CIE.
Le champ Longueur de préfixe du CIE devrait être utilisé avec modération, afin d'éviter que les stations NHRP choisissent des chemins de transit sous optimaux lorsque des chevauchement de préfixes sont disponibles. Le présent document spécifie l'utilisation de la longueur de préfixe seulement quand toutes les destinations couvertes par le préfixe sont "stables". C'est à dire que soit :
(a) toutes les destinations couvertes par le préfixe sont sur le réseau NBMA, soit
(b) toutes les destinations couvertes par le préfixe sont directement rattachées à la station NHRP répondante.
L'utilisation du champ Longueur de préfixe du CIE dans d'autres circonstances sort du domaine d'application du présent document.
On peut facilement imaginer une situation dans laquelle un routeur, agissant comme station d'entrée au sous-réseau NBMA, reçoit un paquet de données, de telle sorte que ce paquet déclanche une demande de résolution NHRP. Si le routeur transmet ce paquet de données sans attendre qu'un chemin de transit NHRP soit établis, lorsque le prochain routeur le long du chemin reçoit le paquet, le prochain routeur peut agir exactement de même – générant sa propre demande de résolution NHRP (aussi bien que transmettre le paquet). En fait, un tel paquet de données peut déclancher la génération d'une demande de résolution NHRP à chaque routeur le long du chemin à travers un sous-réseau NBMA. On appelle ce phénomène l'effet "domino" NHRP.
L'effet domino NHRP est évidement indésirable. Au mieux, il peut résulter en un trafic NHRP excessif. Au pire, il peut résulter en l'établissement d'un nombre excessif de circuits virtuels sans nécessité. Donc, il est important de prendre certaines mesures pour éviter ou supprimer ce comportement. Les mises en œuvre de NHRP pour les NHS DOIVENT fournir un mécanisme pour régler ce problème. Une stratégie possible pour ce faire serait de configurer un routeur de telle façon que la génération des demandes de résolution NHRP par le routeur soit pilotée seulement par le trafic que le routeur reçoit sur ses interfaces non NBMA (interfaces qui ne sont pas rattachées à un sous-réseau NBMA). Le trafic reçu par le routeur sur ses interfaces rattachées à NBMA ne déclancheraient pas de demandes de résolution NHRP. Un tel routeur éviterait l'effet domino NHRP par des moyens administratifs.
7. NHRP sur les réseaux BMA traditionnels
Il apparaît qu'aucun empêchement significatif ne s'oppose au fonctionnement de NHRP sur les sous réseaux de diffusion traditionnels. Il peut y avoir des problèmes à faire fonctionner NHRP à travers plusieurs sous-réseaux. Le fonctionnement de NHRP sur un support de diffusion offre quelques possibilités intéressantes ; en particulier lors de l'établissement d'un raccourci pour du trafic inter-ELAN inter-LIS/LAG lorsque une station ou les deux sont rattachées de façon traditionnelle. Cette utilisation de NHRP exige des études complémentaires.
Le résultat d'une demande de résolution NHRP dépend de la façon dont l'acheminement est configuré parmi les NHS d'un sous-réseau NBMA. Si la station de destination est directement connectée au sous-réseau NBMA et si le chemin vers lui est entièrement compris dans le sous-réseau NBMA, les réponses de résolution NHRP retournent toujours l'adresse NBMA de la station de destination elle-même plutôt que l'adresse NBMA d'un routeur de sortie. D'un autre côté, si le chemin sort du sous-réseau NBMA, NHRP sera incapable de résoudre l'adresse NBMA de la destination, mais retournera plutôt l'adresse du routeur de sortie. Pour les destinations extérieures au sous-réseau NBMA, les routeurs de sortie et les routeurs dans les autres sous-réseaux devraient échanger des informations d'acheminement afin de trouver les meilleurs routeurs de sortie.
En plus des NHS, une station NBMA pourrait aussi être associée à un ou plusieurs routeurs réguliers qui pourraient agir comme "serveurs sans connexion" pour la station. La station pourrait alors choisir de résoudre le prochain bond NBMA ou juste d'envoyer les paquets à un de ses serveurs sans connexion. Cette dernière option peut être souhaitable si la communication avec la destination est de courte durée de vie et/ou n'exige pas beaucoup de ressources réseau. Les serveurs sans connexion pourraient, bien sûr, être physiquement intégrés dans les NHS en les agrémentant de fonctionnalités de commutation de couche inter réseautage.
9. Considérations relatives à l'IANA
L'IANA prendra l'avis de l'expert sur le sujet désigné par le directeur de zone afin d'allouer des numéros dans les divers espaces numériques décrits ici. Dans le cas où l'expert sur le sujet désigné par le directeur de zone serait indisponible, le directeur de zone de l'IESG pertinent désignera un autre expert. Toutes les demandes d'allocation de valeur au sein d'un espace numérique donné seront acceptées lorsque l'usage de l'allocation de valeur sera documenté. Les formes possibles de documentation incluent, mais ne s'y limitent pas, les RFC ou le produit d'un autre organisme de normalisation coopératif (par exemple, les groupes de travail MPOA et LANE du Forum ATM).
Références
[1] J. Heinanen, R. Govindan, "Protocole de résolution d'adresse NBMA (NARP)", RFC 1735, décembre 1994. (Exp.)
[2] D. Plummer, "Protocole de résolution d’adresses Ethernet : conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur un matériel Ethernet", RFC 826, STD 37, novembre 1982.
[3] M. Laubach, J. Halpern, "IP et ARP classiques sur ATM", RFC 2225, avril 1998. (Norme proposée.).
[4] D. Piscitello et J. Lawrence, "Transmission de datagrammes IP sur le service SMDS", RFC 1209, STD 52, mars 1991.
[5] "Identification du protocole dans la couche réseau", ISO/CEI TR 9577:1990.
[6] J. Reynolds et J. Postel, "Numéros alloués", STD 2, RFC 1700, octobre 1994. (Historique)
[7] Juha Heinanen, "Encapsulation multi protocole sur couche 5 d'adaptation ATM", RFC 1483, juillet 1993, (remplacée par la RFC 2684).
[8] A. Malis, D. Robinson et R. Ullmann, "Interconnexion multi protocoles sur X.25 et RNIS en mode paquet", RFC 1356, août 1992.
[9] T. Bradley, C. Brown et A. Malis, "Interconnections multi protocoles sur relais de trame", RFC 1490, juillet 1993. (Remplacée par la RFC 2427).
[10] Y. Rekhter, D. Kandlur, "Décision de transmission "locale/distante" dans les sous-réseaux de liaisons de données commutées", RFC 1937, mai 1996. (Information).
[11] G. Armitage, "Prise en charge de la diffusion groupée sur réseaux ATM fondés sur UNI 3.0/3.1", RFC 2022, novembre 1996. (P.S.).
[12] J. Luciani, G. Armitage et J. Halpern, "Protocole de synchronisation d'antémémoire de serveur (SCSP) - NBMA", RFC 2334, avril 1998.
[13] Y. Rekhter, "NHRP pour les destinations en sortie de sous-réseau NBMA", Travail en cours.
[14] J. Luciani, "Transition de IP classique à NHRP", RFC2336, juillet 1998. (Information)
[15] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.
[16] H. Krawczyk, M. Bellare et R. Canetti, "HMAC : Hachage de clés pour l'authentification de message", RFC 2104, février 1997.
Remerciements
Nous tenons à remercier (sans ordre particulier) Thomas Narten d'IBM pour ses commentaires à propos du rôle de Internet AD, Juha Heinenan de Telecom Finland et Ramesh Govidan de ISI pour leurs travaux sur NBMA ARP et sur le projet NHRP d'origine, qui a servi de base à ce document. Russell Gardo d'IBM, John Burnett de Adaptive, Dennis Ferguson de ANS, Andre Fredette de Bay Networks, Joel Halpern de Newbridge, Paul Francis de NTT, Tony Li, Bryan Gleeson et Yakov Rekhter de cisco, et Grenville Armitage de Bellcore doivent aussi être remerciés de leurs commentaires et suggestions qui ont substantiellement amélioré ce document. Nous tenons aussi à remercier les membres du groupe de travail ION de l'IETF, dont les relectures et discussions de ce document ont été précieuses.
Adresse des auteurs
James V. Luciani |
Dave Katz |
Naganand Doraswamy |
Bay Networks |
cisco Systems |
Bay Networks, Inc. |
3 Federal Street |
170 W. Tasman Dr. |
3 Federal Street |
Mail Stop: BL3-03 |
San Jose, CA 95134 USA |
Mail Stop: Bl3-03 |
Billerica, MA 01821 USA |
téléphone : +1 408 526 8284 |
Billerica, MA 01801 USA |
téléphone : +1 978 916 4734 |
mél : dkatz@cisco.com |
téléphone : +1 978 916 1323 |
mél : luciani@baynetworks.com |
|
mél : naganand@baynetworks.com |
David Piscitello |
Bruce Cole |
Core Competence |
Juniper Networks |
1620 Tuckerstown Road |
3260 Jay St. |
Dresher, PA 19025 USA |
Santa Clara, CA 95054 USA |
téléphone : +1 215 830 0692 |
téléphone : +1 408 327 1900 |
mél : dave@corecom.com |
mél : bcole@jnx.com |
Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (1998). Tous droits réservés.
Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.
Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.
Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.