3.    MPLS sur ATM et QoS

1.6   Encapsulation des étiquettes dans les VPI/VCI :

Le format exact d’une étiquette, et la manière avec laquelle cette étiquette est ajoutée au paquet, dépend de la technologie utilisée au niveau de la couche liaison de données (couche 2) dans le réseau MPLS considéré. Par exemple, une étiquette peut correspondre à un VPI/VCI ATM (Virtual Path Identifier / Virtual Channel Identifier), à un DLCI Frame Relay (Data Link Channel Identifier) ou à une longueur d’onde DWDM (Dense Wavelength Division Multiplexing) dans les réseaux optiques. Pour d’autres types de couches de niveau 2, comme par exemple Ethernet ou PPP (Point-to-Point Protocol), l’étiquette est directement ajoutée au paquet de données dans une entête MPLS « shim », qui est placée entre les entêtes des couches 2 et 3.

Dans le cas d’un réseau MPLS sur ATM, l’étiquette correspond à un VPI/VCI ATM dont le format est donné par la figure suivante.

Figure15 : Encapsulation d’étiquettes dans un VPI/VCI ATM.

Seul le champ « Label » sur 20 bits, contenant la valeur de l’étiquette, est conservé.

Le champ VPI/VCI peut contenir une ou deux étiquettes. Ce nombre étant négociable par le protocole LDP. Les champs PT (Payload Type), CLP (Cell Loss Priority), et HEC (Header Error Control) restent inchangés.

1.7   Route explicite :

Une route explicite est un enchaînement précis d’étapes entre l’entrée et la sortie d’un réseau MPLS. Un LSP peut être configuré pour suivre un chemin explicite, c’est-à-dire une liste d’adresses IP. Cependant, il n’est pas nécessaire que ce chemin soit décrit entièrement.

Par exemple, la route peut se limiter à spécifier uniquement les deux premiers sauts à effectuer. Après que le dernier saut faisant partie de la spécification aie été atteint, le routage des LSPs s’effectue suivant le routage dit de « saut par saut ».

De plus, une partie de route explicite n’est pas nécessairement spécifiée autant en détail. Un ensemble de noeuds peut être considéré comme une étape dans la route, par exemple en utilisant un préfixe IP plutôt qu’une adresse précise. Le LSP doit alors être routé jusqu’à un ou certains des noeuds faisant partie de cet ensemble de noeud. La route peut contenir plusieurs sauts faisant partie de l’ensemble de noeuds avant d’émerger jusqu’au prochain saut spécifié par la route explicite.

D’autre part, une route explicite peut être qualifiée de stricte (strict) ou de non-stricte (loose). Une route stricte doit contenir seulement les noeuds spécifiés par la route explicite, et doit les utiliser dans l’ordre préétablit. Une route non-stricte doit inclure tous les sauts spécifiés, et doit conserver l’ordre, mais peut également inclure des sauts supplémentaires et nécessaires pour joindre les noeuds spécifiés.

Les routes explicites sont particulièrement utiles pour contraindre un LSP à utiliser un chemin différent de celui préconisé par le protocole de routage. Elles peuvent également être utilisées pour répartir le trafic dans un réseaux chargé, pour établir des routes contournant les points de congestion ou défaillants, ou pour fournir des LSPs de secours pré-alloués en cas de panne du réseau.  

1.8   Route basée contrainte :

L’appellation route basée contrainte provient de la traduction directe du terme anglais « Constraint Based Routes (CBR) ». La route qu’emprunte un  LSP peut être forcée à partir du LSR d’entrée du réseau selon certains critères, dont le nombre est assez important. Une route explicite est un exemple de route basée contrainte, où la contrainte est l’ordre dans lequel les LSRs intermédiaires doivent être joints. D’autres types de contraintes peuvent être imposées par une description précise du trafic devant être assuré. Dans ce cas sont définis la bande passante, le délai, les classes et priorités des différentes ressources.

Une approche consiste à ce que le LSR d’entrée calcule entièrement la route basée contrainte en se fondant sur les contraintes et les informations de l’état actuel du réseau. Ceci conduit à l’établissement d’une route  explicite satisfaisant les contraintes énoncées.

Une autre approche possible consiste à faire varier le routage saut par saut, où à chaque LSR, le saut suivant est calculé en utilisant les informations détenues par ce LSR et concernant la disponibilité des ressources locales.

Ces deux approches peuvent être combinées, notamment lorsque l’information de segments de route est indisponible, par exemple, lors de la traversée d’un système autonome. Dans ce cas, la route peut être spécifiée en partie, et ce non-strictement, puis routée explicitement en utilisant les contraintes là où elles sont requises. 

1.9   Le protocole CR-LDP :

CR-LDP est une version étendue de LDP spécialement destinée à faciliter le routage basé sur la contrainte des LSPs. Tout comme, LDP, CR-LDP utilise des sessions TCP entre les LSRs, au cours desquelles il envoie les messages de distribution des étiquettes. Ceci permet en particulier à CR-LDP d’assurer une distribution fiable des messages de contrôle.

Les échanges d’informations nécessaires à l’établissement des LSPs utilisant CR-LDP sont décrits dans la figure suivante.

Figure 16 :Procédure d’établissement des LSPs avec CR-LDP.

• Le LSR d’entrée (LSR A) détermine qu’il est nécessaire d’établir un nouveau LSP jusqu’au LSR C. Les paramètres et critères de trafic requis pour la session permettent au LSR A de déterminer que la route pour le nouveau LSP doit passer par le LSR B, puis aller vers le LSR C. Cette route n’est d’ailleurs vraisemblablement pas la même que la route saut par saut pour aller du LSR A jusqu’au LSR C. Le LSR A construit alors un message LABEL_REQUEST contenant une route explicite (B, C) et les détails des paramètres de trafic demandés pour la nouvelle route. Le LSR A réserve les ressources dont il a besoin pour le nouveau LSP, et envoie le message LABEL_REQUEST constitué vers le LSR B en utilisant une session TCP.

• Le LSR B reçoit le message LABEL_REQUEST, détermine qu’il ne doit pas être considéré comme le LSR de sortie vis-à-vis de ce LSP, et qu’il doit donc envoyer le message sur la route spécifiée. Le LSR B réserve alors les ressources nécessaires pour le nouveau LSP, modifie la route explicite dans le message LABEL_REQUEST, et envoie le message au LSR C. Il faut noter que si les paramètres de trafic étaient marqués comme étant négociables dans le message LABEL_REQUEST, le LSR B pourrait alors réduire la réservation des ressources allouées au nouveau LSP.

• Le LSR C  reçoit à son tour le message LABEL_REQUEST, et détermine qu’il est bien le LSR de sortie pour ce nouveau LSP. Il effectue alors les dernières négociations de ressources puis les alloue au LSP. Le LSR C attribue ensuite une étiquette au nouveau LSP et distribue cette étiquette au LSR B dans un message LABEL_MAPPING, qui contient les détails des paramètres finaux du trafic réservé pour le LSP.

• Le LSR B reçoit le message LABEL_MAPPING et le fait correspondre à la demande originale en utilisant l’identité du LSP contenue à la fois dans les messages LABEL_REQUEST et LABEL_MAPPING. Le LSR B finalise les réservations de ressources, attribue une étiquette au LSP, configure sa table de routage, et envoie la nouvelle étiquette au LSR A dans un message LABEL_MAPPING.

• Le processus est le même au niveau du LSR A, mais celui-ci n’a pas à attribuer une nouvelle étiquette et à la propager vers les LSRs amonts, puisqu’il est le LSR d’entrée pour ce nouveau LSP.

Un LSP, appelé CR-LSP (Constrained Route -Label Switched Path) est alors établit entre le LSR d’entrée et celui de sortie.

1.10                   Le protocole RSVP :

Le protocole RSVP utilisait initialement un échange de message pour réserver les ressources des flux IP à travers un réseau. Une version étendue de ce protocole, en particulier pour permettre les tunnels de LSP, autorise actuellement RSVP à être utilisé pour distribuer des étiquettes MPLS.

RSVP est un protocole complètement séparé de la couche IP, qui utilise des datagrammes IP (ou UDP (User Datagram Protocol) aux limites du réseau) pour communiquer entre LSRs. RSVP ne requiert pas la maintenance nécessaire aux connexions TCP, mais doit néanmoins être capable de faire face à la perte de messages de contrôle.

Les échanges d’informations nécessaires à l’établissement de LSP permettant les tunnels de LSP et utilisant RSVP sont décrits dans la figure suivante.

Figure 17 : Procédure d’établissement des LSPs pour tunnels de LSP avec RSVP.

• Le LSR d’entrée (LSR A) détermine qu’il est nécessaire d’établir un nouveau LSP jusqu’au LSR C. Les paramètres et critères de trafic requis pour la session permettent au LSR A de déterminer que la route pour le nouveau LSP doit passer par le LSR B, puis aller vers le LSR C. Cette route n’est d’ailleurs vraisemblablement pas la même que la route saut par saut pour aller du LSR A jusqu’au LSR C. Le LSR A construit alors un message de chemin (Path message) contenant une route explicite (B, C) et les détails des paramètres de trafic demandés pour la nouvelle route. Le LSR A envoie le message de chemin comme datagramme IP vers le LSR B.

• Le LSR B reçoit le message de chemin, détermine qu’il ne doit pas être considéré comme le LSR de sortie vis-à-vis de ce LSP, et qu’il doit donc envoyer le message sur la route spécifiée. Le LSR B modifie alors la route explicite dans le message de chemin, et envoie le message au LSR C.

• Le LSR C reçoit à son tour le message de chemin, et détermine qu’il est bien le LSR de sortie pour ce nouveau LSP. En fonction des paramètres de trafic demandés, le LSR C détermine la bande passante nécessaire pour réserver et allouer les ressources. Le LSR C attribue ensuite une étiquette au nouveau LSP et distribue cette étiquette au LSR B dans un message Resv, qui contient les détails de la réservation des ressources pour le LSP.

• Le LSR B reçoit le message Resv et le fait correspondre à la demande originale en utilisant l’identité du LSP contenue à la fois dans les messages de chemin (Path message) et Resv. A partir des détails du message Resv, le LSR B détermine quelles ressources doivent être réservées, attribue une étiquette au LSP, configure sa table de routage, et envoie la nouvelle étiquette au LSR A dans un message Resv.

• Le processus est le même au niveau du LSR A, mais celui-ci n’a pas à attribuer une nouvelle étiquette et à la propager vers les LSRs amonts, puisqu’il est le LSR d’entrée pour ce nouveau LSP.

Un LSP, appelé CR-LSP (Constrained Route -Label Switched Path) est alors établit entre le LSR d’entrée et celui de sortie.

1.11                   Comparaison CR-LDP et RSVP :

Les principales différences entre CR-LDP et RSVP sont essentiellement la fiabilité des protocoles de transport utilisés (IP dans le cas de RSVP et TCP dans le cas de CR-LDP), et le sens dans lequel s’effectue les réservations de ressources (sens montant pour RSVP et sens descendant pour CR-LDP).

Ces différences, ainsi que d’autres, sont résumées dans le tableau ci-dessous :

Tableau 13 : comparatif : CR-LDP versus RSVP.

RSVP et CR-LDP s’avèrent être tous les deux de bonnes solutions techniques pour la configuration et la gestion de LSPs utilisant le Traffic Engineering.

Les différences, tant dans la structure de ces protocoles que dans les protocoles de transport associés, permettent de conclure que l’apport inhérent à RSVP et à CR-LDP ne pourront jamais converger complètement. De plus, les différences mises en avant plus haut, ainsi que celles de vitesse et de possibilité de déploiement seront les principaux facteurs permettant de faire un choix entre ces deux protocoles.

1.12                   Traffic Engineering :

Le Traffic Engineering (TE), ou gestion de trafic, consiste à router les données à travers le réseau suivant une vision de management de la disponibilité des ressources, et du trafic courant et attendu. La classe de service et la qualité de service requises pour les données peuvent aussi être prises en compte.

Le Traffic Engineering peut être sous le contrôle d’opérateurs manuels. Ils surveillent l’état du réseau et routent le trafic ou réservent des ressources supplémentaires pour pouvoir faire face à d’éventuels problèmes naissant. De manière alternative, le Traffic Engineering peut aussi être mené par des processus automatisés, réagissant aux informations relatives à l’état du réseau qui sont envoyées entre autres par les protocoles de routage.

Le Traffic Engineering aide le fournisseur de réseau à optimiser au mieux les ressources disponibles, répartissant la charge des liaisons de niveau 2, et autorisant quelques liaisons à être réservées pour certaines classes de trafic, ou pour des clients particuliers.

Ainsi, pour assurer le service demandé, il ne suffit pas de sélectionner une route pouvant fournir suffisamment de ressources. Ces ressources doivent être réservées pour assurer qu’elles ne seront pas partagées ou « volées » par d’autres LSPs plus tard. Les critères nécessaires à l’établissement d’un trafic adapté peuvent être acheminés lors de la configuration des LSPs, ou avec le routage basé contrainte. Ces critères sont utilisés à chaque LSR pour réserver les ressources nécessaires, ou pour signaler un échec d’établissement de LSP dans le cas de ressources insuffisantes.

Une des principale utilisation du MPLS est de fournir du Traffic Engineering amélioré sur les réseaux fédérateurs des fournisseurs de services Internet (ISPs). En particulier, pour l’utilisation de services nécessitant différents niveaux de priorités, tel le transport de voix ou de vidéo sur Internet, MPLS permet d’éviter le recours à une politique de surdimensionnement des réseaux physiques pratiquée jusqu’alors, en allouant les ressources du réseau à des LSPs utilisant le routage basé contrainte.