Extensions de protocole pour la prise en charge de l'ingénierie de trafic à capacité Diffserv

Statut de ce mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour 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 copyright

Copyright (C) The Internet Society (2005).

Résumé

Le présent document spécifie les extensions de protocole pour la prise en charge de l'ingénierie de trafic MPLS à capacité de différenciation de service (DS-TE, Diffserv-aware MPLS Traffic Engineering). Cela inclut la généralisation de la sémantique d'un certain nombre d'extensions du protocole de passerelle intérieure (IGP, Interior Gateway Protocol) déjà définies pour l'ingénierie du trafic MPLS existante dans les RFC 3630, RFC 3784, et d'autres extensions à IGP au delà de celles-là. Cela inclut aussi des extensions à la signalisation RSVP-TE au delà de celles déjà spécifiées dans la RFC 3209 pour l'ingénierie du trafic MPLS existante. Ces extensions répondent aux exigences pour DS-TE invoquées dans la RFC 3564.

1. Introduction

La [RFC3564] présente les exigences des fournisseurs de service pour la prise en charge de l'ingénierie du trafic MPLS à capacité de services différenciés (DS-TE, Differentiated-Service (Diffserv)-aware MPLS Traffic Engineering). Cela inclut l'exigence fondamentale d'être capable d'appliquer différentes contraintes de bande passante pour les différentes classes de trafic.

Le présent document spécifie les extensions de signalisation IGP et RSVP-TE (au delà de celles déjà spécifiées pour l'ingénierie de trafic MPLS existante [RFC3630], [RFC3784], [RFC3209]) pour la prise en charge des exigences DS-TE invoquées dans la [RFC3564] incluant les environnements qui s'appuient sur l'acheminement réparti fondé sur la contrainte (par exemple, le calcul de chemin impliquant des routeurs de commutation d'étiquette d'extrémité de tête).

La [RFC3564] donne une définition et des exemples de modèles à contraintes de bande passante. Le présent document ne spécifie pas ni ne suppose un modèle de contraintes de bande passante particulier. Les modèles spécifiques de contraintes de bande passante sortent du domaine d'application du présent document. Bien que les extensions pour DS-TE spécifiées dans ce document puissent n'être pas suffisantes pour prendre en charge tous les modèles concevables de contraintes de bande passante, elles prennent en charge le modèle des poupées russes spécifié dans la [RFC4127], le modèle d'allocation maximum spécifié dans la [RFC4125], et le modèle d'allocation maximum avec réservation spécifié dans la [RFC4126].

Il peut y avoir des différences entre la qualité de service exprimée et obtenue avec Diffserv sans DS-TE et avec DS-TE. Parce que DS-TE utilise l'acheminement fondé sur la contrainte, et à cause du type de capacités de contrôle d'admission qu'il ajoute à Diffserv, DS-TE a des capacités de trafic que Diffserv n'a pas : Diffserv n'indique pas la préemption, délibérément, tandis que DS-TE décrit plusieurs niveaux de préemption pour ses types de classes. Aussi, Diffserv ne prend en charge aucun moyen de contrôler explicitement la sur réservation, alors que DS-TE le permet. Quand on considère un environnement complet de qualité de service, avec des routeurs Diffserv et DS-TE, il est important de veiller à prendre en compte ces différences.

1.1 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].

2. Auteurs contributeurs

Le présent document est le travail collectif de plusieurs auteurs. Le texte et le contenu ont été apportés par l'éditeur et les co-auteurs cités ci-dessous. (Les informations de contact de l'éditeur figurent à la fin du document.)

3. Définitions

Pour faciliter la lecture, un certain nombre de définitions de la [RFC3564] sont répétées ici :

Jonction de trafic (traffic trunk) : agrégation de flux de trafic de la même classe (c'est-à-dire, traités de façon équivalente du point de vue de DS-TE) qui est placée dans un chemin de commutation d'étiquettes (LSP, Label Switched Path).

Type de classe (CT, Class-Type) : ensemble de jonctions de trafic qui traversent une liaison gouvernée par un jeu spécifique de contraintes de bande passante. Le CT est utilisé pour l'allocation de la bande passante de la liaison, l'acheminement fondé sur la contrainte et le contrôle d'admission. Une certaine jonction de trafic appartient au même CT sur toutes les liaisons.

Classe TE : une paire de type et classe ou une priorité de préemption allouée pour cette classe-type. Cela signifie qu'un LSP qui transporte une jonction de trafic de cette classe-type peut utiliser cette priorité de préemption comme priorité à l'établissement, comme priorité de garde, ou les deux.

Les définitions d'un certain nombre de termes MPLS ne sont pas répétées ici. On les trouvera dans la [RFC3031].

4. Paramètres configurables

Cette Section ne discute que des différences avec les paramètres configurables pris en charge pour l'ingénierie du trafic MPLS selon les [RFC2702], [RFC3784], [RFC3630], et [RFC3209]. Tous les autres paramètres sont inchangés.

4.1 Paramètres de liaisons

4.1.1 Contraintes de bande passante (BC, Bandwidth Constraints)

La [RFC3564] déclare que "sans considération du modèle de contraintes de bande passante, la solution DS-TE DOIT permettre la prise en charge de jusqu'à 8 BC."

Pour DS-TE, le paramètre existant "Bande passante maximum de liaison réservable" est conservé, mais sa sémantique est généralisée et interprétée comme étant la contrainte de bande passante agrégée sur tous les classes-types, de façon que, indépendamment du modèle de contrainte de bande passante utilisé :

SOMME (Réservée (CTc)) ≤ Bande passante maximum réservable,

où la SOMME est sur toutes les valeurs de "c" dans la gamme 0 ≤ c ≤ 7.

De plus, sur chaque liaison, une mise en œuvre DS-TE DOIT assurer la configuration de jusqu'à 8 paramètres de liaison supplémentaires qui sont les huit BC potentiels, c'est-à-dire, BC0, BC1, ... BC7. Le LSR DOIT interpréter ces BC conformément au modèle de contraintes de bande passante pris en charge (c'est-à-dire, quel BC s'applique à quelle classe-type, et comment).

Lorsque le modèle de contraintes de bande passante impose des relations entre les valeurs à configurer pour ces BC, le LSR DOIT les appliquer au moment de la configuration. Par exemple, lorsque le modèle de contraintes de bande passante des poupées russes ([RFC4127]) est utilisé, le LSR DOIT s'assurer que BCi est configuré inférieur ou égal à BCj, où i est supérieur à j, et s'assurer que BC0 est égal à la bande passante maximum réservable. Dans un autre exemple, lorsque on utilise le modèle de l'allocation maximum ([RFC4125]) le LSR DOIT s'assurer que tous les BCi sont configurés inférieurs ou égaux à la bande passante maximum réservable.

4.1.2 Sur réservation

DS-TE permet à un administrateur de réseau d'appliquer des ratios de sur réservation (ou sous réservation) différents pour les différents CT.

Les méthodes principales pour réaliser cela sont les mêmes que celles utilisées historiquement dans les déploiements TE existants :

(i) Tenir compte du ratio approprié de sur/sous réservation approprié pour l'agrégat ordonné (OA, Ordered Aggregate) ou CT associé au LSP considéré au moment de l'établissement de la taille de la bande passante d'un certain LSP. On se réfère à cette méthode sous le nom de "méthode de sur réservation de taille de LSP". ET/OU,

(ii) de prendre en compte le ratio de sur/sous réservation au moment de la configuration de la bande passante maximum réservable/BC et d'utiliser les valeurs qui sont supérieures (sur réservation) ou inférieures (sous réservation) à celles acceptées en fait par la liaison. On appelle cette méthode la "méthode de sur réservation de taille de liaison".

Les méthodes de "sur réservation de taille de LSP" et de "sur réservation de taille de liaison" sont supposées être suffisantes dans de nombreux environnements DS-TE et n'exigent pas de paramètre configurable supplémentaire. D'autres méthodes de sur réservation peuvent impliquer de tels paramètres configurables supplémentaires, mais elles sortent du domaine d'application du présent document.

4.2 Paramètres de LSR

4.2.1 Transposition de TE à classe

Conformément à la [RFC3564], les attributs de préemption définis dans la [RFC2702] sont conservés avec DS-TE et applicable au sein, et à travers tous les CT. Les attributs de préemption de priorité d'établissement et de garde conservent leur sémantique existante, et en particulier cette sémantique n'est pas affectée par le CT de LSP. Cela signifie que si le LSP1 est en compétition avec le LSP2 pour des ressources, le LSP1 peut préempter le LSP2 si le LSP1 a une priorité de préemption supérieure (c'est-à-dire, une valeur numérique de priorité inférieure) à la priorité de préemption de garde que le LSP2, sans considération du CT du LSP1 et du CT du LSP2.

Les LSR DS-TE DOIVENT permettre la configuration d'une transposition de classe TE par laquelle le classe-type et le niveau de préemption sont configurés pour chacune des (jusqu'à) 8 classes de TE.

Cette transposition est désignée comme : TE-Class[i] <--> < CTc , préemption p >

où 0 ≤ i ≤ 7, 0 ≤ c ≤ 7, 0 ≤ p ≤ 7

Deux classes de TE NE DOIVENT PAS être identiques (c'est-à-dire, avoir le même classe-type et la même priorité de préemption).

Il n'y a pas d'autre restriction sur la façon dont un des 8 classes-types peuvent être appariés avec une des 8 priorités de préemption pour former une classe TE. En particulier, une certaine priorité de préemption peut être appariée avec deux (ou plus) différentes classes-types pour former deux (ou plus) classes de TE. De même, une classe-type peut être appariée avec deux (ou plus) différentes priorités de préemption pour former deux (ou plus) classes de TE. Aussi, il n'y a pas de relation d'ordre obligatoire entre l'indice de classe de TE (c'est-à-dire, le "i" ci-dessus) et la classe-type (c'est-à-dire, le "c" ci-dessus) ou la priorité de préemption (c'est-à-dire, le "p" ci-dessus) de la classe de TE.

Lorsque l'administrateur de réseau utilise moins de huit classes de TE, le LSR DS-TE DOIT permettre que celles qui restent soient configurées comme "Inutilisées". Noter que configurer toutes les 8 classes de TE comme "Inutilisées" équivaut effectivement à désactiver TE/DS-TE car aucun LSP TE/DS-TE ne peut être établi (ni même configuré, car comme décrit au paragraphe 4.3.3, la CT et les priorités de préemption configurées pour un LSP DOIVENT former une des classes de TE configurées).

Pour assurer un fonctionnement DS-TE cohérent, l'administrateur de réseau DOIT configurer exactement la même transposition de classe de TE sur tous les LSR du domaine DS-TE.

Lorsque la transposition de classe de TE doit être modifiée dans le domaine DS-TE, il faut faire attention durant la période transitoire de reconfiguration pendant laquelle des LSR DS-TE peuvent être configurés avec la nouvelle transposition de classe de TE tandis que d'autres sont encore configurés avec l'ancienne. Il est recommandé que les tunnels actifs n'utilisent aucune des classes de TE en cours de modification durant une telle période transitoire de reconfiguration.

4.3 Paramètres de LSP

4.3.1 Type de classe

Avec DS-TE, les LSR DOIVENT prendre en charge, pour chaque LSP, un paramètre configurable supplémentaire qui indique le classe-type de la jonction de trafic transportée par le LSP.

Il y a un, et un seul, classe-type configuré par LSP.

Le classe-type configuré indique, conformément au modèle de contraintes de bande passante pris en charge, les BC qui DOIVENT être appliquées pour ce LSP.

4.3.2 Priorités de préemption d'établissement et de mise en garde

Comme avec la TE existante, les LSR DS-TE DOIVENT permettre à chaque LSP DS-TE d'être configuré avec une priorité d'établissement et de garde, chacune d'une valeur entre 0 et 7.

4.3.3 Relations entre type de classe et préemption

Avec DS-TE, la priorité de préemption configurée avec la priorité d'établissement d'un certain LSP et le classe-type configuré pour ce LSP DOIVENT être tels que, ensemble, ils forment une des (jusqu'à) 8 classes de TE configurées dans la transposition de classe de TE spécifiée au paragraphe 4.2.1.

La priorité de préemption configurée pour la priorité de garde d'un certain LSP et le classe-type configurés pour ce LSP DOIVENT aussi être tels que, ensemble, ils forment une des (jusqu'à) 8 classes de TE configurées dans la transposition de classe de TE spécifiée au paragraphe 4.2.1.

Le LSR DOIT appliquer ces deux règles au moment de la configuration.

4.4 Exemples de configuration de paramètres

Pour illustrer le propos, voici quelques exemples de la façon d'utiliser ces paramètres configurables. Tous ces exemples supposent que des BC différentes doivent être appliquées pour des ensembles différents de jonctions de trafic (par exemple, pour la voix et pour les données) de sorte que deux classes-types ou plus doivent être utilisés.

4.4.1 Exemple 1

L'administrateur de réseau d'un premier réseau utilisant deux CT (CT1 pour la voix et CT0 pour les données) peut choisir de configurer la transposition de classe de TE suivante pour s'assurer que les LSP vocaux ne sont jamais écartés de leur plus court chemin à cause de LSP de données :

TE-Class[0] <--> < CT1 , préemption 0 >

TE-Class[1] <--> < CT0 , préemption 1 >

TE-Class[i] <--> inutilisé, pour 2 ≤ i ≤ 7

Les LSP vocaux seraient alors configurés avec : CT = CT1, priorité d'établissement = 0, priorité de garde = 0

Les LSP de données seraient alors configurés avec : CT = CT0, priorité d'établissement = 1, priorité de garde = 1

Un nouveau LSP vocal va alors être capable de préempter un LSP de données existant en cas de concurrence pour les ressources. Un LSP de données ne va jamais préempter un LSP vocal. Un LSP vocal ne va jamais préempter un autre LSP vocal. Un LSP de données ne va jamais préempter un autre LSP de données.

4.4.2 Exemple 2

L'administrateur de réseau d'un autre réseau peut choisir de configurer la transposition de classe de TE suivante afin d'optimiser l'utilisation globale du réseau en favorisant le placement de grands LSP au plus proche de leur plus court chemin :

TE-Class[0] <--> < CT1 , préemption 0 >

TE-Class[1] <--> < CT0 , préemption 1 >

TE-Class[2] <--> < CT1 , préemption 2 >

TE-Class[3] <--> < CT0 , préemption 3 >

TE-Class[i] <--> inutilisé, pour 4 ≤ i ≤ 7

Les LSP vocaux de grande taille pourraient être configurés avec :

CT = CT1, priorité d'établissement = 0, priorité de garde = 0

Les LSP de données de grande taille pourraient être configurés avec :

CT = CT0, priorité d'établissement = 1, priorité de garde = 1

Les LSP vocaux de petite taille pourraient être configurés avec :

CT = CT1, priorité d'établissement = 2, priorité de garde = 2

Les LSP de données de petite taille pourraient être configurés avec :

CT = CT0, priorité d'établissement = 3, priorité de garde = 3

Un nouveau LSP vocal de grande taille serait alors capable de préempter un LSP vocal de petite taille ou tout LSP de données en cas de concurrence pour les ressources. Un nouveau LSP de données de grande taille serait alors capable de préempter un LSP de données de petite taille ou un LSP vocal de petite taille si ils se trouvaient en concurrence pour les ressources, mais il ne serait pas capable de préempter un LSP vocal de grande taille.

4.4.3 Exemple 3

L'administrateur de réseau d'un autre réseau peut choisir de configurer la transposition de classe de TE suivante afin de s'assurer que les LSP vocaux ne sont jamais sortis de leur plus court chemin à cause de LSP de données. Cela aussi réalise une certaine optimisation de l'utilisation globale des ressources du réseau en favorisant le placement des grands LSP plus près de leur plus court chemin :

TE-Class[0] <--> < CT1 , préemption 0 >

TE-Class[1] <--> < CT1 , préemption 1 >

TE-Class[2] <--> < CT0 , préemption 2 >

TE-Class[3] <--> < CT0 , préemption 3 >

TE-Class[i] <--> inutilisé, pour 4 ≤ i ≤ 7

Les LSP vocaux de grande taille pourraient être configurés avec :

CT = CT1, priorité d'établissement = 0, priorité de garde = 0.

Les LSP vocaux de petite taille pourraient être configurés avec :

CT = CT1, priorité d'établissement = 1, priorité de garde = 1.

Les LSP de données de grande taille pourraient être configurés avec :

CT = CT0, priorité d'établissement = 2, priorité de garde = 2.

Les LSP de données de petite taille pourraient être configurés avec :

CT=CT0, priorité d'établissement = 3, priorité de garde = 3.

Un LSP vocal pourrait préempter un LSP de données si ils étaient en concurrence pour les ressources. Un LSP de données ne pourrait jamais préempter un LSP vocal. Un LSP vocal de grande taille pourrait préempter un LSP vocal de petite taille si ils sont en concurrence pour les ressources. Un LSP de données de grande taille pourrait préempter un LSP de données de petite taille si ils sont en concurrence pour les ressources.

4.4.4 Exemple 4

L'administrateur de réseau d'un autre réseau peut choisir de configurer la transposition de classe de TE suivante afin de s'assurer qu'aucune préemption ne survient dans le domaine DS-TE :

TE-Class[0] <--> < CT1 , préemption 0 >

TE-Class[1] <--> < CT0 , préemption 0 >

TE-Class[i] <--> inutilisé, pour 2 <= i <= 7

Les LSP vocaux seraient alors configurés avec : CT = CT1, priorité d'établissement =0, priorité de garde = 0

Les LSP de données seraient alors configurés avec : CT = CT0, priorité d'établissement = 0, priorité de garde = 0

Aucun LSP ne serait alors capable de préempter un autre LSP.

4.4.5 Exemple 5

L'administrateur de réseau d'un autre réseau peut choisir de configurer la transposition de classe de TE suivante afin d'augmenter la stabilité du réseau par une utilisation plus limitée de la préemption :

TE-Class[0] <--> < CT1 , préemption 0 >

TE-Class[1] <--> < CT1 , préemption 1 >

TE-Class[2] <--> < CT0 , préemption 1 >

TE-Class[3] <--> < CT0 , préemption 2 >

TE-Class[i] <--> inutilisé, pour 4 ≤ i ≤ 7

Les LSP vocaux de grande taille pourraient être configurés avec :

CT = CT1, priorité d'établissement = 0, priorité de garde = 0.

Les LSP vocaux de petite taille pourraient être configurés avec :

CT = CT1, priorité d'établissement = 1, priorité de garde = 0.

Les LSP de données de grande taille pourraient être configurés avec :

CT = CT0, priorité d'établissement = 2, priorité de garde = 1.

Les LSP de données de petite taille pourraient être configurés avec :

CT = CT0, priorité d'établissement = 2, priorité de garde = 2.

Un nouveau LSP vocal de grande taille serait capable de préempter un LSP de données en cas de concurrence pour les ressources, mais il ne serait pas capable de préempter un LSP vocal, même de petite taille.

Un nouveau LSP vocal de petite taille serait capable de préempter un LSP de données de petite taille en cas de concurrence pour les ressources, mais il ne serait pas capable de préempter un LSP de données de grande taille ou un LSP vocal.

Un LSP de données ne serait pas capable de préempter un autre LSP.

5. Extensions IGP pour DS-TE

Cette section ne discute que des différences avec les annonces IGP prises en charge pour l'ingénierie de trafic MPLS (agrégé) selon les [RFC3630] et [RFC3784]. Le reste de l'annonce IGP est inchangé.

5.1 Contraintes de bande passante

Comme précisé au paragraphe 4.1.1, jusqu'à 8 BC (BCb, 0 ≤ b ≤ 7) sont configurables sur toute liaison.

Avec DS-TE, le sous TLV existant "Bande passante maximum réservable" ([RFC3630], [RFC3784]) est conservé avec une sémantique généralisée de sorte qu'il DOIT maintenant être interprété comme la contrainte de bande passante agrégée à travers toutes les classes-types; c'est-à-dire, SOMME ((CTc) réservé) ≤ Bande passante maximum réservable, indépendamment du modèle de contraintes de bande passante.

Le présent document définit aussi les nouveaux sous TLV facultatifs suivants pour annoncer les huit BC potentiels (BC0 à BC7) :

Sous TLV "Contraintes de bande passante" :

- Identifiant de modèle de contraintes de bande passante (1 octet)

- Réservé (3 octets)

- Contraintes de bande passante (N x 4 octets)

Où :

- avec OSPF, le sous TLV est un sous TLV du "TLV de liaison" et son type de sous TLV est 17.

- avec ISIS, le sous TLV est un sous TLV du "TLV Accessibilité IS étendue" et son type de sous TLV est 22.

- Identifiant de modèle de contraintes de bande passante : identifiant de un octet pour le modèle de contraintes de bande passante actuellement utilisé par le LSR qui initie l'annonce IGP. Voir à la section "Considérations relatives à l'IANA" l'allocation des valeurs dans cet espace de noms.

- Réservé : champ de 3 octets. Ce champ devrait être réglé à zéro par le LSR qui génère le sous TLV et devrait être ignoré par le LSR qui reçoit le sous TLV.

- Contraintes de bande passante : contient BC0, BC1,... BC(N-1). Chaque BC est codé sur 32 bits en format de virgule flottante IEEE. Les unités sont des octets (pas des bits !) par seconde. Lorsque la transposition de classe de TE et le modèle de contraintes de bande passante configurés utilisés sont tels que BCh+1, BCh+2, ...et BC7 ne conviennent pour aucune des classes-types associés à une classe TE configurée, il est RECOMMANDÉ que seules les contraintes de bande passante de BC0 à BCh soient annoncées, afin de minimiser l'impact sur l'adaptabilité de IGP.

Toutes les règles pertinentes de codage générique de TLV (incluant le format de TLV, le bourrage et l'alignement, ainsi que le codage du format en virgule flottante IEEE) définies dans la [RFC3630] et la [RFC3784] sont applicables à ce nouveau sous TLV.

Le format du sous TLV "Contraintes de bande passante" est illustré 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ID modèle BC | Réservé |

+---------------+---------------+---------------+---------------+

| Valeur de BC0 |

+---------------+---------------+---------------+---------------+

// . . . //

+---------------+---------------+---------------+---------------+

| Valeur de BCh |

+---------------+---------------+---------------+---------------+

Un LSR DS-TE PEUT facultativement annoncer des BC.

Un LSR DS-TE, qui annonce des BC, DOIT utiliser le nouveau sous TLV "contraintes de bande passante" (en plus du sous TLV existant Bande passante maximum réservable) pour le faire. Par exemple, dans le cas où un fournisseur de services déploie DS-TE avec des classes TE associées seulement à CT0 et CT1, et où le modèle de contraintes de bande passante est tel que seuls BC0 et BC1 sont pertinents pour CT0 et CT1, un LSR DS-TE qui annonce les BC va inclure dans l'annonce IGP le sous TLV Bande passante maximum réservable, ainsi que le sous TLV "Contraintes de bande passante". Le premier devrait contenir la contrainte agrégée de bande passante sur tous les CT, et le dernier devrait contenir BC0 et BC1.

Un LSR DS-TE qui reçoit le sous TLV "Contraintes de bande passante" avec un identifiant de modèle de contraintes de bande passante qui ne correspond pas au modèle de contraintes de bande passante qu'il utilise actuellement DEVRAIT générer un avertissement à l'opérateur/système de gestion, rapportant l'incohérence entre les modèles de contraintes de bande passante utilisés sur les différentes liaisons. Aussi, dans ce cas, si le LSR DS-TE ne prend pas en charge le modèle de contraintes de bande passante désigné par l'identifiant de modèle de contraintes de bande passante, ou si le LSR DS-TE ne prend pas en charge des opérations avec plusieurs modèles de contraintes de bande passante simultanés, le LSR DS-TE PEUT éliminer le TLV correspondant. Si le LSR DS-TE ne prend pas en charge le modèle de contraintes de bande passante désigné par l'identifiant de modèle de contraintes de bande passante, et si le LSR DS-TE ne prend pas en charge les opérations avec plusieurs modèles de contraintes de bande passante simultanés, le LSR DS-TE PEUT accepter le TLV correspondant et permettre les opérations avec les différents modèles de contraintes de bande passante utilisés dans les différentes parties du domaine DS-TE.

5.2 Bande passante non réservée

Avec DS-TE, le sous TLV existant "Bande passante non réservée" est conservé comme seul véhicule pour annoncer les informations de bande passante dynamique nécessaire pour l'acheminement fondé sur la contrainte sur les extrémités de tête, sauf que ceci est utilisé avec une sémantique généralisée. Le sous TLV Bande passante non réservée porte encore huit valeurs de bande passante, mais elles correspondent maintenant à la bande passante non réservée pour chaque classe TE (au lieu de chaque priorité de préemption, selon la TE existante).

Plus précisément, un LSR DS-TE DOIT prendre en charge le sous TLV Bande passante non réservée avec une définition qui est généralisée de la façon suivante :

Le sous TLV Bande passante non réservée spécifie la quantité de bande passante non encore réservée pour chacune des huit classes TE, dans le format de virgule flottante IEEE, arrangées en ordre croissant d'indice de classe TE. La bande passante non réservée pour la classe TE [0] se présente au début du sous TLV, et la bande passante non réservée pour la classe TE [7] à la fin du sous TLV. La valeur de bande passante non réservée pour la classe TE [i] ( 0 ≤ i ≤ 7) est appelée la "classe TE non réservée [i]". Elle indique la bande passante disponible pour réservation, à un LSP qui :

- transporte une jonction de trafic du classe-type de TE-Classe[i], et

- a une priorité d'établissement correspondant à la priorité de préemption de TE-Classe[i].

Les unités sont des octets par seconde.

Parce que les valeurs de bande passante sont maintenant ordonnées par indice de classe TE et peuvent donc se rapporter aux différents CT avec les différents BC et à toute priorité de préemption arbitraire, un LSR DS-TE NE DOIT PAS supposer de relation ordonnée parmi ces valeurs de bande passante.

Avec la TE existante, parce que toutes les priorités de préemption reflètent les mêmes BC (et seulement eux) et que les valeurs de bande passante sont annoncées dans l'ordre de priorité de préemption, la relation suivante est toujours vraie, et est souvent supposée par les mises en œuvre de TE :

Si i < j, alors "Bande passante non réservée [i]" ≥ "Bande passante non réservée [j]"

Avec DS-TE, aucune relation ne peut être supposée telle que :

Si i < j, alors toute relation parmi les suivantes peut être vraie :

"Classe TE non réservée [i]" = "Classe TE non réservée [j]"

OU

"Classe TE non réservée [i]" > "Classe TE non réservée [j]"

OU

"Classe TE non réservée [i]" < "Classe TE non réservée [j]".

Les règles de calcul de "Classe TE non réservée [i]" sont spécifiées à la Section 11.

Si la classe TE [i] n'est pas utilisée, la valeur annoncée par l'IGP dans "Classe TE non réservée [i]" DOIT être réglée à zéro par le LSR qui génère l'annonce IGP, et DOIT être ignorée par le LSR qui reçoit l'annonce IGP.

6. Extensions RSVP-TE pour DS-TE

Dans cette section, on décrit les extensions à RSVP-TE pour la prise en charge de l'ingénierie de trafic MPLS à capacité Diffserv. Ces extensions s'ajoutent aux extensions à RSVP définies dans la [RFC3209] pour la prise en charge de l'ingénierie de trafic MPLS (agrégée) et aux extensions à RSVP définies dans la [RFC3270] pour la prise en charge de Diffserv sur MPLS.

6.1 Format de messages RSVP en relation avec DS-TE

Un nouvel objet RSVP est défini dans le présent document : l'objet CLASSTYPE. Une description détaillée de cet objet est donnée ci-dessous. Ce nouvel objet est applicable aux messages Path. La présente spécification définit seulement l'utilisation de l'objet CLASSTYPE dans les messages Path utilisés pour établir des tunnels LSP conformément à la [RFC3209] et contenant donc un objet Session avec un CT égal à LSP_TUNNEL_IPv4 et contenant un objet LABEL_REQUEST (demande d'étiquette).

Les restrictions définies dans la [RFC3209] pour la prise en charge de l'établissement de tunnels LSP via RSVP-TE sont aussi applicables à l'établissement de tunnels LSP qui prennent en charge DS-TE. Par exemple, seuls les LSP en envoi individuel sont acceptés, et les LSP en diffusion groupée feront d'objet d'études ultérieures.

Ce nouvel objet CLASSTYPE est facultatif par rapport à RSVP de sorte que les mises en œuvre générales de RSVP qui ne sont pas concernées par l'établissement de LSP MPLS n'ont pas à prendre cet objet en charge.

Un LSR qui prend en charge DS-TE DOIT prendre en charge l'objet CLASSTYPE.

6.1.1 Format des messages Path

Le format du message Path est le suivant :

<Message Path> ::= <En-tête commun> [ <INTEGRITY> ]

<SESSION> <RSVP_HOP>

<TIME_VALUES>

[ <EXPLICIT_ROUTE> ]

<LABEL_REQUEST>

[ <SESSION_ATTRIBUTE> ] [ <DIFFSERV> ] [ <CLASSTYPE> ]

[ <POLICY_DATA> ... ] [ <descripteur d'envoyeur> ]

<descripteur d'envoyeur> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]

[ <ADSPEC> ] [ <RECORD_ROUTE> ]

6.2 Objet CLASSTYPE

Le nom de classe de l'objet CLASSTYPE est CLASSTYPE. Son numéro de classe est 66. Actuellement, il n'y a qu'un seul C-Type défini qui est C-Type 1. Le format de l'objet CLASSTYPE est montré ci-dessous.

6.2.1 Objet CLASSTYPE

Numéro de classe = 66

Type de classe = 1

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Réservé | CT |

+---------------+---------------+---------------+---------+-+-+-+

Réservé : 29 bits. Ce champ est réservé. Il DOIT être réglé à zéro à la transmission et DOIT être ignoré à réception.

CT : 3 bits. Indique le Classe-Type. Les valeurs actuellement permises sont 1, 2, ... , 7. La valeur 0 est réservée.

6.3 Traitement de l'objet CLASSTYPE

Pour établir un tunnel LSP avec RSVP, le LSR envoyeur crée un message Path avec un type de session de LSP_Tunnel_IPv4 et avec un objet LABEL_REQUEST selon la [RFC3209]. Le LSR envoyeur peut aussi inclure l'objet DIFFSERV conformément à la [RFC3270].

Si le LSP est associé au classe-type 0, le LSR envoyeur NE DOIT PAS inclure l'objet CLASSTYPE dans le message Path. Cela permet la rétro compatibilité avec les LSR non configurés avec DS-TE ou sans capacité DS-TE comme expliqué à la Section 10 et dans l'Appendice C.

Si le LSP est associé au classe-type N (1 ≤ N ≤7), l'envoyeur LSR DOIT inclure l'objet CLASSTYPE dans le message Path avec le champ Classe-Type (CT) réglé à N.

Si un message Path contient plusieurs objets CLASSTYPE, seul le premier est significatif ; les objets CLASSTYPE suivants DOIVENT être ignorés et NE DOIVENT PAS être transmis.

Chaque LSR le long du chemin DOIT enregistrer l'objet CLASSTYPE, quand il est présent, dans son bloc d'état de chemin.

Si l'objet CLASSTYPE n'est pas présent dans le message Path, le LSR DOIT associer le Classe-Type 0 au LSP.

Le LSR de destination qui répond au message Path en envoyant un message Resv NE DOIT PAS inclure un objet CLASSTYPE dans le message Resv (que le message Path contienne ou non un objet CLASSTYPE).

Durant l'établissement d'un LSP correspondant au Classe-Type N, le LSR DOIT effectuer le contrôle d'admission sur la bande passante disponible pour ce Classe-Type particulier.

Un LSR qui reconnaît l'objet CLASSTYPE et qui reçoit un message Path qui :

- contient l'objet CLASSTYPE, mais

- ne contient pas d'objet LABEL_REQUEST ou n'a pas un type de session de LSP_Tunnel_IPv4,

DOIT envoyer une PathErr (erreur de chemin) à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "Objet CLASSTYPE inattendu". Ces codes sont définis au paragraphe 6.5.

Un LSR qui reçoit un message Path avec l'objet CLASSTYPE qui :

- reconnaît l'objet CLASSTYPE, mais

- ne prend pas en charge le Classe-Type particulier,

DOIT envoyer une PathErr à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "Classe-Type non pris en charge". Ces codes sont définis au paragraphe 6.5.

Un LSR qui reçoit un message Path avec l'objet CLASSTYPE qui :

- reconnaît l'objet CLASSTYPE, mais

- détermine que la valeur de classe-type n'est pas valide (c'est-à-dire, la valeur de classe-type 0),

DOIT envoyer une PathErr à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "Valeur de classe-type invalide". Ces codes sont définis au paragraphe 6.5.

Un LSR qui reçoit un message Path avec l'objet CLASSTYPE, qui :

- reconnaît l'objet CLASSTYPE et

- prend en charge le classe-type particulier, mais

- détermine que le tuplet formé par (i) ce classe-type et (ii) la priorité d'établissement signalée dans le même message Path, n'est pas une des huit classes TE configurées dans la transposition de classe TE,

DOIT envoyer une PathErr à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "CT et priorité d'établissement ne forment pas une classe TE configurée". Ces codes sont définis au paragraphe 6.5.

Un LSR qui reçoit un message Path avec l'objet CLASSTYPE qui :

- reconnaît l'objet CLASSTYPE et

- prend en charge le classe-type particulier, mais

- détermine que le tuplet formé par (i) ce classe-type et (ii) la priorité de garde signalée dans le même message Path, n'est pas une des huit classes TE configurées dans la transposition de classe TE,

DOIT envoyer une PathErr à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "CT et priorité de garde ne forment pas une classe TE configurée". Ces codes sont définis au paragraphe 6.5.

Un LSR qui reçoit un message Path avec l'objet CLASSTYPE qui :

- reconnaît l'objet CLASSTYPE et

- prend en charge le classe-type particulier, mais

- détermine que le tuplet formé par (i) ce classe-type et (ii) la priorité d'établissement signalée dans le même message Path, n'est pas une des huit classes TE configurées dans la transposition de classe TE, ET

- détermine que le tuplet formé par (i) ce classe-type et (ii) la priorité de garde signalée dans le même message Path, n'est pas une des huit classes TE configurées dans la transposition de classe TE

DOIT envoyer une PathErr à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "CT et priorité d'établissement ne forment pas une classe TE configurée ET CT et priorité de garde ne forment pas une classe TE configurée". Ces codes sont définis au paragraphe 6.5.

Un LSR qui reçoit un message Path avec l'objet CLASSTYPE et avec l'objet DIFFSERV pour un L-LSP qui :

- reconnaît l'objet CLASSTYPE,

- a une connaissance locale de la relation entre les classes-types et les classes de programmation de comportement par bond (PHB, Per Hop Behavior) par exemple, via la configuration, et

- détermine, sur la base de sa connaissance locale, que la classe de programmation de PHB (PSC, PHB Scheduling Class) signalée dans l'objet DIFFSERV n'est pas cohérente avec le classe-type signalé dans l'objet CLASSTYPE,

DOIT envoyer une PathErr à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "Incohérence entre PSC signalé et CT signalé". Ces codes sont définis au paragraphe 6.5.

Un LSR qui reçoit un message Path avec l'objet CLASSTYPE et l'objet DIFFSERV pour un E-LSP qui :

- reconnaît l'objet CLASSTYPE,

- a une connaissance locale de la relation entre les classes-types et les PHB (par exemple, via la configuration)

- détermine, sur la base de cette connaissance locale, que les PHB signalés dans les entrées MAP de l'objet DIFFSERV sont incohérentes avec le classe-type signalé dans l'objet CLASSTYPE,

DOIT envoyer une PathErr à l'envoyeur avec le code d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "Incohérence entre les PHB signalés et le CT signalé". Ces codes sont définis au paragraphe 6.5.

Un LSR DOIT traiter les situations dans lesquelles le LSP ne peut pas être accepté pour des raisons autres que celles déjà exposées dans cette section, conformément aux [RFC3209] et [RFC3270] (par exemple, une réservation est rejetée par le contrôle d'admission, et une étiquette ne peut pas être associée).

6.4 Non prise en charge de l'objet CLASSTYPE

Un LSR qui ne reconnaît pas l'objet CLASSTYPE Class-Num DOIT se comporter conformément aux procédures spécifiées dans la [RFC2205] pour un Class-Num inconnu dont le format est 0bbbbbbb (c'est-à-dire, il DOIT envoyer une PathErr avec le code d'erreur "Classe d'objet inconnue" à l'envoyeur).

Un LSR qui reconnaît l'objet CLASSTYPE Class-Num mais ne reconnaît pas l'objet CLASSTYPE C-Type, DOIT se comporter conformément aux procédures spécifiées dans la [RFC2205] pour un C-type inconnu (c'est-à-dire, il DOIT envoyer une PathErr avec le code d'erreur "C-Type d'objet inconnu" à l'envoyeur).

Les deux situations ci dessus causent l'échec de l'établissement du chemin. L'envoyeur DEVRAIT notifier à l'opérateur/système de gestion qu'un LSP ne peut pas être établi et qu'il pourrait prendre des mesures pour réessayer l'établissement de la réservation sans l'objet CLASSTYPE.

6.5 Codes d'erreur pour TE à capacité Diffserv

Dans les procédures décrites ci-dessus, certaines erreurs sont rapportées comme des "Erreur TE à capacité Diffserv". La valeur du code d'erreur "Erreur TE à capacité Diffserv" est 28.

Le tableau suivant définit les valeurs d'erreur pour l'erreur TE à capacité Diffserv :

Voir à la Section Considérations relatives à l'IANA l'allocation de valeurs supplémentaires.

7. Prise en charge de DS-TE avec extensions MPLS

Il y a un certain nombre d'extensions à la spécification de base initiale pour la signalisation [RFC3209] et la prise en charge de TE par IGP [RFC3630], [RFC3784]. Cela inclut des améliorations pour la généralisation ([RFC3471] et [RFC4202]), ainsi que des fonctionnalités supplémentaires, comme la hiérarchie de LSP [RFC4206], la mise en faisceau de liaisons [RFC4201], et la restauration rapide [RFC4090]. Ces spécifications peuvent faire référence à la façon de coder les informations associées à certaines priorités de préemption, comment traiter les LSP à des priorités de préemption différentes, ou elles peuvent aussi spécifier des codages ou comportements qui ont une signification différente pour un routeur DS-TE.

Pour qu'une mise en œuvre prenne en charge la présente spécification pour TE à capacité Diffserv et une certaine amélioration MPLS, comme celles citées ci-dessus, mais qui ne s'y limitent pas, elle DOIT traiter les références à la "priorité de préemption" et à la "bande passante maximum réservable" d'une manière généralisée, c'est-à-dire, la manière dont la présente spécification utilise ces termes.

De plus, les améliorations actuelles et futures de MPLS pourront inclure des spécifications plus précises de la façon dont elles interagissent avec TE à capacité Diffserv.

7.1 Prise en charge de DS-TE et références à la priorité de préemption

Lorsque un routeur prend en charge à la fois TE à capacité Diffserv et une des extensions de protocole MPLS telles que celles mentionnées ci-dessus, le codage des valeurs de priorité de préemption dans la signalisation ou le codage des informations associées aux priorités de préemption dans IGP définies pour l'extension de MPLS, DOIT être considéré comme un codage des mêmes informations pour la classe TE correspondante. Par exemple, si une amélioration MPLS spécifie une annonce dans IGP d'un paramètre pour des informations d'acheminement à la priorité de préemption N, dans un environnement DS-TE il DOIT en fait être interprété comme spécifiant une annonce des mêmes informations d'acheminement mais pour la classe TE [N]. À réception, les routeurs DS-TE DOIVENT aussi l'interpréter comme telle.

Quand il y a une discussion sur la façon de comparer le traitement des LSP de différentes priorités de préemption, un LSR DS-TE DOIT traiter les priorités de préemption dans ce contexte comme celles associées aux classes TE des LSP en question.

7.2 Prise en charge de DS-TE et références à la bande passante maximum réservable

Lorsque un routeur prend en charge à la fois TE à capacité Diffserv et les extensions de protocole MPLS telles que celles citées ci-dessus, les annonces de bande passante maximum réservable DOIVENT être faites avec l'interprétation généralisée définie au paragraphe 4.1.1 comme contrainte de bande passante agrégée sur tous les types de classes. Il PEUT aussi permettre l'annonce facultative de toutes les BC.

8. Acheminement fondé sur la contrainte

Considérons le cas où il faut calculer un chemin pour un LSP dont le classe-type est configuré à CTc et dont la priorité de préemption d'établissement est configurée à p.

La paire {CTc, p} va se transposer en les classes TE définies dans la transposition de classe de TE. Appelons cette classe TE TE-Class[i].

L'algorithme d'acheminement fondé sur la contrainte d'un LSR DS-TE n'est obligé que d'effectuer un calcul de chemin satisfaisant une seule BC qui va tenir dans la "TE-Class [i] non réservée" comme annoncé par l'IGP pour chaque liaison. Donc, aucun changement n'est exigé à l'algorithme existant d'acheminement TE fondé sur la contrainte lui-même.

L'algorithme d'acheminement fondé sur la contrainte PEUT aussi prendre en compte, lorsque il est utilisé, les informations supplémentaires facultatives annoncées dans l'IGP telles que les BC et la bande passante maximum réservable. Par exemple, les BC POURRAIENT être utilisées comme critère de départage dans des situations où plusieurs chemins, par ailleurs également attractifs, sont possibles.

9. Programmation Diffserv

Le classe-type signalé à l'établissement du LSP PEUT facultativement être utilisé par les LSR DS-TE pour ajuster de façon dynamique les ressources allouées au classe-type par le programmeur Diffserv. De plus, les informations Diffserv (c'est-à-dire, la PSC) signalées par les protocoles de signalisation TE-LSP comme spécifiées dans la [RFC3270], si elles sont utilisées, PEUVENT facultativement être utilisées par les LSR DS-TE pour ajuster dynamiquement les ressources allouées par le programmeur Diffserv à une PSC/OA au sein d'un CT.

10. TE existante comme cas particulier de DS-TE

On observer que la TE existante peut être vue comme un cas particulier de DS-TE où :

(i) un seul classe-type est utilisé,

(ii) les 8 priorités de préemption sont toutes permises pour ce classe-type, et

(iii) la transposition de classe de TE suivante est utilisée : TE-Classe[i] <--> < CT0 , préemption i > où 0 ≤ i ≤ 7.

Dans ce cas, DS-TE se comporte comme la TE existante.

Comme avec la TE existante, l'IGP annonce la bande passante non réservée pour chacune des 8 priorités de préemption.

Comme avec la TE existante, l'IGP peut annoncer la bande passante maximum réservable contenant une BC s'appliquant sur tous les LSP.

Parce que tous les LSP transportent du trafic provenant de CT0, la signalisation RSVP-TE est faite sans signalisation explicite du classe-type (qui n'est utilisé que pour les classes-types autres que CT0, comme expliqué à la Section 6) comme avec la TE existante.

11. Calcul de "Unreserved TE-Class [i]" et règles de contrôle d'admission

11.1 Calcul de "Unreserved TE-Class [i]"

On observe d'abord que, pour la TE existante, les détails sur les algorithmes de contrôle d'admission pour les LSP TE, et par conséquent, les détails sur les formules de calcul de la bande passante non réservée, sortent du domaine d'application des travaux actuels de l'IETF. Ceci relève de la différenciation des fabricants. Noter que cela ne compromet pas l'interopérabilité entre les diverses mises en œuvre parce que les schémas de TE s'appuient sur les LSR pour annoncer leur vue locale du monde en termes de bande passante non réservée aux autres LSR. De cette façon, sans considération de l'algorithme de contrôle d'admission local réellement utilisé sur un certain LSR, l'acheminement fondé sur la contrainte sur les autres LSR peut s'appuyer sur les informations annoncées pour déterminer si un LSP supplémentaire sera accepté ou rejeté par ce LSR. La seule exigence est qu'un LSR annonce des valeurs de bande passante non réservée qui soient cohérentes avec son algorithme spécifique de contrôle d'admission local et prennent en compte la priorité de préemption de garde des LSP établis.

Dans le contexte de DS-TE, là encore, les détails des algorithmes de contrôle d'admission relèvent des différents fabricants, et les formules de calcul de la bande passante non réservée pour TE-Class[i] sortent du domaine d'application de la présente spécification. Cependant, DS-TE pose une exigence supplémentaire pour le LSR qui est que la valeur de bande passante non réservée annoncée DOIT refléter toutes les BC pertinentes pour le CT associé à la TE-Class[i] conformément au modèle de contraintes de bande passante. Donc, les formules pour calculer "Unreserved TE-Class [i]" dépendent du modèle de contraintes de bande passante utilisé et DOIVENT refléter comment les BC s'appliquent aux CT. Des exemples de formules pour calculer le modèle de "Unreserved TE-Class [i]" sont fournis pour le modèle des poupées russes et pour le modèle d'allocation maximum, respectivement dans la [RFC4127] et la [RFC4125].

Comme avec la TE existante, les LSR DS-TE DOIVENT considérer la priorité de préemption de garde des LSP établis (par opposition à leur priorité de préemption d'établissement) pour les besoins du calcul de la bande passante non réservée pour TE-Class [i].

11.2 Règles de contrôle d'admission

Un LSR DS-TE DOIT prendre en charge les règles de contrôle d'admission suivantes :

Sans considération de la façon dont l'algorithme de contrôle d'admission calcule réellement la bande passante non réservée pour TE-Class[i] pour une de ses liaisons locales, un LSP de bande passante B, de priorité de préemption d'établissement p et de classe-type CTc est admissible sur cette liaison si et seulement si B ≤ Bande passante non réservée pour TE-Class[i] ; où TE-Class[i] correspond à {CTc , p} dans la transposition de classe de TE configurée sur le LSR.

12. Considérations sur la sécurité

Le présent document n'introduit pas de menace supplémentaire pour la sécurité au delà de celles décrites pour Diffserv ([RFC2475]) et l'ingénierie de trafic MPLS ([RFC2702], [RFC3209], [RFC3630], [RFC3784]) et les mesures et procédures de sécurité décrites dans ces documents s'appliquent ici. Par exemple, l'approche pour la défense contre les attaques de vol et de déni de service discutées dans la [RFC2475], qui consistent en la combinaison de conditionnement de trafic aux nœuds frontière de DS avec la sécurité et l'intégrité de l'infrastructure du réseau au sein d'un domaine Diffserv, peut être suivie lors de l'utilisation de DS-TE. Aussi, comme déclaré dans la [RFC2702], il est spécifiquement important que la manipulation de paramètres administrativement configurables (comme ceux relatifs aux LSP DS-TE) soit exécutée de manière sûre par les entités autorisées.

13. Considérations relatives à l'IANA

Le présent document crée deux nouveaux espaces de noms qui seront gérés par l'IANA. Un certain nombre d'allocations dans les espaces de noms existants ont également été faits par l'IANA dans ce document. Ils sont exposés ci-dessous.

13.1 Nouvel espace de noms pour identifiants de modèle de contraintes de bande passante

Le présent document définit au paragraphe 5.1 un champ (espace de noms) "Identifiant de modèle de contraintes de bande passante" au sein du sous TLV "contraintes de bande passante", pour OSPF et ISIS. Le nouvel espace de noms a été créé par l'IANA qui va tenir ce nouvel espace de noms. Le champ pour cet espace de noms est de 1 octet, et les lignes directrices de l'IANA pour l'allocation de ce champ sont les suivantes :

o les valeurs dans la gamme 0 à 239 sont allouées selon la politique de "spécification exigée" définie dans la [RFC2434] ;

o les valeurs dans la gamme 240 à 255 sont réservée pour "utilisation privée" comme défini dans la [RFC2434].

13.2 Nouvel espace de noms pour valeurs d'erreur sous le "Diffserv-aware TE Error"

Un code d'erreur est une quantité de huit bits définie dans la [RFC2205] qui apparaît dans un objet ERROR_SPEC pour définir largement une condition d'erreur. Avec chaque code d'erreur, il peut y avoir une valeur d'erreur de 16 bits (qui dépend du code d'erreur) qui spécifie plus précisément la cause de l'erreur.

Le présent document définit au paragraphe 6.5 un nouveau code d'erreur RSVP, "Erreur TE à capacité Diffserv" (voir au paragraphe 13.3.4). Les valeurs d'erreur pour "Erreur TE à capacité Diffserv" constituent un nouvel espace de nom géré par l'IANA.

Le présent document définit, au paragraphe 6.5, les valeurs 1 à 7 de cet espace de noms (voir le paragraphe 13.3.5).

Les futures allocations de valeurs dans cet espace de noms seront allouées par l'IANA selon la politique "spécification exigée" définie dans la [RFC2434].

13.3 Allocations faites dans ce document

13.3.1 Sous TLV Contrainte de bande passante pour OSPF version 2

La [RFC3630] crée un espace de noms pour les types de sous TLV au sein de la "TLV Liaison" de l'annonce d'état de liaison (LSA, Link State Advertisement) de l'ingénierie de trafic et les règles pour la gestion de cet espace de noms par l'IANA.

Le présent document définit au paragraphe 5.1 une nouvelle sous TLV "Contraintes de bande passante" pour la TLV OSPF "Link". En accord avec les considérations relatives à l'IANA fournies dans la [RFC3630], un type de sous TLV dans la gamme de 10 à 32 767 a été demandé, et la valeur 17 a été allouée par l'IANA pour la sous TLV "contraintes de bande passante".

13.3.2 Sous TLV Contrainte de bande passante pour ISIS

La [RFC3784] crée un espace de noms pour les types de sous TLV au sein de la TLV ISIS "accessibilité IS étendue" et les règles de gestion de cet espace de noms par l'IANA.

Le présent document définit au paragraphe 5.1 une nouvelle sous TLV "Contraintes de bande passante", pour la TLV ISIS "Accessibilité IS étendue". En accord avec les considérations relatives à l'IANA fournies dans la [RFC3784], un type de sous TLV a été demandé, et la valeur 22 a été allouée par l'IANA pour la sous TLV "Contraintes de bande passante".

13.3.3 Objet CLASSTYPE pour RSVP

La [RFC2205] définit l'espace de noms Numéro de classe pour les objets RSVP, qui est géré par l'IANA. Les numéros de classe actuellement alloués sont donnés à http://www.iana.org/assignments/rsvp-parameters .

Le présent document définit au paragraphe 6.2.1 un nouvel objet RSVP, l'objet CLASSTYPE. L'IANA a alloué un numéro de classe pour cet objet RSVP dans la gamme définie au paragraphe 3.10 de la [RFC2205] pour les objets qui, si ils ne sont pas compris, causent le rejet du message RSVP entier avec un code d'erreur de "Classe d'objet inconnue". De tels objets sont identifiés par un zéro au bit de plus fort poids du numéro de classe (c'est-à-dire, Class-Num = 0bbbbbbb).

L'IANA a alloué le numéro de classe 66 à l'objet CLASSTYPE. Le C_Type 1 est défini dans ce document pour l'objet CLASSTYPE.

13.3.4 Code d'erreur "Erreur TE à capacité Diffserv"

La [RFC2205] définit l'espace de noms de code d'erreur et les règles de gestion de cet espace de noms par l'IANA. Les codes d'erreur actuellement alloués figurent à http://www.iana.org/assignments/rsvp-parameters .

Le présent document définit au paragraphe 6.5 un nouveau code d'erreur RSVP, "Erreur TE à capacité Diffserv". En accord avec les considérations relatives à l'IANA fournies dans la [RFC2205], le code d'erreur 28 a été alloué par l'IANA à "Erreur TE à capacité Diffserv".

13.3.5 Valeur d'erreur pour "Erreur TE à capacité Diffserv"

Un code d'erreur est une quantité de 8 bits définie dans la [RFC2205] qui apparaît dans les objets ERROR_SPEC pour définir les grandes lignes d'une condition d'erreur. Avec chaque code d'erreur, il y a une valeur d'erreur de 16 bits (qui dépend du code d'erreur) qui précise la cause de l'erreur.

Le présent document définit au paragraphe 6.5 un nouveau code d'erreur RSVP, "Erreur TE à capacité Diffserv" (voir le paragraphe 13.3.4). Les valeurs d'erreur pour "Erreur TE à capacité Diffserv" constituent un nouvel espace de noms géré par l'IANA.

Le présent document définit au paragraphe 6.5, les valeurs d'erreur suivantes pour "Erreur TE à capacité Diffserv" :

Voir au paragraphe 13.2 l'allocation des autres valeurs dans cet espace de noms.

14. Remerciements

Merci à Martin Tatham, Angela Chiu, et Pete Hicks de leur contribution précoce à ce travail. Nous remercions aussi Sanjaya Choudhury de sa relecture attentive et de ses suggestions.

Appendice A. Prédiction pour calcul de chemins multiples

Il y a des situations où une extrémité de tête a besoin de calculer des chemins pour plusieurs LSP sur une courte période. Il y a des avantages potentiels pour l'extrémité de tête à essayer de prédire l'impact du nième LSP sur la bande passante non réservée lors du calcul du chemin pour le (n+1)ième LSP, avant de recevoir des informations de IGP mises à jour. Par exemple, une meilleure distribution de charge des multiples LSP serait effectuée à travers les divers chemins. Aussi, lorsque le (n+1)ième LSP ne va plus tenir sur une liaison après l'établissement du nième LSP, l'extrémité de tête évitera le rejet du contrôle d'admission de connexion (CAC, Connection Admission Control). Bien qu'un certain nombre de scénarios soient concevables lorsque les pires situations pourraient résulter, faire de telles prédictions va plus probablement améliorer la situation. En fait, un certain nombre d'administrateurs de réseau ont choisi d'utiliser de telles prédictions pour déployer la TE existante.

De telles prédictions sont des affaires locales, sont facultatives, et sortent du domaine d'application de cette spécification.

Si de telles prédictions ne sont pas utilisées, la sous TLV BC facultative et la sous TLV facultative Bande passante maximum réservable n'ont pas besoin d'être annoncées dans IGP pour les besoins du calcul de chemin, car les informations contenues dans la sous TLV Bande passante non réservée sont tout ce qui est nécessaire à l'extrémité de tête pour effectuer l'acheminement fondé sur la contrainte.

lorsque de telles prédictions sont utilisées sur les extrémités de tête, les sous TLV BC facultatives et la sous TLV facultative Bande passante maximum réservable PEUVENT être annoncées dans IGP. Cela afin que les extrémités de tête prédisent de façon aussi précise que possible comment un LSP affecte les valeurs de bande passante non réservée pour les LSP suivants.

On se souvient que les algorithmes réels de contrôle d'admission sont du ressort de la différenciation des fabricants, et on observe que les prédictions ne peuvent être effectuées efficacement que lorsque les prédictions de LSR d'extrémité de tête se fondent sur le même (ou un autre très proche) algorithme de contrôle d'admission que celui utilisé par les autres LSR.

Appendice B. Évaluation de solution

B.1 Satisfaction des exigences détaillées

Cette solution DS-TE traite tous les scénarios présentés dans la [RFC3564]. Elle satisfait aussi aux exigences détaillées présentées dans la [RFC3564].

L'objectif présenté dans le dernier alinéa du paragraphe 4.7 de la [RFC3564], "Sur réservation", est seulement partiellement traité par cette solution DS-TE. Par la prise en charge des méthodes de "sur réservation de taille de LSP" et de "sur réservation de taille de liaison", cette solution DS-TE permet effectivement aux CT d'avoir des ratios de sur réservation différents et permet simultanément que la sur réservation soit appliquée différemment (collectivement sur tous les CT) sur les différentes liaisons. Mais, en général, elle ne permet pas que le ratio effectif de sur réservation de chaque CT soit appliqué différemment dans les différentes parties du réseau indépendamment des autres CT, tout en conservant une comptabilité précise de la façon dont les bandes passantes des différents CT s'affectent mutuellement à travers les BC partagées (comme la bande passante maximum réservable).

B.2 Souplesse

Cette solution DS-TE prend en charge 8 CT. Sa souplesse est complète quant à la façon dont les jonctions de trafic sont groupées dans un CT.

B.3 Extensibilité

Un maximum de 8 CT est considéré comme plus confortable par les auteurs de ce document qui estiment aussi qu"un maximum de 8 classes TE est suffisant. Cependant, cette solution pourrait être étendue pour prendre en charge plus de CT ou plus de classes TE si cela se révélait nécessaire à l'avenir ; cela nécessiterait des extensions IGP supplémentaires au delà de celles spécifiées dans le présent document.

Bien que le principal objectif de cette solution soit de prendre en charge l'ingénierie de trafic à capacité Diffserv, ses mécanismes ne sont pas étroitement couplés avec Diffserv. Cela rend cette solution souple, ou plus facilement extensible, pour prendre en charge de potentielles autres applications futureq d'ingénierie de trafic.

B.4 Adaptabilité

Cette solution DS-TE est supposée avoir un très faible impact sur l'adaptabilité comparée à celle de la TE existante.

Du point de vue d'IGP, la quantité d'informations dont l'annonce est obligatoire est identique à celle de la TE existante. Une sous TLV supplémentaire a été spécifiée, mais son utilisation est facultative, et elle ne contient qu'une quantité limitée d'informations statiques (au plus 8 BC).

On n'attend pas d'impact notable sur le calcul de chemin de LSP parce que, comme avec la TE existante, cette solution exige seulement que la contrainte de plus court chemin en premier (CSPF, Constrained Shortest Path First) considère une seule valeur de bande passante non réservée pour tout LSP.

Du point de vue de la signalisation, on n'attend pas d'impact significatif de cette solution parce que elle exige seulement le traitement d'un seul élément d'information supplémentaire (le classe-type) et n'augmente pas significativement la probabilité d'un rejet de CAC. Noter que DS-TE a un impact inhérent sur la signalisation de LSP en ce qu'il suppose que des classes de trafic différents sont partagées entre différents LSP de sorte que plus de LSP doivent être signalés. Cependant, ceci est dû au concept de DS-TE lui-même et non à la solution réelle de DS-TE discutée ici.

B.5 Rétro compatibilité/migration

Cette solution est censée permettre une migration en douceur de la TE existante à DS-TE. C'est parce que la TE existante peut être acceptée comme configuration particulière de DS-TE. Cela signifie qu'un LSR "mis à niveau" avec une mise en œuvre de DS-TE peut inter fonctionner directement avec un "vieux" LSR ne prenant en charge que la TE existante.

On attend de cette solution qu'elle permette une migration en douceur lorsque le nombre de CT réellement déployés aura augmenté, car cela exige seulement des changements de configuration. Cependant, ces changements doivent être effectuées de façon coordonnée à travers le domaine DS-TE.

Appendice C. Interopérabilité avec des LSR sans capacité DS-TE

Cette solution DS-TE permet le fonctionnement dans un réseau hybride où certains LSR sont à capacité DS-TE et d'autres ne le sont pas, comme cela peut se produire pendant les phases de migration. Cet appendice discute des contraintes et du fonctionnement dans de tels réseaux hybrides.

On se réfère à l'ensemble des LSR à capacité DS-TE comme au domaine DS-TE. On se réfère à l'ensemble des LSR sans capacité DS-TE (mais à capacité TE) comme au domaine TE.

Le fonctionnement hybride exige que la transposition de classe de TE dans le domaine DS-TE soit configurée de telle sorte que :

- une classe TE existe pour CT0 pour chaque priorité de préemption réellement utilisée dans le domaine TE, et

- l'indice dans la transposition de classe TE pour chacune de ces classes TE soit égale à la priorité de préemption.

Par exemple, imaginons que le domaine TE utilise les préemptions 2 et 3. DS-TE peut alors être déployé dans le même réseau en incluant les classes TE suivantes dans la transposition de classe de TE :

i <---> CT préemption

=======================

2 CT0 2

3 CT0 3

Une autre façon de voir cela est de dire que bien que toute la transposition de classe TE n'ait pas à être cohérente avec le domaine TE, le sous ensemble de cette transposition de classe de TE applicable à CT0 doit effectivement être cohérent avec le domaine TE.

Le fonctionnement hybride exige aussi que :

- les LSR sans capacité DS-TE soient configurés à annoncer la bande passante maximum réservable, et

- les LSR à capacité DS-TE soient configurés à annoncer les BC (en utilisant le sous TLV Bande passante maximum réservable ainsi que les sous TLV BC, comme spécifié au paragraphe 5.1).

Cela permet aux LSR à capacité DS-TE d'identifier sans ambiguïté les LSR sans capacité DS-TE.

Finalement, le fonctionnement hybride exige que les LSR sans capacité DS-TE soient capables d'accepter les sous TLV Bande passante non réservée contenant des valeurs de bande passante non décroissantes (c'est-à-dire, avec Non réservé [p] < Non réservé [q] avec p < q).

Dans de tels réseaux hybrides, ce qui suit s'applique :

- Les LSP CT0 peuvent être établis aussi bien par les LSR à capacité DS-TE que sans capacité DS-TE.

- Les LSP CT0 peuvent transiter via (ou se terminer à) aussi bien par des LSR à capacité DS-TE que sans capacité DS-TE.

- Les LSP provenant d'autres CT ne peuvent être établis que par des LSR à capacité DS-TE.

- Les LSP provenant d'autres CT ne peuvent transiter que via (ou se terminer qu'à) des LSR à capacité DS-TE.

Considérons l'exemple suivant pour illustrer le fonctionnement :

LSR0--------LSR1----------LSR2

Link01 Link12

où LSR0 est un LSR sans capacité DS-TE, et LSR1 et LSR2 sont des LSR à capacité DS-TE.

Supposons encore que les préemptions 2 et 3 sont utilisées dans le domaine TE et que la transposition de classe de TE suivante est configurée sur les LSR1 et LSR2 :

i <---> CT préemption

=======================

0 CT1 0

1 CT1 1

2 CT0 2

3 CT0 3

Le reste n'est pas utilisé

LSR0 est configuré avec une bande passante maximum réservable = m01 pour Link01. LSR1 est configurée avec BC0 = x0, un BC1 = x1 (éventuellement = 0), et une bande passante maximum réservable = m10 (éventuellement = m01) pour Link01.

Dans IGP pour Link01, LSR0 va annoncer :

- Sous TLV Bande passante maximum réservable = <m01>

- Sous TLV Bande passante non réservée = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4, CT0/5, CT0/6, CT0/7>

À réception d'une telle annonce, LSR1 va :

- comprendre que LSR0 n'a pas de capacité DS-TE parce qu'il annonce une sous TLV Bande passante maximum réservable et pas de sous TLV de contraintes de bande passante, et

- conclure que seuls les LSP CT0 peuvent transiter via LSR0 et que seules les valeurs CT0/2 et CT0/3 ont une signification dans la sous TLV. LSR1 peut effectivement se comporter comme si les six autres valeurs contenues dans la sous TLV Bande passante non réservée étaient réglées à zéro.

Dans IGP pour Link01, LSR1 va annoncer :

- Sous TLV Bande passante maximum réservable = <m10>

- Sous TLV Contraintes de bande passante = <Identifiant de modèle de BC, x0, x1>

- Sous TLV Bande passante non réservée = <CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>

À réception d'une telle annonce, LSR0 va :

- ignorer la sous TLV Contraintes de bande passante (non reconnue)

- traiter correctement CT0/2 et CT0/3 dans la sous TLV Bande passante non réservée et utiliser ces valeurs pour l'établissement du LSP CTO,

- croire à tort que les autres valeurs contenues dans la sous TLV Bande passante non réservée se rapportent aux autres priorités de préemption pour CT0 ; mais il ne va en fait jamais les utiliser car on suppose que seules les préemptions 2 et 3 sont utilisées dans le domaine TE.

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)

[RFC2205] R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)

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

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

[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 001. (P.S.) (MàJ par la RFC6790)

[RFC3209] D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

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

[RFC3564] F. Le Faucheur, W. Lai, "Exigences pour la prise en charge de l'ingénierie de trafic MPLS capable de services différenciés", juillet 2003. (Information)

[RFC3630] D. Katz, K. Kompella et D. Yeung, "Extensions d'ingénierie de trafic à OSPF version 2", septembre 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) (MàJ par RFC4205) (Information)

Références pour information

[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre 1998. (MàJ par RFC3260)

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

[RFC4090] P. Pan et autres, "Extensions de reroutage rapide à RSVP-TE pour les tunnels de LSP", mai 2005. (P.S. ; MàJ par RFC8271, RFC8537)

[RFC4125] F. Le Faucheur, W. Lai, "Modèle de contraintes d'allocation maximale de bande passante pour l'ingénierie de trafic MPLS avec capacité Diffserv", juin 2005. (Expérimentale)

[RFC4126] J. Ash, "Allocation maximale avec le modèle de contraintes de réservation de bande passante pour l'ingénierie de trafic MPLS avec capacité Diffserv et comparaisons de performances", juin 2005. (Exp.)

[RFC4127] F. Le Faucheur, éd., "Modèle de contraintes de bande passante des poupées russes pour l'ingénierie de trafic MPLS avec capacité Diffserv", juin 2005. (Expérimentale)

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

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

[RFC4206] K. Kompella, Y. Rekhter, "Hiérarchie de chemins commutés par étiquettes (LSP) avec l'ingénierie de trafic (TE) de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (P.S.)

Adresse de l'éditeur

Francois Le Faucheur

Cisco Systems, Inc.

Village d'Entreprise Green Side - Batiment T3

400, Avenue de Roumanille

06410 Biot-Sophia Antipolis

France

téléphone : +33 4 97 23 26 19

mél : flefauch@cisco.com

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, 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 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.

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