Title: Groupe de travail Réseau

RFC3630	page - 2 -	Katz, Kompella & Yeung

Groupe de travail Réseau | D. Katz & K. Kompella, Juniper Networks
Request for Comments : 3630 | D. Yeung, Procket Networks
RFC mise à jour : 2370 | septembre 2003
Catégorie : En cours de normalisation | Traduction Claude Brière de L’Isle

Extensions d’ingénierie du trafic (TE) à OSPF version 2

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

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

Résumé
Le présent document décrit des extensions au protocole OSPF (Open Shortest Path First, plus court chemin ouvert en premier) version 2 pour la prise en charge de l’ingénierie de trafic (TE, traffic engineering) intra-zone, en utilisant des avis d’état de liaison (LSA, Link State Advertisement) opaques.

1.	Introduction

Le présent document spécifie une méthode d’ajout des capacités d’ingénierie du trafic à OSPF version 2 [RFC2328]. L’architecture de l’ingénierie du trafic est décrite dans la [RFC2702]. Le contenu sémantique des extensions est essentiellement identique à celui des extensions correspondantes à IS-IS [RFC3784]. On s’attend à ce que les extensions d’ingénierie du trafic OSPF continuent de refléter celles d’IS-IS.

Les extensions donnent le moyen de décrire la topologie d’ingénierie du trafic (y compris les contraintes de bande passante et administratives) et de distribuer ces information au sein d’une certaine zone OSPF. Cette topologie ne correspond pas nécessairement à la topologie d’acheminement régulier, bien que la présente proposition dépende des avis d’état de liaison (LSA) du réseau pour décrire les liaisons multi-accès. Le présent document reste délibérément muet sur la façon dont les mécanismes décrits ici peuvent être utilisés pour l’ingénierie du trafic à travers plusieurs zones OSPF ; cette tâche est laissée à des documents futurs. De plus, aucun changement n’a été fait au fonctionnement de l’arrosage OSPFv2 ; en particulier, si des nœuds sans capacité d’ingénierie du trafic existent dans la topologie, ils DOIVENT arroser les LSA TE comme tout autre LSA opaque de type 10 (portée de zone locale) (voir la [RFC2370]).

1.1	Applicabilité

Beaucoup des extensions spécifiées dans le présent document répondent à des exigences formulées dans la [RFC2702], et sont donc appelées "extensions d’ingénierie du trafic", et sont aussi couramment associées à l’ingénierie du trafic MPLS. Une désignation plus précise (bien que sans relief) est celle de "attributs de liaison étendus", car la proposition est simplement d’ajouter plus d’attributs aux liaisons dans les avis OSPF.

Les informations rendues disponibles par ces extensions peuvent être utilisées pour construire une base de données des états de liaison étendus tout comme les LSA de routeur sont utilisés pour construire une base de données des états de liaison "réguliers" ; la différence est que la base de données d’état de liaison étendus (qu’on appelle base de données d’ingénierie du trafic dans la suite de ce document) a des attributs de liaison supplémentaires. L’utilisation de la base de données d’ingénierie du trafic inclut :
o	de surveiller les attributs de liaison étendus ;
o	un acheminement local de source fondé sur la contrainte ; 
o	l’ingénierie globale du trafic.

Par exemple, un appareil à capacité OSPF peut participer à une zone OSPF, construire une base de données d’ingénierie du trafic, et par là faire des rapports sur l’état de réservation des liaisons dans cette zone.

Dans "l’acheminement local de source fondé sur la contrainte", un routeur R peut calculer un chemin d’un nœud source A à un nœud de destination B ; normalement, A est R lui-même, et B est spécifié par une "adresse de routeur" (voir ci-dessous). Ce chemin peut être soumis à diverses contraintes quant aux attributs des liaisons et nœuds que traverse le chemin, par exemple, utiliser des liaisons vertes qui aient une bande passante non réservée d’au moins 10 Mbit/s. Ce chemin pourrait alors être utilisé pour porter un sous-ensemble du trafic de A à B, formant un moyen simple mais efficace d’ingénierie du trafic. Comment est déterminé ce sous-ensemble du trafic, et comment est instancié le chemin, sortent du domaine d’application du présent document ; il suffit de dire qu’un des moyens de définir le sous-ensemble du trafic est "les paquets dont la destination IP a été apprise de B", et un des moyens d’instancier les chemins est d’utiliser des tunnels MPLS. De plus on notera que l’acheminement fondé sur la contrainte peut être "NP-hard", ou même insoluble, selon la nature des attributs et des contraintes, et donc de nombreuses mises en œuvre vont utiliser des heuristiques. Par conséquent, on ne tentera pas ici d’esquisser un algorithme.

Finalement, pour "l’ingénierie globale du trafic", un appareil peut construire une base de données d’ingénierie du trafic, entrer une matrice de trafic et une fonction d’optimisation, mouliner les informations, et ainsi calculer l’acheminement optimal ou presque optimal pour le réseau entier. L’appareil peut ensuite surveiller la topologie d’ingénierie du trafic et réagir aux changements en recalculant le chemins optimaux.

1.2	Limitations

Comme on l’a mentionné ci-dessus, le présent document spécifie des extensions et des procédures pour la distribution intra-zone des informations d’ingénierie du trafic. Les méthodes de distribution inter-zone et inter-système autonome (AS, Autonomous System) ne sont pas exposées ici.

Les extensions spécifiées dans le présent document capturent l’état de réservation de liaisons point à point. L’état de réservation des liaisons multi-accès peut n’être pas reflété de façon précise, sauf dans le cas particulier où il y a seulement deux appareils dans le sous-réseau multi-accès. Le fonctionnement sur des réseaux multi-accès avec plus de deux appareils n’est pas spécifiquement interdit. Une description plus précise de l’état de réservation des réseaux multi-accès fera l’objet d’études complémentaires.

Le présent document ne prend pas non plus en charge les liaisons non numérotées. Cette déficience sera réglée dans de futurs documents ; voir aussi les [RFC3477] et [RFC3480].

1.3	Conventions

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

2.	Format de LSA
2.1	Type de LSA

Cette extension utilise le LSA opaque [RFC2370].

Trois types de LSA opaques existent, dont chacun a une portée d’arrosage différente. La présente proposition utilise seulement les LSA de type 10, qui ont la zone pour portée d’arrosage.

Un nouveau LSA est défini, le LSA d’ingénierie du trafic. Ce LSA décrit les routeurs, les liaisons point à point, et les connexions à des réseaux multi-accès (similaires à des LSA routeurs). Pour les besoins de l’ingénierie du trafic, le LSA réseau existant est suffisant pour décrire les liaisons multi-accès, de sorte qu’aucun LSA supplémentaire n’est défini à cette fin.

2.2	Identifiant de LSA

L’identifiant de LSA d’un LSA opaque est défini comme ayant huit bits de données de type et 24 bits de données spécifiques du type. Le LSA d’ingénierie du trafic utilise le type 1. Les 24 bits restants sont le champ Instance, comme suit :

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |                   Instance                    |
   +---------------+---------------+---------------+---------------+

Le champ Instance est une valeur arbitraire utilisée pour maintenir plusieurs LSA d’ingénierie du trafic. Un maximum de 16 777 216 de LSA d’ingénierie du trafic peut être généré par un seul système. L’identifiant de LSA n’a pas de signification topologique.

2.3	Vue d’ensemble du format de LSA
2.3.1	En-tête de LSA
Le LSA d’ingénierie du trafic commence par l’en-tête de LSA standard :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           âge du LS           |    Options    |      10       |
   +---------------+---------------+---------------+---------------+
   |       1       |                   Instance                    |
   +---------------+---------------+---------------+---------------+
   |                     Routeur annonceur                         |
   +---------------+---------------+---------------+---------------+
   |                     Numéro de séquence LS                     |
   +---------------+---------------+---------------+---------------+
   |   Somme de contrôle LS        |             Longueur          |
   +---------------+---------------+---------------+---------------+

2.3.2	En-tête de TLV
La charge utile du LSA consiste en un ou plusieurs triplets Type/Longueur/Valeur (TLV) incorporés pour l’extensibilité. Le format de chaque TLV est :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Longueur          |
   +---------------+---------------+---------------+---------------+
   |                            Valeur..                           |
   .                                                               .
   .                                                               .
   .                                                               .
   +---------------+---------------+---------------+---------------+

Le champ Longueur définit la longueur de la portion valeur en octets (donc un TLV sans portion valeur aurait une longueur de zéro). Le TLV est bourré jusqu’à être aligné sur quatre octets ; le bourrage n’est pas inclus dans le champ de longueur (de sorte qu’une valeur de trois octets aura une longueur de trois, mais la taille totale du TLV sera de huit octets). Les TLV incorporés sont aussi alignés sur 32 bits. Les types non reconnus sont ignorés.

Le présent mémoire définit les types 1 et 2. Voir à la section "Considérations relatives à l’IANA" l’allocation des nouveaux types.

2.4	Détails de la charge utile de LSA

Un LSA contient un TLV de niveau supérieur.
Deux TLV de niveau supérieur sont définis :
1 – Adresse de routeur 
2 – Liaison

2.4.1	TLV Adresse de routeur
Le TLV Adresse de routeur spécifie une adresse IP stable du routeur annonceur, qui est toujours accessible si il y a la connexité avec elle ; ceci est normalement mis en œuvre comme une "adresse de bouclage". L’attribut clé est que l’adresse ne devient pas inutilisable si une interface est morte. Dans d’autres protocoles, ceci est appelé "l’identifiant de routeur", mais pour des raisons évidentes, cette dénomination est évitée ici. Si un routeur annonce des chemins BGP avec l’attribut de prochain bond BGP réglé à l’identifiant de routeur BGP, l’adresse de routeur DEVRAIT être la même que l’identifiant de routeur BGP.

Si IS-IS est aussi actif dans ce domaine, cette adresse peut aussi être utilisée pour calculer la transposition entre les topologies OSPF et IS-IS. Par exemple, supposons qu’un routeur R annonce à la fois des LSA d’ingénierie du trafic IS-IS et OSPF, et supposons de plus qu’un certain routeur S construit une seule base de données d’ingénierie du trafic (TED, Traffic Engineering Database) sur la base des deux informations IS-IS et OSPF TE. R peut alors apparaître comme deux nœuds séparés dans la TED de S. Cependant, si les LSA IS-IS et OSPF générés par R contiennent tous deux la même adresse de routeur, S peut alors déterminer que le LSA IS-IS TE et le LSA OSPF TE provenant de R proviennent en fait d’un seul routeur.

Le TLV adresse de routeur est du type 1, a une longueur de 4, et une valeur qui est l’adresse IP de quatre octets. Il doit apparaître dans exactement un LSA d’ingénierie du trafic généré par un routeur.

2.4.2	TLV Liaison
Le TLV Liaison décrit une seule liaison. Il est construit sur un ensemble de sous TLV. Il n’y a pas d’exigence d’ordre pour les sous TLV.

Un seul TLV Liaison devra être porté dans chaque LSA, permettant des changements de granularité fine dans la topologie.

Le TLV Liaison est du type 2, et sa longueur est variable.

Les sous TLV suivants du TLV Liaison sont définis :
1 – Type de liaison (1 octet)
2 – Identifiant de liaison (4 octets)
3 – Adresse IP d’interface locale (4 octets)
4 – Adresse IP d’interface distante (4 octets)
5 – Métrique d’ingénierie du trafic (4 octets)
6 – Bande passante maximum (4 octets)
7 – Bande passante maximum réservable (4 octets)
8 – Bande passante non réservée (32 octets)
9 – Groupe administratif (4 octets)

Le présent mémoire définit les sous types de 1 à 9. Voir à la Section “Considérations relatives à l’IANA” les allocations de nouveaux sous types.

Les sous TLV Type de liaison et Identifiant de liaison sont obligatoires, c’est-à-dire qu’ils doivent apparaître exactement une fois. Tous les autres sous TLV définis ici peuvent survenir au plus une fois. Ces restrictions n’ont pas besoin de s’appliquer aux sous TLV futurs. Les sous TLV non reconnus sont ignorés.

Les diverses valeurs ci-dessous utilisent le format de virgule flottante (à 32 bits) de l’IEEE. Pour une référence rapide, ce format est comme suit :

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|  Exposant   |                    Fraction                   |
   +-+-------------+---------------+---------------+---------------+

S est le signe, Exposant est l’exposant base 2 en notation "au delà de 127", et Fraction est la mantisse - 1, avec une virgule binaire implicite devant elle. Donc, ce qui est ci-dessus représente la valeur :

(-1)**(S) * 2**(Exposant-127) * (1 + Fraction)

Pour plus de détails, se référer à [4].

2.5	Détails de sous-TLV
2.5.1	Type de liaison
Le sous TLV Type de liaison définit le type de la liaison :
1 – Point à point
2 – Multi-accès

Le sous TLV Type de liaison est le TLV de type 1, et sa longueur est de un octet.

2.5.2	Identifiant de liaison
Le sous TLV Identifiant de liaison identifie l’autre extrémité de la liaison. Pour les liaisons point à point, c’est l’identifiant de routeur du voisin. Pour les liaisons multi-accès, c’est l’adresse de l’interface du routeur désigné. L’identifiant de liaison est identique au contenu du champ Identifiant de liaison dans le LSA routeur pour ces types de liaison.

Le sous TLV Identifiant de liaison est le TLV de type 2, et sa longueur est de quatre octets.

2.5.3	Adresse IP d’interface locale
Le sous TLV Adresse IP d’interface locale spécifie les adresses IP de l’interface qui correspond à cette liaison. Si il y a plusieurs adresses locales sur la liaison, elles sont toutes énumérées dans ce sous TLV.

Le sous TLV Adresse IP d’interface locale est un TLV de type 3, et sa longueur est de 4N octets, où N est le nombre d’adresses locales.

2.5.4	Adresse IP d’interface distante
Le sous TLV Adresse IP d’interface distante spécifie les adresses IP de l'interface du voisin qui correspond à cette liaison. Celle-ci et l’adresse locale sont utilisées pour discerner plusieurs liaisons parallèles entre les systèmes. Si le type de liaison de la liaison est multi-accès, l’adresse IP de l’interface distante est réglés à 0.0.0.0 ; autrement, une mise en œuvre PEUT choisir de ne pas envoyer ce sous TLV.

Le sous TLV Adresse IP d’interface distante est le TLV de type 4, et sa longueur est de 4N octets, où N est le nombre d’adresses de voisin.

2.5.5	Métrique d’ingénierie du trafic
Le sous TLV Métrique d’ingénierie du trafic spécifie la métrique de la liaison pour les besoins de l’ingénierie du trafic. Cette métrique peut être différente de la métrique de liaison OSPF standard. Normalement, cette métrique est allouée par un administrateur de réseau.

Le sous TLV Métrique d’ingénierie du trafic est le TLV de type 5, et sa longueur est de quatre octets.

2.5.6	Bande passante maximum
Le sous TLV Bande passante maximum spécifie la bande passante maximum qui peut être utilisée sur cette liaison, dans cette direction (du système qui génère le LSA à son voisin) en format de virgule flottante IEEE. C’est la vraie capacité de la liaison. L’unité est l’octet par seconde.

Le sous TLV Bande passante maximum est le TLV de type 6, et sa longueur est de quatre octets.

2.5.7	Bande passante réservable maximum
Le sous TLV Bande passante maximum réservable spécifie la bande passante maximum qui peut être réservée sur cette liaison, dans cette direction, en format de virgule flottante IEEE. Noter que ceci peut être supérieur à la bande passante maximum (auquel cas la liaison peut être sur souscrite). Ceci DEVRAIT être configurable par l’usager ; la valeur par défaut devrait être la bande passante maximum. L’unité est l’octet par seconde.

Le sous TLV Bande passante maximum réservable est TLV type 7, et sa longueur est de quatre octets.

2.5.8	Bande passante non réservée
Le sous TLV Bande passante non réservée spécifie la quantité de bande passante non encore réservée à chacun des huit niveaux de priorité dans le format de virgule flottante de l’IEEE. Les valeurs correspondent à la bande passante qui peut être réservée avec une priorité d’établissement de 0 à 7, arrangées en ordre croissant, la priorité 0 survenant au début du sous TLV, et la priorité 7 à la fin du sous TLV. Les valeurs initiales (avant toute réservation de bande passante) sont toutes réglées à la bande passante maximum réservable. Chaque valeur sera inférieure ou égale à la bande passante maximum réservable. L’unité est l’octet par seconde.

Le sous TLV Bande passante non réservée est le TLV de type 8, et sa longueur est de 32 octets.

2.5.9	Groupe administratif
Le sous TLV Groupe administratif contient un gabarit binaire de 4 octets alloué par l’administrateur de réseau. Chaque bit établi correspond à un groupe administratif alloué à l’interface. Une liaison peut appartenir à plusieurs groupes.

Par convention, le bit de moindre poids est appelé 'groupe 0', et le bit de plus fort poids est appelé 'groupe 31'.

Le groupe administratif est aussi appelé classe/couleur de ressource [RFC2702].

Le sous TLV Groupe administratif est le TLV de type 9, et sa longueur est de quatre octets.

3.	Éléments de procédure

Les routeurs devront générer des LSA d’ingénierie du trafic chaque fois que change le contenu du LSA, et chaque fois que c’est par ailleurs exigé par OSPF (un rafraîchissement de LSA, par exemple). Noter que cela ne signifie pas que chaque changement doive être immédiatement diffusé ; une mise en œuvre PEUT fixer des seuils (par exemple, un seuil de changement de bande passante) qui déclanchent un arrosage immédiat, et initient l’arrosage d’autres changements après un bref intervalle de temps. Dans tous les cas, la génération de LSA d’ingénierie du trafic DEVRAIT être limitée en débit au plus à chaque MinLSInterval [RFC2328], [RFC3480].

À réception d’un LSA d’ingénierie du trafic ou d’un LSA réseau changé (car ils sont utilisés dans les calculs d’ingénierie du trafic) le routeur devrait mettre à jour sa base de données d’ingénierie du trafic. Aucun autre calcul de plus court chemin en premier (SPF, Shortest Path First) ou autre calcul de chemin n’est nécessaire.

4.	Problèmes de compatibilité

Il ne devrait pas y avoir de problème d’interopérabilité avec les routeurs qui ne mettent pas en œuvre ces extensions, car les LSA opaques seront ignorés en silence.

Le résultat de la présence de routeurs qui ne mettent pas en œuvre ces extensions est que la topologie d’ingénierie du trafic va avoir des pièces manquantes. Cependant, si la topologie est connectée, les chemins à ingénierie du trafic peuvent tout de même être calculés et devraient fonctionner.

5.	Considérations pour la sécurité

Le présent document spécifie le contenu des LSA opaques dans OSPFv2. Comme les LSA opaques ne sont pas utilisés pour le calcul de SPF ou de l’acheminement normal, les extensions spécifiées ici n’affectent pas l’acheminement IP. Cependant, l’altération des LSA de TE peut avoir un effet sur les calculs d’ingénierie du trafic, et il est suggéré que tout mécanisme utilisé pour sécuriser la transmission des LSA OSPF normaux soit également appliqué à tous les LSA opaques, y compris les LSA de TE spécifiés ici.

Noter que les mécanismes des [RFC2328], [RFC3480] et [RFC2154] s’appliquent aux LSA opaques. Il est suggéré que tout futur mécanisme proposé pour la sécurisation/authentification des échanges de LSA OSPFv2 soit faite de façon suffisamment générale pour pouvoir être utilisée avec les LSA opaques.

6.	Considérations relatives à l’IANA

Le types de niveau supérieur dans un LSA TE, ainsi que les types pour les sous TLV pour chaque type de niveau supérieur, ont été enregistrés auprès de l’IANA, sauf indication contraire.

Voici les lignes directrices (en utilisant les termes définis dans la [RFC2434]) pour l’affectation des types de niveau supérieur dans les LSA TE :
o	les types dans la gamme 3 – 32 767 sont à affecter par action de normalisation ;
o	les types dans la gamme 32 768 - 32 777 sont pour usage expérimental ; il ne seront pas enregistrés par l’IANA, et NE DOIVENT PAS être mentionnés par les RFC ;
o	les types dans la gamme 32 778 - 65 535 ne sont pas à affecter pour l’instant. Avant qu’une affectation puisse être effectuée dans cette gamme, il DOIT y avoir une RFC en cours de normalisation spécifiant des considérations relatives à l’IANA qui couvrent la gamme à affecter.

Les lignes directrices pour l’affectation des types pour les sous TLV dans un LSA TE sont comme suit :
o	les types dans la gamme 10 - 32767 sont à affecter par action de normalisation ;
o	les types dans la gamme 32 768 - 32 777 sont pour usage expérimental ; il ne seront pas enregistrés par l’NA, et NE DOIVENT PAS être mentionnés par les RFC ;
o	les types dans la gamme 32 778 - 65 535 ne sont pas à affecter pour l’instant. Avant qu’une affectation puisse être effectuée dans cette gamme, il DOIT y avoir une RFC en cours de normalisation spécifiant des considérations relatives à l’IANA qui couvrent la gamme à affecter.

7.	Déclaration de droits de propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’IETF au sujet des droits dans les documents en cours de normalisation et se rapportant aux normes figurent dans le BCP 11.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, brevet ou applications de brevets, ou autres droits de propriété qui pourraient recouvrir la technologie qui pourrait être nécessaire pour mettre en œuvre la présente norme. Prière d’adresser les informations au directeur exécutif de l’IETF.

8.	Références
8.1	Références normatives

[IEEE]	"IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8).

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

[RFC2328]	J. Moy, "OSPF version 2", STD 54, avril 1998.

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

8.2	Références pour information

[RFC2154]	S. Murphy, M. Badger et B. Wellington, "OSPF avec des signatures numériques", juin 1997.

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)

[RFC2702]	D. Awduche et autres, "Exigences d'ingénierie du trafic sur MPLS", septembre 1999. (Information)

[RFC3477]	K. Kompella, Y. Rekhter, "Signalisation des liaisons non numérotées dans le protocole de réservation de ressource – ingénierie du trafic (RSVP-TE)", janvier 2003. (P.S.)

[RFC3480]	K. Kompella, Y. Rekhter, A. Kullberg, "Signalisation des liaisons non numérotées dans le protocole de distribution d'étiquettes acheminées sur la base des contraintes de signalisation (CR-LDP)", février 2003.

[RFC3784]	H. Smit, T. Li, "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour l'ingénierie du trafic (TE)", juin 2004. (Obsolète, voir RFC5305) (Information)

9.	Adresse des auteurs

Dave Katz | Derek M. Yeung | Kireeti Kompella
Juniper Networks | Procket Networks, Inc. | Juniper Networks
1194 N. Mathilda Ave. | 1100 Cadillac Court | 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 USA | Milpitas, CA 95035 USA | Sunnyvale, CA 94089 USA
téléphone : +1 408 745 2000 | téléphone : +1 408 635-7900 | téléphone : +1 408 745 2000
mél : dkatz@juniper.net | mél : myeung@procket.com | mél : kireeti@juniper.net

10.	Déclaration complète de droits de reproduction

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent et paragraphe soient inclus dans toutes ces copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

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

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