Groupe de travail Réseau	H. Ould-Brahim, Nortel Networks
Request for Comments: 5543	D. Fedyk, Alcatel-Lucent
Catégorie : Sur la voie de la normalisation	Y. Rekhter, Juniper Networks
Traduction Claude Brière de L'Isle	mai 2009

Attribut Ingénierie du trafic de BGP

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet 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 connaître l’état de la 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) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Le présent document définit un nouvel attribut BGP, l'attribut Ingénierie du trafic, qui permet à BGP de porter des informations d'ingénierie du trafic.

La portée et l'applicabilité de cet attribut excluent actuellement son utilisation pour des informations qui ne sont pas d'accessibilité de VPN.
Table des matières
1. Introduction	1
2. Spécification des exigences	2
3. Attribut Ingénierie du trafic	2
4. Implications sur l'agrégation	3
5. Implications sur l'adaptabilité	3
6. Considérations relatives à l'IANA	3
7. Considérations sur la sécurité	4
8. Remerciements	4
9. Références	4
9.1 Références normatives	4
9.2 Références pour information	4
Adresse des auteurs	4

 	1.	Introduction

Dans certains cas (par exemple, des VPN de couche 1 (L1VPN, Layer-1 VPN) [RFC5195]) il peut être utile d'augmenter les informations d'accessibilité de VPN portées dans BGP avec des informations d'ingénierie du trafic.

Le présent document définit un nouvel attribut BGP, l'attribut Ingénierie du trafic, qui permet à BGP [RFC4271] de porter des informations d'ingénieriene du trafic.

La Section 4 de la [RFC5195] décrit un usage possible de cet attribut.

La portée et l'applicabilité de cet attribut exclut actuellement son utilisation pour les informations qui ne sont pas d'accessibilité de VPN.

Les procédures pour modifier l'attribut Ingénierie du trafic, quand on ré-annonce un chemin qui porte un tel attribut, sortent du domaine d'application de ce document.

 	2.	Spécification 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],.

 	3.	Attribut Ingénierie du trafic

L'attribut Ingénierie du trafic est un attribut BGP facultatif, non transitif.

Les informations portées dans cet attribut sont identiques à celles portées dans le descripteur de capacité de commutation d'interface, comme spécifié dans les [RFC4203] et [RFC5307].

L'attribut contient un ou plusieurs des champs suivants :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capac. commut.|  Codage       |           Réservé             |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 0          |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 1          |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 2          |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 3          |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 4          |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 5          |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 6          |
+---------------+---------------+---------------+---------------+
|        Bande passante maximum de LSP à la priorité 7          |
+---------------+---------------+---------------+---------------+
|        Informations spécifiques de capacité de commutation    |
|                           (variable)                          |
+---------------+---------------+---------------+---------------+

Le champ Capacité de commutation (Capac. commut.) contient une des valeurs spécifiées au paragraphe 3.1.1 de la [RFC3471].

Le champ Codage contient une des valeurs spécifiées au paragraphe 3.1.1 de la [RFC3471].

Le champ Réservé DEVRAIT être réglé à 0 à l'émission et DOIT être ignoré à réception.

Bande passante maximum de LSP (chemin de commutation d'étiquettes) est codé comme une liste de huit champs de 4  octets dans le format de virgule flottante de l'IEEE [IEEE], avec la priorité 0 en premier et la priorité 7 en dernier. Les unités sont des octets (pas des bits !) par seconde.

Le contenu du champ Informations spécifiques de capacité de commutation dépend de la valeur du champ Capacité de commutation.

Quand le champ Capacité de commutation est PSC-1, PSC-2, PSC-3, ou PSC-4, le champ Informations spécifiques de capacité de commutation inclut la bande passante minimum de LSP et la MTU d'interface.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Bande passante minimum de LSP                     |
+---------------+---------------+---------------+---------------+
|         MTU d'interface       |
+---------------+---------------+

La bande passante minimum de LSP est codée dans un champ de 4 octets dans le format de virgule flottante de l'IEEE. Les unités sont des octets (pas des bits !) par seconde. La MTU d'interface est codée comme un entier de 2 octets.

Quand le champ Capacité de commutation est à capacité de commutation de couche 2 (L2SCC, Layer-2 Switch Capable) il n'y a pas de champ Informations spécifiques de capacité de commutation présent.

Quans le champ Capacité de commutation est à capacité de multiplexage à division dans le temps (TDM, Time-Division-Multiplex) le champ Informations spécifiques de capacité de commutation inclut la bande passante minimum de LSP et une indication de si l'interface prend en charge la hiérarchie standard ou arbitraire de réseau optique synchrone/hiérarchie numérique synchrone (SONET/SDH, Synchronous Optical Network/Synchronous Digital Hierarchy).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Bande passante minimum de LSP                |
+---------------+---------------+---------------+---------------+
|   Indication  |
+---------------+

La bande passante minimum de LSP est codée dans un champ de 4 octets dans le format de virgule flottante de l'IEEE. Les unités sont des octets (pas des bits !) par seconde. L'indication de si l'interface prend en charge le SONET/SDH standard ou arbitraire est codée sur 1 octet. La valeur de cet octet est 0 si l'interface prend en charge le SONET/SDH standard, et 1 si l'interface prend en charge le SONET/SDH arbitraire.

Quand le champ Capacité de commutation est la capacité de commutation lambda (LSC, Lambda Switch Capable) il n'y a pas de champ Informations spécifiques de capacité de commutation présent.

 	4.	Implications sur l'agrégation

Les chemins qui portent l'attribut Ingénierie du trafic ont une sémantique supplémentaire qui pourrait affecter le comportement de transmission du trafic. Donc, ces chemins NE DEVRONT PAS être agrégés sauf si ils partagent des attributs Ingénierie du trafic identiques.

Construire l'attribut Ingénierie du trafic quand on agrège des chemins avec des attributs Ingénierie du trafic identiques suit les procédures de la [RFC4201].

 	5.	Implications sur l'adaptabilité

L'utilisation de l'attribut Ingénierie du trafic n'augmente pas le nombre de chemins, mais peut augmenter le nombre de messages BGP Update exigés pour distribuer les chemins, selon que ces chemins partagent ou non le même attribut BGP Ingénierie du trafic (voir ci-dessous).

Quand les chemins diffèrent autrement que par l'attribut Ingénierie du trafic (par exemple, diffèrent par l'ensemble de chemins cibles et/ou NEXT_HOP) l'utilisation de l'attribut Ingénierie du trafic n'a pas d'impact sur le nombre de messages BGP Update requis pour porter les chemins. Il n'y a pas non plus d'impact quand les chemins partagent toutes les autres informations d'attribut et ont un attribut Ingénierie du trafice agrégé ou identique. Quand les chemins partagent toutes les autres informations d'attribut et ont des attributs Ingénierie du trafic différents, les chemins doivent être distribués dans les messages BGP Update par chemin, plutôt que dans un seul message.

 	6.	Considérations relatives à l'IANA

Le présent document définit un nouvel attribut BGP, Ingénierie du trafic. Cet attribut est facultatif et non transitif.

 	7.	Considérations sur la sécurité

Cette extension à BGP ne change pas les problèmes de sécurité sous-jacents actuellement inhérents à BGP. Les considérations sur la sécurité de BGP sont discutées dans la RFC 4271.

 	8.	Remerciements

Les auteurs tiennent à remercier John Scudder et Jeffrey Haas de leur relecture et de leurs commentaires.

 	9.	Références
 	9.1	Références normatives

[IEEE]	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. (MàJ par RFC8174)

[RFC3471]	L. Berger, éd., "Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : description fonctionnelle de la signalisation", janvier 2003. (MàJ par RFC4201, RFC4328, RFC4872, RFC8359) (P.S.)

[RFC4201]	K. Kompella et autres, "Faisceaux de liaisons dans l'ingénierie du trafic MPLS", octobre 2005. (P.S.)

[RFC4271]	Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608, RFC8212, 9072)

 	9.2	Références pour information

[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.)

[RFC5195]	H. Ould-Brahim et autres, "Auto découverte fondée sur BGP pour VPN de couche 1", juin 2008. (P.S.)

[RFC5307]	K. Kompella et Y. Rekhter, éd., "Extensions IS-IS pour la prise en charge de la commutation multiprotocole avec étiquetage des flux généralisée (GMPLS)", octobre 2008. (MàJ RFC5305) (P.S.)

 	Adresse des auteurs

Hamid Ould-Brahim	Don Fedyk	Yakov Rekhter	
Nortel Networks	Alcatel-Lucent	Juniper Networks, Inc.	
mél : hbrahim@nortel.com	mél : donald.fedyk@alcatel-lucent.com	mél : yakov@juniper.net