Groupe de travail Réseau	M. Shand, Cisco Systems	
Request for Comments : 5306	L. Ginsberg, Cisco Systems	
Rend obsolète la RFC3847	octobre 2008	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Signalisation de redémarrage pour IS-IS

Statut de ce 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 (2008).

Résumé
Le présent document décrit un mécanisme pour qu'un routeur qui redémarre signale à ses voisins qu'il redémarre, leur permettant de rétablir leurs adjacences sans passer par l'état Désactivé, tout en initiant correctement la synchronisation de base de données.

Le présent document décrit de plus un mécanisme pour qu'un routeur qui redémarre détermine quand il a terminé la synchronisation de base de données d'unités de données de protocole d'état de liaison (LSP, Link State Protocol) avec ses voisins et un mécanisme pour optimiser la synchronisation de base de données de LSP, tout en minimisant l'interruption transitoire d'acheminement quand un routeur démarre. Le présent document rend obsolète la RFC 3847.
Table des matières
1. Introduction	1
2. Conventions utilisées dans ce document	2
3. Approche	2
3.1 Temporisateurs	2
3.2 TLV Restart	3
3.3 (Ré)acquisition d'adjacence	5
3.4 Synchronisation de base de données	7
4. Tableaux d'état	9
4.1 Routeur en fonctionnement	9
4.2 Redémarrage de routeur	9
4.3 Démarrage de routeur	10
5. Considérations sur la sécurité	11
6. Considérations relatives à l'IANA	11
7. Considérations de gestion	11
8. Remerciements	11
9. Références normatives	11
Adresse des auteurs	12
Déclaration complète de droits de reproduction	12

 	1.	Introduction

Le protocole d'acheminement de système intermédiaire à système intermédiaire(IS-IS, Intermediate System to Intermediate System) [RFC1195], [ISO10589] est un protocole d'acheminement intra domaine d'état de liaison. Normalement, quand un routeur IS-IS est redémarré, une interruption temporaire de l'acheminement se produit due aux événements dans le routeur qui redémarre et chez les voisins du routeur qui redémarre.

Le routeur qui a été redémarré calcule ses propres chemins avant de réaliser la synchronisation de base de données avec ses voisins. Les résultats de ce calcul ne vont probablement pas être convergents avec les chemins calculés par les autres routeurs dans la zone/domaine.

Les voisins du routeur qui redémarre détectent l'événement de redémarrage et règlent leurs adjacences avec le routeur qui redémarre à travers l'état "Désactivé". Le réglage de l'état d'adjacence cause la régénération par les voisins de leurs LSP qui décrivent l'adjacence concernée. Ceci à son tour cause une interruption temporaire des chemins qui passent à travers le routeur qui redémarre.

Dans certains scénarios, l'interruption temporaire des chemins est très indésirable. Le présent document décrit des mécanismes pour éviter ou minimiser l'interruption due à ces deux causes.

Quand une adjacence est réinitialisée par suite du redémarrage d'un voisin, un routeur fait les trois choses suivantes :

1.	Il cause la régénération de ses propres LSP, déclenchant donc des calculs de SPF à travers la zone (ou dans le cas d'un niveau 2, à travers le domaine).

2.	Il établit les fanions SRM sur sa propre base de données de LSP pour l'adjacence concernée.

3.	Dans le cas d'une liaison point à point, il transmet un ensemble complet de PDU Numéro de séquence complet (CSNP, Complete Sequence Number PDU) sur l'adjacence.

Dans le cas de processus de routeur qui redémarre, le premier est très indésirable, mais le second est essentiel afin d'assurer la synchronisation de la base de données de LSP.

La troisième action minimise le nombre de LSP qui doivent être échangés et, si c'est fait de façon fiable, fournit un moyen pour déterminer quand les bases de données de LSP des routeurs du voisinage ont été synchronisées. Ceci est désirable que le routeur soit ou non redémarré (de sorte que le bit Surcharge peut être à zéro dans le propre LSP du routeur, par exemple).

Le présent document décrit un mécanisme pour qu'un routeur qui redémarre signale qu'il redémarre à ses voisins, et leur permette de rétablir leurs adjacences sans passer par l'état Désactivé, tout en initiant quand même correctement la synchronisation des bases de données.

Le présent document décrit de plus un mécanisme pour qu'un routeur qui redémarre détermine quand il a achevé la synchronisation de base de données de LSP avec ses voisins et un mécanisme pour optimiser la synchronisation de base de données de LSP et minimiser l'interruption transitoire d'acheminement quand un routeur démarre.

On suppose que la prise de contact à trois phases [RFC5303] est utilisée sur les circuits en point à point.

 	2.	Conventions utilisées dans ce document

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

Si les fonctions de contrôle et de transmission dans un routeur peuvent être maintenues indépendamment, il est possible que l'état de la fonction de transmission soit maintenu à travers une reprise des opérations de la fonction de contrôle. Cette fonctionnalité est supposée quand les termes "redémarrage/qui redémarre" sont utilisés dans le présent document.

Les termes "démarrage/qui démarre" sont utilisés pour se référer à un routeur dans lequel la fonction de contrôle a soit commencé ses opérations pour la première fois, soit a repris ses opérations, mais les fonctions de transmission n'ont pas été maintenues à un état antérieur.

Les termes "(re)démarrage/(qui re)démarre" sont utilisés quand le texte est applicable à la fois au routeur qui "démarre" et qui "redémarre".

 	3.	Approche
 	3.1	Temporisateurs
Trois temporisateurs supplémentaires, T1, T2, et T3, sont exigés pour prendre en charge la fonctionnalité définie dans le présent document.

Une instance de temporisateur T1 est maintenue par interface, et indique le temps après lequel une tentative de (re)démarrage non acquittée va être répétée. Une valeur typique pourrait être 3 secondes.

Une instance de temporisateur T2 est maintenue pour chaque base de données de LSP (LSPDB, LSP database) présente dans le système, c'est-à-dire, pour un système de niveau 1/2, il va y avoir une instance de temporisateur T2 pour le niveau 1 et une instance pour le niveau 2. C'est le délai maximum pendant lequel le système va attendre la synchronisation de LSPDB. Une valeur typique pourrait être 60 secondes.

Une seule instance de temporisateur T3 est maintenue pour le système entier. Il indique le délai après lequel le routeur va déclarer qu'il a échoué à réaliser la synchronisation de base de données (en établissant le bit de surcharge dans son propre LSP). Il est initialisé à 65  535 secondes, mais est réglé au minimum du temps restant de Hello IS-IS reçus (IIH, Hello IS-IS) contenant un TLV Redémarrage avec l'accusé de réception de redémarrage (RA, Restart Acknowledgement) établi et une indication que le voisin a une adjacence dans l'état "Actif" au routeur qui redémarre.

Note : le temporisateur T3 n'est utilisé que par un routeur qui redémarre.

 	3.2	TLV Redémarrage
Un nouveau TLV est défini pour être inclus dans les PDU IIH. La présence de ce TLV indique que l'envoyeur prend en charge la fonctionnalité définie dans le présent document et qu'il porte des fanions qui sont utilisés pour porter des informations durant un (re)démarrage. Tous les IIH transmis par un routeur qui prend en charge cette capacité DOIVENT inclure ce TLV.

Type : 211
Longueur : nombre d'octets dans le champ Valeur (1 à (3 + Longueur d'identifiant))
Valeur :

                            Nombre d'octets
+-----------------------+
|   Fanions             |     1
+-----------------------+
| Temps restant         |     2
+-----------------------+
| ID de voisin redémar. |     Longueur d'identifiant
+-----------------------+

Fanions (1 octet)
 0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
|  Réservé     |SA|RA|RR|
+--+--+--+--+--+--+--+--+

RR (Restart Request) demande de redémarrage
RA (Restart Acknowledgement) accusé de réception de redémarrage
SA (Suppress adjacency advertisement) annonce de suppression d'adjacence

(Note : Les champs restants sont exigés quand le bit RA est établi.)

Temps restant (2 octets) : temps de garde restant (en secondes)

Identifiant de système voisin qui redémarre (octets de longueur d'identifiant) : identifiant de système du voisin auquel RA se réfère.

Note :	les mises en œuvre qui se fondent sur des versions antérieures du présent document peuvent ne pas inclure ce champ dans le TLV quand le bit RA est établi. Dans ce cas, un routeur qui attend un RA sur un circuit de LAN DEVRAIT supposer que l'accusé de réception est dirigé sur le système local.

 	3.2.1	Utilisation des bits RR et RA
Le bit RR est utilisé par un routeur qui (re)démarre pour signaler à ses voisins qu'un (re)démarrage est en cours, qu'une adjacence existante DEVRAIT être maintenue même dans des circonstances où le fonctionnement normal de l'automate à état d'adjacence exigerait que l'adjacence soit réinitialisée, pour demander un ensemble de CSNP, et pour demander l'établissement des fanions SRM.

Le bit RA est envoyé par le voisin d'un routeur qui (re)démarre pour accuser réception d'un TLV Redémarrage avec le bit RR établi.

Quand le voisin d'un routeur qui (re)démarre reçoit un IIH avec le TLV Redémarrage qui a le bit RR établi, si il existe sur cette interface une adjacence dans l'état "Activé" avec le même identifiant de système, et dans le cas d'un circuit de LAN, avec la même adresse de source de LAN, alors, sans considération des autres contenus de l'option "Voisins de système intermédiaire" (circuits de LAN) ou de l'option "Adjacence point à point en trois phases" (circuits point à point) :

a.	L'état de l'adjacence n'est pas changé. Si c'est le premier IIH avec le bit RR établi que ce système a reçu associé à cette adjacence, l'adjacence est alors marquée comme étant en "mode redémarrage" et le temps de garde de l'adjacence est rafraîchi – autrement, le temps de garde n'est pas rafraîchi. Le "temps restant" transmis conformément au point (b) ci-dessous DOIT refléter le temps réel après lequel l'adjacence va maintenant expirer. La réception d'un IIH normal avec le bit RR rétabli va supprimer l'état "mode redémarrage". Cette procédure permet au routeur qui redémarre de causer le maintien chez le voisin de l'adjacence pendant assez longtemps pour que le redémarrage s'achève avec succès, tout en empêchant aussi des redémarrages répétitifs maintenant indéfiniment une adjacence. Qu'une adjacence soit ou non marquée comme étant dans le "mode redémarrage" n'a pas d'effet sur les transitions d'état d'adjacence.

b.	Immédiatement (c'est-à-dire, sans attendre qu'un intervalle de temporisateur actuellement en cours arrive à expiration, mais avec un petit délai aléatoire de quelques dixièmes de millisecondes sur les LAN pour éviter des "tempêtes") transmettre sur l'interface correspondante un IIH incluant le TLV Redémarrage avec le bit RR à zéro et le bit RA établi, dans le cas des adjacences de point à point ayant mis à jour l'option "Adjacence point à point en trois phases" pour refléter toute nouvelle valeur reçue du routeur qui (re)démarre. (Cela permet à un routeur qui redémarre d'acquérir rapidement les informations correctes à placer dans ses Hello.) Le "Temps restant" DOIT être réglé à l'heure actuelle (en secondes) avant que le temporisateur de garde sur cette adjacence arrive à expiration. Si l'interface correspondante est une interface de LAN, alors l'identifiant de système de voisin qui redémarre DEVRAIT être réglé à l'identifiant de système du routeur d'où le IIH avec le bit RR établi a été reçu. Ceci est nécessaire pour associer correctement l'accusé de réception et le temps de garde dans le cas où plusieurs systèmes sur un LAN redémarrent approximativement au même moment. Ce IIH DEVRAIT être transmis avant que des LSP ou SNP soient transmis par suite de la réception du IIH original.

c.	Si l'interface correspondante est une interface point à point, ou si le routeur receveur a la plus forte LnRouterPriority (avec le départage de plus forte adresse de source de commande d'accès au support physique MAC, Media Access Control)) parmi les routeurs auxquels le routeur receveur a une adjacence dans l'état "Activé" sur cette interface dont les IIH contiennent le TLV Redémarrage, en excluant les adjacences à tous les routeurs qui sont considérés en "mode redémarrage" (noter que le DIS N'est PAS changé par ce processus) initier la transmission sur l'interface correspondante d'un ensemble complet de CSNP, et établir les fanions SRM sur l'interface correspondante pour tous les LSP dans la base de données de LSP locale.

Autrement (c'est-à-dire, si il n'y avait pas d'adjacence dans l'état "Activé" à l'identifiant de système en question) traiter le IIH comme normal en réinitialisant l'adjacence et en établissant le bit RA dans le IIH retourné.

 	3.2.2	Utilisation du bit SA
Le bit SA est utilisé par un routeur qui démarre pour demander que son voisin supprime l'annonce de l'adjacence au routeur qui démarre dans les LSP du voisin.

Un routeur qui démarre n'a pas d'état de fonction de transmission maintenu. Ce peut être ou non la première fois que le routeur a démarré. Si ce n'est pas la première fois que le routeur démarre, des copies des LSP générés par ce routeur dans sa précédente incarnation peuvent exister dans les bases de données de LSP des autres routeurs dans le réseau. Ces copies vont probablement apparaître comme "plus nouvelles" que les LSP initialement générés par le routeur qui démarre dues à la réinitialisation des numéros de séquence de fragments de LSP par le routeur qui démarre. Cela peut causer des trous noirs temporaires jusqu'à ce que le fonctionnement normal du processus de mise à jour cause la régénération et l'arrosage par le routeur qui démarre de copies de ses propres LSP avec des numéros de séquence plus élevés. Les trous noirs temporaires peuvent être évités si les voisins du routeur qui démarre suppriment d'annonce d'une adjacence au routeur qui démarre jusqu'à ce que le routeur qui démarre soit capable de propager des versions plus récentes des LSP générés par les incarnations précédentes.

Quand un routeur reçoit un IIH avec le TLV Redémarrage qui a le bit SA établi, si il existe sur cette interface une adjacence dans l'état "Activé" avec le même identifiant de système, et dans le cas d'un circuit de LAN, avec la même adresse de source de LAN, le routeur DOIT alors supprimer l'annonce de l'adjacence au voisin dans ses propres LSP. Jusqu'à ce qu'un IIH avec le bit SA à zéro ait été reçu, l'annonce de voisin DOIT continuer d'être supprimée. Si l'adjacence passe à l'état "Activé", la nouvelle adjacence NE DOIT PAS être annoncée tant qu'un IIH avec le bit SA à zéro n'a pas été reçu.

Noter qu'un routeur qui supprime l'annonce d'une adjacence NE DOIT PAS utiliser cette adjacence quand il effectue son calcul de SPF. En particulier, si une mise en œuvre suit les exemples de lignes directrices présentées dans [ISO10589], Annexe C.2.5, étape 0:b) "TENT pré chargé avec la base de données d'adjacence locale", l'adjacence supprimée NE DOIT PAS être chargée dans TENT.

 	3.3	(Ré)acquisition d'adjacence
La (ré)acquisition d'adjacence est la première étape de la (ré)initialisation. Les routeurs qui démarrent et redémarrent vont utiliser le bit RR dans le TLV Redémarrage, bien que chacun va l'utiliser à des étapes différentes de la procédure de (re)démarrage.

 	3.3.1	Ré-acquisition d'adjacence durant le redémarrage
Le routeur qui redémarre notifie explicitement à son voisin que l'adjacence est acquise à nouveau, et donc qu'il NE DEVRAIT PAS réinitialiser l'adjacence. Ceci se fait en établissant le bit RR dans le TLV Redémarrage. Quand le voisin d'un routeur qui redémarre reçoit un IIH avec le TLV Redémarrage qui a le bit RR établi, si il existe sur cette interface une adjacence dans l'état "Activé" avec le même identifiant de système, et dans le cas d'un circuit de LAN, avec la même adresse de LAN de source, on suit alors les procédures décrites au paragraphe 3.2.1.

Un routeur qui ne prend pas en charge la capacité de redémarrage va ignorer le TLV Redémarrage et réinitialiser l'adjacence comme normalement, en retournant un IIH sans le TLV Redémarrage.

Au redémarrage, un routeur initialise le temporisateur T3, lance le temporisateur T2 pour chaque LSPDB, et pour chaque interface (et dans le cas d'un circuit de LAN, pour chaque niveau) lance le temporisateur T1 et transmet un IIH contenant le TLV Redémarrage avec le bit RR établi.

Sur un circuit point à point, le routeur qui redémarre DEVRAIT régler "État d'adjacence trois phases" à "Initialisation", parce que la réception de l'IIH qui accuse réception (avec RA établi) DOIT causer l'entrée immédiate de l'adjacence dans l'état "Activé".

Sur un circuit de LAN, l'identifiant de LAN alloué au circuit DEVRAIT être le même que celui utilisé avant le redémarrage. En particulier, pour tout circuit pour lequel le routeur qui redémarre était précédemment DIS, l'utilisation d'un identifiant de LAN différent nécessiterait la génération d'un nouvel ensemble de LSP de pseudo nœuds, et les changements correspondants dans tous les LSP qui y font référence à partir des autres routeurs sur le LAN. En préservant l'identifiant de LAN à travers le redémarrage, ce changement peut être évité. Pour permettre à un routeur qui redémarre d'apprendre l'identifiant de LAN utilisé avant le redémarrage, l'identifiant de LAN spécifié dans un IIH avec le bit RR établi DOIT être ignoré.

La transmission des IIH "normaux" est inhibée jusqu'à ce que les conditions décrites ci-dessous soient satisfaites (afin d'éviter de causer une initialisation d'adjacence inutile). À l'expiration du temporisateur T1, il est redémarré et le IIH est retransmis comme ci-dessus.

Quand un routeur qui redémarre reçoit un IIH, une adjacence locale est établie comme d'habitude, et si le IIH contient un TLV Redémarrage avec le bit RA établi (et sur les circuits de LAN avec un identifiant de système de voisin qui redémarre qui correspond à celui du système local) la réception de l'accusé de réception sur cette interface est notée. Quand le bit RA est établi et que l'état de l'adjacence distante est "Activé", le temporisateur T3 est alors établi au minimum de sa valeur courante et de la valeur du champ "Temps restant" dans l'IIH reçu.

Sur une liaison point à point, la réception d'un IIH qui ne contient pas de TLV Redémarrage est aussi traitée comme un accusé de réception, car elle indique que le voisin n'est pas capable de redémarrage. Cependant, comme aucun CSNP n'est garanti d'être reçu sur cette interface, le temporisateur T1 est annulé immédiatement sans attendre un ensemble complet de CSNP. La synchronisation peut donc être réputée complète même si il y a quelques LSP qui sont détenus (seulement) par ce voisin (voir au paragraphe 3.4). Dans ce cas, on veut aussi être certain que le voisin va réinitialiser l'adjacence afin de garantir que les fanions SRM ont été établis sur sa base de données, assurant donc l'éventuelle synchronisation de LSPDB.  Ceci est garanti sauf dans le cas où l'état d'adjacence trois phases dans l'IIH reçu est "Activé" et où l'identifiant de circuit local étendu de voisin correspond à l'identifiant de circuit local étendu alloué par le routeur qui redémarre. Dans ce cas, le routeur qui redémarre DOIT forcer l'adjacence à se réinitialiser en réglant l'état d'adjacence trois phases local à "Désactivé" et en envoyant un IIH normal.

Dans le cas d'une interface de LAN, la réception d'un IIH qui ne contient pas le TLV Redémarrage est pas remarquable parce que la synchronisation peut encore se produire tant qu'au moins un des routeurs non redémarrant du voisinage sur le LAN prend en charge le redémarrage. Donc, T1 continue de tourner dans ce cas. Si aucun des voisins sur le LAN n'est capable de redémarrage, T1 va finalement arriver à expiration après le nombre d'essais défini en local.

Dans le cas d'un circuit point à point, les informations de "Identifiant de circuit local" et "Identifiant de circuit local étendu" contenues dans l'IIH peuvent être utilisées immédiatement pour générer un IIH contenant les informations correctes de prise de contact en trois phases. La présence des informations de "Identifiant de circuit local étendu voisin" qui ne correspondent pas à la valeur actuellement utilisées par le système local est ignorée (car le IIH peut avoir été transmis avant que le voisin ait reçu la nouvelle valeur du routeur qui redémarre) mais l'adjacence reste dans l'état d'initialisation jusqu'à ce que les informations correctes soient reçues.

Dans le cas d'un circuit de LAN, les informations de source de voisin (par exemple, SNPAAddress) sont enregistrées et utilisées pour l'établissement et la maintenance d'adjacence comme normalement.

Quand un ensemble complet de CSNP (pour chaque niveau actif, dans le cas d'un circuit point à point) ET un accusé de réception ont été reçus sur l'interface, le temporisateur T1 est annulé.

Une fois que le temporisateur T1 a été annulé, les IIH suivants sont transmis en accord avec les algorithmes normaux, mais en incluant le TLV Redémarrage avec les deux bits RR et RA à zéro.

Si un LAN contient un mélange de systèmes, dont seuls certains prennent en charge le nouvel algorithme,la synchronisation de la base de données est encore garantie, mais les "vieux" systèmes auront réinitialisé leurs adjacences.

Si une interface est active, mais n'a pas de routeur voisin accessible sur cette interface, le temporisateur T1 ne va jamais être annulé, et conformément au paragraphe 3.4.1.1, le SPF ne va jamais pouvoir fonctionner. Donc, le temporisateur T1 est annulé après un nombre prédéterminé d'expirations (qui PEUT être 1).

 	3.3.2	Acquisition d'adjacence durant le démarrage
Le routeur qui démarre veut s'assurer qu'au cas où un routeur du voisinage a une adjacence avec le routeur qui démarre dans l'état "Activé" (d'une précédente incarnation du routeur qui démarre) cette adjacence est réinitialisée. Le routeur qui démarre veut aussi que les routeurs du voisinage suppriment l'annonce d'une adjacence au routeur qui démarre jusqu'à ce que la synchronisation de la base de données de LSP soit achevée. Ceci est réalisé par l'envoi de IIH avec le bit RR à zéro et le bit SA établi dans le TLV Redémarrage. Le bit RR reste à zéro et le bit SA reste établi dans les transmissions suivantes des IIH jusqu'à ce que l'adjacence ait atteint l'état "Activé" et que l'intervalle initial du temporisateur T1 (voir ci-dessous) soit arrivé à expiration.

La réception d'un IIH avec le bit RR à zéro va avoir pour résultat que le routeur du voisinage qui utilise le fonctionnement normal de l'automate à états de l'adjacence. Cela va assurer que toute ancienne adjacence sur le routeur du voisinage va être réinitialisée.

À réception d'un IIH avec le bit SA établi, le comportement décrit au paragraphe 3.2.2 est suivi.

Au démarrage, un routeur lance le temporisateur T2 pour chaque LSPDB.

Pour chaque interface (et dans le cas d'un circuit de LAN, pour chaque niveau) quand une adjacence atteint l'état "Activé", le routeur qui démarre lance un temporisateur T1 et transmet un IIH contenant le TLV Redémarrage avec le bit RR à zéro et bit SA établi. À l'expiration du temporisateur T1, il est redémarré et le IIH est retransmis avec les deux bits RR et SA établis (seulement si le bit RR a changé d'état par rapport à des IIH antérieurs).

À réception d'un IIH avec le bit RR établi (que le bit SA soit ou non établi) le comportement décrit au paragraphe 3.2.1 est suivi.

Quand un IIH est reçu par le routeur qui démarre et que l'IIH contient un TLV Redémarrage avec le bit RA établi (et sur les circuits de LAN avec un identifiant de système voisin qui redémarre qui correspond à celui du système local) la réception de l'accusé de réception sur cette interface est notée.

Sur une liaison point à point, la réception d'un IIH qui ne contient pas de TLV Redémarrage est aussi traitée comme un accusé de réception, car elle indique que le voisin n'est pas capable de redémarrage. Comme le voisin va avoir réinitialisé l'adjacence, cela garantit que les fanions SRM ont été établis sur sa base de données, assurant une éventuelle synchronisation de LSPDB. Cependant, comme il n'est pas garanti qu'une CSNP soit reçue sur cette interface, le temporisateur T1 est annulé immédiatement sans attendre un ensemble complet de CSNP. La synchronisation peut donc être réputée achevée même si il y a des LSP qui sont détenus (seulement) par ce voisin (voir au paragraphe 3.4).

Dans le cas d'une interface de LAN, la réception d'un IIH qui ne contient pas de TLV Redémarrage est non remarquable car la synchronisation peut encore se produire tant qu'au moins un des routeurs du voisinage qui ne redémarrent pas sur le LAN prend en charge le redémarrage. Donc, T1 continue de tourner dans ce cas. Si aucun des voisins sur le LAN n'est capable de redémarrage, T1 va finalement arriver à expiration après le nombre d'essais défini en local. Le fonctionnement habituel du processus de mise à jour va assurer que la synchronisation est finalement achevée.

Quand un ensemble complet de CSNP (pour chaque niveau actif, dans le cas d'un circuit point à point) et un accusé de réception ont tous deux été reçus sur l'interface, le temporisateur T1 est annulé. Les IIH suivants envoyés par le routeur qui démarre ont les bits RR et RA à zéro et le bit SA établi dans le TLV Redémarrage.

Le temporisateur T1 est annulé après un nombre prédéterminé d'expirations (qui PEUT être 1).

Quand le ou les temporisateurs T2 sont annulés ou expirent, la transmission de IIH "normaux" (avec les bits RR, RA, et SA à zéro) va commencer.

 	3.3.3.	Niveaux multiples
Un routeur qui fonctionne aux deux niveaux 1 et 2 sur une interface particulière DOIT effectuer les opérations ci-dessus pour chaque niveau.

Sur une interface de LAN, il DOIT envoyer et recevoir des IIH de niveau 1 et 2 et effectuer les synchronisations de CSNP indépendamment pour chaque niveau.

Sur une interface point à point, un seul IIH (indiquant la prise en charge des deux niveaux) est exigé, mais il DOIT effectuer la synchronisation de CSNP indépendamment pour chaque niveau.

 	3.4	Synchronisation de base de données
Quand un routeur est démarré ou redémarré, il peut s'attendre à recevoir un ensemble complet de CSNP sur chaque interface. L'arrivée du ou des CSNP est maintenant garantie, car un IIH avec le bit RR établi va être retransmis jusqu'à ce que le ou les CSNP soient reçus correctement.

Les CSNP décrivent l'ensemble des LSP qui sont actuellement détenus par chaque voisin. La synchronisation va être complète quand tous ces LSP auront été reçus.

Quand il (re)démarre, un routeur lance une instance de temporisateur T2 pour chaque LSPDB comme décrit dans les paragraphes 3.3.1 ou 3.3.2. En plus du traitement normal des CSNP, l'ensemble des LSPID contenus dans le premier ensemble complet de CSNP reçus sur chaque interface est enregistré, avec leur durée de vie restante. Dans le cas d'une interface de LAN, un ensemble complet de CSNP DOIT consister en les CSNP reçus des voisins qui ne sont pas en redémarrage. Si il y a plusieurs interfaces sur le routeur qui (re)démarre, l'ensemble enregistré de LSPID est l'union de ceux reçus sur chaque interface. Les LSP avec une durée de vie restante de zéro NE sont PAS enregistrés.

Lorsque les LSP sont reçus (par le fonctionnement normal du processus de mise à jour) sur toute interface, l'entrée correspondante de LSPID est supprimée (elle est aussi supprimée si un LSP arrive avant le CSNP contenant la référence). Quand un LSPID a été détenu dans la liste pour sa durée de vie restante indiquée, il est retiré de la liste. Quand la liste de LSPID est vide et que le temporisateur T1 a été annulé pour toutes les interfaces qui ont une adjacence à ce niveau, le temporisateur T2 est annulé.

À ce point, il est garanti que la base de données locale contient tous les LSP (soit avec le même numéro de séquence, soit avec un numéro de séquence plus récent) qui étaient présents dans les bases de données des voisins au moment du (re)démarrage. Les LSP qui sont arrivés dans la base de données d'un voisin après le moment du (re)démarrage peuvent ou non être présents, mais le fonctionnement normal du processus de mise à jour va garantir qu'il vont finalement être reçus. À ce point, la base de données locale est réputée être "synchronisée".

Comme les LSP mentionnés dans le ou les CSNP avec une durée de vie restante de zéro ne sont pas enregistrés, et que ceux qui ont une courte durée de vie restante sont supprimés de la liste quand la durée de vie arrive à expiration, l'annulation du temporisateur T2 ne va pas être empêchée par l'attente d'un LSP qui ne va jamais arriver.

 	3.4.1	Génération et arrosage de LSP et calcul de SPF
Le fonctionnement d'un routeur qui démarre, par rapport à celui qui redémarre, est assez différent. Ces deux cas sont traités séparément.

 	3.4.1.1	Redémarrage
Afin d'éviter de causer un remuement inutile de l'acheminement dans les autres routeurs, il est très souhaitable que les propres LSP du routeur générés par le système qui redémarre soient les mêmes que ceux précédemment présents dans le réseau (en supposant qu'aucun autre changement n'a eu lieu). Il est donc important de ne pas régénérer et arroser les LSP jusqu'à ce que toutes les adjacences aient été rétablies et que toutes les informations requises pour la propagation dans les LSP locaux soient pleinement disponibles. Idéalement, les informations sont chargées dans les LSP d'une façon déterministe, afin que les mêmes informations interviennent à la même place dans le même LSP (et donc les LSP sont identiques à leurs précédentes versions). Si cela peut être réalisé, les nouvelles versions peuvent même ne pas causer de calcul de SPF dans les autres systèmes. Cependant, pourvu que les mêmes informations soient incluse dans l'ensemble de LSP (quoique dans un ordre différent, et éventuellement des LSP différents) le résultat du calcul de SPF va être le même et ne va pas causer de remuement des tableaux de transmission.

Dans le cas d'un routeur qui redémarre, aucun des propres LSP du routeur n'est transmis, pas plus que ne le sont les tableaux de transmission mis à jour du routeur pendant que le temporisateur T3 fonctionne.

La redistribution des informations inter niveaux DOIT être régénérée avant que le LSP de ce routeur soit arrosé aux autres nœuds. Donc, le ou les LSP de niveau n non pseudo nœuds NE DOIVENT PAS être arrosés tant que le temporisateur T2 de l'autre niveau n'a pas expiré et que son SPF n'a pas été fait. Cela assure que toutes les informations inter niveaux qui sont à propager peuvent être incluses dans le ou les LSP de niveau n.

Durant cette période, si un des propres LSP du routeur (incluant les pseudo nœuds) est reçu, et que le routeur local ne l'a pas actuellement dans sa base de données, il N'est PAS purgé. En fonctionnement normal, un tel LSP serait purgé, car le LSP ne devrait clairement pas être présent dans la base de données globale de LSP. Cependant, dans les circonstances présentes, cela serait très indésirable, parce que cela pourrait causer une suppression prématurée du propre LSP d'un routeur -- et donc du remuement dans les routeurs distants. Même si le système local a un ou plusieurs des propres LSP du routeur (qu'il a générés, mais pas encore transmis) il n'est toujours pas valide de comparer le LSP reçu à cet ensemble, car il se peut que par suite de la propagation entre niveau 1 et niveau 2 (ou vice versa) le propre LSP d'un autre routeur ait besoin d'être généré quand les bases de données de LSP se sont synchronisées.

Durant cette période, un routeur qui redémarre DEVRAIT envoyer des CSNP comme il le ferait normalement. Les informations sur les propres LSP du routeur PEUVENT être incluses, mais si elles sont incluses, elles DOIVENT se fonder sur les LSP qui ont été reçus, non sur des versions qui ont été générées (mais pas encore transmises). Cette restriction est nécessaire pour empêcher une suppression prématurée d'un LSP de la base de données globale de LSP.

Quand le temporisateur T2 expire ou est annulé, indiquant que la synchronisation pour ce niveau est achevée, le SPF pour ce niveau est lancé afin de de déduire toutes les informations requises pour être propagées à un autre niveau, mais que les tableaux de transmission ne sont pas encore mis à jour.

Une fois que le SPF de l'autre niveau a été fait et que toute propagation inter niveaux a été résolue, les propres LSP du routeur peuvent être générés et arrosés. Tout LSP propre qui a été précédemment ignoré, mais qui ne fait pas partie de l'ensemble actuel des LSP propres (incluant des pseudo nœuds) DOIT alors être purgé. Noter qu'il est possible qu'un changement de routeur désigné ait eu lieu, et par conséquent, le routeur DEVRAIT purger ces LSP de pseudo nœud qu'il possédait précédemment, mais qui ne font plus partie de son ensemble de LSP de pseudo nœuds.

Quand tous les temporisateurs T2 ont expirés ou ont été annulés, le temporisateur T3 est annulé et les tableaux locaux de transmission sont mis à jour.

Si le temporisateur T3 expire avant que tous les temporisateurs T2 aient expiré ou aient été annulés, cela indique que le processus de synchronisation prend plus longtemps que le temps de garde minimum des voisins. Les propres LSP du routeur pour les niveaux qui n'ont pas encore achevé leur premier calcul de SPF sont alors arrosés avec le bit de surcharge établi pour indiquer que le LSPDB du routeur n'est pas encore synchronisé (et donc que les autres routeurs NE DOIVENT PAS calculer les chemins à travers ce routeur). Le fonctionnement normal du processus de mise à jour reprend, et les tableaux locaux de transmission sont mis à jour. Afin d'empêcher l'expiration des adjacences de voisin, les IIH avec la valeur normale d'interface pour le temps de garde sont transmis sur toutes les interfaces avec ni le bit RR ni le bit RA établis dans le TLV Redémarrage. Cela va causer le rafraîchissement par les voisins de leurs adjacences. Les propres LSP du routeur vont continuer d'avoir le bit de surcharge établi jusqu'à ce que le temporisateur T2 expire ou soit annulé.

 	3.4.1.2	Démarrage
Dans le cas d'un routeur qui démarre, aussitôt que chaque adjacence est établie, et avant tout échange de CSNP, le propre LSP zéro du routeur est transmis avec le bit de surcharge établi. Cela empêche d'autres routeurs de calculer des chemins à travers le routeur jusqu'à ce qu'il ait acquis de façon fiable l'ensemble complet de LSP. Le bit de surcharge reste établi dans les transmissions suivantes du LSP à zéro (comme cela va se produire si une précédente copie du propre LSP à zéro du routeur est encore présente dans le réseau) tandis que tous les temporisateurs T2 fonctionnent.

Quand tous les temporisateurs T2 ont été annulés, le ou les propres LSP à zéro du routeur PEUVENT être régénérés avec le bit de surcharge à zéro (en supposant que le routeur n'est pas en fait surchargé, et qu'il n'y a pas d'autre raison, comme une convergence BGP incomplète, de garder le bit de surcharge établi) et arrosés comme normalement.

Les autres LSP possédés par ce routeur (y compris les pseudo nœuds) sont générés et arrosés comme normalement, sans considération du temporisateur T2. Le SPF est aussi calculé normalement et la base de données d'informations d'acheminement (RIB, Routing Information Base) et la base de données d'informations de transmission (FIB, Forwarding Information Base) sont mises à jour lorsque les chemins deviennent disponibles.

Pour éviter la possible formation de trous noirs temporaires, le routeur qui démarre établit le bit SA dans le TLV Redémarrage (comme décrit au paragraphe 3.3.2) dans tous les IIH qu'il envoie.

Quand tous les temporisateurs T2 ont été annulés, le routeur qui démarre DOIT transmettre les IIH avec le bit SA à zéro.

 	4.	Tableaux d'état

Cette section présente les tableaux d'états qui résument les comportements décrits dans le présent document. D'autres comportements, en particulier les transitions d'état d'adjacence et le fonctionnement de la mise à jour des bases de données de LSP, NE sont PAS inclus dans les tableaux d'états excepté lorsque le présent document modifie les comportements décrits dans [ISO10589] et dans la [RFC5303].

Les état désignés dans les colonnes des tableaux ci-dessous sont un mélange des états qui sont spécifiques d'une seule adjacence (ADJ supprimée, ADJ vue RA, ADJ vue CSNP) et d'états qui sont indicatifs de l'état de l'instance de protocole (Courant, Redémarrage, Démarrage, SPF en attente).

Trois tableaux d'états sont présentés du point de vue d'un routeur en fonctionnement, d'un routeur qui redémarre, et d'un routeur qui démarre.

 	4.1	Routeur en fonctionnement
Événement	En fonctionnement	Adjacence supprimée
RX RR	Maintient l'état d'adjacence	
	Envoie RA	
	Établit SRM, envoie CSNP (Note 1)	
	Met à jour temps de garde, établit mode redémarrage (Note 2)	
RX RR clr	Supprime mode redémarrage	
RX SA	Supprime TLV IS de voisin dans les LSP	
	Passe à Adjacence supprimée	
RX SA clr		Rétablit TLV IS de voisin dans les LSP
		Passe à En fonctionnement

Note 1 : les CSNP sont envoyés par les routeurs selon le paragraphe 3.2.1c
Note 2 : Si le mode redémarrage est à zéro.
(RX pour réception ; clr pour mis à zéro)
 	4.2	Redémarrage de routeur
Événement	Redémarrage	ADJ vue RA	ADJ vue CSNP	SPF en attente
Routeur redémarre	Envoie IIH/RR			
	ADJ Init			
	Lance T1,T2,T3			
RX RR	Envoie RA			
RX RA	Ajuste T3		Annule T1	
	Passe à ADJ vue RA	Ajuste T3	
RX CSNP établi	Passe à ADJ vue CSNP	Annule T1	
RX IIH w/o TLV Red.	Annule T1 (point à point seul)		
T1 expires	Envoie IIH/RR	Envoie IIH/RR	Envoie IIH/RR	
	Relance T1	Relance T1	Relance T1	
T1 expire nième fois	Envoie IIH/ normal	Envoie IIH/normal	Envoie IIH/normal
T2 expire	Déclenche SPF			
	Passe à SPF en attente			
T3 expire	Établit bit de surcharge		
	Arrose LSP locaux			
	Met à jour plan de trans		
LSP DB Sync	Annule T2, et T3			
	Déclenche SPF			
	Passe à SPF en attente			
Tous SPF faits				Bit de surcharge à zéro
				Met à jour plan de transm.
				Arrose LSP locaux
				Passe En fonctionnement
(w/o pour avec ou sans ; Red pour Redémarre)
 	4.3	Démarrage de routeur
Événement	Démarrage	ADJ vue RA	ADJ vue CSNP
Routeur démarre	Envoie IIH/SA		
	Lance T1,T2		
RX RR	Envoie RA		
RX RA	Passe à ADJ vue RA		Annule T1
RX CSNP établi	Passe à ADJ vue CSNP	Annule T1	
RX IIH sans TLV redémar.	Annule T1		
	(point à point seulement)	
ADJ Activée	Lance T1		
	Envoie local LSP avec bit de surcharge établi	
T1 expire	Envoie IIH/RR et SA	Envoie IIH/RR et SA	Envoie IIH/RR et SA
	Relance T1	Relance T1	Relance T1
T1 expire nième fois	Envoie IIH/SA	Envoie IIH/SA	Envoie IIH/SA
T2 expire	Bit de surcharge à zéro		
	Envoie IIH normal		
	Passe à En fonctionnement
DB LSP synchronisée	Annule T2		
	Bit de surcharge à zéro		
	Envoie IIH normal		

 	5.	Considérations sur la sécurité

Toutes les nouvelles questions de sécurité soulevées par les procédures du présent document dépendent de la capacité d'un attaquant d'injecter un IIH faux mais apparemment valide, dont la facilité/difficulté n'a pas été altérée.

Si le bit RR est établi dans un faux IIH, les voisins qui reçoivent cet IIH vont continuer de maintenir une adjacence existante dans l'état "Activé" et peuvent (re)envoyer un ensemble complet de CSNP. Bien que la première action soit une perte de temps, aucune de ces actions ne cause d'interruption du fonctionnement correct du protocole.

Si le bit RA est établi dans un faux IIH, un routeur qui (re)démarre et reçoit un tel IIH peut croire à tort qu'il y a un voisin sur l'interface correspondante qui prend en charge les procédures décrites dans le présent document. En l'absence de réception d'un ensemble complet de CSNP sur cette interface, cela pourrait retarder l'achèvement des procédures de (re)démarrage en exigeant du temporisateur T1 qu'il périme le nombre maximum d'essais défini en local. Ce  comportement est le même que celui qui se produirait sur un LAN où aucun voisin du routeur qui (re)démarre ne prend en charge les procédures du présent document et est couvert aux paragraphes 3.3.1 et 3.3.2.

Si un bit SA est établi dans un faux IIH, cela pourrait causer la suppression de l'annonce d'un IS voisin, qui pourrait soit continuer pendant une période indéfinie, soit se produire de façon intermittente avec pour résultat une possible perte d'accessibilité de certaines destinations dans le réseau et/ou une fréquence accrue d'arrosage de LSP et de calcul de SPF.

La possibilité d'usurpation de PDU IS-IS peut être réduite par l'utilisation de l'authentification comme décrit dans la [RFC1195] et dans [ISO10589], et en particulier l'utilisation de l'authentification cryptographique comme décrit dans la [RFC5304].

 	6.	Considérations relatives à l'IANA

Le présent document définit le TLV IS-IS suivant qui est inscrit dans le registre des codets de TLV IS-IS :

Type	Description	IIH	LSP	SNP
211	TLV Redémarrage	oui	non	non

 	7.	Considérations de gestion

Ces extensions ont été conçues, développées, et déployées depuis de nombreuses années et n'ont aucun impact sur la gestion et le fonctionnement du protocole IS-IS via ce processus de normalisation.

 	8.	Remerciements

Les auteurs tiennent à remercier de leurs contributions Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, et Rena Yang.

 	9.	Références normatives

[ISO10589]	Norme internationale ISO 10589, "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes - Protocole d'échange d'informations d'acheminement intra domaine de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole de fourniture du service réseau en mode sans connexion(ISO8473)", seconde édition, 2002.

[RFC1195]	R. Callon, "Utilisation de l'IS-IS OSI pour l'acheminement dans les environnements TCP/IP et duels", décembre 1990. (Mise à jour par les RFC 1349, 5302, 5304)

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

[RFC5303]	D. Katz et autres, "Prise de contact à trois étapes pour adjacences IS-IS point à point", octobre 2008. (Remplace RFC3373) (P.S.)

[RFC5304]	T. Li et R. Atkinson, "Authentification cryptographique IS-IS", octobre 2008. (Remplace RFC3567, MàJ RFC1195) (PS, MàJ par RFC6233, RFC6232)

 	Adresse des auteurs

Mike Shand	Les Ginsberg	
Cisco Systems	Cisco Systems	
250, Longwater Avenue.	510 McCarthy Blvd	
Reading, Berks  RG2 6GB	Milpitas, CA  95035	
UK	USA	
téléphone : +44 208 824 8690	mél : ginsberg@cisco.com	
mél : mshand@cisco.com 		

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2008).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

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

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .
L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

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