Redémarrage OSPF en mode dégradé

Statut de ce mémoire

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

Notice de copyright

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

Résumé

Le présent mémoire expose une amélioration du protocole d’acheminement OSPF, par lequel un routeur OSPF peut rester sur le chemin d’émission même si le logiciel OSPF est redémarré. Ceci est appelé "redémarrage en mode dégradé" ou "émission sans interruption". Un routeur qui redémarre peut n’être pas capable d’ajuster son émission à temps lorsque la topologie du réseau change. Afin d’éviter les boucles d’acheminement éventuelles, la procédure du présent mémoire revient automatiquement au redémarrage OSPF normal lorsqu’un tel changement de topologie est détecté, ou quand un ou plusieurs des voisins du routeur qui redémarre n’accepte pas les améliorations du présent mémoire. Un fonctionnement approprié du réseau durant un redémarrage en mode dégradé fait des hypothèses sur l’environnement de redémarrage du routeur ; ces hypothèses sont également exposées.

Table des matières

Redémarrage OSPF en mode dégradé

1.   Généralités

2.   Fonctionnement d’un routeur qui redémarre

2.1   Entrée dans le redémarrage dégradé

2.2   Quand sortir du redémarrage dégradé

2.3   Actions en sortie de redémarrage dégradé

3.   Fonctionnement du voisin assistant

3.1   Entrée dans le mode d'assistance

3.2   Sortie du mode d'assistance

4.   Rétrocompatibilité

5.   Coupures imprévues

6.   Interaction avec l'ingénierie du trafic

7.   Possible future évolution

8.   Notice sur les droits de propriété intellectuelle

9.   Références

9.1   Références normatives

9.2   Références informatives

Annexe A.   Format de grace-LSA

Annexe B.   Paramètres configurables

B.1   Paramètres globaux (sous-ensemble minimum)

B.2   Paramètres globaux (facultatifs)

Considérations pour la sécurité

Remerciements

1.   Généralités

De nombreux routeurs Internet mettent aujourd’hui en œuvre une séparation des fonctions de contrôle et de transmission. Certains processeurs sont dédiés aux tâches de contrôle et de gestion telles que l’acheminement OSPF, alors que d’autres processeurs effectuent les tâches de transmission des données. Cette séparation crée la possibilité de maintenir les capacités de transmission de données d’un routeur alors que le logiciel de contrôle du routeur est redémarré ou rechargé. On appelle une telle possibilité "redémarrage en mode dégradé" ou "émission sans interruption".

Le protocole OSPF présente un problème de redémarrage en mode dégradé selon lequel, en fonctionnement normal, OSPF achemine intentionnellement sur un routeur de redémarrage pendant qu’il reconstruit sa base de données d’état de liaisons. OSPF évite le routeur en cours de redémarrage dans l’éventualité de boucles d’acheminement et/ou de trous noirs causés par l’absence de synchronisation des bases de données. L’évitement est accompli en ayant une nouvelle annonce des LSA des voisins du routeur, en omettant les liens avec le routeur qui redémarre.

Cependant, si, (a) la topologie du réseau reste stable et, (b) si le routeur qui redémarre est capable de garder son ou ses tableaux de transmission à travers le redémarrage, il serait sûr de garder le routeur qui redémarre sur le chemin de transmission. Le présent mémoire expose une amélioration d’OSPF qui rend possible un tel redémarrage en mode dégradé, et revient automatiquement au redémarrage OSPF standard par sécurité lorsque des changements de la topologie du réseau sont détectés.

En résumé, les améliorations de OSPF pour un redémarrage en mode dégradé sont les suivantes :

-   Le routeur qui tente un redémarrage en mode dégradé génère des LSA opaques de liaison locale, appelés ici Grace-LSA, qui annoncent son intention d’effectuer un redémarrage en mode dégradé dans un délai spécifié ou "délai de grâce".

-   Durant le délai de grâce, ses voisins continuent d’annoncer le routeur qui redémarre dans leurs LSA comme si il était pleinement adjacent (c’est-à-dire Plein état de voisin OSPF), mais seulement si la topologie du réseau reste statique (c’est-à-dire que le contenu des LSA qui dans la base de données des états de liaisons ont leur types LS 1 - 5, 7 inchangés et que des rafraîchissements périodiques sont permis).

Deux rôles sont joués par les routeurs OSPF durant un redémarrage en mode dégradé. Il y a d’abord celui du routeur qui est redémarré. Le fonctionnement de ce routeur durant un redémarrage en mode dégradé, y compris comment le routeur entre et sort du redémarrage en mode dégradé est le sujet de la Section 2. Puis il y a celui des voisins du routeur, qui doivent coopérer afin que le redémarrage se fasse en mode dégradé. Durant un redémarrage en mode dégradé, on dit que les voisins fonctionnent en "mode d’assistance". La Section 3 couvre les responsabilités d’un routeur qui fonctionne en mode d’assistance, y compris l’entrée et la sortie du mode d’assistance.

2.   Fonctionnement d’un routeur qui redémarre

Après le redémarrage/rechargement du routeur, il doit changer quelque peu son traitement OSPF jusqu’à ce qu’il rétablisse de pleines adjacences avec tous ses anciens voisins pleinement adjacents. Cette période, entre le redémarrage/rechargement et le rétablissement des adjacences, est appelé "redémarrage dégradé". Durant le redémarrage dégradé :

1)   Le routeur qui redémarre ne génère pas de LSA des types LS 1 - 5, 7. Au lieu de cela, le routeur qui redémarre veut que les autres routeurs dans le domaine OSPF calculent les chemins en utilisant les LSA qu’il a généré avant son redémarrage. Durant ce temps, le routeur qui redémarre ne modifie pas ni ne purge les LSA auto générés reçus, (voir au paragraphe 13.4 de [1]). Ils sont au contraire acceptés comme valides. En particulier, les grace-LSA que le routeur qui redémarre avait générés avant le redémarrage sont laissés en place. Les LSA auto générés reçus seront traités lorsque le routeur sortira du redémarrage dégradé (voir le paragraphe 2.3).

2)   Le routeur qui redémarre fait ses calculs d’acheminement OSPF, comme spécifié à la Section 16 de [1]. Cela est nécessaire pour ramener toutes les liaisons virtuelles OSPF en activité. Cependant, le routeur qui redémarre n’installe pas les chemins OSPF dans le ou les tableaux de transmission du système et s’appuie sur les entrées de transmission qu’il avait installées avant le redémarrage.

3)   Si le routeur qui redémarre détermine qu’il était le routeur désigné sur un segment donné avant le redémarrage, il se choisit à nouveau lui-même comme routeur désigné. Le routeur qui redémarre sait qu’il était le routeur désigné si, alors que l’interface associée est dans l’état Attente, un paquet Hello est reçu d’un voisin qui désigne le routeur comme le routeur désigné.

Autrement, le routeur qui redémarre fonctionne de la même façon que tout autre routeur OSPF. Il découvre les voisins en utilisant le protocole Hello d’OSPF, choisit le routeur désigné et le routeur désigné de secours, effectue la procédure d’échange de base de données pour synchroniser initialement les bases de données d’état de liaison avec ses voisins, et entretient cette synchronisation à travers l’arrosage.

Le processus d’entrée dans le redémarrage dégradé, et de sortie du redémarrage dégradé (avec ou sans succès) est traité dans les sections suivantes.

2.1   Entrée dans le redémarrage dégradé

Le routeur (appelons le Routeur X) est informé du désir de son redémarrage dégradé lorsque une commande appropriée est produite par l’opérateur du réseau. L’opérateur du réseau peut aussi spécifier la longueur de la période de grâce, ou la période de grâce nécessaire peut être calculée par le logiciel OSPF du routeur. Afin d’éviter que les LSA du routeur qui redémarre ne se périment, la période de grâce ne devrait pas excéder LSRefreshTime (1800 secondes) [1].

En préparation du redémarrage dégradé, le Routeur X doit effectuer les actions suivantes avant que son logiciel ne soit redémarré/rechargé :

(Noter que les procédures courantes de clôture OSPF ne sont pas effectuées, car on veut que les autres routeurs OSPF agissent comme si le Routeur X restait en service. Par exemple, le Routeur X ne purge pas ses LSA générés en local, car on veut qu’ils restent dans les bases de données d’état de liaison des autres routeurs tout au long de la période de redémarrage.)

1)   Le Routeur X doit s’assurer que son ou ses tableaux de transmission sont à jour et vont rester en place à travers le redémarrage.

2)   Le routeur peut avoir besoin de préserver les numéros de séquence cryptographique utilisés sur chaque interface dans des mémoires non volatiles. Une solution de remplacement est d’utiliser l’horloge du routeur pour la génération de numéros de séquence cryptographique et s’assurer que l'horloge est préservée à travers les redémarrages (sur le même processeur d’acheminement ou sur des processeurs redondants). Si rien de cela ne peut être garanti, il peut prendre au routeur jusqu’à RouterDeadInterval secondes après le redémarrage avant que les adjacences puissent être rétablies et cela forcerait un grave rallongement de la période de grâce.

Le Routeur X génère alors les grace-LSA. Ce sont des LSA opaques de liaison locale (voir l’Appendice A). Leur champ âge LS est réglé à 0, et la période de grâce demandée (en secondes) est insérée dans le corps du grace-LSA. Le contenu précis du grace-LSA est décrit dans l’Appendice A.

Un grace-LSA est généré pour chaque interface OSPF du routeur.

Si le Routeur X veut s’assurer que ses voisins reçoivent les grace-LSA, il devrait retransmettre les grace-LSA jusqu’à ce qu’il en soit accusé réception (c’est-à-dire, effectuer l’arrosage fiable OSPF standard des grace-LSA). Si un ou plusieurs voisins pleinement adjacents ne reçoivent pas les grace-LSA, il vont plus que probablement causer la fin prématurée de la procédure de redémarrage dégradé (voir la Section 4).

Après l’envoi des grace-LSA, le routeur devrait mémoriser le fait qu’il est en train d’effectuer un redémarrage dégradé ainsi que la longueur de la période de grâce demandée dans une mémoire non volatile. (Note pour les développeurs : Il peut être plus facile de simplement mémoriser le temps absolu de la fin de la période de grâce). Le logiciel OSPF devrait alors être rechargé. Lorsque le logiciel rechargé commence à exécuter le redémarrage dégradé, les modifications de protocole de la Section 2 sont suivies. (Noter qu’avant le redémarrage, le routeur ne sait pas si les voisins vont coopérer comme "assistants" ; la simple réception des grace-LSA n’implique pas l’acceptation des responsabilités d’assistant. Le présent mémoire suppose que le routeur voudra quand même redémarrer, même si le redémarrage ne va pas être dégradé).

2.2   Quand sortir du redémarrage dégradé

Un Routeur X sort du redémarrage dégradé quand survient un des événements suivants :

1)   Le Routeur X a rétabli toutes ses adjacences. Le Routeur X peut le déterminer en examinant les LSA de routeur qu’il a générés avant le redémarrage (appelés les "LSA de routeur pré-redémarrage") et, sur les segments où le routeur est le routeur désigné, les LSA de réseau de pré-redémarrage. Ces LSA auront été reçus des voisins assistants, et n’ont pas besoin d’être conservés dans une mémoire non volatile pendant tout le redémarrage. Toutes les adjacences précédentes seront notées comme liaisons de type-1 et type-2 dans les LSA de routeur, et comme voisins dans le corps du LSA de réseau.

2)   Le Routeur X reçoit un LSA qui n’est pas cohérent avec son LSA de routeur pré-redémarrage. Par exemple, X reçoit un LSA de routeur généré par le routeur Y qui ne contient pas de liaison avec X, bien que le LSA de routeur pré-redémarrage de X ne contienne pas de liaison avec Y. Cela indique soit, a) que Y ne prend pas en charge le redémarrage dégradé, soit, b) que Y n’a jamais reçu le grace-LSA, soit, c) que Y a terminé son mode d’assistant pour une raison quelconque (paragraphe 3.2). Un cas particulier d’incohérence de LSA est celui où le Routeur X établit une adjacence avec le routeur Y et ne reçoit pas une instance de son propre LSA de routeur de pré-redémarrage.

3)   La période de grâce est arrivée à expiration.

2.3   Actions en sortie de redémarrage dégradé

À la sortie du "redémarrage dégradé", le routeur qui redémarre revient au fonctionnement OSPF complètement normal, régénérant les LSA sur la base de l'état en cours du routeur et mettant à jour son ou ses tableaux de transmission sur la base des contenus actuels de la base de données des états de liaisons. En particulier, les actions suivantes devraient être effectuées lors de la sortie, réussie ou non, du redémarrage dégradé :

1)   Le routeur devrait régénérer ses LSA de routeur pour toutes les zones rattachées afin de s'assurer qu'elles ont les contenus corrects.

2)   Le routeur devrait régénérer les LSA de réseau sur tous les segments sur lesquels il est le routeur désigné.

3)   Le routeur recommence ses calculs d'acheminement OSPF (Section 16 de [1]), installant cette fois les résultats dans le tableau de transmission du système, et générant des LSA résumés, des LSA de type 7 et des LSA externes à l'AS, en tant que de besoin.

4)   Toutes les entrées restantes dans le tableau de transmission du système qui ont été installées avant le redémarrage, mais ne sont plus valides, devraient être retirées.

5)   Tous les LSA reçus générés par lui-même qui ne sont plus valides devraient être purgés.

6)   Tous les grace-LSA que le routeur a généré devraient être purgés.

3.   Fonctionnement du voisin assistant

La relation d'assistance se fait par segment de réseau. Comme "voisin assistant" sur un segment S pour un routeur X qui redémarre, le routeur Y a plusieurs tâches. Il surveille les changements de la topologie du réseau, et tant qu'il n'y en a pas, il continue d'annoncer ses LSA comme si X était resté en fonctionnement OSPF continu. Cela signifie que les LSA de Y continuent de faire la liste des adjacences à X sur le segment de réseau S, sans considération de l'état de synchronisation actuelle de l'adjacence. Cette logique affecte le contenu aussi bien des LSA de routeur que des LSA de réseau, et dépend aussi du type de segment S de réseau (voir les paragraphes 12.4.1.1 à 12.4.1.5 et le paragraphe 12.4.2 de [1]). Lors d'une assistance sur une liaison virtuelle, l'assistant doit aussi continuer d'établir le bit V dans son LSA de routeur pour la zone de transit de la liaison virtuelle (paragraphe 12.4.1 de [1]).

De plus, si X était le routeur désigné sur le segment de réseau S lorsque a commencé la relation d'assistance, Y maintient X comme routeur désigné jusqu'à ce que la relation d'assistance se termine.

3.1   Entrée dans le mode d'assistance

Lorsque un routeur Y reçoit un grace-LSA du routeur X, il entre en mode d'assistance pour X sur le segment de réseau associé, tant que les vérifications suivantes sont satisfaites :

1)   Il y a actuellement une pleine adjacence avec X (état de voisin Plein) sur le segment de réseau associé. Sur les segments de diffusion, NBMA et de point à multipoint, la relation de voisinage avec X est identifiée par l'adresse IP d'interface dans le corps du grace-LSA (voir l'Appendice A). Sur tous les autres Types de segment, X est identifié par le champ Routeur d'annonce du grace-LSA.

2)   Il n'y a pas eu de changement du contenu de la base de données d'état des liaisons (types LS 1 - 5, 7) depuis le redémarrage du routeur X. Ceci est déterminé comme suit :

-   Le routeur Y examine la liste de retransmission d'état de liaison pour X sur le segment de réseau associé.

-   Si il y a un ou des LSA de type LS 1 - 5, 7 sur la liste, ils doivent alors tous être rafraîchis périodiquement.

-   Si il y a à la place des LSA sur la liste dont le contenu a changé (voir le paragraphe 3.3 de [7]), Y doit refuser d'entrer en mode d'assistance.

   Le routeur Y peut facultativement interdire le redémarrage dégradé avec le routeur X sur les autres segments de réseau. Il est possible de déterminer si des LSA modifiés ont été diffusés avec succès au routeur Y sur les autres segments de réseau, mais cela sort du domaine d'application du présent document.

3)   La période de grâce n'a pas encore expiré. Cela signifie que l'âge LS du grace-LSA est inférieur à la période de grâce spécifiée dans le corps du grace-LSA (Appendice A).

4)   La politique locale permet à Y d'agir comme assistant pour X. Des exemples de politiques configurées peuvent être : a) ne jamais agir comme assistant, b) ne jamais permettre que la période de grâce excède un temps T, c) n'assister que pour des rechargements/mises à jour de logiciel, ou d) ne jamais agir comme assistant pour des routeurs spécifiques (spécifiés par identifiant de routeur OSPF).

5)   Le routeur Y n'est pas dans le processus de redémarrage dégradé.

Il y a une exception aux exigences ci-dessus. Si Y assistait déjà X sur le segment de réseau associé, le nouveau grace-LSA devrait être accepté et la période de grâce devrait être mise à jour en conséquence.

Noter que le routeur Y peut assister X sur certains segments de réseau, et pas sur les autres. Cependant, cette circonstance va probablement conduire à une terminaison prématurée du redémarrage dégradé de X, car Y ne va pas continuer à annoncer des adjacences sur les segments sur lesquels il n'assiste pas (voir au paragraphe 2.2).

Autrement, le routeur Y peut choisir d'entrer en mode d'assistance lorsque un grace-LSA est reçu et que les vérifications ci-dessus sont satisfaites pour toutes les adjacences avec le routeur X. Cette autre mise en œuvre de l'agrégation des adjacences par rapport au mode d'assistance est compatible avec les mises en œuvre qui considèrent chaque adjacence séparément.

Il est permis à un seul routeur de servir simultanément d'assistant pour plusieurs voisins qui redémarrent.

3.2   Sortie du mode d'assistance

Le routeur Y cesse d'effectuer la fonction d'assistant pour son voisin le routeur X sur un segment donné lorsque survient un des événements suivants :

1)   Le grace-LSA généré par X sur le segment est purgé. Cela indique le succès de la fin du redémarrage dégradé.

2)   La période de grâce du grace-LSA arrive à expiration.

3)   Un changement du contenu de la base de données d'état de liaison indique un changement de la topologie du réseau, qui force la terminaison d'un redémarrage dégradé. Précisément, si le routeur Y installe un nouveau LSA dans sa base de données avec des types LS de 1 - 5, 7 et qui ont les deux propriétés suivantes, il devrait cesser d'assister X. Les deux propriétés de LSA sont :

a)   le contenu du LSA a changé ; cela inclut des LSA sans instance précédente de base de données d'état de liaison et la purge des LSA de la base de données, mais exclut les rafraîchissements périodiques de LSA (voir le paragraphe 3.3 de [7]), et

b)   le LSA aurait été diffusé à X, si Y et X avaient été pleinement adjacents. Comme exemple de la seconde propriété, si Y installe un LSA d'AS externe modifié, il ne devrait pas terminer une relation d'assistance avec un voisin appartenant à une zone d'extrémité, car de toutes façons ce voisin ne verra pas le LSA d'AS externe. Une mise en œuvre PEUT fournir une option de configuration pour empêcher les options de base de données d'état de liaison de terminer le redémarrage dégradé. Une telle option va cependant augmenter le risque de boucles d'acheminement transitoires et de trous noirs.

Lorsque le routeur Y sort du mode d'assistance pour X sur un segment de réseau donné, il régénère ses LSA sur la base de l'état en cours de son adjacence au routeur X sur le segment. En détails, Y entreprend les actions suivantes :

a)   Y recalcule le routeur désigné pour le segment,

b)   Y régénère son LSA de routeur pour la zone OSPF du segment,

c)   si Y est routeur désigné pour le segment, il régénère le LSA de réseau pour le segment et

d)   si le segment était une liaison virtuelle, Y régénère son LSA de routeur pour la zone de transit de la liaison virtuelle.

Si le routeur Y agrégeait des adjacences avec le routeur X lors de l'entrée dans le mode d'assistance (comme décrit au paragraphe 3.1) il doit aussi sortir du mode d'assistance pour toutes les adjacences avec le routeur X lorsque un quelconque des événements de sortie survient pour une adjacence avec le routeur X.

4.   Rétrocompatibilité

La rétrocompatibilité avec les routeurs OSPF non modifiés est une conséquence automatique de la fonctionnalité exposée ci-dessus. Si un ou plusieurs voisins d'un routeur qui demande le redémarrage dégradé sont non modifiés, ou si ils ne reçoivent pas le grace-LSA, le redémarrage dégradé revient au redémarrage OSPF normal.

Les routeurs non modifiés vont commencer l'acheminement autour du routeur redémarré X lorsqu'il effectue la synchronisation initiale de base de données en renvoyant leurs LSA avec les liaisons omises avec X. Ces LSA seront interprétés par les voisins assistants comme un changement de topologie, et par X comme une incohérence de LSA ; dans l'un et l'autre cas, il reviennent au fonctionnement normal OSPF.

5.   Coupures imprévues

Le mécanisme de redémarrage décrit dans le présent mémoire peut être utilisé pour des pannes imprévues. (Des exemples de pannes imprévues incluent la défaillance du logiciel de contrôle d'un routeur, un passage inattendu sur un processeur de contrôle redondant, etc.). Cependant, les développeurs et les opérateurs de réseaux devraient noter que tenter le redémarrage dégradé à partie d'une panne imprévue peut n'être pas une bonne idée, à cause de l'incapacité d'un routeur à se préparer correctement au redémarrage (voir au paragraphe 2.1). En particulier, il semble peu vraisemblable qu'un routeur puisse garantir la bonne santé de son ou ses tableaux de transmission lors d'un redémarrage imprévu. En tout état de cause, les développeurs qui fournissent l'option de récupération gracieuse des pannes imprévues doivent permettre à un opérateur de réseau de désactiver l'option.

À l'opposé de la procédure pour les redémarrages/rechargements planifiés qui ont été décrits au paragraphe 2.1, un routeur qui tente un redémarrage dégradé après une panne imprévue doit générer des grace-LSA *après* la reprise de fonctionnement de son logiciel de contrôle. Les points suivants doivent être respectés durant cette génération de grace-LSA.

o   Les grace-LSA doivent être générés et envoyés *avant* que le routeur redémarré n'envoie de paquets OSPF Hello. Sur les réseaux de diffusion, ce LSA doit être diffusé à l'adresse AllSPFRouters de diffusion groupée (224.0.0.5) car le routeur qui redémarre ne connaît pas son état DR précédent.

o   Les grace-LSA sont encapsulés dans les paquets de mise à jour d'état de liaison et envoyés à toutes les interfaces, même si le routeur redémarré n'a pas d'adjacences et pas de connaissance des adjacences précédentes.

o   Pour améliorer la probabilité que les grace-LSA soient livrés, une mise en œuvre peut les envoyer plusieurs fois (voir par exemple la variable de robustesse dans [8]).

o   La raison du redémarrage dans les grace-LSA doit être réglée à 0 (inconnu) ou 3 (passé à un processeur de contrôle redondant). Cela permet aux voisins de décider si ils veulent assister ce routeur à travers un redémarrage imprévu.

6.   Interaction avec l'ingénierie du trafic

Le fonctionnement des extensions d'ingénierie de trafic à OSPF [4] durant le redémarrage OSPF dégradé est spécifié dans [6].

7.   Possible future évolution

Imaginer un algorithme moins prudent pour la terminaison d'assistant au redémarrage dégradé qui fournisse un niveau comparable d'évitement de trous noirs et de boucles d'acheminement.

8.   Notice sur les droits de 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 pourraient ê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’IETF au sujet des droits dans les documents en cours de normalisation et se rapportant aux normes figurent dans le BCP 11.

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, brevet ou applications de brevets, ou autres droits de propriété qui pourraient recouvrir la technologie qui pourrait être nécessaire pour mettre en œuvre la présente norme. Prière d’adresser les informations au directeur exécutif de l’IETF.

9.   Références

9.1   Références normatives

[2]   R. Coltun, "Option OSPF LSA opaque", RFC2370, juillet 1998. (Obsolète, voirRFC5250) (P.S.)

9.2   Références informatives

[3]   T. Howes, "Représentation comme chaîne des filtres de recherche LDAP", RFC2254, décembre 1997. (Obsolète, voirRFC4510, RFC4515) (P.S.)

[4]   D. Katz, K. Kompella et D. Yeung, "Extensions d'ingénierie de trafic à OSPF version 2", RFC3630, septembre 2003.

[5]   P. Murphy, "Option OSPF zone pas tout à fait de bout (NSSA)", RFC3101, janvier 2003. (P.S.)

[6]   K. Kompella et autres, "Extensions d'acheminement pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", RFC4202, octobre 2005. (P.S.)

[7]   J. Moy, "Extension d'OSPF pour la prise en charge de circuits à la demande", RFC1793, avril 1995. (MàJ parRFC3883) (P.S.)

[8]   B. Cain et autres, "Protocole Internet de gestion de groupe, IGMP version 3", RFC3376, octobre 2002.

Annexe A.   Format de grace-LSA

Le grace-LSA est un LSA opaque à portée de liaison locale [2], qui a un type Opaque de 3 et un ID Opaque égal à 0. Les grace-LSA sont générés par un routeur qui souhaite exécuter un redémarrage dégradé de son logiciel OSPF. Un grace-LSA demande que les voisins du routeur aident à son redémarrage dégradé en continuant d'avertir le routeur comme si il était pleinement adjacent durant une période de grâce spécifiée.

Chaque grace-LSA a un champ d'âge LS réglé à 0 lorsque le LSA est généré ; la valeur actuelle de l'âge LS indique ensuit depuis combien de temps le routeur qui redémarre a fait sa demande. Le corps du LSA est codé en TLV. Les informations codées en TLV incluent la longueur de la période de grâce, la raison du redémarrage dégradé et, lorsque le grace-LSA est associé à un segment de réseau de diffusion, de NBMA ou de point à multipoint, l'adresse IP de l'interface du routeur qui redémarre.

 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

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

|                âge LS         |     Options   |       9       |

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

|       3       |                  0                            |

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

|                       Routeur annonceur                       |

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

|                     Numéro de séquence LS                     |

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

|       Somme de contrôle LS    |           longueur            |

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

|                                                               |

+-                              TLV                            -+

|                               ...                             |

Le format des TLV au sein du corps d'un grace-LSA est le même que le format utilisé par les extensions d'ingénierie du trafic à OSPF [4]. La charge utile de LSA comporte un ou plusieurs triplets Type/Longueur/Valeur (TLV) incorporés. Le format de chaque TLV est :

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

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

Le champ Longueur définit la longueur de la portion Valeur en octets (donc un TLV sans portion Valeur aurait une longueur de zéro). Le TLV est bourré pour un alignement sur quatre octets ; le bourrage n'est pas inclus dans le champ de longueur (de sorte qu'une valeur de trois octets aurait une longueur de trois, mais la taille totale du TLV serait de huit octets). Les TLV incorporés sont aussi alignés sur 32 bits. Par exemple, une valeur d'un octet aurait le champ de longueur réglé à 1, et trois octets de bourrage seraient ajoutés à la fin de la portion Valeur du TLV. Les types non reconnus sont ignorés.

Voici la liste des TLV qui peuvent apparaître dans le corps d'un grace-LSA :

o   Période de grâce (Type = 1, longueur = 4). Le nombre de secondes pendant lequel les voisins du routeur devraient continuer d'annoncer au routeur comme si il était pleinement adjacent, sans considération de l'état de la synchronisation de base de données entre le routeur et ses voisins. Comme cette durée commence quand l'âge LS du grace-LSA était égal à 0, la période de grâce se termine quand :

a)   l'âge LS du grace-LSA excède la valeur d'une période de grâce, ou

b)   le grace-LSA est purgé. Voie au paragraphe 3.2 les autres conditions qui terminent le redémarrage dégradé.

Ce TLV doit toujours apparaître dans un grace-LSA.

o   Raison du redémarrage dégradé (Type = 2, longueur = 1). Code la raison du redémarrage du routeur parmi les suivantes : 0 (inconnu), 1 (redémarrage du logiciel), 2 (rechargement/mise à niveau du logiciel) ou 3 (passe à un processeur de contrôle redondant). Ce TLV doit toujours apparaître dans un grace-LSA.

o   Adresse IP d'interface (Type = 3, longueur = 4). C'est l'adresse IP de l'interface du routeur sur le sous-réseau associé au grace-LSA. Elle est exigée sur les segments de réseau en diffusion, en NBMA et en point à multipoint, où l'assistant utilise l'adresse IP de l'interface pour identifier le routeur qui redémarre (voir au paragraphe 3.1).

DoNotAge n'est jamais établi dans un grace-LSA, même si le grace-LSA est diffusé sur un circuit de demande[7]. Cela parce que le champ âge LS du grace-LSA est utilisé pour calculer la durée de la période de grâce.

Les grace-LSA ont une portée de liaison locale parce qu'il est seulement nécessaire qu'ils soient vus par les voisins directs du routeur.

Les TLV supplémentaires de grace-LSA doivent être décrits dans un projet Internet et seront soumis à révision d'expert du groupe de travail OSPF.

Annexe B.   Paramètres configurables

Les paramètres OSPF de redémarrage dégradé sont suggérés ci-dessous. Le paragraphe B.1 contient un sous ensemble minimum de paramètres qui devraient être pris en charge. B.2 comporte des paramètres de configuration supplémentaires qu'une mise en œuvre peut choisir de prendre en charge.

B.1   Paramètres globaux (sous-ensemble minimum)

RestartSupport

C'est le niveau de prise en charge du routeur pour le redémarrage dégradé OSPF. Les valeurs admissibles sont aucune, redémarrage planifié seulement, et planifié/non planifié.

RestartInterval

C'est l'intervalle de redémarrage dégradé en secondes. La gamme est de 1 à 1800 secondes, avec une valeur par défaut suggérée de 120 secondes.

B.2   Paramètres globaux (facultatifs)

RestartHelperSupport

La prise en charge du routeur pour agir comme assistant au redémarrage OSPF. Les valeurs admissibles sont aucune, e, redémarrage planifié seulement, et planifié/non planifié.

RestartHelperStrictLSAChecking

Indique si un assistant de redémarrage OSPF devrait ou non terminer le redémarrage dégradé lorsque il y a un changement d'un LSA qui devrait être diffusé au routeur qui redémarre ou quand il y a un LSA changé sur la liste de retransmission du routeur qui redémarre lorsque le redémarrage dégradé est initié. La valeur par défaut suggérée est "activé".

Considérations pour la sécurité

Une des façons d’attaquer un protocole d’état de liaison tel que OSPF est d’injecter de faux LSA, ou de corrompre des LSA existants, dans la base de données d’état de liaison. L’injection d’un faux grace-LSA permettrait à un attaquant de mystifier un routeur qui, en réalité, a été retiré du service. La façon standard d’empêcher une telle corruption de la base de données d’état de liaison est de sécuriser les échanges de protocole OSPF en utilisant l’authentification cryptographique spécifiée dans [1]. Une façon encore plus forte de sécuriser le contenu de la base de données d’état de liaison a été proposée dans [3].

Lorsque l’authentification cryptographique de [1] est utilisée sur le routeur qui redémarre, la préservation des numéros de séquence reçus dans une mémoire non volatile n’est pas obligatoire. Il y a un risque qu’un paquet Hello répété puisse causer la création d’un état de voisin chez un voisin défunt. Cependant, le risque n’est pas plus grand qu’en fonctionnement normal.

Remerciements

Les auteurs tiennent à remercier John Drake, Vishwas Manral, Kent Wong, et Don Goodspeed pour leur précieux commentaires, ainsi que Alex Zinin et Bill Fenner pour leur révision minutieuse.

Adresse des auteurs

Déclaration complète de droits de reproduction

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

Le présent document et les informations qui y sont 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.

Remerciement

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