Détection de voisins inactifs sur les circuits OSPF à la demande (DC)

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 (2004).

Résumé

OSPF est un protocole d’acheminement intra-domaine à état de liaison utilisé dans les réseaux IP. Le comportement d’OSPF sur les circuits à la demande (DC, demand circuit) est optimisé dans la RFC1793 pour minimiser la quantité de trafic redondant. Une partie des extensions de circuit à la demande OSPF est le mécanisme de suppression de Hello. Cette technique permet à un circuit à la demande de se désactiver lorsque aucun trafic intéressant ne passe à travers la liaison. Cependant, cela introduit aussi un problème, lorsque il devient impossible de détecter un voisin OSPF inactif sur une telle liaison. Le présent mémoire introduit un nouveau mécanisme appelé "sondage de voisin" pour régler ce problème.

1. Motifs

Dans certaines situations, lors du fonctionnement sur des circuits à la demande, le voisin distant peut être dans l’incapacité de faire fonctionner OSPF [RFC2328], et il s’ensuit éventuellement qu’il est incapable d’acheminer le trafic d’application. Les scénarios possibles incluent que :

o le processus OSPF peut avoir disparu chez le voisin distant,

o le surabonnement (Section 7 de la [RFC1793]) peut causer un abandon continu de données d’application au niveau liaison.

Le problème ici est que le routeur local ne peut pas identifier des problèmes comme celui-là, car l’échange de Hello est supprimé sur les circuits à la demande. Si la topologie du réseau est telle que les autres routeurs ne peuvent pas communiquer leurs connaissances sur le voisin distant via l’arrosage, le routeur local et tous les routeurs derrière lui ne vont jamais connaître le problème, de sorte que le trafic d’application peut continuer d’être transmis au routeur incapable de traiter OSPF.

Le présent mémoire décrit un mécanisme de sondage de rétro compatibilité de voisin fondé sur les détails de la procédure d’arrosage standard suivie par les routeurs OSPF.

2. Solution proposée

La solution que propose le présent document utilise les paquets de mise à jour d’état de liaison pour détecter si le processus OSPF est opérationnel sur le voisin distant. On appelle ce processus le "sondage de voisin" (Neighbor probing). L’idée derrière cette technique est de permettre qu’un des deux voisins connectés sur un circuit à la demande vérifie à tout moment le voisin distant (voir le paragraphe 2.1).

Les routeurs sur le circuit à la demande peuvent être connectés par une liaison point à point, une liaison virtuelle, ou une interface de diffusion. Le cas de routeurs connectés par des réseaux de diffusion ou des liaisons multi accès sans diffusion (NBMA, Non-Broadcast Multi-Access) n’est pas pris en considération, car la suppression de Hello n’est pas utilisée dans ces cas (paragraphe 3.2 de la [RFC1793]).

Le mécanisme de sondage de voisin est utilisé comme suit. Après qu’un routeur a synchronisé la base de données d’état de liaison (LSDB, Link State Database) avec son voisin sur le circuit à la demande, le circuit à la demande peut être supprimé si il n’y a plus de trafic d’application. Lorsque le trafic d’application recommence à passer sur la liaison, celle-ci est réactivée. Si ospfIfDemandNbrProbe est activé, les routeurs DEVRAIENT se sonder les uns les autres. Lorsque la liaison est active, les routeurs peuvent aussi se sonder les uns les autres périodiquement tous les ospfIfDemandNbrProbeInterval. Le sondage de voisin ne devrait pas être considéré comme du trafic intéressant et ne devrait pas causer le maintien en activité du circuit à la demande (les détails pertinents de mise en œuvre sortent du domaine d’application du présent document).

Le cas où une ou plusieurs des liaisons du routeur sont surabonnées (voir la section 7 de la [RFC1793]) devrait être considéré par les mises en œuvre. Dans une telle situation, même si l’état de liaison est actif et si les données d’application sont envoyées sur la liaison, seul un nombre limité de voisins sont réellement joignables. Pour s’assurer que des voisins temporairement injoignables ne sont pas déclarés morts par erreur, le sondage de voisin devrait se restreindre à ceux des voisins qui sont réellement joignables (c’est-à-dire qu’il y a un circuit établi avec le voisin au moment où il y a besoin d’initier la procédure de sondage). Cette vérification elle-même est aussi considérée comme un détail de mise en œuvre.

2.1 Sondage du voisin

La méthode de sondage de voisin décrite dans ce paragraphe est complètement compatible avec les mises en œuvre standard d’OSPF, parce qu’elle se fonde sur le comportement standard qui doit être suivi par les mises en œuvre d’OSPF afin de conserver leurs LSDB synchronisées.

Lorsque un routeur a besoin de vérifier la capacité OSPF d’un voisin accessible à travers un circuit à la demande, il devrait arroser vers le voisin avec tout LSA de sa LSDB qui serait normalement envoyé au voisin durant le processus initial de synchronisation de LSDB (dans la plupart des cas, un tel LSA doit avoir déjà été arrosé vers le voisin au moment du début de la procédure de sondage). Par exemple, le routeur peut arroser son propre LSA de routeur (sans générer une nouvelle version) ou le propre LSA de routeur du voisin. Si le voisin est encore en vie et a la capacité OSPF, il réplique par un accusé de réception d’état de liaison ou une mise à jour d’état de liaison (un accusé de réception implicite) et le LSA est retiré de la liste de retransmission du voisin. Les mises en œuvre devraient limiter le nombre de fois qu’un LSA peut être retransmis à ospfIfDemandNbrProbeRetxLimit, lorsque utilisé pour le sondage de voisin. Si aucun accusé de réception (explicite ou implicite) n’est reçu pendant une durée prédéfinie, le routeur sondeur devrait traiter cela comme la preuve de l’inaccessibilité du voisin (en prouvant qu’est fausse l’hypothèse d’accessibilité utilisée dans la [RFC1793]) et devrait arrêter l’adjacence.

Noter que lorsque le voisin sondé reçoit un tel paquet de mise à jour d’état de liaison, le LSA reçu a le même contenu que le LSA dans la LSDB du voisin, et donc ne devrait normalement pas causer d’arrosage supplémentaire. Cependant, comme les rafraîchissements de LSA ne sont pas arrosés sur les circuits à la demande, le LSA reçu peut avoir un numéro de séquence supérieur. Il va en résulter que le premier LSA de sondage sera arrosé encore par le voisin. Noter que si la version actuelle du LSA de sondage a déjà été arrosée au voisin, elle ne sera pas propagée plus loin par le voisin. Noter aussi que dans tous les cas, les LSA de sondage suivants (qui ne sont pas le premier) ne vont pas causer d’autre arrosage tant que le numéro de séquence du LSA est incrémenté.

Les mises en œuvre devraient bien s’assurer (par des mécanismes internes) que les paquets de mise à jour d’état de liaison OSPF envoyés sur le circuit à la demande pour les besoins du sondage de voisin n’empêchent pas ce circuit d’être supprimé.

3. Prise en charge des interfaces de liaison virtuelle et de point à multipoint

Les liaisons virtuelles peuvent être traitées de façon analogue à celle des liaisons point à point, de sorte que les techniques décrites dans le présent mémoire sont applicables aussi aux liaisons virtuelles. Le cas de l’interface point à multipoint (diffusion) fonctionnant comme un circuit à la demande (paragraphe 3.5 de la [RFC1793]) peut être traité comme une liaison point à point individuelle, pour laquelle la solution a été décrite à la Section 2.

4. Questions de compatibilité

Tous les mécanismes décrits dans le présent document sont rétro compatibles avec les mises en œuvre OSPF standard.

5. Considérations de déploiement

En plus de la fonctionnalité perdue mentionnée à la Section 6 de la [RFC1793], il y a une redondance supplémentaire en termes de quantité de données (mises à jour d’état de liaison et accusés de réception) qui sont transmises du fait du sondage du voisin chaque fois que la liaison est activée, augmentant par là le coût global.

6. Remerciements

L’idée originale de limiter le nombre de retransmissions de LSA sur les circuits à la demande (utilisés au titre de la solution décrite dans la présent document) et sa mise en œuvre revient à Padma Pillay-Esnault et Derek Yeung.

Les auteurs tiennent à remercier John Moy, Vijayapal Reddy Patil, SVR Anand, et Peter Psenak de leurs commentaires sur ce travail.

Une portion significative du travail de Sira a été effectuée au titre du projet de recherche HFCL-IISc (HIRP), Bangalore, Inde. Il remercie l’équipe de ses discussions éclairantes.

7. Considérations pour la sécurité

Le mécanisme décrit dans le présent document ne modifie pas les aspects de sécurité du protocole d’acheminement OSPF.

8. Références normatives

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

[RFC2328] J. Moy, "OSPF version 2", STD 54, avril 1998. (MàJ par la RFC6549)

Appendice A Paramètres configurables

Le présent mémoire définit les paramètres de configuration supplémentaires suivants pour les interfaces OSPF.

ospfIfDemandNbrProbe

Indique si le sondage de voisin est ou non activé pour déterminer si le voisin est inactif. Le sondage de voisin est désactivé par défaut.

ospfIfDemandNbrProbeRetxLimit

Le nombre de retransmissions consécutives de LSA avant que le voisin soit réputé inactif et que l’adjacence de voisin soit supprimée. La valeur type est 10 retransmissions consécutives de LSA.

ospfIfDemandNbrProbeInterval

Définit la fréquence du sondage de voisin. La valeur type est 2 minutes.

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004). 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 qui y sont contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations 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 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’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 le 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 l’Internet Society.