Network Working Group J

Le présent document spécifie un protocole 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 l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Le présent mémoire définit les améliorations au protocole OSPF qui permettent un fonctionnement efficace sur les "circuits à la demande". Les circuits à la demande sont des segments de réseau dont les coûts varient avec l’usage ; les charges peuvent être fondées à la fois sur la durée de connexion et sur les octets/paquets transmis. Des exemples de circuits à la demande incluent les circuits RNIS, les SVC X.25, et les lignes téléphoniques. La nature périodique du trafic d’acheminement OSPF a jusqu’à présent exigé qu’une connexion de la liaison de données sous-jacente du circuit à la demande soit ouverte en continu, ce qui résulte en des charges d’usage indésirables. Avec les modifications décrites ici, les Hello OSPF et les rafraîchissements d’informations d’acheminement OSPF sont supprimés sur les circuits à la demande, permettant que les connexions de la liaison de données sous-jacente soient fermées lorsque elles ne portent pas de trafic d’application.

Les circuits à la demande et les segments de réseau réguliers (par exemple, les liaisons louées) peuvent être combinés de toutes les manières. En d’autres termes, il n’y a pas de restrictions topologiques sur la prise en charge de circuit à la demande. Cependant, bien que tout segment de réseau OSPF puisse être défini comme un circuit à la demande, seuls les réseaux en point à point en reçoivent tout le bénéfice. Lorsque des réseaux de diffusion et des réseaux multi accès sans diffusion (NBMA, non-broadcast multi-access) sont déclarés circuits à la demande, le trafic de mise à jour d’acheminement est réduit mais l’envoi périodique des Hello ne l’est pas, ce qui exige en fait que les connexions de liaisons de données restent constamment ouvertes.

Bien que principalement destinées à être utilisées avec des liaisons réseau conscientes des coûts telles que de RNIS, X.25 et de téléphone, les modifications du présent mémoire peuvent aussi se révéler utiles sur des liaisons réseau à bande passante limitée telles que des liaisons louées à basse vitesse et du paquet radio.

Les améliorations définies dans le présent mémoire sont rétro compatibles avec la spécification OSPF définie dans la [RFC1583], et avec les extensions OSPF définies dans la [RFC1587] (zones OSPF NSSA), la [RFC1584] (MOSPF) et [8] (Interface OSPF en point à multipoint).

Le présent mémoire fournit des fonctionnalités similaires à celles spécifiées pour RIP dans la [RFC1582], avec comme principale différence la façon dont les deux propositions traitent le surabonnement (voir les paragraphes 4.3 et la Section 7 ci-dessous). Cependant, comme OSPF emploie la technologie d’acheminement par état de liaison, par opposition à celle du vecteur de distance de RIP, les mécanismes utilisés pour réaliser la fonction de circuit à la demande sont assez différents.

Les auteurs tiennent à remercier de leurs commentaires utiles Fred Baker, Rob Coltun, Dawn Li, Gerry Meyer, Tom Pusateri et Zhaohui Zhang. Le présent mémoire a été produit par le groupe de travail OSPF.

Table des Matières

1. Modèle pour les circuits à la demande 2

2. Modifications pour tous les routeurs OSPF 3

2.1 Champ Options OSPF 3

2.2 Champ Age LS 3

2.3 Suppression des LSA DoNotAge périmés 4

2.4 Changement de l’algorithme d’arrosage 4

2.5 Interopérabilité avec les routeurs OSPF non modifiés 4

3. Modifications aux points d’extrémité de circuit à la demande 6

3.1 Modifications à l’automate à états d’interface 6

3.2 Envoi et réception des Hello OSPF 6

3.3 Arrosage sur les circuits à la demande 7

3.4 Prise en charge de liaison virtuelle 8

3.5 Prise en charge d’interface de point à multipoint 8

4. Exemples 8

4.1 Exemple 1 : Connexité unique à travers des circuits à la demande 9

4.2 Exemple 2 : Circuits à la demande et non à la demande en parallèle 10

4.3 Exemple 3 : Fonctionnement en surabonnement 12

5. Recommandations de topologie 13

6. Fonctionnalités perdues 13

7. Travaux futurs : surabonnement 14

8. Capacités non prises en charge 15

A. Format du champ Options OSPF 15

B. Paramètres configurables 16

C. Constantes architecturales 16

Références 16

Considérations pour la sécurité 17

Adresse de l’auteur 17

Dans le présent mémoire, les circuits à la demande se réfèrent aux segments de réseau dont le coût dépend du temps de connexion et/ou de l’usage (exprimé en termes d’octets ou de paquets). Les exemples incluent les circuits RNIS et les circuits virtuels commutés (SVC, Switched Virtual Circuit) X.25. Sur ces circuits, il est souhaitable pour un protocole d’acheminement d’envoyer aussi peu de trafic d’acheminement que possible. En fait, lorsque il n’y a pas de changement dans la topologie du réseau, il est souhaitable pour un protocole d’acheminement de ne pas envoyer du tout de trafic d’acheminement ; cela permet à la connexion de la liaison de données sous-jacente d’être close lorsque elle n’est plus nécessaire pour le trafic de données d’application.

Le modèle utilisé dans le présent mémoire pour la maintenance des circuits à la demande est le suivant. Si il n’y a pas de données à envoyer (trafic de protocole d’acheminement ou de données d’application) la connexion de liaison de données reste close. Sitôt qu’il y a des données à envoyer, une tentative d’ouverture de la connexion de liaison de données est faite (par exemple, un appel RNIS ou X.25 est lancé). Lorsque, ou si, la connexion de liaison de données est établie, les données sont envoyées, et la connexion reste ouverte jusqu’à ce qu’une certaine période de temps se soit écoulée sans autre envoi de données. À ce moment, la connexion de liaison de données est de nouveau close, afin de préserver les coûts et les ressources (voir la Section 1 de la [RFC1582]).

La "présomption d’accessibilité" décrite dans la [RFC1582] est aussi utilisée. Même si la connexion de liaisons de données d’un circuit peut être close à tout moment, la couche d’acheminement (c’est-à-dire, OSPF) suppose que le circuit est disponible sauf si sont présentes des informations contraires, comme un code de diagnostic défavorable résultant d’une tentative de connexion de liaison de données.

Il se peut qu’une connexion de liaison de données ne puisse être établie à cause d’un manque de ressources. Par exemple, un routeur avec une seule interface au taux de base RNIS ne peut pas ouvrir plus de deux connexions de liaisons de données RNIS simultanées (une pour chaque canal B) et des limitations du matériel d’interface et/ou de capacité de commutation peuvent limiter le nombre de SVC X.25 pris en charge simultanément. Lorsque un routeur ne peut pas ouvrir simultanément toutes ses connexions de liaison de données de ses circuits à cause de limitations des ressources, on dit que le routeur est surabonné. Dans ces cas, les datagrammes à transmettre sur les connexions (temporairement non ouvrables) de liaison de données sont éliminés, au lieu d’être mis en file d’attente. Noter aussi que cette incapacité temporaire à ouvrir les connexions de liaisons de données due au sur abonnement N’EST pas rapportée par le système d’acheminement OSPF comme de l’inaccessibilité ; voir plus d’informations au paragraphe 4.3.

L’une ou l’autre extrémité d’un circuit à la demande peut tenter d’ouvrir la connexion de liaison de données. Lorsque les deux extrémités tentent d’ouvrir la connexion simultanément, il y a une possibilité de collision d’appels. Toutes les liaisons de données ne spécifient pas comment sont traitées les collisions d’appels. Aussi, bien que OSPF exige que tous les temporisateurs périodiques soient aléatoires pour éviter la synchronisation (voir au paragraphe 4.4 de la [RFC1583]) si les tentatives d’appel sont strictement commandées par les données, il peut cependant y avoir encore un espacement insuffisant des tentatives d’appel pour éviter des collisions sur certaines liaisons de données. Pour ces raisons, pour les liaisons de données sans prise en charge de la détection/évitement de collision, il est suggéré (mais non spécifié ici) qu’un schéma de retard exponentiel soit employé pour les répétitions d’appel à la couche de liaison des données. En dehors de l’aide apportée au traitement des collisions d’appel, un tel schéma pourrait minimiser les charges (si elles existent) pour les échecs de tentatives d’appel.

Par suite de la mise en œuvre physique de certains circuits à la demande, seule une extrémité du circuit peut être capable d’ouvrir la connexion de liaison de données. Par exemple, certains modems asynchrones peuvent initier des appels, mais ne peuvent pas accepter les appels entrants. Dans ces cas, comme l’initiation de la connexion est pilotée par les données dans le présent mémoire, il faut veiller à s’assurer que la partie d’application qui initie est située à l’extrémité appelante du circuit à la demande.

Bien que la plupart des modifications pour la prise en charge des circuits à la demande soient isolées des points d’extrémité du circuit à la demande (voir la Section 3) il y a des changements qui sont exigés de tous les routeurs OSPF. Ces changements sont décrits dans les paragraphes suivants.

Un nouveau bit est ajouté au champ Options OSPF pour prendre en charge les extensions de circuit à la demande. Ce bit est appelé le "bit DC". Le format résultant du champ Options est décrit à l’Appendice A.

Un routeur qui met en œuvre la fonction décrite à la Section 2 du présent mémoire établit le bit DC dans le champ Options de tous les avis d’état de liaison (LSA, Link State Advertisement) qu’il génère. Ceci, sans considération du type LS du LSA, et aussi sans considérer si le routeur met en œuvre les modifications plus substantielles exigées des points d’extrémité de circuit à la demande (voir la Section 3). Établir le bit DC dans les LSA auto générés dit au reste du domaine d’acheminement que le routeur peut traiter correctement les LSA DoNotAge (voir les paragraphes 2.2, 2.3 et 2.5).

Il y a une seule exception à la règle ci-dessus. Un routeur qui met en œuvre la Section 2 du présent mémoire peut parfois générer un "LSA d’indication" ; ces LSA ont toujours le bit DC à zéro. Les LSA d’indication sont utilisés pour porter à travers les limites de zone l’existence de routeurs incapables de traiter le DoNotAge ; voir les détails au paragraphe 2.5.1.

La sémantique du champ Age LS du LSA est changée, et permet que le bit de poids fort du champ Age LS soit établi. Ce bit est appelé "DoNotAge" ; voir sa définition formelle à l’Appendice C. Les LSA dont le champ Age LS a le bit DoNotAge établi ne sont pas vieillis lorsque ils sont détenus par la base de données d’état de liaison, ce qui signifie qu’ils n’ont pas à être rafraîchis tous les LSRefreshInterval comme le sont tous les autres LSA OSPF.

Par convention, dans la suite de ce mémoire, on exprimera les champs Age LS qui ont le bit DoNotAge établi par "DoNotAge+x", tandis qu’un Age LS exprimé juste par "x" est supposé ne pas avoir le bit DoNotAge établi. Les LSA qui ont DoNotAge établi sont aussi parfois appelés des "LSA DoNotAge".

Lorsque on compare deux instances de LSA pour voir laquelle est la plus récente, les champs Age LS des deux LSA sont comparés chaque fois que sont trouvés identiques les numéros de séquence LS et les sommes de contrôle LS (voir au paragraphe 13.1 de la [RFC1583]). Avant de les comparer, les champs Age LS doivent avoir leurs bits DoNotAge masqués. Par exemple, pour déterminer quel LSA est plus récent, les ages LS de 1 et de DoNotAge+1 sont considérés comme équivalents ; un LSA arrosé avec un age LS de 1 peut être acquitté avec un accusé de réception d’état de liaison affichant un age LS de DoNotAge+1, ou vice versa. En particulier, DoNotAge+MaxAge est équivalent à MaxAge ; cependant, pour la rétro compatibilité, la forme MaxAge devrait toujours être utilisée lors de la purge des LSA du domaine d’acheminement (voir le paragraphe 14.1 de la [RFC1583]).

Donc, la gamme des valeurs admissibles pour le champ Age LS tombe dans deux intervalles : de 0 à MaxAge, et de DoNotAge à DoNotAge+MaxAge. (Précédemment, le champ Age LS ne pouvait pas dépasser la valeur de MaxAge.) Tout champ Age LS qui ne tombe pas dans ces deux gammes devrait être considéré comme égal à MaxAge.

Lorsque un LSA est arrosé à partir d’une interface, la constante InfTransDelay est ajoutée au champ Age LS du LSA. Cela se produit même si le bit DoNotAge est établi ; dans ce cas, le champ Age LS ne peut pas excéder DoNotAge+MaxAge. Si le champ Age LS atteint DoNotAge+MaxAge durant l’arrosage, le LSA est purgé du domaine d’acheminement. Cela préserve la protection prévue par la [RFC1583] contre les boucles d’arrosage.

Le champ Age LS n’est pas protégé par la somme de contrôle. Des erreurs dans la mémoire d’un routeur peuvent établir par erreur le bit DoNotAge d’un LSA, arrêtant le vieillissement du LSA. Cependant, un routeur devrait noter que les propres LSA qu’il génère ne devraient jamais avoir le bit DoNotAge établi dans sa propre base de données. Cela signifie que dans tous les cas, les LSA générés par le routeur lui-même seront rafraîchis tous les LSRefreshInterval. Comme ce rafraîchissement est arrosé dans tout le domaine d’acheminement OSPF, il va remplacer toutes les copies de LSA dans les bases de données des autres routeurs dont les bits DoNotAge ont été établis par erreur.

Comme les LSA qui ont le bit DoNotAge établi ne sont jamais vieillis, ils peuvent rester dans la base de données d’état de liaison même lorsque le générateur du LSA n’existe plus. Pour s’assurer que ces LSA sont finalement purgés du domaine d’acheminement, et que la taille de la base de données d’état de liaison n’augmente pas sans limites, il est exigé des routeurs qu’ils purgent un LSA DoNotAge si les DEUX conditions suivantes sont satisfaites :

(1) Le LSA a été dans la base de données du routeur pendant au moins MaxAge secondes.

(2) Le générateur du LSA a été injoignable (selon les calculs d’acheminement spécifié à la Section 16 de la [RFC1583]) pendant au moins MaxAge secondes.

Pour un exemple,voir le Temps T8 dans l’exemple du paragraphe 4.1. Noter que la fonctionnalité ci-dessus est une exception à la règle OSPF générale qu’un routeur ne peut purger (c’est-à-dire, vieillir prématurément ; voir le paragraphe 14.1 de la [RFC1583]) que ses propres LSA. La fonctionnalité ci-dessus n’appartient qu’aux LSA DoNotAge. Un LSA qui a DoNotAge à zéro ne peut être vieilli prématurément que par son générateur ; autrement, le LSA doit vieillir naturellement jusqu’à MaxAge avant d’être retiré du domaine d’acheminement.

Un intervalle aussi long que MaxAge a été choisi pour éviter toute possibilité de purger un LSA et qu’il soit généré à nouveau peu après. Noter que selon les règles ci-dessus, un LSA DoNotAge ne sera pas retiré du domaine d’acheminement plus vite que si il avait été vieilli naturellement (c’est-à-dire, si DoNotAge n’était pas établi).

Le changement suivant est fait à l’algorithme d’arrosage OSPF. Lorsque un paquet de mise à jour d’état de liaison est reçu qui contient une instance de LSA en fait moins récente que la copie actuelle de la base de données du routeur, celui-ci doit alors traiter le LSA comme suit (modifiant en conséquence l’étape 8 de la Section 13 de la [RFC1583]) :

o Si la copie de la base de données a Age LS égal à MaxAge et le numéro de séquence LS égal à MaxSequenceNumber, éliminer simplement le LSA reçu sans l’acquitter. (Dans ce cas, le numéro de séquence du LSA est revenu à zéro, et le LSA MaxSequenceNumber doit être complètement purgé avant qu’aucun nouveau LSA puisse être introduit). Ce comportement est identique à celui spécifié par l’étape 8 de la Section 13 de la [RFC1583].

o Autrement, renvoyer la copie de la base de données au voisin envoyeur, en l’encapsulant dans un paquet de mise à jour d’état de liaison. En faisant ainsi, ne pas mettre la copie de la base de donnée du LSA sur la liste de retransmission d’état de liaison du voisin, et ne pas accuser réception de l’instance de LSA reçue (la moins récente.

Ce changement est nécessaire pour prendre en charge l’arrosage sur les circuits à la demande. Par exemple, voir le Temps T4 dans l’exemple du paragraphe 4.2.

Cependant, ce changement est aussi bénéfique pour l’arrosage sur des interfaces non à la demande. Pour cette raison, le changement d’arrosage appartient à toutes les interfaces, et pas seulement aux interfaces de circuits à la demande. Le principal exemple implique les LSA MaxAge. Il y a des fois où les LSA MaxAge restent dans la base de données d’un routeur pendant de longs intervalles de temps : 1) lorsque ils sont coincés dans une file d’attente de retransmission sur une liaison lente ou 2) lorsque un routeur ne les purge pas correctement de sa base de données, à cause de bogues logicielles. L’existence prolongée de ces LSA MaxAge peut inhiber l’arrosage de nouvelles instances du LSA. Les nouvelles instances commencent normalement par le numéro de séquence LS initial, et sont traitées comme moins récentes (et donc, éliminées) par les routeurs qui détiennent encore des instances MaxAge. Cependant, avec le changement de l’arrosage ci-dessus, un routeur avec une instance MaxAge va répondre avec l’instance MaxAge. Cela va revenir au générateur du LSA, qui va alors prendre le prochain plus fort numéro de séquence LS et réarroser, écrasant l’instance MaxAge.

Ce changement sera inclus dans les futures révisions de la spécification OSPF de base, [RFC1583].

Les routeurs OSPF non modifiés vont probablement traiter les LSA DoNotAge comme si ils avaient un age LS de MaxAge. Au pire, cela va causer des retransmissions continuelles des LSA DoNotAge. (Voici un exemple de ce scénario. Supposons que les routeurs A et B soient connectés par une liaison point à point. Le routeur A met en œuvre les extensions de circuit à la demande, mais pas le routeur B. Aucun d’eux ne traite ses liaisons de connexion comme un circuit à la demande. À un certain moment, le routeur A reçoit d’un autre voisin, via l’arrosage, un LSA DoNotAge. Le LSA DoNotAge est alors arrosé par le routeur A au routeur B. Le routeur B, qui ne comprend pas les LSA DoNotAge, le traite comme un LSA MaxAge et en accuse réception comme tel au routeur A. Le routeur A reçoit cet accusé de réception mais remarque qu’il est pour une instance différente, et commence donc à retransmettre le LSA.)

Cependant, pour éviter cette confusion, les LSA DoNotAge ne seront permis dans une zone OSPF que si et seulement si, dans la base de données d’état de liaison de la zone, tous les LSA ont le bit DC établi dans leur champ Options (voir au paragraphe 2.1). Noter qu’il n’est pas exigé que le routeur annonceur du LSA soit accessible ; si un des LSA se trouve n’avoir pas son bit DC établi (sans considération d’accessibilité) le routeur devrait alors purger (c’est-à-dire, vieillir prématurément ; voir le paragraphe 14.1 de la [RFC1583]) tous les LSA DoNotAge de la zone. Ces LSA vont alors être générés à nouveau à leur source, cette fois, avec DoNotAge à zéro. Comme le changement du paragraphe 2.3, celui-ci est une exception à la règle générale OSPF qu’un routeur peut seulement purger les LSA qu’il a lui-même générés. Les deux changements ne relèvent que des LSA DoNotAge, et dans les deux cas, le champ Age LS d’un LSA purgé devrait être réglé à MaxAge et non à DoNotAge+MaxAge.

Les LSA externes à l’AS sont arrosés sur tout le domaine d’acheminement OSPF, en exceptant seulement les zones d’extrémité OSPF et les zones "pas si en bout que cela" (NSSA, Not-So-Stubby Area). Pour cette raison, si un routeur OSPF qui est incapable de traiter DoNotAge existe dans une zone "régulière" (c’est-à-dire, une zone qui n’est ni un bout ni une NSSA) aucun LSA externe à l’AS ne peut avoir DoNotAge établi. Le présent mémoire simplifie cette exigence en l’élargissant à la règle suivante : il est permis aux LSA dans les zones OSPF régulières d’avoir DoNotAge établi si et seulement si chaque routeur dans le domaine OSPF (excepté ceux qui sont dans les zones de bout et les NSSA) est capable de traiter DoNotAge. Le reste de ce paragraphe décrit comment mettre la règle en œuvre.

Comme décrit aux paragraphes 2.1 et 2.5, un routeur indique qu’il est capable de traiter DoNotAge en établissant le bit DC dans les LSA qu’il génère. Cependant, il y a un problème. Il est possible que, dans toutes les zones auxquelles se rattache directement le routeur X, tous les routeurs soient capables de traiter DoNotAge, mais qu’il y ait quelque routeur dans une zone "régulière" distante qui ne puisse pas traiter les LSA DoNotAge. Ces informations doivent alors être transportées jusqu’au routeur X, afin qu’il n’arrose/crée pas par erreur de LSA DoNotAge.

La solution est la suivante : les routeurs de bordure de zone transmettent l’existence de routeurs incapables de DoNotAge à travers les frontières de zone, en utilisant les "LSA d’indication". Les LSA d’indication sont des LSA de résumé de type 4 (aussi appelés LSA résumés de routeur frontière de système autonome (ASBR, Autonomous System Boundary Router) ou LSA résumés ASBR) qui décrivent le routeur de zone bordure lui-même comme l’ASBR décrit, avec le coût du LSA réglé à LSInfinity et le bit DC à zéro. Noter que les LSA d’indication ne portent pas d’informations supplémentaires ; en particulier, ils sont utilisés même si le routeur de zone bordure n’est pas réellement un routeur frontière de système autonome (ASBR).

En prenant en compte les LSA d’indication, la règle selon laquelle les LSA DoNotAge sont admis dans toute zone particulière est EXACTEMENT la même que celle donnée au paragraphe 2.5, à savoir que les LSA DoNotAge ne seront admis dans une zone OSPF que si et seulement si, dans la base de données d’état de liaison de la zone, tous les LSA ont le bit DC établi dans leur champ Options.

Par la génération des LSA d’indication, l’existence de routeurs incapables de DoNotAge peut être vue comme venant de zones régulières en dehors du cœur de réseau, vers la zone de cœur de réseau et de là vers toutes les autres zones régulières. Les deux cas suivants résument les exigences pour qu’un routeur de zone bordure génère des LSA d’indication :

(1) Supposons qu’un routeur de zone bordure (routeur X) soit connecté à une zone OSPF régulière non cœur de réseau (zone A). Supposons de plus que la zone A a des LSA avec le bit DC à zéro, autres que des LSA d’indication. Le routeur X devrait alors générer des LSA d’indication dans toutes les autres zones "régulières" directement connectées, incluant la zone cœur de réseau, en gardant en mémoire les lignes directrices du paragraphe 2.5.1.1.

(2) Supposons qu’un routeur de zone bordure (routeur X) soit connecté à la zone OSPF cœur de réseau (zone 0.0.0.0). Supposons de plus que le cœur de réseau ait des LSA avec le bit DC à zéro qui ; soit a) ne sont pas des LSA d’indication, soit b) sont des LSA d’indication qui ont été générés par des routeurs autres que le routeur X lui-même. Le routeur X devrait alors générer des LSA d’indication dans toutes les autres zones "régulières" directement connectées non cœur de réseau, en gardant en mémoire les lignes directrices du paragraphe 2.5.1.1.

Pour limiter le nombre de LSA d’indication générés, les lignes directrices suivantes devraient être observées par un routeur de zone bordure (routeur X) lorsque il génère des LSA d’indication. D’abord, les LSA d’indication ne sont pas générés dans une zone A lorsque A déjà des LSA avec le bit DC à zéro autres que des LSA d’indication. Ensuite, si un autre routeur de zone bordure a généré un LSA d’indication dans la zone A, et si ce routeur de zone bordure a un identifiant de routeur OSPF supérieur à celui du routeur X (même départage que pour la génération d’adresse de transmission ; voir au paragraphe 12.4.5 de la [RFC1583]) le routeur X ne devrait alors pas générer de LSA d’indication dans la zone A.

Par exemple, supposons que trois zones OSPF régulières (zones A, B et C) sont connectées par (respectivement) les routeurs X, Y et Z à la zone cœur de réseau. De plus, supposons que tous les routeurs sont capables du traitement de DoNotAge, excepté les routeurs des zones A et B. Finalement, supposons que le routeur Z a un identifiant de routeur supérieur à celui de Y, qui a à son tour un identifiant de routeur supérieur à celui de X. Dans ce cas, deux LSA d’indication seront générés (si on suit les règles du paragraphe 2.5.1 et les lignes directrices du paragraphe précédent) : le routeur Y va générer un LSA d’indication dans le cœur de réseau, et le routeur Z va générer un LSA d’indication dans la zone C.

Les paragraphes suivants détaillent les modifications exigées des routeurs aux points d’extrémité des circuits à la demande. Elles consistent en modifications de deux pièces principales de OSPF : 1) envoi et réception des paquets Hello sur les circuits à la demande et 2) arrosage des LSA sur les circuits à la demande.

Un paramètre supplémentaire de configuration d’interface OSPF, ospfIfDemand, est défini pour indiquer si une interface OSPF se connecte à un circuit à la demande (voir l’Appendice B). Deux routeurs qui se connectent à un segment de réseau commun n’ont pas besoin de se mettre d’accord sur le statut de circuit à la demande de ce segment. Cependant, pour tirer le plein bénéfice des extensions de circuit à la demande, les deux extrémités d’une liaison en point à point doivent toutes deux accepter de traiter la liaison comme un circuit à la demande (voir le paragraphe 3.2).

Une interface OSPF point à point qui se connecte à un circuit à la demande est considérée comme étant dans l’état "point à point" si et seulement si son voisin associé est dans l’état "1-Way" ou supérieur ; autrement, l’interface est considérée comme étant dans l’état "Down". Les Hello sont envoyés d’une telle interface lorsque elle est dans l’état "Down", à l’intervalle réduit de PollInterval. Si la négociation du paragraphe 3.2.1 réussit, les Hello vont cesser d’être envoyés de l’interface chaque fois que le voisin associé atteint l’état "Plein".

Noter qu’il en résulte qu’un événement "LLDown" pour le voisin du circuit à la demande point à point force le voisin et l’interface à passer tous deux à l’état "Down" (voir le paragraphe 3.2.2).

Pour les réseaux OSPF de diffusion et NBMA qui ont été configurés comme circuits à la demande, il n’y a pas de changement à l’automate à états d’interface.

Les paragraphes qui suivent décrivent les modifications exigées du traitement des paquets Hello OSPF sur les circuits à la demande en point à point.

Pour les réseaux OSPF de diffusion et NBMA qui ont été configurés comme des circuits à la demande, il n’y a pas de changement à l’envoi et la réception des Hello, ni à l’automate à états de voisin. Cela parce que le fonctionnement approprié de l’algorithme de choix du routeur désigné exige des échanges périodiques de paquets Hello.

Sur les circuits à la demande en point à point, les deux points d’extrémité doivent être d’accord pour supprimer l’envoi des paquets Hello. Pour s’assurer de cet accord, un routeur établit le bit DC dans les Hello OSPF et les paquets de description de base de données envoyés de l’interface de demande. Recevoir un Hello ou un paquet de description de base de données avec le bit DC établi indique l’accord. Recevoir un Hello avec le bit DC à zéro et indiquant aussi l’identifiant de routeur du routeur dans le corps du message Hello, ou un paquet de description de base de données avec le bit DC à zéro (ou un qui indique la connexité bidirectionnelle) indique que l’autre extrémité refuse de supprimer les Hello. Dans ces derniers cas, le routeur revient à l’envoi périodique normal des paquets Hello à partir de l’interface (voir le paragraphe 9.5 de la [RFC1583]).

Un circuit à la demande point à point a besoin d’être configuré dans seulement un des deux points d’extrémité (voir le paragraphe 4.1). Si un routeur qui met en œuvre les Sections 2 et 3 du présent mémoire reçoit un paquet Hello avec le bit DC établi, il devrait traiter la liaison point à point comme un circuit à la demande, en faisant les changements appropriés à son traitement de Hello (voir le paragraphe 3.2.2) et à l’arrosage (voir le paragraphe 3.3).

Même si la négociation ci-dessus échoue, le routeur devrait continuer d’établir le bit DC dans ses Hello et ses descriptions de base de données (le voisin va simplement ignorer le bit). Le routeur va alors automatiquement tenter de renégocier la suppression de Hello chaque fois que la liaison s’interrompt et redémarre. Par exemple, si le routeur voisin est réamorcé avec un logiciel capable de fonctionner sur des circuits à la demande (c’est-à-dire, si il met en œuvre les Sections 2 et 3 de ce mémoire) une négociation future réussira.

Aussi, même si la négociation de suppression des Hello échoue, les modifications à l’arrosage décrites au paragraphe 3.3 sont quand même effectuées sur la liaison.

Lorsque la négociation ci-dessus réussit, les paquets Hello ne sont envoyés sur les circuits à la demande en point à point que jusqu’à ce que soit achevée la synchronisation de la base de données d’état de liaison initial avec le voisin (c’est-à-dire, l’état où la connexion de voisin atteint "Plein", comme défini au paragraphe 10.1 de la [RFC1583]). Après cela, les Hello sont supprimés et la connexion de liaison de données avec le voisin est supposée disponible jusqu’à preuve du contraire. Lorsque le routeur trouve que le voisin n’est plus disponible, vraisemblablement à partir de quelque chose comme un code de diagnostic défavorable contenu dans une réponse à un échec de demande d’appel, la connexion de voisin revient à l’état "Down" et des Hello sont envoyés périodiquement (à l’intervalle de PollInterval) pour tenter de redémarrer la synchronisation avec le voisin.

Cela exige des changements à l’automate à états de voisin OSPF (voir le paragraphe 10.3 de la [RFC1583]). La réception de Hello de circuits de demande de voisins dans l’état "En charge" ou "Plein" ne peut plus être exigée. En d’autres termes, l’événement InactivityTimer défini au paragraphe 10.2 de la [RFC1583] n’a pas d’effet sur les circuits à la demande de voisins dans l’état "En charge" ou "Plein". Une précision supplémentaire est nécessaire dans l’événement LLDown de l’automate à états de voisin. Pour les circuits à la demande, cet événement devrait être transposé en "code de diagnostic défavorable" discuté précédemment à la Section 1, et ne devrait pas être généré lorsque la connexion de liaison de données a été fermée simplement pour économiser les ressources. Un LLDown ne devrait pas être généré si une connexion de liaison de données échoue à cause d’un manque temporaire de ressources.

L’arrosage sur les circuits à la demande (point à point ou autres) n’est modifié que si et seulement si tous les routeurs ont indiqué qu’ils peuvent traiter les LSA qui ont DoNotAge établi. Ceci est déterminé par l’examen de la base de données d’état de liaison de la zone OSPF qui contient le circuit à la demande. Tous les LSA qui sont dans la base de données doivent avoir le bit DC établi. Si un ou plusieurs LSA ont le bit DC à zéro, l’arrosage sur les circuits à la demande est inchangé par rapport à la [RFC1583]. Autrement, l’arrosage est changé comme suit.

(1) Seuls les LSA réellement changés sont arrosés sur les circuits à la demande. Lorsque un routeur reçoit une nouvelle instance de LSA, il vérifie d’abord si le contenu a changé. Sinon, le nouveau LSA est simplement un rafraîchissement périodique et n’est pas arrosé sur les circuits à la demande rattachés (il est cependant quand même arrosé sur les autres interfaces). Cette vérification devrait être effectuée dans l’étape 5b de la Section 13 de la [RFC1583]. Lors de la comparaison d’un LSA à son instance précédente, on considère comme un changement de contenu :

o qu’une ou plusieurs instances de LSA aient l’age LS réglé à MaxAge (ou DoNotAge+MaxAge),

o le changement du contenu du LSA, à l’exclusion de l’en-tête d’état de liaison de 20 octets. Noter que cela exclut les changements du numéro de séquence LS et la somme de contrôle LS.

(2) Lorsque il a été décidé d’arroser un LSA sur un circuit à la demande, DoNotAge devrait être établi dans la copie du LSA qui est arrosé sur l’interface de demande. (Il y a une exception : DoNotAge ne devrait pas être établi si l’age LS du LSA est égal à MaxAge.) Établir DoNotAge va être cause que les routeurs sur l’autre côté du circuit à la demande vont détenir indéfiniment le LSA dans leurs bases de données, en retirant le besoin de rafraîchissement périodique. Noter qu’il est parfaitement possible que DoNotAge soit déjà établi. Cela indique simplement que le LSA a déjà été arrosé sur les circuits à la demande. Dans tous les cas, le champ age LS de la copie arrosée doit aussi être incrémenté de InfTransDelay (voir l’étape 5 du paragraphe 13.3 de la [RFC1583], et le paragraphe 2.2 du présent mémoire) comme protection contre les boucles d’arrosage.

Le paragraphe précédent relève aussi des LSA arrosés sur les circuits à la demande en réponse aux demandes d’état de liaison. Il relève aussi des LSA qui sont retransmis sur les circuits à la demande.

Les liaisons virtuelles OSPF sont essentiellement des liaisons point à point non numérotées (voir la Section 15 de la [RFC1583]). En conséquence, la prise en charge de circuits à la demande pour les liaisons virtuelles ressemble à ce qui est décrit pour les liaisons en point à point dans les paragraphes précédents. La principale différence est qu’un routeur qui met en œuvre les Sections 2 et 3 du présent mémoire, et qui prend en charge les liaisons virtuelles, traite toujours les liaisons virtuelles comme si elles étaient des circuits à la demande. Autrement, quand le chemin physique sous-jacent d’une liaison virtuelle contient un ou plusieurs circuits à la demande, les échanges périodiques de protocole OSPF sur la liaison virtuelle garderaient inutilement ouverts les circuits à la demande sous-jacents.

La prise en charge de circuit à la demande sur liaisons virtuelles peut se résumer comme suit :

o Au lieu de modifier l’automate à état d’interface pour les liaisons virtuelles comme on le fait pour les liaisons point à point du paragraphe 3.1, l’automate à états d’interface pour les liaisons virtuelles reste inchangé. Une liaison virtuelle est considérée comme étant dans l’état "point à point" si un chemin intra-zone (à travers la zone de transit de la liaison virtuelle) existe vers l’autre point d’extrémité. Autrement, elle est considérée comme étant dans l’état "Down". Voir la Section 15 de la [RFC1583] pour les détails.

o Les liaisons virtuelles sont toujours traitées comme des circuits à la demande. En particulier, sur des liaisons virtuelles un routeur négocie toujours pour supprimer l’envoi des Hello. Voir les détails aux paragraphes 3.2.1 et 3.2.2.

o Dans la prise en charge de circuit à la demande sur liaison virtuelle, il n’y a pas de "code de diagnostic défavorable" comme décrit à la Section 1. La connexion est plutôt considérée comme existante si et seulement si un chemin intra-zone (à travers la zone de transit de la liaison virtuelle) existe vers l’autre point d’extrémité. Voir les détails à la Section 15 de la [RFC1583].

o Comme les liaisons virtuelles sont toujours traitées comme des circuits à la demande, l’arrosage sur les liaisons virtuelles se passe toujours comme décrit au paragraphe 3.3.

L’interface OSPF point à multipoint a été récemment développée pour être utilisée avec des segments de réseau connectés sans maillage. Un exemple courant est un sous-réseau en relais de trame où les PVC sont provisionnés entre certaines paires de routeurs, mais pas toutes les paires. Dans ce cas, l’interface de point à multipoint représente la seule interface physique avec le réseau en relais de trame, sur lequel plusieurs conversations OSPF en point à point (une sur chaque PVC) ont lieu. Pour plus d’informations sur l’interface en point à multipoint, voir [8].

Comme une interface OSPF point à multipoint consiste essentiellement en plusieurs liaisons point à point, la prise en charge de circuit à la demande sur l’interface point à multipoint ressemble fortement à la prise en charge de circuit à la demande pour les liaisons en point à point. Cependant, comme l’interface point à multipoint exige que toutes les liaisons point à point composantes partagent les mêmes caractéristiques de configuration, il y a quelques différences.

La prise en charge de circuit à la demande sur les interfaces en point à multipoint peut être résumée comme suit :

o Au lieu de modifier l’automate à états d’interface pour les interfaces en point à multipoint comme on l’a fait pour les liaisons en point à point au paragraphe 3.1, l’automate à états d’interface pour les interfaces en point à multipoint reste inchangé.

o Lorsque ospfIfDemand est établi sur une interface en point à multipoint, le routeur essaye de négocier la suppression de Hello séparément sur chaque liaison point à point composante de l’interface. Cette négociation se fait comme au paragraphe 3.2.1. La négociation peut échouer sur certaines liaisons point à point et réussir sur d’autres. C’est acceptable. Sur les liaisons composantes où la négociation échoue, les Hello seront toujours envoyés ; autrement, les Hello vont cesser d’être envoyés lorsque le processus de description de base de données s’achève sur la liaison composante (voir au paragraphe 3.2.2).

o Le paragraphe 3.3 définit le comportement d’arrosage de circuit à la demande pour tous les types d’interface OSPF. Cela inclut les interfaces en point à multipoint.

La présente section donne trois exemples du fonctionnement sur des circuits à la demande. Le premier exemple est probablement le plus courant et certainement le plus basique. Il montre un seul circuit à la demande en point à point qui connecte deux routeurs. Le second illustre ce qui arrive lorsque des circuits à la demande et des liaisons louées sont utilisés en parallèle. Le troisième explique ce qui arrive lorsque un routeur a plusieurs circuits à la demande et ne peut pas les garder tous ouverts (pour des raisons de ressources) en même temps.

La Figure 1 montre un exemple d’interréseau avec un seul circuit à la demande qui fournit la connexité avec le LAN qui contient l’hôte H2. Supposons que les trois routeurs (RTA, RTB et RTC) ont mis en œuvre la fonctionnalité de la Section 2 de ce mémoire, et vont donc établir le bit DC dans leurs LSA. Supposons de plus que le routeur RTB a été configuré pour traiter la liaison avec le routeur RTC comme un circuit à la demande, mais que le routeur RTC n’a pas été configuré ainsi. Supposons finalement que l’interface de LAN qui connecte le routeur RTA à l’hôte H1 est initialement morte.

La séquence d’événements suivante peut alors se produire, commençant par l’amorçage du routeur RTB et activant sa liaison avec le routeur RTC:

Le routeur RTB va commencer d’envoyer des Hello sur le circuit à la demande avec le bit DC établi dans le champ Options des Hello. Comme RTC n’est pas configuré pour traiter la liaison comme un circuit à la demande, le premier Hello que RTB reçoit de RTC ne peut pas avoir le bit DC établi. Cependant, les Hello suivants et les paquets de description de base de données reçus de RTC vont avoir le bit DC établi, indiquant que les deux routeurs se sont mis d’accord pour que la liaison soit traitée comme un circuit à la demande. La négociation entière est décrite par la Figure 2. Noter que si RTC était incapable, ou non désireux, de supprimer les Hello sur la liaison, la description de base de données initiale envoyée du routeur RTC à RTB aurait le bit DC à zéro, forçant le routeur RTB à revenir à l’envoi périodique des Hello spécifié au paragraphe 9.5 de la [RFC1583].

La synchronisation initiale des bases de données d’état de liaison (le processus d’échange de bases de données) sur le circuit à la demande se fait alors comme sur toute liaison en point à point, à une exception près. Les LSA inclus dans les paquets de mise à jour d’état de liaison envoyés sur le circuit à la demande (en réponse aux paquets de demande d’état de liaison) vont avoir le bit DoNotAge établi dans leur champ Age LS. Donc, après la fin du processus d’échange de base de données, tous les routeurs vont avoir trois LSA dans leur base de données d’état de liaison (les LSA de routeur pour les routeurs RTA, RTB et RTC) mais les champs Age LS qui appartiennent aux LSA vont varier selon le côté du circuit à la demande qui les a généré (voir le Tableau 1). Par exemple, tous les routeurs autres que le routeur RTC ont le bit DoNotAge établi dans le LSA de routeur du routeur RTC ; cela supprime le besoin que le routeur RTC rafraîchisse son LSA de routeur sur le circuit à la demande.

Figure 1 : Dans l’exemple du 4.1, un seul circuit à la demande (marqué ODL) coupe un interréseau

Tableau 1 : Après l’instant T1 du 4.1, champs Age LS possibles sur l’un ou l’autre côté du circuit à la demande

Après l’achèvement du processus d’échange de base de données, aucun Hello n’est plus envoyé sur le circuit à la demande. Si il n’y a pas de données d’application à envoyer sur le circuit à la demande, le circuit sera inactif.

Après une certaine période d’inactivité, la connexion de liaison de données sous-jacente va être supprimée (par exemple, un appel RNIS serait supprimé) afin d’économiser les charges de connexion. Cela sera transparent pour l’acheminement OSPF ; il en résulte qu’aucun LSA ou entrée de tableau d’acheminement ne va changer.

À un certain moment, le routeur RTA va rafraîchir son propre LSA de routeur (c’est-à-dire, lorsque l’age LS du LSA atteint LSRefreshInterval). Ce rafraîchissement sera arrosé au routeur RTB, qui va le regarder et décider de NE PAS l’arroser sur le circuit à la demande au routeur RTC, parce que le contenu du LSA n’a pas réellement changé (seul a changé le numéro de séquence LS). À ce moment, les numéros de séquence LS que les routeurs ont pour le LSA de routeur de RTA diffèrent selon le côté du circuit à la demande où se trouve le routeur. Comme il n’y a pas encore de trafic d’application, la connexion de liaison de données sous-jacente reste déconnectée.

Lorsque l’interface de LAN du routeur RTA (qui le connecte à l’hôte H1) s’active, RTA va générer un nouveau LSA de routeur. Ce LSA de routeur VA être arrosé sur le circuit à la demande parce que son contenu a maintenant changé. La connexion de liaison de données sous-jacente devra être activée pour arroser le LSA. Après l’arrosage, les routeurs des deux côtés du circuit à la demande vont à nouveau se mettre d’accord sur le numéro de séquence LS pour le LSA de routeur du routeur RTA.

Temps T6 : La connexion de liaison de données sous-jacente est de nouveau supprimée

En supposant qu’il n’y a toujours pas de trafic d’application qui transite par le circuit à la demande, la connexion de liaison de données sous-jacente va encore être supprimée après une certaine période d’inactivité.

Sitôt que des données d’application doivent être envoyées à travers le circuit à la demande, la connexion de liaison de données sous-jacente est remise en activité.

Si une indication est reçue de la couche de liaison de données ou de la couche physique, indiquant que le circuit à la demande ne peut plus être établi, les routeurs RTB et RTC déclarent leurs interfaces point à point mortes, et génèrent de nouveaux LSA de routeur. Les deux routeurs vont tenter de réactiver la connexion en envoyant des Hello au taux réduit de PollInterval. Noter que tandis que la connexion est inopérante, les routeurs RTA et RTB vont continuer d’avoir un vieux LSA de routeur pour RTC dans leur base de données d’état de liaison, et que ce LSA ne va pas vieillir parce que il a le bit DoNotAge établi. Cependant, selon le paragraphe 2.3, ils vont purger le LSA de routeur du routeur RTC si le circuit à la demande reste inopérant pendant plus longtemps que MaxAge.

Cet exemple montre la fonction de circuit à la demande lorsque des circuits à la demande et des circuits non à la demande (par exemple, des liaisons louées) sont tous deux utilisés pour interconnecter des régions d’un interréseau. Un tel interréseau est montré à la Figure 3. L’hôte H1 peut communiquer avec l’hôte H2 soit sur la liaison à la demande entre les routeurs RTB et RTC, soit sur la liaison louée entre les routeurs RTB et RTD.

Comme les propriétés de base de la fonction de circuit à la demande ont été présentées dans l’exemple précédent, le présent exemple va seulement traiter les seules questions qui découlent de l’utilisation en parallèle de circuits à la demande et non à la demande.

On suppose que les routeurs RTB et RTY sont initialement sous tension, mais que tous les autres routeurs et les liaisons qui leur sont rattachées sont à la fois opérationnelles et mettent en œuvre les modifications de circuit à la demande de OSPF. Tout au long de l’exemple, une connexion TCP entre les hôtes H1 et H2 transmet des données. De plus, on suppose que le coût du circuit à la demande de RTB à RTC a été établi à un niveau très supérieur à celui du coût de la liaison louée entre RTB et RTD ; pour cette raison, le trafic entre les hôtes H1 et H2 va toujours être envoyé sur la liaison louée lorsque elle est opérationnelle.

Les lignes verticales sont des segments de LAN. Six routeurs sont présents, les routeurs RTA à RTE et RTY. RTB a trois interfaces de ligne série, dont deux sont des liaisons louées et la troisième (qui le connecte à RTC) est un circuit à la demande. Deux hôtes, H1 et H2, sont représentés pour illustrer les effets du trafic d’application.

On suppose que RTB prend en charge les modifications OSPF de circuit à la demande. Lorsque le routeur RTB est activé et établit les liaisons avec les routeurs RTC et RTD, il va arroser les mêmes informations sur les deux. Cependant, les LSA envoyés sur le circuit à la demande (au routeur RTC) vont avoir le bit DoNotAge établi, alors que ceux envoyés sur la liaison louée au routeur RTD ne l’auront pas. Comme le bit DoNotAge n’est pas pris en compte lors de la comparaison des instances de LSA, les routeurs sur la droite de RTB (RTC, RTE et RTD) peuvent avoir ou non le bit DoNotAge établi dans leur copie de base de données des LSA de routeur de RTA et RTB. Cela dépend de si les LSA envoyés sur la liaison de demande atteignent les routeurs avant ceux envoyés sur la liaison louée. Une possibilité est décrite dans le Tableau 2.

Tableau 2 : Après le temps T0 dans l’exemple 2, champs Age LS sur le côté droit du routeur RTB.

Tableau 3 : Après le temps T2 dans l’exemple 2, champs Age LS sur le côté droit du routeur RTB.

Tableau 4 : Après le temps T3 dans l’exemple 2, champs Age LS sur le côté droit du routeur RTB.

Tableau 5 : Après le temps T4 dans l’exemple 2, champs Age LS sur le côté droit du routeur RTB.

Tout le trafic d’application s’écoule sur la ligne louée qui connecte les routeurs RTB et RTD au lieu du circuit à la demande, à cause du moindre coût OSPF de la ligne louée. Après une certaine période d’inactivité, la connexion de liaison de données sous-jacente au circuit à la demande sera supprimée. Cela n’affecte pas la base de données OSPF ni les tableaux d’acheminement des routeurs.

Lorsque le routeur RTA rafraîchit son LSA de routeur (comme le font tous les routeurs tous les LSRefreshInterval) le routeur RTB arrose le LSA rafraîchi sur la ligne louée mais pas sur le circuit à la demande, parce que le contenu du LSA n’a pas changé. Ce nouveau LSA ne va pas avoir le bit DoNotAge établi, et va remplacer les vieilles instances (qu’elles aient ou non le bit DoNotAge établi) à cause de son numéro de séquence LS plus élevé. Ceci est représenté au Tableau 3.

Lorsque la ligne louée devient non opérationnelle, la connexion de liaison de données sous-jacente au circuit de demande va être rouverte, afin d’arroser un nouveau (et changé) LSA de routeur pour RTB et aussi porter le trafic d’application entre les hôtes H1 et H2. Après l’arrosage du nouveau LSA, tous les routeurs du côté droit du circuit de demande vont avoir DoNotAge établi dans leur copie du LSA de routeur de RTB et DoNotAge à zéro dans leur copie du LSA de routeur de RTA(voir le Tableau 4).

Temps T4 : Dans le routeur RTE, le LSA de routeur du routeur RTA arrive en fin de temporisation.

Les rafraîchissements du LSA de routeur du routeur RTA ne vont pas être arrosés sur le circuit à la demande. Cependant, le LSA de routeur de RTA est vieilli dans tous les routeurs à droite du circuit à la demande. Pour cette raison, le LSA de routeur va finalement être périmé et réarrosé (par le routeur RTE dans notre exemple). Comme ce LSA périmé constitue un réel changement (voir au paragraphe 3.3) il est arrosé sur le circuit à la demande du routeur RTC à RTB. Il y a maintenant deux scénarios possibles. D’abord, le numéro de séquence LS pour le LSA de routeur de RTA peut être supérieur sur le côté de RTB de la liaison de demande. Dans ce cas, lorsque le routeur RTB reçoit le LSA purgé, il va répondre en arrosant en retour la plus récente instance (voir au paragraphe 2.4). Si au lieu de cela, les numéros de séquence LS sont les mêmes, le LSA purgé sera arrosé sur tout le chemin en retour jusqu’au routeur RTA, qui sera alors forcé de générer à nouveau le LSA. Dans tous les cas, après une courte période de temps, tous les routeurs du côté droit de la liaison de demande auront le bit DoNotAge établi dans leur copie du LSA de routeur de RTA (voir le Tableau 5). Dans le petit intervalle entre la purge et l’attente d’une nouvelle instance du LSA, il y aura une perte temporaire de connexité entre les hôtes H1 et H2.

Temps T5 : Un routeur qui ne prend pas en charge le dispositif se joint au schéma.

Supposons que le routeur RTY devienne maintenant opérationnel, et qu’il ne prenne pas en charge les extensions OSPF de circuit à la demande. Le LSA de routeur du routeur RTY n’aura alors pas le bit DC établi dans son champ Options, et comme le LSA de routeur est arrosé dans tout l’interréseau, il purge tous les LSA qui ont le bit DoNotAge établi et cause l’inversion du comportement d’arrosage sur le circuit à la demande pour revenir au comportement normal d’arrosage défini dans la [RFC1583]. Cependant, bien que tous les LSA soient maintenant arrosés sur le circuit à la demande, sans considération de ce que leur contenu a réellement changé ou non, les Hello vont toujours continuer d’être supprimés sur le circuit à la demande (voir au paragraphe 3.2.2).

L’exemple suivant montre le comportement des extensions de circuit à la demande en présence d’interfaces surabonnées. Noter que la topologie de l’exemple exclut la possibilité de chemins de remplacement. La combinaison de topologie surabonnée et redondante (c’est-à-dire, avec des chemins de remplacement) pose des problèmes particuliers pour les extensions de circuit à la demande. Ces problèmes sont exposés à la Section 7.

La Figure 4 montre un seul routeur (RT1) connecté via des circuits à la demande à trois autres routeurs (RT2 à RT4). On suppose que RT1 peut avoir seulement deux des trois connexions de liaison de données sous-jacentes ouvertes à la fois. Cela peut être dû à une des raisons suivantes : le routeur RT1 utilise peut-être une seule interface RNIS au taux de base (deux canaux B) pour prendre en charge les trois circuits à la demande, ou peut-être que RT1 est connecté à un commutateur de liaison de données (par exemple, un commutateur X.25 ou de relais de trame) qui n’a qu’une telle capacité de connexions de liaison de données simultanées.

Les événements suivants vont survenir, en commençant par l’activation du routeur RT1.

Le routeur RT1 tente d’établir des connexions avec les voisins et de synchroniser les bases de données OSPF avec les routeurs RT2 à RT4. Mais, comme il ne peut pas avoir de connexions de liaison de données ouvertes avec les trois à la fois, il va se synchroniser avec RT2 et RT3, tandis que les Hello envoyés à RT4 seront éliminés (voir à la Section 1).

Temps T1 : La connexion de liaison de données avec RT2 est close pour inactivité.

En supposant qu’aucun trafic d’application n’est envoyé de/vers l’hôte H2, la connexion de liaison de données sous-jacente avec RT2 va finalement être close pour inactivité. Cela va permettre à RT1 de finalement se synchroniser avec RT4 ; le prochain Hello que RT1 tente d’envoyer à RT4 va causer l’ouverture de cette connexion de liaison de données et la synchronisation avec RT4 va s’ensuivre. Noter que, jusqu’à ce moment, H4 aura été considéré comme injoignable par l’acheminement OSPF. Cependant, dans tous les cas, le trafic de données n’aurait pas été livrable à H4 jusqu’à ce moment.

Cela amène RT2 à produire à nouveau son LSA de routeur. Cependant, il peut n’être pas capable de l’arroser à RT1 si RT1 a déjà des connexions de liaisons de données ouvertes avec RT3 et RT4. Alors que la connexion de liaison de données de RT2 à RT1 ne peut pas être ouverte à cause d’un manque de ressources, le nouveau LSA de routeur sera retransmis en continu (et abandonné par l’interface RNIS de RT2 ; voir la Section 1). Cela signifie que les routeurs RT1, RT3 et RT4 ne vont pas détecter l’injoignabilité de l’hôte H2 jusqu’à ce qu’une connexion de liaison de données sur RT1 devienne disponible.

Comme les LSA qui indiquent des changements de topologie sont toujours arrosés sur les circuits à la demande, il est quand même avantageux de concevoir les réseaux de telle sorte que les circuits à la demande soient isolés autant que possible des changements de topologie. Dans OSPF, cela se fait en encastrant les circuits à la demande au sein des zones de bout OSPF ou au sein de NSSA (voir la [RFC1587]). Dans les deux cas, cela isole les circuits à la demande des changements d’acheminement externes à l’AS, qui dans de nombreux réseaux sont les plus fréquents (voir la [RFC1245]). Les zones de bout peuvent même isoler les circuits à la demande des changements dans d’autres zones OSPF.

Aussi, en considérant l’interopération des routeurs OSPF qui prennent en charge les circuits à la demande et de ceux qui ne le font pas (voir au paragraphe 2.5) les zones de bout isolées ou les NSSA peuvent être convertis indépendamment pour prendre en charge les circuits à la demande. À l’oppose, les zones OSPF régulières doivent toutes être converties avant que la fonction puisse prendre effet dans toute zone OSPF régulière particulière.

Les améliorations définies dans le présent mémoire pour la prise en charge des circuits à la demande ont un certain coût. Bien qu’on y gagne une utilisation efficace des circuits à la demande, en ne les gardant ouverts que lorsque il y a réellement des données d’application à envoyer, voici ce qu’on perd :

Dans l’OSPF régulier de la [RFC1583], tous les LSA sont rafraîchis tous les LSRefreshInterval. Cela assure une protection contre les routeurs qui perdent des LSA (ou ont des LSA qui sont corrompus) dans leur base de données d’état de liaison à cause d’erreurs de logiciel, etc. Sur les circuits à la demande, ce rafraîchissement périodique est supprimé, et on compte que les routeurs vont conserver indéfiniment et correctement les LSA marqués avec DoNotAge dans leurs bases de données.

OSPF fournit des variables de gestion de réseau, à savoir ospfExternLSACksumSum et ospfAreaLSACksumSum dans la [RFC1253], qui permettent à une station de gestion de réseau de vérifier la synchronisation des bases de données OSPF entre les routeurs. Cependant, ces variables sont les sommes des champs de somme de contrôle LS des LSA individuels, dont il n’est plus garanti qu’elles soient identiques à travers les circuits à la demande (parce que la somme de contrôle LS couvre le numéro de séquence LS, qui va en général différer entre les circuits à la demande). Cela signifie que ces variables ne peuvent plus être utilisées pour vérifier la synchronisation des bases de données dans les réseaux OSPF qui contiennent des circuits à la demande.

Un interréseau est surabonné lorsque toutes les connexions sous-jacentes de ses circuits à la demande ne peuvent pas être ouvertes en même temps, à cause de limitations des ressources. Ces interréseaux ont été discutés au paragraphe 4.3. Cependant, lorsque toutes les sources possibles dans l’interréseau sont actives en même temps, des problèmes peuvent survenir, qui ne sont pas examinés dans le présent mémoire.

(1) Il y a un problème de conception de réseau. Existe t-il un sous-ensemble de circuits à la demande tel que a) leurs connexions de liaison de données puissent être ouvertes simultanément et b) elles puissent fournir la connexité pour toutes les sources possibles ? Cela exige que (au moins) un arbre d’expansion soit formé à partir des connexions établies. La Figure 4 donne un exemple où ce n’est pas possible ; les hôtes H1 à H4 ne peuvent par parler simultanément, car le routeur RT1 est limité à deux circuits à la demande ouverts simultanément.

(2) Même si il est possible que soit formé un arbre d’expansion, y en a t-il un ? Selon le modèle de la Section 1, les circuits à la demande sont activés quand nécessaire pour le trafic de données, et restent établis tant que du trafic de données est présent. Un exemple est donné à la Figure 5. Quatre routeurs sont interconnectés via des circuits à la demande, et chaque routeur est capable d’établir un circuit avec n’importe lequel des autres. Cependant, on suppose que chaque routeur ne peut avoir que deux circuits ouverts à la fois (par exemple, les routeurs pourraient utiliser le débit de base RNIS). Dans ce cas, on espère que les connexions de liaison de données de la Figure 5a vont se former. Mais les connexions de la Figure 5b sont également vraisemblables, qui laissent l’hôte H2 incapable de communiquer. Une approche possible de ce problème serait que a) la base de données OSPF indique quels circuits à la demande ont été en fait établis et b) soit mis en œuvre une construction d’arbre d’expansion réparti (voir un exemple au paragraphe 5.2.2 de [9]) lorsque nécessaire.

(3) Même lorsque un arbre d’expansion a été construit, sera t-il utilisé ? Les routeurs qui mettent en œuvre la fonction décrite dans le présent mémoire ne savent pas nécessairement quelles connexions de liaison de données sont établies à un instant donné. En fait, ils voient tous les circuits à la demande comme étant également disponibles, qu’ils soient ou non actuellement établis. Ainsi, par exemple, même lorsque les connexions établies forment le schéma de la Figure 5a, le routeur RT1 peut quand même croire que le meilleur chemin vers le routeur RT3 est par le circuit à la demande direct. Cependant, ce circuit ne peut pas être établi à cause d’un manque de ressources.

Une approche possible de ce problème est d’augmenter le coût OSPF des circuits à la demande qui éliminent actuellement des paquets d’application (c’est-à-dire, ne peuvent pas être établis) à cause d’un manque de ressources. Cela peut aider l’acheminement à trouver des chemins qui puissent réellement livrer les paquets. D’un autre côté, cela va créer plus de trafic d’acheminement. Aussi, des oscillations d’acheminement indésirables peuvent en résulter quand on commence à faire varier les métriques d’acheminement pour refléter la dynamique des conditions du réseau ; voir [10].

Les capacités possibles suivantes associées à l’acheminement de circuit à la demande ont été explicitement écartées du présent mémoire :

o Lorsque la topologie d’une zone OSPF change, les changements sont arrosés sur les circuits à la demande de la zone, même si cela exige l’établissement ou le rétablissement des connexions de liaison de données des circuits à la demande. On peut imaginer un système d’acheminement où l’arrosage des changements de topologie sur les circuits à la demande seraient différé jusqu’à ce que les circuits à la demande soient rouverts pour le trafic d’application. Cependant, cette capacité n’est pas prise en charge parce que retarder l’arrosage de cette manière entraverait parfois la capacité à découvrir de nouvelles destinations réseau.

o En précisant la capacité précédente, on pourrait imaginer que l’administrateur du réseau serait capable de configurer pour chaque interface de demande si l’arrosage devrait être immédiat, ou si il devrait être différé jusqu’à ce que la connexion de liaison de données soit établie pour le trafic d’application. Cela permettrait certains comportements d’acheminement "spécifiques de l’application". Par exemple, un circuit à la demande peut connecter une collection de sous réseaux fondés sur le client à une collection de sous réseaux fondés sur le serveur. Si le côté client est configuré pour différer l’arrosage, alors que le côté serveur est configuré à arroser immédiatement les changements, les nouveaux serveurs seraient découverts rapidement alors que les nouveaux clients pourraient n’être pas découverts avant qu’ils n’initient une conversation. Cependant, cette capacité n’est pas prise en charge parce qu’elle entraîne une augmentation de la complexité (et donc de possibilités d’erreur) de la configuration du réseau.

Le champ Options OSPF est présent dans les paquets Hello OSPF, dans les paquets de description de base de données et dans tous les LSA. Le champ Options permet aux routeurs OSPF de prendre en charge (ou de ne pas prendre en charge) des capacités facultatives, et de communiquer leur niveau de capacités aux autres routeurs OSPF. Par ce mécanisme, des routeurs de capacités différentes peuvent être mélangés au sein d’un domaine d’acheminement OSPF.

Le présent mémoire définit un des bits d’option : le bit DC (pour la capacité de circuit à la demande). Le bit DC est établi dans les LSA auto générés d’un routeur si et seulement si il prend en charge la fonctionnalité définie à la Section 2 du présent mémoire. Noter que cela ne signifie pas nécessairement que le routeur puisse être le point d’extrémité d’un circuit à la demande, mais seulement qu’il peut correctement traiter les LSA qui ont le bit DoNotAge établi. À l’opposé, le bit DC est établi dans les paquets Hello et les paquets de description de base de données envoyés à une interface si et seulement si le routeur veut traiter le réseau en point à point rattaché comme un circuit à la demande (voir le paragraphe 3.2.1).

L’ajout du bit DC fait apparaître l’allocation actuelle du champ Options OSPF comme suit :

Ce bit décrit la capacité d’acheminement fondé sur le TOS, comme spécifié dans la [RFC1583].

Ce bit décrit la façon dont les LSA externes à l’AS sont arrosés, comme décrit dans la [RFC1583].

Ce bit décrit si les datagrammes de diffusion groupée IP sont transmis selon les spécifications de la [RFC1584].

Ce bit décrit le traitement des LSA de type 7, comme spécifié dans la [RFC1587].

Ce bit décrit la volonté du routeur de recevoir et transmettre les LSA d’attributs externes, comme spécifié dans [5].

Ce bit décrit le traitement des circuits à la demande, comme spécifié dans le présent mémoire. Son réglage dans les paquets Hello et de description de base de données est décrit aux paragraphes 3.2.1 et 3.2.2. Son réglage dans les LSA est décrit aux paragraphes 2.1 et 2.5.

Le présent mémoire définit un seul paramètre de configuration supplémentaire pour les interfaces OSPF. De plus, le paramètre de configuration d’interface OSPF PollInterval, précédemment utilisé seulement sur les réseaux NBMA, est maintenant aussi utilisé sur les réseaux point à point (voir les paragraphes 3.1 et 3.2.2).

Il indique si l’interface connecte un circuit à la demande. Lorsque réglé à VRAI, les procédures décrites à la Section 3 du présent mémoire sont suivies, afin d’envoyer un minimum de trafic d’acheminement sur le circuit à la demande. Sur les réseaux en point à point, cela permet que le circuit soit fermé lorsque il ne porte pas de trafic d’application. Lorsque une interface de diffusion ou de NBMA est configurée à connecter un circuit à la demande (voir le paragraphe 1.2 de la [RFC1583]), les connexions de liaison de données vont rester constamment ouvertes du fait du trafic de Hello OSPF, mais la quantité de trafic d’arrosage va être considérablement réduite.

Le présent mémoire définit une seule constante architecturale OSPF supplémentaire.

Égal à la valeur hexadécimale 0x8000, qui est le bit de poids fort du champ de 16 bits Age LS dans les LSA OSPF. Lorsque ce bit est établi dans le champ Age LS, le LSA n’est pas vieilli car il est détenu dans la base de données d’état de liaison du routeur. Cela permet l’élimination du rafraîchissement périodique du LSA sur les circuits à la demande. Voir le paragraphe 2.2 pour des précisions sur le traitement du bit DoNotAge.

[RFC1253] F. Baker et R. Coltun, "Base de données d'informations de gestion OSPF version 2", août 1991. (remplacée par RFC1850)

[RFC1582] G. Meyer, "Extensions à RIP pour prendre en charge les circuits de demande", février 1994. (P.S.)

[RFC1584] J. Moy, "Extensions de diffusion groupée à OSPF", mars 1994. (Historique)

[RFC1587] R. Coltun et V. Fuller, "L'option NSSA OSPF", mars 1994. (P.S., remplacée par RFC3101)

[5] Ferguson, D., "The OSPF External Attributes LSA", (non publiée comme RFC)

[10] Khanna, A., "Short-Term Modifications to Routing et Congestion Control", BBN Report 6714, BBN, février 1988.

Groupe de travail Réseau	J. Moy, Cascade
Request for Comments : 1793	avril 1995
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle