Groupe de travail Réseau 	P. Psenak, Cisco Systems	
Request for Comments : 4915	S. Mirtorabi, Force10 Networks	
Catégorie : Sur la voie de la normalisation	A. Roy, Cisco Systems	
	L. Nguyen, Cisco Systems	
	P. Pillay-Esnault, Cisco Systems	
Traduction Claude Brière de L'Isle	juin 2007	

Acheminement multi topologies (MT) dans OSPF

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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 "Protocoles officiels de l’Internet" (STD 1) pour voir 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 (2007). Tous droits réservés.

Résumé
Le présent document décrit une extension au plus court chemin ouvert en premier (OSPF, Open Shortest Path First) afin de définir des topologies IP indépendantes appelées multi topologies (MT). L'extension multi topologies peut être utilisée pour calculer des chemins différents pour le trafic en envoi individuel, en diffusion groupée, pour différentes classes de service fondées sur des critères souples, ou dans une topologie de gestion de réseau dans la bande.

Une extension facultative pour exclure des liaisons choisies de la topologie par défaut est aussi décrite.
Table des matières
1. Introduction	2
1.1 Différences entre acheminement multi topologies et fondé sur le TOS	2
2. Terminologie	2
2.1 Notation des exigences	2
2.2 Termes	2
3. Spécifications fonctionnelles de MT de base	3
3.1 Frontière de zone MT	3
3.2 Adjacence des MT	3
3.3 Envoi des paquets de contrôle OSPF	3
3.4 Annonce des adjacences de MT et des préfixes IP correspondants	3
3.5 Purge des informations de MT	4
3.6 Calcul de SPF de MT	4
3.7 Valeurs d'identifiant de MT	4
3.8 Transmission dans MT	4
4. Spécifications fonctionnelles de l'exclusion de liaisons de la topologie par défaut	4
4.1 Exclusion de liaisons dans la topologie par défaut	4
4.2 Nouveau paramètre de structure de données de zone	5
4.3 Formation d'adjacence avec capacité d'exclusion de liaison	5
4.4 Transmission des paquets de contrôle OSPF sur des liaisons exclues	5
4.5 Annonce de LSA OSPF et calcul de SPF pour liaisons exclues	6
5. Interopérabilité entre routeurs à capacité et sans capacité MT	6
5.1 Considérations de compatibilité de circuit de demande	6
6. Migration de zone non MT à zone MT	6
7. Considérations de gestion de réseau MT	7
7.1 Création d'une topologie de gestion dédiée pour inclure tous les nœuds	7
7.2 Extention de la topologie par défaut à tous les nœuds	7
8. Considérations sur la sécurité	7
9. Considérations relatives à l'IANA	7
10. Références	8
10.1 Références normatives	8
10.2 Références pour information	8
Appendice A. Remerciements	8
Appendice B. Formats de données OSPF	8
B.1 LSA de routeurs	8
B.2 LSA de réseau	9
B.3 LSA sommaires	10
B.4 LSA externes à l'AS	10
B.5 LSA externes à l'AS de type 7	11
Adresse des auteurs	11
Déclaration complète de droits de reproduction	11

 	1.	Introduction

OSPF utilise un format de paquet fixe, donc il n'est pas facile d'introduire des extensions rétro compatibles. Cependant, la spécification OSPF [RFC2328] introduit la métrique de type de service (TOS, Type of Service) dans une spécification antérieure [RFC1583] afin d'annoncer un coût de liaison différent fondé sur le TOS. L'acheminement fondé sur le TOS comme décrit dans la [RFC1583] n'a jamais été déployé et a été ensuite déconseillé. La [RFC5120] décrit un mécanisme similaire pour ISIS.

On propose de réutiliser les champs de métrique fondée sur le TOS. Ils ont été redéfinis et sont utilisés pour annoncer différentes topologies en annonçant des métriques séparées pour chacune d'elles.

 	1.1	Différences entre acheminement multi topologies et fondé sur le TOS
L'acheminement multi topologies diffère de l'acheminement fondé sur le TOS de la [RFC1583] de la façon suivante :

1.	Avec l'acheminement de TOS [RFC1583], le TOS ou le codet Diffserv (DSCP, Diffserv Code Point) dans l'en-tête IP est transposé directement en le calcul de plus court chemin en premier (SPF, Shortest Path First) OSPF et le tableau d'acheminement correspondant. Cela limite le nombre et la définition des topologies aux 16 valeurs de TOS spécifiées au paragraphe 12.3 de la [RFC1583]. Avec l'acheminement multi topologies, en quelle topologie se transpose la classification du type de trafic sort du domaine d'application du présent document.

2.	Avec l'acheminement de TOS [RFC1583], le trafic qui est inaccessible dans le tableau d'acheminement associé au TOS correspondant va revenir au TOS 0 du tableau d'acheminement. Avec l'acheminement multi topologies, ceci est facultatif.

3.	Avec l'acheminement de TOS [RFC1583], les liaisons ou préfixes individuels ne pourraient pas être exclus d'une topologie. Si les options de bit T de l'annonce d'état de liaison (LSA, Link State Advertisement) sont établies, toutes les liaisons ou préfixes sont soit annoncées explicitement, soit reviennent par défaut à la métrique TOS 0. Avec l'acheminement multi topologies, les liaisons ou préfixes qui ne sont pas annoncés pour une topologie spécifique n'existent pas dans cette topologie.

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

 	2.2	Termes
On utilise la terminologie suivante dans le présent document :

Routeur non MT : routeurs qui n'ont pas la capacité multi topologies.

Routeur MT : routeurs qui ont la capacité multi topologies décrite dans le présent document.

MT-ID : champ de TOS dans les LSA renommé pour représenter l'identifiant multi topologies.

Topologie par défaut : topologie construite en utilisant la métrique TOS 0 (métrique par défaut).

Topologie MT : topologie construite en utilisant la métrique de MT-ID correspondante.

MT : notation abrégée pour multi topologies.

Topologie MT#0 : représentation de la métrique TOS 0 en format MT-ID.

Zone non MT : zone qui contient seulement des routeurs non multi topologies.

Zone MT : zone qui contient à la fois des routeurs non MT et des routeurs MT, ou seulement des routeurs MT.

 	3.	Spécifications fonctionnelles de MT de base
 	3.1	Frontière de zone MT
Chaque interface OSPF appartient à une seule zone, et toutes les MT qui partagent cette liaison doivent appartenir à la même zone. Donc, les frontières de la zone pour toutes les MT sont les mêmes, mais chaque rattachement de MT à la zone est indépendant.

 	3.2	Adjacence des MT
Chaque interface peut être configurée pour appartenir à un ensemble de topologies. Une seule adjacence est formée avec les voisins sur l'interface même si l'interface est configurée à participer à plusieurs topologies. De plus, la formation d'une adjacence est indépendante des topologies configurées sur l'interface locale et le routeur voisin.

 	3.3	Envoi des paquets de contrôle OSPF
L'envoi de paquets de contrôle OSPF est inchangé par rapport à la [RFC2328]. Pour les paquets de contrôle OSPF envoyés sur l'extrémité distante d'une liaison virtuelle, le chemin de zone de transit DOIT être composé de liaisons participant à la topologie par défaut et les paquets de contrôle OSPF DOIVENT être transmis en utilisant la topologie par défaut.

 	3.4	Annonce des adjacences de MT et des préfixes IP correspondants
Le champ Métrique de TOS est réutilisé pour annoncer la métrique spécifique de la topologie pour les liaisons et préfixes appartenant à cette topologie. Le champ TOS est redéfini comme MT-ID dans la charge utile des LSA de routeur, sommaires, et externes à l'AS de type 5 et de type 7 (voir l'Appendice B).

Les métriques MT-ID dans les LSA DEVRAIENT être en ordre ascendant de MT-ID. Si un MT-ID existe plusieurs fois dans une LSA ou une liaison de routeur, la métrique dans la première instance de MT-ID DOIT être utilisée.

Quand un routeur établit une pleine adjacence sur une liaison qui appartient à un ensemble de MT, il annonce le coût correspondant pour chaque MT-ID.

Par défaut, toutes les liaisons sont incluses dans la topologie par défaut et tous les préfixes annoncés qui appartiennent à la topologie par défaut vont utiliser la métrique de TOS 0 comme défini dans la [RFC2328].

Chaque MT a son propre champ Métrique MT-ID. Quand une liaison ne fait pas partie d'une certaine MT, la métrique de MT-ID correspondante est exclue de la LSA.

La LSA de réseau ne contient aucune information de MT car le routeur désigné (DR) est partagé par toutes les MT. Donc, il n'y a pas de changement à la LSA de réseau.

 	3.4.1	Acheminement inter zones et externe
Dans les LSA sommaires et les LSA externes à l'AS de type 5 et de type 7, les champs de métrique de TOS sont redéfinis comme champs de métrique MT-ID et sont utilisés pour annoncer l'accessibilité de préfixe et de routeur dans la topologie correspondante.

Quand un routeur génète une LSA sommaire, ou une LSA externe à l'AS de type 5 ou 7 qui appartient à un ensemble de MT, il inclut le coût correspondant pour chaque MT-ID. Par défaut, le préfixe participe à la topologie par défaut et utilise la métrique de TOS 0 pour la topologie par défaut, comme dans la norme OSPF [RFC2328].

L'établissement du bit P dans une LSA externe à l'AS de type 7 est indépendant de la topologie et relève de tous les MT-ID annoncés dans le corps de la LSA.

 	3.5	Purge des informations de MT
Quand une certaine liaison ou préfixe qui existait ou était accessible dans une certaine topologie ne fait plus partie de cette topologie ou est inaccessible dans cette topologie, une nouvelle version de la LSA DOIT être générée en excluant les informations de métrique qui représentent la liaison ou le préfixe dans cette topologie.

La métrique de MT dans la LSA de routeur peut aussi être réglée à la métrique maximum possible pour permettre au routeur de devenir une extrémité dans une certaine topologie [RFC3137].

 	3.6	Calcul de SPF de MT
En considérant les métriques de MT-ID dans les LSA, OSPF calcule plusieurs topologies et trouve des chemins pour des préfixes IP pour chaque MT indépendamment. Un SPF séparé va être calculé pour chaque MT-ID pour trouver des chemins indépendants pour les préfixes IP.

Les LSA de réseau sont utilisées par toutes les topologies durant le calcul de SPF. Durant le SPF pour un certain MT-ID, seules les liaisons et métriques pour cet MT-ID sont considérées. Les entrées dans le tableau d'acheminement de routeur sont aussi spécifiques du MT-ID.

 	3.7	Valeurs d'identifiant de MT
Comme les LSA externes à l'AS utilisent le bit de poids fort du champ MT-ID (bit E) pour le type de métrique externe, seuls les MT-ID dans la gamme de 0 à 127 sont valides. Les valeurs de MT-ID suivantes sont réservées :

0 :	Réservé pour annoncer la métrique associée à la topologie par défaut (paragraphe 4.2)
1 :	Réservé pour annoncer la métrique associée à à la topologie de diffusion groupée par défaut
2 :	Réservé pour les besoins de la gestion IPv4 dans la bande
3 à 31 :	Réservé pour les allocations par l'IANA
32 à 127 :	Réservé pour des caractéristiques de développement, expérimentales et propriétaires [RFC3692]
128 à 255 :	Invalides et DEVRAIENT être ignorées

 	3.8	Transmission dans MT
Il sort du domaine d'application du présent document de spécifier comment les informations dans des structures de transmission spécifiques de diverses topologies sont utilisées durant la transmission de paquet ou comment les paquets entrants sont associés à la topologie correspondante. Pour un fonctionnement correct, le comportement de transmission et les méthodes pour associer les paquets entrants à la topologie correspondante doivent tous deux être appliqués de façon cohérente dans le réseau.

 	4.	Spécifications fonctionnelles de l'exclusion de liaisons de la topologie par défaut

Le multi topologies implique que tous les routeurs participent à la topologie par défaut. Cependant, il peut être utile d'exclure certaines liaisons de la topologie par défaut et de les réserver pour des classes de trafic spécifiques.

L'extension multi topologies pour l'exclusion de liaison ou prefixe de la topologie par défaut est décrite dans les paragraphes qui suivent.

 	4.1	Exclusion de liaisons dans la topologie par défaut
OSPF n'a pas de notion de liaison inaccessible. Toutes les liaisons peuvent avoir une métrique maximum de 0xFFFF annoncée dans la LSA de routeur. La capacité d'exclusion de liaison exige que les routeurs ignorent les métriques TOS 0 dans les LSA de routeur dans la topologie par défaut et utilisent à la place la métrique MT-ID#0 pour annoncer la métrique associé à la topologie par défaut. Donc, tous les routeurs dans une zone DOIVENT s'accorder sur la façon dont la métrique pour la topologie par défaut va être annoncée.

Le bit T inutilisé est défini comme bit MT dans le champ d'options afin de s'assurer qu'un routeur capable d'exclusion de liaison multi topologies va seulement former une adjacence avec un autre routeur de configuration similaire.

              +---+---+---+---+---+---+---+---+
              |DN |O  |DC |EA |NP |MC |E  |MT |
              +---+---+---+---+---+---+---+---+

Figure 1 : Bits d'options OSPF

Bit MT : si DefaultExclusionCapability (capacité d'exclusion par défaut) est activé, le bit DOIT être établi dans les paquets Hello et DEVRAIT être établi dans le paquet Description de base de données (paragraphe 4.2).

 	4.2	Nouveau paramètre de structure de données de zone
On définit un nouveau paramètre dans la structure de données de zone :

DefaultExclusionCapability : ce paramètre configurable assure que tous les routeurs dans une zone ont cette capacité établie avant que la topologie par défaut puisse être désactivée sur une liaison de routeur dans la zone sans causer de problèmes de rétro compatibilité.

Quand une structure de données de zone est créée, le paramètre DefaultExclusionCapability est désactivé par défaut.

Si DefaultExclusionCapability est désactivé :
o	Le bit MT DOIT être mis à zéro dans les paquets Hello et DEVRAIT être mis à zéro dans les paquets Description de base de données.
o	Si une liaison participe à une topologie non par défaut, elle est automatiquement incluse dans la topologie par défaut pour prendre en charge la rétro compatibilité entre routeurs MT et non MT. Cela est réalisé en utilisant le champ Métrique TOS 0 commme décrit dans la [RFC2328].

Si DefaultExclusionCapability est activé :
o	Le bit MT DOIT être établi dans les paquets Hello et DEVRAIT être établi dans les paquets Description de base de données.
o	Le routeur va seulement accepter un paquet Hello si le bit MT est établi (paragraphe 4.3).

Quand DefaultExclusionCapability est réglé à activé, un routeur est dit fonctionner en mode DefaultExclusionCapability.

 	4.3	Formation d'adjacence avec capacité d'exclusion de liaison
Afin d'avoir une transition en douceur d'une zone non MT à une zone MT, un routeur MT avec DefaultExclusionCapability désactivé va former des adjacences avec des routeurs non MT et va inclure toutes les liaisons au titre de la topologie par défaut.

Une liaison peut cesser de participer à la topologie par défaut si DefaultExclusionCapability est réglé à activé. Dans cet état, un routeur va seulement former une adjacence avec les routeurs qui établissent le bit MT dans leurs paquets Hello. Cela va assurer que tous les routeurs ont DefaultExclusionCapability activé avant que la topologie par défaut puisse être désactivée sur une liaison.

La réception des paquets Hello OSPF comme définie au paragraphe 10.5 de la [RFC2328] est modifiée comme suit :

o	Si le paramètre DefaultExclusionCapability dans la structure Données de zone est réglé à activé, les paquets Hello sont éliminés si le paquet reçu n'a pas le bit MT établi dans les options d'en-tête.

La réception des paquets Description de base de données OSPF comme définie au paragraphe 10.6 de la [RFC2328] est inchangée. Alors que les options de paquets sont validées dans les paquets Hello, seule la vérification d'option effectuée pour les paquets Description de base de données assure que les options ne changent pas durant le processus d'échange de base de données.

 	4.4	Transmission des paquets de contrôle OSPF sur des liaisons exclues
Si le paramètre DefaultExclusionCapability est activé, la topologie par défaut peut être désactivée sur une interface. Désactiver la topologie par défaut sur une interface n'impacte pas l'installation de chemins connectés pour l'interface dans la topologie par défaut. Cela affecte seulement ce qu'un routeur annonce dans sa LSA de routeur.

Cela permet aux paquets de contrôle OSPF d'être envoyés et reçus sur une interface même si la topologie par défaut est désactivée sur l'interface.

 	4.5	Annonce de LSA OSPF et calcul de SPF pour liaisons exclues
Quand DefaultExclusionCapability est activé et que la liaison ne participe pas à la topologie par défaut, la métrique MT-ID#0 n'est pas annoncée. La métrique TOS 0 de la liaison est ignorée durant le calcul du SPF de la topologie par défaut.

Quand DefaultExclusionCapability est activé et qu'une liaison participe à la topologie par défaut, la métrique MT-ID#0 est utilisée pour annoncer la métrique associée à la topologie par défaut. La métrique TOS 0 de la liaison est ignorée durant le calcul du SPF de la topologie par défaut

Indépendamment du paramètre DefaultExclusionCapability, la métrique TOS 0 est utilisée pour les LSA sommaires et les LSA externes à l'AS de type 5 et de type 7.

o	Si le préfixe ou routeur n'existe pas dans la topologie par défaut, la métrique TOS 0  est réglée à l'infini (0xFFFFFF).

o  Si le préfixe ou routeur existe dans la topologie par défaut, la métrique TOS 0 est utilisée pour annoncer la métrique dans la topologie par défaut.

Durant le calcul de préfixe sommaire et externe pour la topologie par défaut, la métrique TOS 0 est utilisée pour les LSA sommaires et les LSA externes à l'AS de type 5 et de type 7.

 	5.	Interopérabilité entre routeurs à capacité et sans capacité MT

Le champ Métrique par défaut est obligatoire dans toutes les LSA (même quand la valeur de la métrique est 0). Même quand une liaison ou préfixe n'existe pas dans la topologie par défaut, un routeur non MT va considérer la valeur zéro dans le champ Métrique comme une valeur valide et considérer que la liaison ou préfixe fait partie de la topologie par défaut.

Afin d'empêcher le problème ci-dessus, un routeur à capacité MT va inclure toutes les liaisons au titre de la topologie par défaut. Si des liaisons doivent être retirées de la topologie par défaut, un routeur à capacité MT doit être configuré en mode DefaultExclusionCapability. Dans ce mode, les routeurs vont s'assurer que tous les autres routeurs dans la zone sont en mode DefaultExclusionCapability avant de considérer la métrique MT-ID#0 dans le calcul du SPF. C'est seulement alors que le champ métrique TOS 0 dans les LSA de routeur peut être ignoré en toute sécurité durant le calcul de SPF de topologie par défaut.

Noter que pour que tout préfixe ou routeur devienne accessible dans une certaine topologie, un chemin contigu à l'intérieur de cette topologie doit exister entre le routeur qui fait le calcul et le préfixe ou routeur de destination.

 	5.1	Considérations de compatibilité de circuit de demande
Un changement du paramètre DefaultExclusionCapability d'une zone exige un traitement supplémentaire pour les zones voisines qui suppriment des paquets Hello comme spécifé dans "Extension d'OSPF pour la prise en charge de circuits à la demande" [RFC1793]. Quand le paramètre DefaultExclusionCapability est changé pour une zone, la suppression de Hello doit être désactivée pour ces voisins pour une période de RouterDeadInterval secondes. Cela implique que les paquets Hello sont envoyés avec le bit DC à zéro, comme spécifé au paragraphe 3.2.1 de la [RFC1793] durant cette période. Après RouterDeadInterval secondes, soit l'adjacence va être supprimée à cause du rejet de paquets Hello avec un bit MT en conflit, soit la suppression de Hello va être renégociée.

 	6.	Migration de zone non MT à zone MT

Introduire MT-OSPF dans un réseau peut être fait graduellement pour permettre aux routeurs MT et non MT de participer à la topologie par défaut tandis que les routeurs MT participent à d'autres topologies.

Si il y a une exigence d'exclure certaines liaisons de la topologie par défaut dans une zone, tous les routeurs dans la zone DOIVENT être dans le mode DefaultExclusionCapability. Dans cette section, on décrit les étapes de migration à considérer lors de la transition d'un réseau non MT à un réseau MT.

Considérons un réseau avec une zone de cœur et un ensemble de zone non de cœur fonctionnant en mode OSPF standard. On souhaitrait migrer partiellement ou complètement sur un réseau MT.

1.	Comme demandé, une partie d'une zone est mise à niveau pour être à capacité MT. Les routeurs MT vont interagir avec les routeurs non MT dans la topologie par défaut et participer à d'autres topologies comme demandé.

2.	Si une nouvelle zone non de cœur est créée pour les routeurs MT, elle peut être configurée en mode DefaultExclusionCapability car il n'y a pas d'interaction exigée avec les routeurs non MT. Dans ce mode, la topologie par défaut peut être exclue sur des liaisons comme nécessaire.

3.	Si il y a plusieurs zones non de cœur où MT est utilisée, il est souhaitable que la zone de cœur soit d'abord mise à niveau pour être capable de MT afin que l'acheminement inter zones soit assuré pour les destinations MT dans les différentes zones.

4.	Graduellement, le réseau entier peut être rendu capable de MT.

Noter que l'acheminement inter zones pour la zone MT dépend encore de la zone cœur. Donc, si différentes zones configurées pour une topologie donnée ont besoin de communiquer, la zone cœur doit aussi être configurée pour cette topologie.

 	7.	Considérations de gestion de réseau MT

Quand plusieurs topologies OSPF existent au sein d'un domaine, certains routeurs peuvent être configurés à participer à un sous ensemble des MT dans le réseau. Cette section discute certaines des options qu'on a pour permettre le fonctionnement ou pour que les stations de gestion de réseau accèdent à ces routeurs.

 	7.1	Création d'une topologie de gestion dédiée pour inclure tous les nœuds
Cette approche est pour établir une toplologie de gestion dédiée ou une topologie de gestion dans la bande. Cette topologie 'mgmt' va inclure tous les routeurs qui doivent être gérés. Les chemins calculés dans la topologie vont être installés dans la base de données d'informations d'acheminement (RIB, Routing Information Base) 'mgmt'. À condition que la topologie 'mgmt' utilise un ensemble d'espace d'adresses sans chevauchement avec la topologie par défaut, ces chemins 'mgmt' peuvent aussi être facultativement installés dans la RIB par défaut. Les avantages de chemins 'mgmt' dupliqués dans les deux RIB incluent : les utilitaires de gestion de réseau sur le système n'ont pas à être modifiés pour utiliser une RIB spécifique autre que la RIB par défaut ; la topologie 'mgmt' peut partager la même liaison avec la topologie par défaut si elle est conçue ainsi.

 	7.2	Extention de la topologie par défaut à tous les nœuds
Même dans le cas où la topologie par défaut n'est pas utilisée sur certains des nœuds dans la transmission IP, on peut vouloir étendre la topologie par défaut à ces nœuds pour les besoins de la gestion du réseau. Les opérateurs DEVRAIENT mettre un coût élevé aux liaisons qui appartiennent à la portion étendue de la topologie par défaut. De cette façon, le trafic de données IP ne sera pas transmis par ces nœuds durant les changements de topologie du réseau.

 	8.	Considérations sur la sécurité

Le présent document ne soulève aucun problème de sécurité qui ne soit déjà couvert dans la [RFC2328].

 	9.	Considérations relatives à l'IANA

Le bit T tel que défini dans la [RFC1583] pour la capacité de TOS de routeur est redéfini comme bit MT dans le présent document. L'IANA a alloué le bit MT comme défini au paragraphe 4.1.

De même, le champ TOS pour les LSA de routeur, les LSA sommaires, et les LSA externens à l'AS de type 5 et de type 7, comme définis dans la [RFC2328], est redéfini comme MT-ID au paragraphe 3.7.

L'IANA a créé un nouveau registre, "Valeurs d'identifiant de multi topologes OSPF", avec les allocations et politiques d'enregistrement mentionnées au paragraphe 3.7 de ce document.

 	10.	Références
 	10.1	Références normatives

[RFC1583]	Moy, J., "Spécification d'OSPFversion 2", mars 1994. (D.S., remplacée par la RFC 2328)

[RFC1793]	J. Moy, "Extension d'OSPF pour la prise en charge de circuits à la demande", avril 1995. (MàJ par RFC3883)
 
[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

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

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

[RFC3692]	T. Narten, "L'allocation de numéros expérimentaux et d'essai est considérée comme utile", janvier 2004. (BCP0082)

 	10.2	Références pour information

[RFC3137]	A. Retana et autres, "Annonce de routeur OSPF de bout", juin 2001. (Information ; remplacée par RFC6987)

[RFC5120]	T. Przygienda, N. Shen, N. Sheth, "M-ISIS : acheminement multi topologies (MT) de système intermédiaire à système intermédiaire (IS-IS)", février 2008. (P.S.)

 	Appendice A.	Remerciements

Les auteurs tiennent à remercier Scott Sturgess, Alvaro Retana, David Kushi, Yakov Rekhter, Tony Przygienda, et Naiming Shen de leurs commentaires sur ce document. Des remerciements particuliers pour Acee Lindem pour l'édition et pour Tom Henderson pour sa relecture attentive durant le dernier appel du groupe de travail OSPF.

 	Appendice B.	Formats de données OSPF

Le contenu de LSA défini dans la [RFC2328] est modifié pour introduire le MT-ID.

 	B.1	LSA de routeurs
Les LSA de routeur sont les LSA de type 1. Chaque routeur dans une zone génère une LSA de routeur. La LSA décrit l'état et le coût des liaisons  du routeur (c'est-à-dire, les interfaces) à la zone. Toutes les liaisons du routeur à la zone doivent être décrite dans une seule LSA de routeur. Pour les détails concernant la construction des LSA de routeur, voir le paragraphe  12.4.1 de la [RFC2328].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Age d'état de liaison        |     Options   |       1       |
+---------------+---------------+---------------+---------------+
|        Identifiant d'état de liaison                          |
+---------------+---------------+---------------+---------------+
|                     Routeur annonceur                        |
+---------------+---------------+---------------+---------------+
|              Numéro de séquence d'état de liaison             |
+---------------+---------------+---------------+---------------+
| Somme de contrôle de LS       |            longueur           |
+---------------+---------------+---------------+---------------+
|*|*|*|N|W|V|E|B|        0      |     Nombre de liaisons        |
+-+-+-+-+-+-+-+-+---------------+---------------+---------------+
|                        Identifiant de liaison                 |
+---------------+---------------+---------------+---------------+
|                        Données de liaison                     |
+---------------+---------------+---------------+---------------+
|     Type      |    N° MT-ID   |            Métrique           |
+---------------+---------------+---------------+---------------+
|     MT-ID     |       0       |      Métrique MT-ID           |
+---------------+---------------+---------------+---------------+
|                              ...                              |
+---------------+---------------+---------------+---------------+
|     MT-ID     |       0       |       Métrique MT-ID          |
+---------------+---------------+---------------+---------------+
|                         Identifant de liaison                 |
+---------------+---------------+---------------+---------------+
|                         Données de liaison                    |
+---------------+---------------+---------------+---------------+
|                              ...                              |

Figure 2 : Format de LSA de routeur

 	B.2	LSA de réseau
Les LSA de réseau sont les LSA de type 2. Une LSA de réseau est générée pour chaque réseau en diffusion et réseau multi accès non de diffusion (NBMA, Non-Broadcast Multi-Access) dans la zone qui prend en charge deux routeurs ou plus. La LSA de réseau est générée par le routeur désigné du réseau. La LSA décrit tous les routeurs rattachés au réseau, incluant le routeur désigné lui-même. Le champ Identifiant d'état de liaison de la LSA fait la liste des adresses d'interface IP du routeur désigné.

La distance du réseau à tous les routeurs rattachés est zéro. C'est pourquoi les champs de métrque n'ont pas besoin d'être spécifiés dans une LSA de réseau. Pour les détails concernant la construction des LSA de réseau, voir le paragraphe 12.4.2 de la [RFC2328].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Age d'état de liaison        |      Options  |      2        |
+---------------+---------------+---------------+---------------+
|        Identifiant d'état de liaison                          |
+---------------+---------------+---------------+---------------+
|                     Routeur annonceur                         |
+---------------+---------------+---------------+---------------+
|        Numéro de séquence d'état de liaison                   |
+---------------+---------------+---------------+---------------+
|    Somme de contrôle de LS    |           longueur            |
+---------------+---------------+---------------+---------------+
|                         Gabarit de réseau                     |
+---------------+---------------+---------------+---------------+
|                        Routeur rattaché                       |
+---------------+---------------+---------------+---------------+
|                              ...                              |

Figure 3 : Format de LSA de réseau

Noter que le LSA de réseau ne contient pas de champ MT-ID car le coût de réseau aux routeurs rattachés est 0 et le DR est partagé par toute les topologies.

 	B.3	LSA Sommaires
Les LSA sommaires sont les LSA de type 3 et 4. Ces LSA sont générées par les routeurs de bordure de zone. Les LSA sommaires décrivent les destinations inter zones. Pour les détails concernant la construction des LSA sommaires, voir le paragraphe 12.4.3 de la [RFC2328]. Les LSA sommaires de type 3 sont utilisées quand la destination est un réseau IP. Dans ce cas, le champ Identifiant d'état de liaison de la LSA est un numéro de réseau IP (si nécessaire, l'identifiant d'état de liaison peut aussi avoir un ou plusieurs des bits "hôte" du réseau établis ; voir les détails à l'Appendice E de la [RFC2328]). Quand la destination est un routeur de bordure d'AS, une LSA sommaire de type 4 est utilisée, et le champ Identifiant d'état de liaison est l'identifiant de routeur OSPF du routeur de frontière d'AS. (Pour voir pourquoi il est nécessaire d'annoncer la localisation de chaque ASBR, consulter le paragraphe 16.4 de la [RFC2328].) À part la différence du champ Identifiant d'état de liaison, le format des LSA sommaires de type 3 et 4 est identique.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Age d'état de liaison       |     Options   |    3 ou 4     |
+---------------+---------------+---------------+---------------+
|        Identifiant d'état de liaison                          |
+---------------+---------------+---------------+---------------+
|                     Routeur annonceur                         |
+---------------+---------------+---------------+---------------+
|                Numéro de séquence d'état de liaison           |
+---------------+---------------+---------------+---------------+
|   Somme de contrôle de LS     |           Longueur            |
+---------------+---------------+---------------+---------------+
|                    Gabarit de réseau                          |
+---------------+---------------+---------------+---------------+
|       0       |                  Métrique                     |
+---------------+---------------+---------------+---------------+
|     MT-ID     |         Métrique de MT-ID                     |
+---------------+---------------+---------------+---------------+
|                              ...                              |
+---------------+---------------+---------------+---------------+
|     MT-ID     |          Métrique de MT-ID                    |
+---------------+---------------+---------------+---------------+

Figure 4 : Format de LSA sommaire

 	B.4	LSA externes à l'AS
Les LSA externes à l'AS sont les LSA de type 5. Ces LSA sont générées par les routeurs de frontière d'AS, et décrivent les destinations externes à l'AS. Pour les détails concernant la construction des LSA externes à l'AS, voirle paragraphe 12.4.3 de la [RFC2328].

Les LSA externes à l'AS décrivent généralement une destination externe particulière. Pour ces LSA, le champ Identifiant d'état de liaison spécifie un numéro de réseau IP (si nécessaire, l'identifiant d'état de liaison peut aussi avoir un ou plusieurs des bits "hôte" du réseau établis ; voir les détails à l'Appendice E de la [RFC2328]). Les LSA externes à l'AS sont aussi utilisées pour décrire un chemin par défaut. Les chemins par défaut sont utilisés quand aucun chemin spécifique n'existe pour la destination. Quand il décrit un chemin par défaut, l'identifiant d'état de liaison est toujours réglé à la destination par défaut (0.0.0.0) et le gabarit de réseau est réglé à 0.0.0.0.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Age d'état de liaison       |     Options   |      5        |
+---------------+---------------+---------------+---------------+
|        Identifiant d'état de liaison                          |
+---------------+---------------+---------------+---------------+
|                     Routeur annonceur                         |
+---------------+---------------+---------------+---------------+
|                Numéro de séquence d'état de liaison           |
+---------------+---------------+---------------+---------------+
|  Somme de contrôle de LS      |           Longueur            |
+---------------+---------------+---------------+---------------+
|                    Gabarit de réseau                          |
+---------------+---------------+---------------+---------------+
|E|     0       |                  Métrique                     |
+-+-------------+---------------+---------------+---------------+
|                 Adresse de transmission                       |
+---------------+---------------+---------------+---------------+
|             Étiquette de chemin externe                       |
+---------------+---------------+---------------+---------------+
|E|    MT-ID    |            Métrique de MT-ID                  |
+-+-------------+---------------+---------------+---------------+
|                 Adresse de transmission                       |
+---------------+---------------+---------------+---------------+
|             Étiquette de chemin externe                       |
+---------------+---------------+---------------+---------------+
|                              ...                              |
+---------------+---------------+---------------+---------------+
|E|    MT-ID    |            Métrique de MT-ID                  |
+-+-------------+---------------+---------------+---------------+
|                 Adresse de transmission                       |
+---------------+---------------+---------------+---------------+
|             Étiquette de chemin externe                       |
+---------------+---------------+---------------+---------------+

Figure 5 : Format de LSA externe à l'AS

 	B.5	LSA externes à l'AS de type 7
Les LSA externes à l'AS de type 7 sont générées par les routeurs frontière d'AS locaux à une zone "pas si en bout que cela" (NSSA, Not-So-Stubby Area) et décrivent des destinations externes à l'AS. Les changements aux LSA externes à l'AS de type 7 sont identiques à ceux des LSA externes à l'AS (Appendice A.4.5 de la [RFC2328]). Pour les détails concernant la construction des LSA externes à l'AS de type 7, voir le paragraphe 2.4 de la [RFC3101].

 	Adresse des auteurs

Peter Psenak	Sina Mirtorabi	Abhay Roy	
Cisco Systems	Force10 Networks	Cisco Systems	
Mlynske Nivy 43	1440 McCarthy Blvd	170 West Tasman Drive	
821 09	Milpitas, CA  95035	San Jose, CA  95134	
Bratislava	USA	USA	
Slovakia	mél : sina@force10networks.com 	mél : akr@cisco.com 	
mél : ppsenak@cisco.com 			

Liem Nguyen	Padma Pillay-Esnault	
Cisco Systems	Cisco Systems	
170 West Tasman Drive	170 West Tasman Drive	
San Jose, CA  95134	San Jose, CA  95134	
USA	USA	
mél: lhnguyen@cisco.com 	mél : ppe@cisco.com 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

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

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST 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 encloses ne viole 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 la Internet Society.