Protocole de synchronisation d'antémémoire de serveur (SCSP) - NBMA

Statut du présent mémoire

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

Notice de Copyright

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

(La présente traduction incorpore l'errata 1922 du 21/10/2009)

Résumé

Le présent document décrit le protocole de synchronisation d'antémémoire de serveur (SCSP, Server Cache Synchronization Protocol) et il est écrit en termes d'utilisation de SCSP au sein de réseaux en multi accès sans diffusion (NBMA, Non Broadcast Multiple Access) ; bien qu'une utilisation assez directe soit applicable aux réseaux en multi accès en diffusion (BMA, Broadcast Multiple Access) SCSP essaye de résoudre le problème de la synchronisation/réplication généralisée d'antémémoire pour les entités de protocole réparties. Cependant, dans le présent document, SCSP est présenté sous la forme du paradigme client/serveur selon lequel les entités de serveur réparties, qui sont liées à un groupe de serveurs (SG, Server Group) par certains moyens, souhaitent synchroniser le contenu (ou une partie du contenu) de leurs antémémoires qui contiennent des informations sur l'état des clients desservis.

Table des Matières

1.   Introduction

2.   Généralités

2.1   Protocole Hello

2.2   Protocole d'alignement d'antémémoire

2.2.1   État de négociation maître/esclave

2.2.2   État Résumé d'antémémoire

2.2.3   État Mise à jour d'antémémoire

2.2.4   État Aligné

2.3   Protocole de mise à jour d'état d'antémémoire

2.4   Signification de"Plus à jour"/"Nouveauté"

Appendice A   Terminologie et définitions

Appendice B   Formats de message SCSP

B.1   Partie fixe

B.2.0   Partie obligatoire

B.2.1   Alignement d'antémémoire (CA)

B.2.2   Demande de mise à jour d'état d'antémémoire (Demande de CSU)  

B.2.3   Réponse de mise à jour d'état d'antémémoire (Réponse de CSU)  

B.2.4   Message Sollicitation de mise à jour d'état d'antémémoire (message CSUS)

B.2.5   Hello

B.3   Partie extensions

B.3.0   Fin des extensions

B.3.1   Extension d'authentification SCSP

B.3.2   Extension SCSP de fabricant privé

Appendice C.   Considérations relatives à l'IANA

Références

Remerciements

Adresse des auteurs

Déclaration complète de droits de reproduction

1.   Introduction

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 [10].

C'est peut-être un objectif évident pour tout protocole de ne pas se limiter à un seul point de défaillance comme d'avoir un seul serveur dans un paradigme client/serveur. Même lorsque il y a des serveurs redondants, il reste encore le problème de la synchronisation des antémémoires ; c'est-à-dire que lorsque un serveur est averti d'un changement dans l'état des informations de l'antémémoire, ce serveur doit alors propager la connaissance du changement d'état à tous les serveurs qui reflètent activement ces informations d'état. De plus, cela doit être fait à temps sans faire peser de contraintes de ressources injustifiées sur les serveurs. En supposant que les informations d'état conservées dans l'antémémoire du serveur sont l'état des clients du serveur, afin de minimiser la charge qui pèse sur le client, il est aussi très souhaitable que les clients n'aient pas besoin d'avoir une connaissance complète de tous les serveurs qu'ils peuvent utiliser. Cependant, aucun mécanisme de synchronisation ne devrait empêcher un client d'avoir accès à plusieurs serveurs (ou à tous). Bien sûr, toute solution doit être raisonnablement échelonnable, et capable d'utiliser un service d'auto configuration, et se prêter à une large gamme de méthodes d'authentification.

Le présent document décrit le protocole de synchronisation d'antémémoire de serveur (SCSP, Server Cache Synchronization Protocol). SCSP résout le problème général de la synchronisation/réplication d'antémémoire de serveur tout en réglant les problèmes décrits ci-dessus. SCSP synchronise les antémémoires (ou une portion des antémémoires) d'un ensemble d'entités de serveurs d'un protocole particulier qui est lié à un groupe de serveurs (SG, Server Group) à travers des moyens divers (par exemple, tous les serveurs NHRP appartenant à un sous-réseau logique IP (LIS, Logical IP Subnet) [1]). Le protocole client/serveur qu'utilise un serveur particulier est identifié par un identifiant de protocole (PID, Protocol ID). Les SG sont identifiés par un identifiant (ID) qui, sans surprise, est appelé un SGID. Noter donc que la combinaison PID/SGID identifie à la fois le protocole client/serveur pour lequel les serveurs du SG sont synchronisés et l'instance de ce protocole. Cela implique que plusieurs instances du même protocole peuvent fonctionner en même temps et ont leurs serveurs synchronisés de façon indépendante l'une de l'autre. Un exemple des types d'informations qui doivent être synchronisées peut être trouvé dans NHRP [2] qui utilise IP et où les informations incluent les transpositions de IP à NBMA pour les clients enregistrés dans le LIS du SG.

La façon la plus simple de comprendre SCSP est de comprendre que l'algorithme utilisé ici est assez similaire à celui utilisé dans OSPF [3]. En fait, si le lecteur souhaite comprendre plus en détails les compromis et les aspects de fiabilité dans SCSP, il devrait se reporter aux procédures de prise de contact, de synchronisation de base de données, et d'arrosage dans OSPF [3].

Comme décrit plus loin, le protocole passe par trois phases. La première, très brève phase, est celle de la prise de contact (hello) où deux appareils déterminent qu'ils peuvent se parler. Ensuite il y a la synchronisation de base de données. Le fonctionnement de SCSP suppose que jusqu'à ce point, lorsque de nouvelles informations sont reçues, deux entités ont les mêmes données disponibles. La phase de synchronisation de base de données s'en assure.

Dans la synchronisation de base de données, les deux voisins échangent des informations résumées sur chaque entrée de leur base de données. Les résumés sont utilisés car la base de données elle-même peut être assez importante. Sur la base de ces résumés, les voisins peuvent déterminer si il y a des informations de l'un qui sont nécessaires à l'autre. S'il en est ainsi, elles sont demandées et fournies. Donc, à la fin de cette phase de fonctionnement, les deux voisins ont les mêmes données dans leur base de données.

Après cela, les entités entrent et restent dans l'état d'arrosage. Dans l'état d'arrosage, toute nouvelle information apprise est envoyée à tous les voisins, excepté celui (s'il en est) d'où l'information a été apprise. Cela fait que toute nouvelle information se propage à tous les nœuds dans le système, restaurant donc l'état où chacun connaît la même chose. L'arrosage est fait de façon fiable sur chaque liaison, de sorte qu'aucun schéma de faible perte de paquet ne va causer d'interruption. (Évidemment, un taux de perte de paquet suffisamment élevé va causer l'effondrement de la relation de voisinage toute entière, mais si la liaison ne fonctionne pas, il n'y a plus rien à faire.)

Comme la procédure de synchronisation des bases de données est lancée chaque fois qu'une liaison est activée, le système assure de façon robuste que tous les nœuds participants ont toutes les informations disponibles. Il récupère correctement des partitions, et fait avec les autres défaillances.

La spécification SCSP n'est pas utile comme protocole autonome. Elle doit être couplée à l'utilisation d'un protocole spécifique de SCSP qui définit comment un protocole donné va faire usage des primitives de synchronisation fournies par SCSP. De telles spécifications feront l'objet de documents distincts ; par exemple, [8] [9].

2.   Généralités

SCSP ne fixe pas d'exigences topologiques sur le SG. Évidemment cependant, le graphe résultant doit couvrir l'ensemble des serveurs à synchroniser. SCSP emprunte son mécanisme de répartition d'antémémoires aux protocoles d'état de liaison [3], [4]. Cependant, à la différence de ces technologies, il n'y a pas de calcul obligatoire du plus court chemin en premier (SPF, Shortest Path First), et SCSP n'impose aucune exigence de mémoire supplémentaire par dessus et au-delà de ce qui est exigé pour sauvegarder les informations d'antémémoire qui existeraient sans considération de la technique de synchronisation.

Afin de donner un cadre de référence pour l'exposé qui suit, sont introduits les termes de serveur local (LS, Local Server), serveur directement connecté (DCS, Directly Connected Server), et serveur distant (RS, Remote Server). Le LS est le serveur examiné ; c'est-à-dire que toutes les déclarations sont faites du point de vue du LS lors de l'exposé du protocole SCSP. Le DCS est un serveur qui est directement connecté au LS ; par exemple, il existe un circuit virtuel (VC) entre le LS et le DCS. Et donc, chaque serveur est un DCS du point de vue de chaque autre serveur qui se connecte directement à lui, et chaque serveur est un LS qui a zéro, un ou plusieurs DCS qui lui sont directement connectés. Du point de vue d'un LS, un RS est un serveur, distinct du LS, qui n'est pas directement connecté au LS (c'est-à-dire qu'un RS est toujours à deux bonds ou plus d'un LS tandis qu'un DCS est toujours à un bond d'un LS).

SCSP contient trois sous protocoles : le protocole "Hello", le protocole "Alignement d'antémémoire", et le protocole "Mise à jour d'état d'antémémoire". Le protocole "Hello" est utilisé pour s'assurer qu'un DCS est opérationnel et si la connexion entre le LS et le DCS est bidirectionnelle, unidirectionnelle, ou non fonctionnelle. Le protocole "Alignement d'antémémoire" (CA, Cache Alignment) permet à un LS de synchroniser son antémémoire entière avec l'antémémoire de ses DCS. Le protocole "Mise à jour d'état d'antémémoire" (CSU, Cache State Update) est utilisé pour mettre à jour l'état des entrées d'antémémoire dans les serveurs pour un SG donné. Les paragraphes 2.1, 2.2, et 2.3 contiennent une explication plus approfondie des protocoles Hello, CA, et CSU et des messages qu'ils utilisent.

La synchronisation fondée sur SCSP est effectuée sur la base de l'instance de protocole. C'est-à-dire qu'une instance distincte de SCSP fonctionne pour chaque instance du protocole en question dans une boîte donnée. Le protocole est identifié dans SCSP via un identifiant de protocole et l'instance du protocole est identifiée par un identifiant de groupe de serveurs (SGID, Server Group ID). Donc la paire PID/SGID identifie de façon univoque une instance de SCSP. En général, cela ne pose pas de problème car c'est rarement le cas que plusieurs instances d'un protocole donné (qui est réparti et a besoin d'une synchronisation d'antémémoire) fonctionnent dans la même boîte physique. Cependant, lorsque c'est le cas, il y a un mécanisme appelé identifiant de famille (Identifiant de famille) (décrit brièvement dans le protocole Hello) qui permet une réduction substantielle du trafic de maintenance à faible coût réel en termes de contrôle. L'utilisation du mécanisme de l'identifiant de famille, lorsqu'il est approprié pour un protocole donné qui utilise SCSP, sera pleinement définie dans la spécification particulière du protocole SCSP donné.

                                                              +---------------+

                                                              |               |

                                                       +----->|    SOMMEIL    |<--------+

                                                       |      |               |         |

                                                       |      +---------------+         |

                                                       |            |      ^            |

                                                       |            |      |            |

                                                       |            |      |            |

                                                       |            |      |            |

                                                       |            v      |            |

                                                       |       +---------------+        |

                                                       |       |               |        |

                                                       |       |    ATTENTE    |        |

                                                       |    +--|               |--+     |

                                                       |    |  +---------------+  |     |

                                                       |    |   ^             ^   |     |

                                                       |    |   |             |   |     |

                                                       |    v   |             |   v     |

                                                    +---------------+     +---------------+

                                                    |   CONNEXION   |---->|   CONNEXION   |

                                                    |               |     |      UNI-     |

                                                    |BIDIECTIONNELLE|<----| DIRECTIONNELLE|

                                                    +---------------+     +---------------+

Figure 1 : Automate à états finis de prise de contact (HFSM, Hello Finite State Machine)

2.1   Protocole Hello

Les messages "Hello" sont utilisés pour s'assurer si un DCS est fonctionnel et si les connexions entre le LS et le DCS sont bidirectionnelles, unidirectionnelles, ou non fonctionnelles. Pour ce faire, chaque LS DOIT envoyer périodiquement un message Hello à ses DCS.

Un LS doit être configuré avec une liste d'adresses NBMA qui représentent les adresses des serveurs homologues dans un SG avec lequel le LS souhaite avoir une connexion directe pour les besoins du fonctionnement de SCSP ; c'est-à-dire que ces adresses sont celles de DCS potentiels. Le mécanisme pour la configuration d'un LS avec ces adresses NBMA sort du domaine d'application du présent document ; cependant un mécanisme possible serait l'auto configuration du serveur.

Un LS a un automate à états finis de prise de contact (HFSM, Hello Finite State Machine) associé à chacun de ses DCS (voir la Figure 1) pour un SG donné, et le HFSM surveille l'état de connexité entre les serveurs.

Le HFSM commence dans l'état "Sommeil" et passe à l'état "Attente" après que la connexité de niveau NBMA a été établie. Une fois dans l'état Attente, le LS commence à envoyer des messages Hello au DCS. Le message Hello comporte un identifiant d'envoyeur qui est établi à l'identifiant du LS (LSID), zéro, un ou plusieurs identifiants de receveur qui identifient les DCS d'où le LS a récemment entendu un message Hello (comme décrit plus loin), et un intervalle de Hello (IntervalleHello) et un facteur de mort (FacteurDeMort) qui seront décrits plus loin. À ce point, le DCS peut envoyer ou non ses propres messages Hello au LS.

Lorsque le LS reçoit un message Hello d'un de ses DCS, le LS vérifie si un de ses LSID est dans un des champs d'identifiant de receveur de ce message qu'il vient juste de recevoir, et le LS sauvegarde l'identifiant d'envoyeur (Sender ID) provenant de ce message Hello. Si le LSID est dans un des champs d'identifiant de receveur, le LS passe alors le HFSM à l'état de Connexion bidirectionnelle, autrement il passe le HFSM dans l'état Connexion unidirectionnelle. L'identifiant d'envoyeur qui a été sauvegardé est l'identifiant du DCS (DCSID). À un moment antérieur à la prochaine fois que le LS envoie son propre message Hello au DCS, le LS va vérifier le DCSID sauvegardé dans une liste d'identifiants de receveur que le LS utilise lors de l'envoi de ses propres messages Hello. Si le DCSID ne se trouve pas dans la liste des identifiants de receveur, il l'ajoute alors à cette liste avant que le LS envoie son message Hello.

Les messages Hello contiennent aussi un IntervalleHello et un FacteurDeMort. L'intervalle Hello annonce la durée (en secondes) entre l'envoi de messages Hello consécutifs par le serveur qui envoie le message Hello "en cours". C'est-à-dire que si la durée entre la réception des messages Hello provenant d'un DCS excède le IntervalleHello annoncé par ce DCS, le prochain message Hello sera considéré comme tardif par le LS. Si le LS ne reçoit pas un message Hello, qui contienne le LSID du LS dans un des champs d'identifiant de receveur, dans l'intervalle IntervalleHello*FacteurDeMort secondes (où FacteurDeMort a été annoncé par le DCS dans un message Hello précédent) le LS DOIT alors considérer le DCS comme périmé. À ce point, de deux choses l'une : 1) si des messages Hello ont été reçus durant les dernières IntervalleHello*FacteurDeMort secondes, le LS devrait alors passer le HFSM pour ce DCS à l'état Connexion unidirectionnelle ; autrement, le LS devrait passer le HFSM pour ce DCS à l'état Attente et retirer le DCSID de la liste des identifiants de receveur.

Noter que le protocole Hello fonctionne par PID/SGID. Et donc, par exemple, si il y a deux serveurs (un dans le SG A et l'autre dans le SG B) associés à une adresse NBMA X et deux autres serveurs (l'un aussi dans le SG A et l'autre dans le SG B) associés à l'adresse NBMA Y et s'il y a un circuit virtuel convenable en point à point entre les adresses NBMA, il y a alors deux HFSM qui fonctionnent sur chaque côté du circuit virtuel (un par PID/SGID).

Les messages Hello contiennent une liste d'identifiants de receveur au sein d'un seul identifiant de receveur afin de faire usage des connexions de point à multipoint. Alors qu'il y a un HFSM par DCS, un LS DOIT envoyer seulement un message Hello à ses DCS rattachés comme extrémités d'une connexion de point à multipoint. Le LS fait cela en incluant les DCSID dans la liste des identifiants de receveur lorsque les LS envoient leur prochain message Hello. Seuls sont inclus les DCSID provenant de DCS non périmés desquels le LS a entendu un message Hello.

Tout événement anormal, comme la réception d'un message SCSP mal formé, cause la transition du HFSM à l'état Attente ; cependant, une perte de connexité de NBMA cause la transition du HFSM à l'état Sommeil. Jusqu'à ce que le HFSM soit dans l'état de connexion bidirectionnelle, si des messages SCSP correctement formés autres que des messages Hello sont reçus, ces messages DOIVENT alors être ignorés (ceci pour le cas où, par exemple, il y aurait une connexion de point à multipoint impliquée).

                                                                       +------------+

                                                                       |            |

                                                                  +--->|   Sommeil  |

                                                                  |    |            |

                                                                  |    +------------+

                                                                  ^           |

                                                                  |           @

                                                                  |    +--------------+

                                                                  |    |  Négociation |

                                                                  |-<--|maître/esclave|<---+

                                                                  |    +--------------+    |

                                                                  |           |            |

                                                                  ^           |            ^

                                                                  |           @            |

                                                                  |    +------------+      |

                                                                  |    |   Résumé   |      |

                                                                  |-<--|      d'    |---->-|

                                                                  |    |antémémoire |      |

                                                                  |    +------------+      |

                                                                  ^           |            ^

                                                                  |           @            |

                                                                  |    +-------------+     |

                                                                  |    | Mise à jour |     |

                                                                  |-<--|     d'      |--->-|

                                                                  |    | antémémoire |     |

                                                                  |    +-------------+     |

                                                                  ^           |            ^

                                                                  |           @            |

                                                                  |    +------------+      |

                                                                  |    |            |      |

                                                                  +-<--|   Aligné   |---->-+

                                                                       +------------+

Figure 2 : Alignement d'automate d'antémémoire à états finis

2.2   Protocole d'alignement d'antémémoire

Les messages d'alignement d'antémémoire" (CA) sont utilisés par un LS pour synchroniser son antémémoire avec celle de chacun de ses DCS. C'est à dire que les messages CA permettent à un LS qui s'amorce de se synchroniser avec chacun de ses DCS. Un message CA contient un en-tête de CA suivi par zéro, un ou plusieurs enregistrements de résumé d'annonce d'état d'antémémoire (CSAS, Cache State Advertisement Summary).

Un LS a un automate à états finis d'alignement d'antémémoire (CAFSM, Cache Alignment Finite State Machine) associé (voir la Figure 2) à chacun de ses DCS par PID/SGID, et le CAFSM surveille l'état de l'alignement de l'antémémoire entre les serveurs. Le CAFSM commence dans l'état Sommeil. Le CAFSM est associé à un HFSM, et lorsque cet HFSM atteint l'état Bidirectionnel, le CAFSM passe à l'état Négociation maître/esclave. L'état de négociation maître/esclave amène le LS ou le DCS à jouer le rôle de maître dans le processus d'alignement d'antémémoire. Dans un sens, le serveur maître donne le tempo pour l'alignement d'antémémoire.

Lorsque le CAFSM du LS atteint l'état de négociation maître/esclave, le LS va envoyer un message CA au DCS associé au CAFSM. Le format des messages CA est décrit au paragraphe B.2.1. Le premier message CA qu'envoie le LS ne comporte pas d'enregistrement CSAS et un en-tête CA qui contient le LSID dans le champ Identifiant d'envoyeur, le DCSID dans le champ Identifiant de receveur, un numéro de séquence CA, et trois bits. Ces trois bits sont le bit M (Maître/esclave), le bit I (Initialisation du maître), et le bit O (Plus). Dans le premier message CA envoyé par le LS à un DCS particulier, les bits M, O, et I sont mis à un. Si le LS ne reçoit pas de message CA du DCS en CAReXmtInterval secondes, il renvoie alors le message CA qu'il vient juste d'envoyer. Le LS continue de faire cela jusqu'à ce que le CAFSM passe à l'état Résumé d'antémémoire ou jusqu'à ce que le HFSM sorte de l'état Bidirectionnel. À tout moment où le HFSM sort de l'état Bidirectionnel, le CAFSM passe à l'état Sommeil.

2.2.1   État de négociation maître/esclave

Lorsque le LS reçoit un message CA du DCS dans l'état de négociation maître/esclave, le rôle que joue le LS dans l'échange dépend du traitement de paquet de la façon suivante :

1)   Si le CA provenant du DCS a les bits M, I, et O établis à un et si il n'y a pas d'enregistrement CSAS dans le message CA et si l'identifiant d'envoyeur comme spécifié dans le message CA du DCS est plus grand que le LSID, alors :

a)   le temporisateur qui décompte le CAReXmtInterval est arrêté,

b)   le CAFSM correspondant à ce DCS passe à l'état Résumé d'antémémoire et le LS prend le rôle d'esclave,

c)   le LS adopte le numéro de séquence CA qu'il a reçu dans le message CA comme numéro de séquence CA,

d)   le LS envoie un message CA au DCS formaté comme suit : les bits I sont mis à zéro, le champ ID d'envoyeur est mis à la valeur du LSID, le champ Identifiant de receveur est mis au DCSID, et le numéro de séquence CA est mis au numéro de séquence CA qui apparaissait dans le message CA du DCS. Si il y a des enregistrements CSAS à envoyer (c'est-à-dire, si l'antémémoire du LS n'est pas vide), et si tous ne tiennent pas dans ce message CA, le bit O est alors mis à un et l'ensemble initial d'enregistrements CSAS est inclus dans le message CA ; autrement, le bit O est mis à zéro et si des enregistrements CSAS doivent être envoyés, ils sont alors inclus dans le message CA.

2)   Si le message CA provenant du DCS a les bits M et I non établis et si l'identifiant d'envoyeur comme spécifié dans le message CA du DCS est plus petit que le LSID, alors

a)   le temporisateur qui décompte le CAReXmtInterval est arrêté,

b)   le CAFSM correspondant à ce DCS passe à l'état Résumé d'antémémoire et le LS prend le rôle de maître,

c)   le LS doit traiter le message CA reçu. Une explication du traitement du message CA est données ci-dessous ;

d)   le LS envoie un message CA au DCS formaté comme suit : le bit M est mis à un, le bit I est mis à zéro, le champ ID d'envoyeur est mis au LSID, le champ Identifiant de receveur est mis au DCSID, et le numéro de séquence CA actuel du LS est incrémenté de un et placé dans le message CA. Si il y a des enregistrements CSAS à envoyer du LS au DCS (c'est-à-dire, si l'antémémoire du LS n'est pas vide) le bit O est alors mis à un et l'ensemble initial d'enregistrements CSAS est inclus dans le message CA que le LS envoie au DCS.

3)   Autrement, le paquet doit être ignoré.

2.2.2   État Résumé d'antémémoire

À tout moment, le maître ou l'esclave a au plus un message CA en instance. Une fois que le CAFSM du LS est passé à l'état Résumé d'antémémoire, la séquence d'échanges de messages CA se fait de la façon suivante :

1)   Si le LS reçoit un message CA avec le bit M mis incorrectement (par exemple, le bit M est mis dans le CA du DCS et le LS est maître) ou si le bit I est mis, le CAFSM repasse alors à l'état Négociation maître/esclave.

2)   Si le LS est maître et si le LS reçoit un message CA avec un numéro de séquence CA qui est inférieur de un au numéro de séquence CA actuel du LS, le message est un duplicata et le message DOIT être éliminé.

3)   Si le LS est maître et qu'il reçoit un message CA avec un numéro de séquence CA qui est égal au numéro de séquence CA actuel du LS, le message CA DOIT alors être traité. Une explication de "traitement du message CA" est donnée plus loin. Suite à la réception du message CA provenant du DCS il va arriver ce qui suit :

a)   le temporisateur qui décompte le CAReXmtInterval est arrêté,

b)   le LS doit traiter tout enregistrement CSAS dans le message CA reçu,

c)   incrémenter le numéro de séquence CA du LS de un,

d)   l'échange d'antémémoire continue comme suit :

1)   Si le LS n'a plus d'enregistrements CSAS à envoyer et si le message CA reçu n'a pas le bit O, le CAFSM passe alors à l'état Mise à jour d'antémémoire.

2)   Si le LS n'a plus d'enregistrement CSAS à envoyer et si le message CA reçu a le bit O établi, le LS renvoie alors un message CA (avec un nouveau numéro de séquence CA) qui ne contient pas d'enregistrement CSAS et sans le bit O. Recaler le temporisateur qui décompte CAReXmtInterval.

3)   Si le LS a encore des enregistrements CSAS à envoyer, le LS envoie le nouveau message CA avec le prochain ensemble d'enregistrements CSAS du LS. Si le LS envoie son dernier ensemble d'enregistrements CSAS, le bit O est à zéro, autrement, il est mis à un. Recaler le temporisateur qui décompte CAReXmtInterval.

4)   Si le LS est esclave et qu'il reçoit un message CA avec un numéro de séquence CA égal au numéro de séquence CA actuel du LS, le message CA est alors un duplicata et le LS DOIT renvoyer le message CA qu'il vient d'envoyer au DCS.

5)   Si le LS est esclave et qu'il reçoit un message CA avec un numéro de séquence CA qui est supérieur de un au numéro de séquence CA actuel du LS, le message est valide et DOIT être traité. Une explication de "traitement de message CA" est données plus loin. Par suite de la réception d'un message CA du DCS, il arrive ce qui suit :

a)   le LS doit traiter tout enregistrement CSAS dans le message CA reçu,

b)   le numéro de séquence CA du LS est réglé au numéro de séquence CA dans le message CA,

c)   l'échange d'antémémoire continue comme suit :

1)   Si le LS vient juste d'envoyer un message CA sans le bit O et si le message CA reçu n'a pas le bit O, le CAFSM passe alors à l'état Mise à jour d'antémémoire et le LS envoie un message CA sans enregistrement CSAS et sans le bit O.

2)   Si le LS a encore des enregistrements CSAS à envoyer, le LS DOIT alors envoyer un message CA contenant les enregistrements CSAS.

a)   Si le message en cours d'envoi par le LS au DCS ne contient pas les derniers enregistrements CSAS que le LS a besoin d'envoyer, le message CA est alors envoyé avec le bit O établi.

b)   Si le message en cours d'envoi par le LS au DCS ne contient pas les derniers enregistrements CSAS que le LS a besoin d'envoyer et si le message CA qui vient juste d'être reçu du DCS n'a pas le bit O, le message CA est alors envoyé sans le bit O, et le LS passe le CAFSM dans l'état Mise à jour d'antémémoire.

c   Si le message en cours d'envoi par le LS au DCS ne contient pas les derniers enregistrements CSAS que le LS a besoin d'envoyer et si le message CA juste reçu du DCS a le bit O établi, le message CA est alors envoyé sans le bit O et le processus d'alignement continue.

6)   Si le LS est esclave et qu'il reçoit un message CA avec un numéro de séquence CA qui n'est ni égal ni supérieur de un au numéro de séquence CA actuel du LS, une erreur est alors survenue et le CAFSM passe à l'état Négociation maître/esclave.

Noter que si le LS était esclave durant le processus CA, il DOIT garder une copie du dernier message CA qu'il a envoyé lors de la transition du CAFSM à l'état Mise à jour d'antémémoire, et le LS DEVRAIT lancer un temporisateur égal à CAReXmtInterval. Si le temporisateur arrive à expiration ou si le LS reçoit un message CSU Sollicité (CSUS) (les messages CSUS sont décrits au paragraphe 2.2.3) de la part du DCS, le LS délivre alors la copie du message CA. La raison en est que si le DCS (qui est maître) perd le dernier message CA envoyé par le LS, le DCS va alors renvoyer le message CA précédent avec le dernier numéro de séquence CA utilisé. Si cela devait survenir, le LS aurait besoin de renvoyer aussi son dernier message CA envoyé.

2.2.2.1   "Traitement du message CA" :

Le LS fait une liste des entrées d'antémémoire qui sont "plus à jour" dans le DCS que dans la propre antémémoire du LS. Cette liste est appelée la liste de demandes CSA (CRL, CSA Request List). Voir au paragraphe 2.4 la description de ce que cela signifie pour un enregistrement de CSA (annonce d'état de client, Client State Advertisement) ou qu'un enregistrement CSAS est plus "à jour" que l'entrée d'antémémoire du LS.

2.2.3   État Mise à jour d'antémémoire

Si le CRL du CAFSM associé au LS est vide lors de la transition en état de mise à jour d'antémémoire, le CAFSM passe immédiatement à l'état Aligné.

Si le CRL n'est pas vide lors de la transition en état de mise à jour d'antémémoire, le LS sollicite alors le DCS pour l'envoi des enregistrements CSA correspondants aux résumés (c'est-à-dire, les enregistrements CSAS) que le LS détient dans son CRL. Les enregistrements CSA sollicités vont contenir la totalité des informations d'antémémoire détenues dans l'antémémoire du DCS pour l'entrée d'antémémoire considérée. Le LS sollicite les enregistrements CSA pertinents en formant des messages CSU Sollicité (CSUS) du CRL. Voir au paragraphe B.2.4 la description du format du message CSUS. Le LS envoie alors les messages CSUS au DCS. Le DCS répond au message CSUS en envoyant au LS un ou plusieurs messages de demande CSU contenant la totalité des informations d'antémémoire les plus récentes identifiées dans le message CSUS. À réception de la Demande CSU le LS va envoyer une ou plusieurs Réponses CSU comme décrit au paragraphe 2.3. Noter que le LS peut avoir au plus un message CSUS en instance à un moment donné.

Juste avant l'envoi du premier message CSUS d'un LS au DCS associé au CAFSM, un temporisateur est réglé à CSUSReXmtInterval secondes. Si tous les enregistrements CSA correspondants aux enregistrements CSAS dans le message CSUS n'ont pas été reçus au moment où le temporisateur arrive à expiration, un nouveau message CSUS sera alors créé contenant tous les enregistrements CSAS pour lesquels aucun enregistrement CSA approprié n'a été reçu plus les enregistrements CSAS supplémentaires non couverts par le message CSUS précédent. Le nouveau message CSUS est alors envoyé au DCS. Si, à un moment quelconque avant l'arrivée à expiration du temporisateur, toutes les mises à jour d'enregistrement CSA ont été reçues pour tous les enregistrements CSAS inclus dans le message CSUS envoyé précédemment, le temporisateur est alors arrêté. Une fois que le temporisateur est arrêté, si il y a des enregistrements CSAS supplémentaires qui n'étaient pas couverts dans le message CSUS précédent mais qui étaient dans le CRL, le temporisateur est alors recalé et un nouveau message CSUS est créé qui contient seulement les enregistrements CSAS provenant du CRL qui n'ont pas encore été envoyés au DCS. Ce processus continue jusqu'à ce que tous les enregistrements CSA correspondants à des enregistrements CSAS qui étaient dans le CRL aient été reçus par le LS. Lorsque le LS a complètement mis à jour son antémémoire, il passe alors le CAFSM associé au DCS à l'état Aligné.

Si un LS reçoit un message CSUS ou un message CA avec un identifiant de receveur qui n'est pas le LSID du LS, le message doit alors être éliminé et ignoré. Ceci est nécessaire car un LS peut être l'extrémité d'une connexion de point à multipoint avec d'autres serveurs dans le SG.

2.2.4   État Aligné

Dans l'état Aligné, un LS va effectuer le protocole de mise à jour d'état d'antémémoire comme décrit au paragraphe 2.3.

Noter qu'un LS peut recevoir un message CSUS lorsqu'il est dans l'état Aligné et le LS DOIT répondre au message CSUS par le message Demande CSU approprié d'une façon similaire à la méthode précédemment décrite au paragraphe 2.2.3.

2.3   Protocole de mise à jour d'état d'antémémoire

Les messages de mise à jour d'état d'antémémoire (CSU, Cache State Update) sont utilisés pour mettre à jour de façon dynamique les entrées d'état d'antémémoire dans les serveurs sur la base d'un PID/SGID donné. Les messages CSU contiennent zéro, un ou plusieurs enregistrements d'annonce d'état d'antémémoire (CSA, Cache State Advertisement) dont chacun contient sa propre photographie de l'état d'une entrée d'antémémoire particulière. Un LS peut envoyer/recevoir une CSU à/de un DCS seulement quand le CAFSM correspondant est dans l'état Aligné ou dans l'état mise à jour d'antémémoire.

Il y a deux types de messages CSU : les Demandes CSU et les réponses CSU. Voir respectivement les paragraphes B.2.2 et B.2.3 pour les formats de message. Un message Demande de CSU est envoyé d'un LS à un ou plusieurs DCS pour une de deux raisons : soit le LS a reçu un message CSUS et DOIT répondre seulement au DCS qui a généré le message CSUS, ou le LS a été averti d'un changement d'état d'une entrée d'antémémoire. Un LS est averti d'un changement d'état d'une entrée d'antémémoire par la réception d'une Demande de CSU d'un de ses DCS ou par suite de l'observation d'un changement d'état dans une entrée d'antémémoire générée par le LS. Dans le premier cas, le LS va envoyer une Demande de CSU à chacun de ses DCS excepté celui par qui le LS a été averti du changement d'état. Dans le dernier cas, le LS va envoyer une Demande de CSU à chacun de ses DCS. Le changement d'état d'une entrée d'antémémoire particulière est notée dans un enregistrement CSA qui est ensuite ajouté à la fin de la partie obligatoire du message Demande de CSU. De cette façon, les changements d'état sont propagés dans tout le SG.

Voici des exemples de tels changements d'état :

1)   un serveur reçoit d'un client une demande d'ajouter une entrée à son antémémoire,

2)   un serveur reçoit d'un client une demande de retirer une entrée de son antémémoire,

3)   une entrée d'antémémoire est périmée dans l'antémémoire du serveur, a été rafraîchie dans l'antémémoire du serveur, ou a été modifiée administrativement.

Lorsque un LS reçoit une demande de CSU de la part d'un de ses DCS, le LS accuse réception d'un ou plusieurs enregistrements CSA qui étaient contenus dans la demande de CSU en envoyant une Réponse de CSU. La Réponse de CSU contient un ou plusieurs enregistrements CSAS qui correspondent aux enregistrements de CSA dont il est accusé réception. Et donc, par exemple, si un enregistrement CSA est abandonné (ou retardé dans le traitement) par le LS parce qu'il y a des ressources insuffisantes pour le traiter, un enregistrement CSAS correspondant n'est pas inclus dans la Réponse de CSU au DCS.

Noter qu'un LS peut envoyer plusieurs messages Demande de CSU avant de recevoir une Réponse de CSU accusant réception des enregistrements CSA contenus dans les Demandes de CSU. Noter aussi qu'une Réponse de CSU peut contenir des accusés de réception pour des enregistrements CSA pour plusieurs Demandes de CSU. Et donc, les termes "demande" et "réponse" peuvent prêter un peu à confusion.

Noter qu'un enregistrement CSA contient un enregistrement CSAS suivi par des informations spécifiques du protocole client/serveur contenues dans une entrée d'antémémoire (voir le paragraphe B.2.0.2 pour les informations sur le format d'enregistrement CSAS et le paragraphe B.2.2.1 pour les informations de format d'enregistrement CSA). Lorsque un enregistrement CSA est considéré par le LS comme représentant des informations d'antémémoire qui sont plus "à jour" (voir au paragraphe 2.4) que les informations contenues dans l'antémémoire du LS, deux choses peuvent se produire :

1)   l'antémémoire du LS est mise à jour avec les informations plus à jour, et

2)   le LS envoie une Demande de CSU contenant l'enregistrement CSA à chacun de ses DCS excepté à celui d'où l'enregistrement CSA est arrivé.

De cette façon, les changements d'état sont propagés au sein du PID/SGID. Bien sûr, à un certain moment, le LS va aussi accuser réception de l'enregistrement CSA en envoyant au DCS approprié un message Réponse de CSU contenant l'enregistrement CSAS correspondant.

Lorsque un LS envoie une nouvelle Demande de CSU, le LS garde trace des enregistrements CSA en cours dans cette Demande de CSU et des DCS auxquels il a envoyé la Demande de CSU. Pour chaque DCS auquel la Demande de CSU a été envoyée, un temporisateur réglé à CSUReXmtInterval secondes est lancé juste avant l'envoi de la Demande de CSU. Ce temporisateur est associé à l'enregistrement CSA contenu dans cette Demande de CSU de telle sorte que si ce temporisateur arrive à expiration avant d'avoir un accusé de réception pour tous les enregistrements CSA de ce DCS, alors (et seulement alors) une Demande de CSU est renvoyée par le LS à ce DCS. Cependant, la Demande de CSU renvoyée ne contient que les enregistrements CSA qui n'ont pas encore été acquittés. Si tous les enregistrements CSA associés à un temporisateur ont été acquittés le temporisateur est alors arrêté. Noter que les enregistrements CSA renvoyés suivent les mêmes règles de temporisation et de retransmission que si ils étaient nouveaux. La retransmission va intervenir un nombre de fois configuré pour un enregistrement CSA donné et si l'accusé de réception n'intervient pas, un "événement anormal" survient alors et c'est à ce moment que le HFSM associé au DCS va passer à l'état Attente.

Une instance d'enregistrement CSA est dite être sur une "file d'attente de retransmission DCS" lorsque elle est associée au temporisateur mentionné précédemment. Il est permis à l'enregistrement CSA le plus à jour d'être mis en file d'attente dans une file d'attente de retransmission DCS donnée. Et donc, si un enregistrement CSA moins à jour est mis en file d'attente dans la file d'attente de retransmission DCS lorsque une instance plus récente d'enregistrement CSA est sur le point d'être mise en file d'attente dans cette file d'attente de retransmission DCS, la plus ancienne instance d'enregistrement CSA est sortie de la file d'attente et dissociée de son temporisateur immédiatement avant de mettre en file d'attente l'instance plus récente d'enregistrement CSA.

Lorsque un LS reçoit une Réponse de CSU de l'un de ses DCS, il vérifie chaque enregistrement CSAS dans la réponse de CSU par rapport à la portion d'enregistrement CSAS des enregistrements CSA qui sont en file d'attente dans la file d'attente de retransmission du DCS.

1)   Si il existe une correspondance exacte entre la portion d'enregistrement CSAS de l'enregistrement CSA et un enregistrement CSAS dans la réponse de CSU, cet enregistrement CSA est alors considéré comme un accusé de réception et est donc sorti de la file d'attente de retransmission du DCS et est dissocié de son temporisateur.

2)   Si il existe une correspondance entre la portion d'enregistrement CSAS de l'enregistrement CSA et un enregistrement CSAS dans la réponse de CSU sauf pour le numéro de séquence CSA, alors :

a)   Si l'enregistrement CSA mis en file d'attente dans la file d'attente de retransmission du DCS a un numéro de séquence CSA supérieur au numéro de séquence CSA dans l'enregistrement CSAS de la réponse de CSU, l'enregistrement CSAS dans la réponse de CSU est ignoré .

b)   Si l'enregistrement CSA mis en file d'attente dans la file d'attente de retransmission du DCS a un numéro de séquence CSA inférieur au numéro de séquence CSA de l'enregistrement CSAS de la réponse de CSU, l'enregistrement CSA qui est en file d'attente dans la file d'attente de retransmission du DCS est alors sortie de la file d'attente et l'enregistrement CSA est dissocié de son temporisateur. De plus, un message CSUS est envoyé à ce DCS qui a envoyé l'enregistrement CSAS le plus à jour. Le traitement de CSUS normal survient comme si le CSUS était envoyé au titre du protocole de CA.

Lorsque un LS reçoit un message Demande de CSU qui contient un enregistrement CSA avec un numéro de séquence CSA inférieur à celui du CSA en antémémoire, le LS DOIT alors accuser réception de l'enregistrement CSA de la demande de CSU mais il DOIT le faire en envoyant un message Réponse de CSU contenant la portion Enregistrement CSAS de l'enregistrement CSA mémorisé dans l'antémémoire et non la portion Enregistrement CSAS de l'enregistrement CSA contenu dans la Demande de CSU.

Un LS répond aux messages CSUS de ses DCS en envoyant des messages Demande de CSU qui contiennent les enregistrements CSA appropriés au DCS. Si un LS reçoit un message CSUS qui contient un enregistrement CSAS pour une entrée qui n'est plus dans sa base de données (par exemple, l'entrée était périmée et a été éliminée après un échange d'alignement d'antémémoire complet mais avant que l'entrée ait été demandée dans un message CSUS) le LS va alors répondre en copiant l'enregistrement CSAS d'après le message CSUS dans un message Demande de CSU et le LS va régler le bit N qui signifie que cet enregistrement est un enregistrement NULL car l'entrée d'antémémoire n'existe plus dans l'antémémoire du LS. Noter que dans ce cas, "l'enregistrement CSA" inclus dans la Demande de CSU pour signifier l'entrée d'antémémoire NULL est littéralement seulement un Enregistrement CSAS car aucune information spécifique de protocole client/serveur n'existe pour l'entrée d'antémémoire.

Si un LS reçoit un enregistrement CSA dans une Demande de CSU provenant d'un DCS pour lequel le LS a un enregistrement CSA identique envoyé à la file d'attente de retransmission de DCS du DCS correspondant, l'enregistrement CSA sur la file d'attente de retransmission de DCS est alors considéré comme implicitement acquitté. Et donc, l'enregistrement CSA est sorti de la file d'attente de retransmission de DCS et est dissocié de son temporisateur. L'enregistrement CSA envoyé par le DCS DOIT cependant encore être acquitté par le LS dans une Réponse de CSU. Ceci est utile dans le cas de connexions de point à multipoint où la règle que "lorsque un LS reçoit un enregistrement CSA d'un DCS, ce LS arrose cet enregistrement CSA à tous les DCS excepté le DCS d'où il a été reçu" peut être enfreinte.

Si un LS reçoit un CSU avec un identifiant de receveur qui n'est pas égal au LSID et n'est pas réglé tout à 0xFF, le CSU doit alors être éliminé et ignoré. Ceci est nécessaire car le LS peut être une extrémité d'une connexion de point à multipoint avec d'autres serveurs dans le SG du LS.

Un LS PEUT envoyer une Demande de CSU à l'identifiant de receveur tout à 0xFF lorsque le LS est une racine d'une connexion de point à multipoint avec un ensemble de ses DCS. Si un LS reçoit une Demande de CSU avec l'identifiant de receveur tout à 0xFF, il DOIT alors utiliser l'identifiant d'envoyeur dans la Demande de CSU comme identifiant de receveur de la Réponse de CSU (c'est-à-dire, il DOIT envoyer sa réponse en envoi individuel à l'envoyeur de la demande) lorsqu'il répond. Si le LS souhaite envoyer une Demande de CSU à l'identifiant de receveur tout à 0xFF, il DOIT alors créer une temporisation et retransmettre le temporisateur pour chacun des DCS qui sont des feuilles de la connexion de point à multipoint avant d'envoyer la demande de CSU. Si dans ce cas, le temporisateur de retransmission arrive à expiration pour un DCS donné avant l'accusé de réception d'un enregistrement CSA donné, le LS DOIT alors utiliser le DCSID spécifique comme identifiant de receveur plutôt que l'identifiant de receveur tout à 0xFF. De même, si il est nécessaire de renvoyer un enregistrement CSA, le LS DOIT alors spécifier le DCSID spécifique comme identifiant de receveur plutôt que l'identifiant de receveur tout à 0xFF.

Noter que si un ensemble de serveurs est dans un maillage complet de connexions de point à multipoint, et si un serveur d'un tel maillage envoie une Demande de CSU dans ce maillage complet, et si ce serveur envoie les enregistrements CSA de la demande de CSU à tous les identifiants de receveur tout à 0xFF, il ne sera alors pas nécessaire à chaque autre serveur du maillage de générer leur propre demande de CSU contenant ces enregistrements CSA dans le maillage afin de diffuser correctement les enregistrements CSA. Cela parce que chaque serveur dans le maillage va avoir entendu la demande de CSU et va avoir traité les enregistrements CSA comme approprié. Donc, un serveur dans un maillage complet pourrait considérer la maillage comme un seul accès logique et ainsi la règle selon laquelle "lorsque un LS reçoit un enregistrement CSA d'un DCS, ce LS diffuse l'enregistrement CSA à chaque DCS sauf au DCS d'où il l'a reçu" n'est pas enfreinte. Un serveur receveur dans le maillage complet aura quand même besoin d'accuser réception des enregistrements CSA avec des messages Réponse de CSU qui contiennent le LSID du serveur répondant comme identifiant d'envoyeur et l'identifiant du serveur qui a envoyé la demande de CSU comme champ Identifiant de receveur. Dans le cas de l'expiration de temporisation et retransmission, l'identifiant de receveur de la demande de CSU serait réglée au DCSID spécifique qui n'a pas accusé réception de l'enregistrement CSA (par opposition à l'identifiant de receveur tout à 0xFF). Comme un plein maillage émule un support de diffusion pour les serveurs rattachés au plein maillage, l'utilisation de SCSP sur un support de diffusion pourrait faire aussi usage de cette technique. Un exposé plus complet de cette utilisation d'un maillage plein ou l'utilisation du support de diffusion relève des documents spécifiques des protocoles client/serveur.

2.4   Signification de"Plus à jour"/"Nouveauté"

Durant le processus d'alignement d'antémémoire et durant le traitement normal de CSU, un enregistrement CSAS est comparé au contenu d'une entrée d'antémémoire de LS pour décider si les informations contenues dans l'enregistrement sont "plus à jour" que l'entrée d'antémémoire correspondante du LS.

Il y a trois éléments d'information qui sont utilisés pour déterminer si un enregistrement contient des informations qui sont "plus à jour" que les informations contenues dans l'entrée d'antémémoire d'un LS qui traite l'enregistrement :

1)   la clé d'antémémoire,

2)   l'origine qui est décrite par un Identifiant d'origine (OID), et

3)   le numéro de séquence CSA.

Voir au paragraphe B.2.0.2 les informations sur ces champs.

Ces trois éléments d'information étant donnés, un enregistrement CSAS (qu'il fasse partie d'un enregistrement CSA ou qu'il soit autonome) est considéré comme "plus à jour" que les informations contenues dans l'antémémoire d'un LS si les trois conditions suivantes sont remplies :

1)   La clé d'antémémoire dans l'enregistrement CSAS correspond à la clé d'antémémoire mémorisée dans l'entrée d'antémémoire du LS,

2)   L'OID dans l'enregistrement CSAS correspond à l'OID mémorisé dans l'entrée d'antémémoire du LS,

3)   Le numéro de séquence CSA dans l'enregistrement CSAS est supérieur au numéro de séquence CSA dans l'entrée d'antémémoire du LS.

Discussion et conclusions

Bien que le texte ci-dessus soit rédigé en termes de synchronisation de la connaissance de l'état d'un client au sein de l'antémémoire du serveurs contenu dans un SG, cette solution se généralise facilement à tout nombre de problèmes de synchronisation de bases de données (par exemple, la synchronisation de LECS).

SCSP définit un protocole d'arrosage générique. Un certain nombre de questions annexes relatives à la maintenance d'antémémoire et à la maintenance de la topologie sont définies de façon plus appropriée dans les documents spécifiques des protocoles client/serveur; par exemple, il peut être souhaitable de définir un mécanisme générique de temporisation d'entrée d'antémémoire pour un certain protocole ou d'annoncer les informations d'adjacence entre serveurs de telle sorte qu'ils puissent obtenir une carte topographique des serveurs dans un SG. Lorsque de tels mécanismes sont désirables, ils seront définis dans les documents spécifiques de protocole client/serveur.

Appendice A   Terminologie et définitions

Message CA - Message Alignement d'antémémoire

Ces messages permettent à un LS de synchroniser son antémémoire entière avec celle de l'un de ses DCS.

CAFSM – Automate à états finis d'alignement d'antémémoire

Le CAFSM surveille l'état de l'alignement d'antémémoire entre un LS et un DCS particulier. Il existe un CAFSM par DCS vu d'un LS.

Enregistrement CSA – enregistrement d'annonce d'état d'antémémoire (Cache State Advertisement)

Un CSA est un enregistrement au sein d'un message de CSU qui identifie une mise à jour de l'état d'une entrée "particulière" d'antémémoire.

Enregistrement CSAS – enregistrement de résumé d'annonce d'état d'antémémoire (Cache State Advertisement Summary)

Un CSAS contient un résumé des informations dans un CSA. Un serveur va envoyer les enregistrements CSAS qui décrivent ses entrées d'antémémoire à un autre serveur durant le processus d'alignement d'antémémoire. Les enregistrements CSAS sont aussi inclus dans des messages CSUS lorsque un LS veut demander le CSA entier au DCS. Le LS demande le CSA au DCS parce que le LS croit que le DCS a une vue plus récente de l'état de l'entrée d'antémémoire en question.

Message de CSU – message de mise à jour d'état d'antémémoire (Cache State Update)

C'est un message envoyé d'un LS à ses DCS lorsque le LS devient conscient d'un changement de l'état d'une entrée d'antémémoire.

Message CSUS – message de sollicitation de mise à jour d'état d'antémémoire (Cache State Update Solicit)

Ce message est envoyé par un LS à son DCS après que LS et DCS aient échangé des messages CA. Le message CSUS contient un ou plusieurs enregistrements CSAS qui représentent des sollicitations d'enregistrements CSA entiers (par opposition à juste le résumé d'informations détenues dans le CSAS).

DCS – serveur directement connecté (Directly Connected Server)

Le DCS est un serveur qui est directement connecté au LS ; par exemple, il existe un circuit virtuel (VC) entre le LS et le DCS. Ce terme, ainsi que les termes LS et RS, sont utilisés pour donner une trame de référence dans les discussions sur les serveurs et leur synchronisation. Sauf déclaration explicite du contraire, cela n'implique pas de différence de fonctionnalité entre DCS, LS, et RS.

HFSM – automate à états finis de prise de contact (Hello Finite State Machine)

Un LS a un HFSM associé à chacun de ses DCS. Le HFSM surveille l'état de connexité entre le LS et un DCS particulier.

LS – serveur local

Le LS est le serveur examiné ; c'est-à-dire, que toutes les déclarations sont faites du point de vue du LS. Ce terme, avec les termes DCS et RS, est utilisé pour donner un cadre de référence pour parler des serveurs et de leur synchronisation. Sauf déclaration explicite contraire, cela n'implique pas de différence de fonctionnalité entre DCS, LS, et RS.

LSID – identifiant de serveur local (Local Server ID)

Le LSID est un jeton unique qui identifie un LS. Cette valeur peut être tirée de l'adresse de protocole du LS.

PID – identifiant de protocole (Protocol ID)

Ce champ contient un identifiant qui identifie le protocole client/serveur qui utilise SCSP pour le message considéré. L'allocation des identifiants de protocole pour ce champ est dévolue à l'IANA comme décrit à l'Appendice C.

RS – serveur distant (Remote Server)

Du point de vue d'un LS, un RS est un serveur, distinct du LS, qui n'est pas directement connecté au LS (c'est-à-dire, un RS est toujours à deux bonds ou plus d'un LS tandis qu'un DCS est toujours à un bond d'un LS). Sauf mention contraire, un RS se réfère à un serveur dans le SG. Ce terme, ainsi que les termes LS et DCS, est utilisé pour donner un cadre de référence pour parler des serveurs et de leur synchronisation. Sauf déclaration explicite contraire, cela n'implique pas de différence de fonctionnalité entre DCS, LS, et RS.

SG – groupe de serveur (Server Group)

Le SCSP synchronise les antémémoires (ou une portion des antémémoires) d'un ensemble d'entités de serveur qui sont liées à un SG par certains moyens (par exemple, tous les serveurs appartenant à un sous-réseau logique IP (LIS) [1]). Donc, un SG est juste un groupement de serveurs autour de certains traits communs.

SGID – identifiant de groupe de serveurs (Server Group ID)

Cet ID est un champ d'identification de 16 bits qui identifie de façon univoque l'instance de protocole client/serveur pour laquelle les serveurs du SG sont synchronisés. Cela implique que plusieurs instances du même protocole peuvent fonctionner en même temps et avoir leurs serveurs synchronisés indépendamment les uns des autres.

Appendice B   Formats de message SCSP

Cet appendice comporte les formats de message pour SCSP. Les protocoles SCSP sont encapsulés en LLC/SNAP avec un LLC = 0xAA-AA-03, un OUI = 0x00-00-5e et un PID = 0x00-05.

SCSP a trois parties pour chaque paquet : la partie fixe, la partie obligatoire, et la partie extensions. La partie fixe du message existe dans chaque paquet et est montrée ci-dessous. La partie obligatoire est spécifique du type de message particulier (c'est-à-dire, CA, demande/réponse de CSU, Hello, CSUS) et elle comporte (entre autres éléments de paquet) une partie commune obligatoire et zéro, un ou plusieurs enregistrements dont chacun contient des informations pertinentes pour l'état d'une entrée particulière d'antémémoire (excepté dans le cas d'un message Hello) dont les informations sont synchronisées au sein d'un SG. La partie Extensions contient l'ensemble des extensions pour le message SCSP.

Dans les formats de message suivants, les champs marqués "non utilisé" DOIVENT être réglés à zéro à la transmission de tels messages et ignorés à la réception.

B.1   Partie fixe

 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|   Version     |  Code de type |        Taille de paquet       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     Somme de contrôle         |     Début des extensions      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version

C'est le numéro de la version du protocole SCSP utilisé. La version actuelle est 1.

Code de type

C'est le code pour le type de message (par exemple, Hello (5), Demande de CSU (2), Réponse de CSU (3), CSUS (4), CA (1)).

Taille de paquet

C'est la longueur totale du paquet SCSP, en octets (à l'exclusion de la couche de liaison et/ou de l'encapsulation d'autres protocoles).

Somme de contrôle

C'est la somme de contrôle IP standard sur la totalité du paquet SCSP qui commence à 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.

Début des extensions

Ce champ est codé à zéro lorsque aucune extension n'est présente dans le message. Si des extensions sont présentes, ce champ sera alors codé avec le décalage depuis le début de l'en-tête fixe jusqu'au commencement de la première extension.

B.2.0   Partie obligatoire

La partie obligatoire du paquet SCSP contient les informations spécifiques du fonctionnement pour un type de message donné (par exemple, Demande/Réponse de mise à jour d'état d'antémémoire SCSP, etc.) et elle comporte (entre autres éléments de paquet) une partie commune obligatoire (décrite au paragraphe B.2.0.1) et zéro ou plusieurs enregistrements dont chacun contient les informations pertinentes pour l'état d'une entrée d'antémémoire particulière (sauf dans le cas d'un message Hello) dont les informations sont synchronisées au sein d'un SG. Ces enregistrements peuvent, selon le type de message, être soit des enregistrements de résumé d'annonce d'état d'antémémoire (CSAS, décrits au paragraphe B.2.0.2) soit des enregistrements d'annonce d'état d'antémémoire (CSA, décrits au paragraphe B.2.2.1). Les enregistrements CSA contiennent un résumé des informations d'une entrée d'antémémoire (c'est-à-dire, un enregistrement CSAS) plus des informations supplémentaires spécifiques du protocole client/serveur. Le format de la partie commune obligatoire et le format de l'enregistrement CSAS sont donnés ci-dessous, puis on montre leur utilisation dans les messages SCSP, afin d'empêcher leur duplication dans les descriptions de message.

B.2.0.1   Partie commune obligatoire

Les formats montrés aux paragraphes B.2.1 à B.2.5 se chevauchent en substance. Ce chevauchement de format est appelé la partie commune obligatoire et ce format est montré ci-dessous :

 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 protocole    |   ID de groupe de serveurs    |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         non utilisé           |            Fanions            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| L. d'ID d'env.| L. d'ID recev.|    Nombre d'enregistrements   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|            Identifiant d'envoyeur (longueur variable)         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|            Identifiant de receveur (longueur variable)        |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Identifiant de protocole

Ce champ contient un identifiant qui identifie le protocole client/serveur qui utilise SCSP pour le message considéré. L'allocation des identifiants de protocole pour ce champ est dévolue à l'IANA comme décrit à l'Appendice C. Les protocoles avec les documents actuels ont les valeurs définies suivantes :

1 - ATMARP

2 - NHRP

3 - MARS

4 - DHCP

5 - LNNI

ID de groupe de serveurs

C'est l'identifiant univoque de l'instance de protocole client/serveur pour lequel les serveurs sont synchronisés.

Fanions

Le champ Fanions est spécifique du message, et son utilisation sera décrite dans les paragraphes sur les formats spécifiques de message.

L. d'ID d'env.

Ce champ contient la longueur en octets de l'identifiant d'envoyeur.

L. d'ID recev.

Ce champ contient la longueur en octets de l'identifiant de receveur.

Nombre d'enregistrements

Ce champ contient le nombre d'enregistrements supplémentaires associés au message considéré. Le format exact de ces enregistrements est spécifique du message et sera décrit pour chaque type de message dans les paragraphes suivants.

Identifiant d'envoyeur

C'est un identifiant alloué au serveur qui envoie le message considéré. Une allocation possible serait l'adresse de protocole du serveur d'envoi.

Identifiant de receveur

C'est un identifiant alloué au serveur qui va recevoir le message considéré. Une allocation possible serait l'adresse de protocole du serveur qui va recevoir le message considéré.

B.2.0.2   Enregistrement résumé d'annonce d'état d'antémémoire (enregistrement CSAS)

Les enregistrements CSAS contiennent un résumé des informations contenues dans une entrée d'antémémoire d'une base de données d'un client/serveur donné en cours de synchronisation au moyen de SCSP. Le résumé comporte assez d'informations pour que SCSP recherche dans la base de données client/serveur les entrées appropriées de base de données d'antémémoire et compare la "nouveauté" du résumé par rapport à la "nouveauté" de l'entrée d'antémémoire.

Noter que les enregistrements CSAS ne contiennent pas d'identifiant de groupe de serveur (SGID) ni d'identifiant de protocole. Ces identifiants sont nécessaires pour identifier pour quel protocole et quelle instance de ce protocole le résumé est applicable. Ces identifiants sont présents dans la partie commune obligatoire de chaque message.

Noter aussi que les valeurs des champs Compte de bonds et Longueur d'enregistrement d'un enregistrement CSAS dépendent de l'existence de l'enregistrement CSAS comme enregistrement "autonome" ou comme enregistrement CSAS "incorporé" dans l'enregistrement CSA. Ceci est décrit plus en détails ci-dessous.

 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|          Compte de bonds      |   Longueur d'enregistrement   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|L. clé d'antém |L. ID d'origine|     non utilisé               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                   numéro de séquence CSA                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                    Clé d'antémémoire...                       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                   Identifiant du générateur                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Compte de bonds

Ce champ représente le nombre de bonds que peut faire l'enregistrement avant d'être abandonné. Donc, à chaque serveur que traverse l'enregistrement, le compte de bonds est décrémenté. Ce champ est réglé à 1 quand l'enregistrement CSAS est un enregistrement "autonome" (c'est-à-dire, qu'il n'est pas incorporé au sein d'un enregistrement CSA) car les résumés ne vont pas au delà d'un bond durant le processus d'alignement d'antémémoire. Si un enregistrement CSAS est "incorporé" au sein d'un enregistrement CSA, le compte de bonds est alors réglé à une valeur définie administrativement qui est presque certainement supérieure ou égale à la cardinalité du SG moins un. Noter qu'une exception à la règle précédente survient lorsque l'enregistrement CSA est porté au sein d'une demande de CSU qui a été envoyée en réponse à une sollicitation (c'est-à-dire, en réponse à un enregistrement CSAS qui était envoyé dans un message CSUS) ; dans ce cas, le compte de bonds DEVRAIT être réglé à 1.

Longueur d'enregistrement

Si l'enregistrement CSAS est un enregistrement "autonome", cette valeur est 12 + "Longueur de clé d'antémémoire" + "Longueur d'identifiant d'origine" en octets ; autrement, cette valeur est réglée à 12 + "Longueur de clé d'antémémoire" + "Longueur d'identifiant d'origine" + taille de ("Partie spécifique de protocole client/serveur pour l'entrée d'antémémoire"). La taille de la partie spécifique du protocole client/serveur peut être obtenue du document spécifique de protocole client/serveur pour l'identifiant de protocole considéré.

Longueur de clé d'antémémoire

C'est la longueur en octets du champ Clé d'antémémoire.

Longueur de l'identifiant d'origine

C'est la longueur du champ Identifiant d'origine en octets.

N

Le bit "N" signifie que cet enregistrement CSAS est en fait un enregistrement nul. Ce bit est seulement utilisé dans un enregistrement CSAS contenu dans une Demande/Réponse de CSU qui est envoyée en réponse à un message CSUS. Il est possible qu'un LS reçoive une sollicitation pour un enregistrement CSA lorsque l'entrée d'antémémoire représentée par l'enregistrement CSA sollicité n'existe plus dans l'antémémoire du LS (voir les détails au paragraphe 2.3). Dans ce cas, le LS copie l'enregistrement CSAS directement du message CSUS dans la demande de CSU, et le LS règle le bit N signifiant que l'entrée d'antémémoire n'existe plus. Le DCS qui sollicite l'enregistrement CSA qui n'existe plus va quand même répondre avec une Réponse de CSU. Ce bit est normalement réglé à zéro.

numéro de séquence CSA

Ce champ contient un numéro de séquence qui identifie la "nouveauté" d'une instance d'enregistrement CSA en cours de résumé. Un numéro de séquence plus grand signifie une annonce plus récente. Donc, si l'état d'une partie (ou de la totalité) d'une entrée d'antémémoire a besoin d'être mis à jour, l'enregistrement CSA qui annonce le nouvel état DOIT contenir un numéro de séquence CSA supérieur à celui qui correspond à l'annonce précédente. Ce numéro est alloué par l'origine de l'enregistrement CSA. Le numéro de séquence CSA peut être alloué par le serveur d'origine ou par le client qui est cause de l'annonce de son existence par son serveur.

Le numéro de séquence CSA est un nombre signé de 32 bits. Au sein de l'espace des numéros de séquence CSA, le nombre -2^31 (0x80000000) est réservé. Donc, la portion utilisable de l'espace des numéros de séquence CSA pour une clé d'antémémoire données est entre les nombres -2^31+1 (0x80000001) et 2^31-1 (0x7fffffff). Un LS utilise -2^31+1 la première fois qu'il génère un enregistrement CSA pour une création d'entrée d'antémémoire. Chaque fois que l'entrée d'antémémoire est modifiée d'une façon quelconque et lorsque cette modification doit être synchronisée avec les autres serveurs dans le SG, le LS incrémente le numéro de séquence CSA associé à la clé d'antémémoire concernée et utilise ce nouveau numéro de séquence CSA lorsqu'il annonce la mise à jour. S'il se trouvait qu'un numéro de séquence CSA donné atteigne 2^31-2 et que l'entrée d'antémémoire associée ait été modifiée de telle sorte qu'une mise à jour doive être envoyée au reste des serveurs dans le SG, cette entrée d'antémémoire DOIT d'abord être purgée du SG par le LS gtâce à l'envoi d'un enregistrement CSA qui cause le retrait de l'entrée d'antémémoire des autres serveurs et cet enregistrement CSA porte un numéro de séquence CSA de 2^31-1. Le format exact de paquet et le mécanisme par lequel une entrée d'antémémoire est purgée sont définis dans le document spécifique de protocole approprié. Après que la purge de l'enregistrement CSA a été acquittée par chaque DCS, un LS va ensuite envoyer un nouvel enregistrement CSA portant les informations mises à jour, et ce nouvel enregistrement CSA portera un numéro de séquence CSA de -2^31+1.

Après un redémarrage et après que le CAFSM du LS qui redémarre a terminé l'état Aligné, si une mise à jour à une entrée existante d'antémémoire a besoin d'être synchronisée ou si une nouvelle entrée d'antémémoire doit être synchronisée, l'enregistrement CSA qui s'ensuit DOIT alors contenir un numéro de séquence CSA qui soit unique au sein du SG pour l'OID et la clé d'antémémoire concernés. La méthode RECOMMANDÉE d'obtention de ce numéro (sauf mention explicite contraire dans le document spécifique du protocole) est de régler le numéro de séquence CSA dans l'enregistrement CSA au numéro de séquence CSA associé à l'entrée d'antémémoire existante (si une entrée d'antémémoire périmée existe déjà et à zéro sinon) plus une constante configurée. Noter que le document spécifique du protocole peut exiger que toutes les entrées d'antémémoire contenant l'OID du LS qui redémarre soient purgées avant de mettre à jour les entrées d'antémémoire ; dans ce cas, l'enregistrement CSA de mise à jour va quand même contenir un numéro de séquence CSA établi au numéro de séquence CSA associé à l'entrée d'antémémoire existant précédemment plus une constante configurée.

Clé d'antémémoire

C'est une clé de recherche de base de données qui identifie de façon univoque un élément de données que l'origine d'un enregistrement CSA souhaite synchroniser avec ses homologues pour une paire donnée "Identifiant de protocole/Identifiant de groupe de serveurs". Cette clé va généralement être une petite chaîne d'octets opaque que SCSP va associer à un élément de données dans une antémémoire. Donc, par exemple, un générateur peut allouer une chaîne particulière de 4 octets à la liaison à une adresse IP avec celle d'une adresse ATM. En général, le serveur d'origine d'un enregistrement CSA est chargé de générer une clé d'antémémoire pour chaque élément de données que ce serveur génère et que le serveur souhaite synchroniser avec ses homologues dans le SG.

Identifiant d'origine

Ce champ contient un ID alloué administrativement au serveur qui est l'origine des enregistrements CSA.

B.2.1   Alignement d'antémémoire (CA)

Le message Alignement d'antémémoire (CA) permet à un LS de synchroniser la totalité de son antémémoire avec celle de ses DCS au sein d'un groupe de serveurs. Le code de type du message CA est 1. Le format de la partie obligatoire du message CA est le 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                    Numéro de séquence CA                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                  Partie commune obligatoire                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                       Enregistrement CSAS                     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              .......

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                       Enregistrement CSAS                     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Numéro de séquence CA

C'est une valeur qui donne un identifiant univoque pour aider au séquençage du processus d'alignement d'antémémoire. Un numéro de séquence "plus grand" signifie un message CA plus récent. Le serveur esclave copie toujours le numéro de séquence du message CA précédent du serveur maître dans son message CA en cours qu'il envoie et l'esclave accuse réception du message CA du maître. Comme le processus CA initial est verrouillé, si l'esclave ne reçoit pas le même numéro de séquence que celui qu'il avait reçu précédemment, les informations du précédent message CA de l'esclave sont implicitement acquittées. Noter qu'il y a un espace de numéro de séquence CA distinct qui est associé à chaque CAFSM.

Chaque fois qu'il est nécessaire de (re)démarrer l'alignement d'antémémoire et que le CAFSM entre dans l'état de négociation maître/esclave, le numéro de séquence CA devrait être réglé à une valeur non vue précédemment par le DCS. Un schéma possible est d'utiliser l'heure de la machine.

Partie commune obligatoire

La partie commune obligatoire est décrite en détail au paragraphe B.2.0.1. Il y a deux champs dans la partie commune obligatoire dont le codage est spécifique du type de message considéré. Ces champs sont le "Nombre d'enregistrements" et "Fanions".

Nombre d'enregistrements

Le champ Nombre d'enregistrements de la partie commune obligatoire du message CA donne le nombre d'enregistrements CSAS ajoutés à la partie obligatoire du message CA.

Fanions

Le champ Fanions de la partie commune obligatoire du message CA a le format suivant :

 0                   1

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|M|I|O|       non utilisé       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Ce bit fait partie du processus de négociation pour l'alignement d'antémémoire. Lorsque ce bit est établi, l'envoyeur du message CA indique qu'il souhaite conduire le processus d'alignement. Ce bit est le "bit maître/esclave".

I

Lorsque il est établi, ce bit indique que l'envoyeur du message CA pense qu'il est dans un état où il négocie le statut de maître ou d'esclave. Ce bit est le "bit d'initialisation".

O

Ce bit indique que l'envoyeur du message CA a d'autres enregistrements CSAS à envoyer. Cela implique que le processus d'alignement d'antémémoire doit continuer. Ce bit est le "bit plus" (mOre) en dépit de son nom ambigu.

Tous les autres champs de la partie commune obligatoire sont codés comme décrit au paragraphe B.2.0.1.

Enregistrement CSAS

Le message CA ajoute les enregistrements CSAS à la fin de sa partie obligatoire. Ces enregistrements CSAS NE SONT PAS incorporés dans les enregistrements CSA. Voir au paragraphe B.2.0.2 les détails des enregistrements CSAS.

B.2.2   Demande de mise à jour d'état d'antémémoire (Demande de CSU)

Le message Demande de mise à jour d'état d'antémémoire (Demande de CSU) est utilisé pour mettre à jour l'état des entrées d'antémémoire dans les serveurs qui sont directement connectés au serveur qui envoie le message. Un message Demande de CSU est envoyé d'un serveur (le LS) au serveur directement connecté (le DCS) lorsque le LS observe des changements dans l'état d'une ou plusieurs entrées d'antémémoire. Un LS observe un tel changement d'état en recevant une demande de CSU qui cause une mise à jour de sa base de données ou en observant un changement d'état d'une entrée d'antémémoire générée par le LS. Le changement d'état d'une entrée d'antémémoire est noté dans un message de CSU en ajoutant un enregistrement "Annonce d'état d'antémémoire" (CSA) à la fin de la partie obligatoire de la Demande de CSU comme indiqué ci-dessous.

Le code du type de message Demande de CSU est 2. Le format de la partie obligatoire du message Demande de CSU est le 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     Partie commune obligatoire                |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Enregistrement CSA                       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              .......

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                       Enregistrement CSA                      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Partie commune obligatoire

La partie commune obligatoire est décrite en détail au paragraphe B.2.0.1. Il y a dans la partie commune obligatoire deux champs dont le codage est spécifique du type de message. Ces champs sont "Nombre d'enregistrements" et "Fanions".

Nombre d'enregistrements

Le champ Nombre d'enregistrements de la partie commune obligatoire du message Demande de CSU donne le nombre d'enregistrements CSA ajoutés à la partie obligatoire du message Demande de CSU.

Fanions

Actuellement, il n'y a pas de fanion pour le champ Fanions de la partie commune obligatoire du message Demande de CSU.

Tous les autres champs de la partie commune obligatoire sont codés comme décrit au paragraphe B.2.0.1.

Enregistrement CSA

Voir au paragraphe B.2.2.1.

B.2.2.1   Enregistrement d'annonce d'état d'antémémoire (enregistrement CSA)

Les enregistrements CSA contiennent les informations nécessaires pour rapporter l'état actuel d'une entrée d'antémémoire dans un SG aux serveurs à synchroniser. Les enregistrements CSA contiennent un en-tête Enregistrement CSAS et une partie spécifique du protocole client/serveur. L'enregistrement CSAS comporte suffisamment d'informations pour que SCSP recherche dans la base de données client/serveur les entrées appropriées de base de données d'antémémoire et comparer alors la "nouveauté" des résumés à la "nouveauté" de l'entrée de l'antémémoire. Si les informations contenues dans le CSA sont plus nouvelles que l'entrée de l'antémémoire du serveur qui les reçoit, l'entrée de l'antémémoire est mise à jour conformément au contenu de l'enregistrement CSA. La partie spécifique du protocole client/serveur de l'enregistrement CSA est documentée séparément pour chacun de ces protocoles. Des exemples de parties spécifiques de protocole pour NHRP et ATMARP sont données respectivement dans [8] et [9].

La quantité d'informations portée par un enregistrement CSA spécifique peut excéder la taille de la PDU de couche liaison. Donc, de tels enregistrements CSA DOIVENT être fragmentés sur un certain nombre de messages Demande de CSU. La méthode par laquelle ceci est fait est spécifique du protocole client/serveur et est documenté dans le document spécifique de protocole approprié.

Le contenu d'un enregistrement CSA est le 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     Enregistrement CSAS                       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Partie specif. du proto. cl./serv. pour l'entrée d'antémém.... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Enregistrement CSAS

Voir au paragraphe B.2.0.2 les règles et le format de remplissage d'un enregistrement CSAS lorsque il est "incorporé" dans un enregistrement CSA.

Partie specif. du proto. cl./serv. pour l'entrée d'antémém.

Ce champ contient les champs qui sont spécifiques de la portion spécifique du protocole du traitement SCSP. Le réglage de ces champs est défini dans des documents distincts pour chaque protocole utilisateur de SCSP. L'identifiant de protocole, qui identifie le protocole qui utilise SCSP dans le paquet considéré, est situé dans la partie obligatoire du message.

B.2.3   Réponse de mise à jour d'état d'antémémoire (Réponse de CSU)

Le message Réponse de mise à jour d'état d'antémémoire (Réponse de CSU) est envoyé d'un DCS à un LS pour accuser réception d'un ou plusieurs enregistrements CSA qui ont été reçus dans une Demande de CSU. La réception d'un enregistrement CSA dans une Demande de CSU est acquittée par l'inclusion d'un enregistrement CSAS dans la Réponse de CSU qui correspond à l'enregistrement CSA dont on accuse réception. Le message Réponse de CSU a le même format que le message Demande de CSU sauf pour ce qui suit : le code de type est 3, seuls des enregistrements CSAS (plutôt que des enregistrements CSA) sont retournés, et seuls les enregistrements CSAS pour lesquels on accuse réception des enregistrements CSA sont retournés. Cela implique qu'un LS qui envoie une Demande de CSU peut ne pas recevoir un accusé de réception dans une seule Réponse de CSU pour tous les enregistrements CSA inclus dans la Demande de CSU.

B.2.4   Message Sollicitation de mise à jour d'état d'antémémoire (message CSUS)

Ce message permet à un serveur (LS) de solliciter la totalité des données de l'enregistrement CSA mémorisées dans l'antémémoire d'un serveur directement connecté (DCS). Le DCS répond par des messages Demande de CSU qui contiennent les enregistrements CSA appropriés. Le code du type de message CSUS est 4. Le format du message CSUS est le même que celui du message Réponse de CSU. Les messages CSUS sollicitent des demandes de CSU de la part d'un seul serveur (celui qui est identifié par l'identifiant de receveur dans la partie obligatoire du message).

B.2.5   Hello

Le message Hello est utilisé pour vérifier la connexité entre le serveur envoyeur (le LS) et un de ses serveurs voisins directement connectés (les DCS). Le code de type du message Hello est 5. Le format de la partie obligatoire du message Hello est le 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|          IntervalleHello      |        FacteurDeMort          |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|          non utilisé          |    Identifiant de famille     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                    Partie commune obligatoire                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Enregistrement d'identifiant de receveur supplémentaire    |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            .........

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Enregistrement d'identifiant de receveur supplémentaire    |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IntervalleHello

L'intervalle de Hello annonce le délai entre l'envoi des messages Hello consécutifs. Si le LS ne reçoit pas un message Hello du DCS (qui contient le LSID comme identifiant de receveur) dans le délai IntervalleHello annoncé par le DCS, le Hello du DCS est considéré comme en retard. Aussi, le LS DOIT envoyer son propre message Hello à un DCS dans le délai IntervalleHello qu'il a annoncé au DCS dans le message Hello précédent du LS à ce DCS (autrement, le DCS considèrerait que le Hello du LS est en retard).

FacteurDeMort

C'est un multiplicateur de l'IntervalleHello. Si un LS ne reçoit pas un message Hello qui contient le LSID du LS comme identifiant de receveur dans le l'intervalle IntervalleHello*FacteurDeMort de la part d'un DCS donné, qui a annoncé le IntervalleHello et le FacteurDeMort dans un message Hello précédent, le LS DOIT alors considérer que le DCS est périmé ; à ce moment, il DOIT arriver une des deux choses suivantes : 1) si le LS a reçu des messages Hello du DCS durant cette période, le LS passe le HFSM correspondant à l'état Unidirectionnel ; autrement, 2) le LS passe le HFSM correspondant à l'état Attente.

Identifiant de famille

C'est une chaîne binaire opaque qui est utilisée pour se référer à un agrégat de paires Identifiant de protocole/SGID. Un seul HFSM fonctionne pour toutes les paires Identifiant de protocole/SGID allouées à un identifiant de famille. Donc, il y a une transposition de un à plusieurs entre le HFSM et les CAFSM correspondants à chacune des paires Identifiant de protocole/SGID. Cela peut avoir pour effet net une réduction substantielle du trafic de maintenance HFSM. Voir les documents SCSP spécifiques du protocole pour les détails.

Partie commune obligatoire

La partie commune obligatoire est décrite en détail au paragraphe B.2.0.1. Il y a dans la partie commune obligatoire deux champs dont le codage est spécifique du type de message. Ces champs sont "Nombre d'enregistrements" et "Fanions".

Nombre d'enregistrements

Le champ Nombre d'enregistrements de la partie commune obligatoire pour le message Hello contient le nombre d'enregistrements "Identifiant supplémentaire de receveur" qui sont inclus dans le Hello. Les enregistrements supplémentaires d'identifiant de receveur contiennent un champ Longueur et un champ Identifiant de receveur. Noter que le compte de "Nombre d'enregistrements" N'INCLUT PAS l'identifiant de receveur qui est inclus dans la partie commune obligatoire.

Fanions

Il n'y a actuellement pas de fanion défini pour le champ Fanions dans la partie commune obligatoire pour le message Hello.

Tous les autres champs de la partie commune obligatoire sont codés comme décrit au paragraphe B.2.0.1.

Enregistrement supplémentaire d'identifiant de receveur

Cet enregistrement contient un champ Longueur suivi par un identifiant de receveur. Comme on peut concevoir que la longueur d'un identifiant de receveur puisse varier même au sein d'un SG, chaque identifiant de receveur supplémentaire entendu (a delà du premier) va avoir sa longueur en octets et sa valeur codés dans un "Enregistrement d'identifiant de receveur supplémentaire". Les identifiants de receveur sont des identifiants d'un DCS d'où le LS a entendu un Hello récent (c'est-à-dire, dans l'intervalle FacteurDeMort*IntervalleHello comme annoncé par le DCS dans un message Hello précédent).

Le format de cet enregistrement est le 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Long ID de rcv |              identifiant de receveur          |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Si le LS n'a rien entendu de la part d'aucun DCS, il règle alors les champs du message Hello comme suit : Long ID rcv est mis à zéro et aucune mémorisation n'est allouée pour l'identifiant de receveur dans la partie commune obligatoire, "Nombre d'enregistrements" est mis à zéro, et aucune mémorisation n'est alloué pour "Enregistrement d'identifiant de receveur supplémentaire".

Si le LS a entendu exactement un DCS, il règle alors les champs du message Hello comme suit : l'identifiant de receveur du DCS qui a été entendu et la longueur de cet identifiant de receveur sont codés dans la partie commune obligatoire, "Nombre d'enregistrements" est mis à zéro, et aucune mémorisation n'est allouée pour "Enregistrement d'identifiant de receveur supplémentaire".

Si le LS a entendu deux DCS ou plus, il règle les champs du message Hello comme suit : l'identifiant de receveur du premier DCS entendu et la longueur de cet identifiant de receveur sont codés dans la partie commune obligatoire, "Nombre d'enregistrements" est mis au nombre de DCS "supplémentaires" entendus, et pour chaque DCS additionnel, un "Enregistrement d'identifiant de receveur supplémentaire" est formé et ajouté à la fin du message Hello.

B.3   Partie extensions

La partie Extensions, si elle est présente, porte une ou plusieurs extensions dans des 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|          Type                 |              Longueur         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        Valeur...                              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

C'est le code de type d'extension (voir ci-dessous).

Longueur

La longueur en octets de la valeur (non inclus les champs Type et Longueur ; une extension nulle n'aura qu'un en-tête d'extension et une longueur de zéro).

Lorsque les extensions existent, la partie extensions se termine par une extension Fin des extensions, avec le Type = 0 et Longueur = 0.

Les extensions peuvent survenir dans n'importe quel ordre mais un type d'extension particulier ne peut survenir que dans un paquet SCSP. Un LS NE DOIT PAS changer l'ordre des extensions.

B.3.0   Fin des extensions

Type = 0 ; Longueur = 0

Lorsque des extensions existent, la partie extensions se termine par l'extension Fin des extensions.

B.3.1   Extension d'authentification SCSP

Type = 1 ; Longueur = variable

L'extension d'authentification SCSP est portée dans les paquets SCSP pour convoyer les informations d'authentification entre un LS et un DCS dans le même SG.

L'authentification est faite par paire de LS à DCS; c'est-à-dire que l'extension d'authentification est générée à chaque LS. Si un paquet reçu échoue à l'essai d'authentification, un "événement anormal" est survenu. Le paquet est éliminé et cet événement est enregistré.

La présence ou l'absence d'authentification est une affaire locale.

B.3.1.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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|            Indice de paramètre de sécurité (SPI)              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

+-+-+-+-+-+-+ 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 telles qu'un algorithme de hachage. LS et DCS communiquent hors ligne en utilisant une frappe manuelle ou en ligne en utilisant un protocole de gestion de clés pour remplir ce tableau. L'entité SCSP receveuse alloue toujours le SPI et les paramètres qui lui sont associés.

Le champ Données d'authentification contient le MAC (Code d'authentification de message) calculé sur la charge utile SCSP entière. La longueur de ce champ dépend de l'algorithme de hachage utilisé pour calculer le MAC.

B.3.1.2   Algorithmes de hachage pris en charge

L'algorithme de hachage par défaut à prendre en charge est HMAC-MD5-128 [11]. HMAC est plus sûr que les hachages de clé normaux. D'autres algorithmes de hachage PEUVENT être pris en charge par défaut.

B.3.1.3   SPI et négociation des paramètres de sécurité

Les SPI peuvent être négociés soit manuellement soit en utilisant un protocole Internet de gestion de clés. Le traitement manuel DOIT être accepté. Les paramètres suivants sont associés au tuplet <SPI, DCS ID> - Durée de vie, Algorithme, Clé. Durée de vie indique la durée en secondes pendant laquelle la clé est valide. En cas de traitement manuel, cette durée peut être infinie. Aussi, afin de mieux prendre en charge le traitement manuel, il peut y avoir plusieurs tuplets actifs en même temps (l'ID du DCS étant le même).

Tout protocole Internet de gestion de clés standard PEUT être utilisé pour négocier le SPI et les paramètres.

B.3.1.4   Traitement de message

Au moment de l'ajout de l'en-tête d'extension d'authentification, le LS recherche dans un tableau pour aller chercher le SPI et les paramètres de sécurité sur la base de l'ID du DCS. Si il n'y a pas d'entrées dans le tableau et si la gestion de clés est prise en charge, le LS initie le protocole de gestion de clés pour aller chercher les paramètres nécessaires. Le LS calcule alors le hachage en mettant à zéro le champ de données d'authentification avant de calculer le MAC sur l'extrémité d'envoi. Le résultat remplace le champ de données d'authentification mis à zéro. 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.

Lors de la réception de trafic, un LS va chercher les paramètres sur la base du SPI et de son identifiant. Le champ des données d'authentification est extrait avant de le mettre à zéro pour calculer le hachage. Il calcule le hachage sur la charge utile entière et si le hachage ne correspond pas, un "événement anormal" s'est produit.

B.3.1.5   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 d'un choix approprié des clés et de la mise en œuvre correcte des algorithmes.

SCSP a un modèle de confiance d'homologue à homologue. Il est recommandé d'utiliser un protocole Internet de gestion de clés standard 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é.

L'intégrité des données couvre la totalité de la charge utile SCSP. Cela garantit que le message n'a pas été modifié et la source est aussi authentifiée. Si l'extension d'authentification n'est pas utilisée ou si la sécurité est compromise, Les serveurs SCSP sont alors vulnérables à la fois à des attaques d'espionnage, actives et 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. Comme l'intégrité est calculée sur un message SCSP et non sur chaque enregistrement, il y a une confiance implicite entre tous les serveurs dans un domaine. Il est recommandé d'utiliser l'extension de sécurité entre tous les serveurs dans un domaine et pas seulement juste sur un sous ensemble de serveurs.

Tout serveur SCSP est susceptible d'attaques de déni de service (DOS). Un hôte pirate peut inonder ses serveurs SCSP voisins de paquets SCSP. Cependant, si l'option d'authentification est utilisée, les bases de données SCSP ne seront pas corrompues, car les paquets falsifiés seront éliminés lors de l'échec de la vérification de l'authentification.

Du fait du modèle d'authentification par paire de SCSP, les informations reçues de tout serveur correctement authentifié sont de confiance et sont propagées dans tout le groupe de serveurs. Par conséquent, si la sécurité d'un seul serveur SCSP est compromise, la base de données entière devient vulnérable à une corruption générée par le serveur compromis.

B.3.2   Extension SCSP de fabricant privé

Type = 2 ; Longueur = variable

L'extension SCSP de fabricant privé est portée dans les paquets SCSP pour convoyer des informations de fabricant privé entre un LS et un DCS dans le même SG et est donc d'utilisation limitée. Si une granularité plus fine (par exemple, au niveau de l'enregistrement CSA) est désirée , un document SCSP spécifique d'un protocole client/serveur donné DOIT définir de tels mécanismes. Évidemment cependant, un tel mécanisme spécifique du protocole peut ressembler exactement à cette extension. L'extension SCSP de fabricant privé PEUT NE PAS apparaître plus d'une fois dans un paquet SCSP pour une valeur d'identifiant de fabricant donnée.

 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

L'identifiant de fabricant 802 a été alloué par l'IEEE [7].

Données

Les octets restants après l'identifiant de fabricant dans la charge utile sont des données qui dépendent du fabricant.

Si le receveur ne traite pas cette extension, ou ne satisfait pas à l'identifiant de fabricant dans l'extension, cette extension peut alors être complètement ignorée par le receveur.

Appendice C.   Considérations relatives à l'IANA

Toutes les demandes d'allocation de valeurs tirées des divers espaces de nombres décrits dans le présent document requièrent une documentation appropriée. Les formes possibles de documentation incluent, sans y être limitées, les RFC ou le produit d'un autre organisme de normalisation coopératif (par exemple le sous groupe de travail MPOA ou LANE de l'ATM Forum). D'autres demandes peuvent aussi être acceptées, selon l'avis d'un "expert désigné". (Contacter l'IANA pour les informations de contact de l'expert actuel.)

Références

(Les liens sur les numéros pointent sur la version anglaise, ceux dans le titre sur l'éventuelle traduction française)

[1]   M. Laubach, J. Halpern, "IP et ARP classiques sur ATM", RFC2225, avril 1998. (P.S.)

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

[4]   "P-NNI V1", Dykeman, Goguen, 1996.

[5]   G. Armitage, "Prise en charge de la diffusion groupée sur réseaux ATM fondés sur UNI 3.0/3.1", RFC2022, novembre 1996. (P.S.)

[6]   Keene, "LAN Emulation over ATM Version 2 - LNNI specification", btd-lane-lnni-02.08

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

[8]   J. Luciani, "Service NHRP réparti utilisant SCSP", RFC2335, avril 1998. (P.S.)

[9]   Luciani, J., "A Distributed ATMARP Service Using SCSP", Travail en cours.

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

[11]   H. Krawczyk, M. Bellare et R. Canetti, "HMAC : Hachage de clés pour l'authentification de message", RFC2104, février 1997.

Remerciements

Le présent mémoire compile divers problèmes soulevés lors de discussions privées, sur la liste de diffusion du groupe de travail IP-ATM, et durant la réunion de Dallas de l'IETF (12/95). Merci à tous ceux qui ont contribué et en particulier aux personnes suivantes (sans ordre particulier) : Barbara Fox de Harris et Jeffries ; Colin Verrilli de IBM ; Raj Nair, et Matthew Doar de Ascom Nexion ; Andy Malis de Cascade ; Andre Fredette de Bay Networks ; James Watt de Newbridge ; et Carl Marcinik de Fore.

Adresse des auteurs

Naganand Doraswamy

Bay Networks, Inc.

3 Federal St, BL3-03

Billerice, MA 01821

téléphone : +1-978-916-1323

mél : naganand@baynetworks.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 droits de reproduction définis dans les processus des normes pour l'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, 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éclinent 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.