Groupe de travail Réseau

D. Awduche

Request for Comments : 2702

J. Malcolm

Catégorie : Information

J. Agogbua

septembre 1999

M. O'Dell

 

J. McManus

Traduction Claude Brière de L'Isle

UUNET (MCI Worldcom)

 

 

Exigences pour l'ingénierie du trafic sur MPLS

 

Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

 

Notice de copyright

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

 

Résumé

Le présent document présente un ensemble d'exigences pour l'ingénierie du trafic sur la commutation par étiquettes multi protocoles (MPLS, Multiprotocol Label Switching). Il identifie les capacités fonctionnelles requises pour mettre en œuvre les politiques qui facilitent un fonctionnement efficace et fiable du réseau dans un domaine MPLS. Ces capacités peuvent être utilisées pour optimiser l'utilisation des ressources du réseau et pour améliorer les caractéristiques des performances orientées trafic.

 

Table des Matières

1.   Introduction

1.1   Terminologie

1.2   Organisation du document

2.   Ingénierie du trafic

2.1   Objectifs de performances de l'ingénierie du trafic

2.2   Contrôle du trafic et des ressources

2.3   Limitations des mécanismes actuels de contrôle des IGP

3.   MPLS et l'ingénierie du trafic

3.1   Graphe MPLS induit

3.2   Problème fondamental de l'ingénierie du trafic sur MPLS

4.   Capacités augmentées de l'ingénierie du trafic sur MPLS

5.   Attributs et caractéristiques des circuits de trafic

5.1   Circuits de trafic bidirectionnels

5.2   Fonctionnement de base des circuits de trafic

5.3   Surveillance de la comptabilité et des performances

5.4   Attributs de base d'ingénierie du trafic sur les circuits de trafic

5.5   Attributs des paramètres de trafic

5.6   Choix générique de chemin et attributs de gestion

5.6.1   Chemins expicites spécifiés administrativement

5.6.2   Hiérarchie des règles de préférence pour chemins multiples

5.6.3   Attributs d'affinité de classe de ressource

5.6.4   Attribut d'adaptabilité

5.6.5   Répartition de charge sur des circuits de trafic parallèles

5.7   Attribut de priorité

5.8   Attribut de préemption

5.9   Attribut de résilience

5.10   Attribut de régulation

6.   Attribut de ressources

6.1   Multiplicateur d'allocation maximum

6.2   Attribut de classe de ressource

7.   Acheminement fondé sur la contrainte

7.1   Caractéristiques de base de l'acheminement fondé sur la contrainte  .

7.2   Considérations de mise en œuvre

8.   Conclusion

9.   Considérations pour la sécurité

10.   Références

11.   Remerciements

12.   Adresse des auteurs

13.   Déclaration de droits de reproduction

 

1.   Introduction

 

La commutation par étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) [1,2] intègre un cadre d'échange d'étiquettes et un acheminement de couche réseau. L'idée de base implique d'allouer de courtes étiquettes de longueur fixe aux paquets à l'entrée d'un nuage MPLS (sur la base du concept des classes d'équivalence de transmission [1,2]). Tout au long du domaine MPLS, les étiquettes attachées aux paquets sont utilisées pour prendre les décisions de transmission (normalement sans recours aux en-têtes originaux du paquet).

 

Un ensemble de constructions puissantes pour traiter de nombreuses questions critiques des services différenciés émergeants dans l'Internet peut être déduit de ce paradigme relativement simple. Une des applications initiales les plus significatives de MPLS sera dans l'ingénierie du trafic. L'importance de cette application est déjà bien reconnue (voir [1,2,3]).

 

Le présent texte se concentre exclusivement sur les applications d'ingénierie du trafic de MPLS. Précisément, l'objectif de ce document est de mettre en lumière les problèmes et les exigences d'ingénierie du trafic dans un grand cœur de réseau Internet. Ce qu'on en attend est que les spécifications de MPLS, ou les mises en œuvre qui en découlent, se consacrent à la réalisation de ces objectifs. Une description des capacités et fonctionnalités de base exigées d'une mise en œuvre MPLS pour s'accommoder de ces exigences est aussi présentée.

 

On notera que bien que l'accent soit mis sur le cœur de réseau Internet, les capacités décrites dans ce document sont également applicables à l'ingénierie du trafic dans les réseaux d'entreprise. En général, les capacités peuvent être appliquées à tout réseau à commutation par étiquettes soumis à une seule administration technique dans lequel au moins deux chemins existent entre deux nœuds.

 

Certains documents récents se sont concentrés sur les considérations relevant de l'ingénierie du trafic et la gestion du trafic sous MPLS, dont les plus notables sont les travaux de Li et Rekhter [3], et autres. Dans [3] est proposée une architecture qui utilise MPLS et RSVP pour fournir des services différenciés échelonnables et de l'ingénierie du trafic dans l'Internet. Le présent document complète les efforts susmentionnés et ceux qui leurs sont similaires. Il reflète l'expérience opérationnelle de l'auteur dans la gestion d'un grand cœur de réseau Internet.

 

1.1   Terminologie

Le lecteur est supposé être familiarisé avec la terminologie MPLS définie dans [1].

 

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la RFC 2119 [11].

 

1.2   Organisation du document

Le reste de ce document est organisé comme suit : la Section 2 expose les fonctions de base de l'ingénierie du trafic dans l'Internet. La Section 3 donne une vue d'ensemble des potentiels de l'ingénierie du trafic dans MPLS. Les Sections 1 à 3 sont essentiellement des notions de base. La Section 4 présente une vue d'ensemble des exigences fondamentales de l'ingénierie du trafic sur MPLS. La Section 5 décrit les attributs et caractéristiques souhaitables des circuits de trafic qui sont pertinents pour l'ingénierie du trafic. La Section 6 présente un ensemble d'attributs qui peuvent être associés aux ressources pour contraindre l'acheminement des circuits de trafic et des LSP à travers eux. La Section 7 plaide en faveur de l'introduction d'un cadre "d'acheminement fondé sur la contrainte" dans le domaine MPLS. Finalement, la Section 8 contient les remarques qui servent de conclusion.

 

2.   Ingénierie du trafic

 

Cette section décrit les fonctions de base de l'ingénierie du trafic dans un système autonome de l'Internet contemporain. Les limitations des protocoles de passerelle intérieure (IGP, Interior Gateway Protocol) actuels par rapport au contrôle du trafic et des ressource sont mises en lumière. Cette section sert d'exposé des motifs pour les exigences portant sur MPLS.

 

L'ingénierie du trafic (TE, Traffic Engineering) est concernée par l'optimisation des performances du fonctionnement des réseaux. En général, elle met en application les technologies et les principes scientifiques aux mesures, modélisations, caractérisations et contrôles du trafic de l'Internet, et l'application de ces connaissances et techniques pour réaliser des objectifs spécifiques de performances. Les aspects de l'ingénierie du trafic qui concernent le plus MPLS sont les mesures et le contrôle.

 

Un objectif majeur de l'ingénierie du trafic Internet est de faciliter un fonctionnement efficace et fiable du réseau tout en optimisant simultanément l'utilisation des ressources du réseau et les performances du trafic. L'ingénierie du trafic est devenue une fonction indispensable dans de nombreux grands systèmes autonomes à cause du coût élevé des investissements du réseau et de la nature commerciale et de la concurrence sur l'Internet. Ces facteurs soulignent le besoin d'une efficacité de fonctionnement maximale.

 

2.1   Objectifs de performances de l'ingénierie du trafic

 

Les objectifs clés de performances associés à l'ingénierie du trafic peuvent entrer dans deux catégories :

1.   orienté trafic

2.   orienté ressource.

 

Les objectifs de performance orientés trafic incluent les aspects d'amélioration de la qualité de service des flux de trafic. Dans une seule classe, le modèle de service Internet au mieux, les objectifs clés de performances orientées trafic incluent : la minimisation de la perte de paquet, la minimisation du délai, la maximisation du débit, et la mise en application des accords de niveau de service (SLA, service level agreement). Dans la seule classe du modèle de service Internet au mieux, la minimisation de la perte de paquet est un des objectifs les plus importants des performances orientées trafic. La détermination statistique des limites des objectifs de performances orientées trafic (tels que la variation de crête à crête du retard de paquet, le taux de perte, et le délai maximum de transfert de paquet) pourrait devenir utile pour les services différenciés à venir sur l'Internet.

 

Les objectifs de performances orientées ressource incluent les aspects qui relèvent de l'optimisation de l'utilisation des ressources. La gestion efficace des ressources du réseau est le véhicule pour la réalisation des objectifs de performances orientées ressource. En particulier, il est généralement désirable de s'assurer que des sous-ensembles des ressources réseau ne deviennent pas sur utilisés et encombrés alors que d'autres sous-ensembles sur des chemins de remplacement possibles restent sous utilisés. La bande passante est une ressource cruciale dans les réseaux contemporains. Donc, une fonction centrale de l'ingénierie du trafic est de gérer efficacement les ressources de bande passante.

 

Minimiser l'encombrement est un objectif principal des performances orientées trafic et ressource. L'intérêt ici se porte sur les problèmes d'encombrement qui se prolongent plutôt que sur l'encombrement transitoire résultant de salves instantanées. L'encombrement se manifeste normalement selon deux scénarios :

 

1.   Lorsque les ressources du réseau sont insuffisantes ou inadéquates pour s'accommoder de la charge offerte.

 

2.   Lorsque les flux de trafic sont transposés de façon inefficace dans les ressources disponibles, ce qui fait que des sous-ensembles de ressources réseau deviennent sur utilisés alors que d'autres restent sous-utilisés.

 

Le premier type de problème d'encombrement peut se régler soit : (i) par l'expansion des capacités, soit (ii) par l'application des techniques classiques de contrôle d'encombrement, ou (iii) les deux. Les techniques classiques de contrôle de l'encombrement tentent de réguler la demande de telle sorte que le trafic tienne dans les ressources disponibles. Les techniques classiques de contrôle de l'encombrement incluent : la limitation du débit, le contrôle de la fenêtre de flux, la gestion de la file d'attente du routeur, le contrôle fondé sur la programmation, et d'autres ; (voir dans [8] et les références qu'il contient).

 

Le second type de problèmes d'encombrement, à savoir ceux qui résultent d'une allocation inefficace des ressources, peut habituellement être réglé par l'ingénierie du trafic.

 

En général, l'encombrement qui résulte d'une allocation inefficace des ressources peut être réduit par l'adoption de politiques d'équilibrage de charge. L'objectif d'une telle stratégie est de minimiser l'encombrement maximum ou autrement de minimiser l'utilisation maximum des ressources par une allocation efficace des ressources. Lorsque l'encombrement est minimisé par une allocation efficace de ressources, la perte de paquet décroît, le délai de transit décroît, et de débit agrégé s'accroît. Il en résulte que la perception de la qualité de service du réseau par l'utilisateur final est significativement améliorée.

 

En clair, l'équilibrage de charge est une politique importante d'optimisation des performances du réseau. Néanmoins, les capacités fournies pour l'ingénierie du trafic devraient être assez souples pour que les administrateurs de réseau puissent mettre en œuvre d'autres politiques qui prennent en compte la structure prévalente des coûts et le modèle d'utilité ou de revenu.

 

2.2   Contrôle du trafic et des ressources

 

L'optimisation des performances des réseaux opérationnels est fondamentalement un problème de contrôle. Dans le modèle de traitement de l'ingénierie du trafic, l'ingénieur trafic, ou un automate convenable, agit comme contrôleur dans un système de contrôle à rétroaction adaptative. Ce système comporte un ensemble d'éléments de réseau interconnectés, un système de surveillance des performances du réseau, et un ensemble d'outils de gestion de la configuration du réseau. L'ingénieur trafic formule une politique de contrôle, observe l'état du réseau au travers du système de surveillance, caractérise le trafic, et applique des actions de contrôle pour conduire le réseau à l'état désiré, conformément à la politique de contrôle. Cela peut être fait de façon réactive en prenant des mesures en réponse à l'état en cours du réseau, ou de façon proactive en utilisant des techniques de prévision pour anticiper les tendances futures et en appliquant des mesures pour empêcher les états prévus indésirables.

 

Idéalement, les actions de contrôle devraient impliquer :

1.   la modification des paramètres de gestion du trafic,

2.   la modification des paramètres associés à l'acheminement,

3.   la modification des attributs et contraintes associés aux ressources.

 

Le niveau d'intervention manuelle impliqué dans le processus d'ingénierie du trafic devrait être minimisé chaque fois que possible. Cela peut être réalisé en automatisant les aspects des actions de contrôle décrites ci-dessus, d'une façon répartie et échelonnée.

 

2.3   Limitations des mécanismes actuels de contrôle des IGP

 

Ce paragraphe passe en revue les limitations bien connues des IGP actuels à l'égard de l'ingénierie du trafic.

 

Les capacités de contrôle offertes par les protocoles de passerelle intérieure (IGP) existants pour l'Internet ne sont pas adéquats pour l'ingénierie du trafic. Cela rend difficile d'actualiser des politiques efficaces pour qu'elles traitent les problèmes de performance des réseaux. Bien sûr, les IGP fondés sur les algorithmes de plus court chemin contribuent de façon significative aux problèmes d'encombrement dans les systèmes autonomes au sein de l'Internet. Les algorithmes de plus court chemin en premier (SPF, Shortest Path First) optimisent généralement sur la base d'une simple métrique additive. Ces protocoles sont pilotés par la topologie, de sorte que la disponibilité de la bande passante et les caractéristiques du trafic ne sont pas des facteurs pris en considération dans les décisions d'acheminement. Par conséquent, l'encombrement survient fréquemment lorsque :

1.   les plus courts chemins de plusieurs flux de trafic convergent sur des liaisons ou interfaces de routeur spécifiques, ou

2.   un flux de trafic donné est acheminé à travers une liaison ou interface de routeur qui n'a pas assez de bande passante pour le traiter.

 

Ces scénarios se manifestent même lorsque existent des chemins de remplacement acceptables avec des capacités en excès. C'est cet aspect des problèmes d'encombrement (symptôme d'une allocation de ressource sous optimale) que l'ingénierie du trafic vise vigoureusement à éviter. Le partage de charge entre chemins à coût égal peut être utilisé pour régler la seconde cause d'encombrement citée ci-dessus avec un certain degré de succès, mais il ne peut cependant être d'aucune aide pour alléger l'encombrement dû à la première cause qui figure ci-dessus et en particulier dans les grands réseaux qui ont une topologie dense.

 

Une approche populaire pour circonvenir les inadéquations des IGP actuels est d'utiliser un modèle à recouvrement, tel que IP sur ATM ou IP sur relais de trame. Le modèle à recouvrement étend l'espace de conception en permettant que des topologies virtuelles arbitraires soient provisionnées par dessus la topologie physique du réseau. La topologie virtuelle se construit à partir de circuits virtuels (VC) qui apparaissent comme des liaisons physiques aux protocoles d'acheminement IGP. Le modèle à recouvrement apporte des services supplémentaires importants pour la prise en charge du contrôle de trafic et de ressource, y compris : (1) l'acheminement fondé sur la contrainte au niveau VC, (2) la prise en charge de chemins de VC explicites configurables administrativement, (3) la compression de chemin, (4) les fonctions de contrôle d'admission d'appel, (5) des fonctions de formatage du trafic et de régulation du trafic, et (6) la possibilité que survivent des VC. Ces capacités permettent l'actualisation de diverses politiques d'ingénierie du trafic. Par exemple, des circuits virtuels peuvent facilement être réacheminés pour déplacer du trafic de ressources sur utilisées à d'autres relativement sous utilisées.

 

Pour l'ingénierie du trafic dans de grands réseaux denses, il est souhaitable d'équiper MPLS avec un niveau de fonctionnalités au moins en relation avec les modèles à recouvrement actuels. Heureusement, cela peut être fait de manière très directe.

 

3.   MPLS et l'ingénierie du trafic

 

Cette section donne une vue générale de l'applicabilité de MPLS à l'ingénierie du trafic. Les paragraphes suivants présentent l'ensemble des capacités requises pour satisfaire aux exigences de l'ingénierie du trafic.

 

MPLS a une signification stratégique pour l'ingénierie du trafic parce qu'il a un potentiel de fourniture de la plupart des fonctionnalités disponibles à partir du modèle à recouvrement de façon intégrée, et à un coût inférieur à celui des autres solutions actuellement concurrentes. Tous aussi important, MPLS offre la possibilité d'automatiser certains aspects de la fonction d'ingénierie du trafic. Cette dernière considération exige des investigations supplémentaires et sort du domaine d'application de ce document.

 

Une note sur la terminologie : le concept de circuit de trafic MPLS est largement utilisé dans la suite de ce document. Selon Li et Rekhter [3], un circuit de trafic est une agrégation de flux de trafic de la même classe qui sont placés à l'intérieur d'un chemin à commutation par étiquettes. Essentiellement, un circuit de trafic est une représentation abstraite du trafic à laquelle peuvent être associées des caractéristiques spécifiques. Il est utile de voir les circuits de trafic comme des objets qui peuvent être acheminés ; c'est-à-dire que le chemin par lequel traverse un circuit de trafic peut être changé. À cet égard, les circuits de trafic sont similaires aux circuits virtuels dans les réseaux ATM et en relais de trame. Il est cependant important de souligner qu'il existe une différence fondamentale entre un circuit de trafic et le chemin, et bien sûr le LSP, à travers lequel il passe. Un LSP est une spécification du chemin à commutation d'étiquette à travers lequel traverse le trafic. En pratique, les termes de LSP et de circuit de trafic sont souvent utilisés dans le même sens. Les caractéristiques supplémentaires des circuits de trafic qui sont utilisées dans ce document sont énoncées à la section 5.

 

L'attractivité de MPLS pour l'ingénierie du trafic peut être attribuée aux facteurs suivants :

(1) il est très facile de créer des chemins explicites à commutation d'étiquettes qui ne sont pas contraints par le paradigme de la transmission fondée sur la destination par une action administrative manuelle ou par une action automatisée avec les protocoles sous-jacents,

(2) les LSP peuvent être entretenus de façon efficace,

(3) les circuits de trafic peuvent être instanciés et transposés sur les LSP,

(4) un ensemble d'attributs peut être associé aux circuits de trafic afin de moduler leurs caractéristique comportementales,

(5) un ensemble d'attributs peut être associé aux ressources qui contraignent le placement des LSP et des circuits de trafic à travers eux,

(6) MPLS permet aussi bien l'agrégation que la désagrégation de trafic tandis que le transmission IP classique seulement fondée sur la destination ne permet que l'agrégation,

(7) il est relativement facile d'intégrer un cadre "d'acheminement fondé sur la contrainte" à MPLS,

(8) une bonne mise en œuvre de MPLS peut offrir des frais généraux significativement inférieurs à ceux des solutions de remplacement concurrentes pour l'ingénierie du trafic.

 

De plus, grâce aux chemins explicites à commutation d'étiquette, MPLS permet une quasi capacité de commutation de circuit en surimposition au modèle actuel d'acheminement Internet. Beaucoup des propositions existantes pour l'ingénierie du trafic sur MPLS se focalisent seulement sur le potentiel de création de LSP explicites. Bien que cette capacité soit fondamentale pour l'ingénierie du trafic, elle n'est pas réellement suffisante. Des adjonctions supplémentaires sont nécessaires pour alimenter l'actualisation de politiques conduisant à l'optimisation des performances de grands réseaux opérationnels. Quelques unes des adjonctions nécessaires sont décrites dans le présent document.

 

3.1   Graphe MPLS induit

 

Ce paragraphe introduit le concept d'un "graphe MPLS induit" qui est au cœur de l'ingénierie du trafic dans les domaines MPLS. Un graphe MPLS induit est analogue à une topologie virtuelle dans un modèle à recouvrement. Il est transposé logiquement sur le réseau physique par le choix des LSP pour les circuits de trafic.

 

Un graphe MPLS induit consiste en un ensemble de LSR qui comprend les nœuds du graphe et un ensemble de LSP qui donnent la connexité logique point à point entre les LSR, et servent donc de liaisons du graphe induit. Il est possible de construire des graphes MPLS induits hiérarchiques sur la base du concept de pile d'étiquettes (voir [1]).

 

Les graphes MPLS induits sont importants à cause du problème de base de la gestion de la bande passante dans un domaine MPLS qui est la question de comment transposer efficacement un graphe MPLS induit sur la topologie du réseau physique. Le graphe MPLS induit abstrait est formalisé ci-dessous.

 

Soit G = (V, E, c) un graphe qui décrit la topologie physique du réseau. Ici, V est l'ensemble des nœuds du réseau et E est l'ensemble des liaisons ; c'est-à-dire, pour v et w dans V, l'objet (v,w) est dans E si v et w sont directement connectés sous G. Le paramètre "c" est un ensemble de capacités et autres contraintes associées à E et V. On se réfèrera à G comme étant la topologie du réseau "de base".

 

Soit H = (U, F, d) le graphe MPLS induit, où U est un sous-ensemble de V représentant l'ensemble des LSR dans le réseau, ou plus précisément l'ensemble des SR qui sont les points d'extrémité d'au moins un LSP. Ici, F est l'ensemble des LSP, de sorte que pour x et y dans U, l'objet (x, y) est dans F si il y a un LSP avec x et y comme points d'extrémité. Le paramètre "d" est l'ensemble des demandes et restrictions associées à F. Évidemment, H est un graphe dirigé. On peut voir que H dépend des caractéristiques de transitivité de G.

 

3.2   Problème fondamental de l'ingénierie du trafic sur MPLS

 

À la base, il y a trois problèmes fondamentaux qui se rapportent à l'ingénierie du trafic sur MPLS.

 

-   Le premier problème concerne comment transposer les paquets dans deux classes d'équivalence de transmission.

 

-    Le second problème concerne comment transposer les classes d'équivalence de transmission en circuits de trafic.

 

-   Le troisième problème concerne comment transposer les circuits de trafic en topologie du réseau physique à travers des chemins à commutation par étiquettes.

 

Le présent document ne se focalise pas sur les deux premiers problèmes. (Bien qu'ils soient assez importants.) Le reste de ce document se concentre plutôt sur les capacités qui permettent d'effectuer la troisième fonction de transposition d'une façon qui résulte en des opérations de réseau efficaces et fiables. C'est en fait le problème de la transposition d'un graphe MPLS induit (H) sans la topologie de réseau "de base" (G).

 

4.   Capacités augmentées de l'ingénierie du trafic sur MPLS

 

Les sections précédentes passaient en revue les fonctions de base de l'ingénierie du trafic dans l'Internet contemporain. L'applicabilité de MPLS à cette activité a aussi été discutée. Les sections restantes du présent document décrivent les capacités fonctionnelles exigées pour une prise en charge complète de l'ingénierie du trafic sur MPLS dans les grands réseaux.

 

Les capacités proposées consistent en :

1.   Un ensemble d'attributs associés aux circuits de trafic qui spécifient collectivement leurs caractéristiques de comportement.

2.   Un ensemble d'attributs associés aux ressources qui contraignent le placement des circuits de trafic à travers eux. Ils peuvent aussi être vus comme des contraintes d'attributs de topologie.

3   Un cadre "d'acheminement fondé sur la contrainte" qui est utilisé pour choisir des chemins pour les circuits de trafic soumis aux contraintes imposées par les éléments 1) et 2) ci-dessus. Le cadre d'acheminement fondé sur la contrainte n'a pas à faire partie de MPLS. Cependant, l'intégration des deux doit être étroite.

 

Les attributs associés aux circuits de trafic et aux ressources, ainsi que les paramètres associés à l'acheminement, représentent collectivement les variables de contrôle qui peuvent être modifiées soit par action administrative soit par des agents automatisés pour conduire le réseau dans un état désiré.

 

Dans un réseau opérationnel, il est très souhaitable que ces attributs puissent être modifiés de façon dynamique en ligne par un opérateur sans jouer un rôle néfaste sur le fonctionnement du réseau.

 

5.   Attributs et caractéristiques des circuits de trafic

 

La présente section décrit les attributs souhaitables qui peuvent être associés à des circuits de trafic pour influencer leur caractéristiques comportementales.

 

Tout d'abord les propriétés de base des circuit de trafic (telles qu'utilisées dans ce document) sont récapitulées ci-dessous :

 

-   Un circuit de trafic est un *agrégat* de flux de trafic appartenant à la même classe. Dans certains contextes, il peut être souhaitable de relâcher cette définition et de permettre aux circuits de trafic d'inclure des agrégats de trafic multi classes.

 

-   Dans un modèle de service à classe unique, tel que l'Internet actuel, un circuit de trafic pourrait encapsuler tout le trafic entre un LSR d'entrée et un LSR de sortie, ou de leurs sous-ensembles.

 

-   Les circuits de trafic sont des objets d'acheminement (similaires aux VC en ATM).

 

-   Un circuit de trafic est distinct du LSP à travers lequel il traverse. Dans des contextes de fonctionnement, un circuit de trafic peut être déplacé d'un chemin à un autre.

 

-   Un circuit de trafic est unidirectionnel.

 

En pratique, un circuit de trafic peut être caractérisé par ses LSR d'entrée et de sortie, la classe d'équivalence de transmission sur laquelle il est transposé, et un ensemble d'attributs qui déterminent ses caractéristiques de comportement.

 

Deux questions de base sont d'une signification particulière : (1) la mise en paramètre des circuits de trafic et (2) le placement de chemin et les règles de maintenance pour les circuits de trafic.

 

5.1   Circuits de trafic bidirectionnels

 

Bien que par conception les circuits de trafic soient unidirectionnels, dans de nombreux contextes, il est utile d'instancier simultanément deux circuits de trafic avec les mêmes points de terminaison, mais qui portent des paquets dans des directions opposées. Les deux circuits de trafic sont logiquement couplés. Un circuit, appelé circuit d'émission, porte le trafic d'un nœud d'origine à un nœud de destination. L'autre circuit, appelé circuit de retour, porte le trafic du nœud de destination au nœud d'origine. On se réfère à l'amalgame de deux circuits de trafic de cette sorte comme à un circuit de trafic bidirectionnel (BTT) si les deux conditions suivantes sont réunies :

 

-   Les deux circuits de trafic sont instancié à travers une action atomique à un LSR, appelé le nœud d'origine, ou à travers une action atomique à une station de gestion de réseau.

 

-   Aucun des circuits de trafic composite ne peut exister sans l'autre. C'est-à-dire que les deux sont instanciés et détruits ensemble.

 

Les propriétés topologiques des BTT devraient aussi être examinées. Un BTT peut être topologiquement symétrique ou topologiquement asymétrique. Un BTT est dit être "topologiquement symétrique" si ses circuits de trafic constitutifs sont acheminés à travers le même chemin physique, même si ils fonctionnent dans des directions opposées. Si, cependant, les circuits de trafic constitutifs sont acheminés à travers des chemins physiques différents, le BTT est alors dit être "topologiquement asymétrique."

 

On notera que les circuits de trafic bidirectionnels sont simplement une facilité administrative. En pratique, la plupart des fonctions d'ingénierie du trafic peuvent être mises en œuvre en utilisant seulement des circuits de trafic unidirectionnels.

 

5.2   Fonctionnement de base des circuits de trafic

 

Les opérations de base sur les circuits de trafic significatives pour les besoins de l'ingénierie du trafic sont résumées ci-dessous.

-   Établir : pour créer une instance de circuit de trafic.

-   Activer : pour causer le début du passage de trafic par un circuit de trafic. L'établissement et l'activation d'un circuit de trafic sont des événements logiquement séparés. Ils peuvent cependant être mise en œuvre ou invoqués comme une action atomique.

-   Désactiver : cause l'arrêt du passage de trafic par un circuit de trafic.

-   Modifier les attributs : cause la modification des attributs d'un circuit de trafic.

-   Réacheminer : cause le changement de chemin d'un circuit de trafic. Cela peut être fait par une action administrative ou automatiquement par les protocoles sous-jacents.

-   Détruire : retirer une instance d'un circuit de trafic du réseau et réclamer toutes les ressources qui lui étaient allouées. De telles ressources incluent l'espace d'étiquette et la bande passante éventuellement disponible.

 

Les opérations ci-dessus sont considérées comme les opérations de base sur les circuits de trafic. Des opérations supplémentaires telles que la régulation et le formatage du trafic sont aussi possibles.

 

5.3   Surveillance de la comptabilité et des performances

 

Les capacités de surveillance de la comptabilité et des performances sont très importantes pour les fonctions de facturation et de caractérisation du trafic. Les statistiques de performances obtenues des systèmes de surveillance de la comptabilité et des performances peuvent être utilisées pour la caractérisation du trafic, pour l'optimisation des performances et pour la planification des capacités au sein du domaine de l'ingénierie du trafic.

 

La capacité à obtenir des statistiques au niveau du circuit de trafic est si importante qu'elle devrait être considérée comme une exigence essentielle pour l'ingénierie du trafic sur MPLS.

 

5.4   Attributs de base d'ingénierie du trafic sur les circuits de trafic

 

Un attribut d'un circuit de trafic est un paramètre qui lui est alloué et qui influence ses caractéristiques comportementales.

 

Les attributs peuvent être alloués explicitement aux circuits de trafic par une action administrative ou ils peuvent être alloués implicitement par les protocoles sous-jacents lorsque les paquets sont classés et transposés dans des classes d'équivalence à l'entrée d'un domaine MPLS. Sans considération de la façon dont les attributs ont été alloués à l'origine pour les besoins de l'ingénierie du trafic, il devrait être possible de modifier de tels attributs par voie administrative.

 

Les attributs de base des circuits de trafic particulièrement significatifs pour l'ingénierie du trafic sont énumérés ci-dessous.

- Attributs de paramètres de trafic

- Attributs de choix et de maintenance de chemin générique

- Attribut de priorité

- Attribut de préemption

- Attribut de résilience

- Attribut de régulation

 

La combinaison des paramètres de trafic et des attributs de régulation est analogue au contrôle des paramètres d'utilisation dans les réseaux ATM. La plupart des attributs énumérés ci-dessus ont un analogue dans des technologies bien établies. Par conséquent, il devrait être relativement direct de transposer les attributs de circuit de trafic dans de nombreuses architectures existantes de commutation et d'acheminement.

 

Priorité et préemption peuvent être considérés comme des attributs relationnels parce qu'ils expriment certaines relations binaires entre circuits de trafic. L'idée de ces relations binaires est de déterminer la manière dont les circuits de trafic interagissent les uns avec les autres lorsqu'ils sont en compétition pour les ressources du réseau durant l'établissement et la maintenance du chemin.

 

5.5   Attributs des paramètres de trafic

 

Les paramètres de trafic peuvent être utilisés pour capturer les caractéristiques des flux de trafic (ou plus précisément leur classe d'équivalence de transmission) à transporter à travers le circuit de trafic. De telles caractéristiques peuvent inclure des taux de crête, des taux moyens, la taille de salve permise, etc. Du point de vue de l'ingénierie du trafic, les paramètres de trafic sont significatifs parce qu'ils indiquent les exigences de ressources du circuit de trafic. Ceci est utile pour l'allocation de ressource et l'évitement d'encombrement à travers des politiques d'anticipation.

 

Pour les besoins de l'allocation de bande passante, une seule valeur canonique d'exigence de bande passante peut être calculée à partir des paramètres de trafic d'un circuit de trafic. Les techniques pour effectuer ces calculs sont bien connues. Un exemple en est la théorie de la bande passante efficace.

 

5.6   Choix générique de chemin et attributs de gestion

 

Les attributs génériques de choix et de gestion de chemin définissent les règles de choix du chemin pris par un circuit de trafic ainsi que les règles pour la maintenance des chemins qui sont déjà établis.

 

Les chemins peuvent être calculés automatiquement par les protocoles d'acheminement sous-jacents ou ils peuvent être définis administrativement par un opérateur du réseau. Si il n'y a pas d'exigences de ressources ou de restrictions associées à un circuit de trafic, un protocole fondé sur la topologie peut être utilisé pour choisir son chemin. Cependant, si des exigences de ressource ou des restrictions de politique existent, un schéma d'acheminement fondé sur la contrainte devrait alors être utilisé pour le choix du chemin.

 

Dans la Section 7 est décrit un cadre d'acheminement fondé sur la contrainte qui peut calculer automatiquement les chemins selon un ensemble de contraintes. Les questions qui relèvent du chemin explicite réalisé par une action administrative sont exposées au paragraphe 5.6.1.

 

La gestion du chemin concerne tous les aspects qui relèvent de la maintenance des chemins traversés par des circuits de trafic. Dans certains contextes de fonctionnement, il est souhaitable qu'une mise en œuvre de MPLS puisse se reconfigurer de façon dynamique pour s'adapter à certaines notions de changement de "l'état du système." Adaptabilité et la résilience sont des aspects de la gestion dynamique de chemin.

 

Pour guider le processus de choix du chemin et de la gestion, un ensemble d'attributs sont nécessaires. Les attributs de base et les caractéristiques comportementales associées au choix et à la gestion de chemin de circuit de trafic sont décrits dans les paragraphes suivants.

 

5.6.1   Chemins explicites spécifiés administrativement

Un chemin explicitement spécifié administrativement pour un circuit de trafic est configuré par l'action d'un opérateur. Un chemin spécifié administrativement peut être complètement spécifié ou partiellement spécifié. Un chemin est complètement spécifié si tous les bonds requis entre les points d'extrémité sont indiqués. Un chemin est partiellement spécifié si seul un sous-ensemble des bonds intermédiaires est indiqué. Dans ce cas, les protocoles sous-jacents sont obligés de compléter le chemin. Du fait d'erreurs de l'opérateur, un chemin spécifié administrativement peut être incohérent ou illogique. Les protocoles sous-jacents devraient être capables de détecter de telles incohérences et fournir les retours appropriés.

 

Un attribut de "règle de préférence de chemin" devrait être associée aux chemins explicites spécifiés administrativement. Un attribut de règle de préférence de chemin est une variable binaire qui indique si le chemin explicite configuré administrativement est "obligatoire" ou "non obligatoire."

 

Si un chemin explicite configuré administrativement est choisi avec un attribut "obligatoire", ce chemin (et lui seulement) doit être utilisé. Si un chemin obligatoire est topologiquement infaisable (par exemple les deux points d'extrémité sont topologiquement séparés), ou si le chemin ne peut pas être instancié parce que les ressources disponibles sont inadéquates, le processus d'établissement du chemin échoue alors. En d'autres termes, si un chemin est spécifié comme obligatoire, un chemin de remplacement ne peut pas être utilisé, sans considération des circonstances environnantes. Un chemin obligatoire qui est mis en place avec succès est aussi implicitement verrouillé. Une fois que le chemin est mis en place, il ne peut pas être changé sauf par suppression et mise en place d'un nouveau chemin.

 

Cependant, si un chemin explicite configuré administrativement est choisi avec une valeur d'attribut de règle de préférence "non obligatoire", le chemin devrait alors être utilisé si c'est faisable. Autrement, un chemin de remplacement peut être choisi à la place par les protocoles sous-jacents.

 

5.6.2   Hiérarchie des règles de préférence pour chemins multiples

Dans certains contextes pratiques, il peut être utile d'avoir la capacité de spécifier administrativement un ensemble de chemins explicites candidats pour un circuit de trafic donné et de définir une hiérarchie de relations de préférence sur les chemins. Durant l'établissement des chemins, les règles de préférence sont appliquées pour choisir un chemin convenable à partir de la liste des candidats. Dans les scénarios d'échec, les règles de préférence sont aussi appliquées pour choisir un chemin de remplacement à partir de la liste des candidats.

 

5.6.3   Attributs d'affinité de classe de ressource

Les attributs d'affinité de classe de ressource associés à un circuit de trafic peuvent être utilisés pour spécifier la classe des ressources (voir la Section 6) qui sont à inclure ou exclure explicitement du chemin du circuit de trafic. Ce sont des attributs de politique qui peuvent être utilisés pour imposer des contraintes supplémentaires au chemin traversé par un circuit de trafic donné. Les attributs d'affinité de classe de ressource pour un trafic peuvent être spécifiés comme une séquence de tuplets :

 

<classe-de-ressource, affinité>; <classe-de-ressource, affinité>; ..

 

Le paramètre classe-de-ressource identifie une classe de ressource pour laquelle une relation d'affinité est définie par rapport au circuit de trafic. Le paramètre affinité indique la relation d'affinité ; c'est-à-dire, si les membres de la classe de ressource sont à inclure ou à exclure du chemin du circuit de trafic. Précisément, le paramètre affinité peut être une variable binaire qui prend une des valeurs suivantes : (1) inclusion explicite, (2) exclusion explicite.

 

Si l'attribut affinité est une variable binaire, il pourrait être possible d'utiliser des expressions booléennes pour spécifier les affinités de classe de ressource associées à un circuit de trafic donné.

 

Si aucun attribut d'affinité de classe de ressource n'est spécifié, on suppose alors qu'une relation d'affinité "ne pas tenir compte" est supposée exister entre le circuit de trafic et toutes les ressources. C'est à dire qu'aucune exigence n'existe pour explicitement inclure ou exclure une ressources du chemin du circuit de trafic. En pratique, ce devrait être la relation par défaut.

 

Les attributs d'affinité de classe de ressource sont des constructions très utiles et puissantes parce qu'ils peuvent être utilisés pour mettre en œuvre diverses politiques. Par exemple, ils peuvent être utilisés pour contenir certains circuits de trafic au sein de régions topologiques spécifiques du réseau.

 

Un cadre "d'acheminement fondé sur la contrainte" (voir la section 7.) peut être utilisé pour calculer de la façon suivante un chemin explicite pour un circuit de trafic soumis aux contraintes d'affinité de classe de ressource :

 

1.   Pour une inclusion explicite, élaguer toutes les ressources qui n'appartiennent pas aux classes spécifiées avant d'effectuer le calcul du chemin.

 

2.   Pour une exclusion explicite, élaguer toutes les ressources qui appartiennent aux classes spécifiées avant d'effectuer les calculs de placement du chemin.

 

5.6.4   Attribut d'adaptabilité

Les caractéristiques et l'état du réseau changent avec le temps. Par exemple, de nouvelles ressources deviennent disponibles, des ressources défaillantes sont réactivées, et des ressources allouées ne le sont plus. En général, des chemins parfois plus efficaces deviennent disponibles. Donc, du point de vue de l'ingénierie du trafic, il est nécessaire d'avoir des paramètres de contrôle administratif qui peuvent être utilisés pour spécifier comment des circuits de trafic répondent à cette dynamique. Dans certains scénarios, il peut être souhaitable de changer de façon dynamique les chemins de certains circuits de trafic en réponse à des changements de l'état du réseau. Ce processus est appelé réoptimisation. Dans d'autres scénarios, la réoptimisation peut être très indésirable.

 

Un attribut d'adaptabilité fait partie des paramètres de maintenance du chemin associés aux circuits de trafic. L'attribut d'adaptabilité associé à un circuit de trafic indique si le circuit est soumis à réoptimisation. C'est-à-dire qu'un attribut d'adaptabilité est une variable binaire qui prend une des valeurs suivantes : (1) permettre la réoptimisation, (2) désactiver la réoptimisation.

 

Si la réoptimisation est activée, un circuit de trafic peut alors être rerouté sur des chemins différents par les protocoles sous-jacents en réponse à des changements de l'état du réseau (principalement des changements de disponibilité des ressources). À l'inverse, si la réoptimisation est désactivée, le circuit de trafic est alors "cloué" au chemin établi et ne peut pas être rerouté en réponse aux changements de l'état du réseau.

 

La stabilité est un souci majeur lorsque la réoptimisation est permise. Pour favoriser la stabilité, une mise en œuvre de MPLS ne devrait être trop réactive à la dynamique de l'évolution du réseau. En même temps, elle doit s'adapter assez vite pour une utilisation optimale des investissements du réseau. Cela implique que la fréquence de la réoptimisation devrait être configurable administrativement pour permettre les réglages.

 

On doit noter que la réoptimisation est distincte de la résilience. Un attribut différent est utilisé pour spécifier les caractéristiques de résilience d'un circuit de trafic (voir le paragraphe 5.9). En pratique, il semblerait raisonnable de s(attendre à ce que des circuits de trafic soumis à réoptimisation soient implicitement résilients aux défaillances le long de leur chemin. Cependant, on peut aussi exiger d'un circuit de trafic qui n'est pas soumis à réoptimisation et dont le chemin n'est pas administrativement spécifié avec un attribut "obligatoire" qu'il soit résilient aux défaillances de nœuds et de liaisons le long du chemin établi

 

De façon formelle, on peut dire que l'adaptabilité à l'évolution d'état par la réoptimisation implique la résilience aux défaillances, tandis que la résilience aux défaillances n'implique pas une adaptabilité générale à travers la réoptimisation aux changements d'état.

 

5.6.5   Répartition de charge sur des circuits de trafic parallèles

La répartition de charge sur plusieurs circuits de trafic parallèles entre deux nœuds est une importante considération. Dans de nombreux contextes pratiques, le trafic agrégé entre deux nœuds peut être tel qu'aucune liaison unique (et donc aucun chemin unique) ne peut en porter la charge. Cependant, le flux agrégé pourrait être inférieur au flux maximum permis sur un "min-cut" qui partitionne les deux nœuds. Dans ce cas, la seule solution praticable est de diviser de façon appropriée le trafic agrégé en sous flux et d'acheminer les sous flux à travers plusieurs chemins entre les deux nœuds.

 

Dans un domaine MPLS, ce problème peut être réglé en instanciant plusieurs circuits de trafic entre les deux nœuds, de telle sorte que chaque circuit de trafic porte une proportion égale du trafic agrégé. Donc, un moyen souple d'allocation de charge à plusieurs circuits de trafic parallèles portant le trafic entre une paire de nœuds est exigé.

 

Précisément, d'un point de vue opérationnel, dans les situations où des circuits de trafic parallèles sont garantis, il serai utile d'avoir quelque attribut qui puisse indiquer la proportion relative de trafic que chaque circuit de trafic doit porter. Les protocoles sous-jacents vont alors transposer la charge sur les circuits de trafic conformément aux proportions spécifiées. Il est aussi généralement souhaitable de maintenir l'ordre des paquets entre ceux qui appartiennent au même micro flux (mêmes adresse de source, adresse de destination, et numéro d'accès).

 

5.7   Attribut de priorité

 

L'attribut de priorité définit l'importance relative des circuits de trafic. Si on utilise un cadre d'acheminement fondé sur la contrainte avec MPLS, les priorités deviennent alors très importantes parce qu'elles peuvent être utilisées pour déterminer l'ordre dans lequel est fait le choix du chemin pour les circuits de trafic à l'établissement de la connexion et dans les scénarios de faute.

 

Les priorités sont aussi importantes dans les mises en œuvre qui permettent la préemption parce qu'elles peuvent être utilisées pour imposer à l'ensemble des circuits de trafic un ordre partiel conforme aux politiques de préemption qui sont en vigueur.

 

5.8   Attribut de préemption

 

L'attribut de préemption détermine si un circuit de trafic peut prendre le pas sur un autre circuit de trafic provenant d'un chemin donné, et si un autre circuit de trafic peut prendre le pas sur un circuit de trafic spécifique. La préemption est utile à la fois pour les objectifs de performances orientés trafic et orientés ressource. La préemption peut être utilisée pour garantir que les circuits de trafic à haute priorité peuvent toujours être acheminés par des chemins relativement favorables au sein d'un environnement de services différenciés.

 

La préemption peut aussi être utilisée pour mettre en œuvre diverses politiques de restauration affectées de priorités à la suite d'événements de faute.

 

L'attribut de préemption peut être utilisé pour spécifier quatre modes de préemption pour un circuit de trafic : (1) préempteur activé, (2) non préempteur, (3) préemptable, (4) non préemptable. Un circuit de trafic préempteur activé peut préempter les circuits de trafic de priorité inférieure désignés comme préemptables. Un trafic spécifié comme non préemptable ne peut pas être préempté par un autre circuit, sans considération des priorités relatives. Un circuit de trafic désigné comme préemptable peut être préempté par des circuits à priorité supérieure qui ont préempteur activé.

 

Il est évident que certains des modes de préemption s'excluent mutuellement. En utilisant le schéma de numérotation donné ci-dessus, les combinaisons faisables de mode de préemption pour un circuit de trafic donné sont les suivantes : (1, 3), (1, 4), (2, 3), et (2, 4). La combinaison (2, 4) devrait être celle par défaut.

 

Un circuit de trafic, disons "A", peut préempter un autre circuit de trafic, disons "B", seulement si *toutes* les cinq conditions suivantes sont réunies : (i) "A" a une priorité relativement supérieure à celle de "B", (ii) "A" est en compétition pour une ressource utilisée par "B", (iii) la ressource ne peut pas s'accommoder concurremment de "A" et de "B" sur la base d'un certain critère de décision, (iv) "A" à préempteur activé, (v) "B" est préemptable.

 

La préemption n'est pas considérée comme un attribut obligatoire dans le modèle actuel de service au mieux de l'Internet bien qu'il soit utile. Cependant, dans un scénario de services différenciés, le besoin de la préemption se fait plus pressant. De plus, dans les architectures émergeantes d'inter réseau optique, où certaines fonctions de protection et de restauration peuvent migrer d'éléments de la couche optique à des éléments de la couche réseau (comme les routeurs à commutation d'étiquette gigabit et térabit) pour réduire les coûts, les stratégies de préemption peuvent être utilisées pour réduire le délai de restauration pour les circuits de trafic à priorité supérieure dans des conditions de faute.

 

5.9   Attribut de résilience

 

L'attribut de résilience détermine le comportement d'un circuit de trafic dans des conditions de faute. C'est à dire, lorsque une faute survient le long d'un chemin que traverse le circuit de trafic. Les problèmes de base suivants doivent être réglés dans de telles circonstances : (1) détection de la faute, (2) notification de défaillance, (3) récupération et restauration du service. Évidemment, une mise en œuvre de MPLS devra incorporer des mécanismes pour régler ces questions.

 

De nombreuses politiques de récupération peuvent être spécifiées pour les circuits de trafic dont les chemins établis sont impactés par des fautes. Voici des exemples de schémas praticables :

 

1.   Ne pas réacheminer le circuit de trafic. Par exemple, un schéma de survivance peut déjà être en place, approvisionné par un mécanisme de remplacement, qui garantit la continuité du service dans les scénarios de défaillance sans avoir besoin de réacheminer les circuits de trafic. Un exemple d'un tel schéma de solution de remplacement (il en existe certainement beaucoup d'autres) est une situation dans laquelle plusieurs chemins parallèles à commutation d'étiquette sont approvisionnés entre deux nœuds, et fonctionnent de telle manière que la défaillance d'un LSP cause la transposition du circuit de trafic placé sur lui dans les LSP restants conformément à une politique bien définie.

 

2.   Réacheminer par un chemin praticable avec des ressources suffisantes. Si aucun n'existe, on ne fait pas de réacheminement.

 

3.   Réacheminer par tout chemin disponible sans considération des contraintes de ressources.

 

4.   De nombreux autres schémas sont possibles, y compris de combinaisons de ceux ci-dessus.

 

Un attribut de résilience "de base" indique la procédure de récupération à appliquer aux circuits de trafic dont les chemins sont impactés par des fautes. Précisément, un attribut de résilience "de base" est une variable binaire qui détermine si le circuit de trafic cible est à réacheminer lorsque des segments de son chemin sont défaillants. Des attributs de résilience "étendus" peuvent être utilisés pour spécifier des mesures détaillées à prendre dans des scénarios de faute. Par exemple, un attribut de résilience étendu pourrait spécifier un ensemble de chemins de remplacement à utiliser dans des conditions de faute, ainsi que les règles qui gouvernent la préférence relative de chaque chemin spécifié.

 

Les attributs de résilience rendent obligatoire une interaction étroite entre MPLS et l'acheminement.

 

5.10   Attribut de régulation

 

L'attribut de régulation détermine les mesures qui devraient être prises par les protocoles sous-jacents lorsque un circuit de trafic devient non conforme. C'est à dire, lorsque un circuit de trafic excède son contrat tel que spécifié dans les paramètres de trafic. Généralement, les attributs de régulation peuvent indiquer si un circuit de trafic non conforme doit être limité en débit, étiqueté ou simplement transmis sans aucune action de régulation. Si la régulation est utilisée, des adaptations des algorithmes établis tels que le GCRA [11] de l'ATM Forum peuvent alors être utilisés pour remplir cette fonction.

 

La régulation est nécessaire dans de nombreux scénarios de fonctionnement, mais est assez indésirable dans certains autres. En général, il est habituellement souhaitable de réguler à l'entrée d'un réseau (pour mettre en application la conformité aux accords de niveau de service) et pour minimiser la régulation au sein du cœur, sauf lorsque les contraintes de capacité en décident autrement.

 

Donc, du point de vue de l'ingénierie du trafic, il est nécessaire d'être capable d'activer ou désactiver administrativement la régulation du trafic pour chaque circuit de trafic.

 

6.   Attribut de ressources

 

Les attributs de ressource font partie des paramètres d'état de la topologie, qui sont utilisés pour contraindre l'acheminement des circuits de trafic à travers des ressources spécifiques.

 

6.1   Multiplicateur d'allocation maximum

 

Le multiplicateur d'allocation maximum (MAM, maximum allocation multiplier) d'une ressource est un attribut administrativement configurable qui détermine la proportion des ressources qui est disponible pour l'allocation aux circuits de trafic. Cet attribut est principalement applicable à la bande passante de la liaison. Cependant, il peut aussi être appliqué aux ressources de mémoire tampon sur les LSR. Le concept de MAM est analogue aux concepts de facteurs d'abonnement et de réservation dans les réseaux en relais de trame et ATM.

 

Les valeurs du MAM peuvent être choisies de telle sorte qu'une ressource puisse être sous allouée ou sur allouée. Une ressource est dite sous allouée si les demandes agrégées de tous les circuits de trafic (comme exprimé dans les paramètres de circuits de trafic) qui peuvent lui être alloués sont toujours inférieures à la capacité de la ressource. Une ressource est dite sur allouée si les demandes agrégées de tous les circuits de trafic qui lui sont alloués peuvent dépasser la capacité de la ressource.

 

La sous allocation peut être utilisée pour limiter l'utilisation des ressources. Cependant, la situation dans MPLS est plus complexe que dans les schémas de commutation de circuits parce que sous MPLS, certains flux peuvent être acheminés via des protocoles bond par bond conventionnels (et aussi via des chemins explicites) sans considération des contraintes de ressource.

 

La sur allocation peut être utilisée pour tirer parti des caractéristiques statistiques du trafic afin de mettre en œuvre des politiques plus efficaces d'allocation de ressources. En particulier, la sur allocation peut être utilisée dans des situations où les pointes de demandes de circuits de trafic ne coïncident pas dans le temps.

 

6.2   Attribut de classe de ressource

 

Les attributs de classe de ressource sont des paramètres alloués administrativement qui expriment une notion de "classe" pour les ressources. Les attributs de classe de ressource peuvent être vus comme des "couleurs" allouées aux ressources de telle sorte que l'ensemble des ressources qui ont la même "couleur" appartiennent conceptuellement à la même classe Les attributs de classe de ressource peuvent être utilisés pour mettre en œuvre diverses politiques. La ressources clé intéressante ici est la liaison. Lorsque elle s'applique aux liaisons, l'attribut de classe de ressource devient effectivement un aspect des paramètres "d'état de liaison".

 

Le concept d'attributs de classe de ressource est une abstraction puissante. Du point de vue de l'ingénierie du trafic, il peut être utilisé pour mettre en œuvre de nombreuses politiques à l'égard de l'optimisation des performances aussi bien orientées trafic que ressource. Précisément, les attributs de classe de ressource peuvent être utilisés pour :

1.   Appliquer des politiques uniformes à un ensemble de ressources qui ne sont pas nécessairement dans la même région topologique.

2.   Spécifier la préférence relative d'ensembles de ressources pour le placement du chemin de circuits de trafic.

3.   Restreindre explicitement le placement des circuits de trafic à des sous ensembles spécifiques de ressources.

4.   Mettre en œuvre des politiques généralisées d'inclusion/exclusion.

5.   Mettre en application des politiques de confinement local du trafic. C'est à dire, des politiques qui cherchent à contenir le trafic local au sein de régions topologiques spécifiques du réseau.

 

De plus, les attributs de classe de ressource peuvent être utilisés pour des besoins d'identification.

 

En général, une ressource peut être allouée à plus d'un attribut de classe de ressource. Par exemple, toutes les liaisons OC-48 dans un réseau donné peuvent être allouées à un attribut de classe de ressource distinctif. Les sous-ensembles de liaisons OC-48 qui existent avec un domaine d'abstraction du réseau peuvent être allouées à des attributs de classe de ressource supplémentaires afin de mettre en œuvre des politiques de confinement spécifiques, ou pour structurer le réseau d'une certaine manière.

 

7.   Acheminement fondé sur la contrainte

 

Cette section expose les questions qui touchent à l'acheminement fondé sur la contrainte dans les domaines MPLS. Dans la terminologie contemporaine, acheminement fondé sur la contrainte est souvent appelé "acheminement par la qualité de service" voir [5, 6, 7, 10].

 

Ce document utilise cependant le terme "acheminement fondé sur la contrainte", parce qu'il traduit mieux la fonctionnalité considérée, qui englobe généralement l'acheminement par qualité de service comme un de ses sous-ensembles.

 

L'acheminement fondé sur la contrainte permet la coexistence du paradigme de l'acheminement fondé sur la demande à capacité de réservation de ressource avec les protocoles actuels de passerelle intérieure de l'Internet bond par bond fondé sur la topologie.

 

Un cadre d'acheminement fondé sur la contrainte utilise ce qui suit comme entrées :

-   les attributs associés aux circuits de trafic,

-   les attributs associés aux ressources,

-   les autres informations d'état de topologie.

 

Sur la base de ces informations, un processus d'acheminement fondé sur la contrainte sur chaque nœud calcule automatiquement des chemins explicites pour chaque circuit de trafic originaire du nœud. Dans ce cas, un chemin explicite pour chaque circuit de trafic est une spécification de chemin par commutation d'étiquettes qui satisfait aux exigences de demande exprimées dans les attributs du circuit, sous réserve des contraintes imposées par la disponibilité des ressources, de la politique administrative, et des autres informations d'état de topologie.

 

Un cadre d'acheminement fondé sur la contrainte peut largement réduire le niveau de configuration manuelle et d'intervention requis pour actualiser les politiques d'ingénierie du trafic.

 

En pratique, l'ingénieur trafic, un opérateur, ou même un automate, va spécifier les points d'extrémité d'un circuit de trafic et allouer un ensemble d'attributs au circuit qui encapsule les attentes de performances et les caractéristiques comportementales du circuit. Le cadre d'acheminement fondé sur la contrainte est alors supposé trouver un chemin praticable pour satisfaire aux attentes. Si nécessaire, l'ingénieur trafic ou un système de prise en charge de l'ingénierie du trafic peut alors utiliser des chemins explicites configurés administrativement pour effectuer une optimisation plus fine.

 

7.1   Caractéristiques de base de l'acheminement fondé sur la contrainte

 

Un cadre d'acheminement fondé sur la contrainte devrait au moins avoir la capacité d'obtenir automatiquement une solution de base praticable au problème du placement du chemin du circuit de trafic.

 

En général, le problème de l'acheminement fondé sur la contrainte est réputé être intraitable pour la plupart des contraintes réalistes. Cependant, en pratique, une heuristique très simple bien connue (voir par exemple [9]) peut être utilisée pour trouver un chemin praticable si il en existe un :

-   Élaguer d'abord les ressources qui ne satisfont pas aux exigences des attributs du circuit de trafic.

-   Ensuite, appliquer un algorithme de plus court chemin sur le graphe résiduel.

 

Il apparaît clairement que si un chemin praticable existe pour un seul circuit de trafic, la procédure simple ci-dessus va le trouver. Des règles supplémentaires peuvent être spécifiées pour résoudre les conflits et d'autres optimisations. En général, les conflits devraient être résolus de façon que l'encombrement soit minimisé. Lorsque plusieurs circuits de trafic sont à acheminer, il peut cependant être démontré que l'algorithme ci-dessus ne peut pas toujours trouver une correspondance même lorsque existe une transposition praticable.

 

7.2   Considérations de mise en œuvre

 

De nombreuses mises en œuvre commerciales de commutation de relais de trame et d'ATM prennent déjà en charge des notions d'acheminement fondé sur la contrainte. Pour de tels appareils ou pour le nouvel engin centré sur MPLS imaginé à partir de là, il devrait être relativement facile d'étendre les mises en œuvre actuelles d'acheminement fondé sur la contrainte à s'accommoder des exigences particulières de MPLS.

 

Pour les routeurs qui utilisent des IGP bond par bond fondés sur la topologie, l'acheminement fondé sur la contrainte peut être incorporé d'au moins une des façons suivantes :

 

1.   En étendant les protocole IGP actuels comme OSPF et IS-IS pour qu'ils prennent en charge l'acheminement fondé sur la contrainte. L'effort est déjà entrepris pour fournir de telles extensions à OSPF (voir [5, 7]).

 

2.   En ajoutant un processus d'acheminement fondé sur la contrainte à chaque routeur qui peut coexister avec les IGP actuels. Ce scénario est décrit dans la Figure 1.

 

                                                      ---------------------------------------------

                                                      |           Interface de gestion            |

                                                      ---------------------------------------------

                                                       |                 |                      |

                                                ------------    -------------------------   ---------------

                                                | MPLS     |<->| Processus d'acheminement| | Processus IGP |

                                                |          |   | fondé sur la contrainte | | conventionnel |

                                                ------------    -------------------------   ---------------

                                                                   |                          |

                                                -----------------------------------   -----------------

                                                | Base de données de disponibilité | | Base de données |

                                                |    d'attribut de ressource       | |d'état de liaison|

                                                -----------------------------------   -----------------

 

Figure 1 : Processus d'acheminement fondé sur la contrainte sur un LSR de couche 3

 

De nombreux détails importants associés à la mise en œuvre de l'acheminement fondé sur la contrainte sur des appareils de couche 3 ne sont pas abordés ici. Parmi eux se trouvent ceux qui suivent :

-   Les mécanismes pour l'échange des informations d'état de topologie (informations de disponibilité des ressources, informations d'état de la liaison, informations sur les attributs de la ressource) entre les processus d'acheminement fondé sur la contrainte.

-   Les mécanismes pour la maintenance des informations d'état de la topologie.

-   Les interaction entre les processus d'acheminement fondé sur la contrainte et les processus conventionnels d'IGP.

-   Les mécanismes pour s'accommoder des exigences d'adaptabilité des circuits de trafic.

-   Les mécanismes pour s'accommoder des exigences de résilience et de survie des circuits de trafic.

 

En résumé, l'acheminement fondé sur la contrainte aide à l'optimisation des performances des réseaux opérationnels en trouvant automatiquement des chemins praticables qui satisfont à un ensemble de contraintes pour les circuits de trafic. Il peut réduire de façon drastique la quantité de configuration administrative explicite des chemins et les intervention manuelles exigée pour réaliser les objectifs de l'ingénierie du trafic.

 

8.   Conclusion

 

Le présent document présente un ensemble d'exigences pour l'ingénierie du trafic sur MPLS. De nombreuses capacités ont été décrites qui visent à améliorer l'applicabilité de MPLS à l'ingénierie du trafic dans l'Internet.

 

On devrait noter que certaines des questions décrites ici peuvent être réglées en incorporant un ensemble minimal d'éléments dans MPLS, puis en utilisant une superstructure de gestion de réseau pour étendre les fonctionnalités afin de réaliser les exigences. Aussi, le cadre de l'acheminement fondé sur la contrainte n'a pas à faire partie du cœur des spécifications MPLS. Cependant, MPLS exige des interactions avec un cadre d'acheminement fondé sur la contrainte afin de satisfaire à ces exigences.

 

9.   Considérations pour la sécurité

 

Le présent document n'introduit aucun nouveau problème de sécurité en plus de ceux inhérents à MPLS et peut utiliser les mêmes mécanismes que proposés pour cette technologie. Il est cependant particulièrement important que la manipulation des paramètres administrativement configurables soit exécutée d'une façon sécurisée par des entités autorisées.

 

10.   Références

 

[1]   E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", RFC3031, janvier 2001. (P.S.)

 

[2]   R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow et A. Viswanathan, "Cadre pour la commutation par étiquettes multi protocoles", Travail en cours.

 

[3]   T. Li, Y. Rekhter, "Architecture fournisseur pour les services différenciés et l'ingénierie du trafic (PASTE)", RFC2430, octobre 1998. (Info.)

 

[4]   Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, "Généralités sur l'architecture de commutation d'étiquettes de Cisco Systems", RFC2105, février 1997. (Information)

 

[5]   Z. Zhang, C. Sanchez, B. Salkewicz et E. Crawley "Extensions de qualité de service à OSPF", Travail en cours.

 

[6]   E. Crawley et autres, "Cadre pour l'acheminement fondés sur la qualité de service dans l'Internet", RFC2386, août 1998. (Information)

 

[7]   G. Apostolopoulos et autres, "Mécanismes d'acheminement selon la QS et extensions OSPF", RFC2676, août 1999. (Expérimentale)

 

[8]   C. Yang and A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks," IEEE Network Magazine, Volume 9, n° 5, juillet/août 1995.

 

[9]   W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to Quality of Service Constraints in Integrated Communication Networks," IEEE Network, juillet 1995, pp 46-55.

 

[10]   ATM Forum, "Traffic Management Specification: Version 4.0" avril 1996.

 

11.   Remerciements

 

Les auteurs tiennent à remercier Yakov Rekhter pour sa révison d'un projet antérieur de ce document. Les auteurs tiennent aussi à remercier Louis Mamakos et Bill Barns pour leur suggestions utiles, et Curtis Villamizar qui a apporté des corrections utiles.

 

12.   Adresse des auteurs

 

Daniel O. Awduche

Joe Malcolm

Johnson Agogbua

UUNET (MCI Worldcom)

UUNET (MCI Worldcom)

UUNET (MCI Worldcom)

3060 Williams Drive

3060 Williams Drive

3060 Williams Drive

Fairfax, VA 22031

Fairfax, VA 22031

Fairfax, VA 22031

téléphone : +1 703-208-5277

téléphone : +1 703-206-5895

téléphone : +1 703-206-5794

mél : awduche@uu.net

mél : jmalcolm@uu.net

mél : ja@uu.net

 

Mike O'Dell

Jim McManus

UUNET (MCI Worldcom)

UUNET (MCI Worldcom)

3060 Williams Drive

3060 Williams Drive

Fairfax, VA 22031

Fairfax, VA 22031

téléphone : +1 703-206-5890

téléphone : +1 703-206-5607

mél : mo@uu.net

mél : jmcmanus@uu.net

 

13.   Déclaration de droits de reproduction

 

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

 

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

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

 

Remerciement

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