Groupe de travail Réseau	K. Ishiguro, IP Infusion, Inc
Request for Comments : 5329	V. Manral, IP Infusion, Inc
Catégorie : Sur la voie de la normalisation	A. Davey, Data Connection Limited
	A. Lindem, Redback Networks
Traduction Claude Brière de L'Isle	septembre 2008

Extensions d’ingénierie du trafic à OSPF version 3

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 droits de reproduction
Copyright (C) The IETF Trust (2008).

Résumé
Le présent document décrit des extensions à OSPFv3 pour prendre en charge l’ingénierie de trafic intra-zone. Ce document étend OSPFv2 TE pour traiter les réseaux IPv6. Un nouveau TLV et plusieurs nouveaux sous TLV sont définis pour prendre en charge les réseaux IPv6.
Table des matières
1. Introduction	1
1.1 Notation des exigences	2
2. LSA TE intra zone	2
2.1 Charge utile de LSA TE intra zone	2
3. TLV Adresse IPv6 de routeur	3
4. TLV Liaison	3
4.1 Sous TLV Identifiant de liaison	3
4.2 Sous TLV Identifiant de voisin	4
4.3 Sous TLV Adresse IPv6 d’interface locale	4
4.4 Sous TLV Adresse IPv6 d’interface distante	5
5. Considérations sur la sécurité	5
6. Considérations de gestion	5
7. Considérations relatives à l’IANA	6
8. Références	6
8.1 Références normatives	6
8.2 Références pour information	6
Remerciements	7
Adresse des auteurs	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

OSPFv3 a un mécanisme très souple pour ajouter de nouveaux types de LS. Les types de LS inconnus sont arrosés de façon appropriée sur la base des bits de portée d‘arrosage dans le type de LS [RFC5340]. Ce document définit le LSA TE intra- zone pour OSPFv3.

Pour l’ingénierie du trafic, le présent document utilise les "Extensions d’ingénierie du trafic pour OSPF" [RFC3630] comme base des définitions de TLV. De nouveaux TLV et sous TLV sont ajoutés à la [RFC3630] pour étendre les capacités de TE aux réseaux IPv6. Certains TLV et sous TLV existants exigent des précisions pour l’applicabilité à OSPFv3.

GMPLS [RFC4203] et les extensions MPLS Diff-Serv [RFC3270] se fondent sur la [RFC3630]. Ces fonctions peuvent aussi être étendues à OSPFv3 en utilisant les TLV et sous TLV décrits dans le présent document.

 	1.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.	LSA TE intra zone

Un nouveau type de LS est défini pour le LSA TE intra zone. Il est différent de l’ingénierie du trafic OSPFv2 [RFC3630] où des LSA opaques sont utilisés pour annoncer les informations de TE [RFC5250]. Le code de fonction de LSA est 10, le bit U est établi, et la portée est réglée à 01 pour la portée de zone. Quand le bit U est réglé à 1, un routeur OSPFv3 doit arroser le LSA à sa portée d’arrosage définie même si il ne reconnaît pas le type de LS [RFC5340].

 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 de LS            |1|0|1|          10             |
+---------------+---------------+-+-+-+---------+---------------+
|             Identifiant d’état de liaison                     |
+---------------+---------------+---------------+---------------+
|                    Routeur annonceur                          |
+---------------+---------------+---------------+---------------+
|                Numéro de séquence de LS                       |
+---------------+---------------+---------------+---------------+
|  Somme de contrôle de LS      |            Longueur           |
+---------------+---------------+---------------+---------------+
|                                                               |
+-                            TLV                              -+
|                             ...                               |

LSA-TE OSPFv3 intra-zone

L’identifiant d’état de liaison d’un LSA TE intra zone est une valeur arbitraire utilisée pour maintenir plusieurs LSA d’ingénierie du trafic. L’identifiant d’état de liaison n’a pas de signification topologique.

Le format des TLV dans le corps d’un LSA TE intra zone est le même que le format utilisé par les extensions d’ingénierie du trafic à OSPF [RFC3630]. La charge utile de LSA consiste en un ou plusieurs triplets incorporés de Type/Longueur/Valeur (TLV). 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...                          |
+---------------+---------------+---------------+---------------+

Format de TLV 

Le champ Longueur définit la longueur de la portion valeur en octets (donc, un TLV sans portion Valeur va avoir une longueur de 0). Le TLV est bourré sur un alignement de 4 octets ; le bourrage n’est pas inclus dans le champ Longueur (donc une valeur de 3 octets aurait une longueur de 3, mais la taille totale du TLV serait de 8 octets). Les TLV incorporés sont aussi alignés sur 32 bits. Par exemple, une valeur de 1 octet aurait le champ Longueur réglé à 1, et 3 octets de bourrage seraient ajoutés à la fin de la portion Valeur du TLV. Les types non reconnus sont ignorés.

 	2.1	Charge utile de LSA TE intra zone
Un LSA TE intra zone contient un TLV de niveau supérieur. Il y a deux TLV de niveau supérieur applicables :
2 : TLV Liaison
3 : TLV Adresse IPv6 de routeur

 	3.	TLV Adresse IPv6 de routeur

Le TLV Adresse IPv6 de routeur annonce une adresse IPv6 accessible. C’est une adresse IPv6 stable qui DEVRAIT être accessible si il y a la connexité au routeur OSPFv3.

Le TLV Adresse IPv6 de routeur a le type 3, la longueur 16, et une valeur contenant une adresse IPv6 locale de 16 octets. Une adresse de liaison locale NE DOIT PAS être spécifiée pour ce TLV. Il DOIT apparaître dans exactement un LSA d’ingénierie du trafic généré par un routeur OSPFv3 qui prend cn charge les extensions TE. Le TLV Adresse IPv6 de routeur est un TLV de niveau supérieur comme défini dans "Extensions d’ingénierie du trafic à OSPF" [RFC3630], et un seul TLV de niveau supérieur peut être contenu dans un LSA.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              3                |            16                 |
+---------------+---------------+---------------+---------------+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+-+-+-+-           Adresse IPv6 de routeur               -+-+-+-+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+---------------+---------------+---------------+---------------+

Type  : un champ de 16 bits réglé à 3.
Longueur  : un champ de 16 bits qui indique la longueur de la portion valeur en octets. Pour ce TLV, c’est toujours 16.
Valeur  : une adresse IPv6 stable et acheminable.

TLV Adresse IPv6 de routeur

 	4.	TLV Liaison

Le TLV Liaison décrit une seule liaison et consiste en un ensemble de sous TLV [RFC3630]. Tous les sous TLV dans la [RFC3630] autres que le sous TLV Identifiant de liaison sont applicables à OSPFv3. Le sous TLV Identifiant de liaison ne peut pas être utilisé dans OSPFv3 car il est défini pour être utilisé par l’identification OSPFv2 du routeur désigné (DR) sur les réseaux multi-accès. Dans OSPFv2, les voisins sur les réseaux point à point et les liaisons virtuelles sont identifiés par leur identifiant de routeur tandis que les voisins sur les liaisons en diffusion, en multi accès sans diffusion (NBMA, Non-Broadcast Multi-Access) et en point à multipoints sont identifiées par leurs adresses d’interface IPv4 (voir le paragraphe 8.2 de la [RFC2328]). L’adresse d’interface IPv4 n’est pas connue de OSPFv3. À la différence de OSPFv2, OSPFv3 identifie toujours les routeurs du voisinage par leur identifiant de routeur (voir le paragraphe 2.11 de la [RFC5340]).

Trois nouveaux sous TLV sont définis pour le TLV Liaison :
18 – Identifiant de voisin (8 octets)
19 – Adresse IPv6 d’interface locale (16N octets, où N est le nombre d’adresses IPv6)
20 - Adresse IPv6 d’interface distante (16N octets, où N est le nombre d’adresses IPv6)

Le sous TLV Identifiant de voisin est obligatoire pour la prise en charge de l’ingénierie du trafic OSPFv3. Il DOIT apparaître exactement une fois dans un TLV Liaison. Tous les autres sous TLV définis dans le présent document NE DEVRAIENT PAS se produire plus d’une fois dans un TLV Liaison. Si un sous TLV est spécifié plus d’une fois, les instances suivantes de la première sont ignorées.

 	4.1	Sous TLV Identifiant de liaison
Le sous TLV Identifiant de liaison est utilisé dans OSPFv2 pour identifier l’autre extrémité de la liaison. Dans OSPFv3, le sous TLV Identifiant de liaison DOIT être utilisé pour l’identification de la liaison. Dans OSPFv3, le sous TLV Identifiant de liaison NE DEVRAIT PAS être envoyé et DOIT être ignoré à réception.

 	4.2	Sous TLV Identifiant de voisin
Dans OSPFv2, l’identifiant de liaison est utilisé pour identifier l’autre extrémité d’une liaison. Dans OSPFv3, la combinaison de l’identifiant d’interface de voisin et l’identifiant de routeur voisin est utilisée pour l’identification de la liaison voisine. Tous deux sont annoncés dans le sous TLV Identifiant de voisin.
Les valeurs d’identifiant d’interface de voisin et d’identifiant de routeur voisin sont les mêmes que décrites dans la [RFC5340], au paragraphe A.4.3 "LSA de routeurs".

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              18               |             8                 |
+---------------+---------------+---------------+---------------+
|             Identifiant d’interface de voisin                 |
+---------------+---------------+---------------+---------------+
|             Identifiant de routeur voisin                     |
+---------------+---------------+---------------+---------------+

Type  : un champ de 16 bits réglé à 18.
Longueur  : un champ de 16 bits indiquant la longueur de la portion Valeur en octets. Toujours 8 pour ce sous TLV.
Valeur  : Identifiant d’interface et identifiant de routeur du voisin.

Sous TLV Identifiant de voisin

 	4.3	Sous TLV Adresse IPv6 d’interface locale
Le sous TLV Adresse IPv6 d’interface locale spécifie la ou les adresses IPv6 de l’interface correspondant à cette liaison. Si il y a plusieurs adresses locales allouées à la liaison, elles PEUVENT alors être toutes mentionnées dans ce sous TLV. Les adresses de liaison locale NE DOIVENT PAS être incluses dans ce sous TLV.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              19               |            Longueur           |
+---------------+---------------+---------------+---------------+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+-+-+-+-         Adresse IPv6 d’interface locale         -+-+-+-+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+---------------+---------------+---------------+---------------+
|                         o                                     |
|                         o                                     |
|                         o                                     |
+---------------+---------------+---------------+---------------+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+-+-+-+-         Adresse IPv6 d’interface locale         -+-+-+-+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+---------------+---------------+---------------+---------------+

Type  : champ de 16 bits réglé à 19.
Longueur  : champ de 16 bits indiquant la longueur de la portion Valeur en octets. Pour ce sous TLV, il DOIT toujours être un multiple de 16 octets dépendant du nombre d’adresses IPv6 mondiales annoncé.
Valeur  : liste d’une ou plusieurs adresses IPv6 d’interface locale consommant 16 octets chacune.

Sous TLV Adresse IPv6 d’interface locale

 	4.4	Sous TLV Adresse IPv6 d’interface distante
Le sous TLV Adresse IPv6 d’interface distante annonce la ou les adresses IPv6 associées à l’interface de voisin. Ce sous TLV et le sous TLV Adresse IPv6 d’interface locale sont utilisés pour distinguer parmi les liaisons parallèles entre les routeurs OSPFv3. Si le type de liaison est multi-accès, l’adresse IPv6 d’interface distante PEUT être réglée à ::. Autrement, une mise en œuvre PEUT choisir de ne pas envoyer de sous TLV. Les adresses de liaison locale NE DOIVENT PAS être annoncées dans ce sous TLV. Les adresses de voisin annoncées dans les LSA de liaison avec une longueur de préfixe de 128 et le bit LA établi PEUVENT être annoncées.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              20               |            Longueur           |
+---------------+---------------+---------------+---------------+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+-+-+-+-         Adresse IPv6 d’interface distante       -+-+-+-+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+---------------+---------------+---------------+---------------+
|                         o                                     |
|                         o                                     |
|                         o                                     |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+-+-+-+-         Adresse IPv6 d’interface distante       -+-+-+-+
|                                                               |
+-+-+-+-                                                 -+-+-+-+
|                                                               |
+---------------+---------------+---------------+---------------+

Type  : champ de 16 bits réglé à 20.
Longueur  : champ de 16 bits qui indique la longueur de la portion Valeur en octets. Pour ce sous TLV, il DOIT être un multiple de 16 octets dépendant du nombre d’adresses IPv6 mondiales annoncées.
Valeur  : liste de longueur variable des adresses IPv6 d’interface distante.

Sous TLV Adresse IPv6 d’interface distante

 	5.	Considérations sur la sécurité

La fonction décrite dans le présent document ne crée pas de nouveau problème de sécurité pour le protocole OSPFv3. Les considérations de sécurité pour les protocole OSPFv3 de base [RFC5340] et l’ingénierie du trafic OSPFv2 [RFC3630] sont applicables à l’ingénierie du trafic OSPFv3.

 	6.	Considérations de gestion

L’interface de gestion normale pour les routeurs qui utilisent les nouvelles extensions à OSPF pour l’ingénierie du trafic intra zone est fondée sur le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Les objets de gestion supplémentaires pour les opérations et statistiques de configuration sont définies dans la [RFC5643], et une mise en œuvre des extensions définies dans le présent document DEVRAIT fournir les accroches ou l’instrumentation appropriées qui permettent aux objets de MIB d’être mis en œuvre.

Le variables de MIB suivantes ont été ajoutées à la MIB OSPFv3 pour la prise en charge de l’ingénierie du trafic :

ospfv3AreaTEEnabled  : cette variable TruthValue de MIB dans l’entrée du tableau ospfv3AreaEntry indique si l’annonce TE OSPFv3 pour les interfaces OSPFv3 est activée ou non pour la zone correspondante. La valeur par défaut est FAUX.

ospfv3IfTEDisabled  : cette variable TruthValue de MIB dans l’entrée du tableau ospfv3IfEntry indique si l’annonce TE OSPFv3 pour les interfaces OSPFv3 est désactivée ou non pour l’interface correspondante. Cette variable de MIB n’est applicable que si ospfv3AreaTEEnabled est VRAI pour la zone de l’interface. La valeur par défaut est FAUX.

 	7.	Considérations relatives à l’IANA

Les allocations suivantes de l’IANA ont été faites dans les registres existants :

1. Le code de fonction de type de LSA OSPFv3 10 a été alloué au LSA-TE intra-zone OSPFv3.

2. Le type de TLV Adresse IPv6 de routeur 3 a été alloué dans le registre existant des TLV TE OSPF.

3. Les sous TLV Identifiant de voisin (18), Adresse IPv6 d’interface locale (19), et Adresse IPv6 d’interface distante (20) ont été alloués dans le registre existant des sous TLV TE OSPF.

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

[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, 9355)

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

[RFC5340]	R. Coltun et autres, "OSPF pour IPv6", juillet 2008. (P.S. ; Remplace RFC2740  ; MàJ par RFC8362)

 	8.2	Références pour information

[RFC3270]	F. Le Faucheur et autres, "Prise en charge des services différenciés par la commutation d'étiquettes multi-protocoles (MPLS)", mai 2002. (P.S.)

[RFC4203]	K. Kompella et autres, "Extensions OSPF pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (MàJ RFC3630) (P.S.)

[RFC5250]	L. Berger et autres, "Option OSPF de LSA opaque", juillet 2008. (Remplace RFC2370) (P.S.)

[RFC5643]	D. Joyal, V. Manral, "Base de données d'informations de gestion pour OSPFv3 , août 2009. (P.S.)

 	Remerciements
Merci de leurs commentaires à Kireeti Kompella, Alex Zinin, Adrian Farrell, et Mach Chen.
Merci à Vijay K. Gurbani pour la fourniture de la révision de l’équipe générale de revue de zone (Gen-ART).
Merci à Rob Austein qui a assuré la révision de la direction de la sécurité (secdir).
Merci à Dan Romascanu pour la fourniture du texte des "Considérations sur la gestion" dans le cadre de la revue de l’IESG.
Merci à Dave Ward, Tim Polk, Jari Arkko, et Pasi Eronen pour leurs commentaires et les discussions pertinentes dans le contexte de la revue de l’IESG.
Le texte de la RFC a été produit avec l’outil xml2rfc de Marshall Rose.

 	Adresse des auteurs
Kunihiro Ishiguro	Acee Lindem	
IP Infusion, Inc.	Redback Networks	
1188 East Arques Avenue,	102 Carric Bend Court	
Sunnyvale, CA  94085	Cary, NC  27519	
USA	USA	
mél : kunihiro@ipinfusion.com	mél : acee@redback.com	

Vishwas Manral	Alan Davey	
IP Infusion, Inc	Data Connection Limited	
#41, Ground Floor, 5th Cross Road	100 Church Street	
8th Main Road	Enfield	
Vasanth Nagar, Bangalore  560052	EN2 6BQ	
India	UK	
mél : vishwas@ipinfusion.com	mél : Alan.Davey@dataconnection.com	

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

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 fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, 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 fourni par l'activité de soutien administratif de l'IETF (IASA).