Memoire Online - Conception et déploiement de la technologie MPLS dans un réseau métropolitain

Pour ce qui est du routage dans MPLS, nous allons insister sur les deux protocoles CR-

2.2.4.1-) Le protocole de réservation de ressources RSVP-TE

De façon simple, on peut dire que RSVP-TE est une extension du protocole RSVP (Ressource ReSerVation Protocol) pour les réseaux MPLS permettant de prendre en compte la notion de Qualité de Service et d'ingénierie trafic.

Dans son idée de création, le protocole RSVP est destiné à être un protocole de signalisation pour IntServ². RSVP avec quelques extensions a été adapté par MPLS pour être un protocole de signalisation qui supporte MPLS-TE.

L'essentiel est de ne pas quitter des yeux que RSVP-TE est un protocole de réservation et pas des moindres ; il offre jusqu'à trois types de réservations à savoir :

² IntServ² : pour Integrated Services ; qui est un modèle de QoS ou un hôte demande au réseau une QoS donnée pour un flux spécifique.

? Fixed filter (FF) : Cette méthode propose une réservation de label pour chaque noeud émetteur ; ainsi les ressources de chaque noeuds ne sont pas partagées ;

? Wildcard Filter (WF) : Cette méthode propose une seule réservation de label quel que soit le nombre de noeuds émetteurs ; il permet d'effectuer des connexions point à multipoints ;

? Shared Explicit (SE) : Cette méthode permet au récepteur d'inclure explicitement chaque émetteur dans la réservation ; ainsi chaque émetteur a la possibilité de spécifier sa route et permettre donc l'existence de multiples LSPs. La différenciation des types de réservation va être notamment utilisée dans les mécanismes de reroutage.

Quand l'on utilise le routage explicite dans les réseaux MPLS, il peut parfois survenir certaines pannes il est alors impératif de trouver un moyen de contournement : le reroutage du trafic.

Le principe du reroutage est de recréer un LSP transitant par la route désirée et de faire par la suite basculer le trafic dessus ; enfin de détruire l'ancien LSP en s'appuyant sur le principe de'Make befor break³''. Mais cela n'empêche que parfois peuvent survenir des problèmes dans le cas où l'ancienne et la nouvelle route ont des liens en communs. Dans ce cas, durant la création du nouveau lien la bande passante nécessaire sur ces liens sera double et pourrait alors dépasser leur capacité ; mais ce problème est résolu par RSVP-TE. En effet, l'utilisation du même objet SESSION avec comme type de réservation SE (Shared Explicit) est utilisée et de plus, afin de différentier l'ancien et le nouveau tunnel un nouvel LSP ID est inséré ; dès lors, avec ces nouveaux éléments une nouvelle route est créée suivant la méthode conventionnelle. Puis, sur les liens en communs les ressources sont partagées avec l'ancien LSP grâce à la réservation de type SE. Enfin, dès que le LSP est créé le trafic est basculé de LSP et l'ancien LSP est détruit : cette même technique s'utilise pour l'augmentation de la bande passante.

La fonctionnalité 'd?Explicit Routing'' du RSVP-TE est très importante en ingénierie de trafic ; c'est un type de routage permettant de maximiser et d'optimiser l'utilisation des ressources. Il s'effectue à l'aide de l'objet EXPLICITE_ROUTE que nous allons bien aborder plus bas. Ce routage se fait manuellement ou automatiquement à

³ Make befor break³ : Principe selon lequel ; le reroutage doit être effectué sans aucune perturbation du trafic courant, car le LSP doit être recrée sur le tracé considéré avant toute destruction de l'ancien.

l'aide d'un générateur de route. L'objet EXPLICITE_ROUTE contient la liste des noeuds par lesquels la réservation du LSP va être effectuée ; laquelle liste peut être une liste d'adresses IP de sous réseaux IP ou bien des noeuds abstraits (virtuels). En effet, un noeud abstrait est un groupe de noeuds adjacents les uns aux autres dont la topologie n'est pas connue pas le noeud d'entrée : ce sont des systèmes autonomes. Le routage au sein de ces systèmes s'effectue de manière transparente.

RSVP-TE est un protocole dit `'soft state», car la liaison n'est établie que pendant la durée spécifiée par des 'timers» envoyés dans les messages de demande de réservation ; ce qui implique le rétablissement régulier de la liaison.

Ici, nous présentons les principes de fonctionnement et les mécanismes entrants dans la mise en oeuvre du RSVP-TE. Partant du principe que, les noeuds du domaine MPLS doivent pouvoir communiquer entre eux pour assurer leur fonction de routage ; le protocole RSVP-TE répond à ce besoin en définissant des types messages et des objets. Un message est caractérisé par sa propre structure et par les objets qu'il inclut. À chaque objet on peut attribuer une fonction particulière. En général, on distingue deux grands types de messages :

> Les messages destinés au contrôle (remontées d?erreurs etc) : PathErr et ResvErr

> L'objet SESSION : pour identification de session entre un noeud d'entrée et un noeud de sortie ;

> L'objet SENDER_TEMPLATE et l'objet FILTER_SPEC : tous deux combinés permettent d'identifier de façon unique un LSP dans le réseau ;

> L'objet LABEL_REQUEST: il indique une demande de réservation de labels. Il est transmis à l'intérieur du message Path (downstream). Cependant, la liaison des labels n'est effective que lors du passage du message Resv (upstream).

LABEL_REQUEST fournit aussi des renseignements sur le protocole réseau de couche 3 (L3PID : Layer 3 Protocol Identifier) ;

? L'objet EXPLICITE_ROUTE: son rôle premier est d'imposer la route à prendre en spécifiant la suite des noeuds à suivre ;

? L'objet RECORD_ROUTE : il permet d'enregistrer la route empruntée par le message ;

? L'objet SESSION_ATTRIBUTE : il peut contenir des informations de contrôle complémentaires, surtout ceux entrant dans le 'trafic engineering'' ;

? L'objet LSP_TUNNEL_IPv4 et l'objet LSP_TUNNEL_IPv6 qui indiquent si l'adresse du noeud de destination est d'IPV4 ou d'IPV6.

Il existe deux grand groupes de messages RSVP-TE qui sont éclatés en neuf types au total.

Common header
[INTEGRITY]
SESSION
PHOP
TIME-VALUES
[EXPLICIT_ROUTE]
LABEL_REQUEST
[SESSION_ATTRIBUTE]
[POLYCY_DATA]
SENDER_TEMPLATE
SENDER_TSPEC
[ADSPEC]
[RECORD_ROUTE]
Common header
[INTEGRITY]
SESSION
NHOP
TIME-VALUES
[RESV_CONFIRM]
[SCOPE]
[POLYCY_DATA]
STYLE
FLOWSPEC
FILTER_SPEC
LABEL
[RECORD_ROUTE]

Nous voyons que chaque objet contenu dans un message RSVP-TE est spécifique à une fonction particulière qu'il remplit pleinement (Voir tableau II.2).

Appartenance à un grand groupe	Type de message		Commentaire descriptif
Groupe de messages Path et Resv : qui sont des messages destinés à la création des routes.		Path	Utilisé pour établir et maintenir les chemins tracés.
		PathTear	Similaire au message de type Path, mais s'utilise plutôt pour la suppression des réservations réseau.
		Resv	Il est envoyé en réponse au message Path.
		ResvTear	Similaire au message de type Resv, mais s'utilise plutôt pour la suppression des réservations réseau.
		ResvConf	S'envoie de façon optionnelle à l'émetteur d'un message Resv pour confirmation qu'une réservation donnée est bien établie.
		ResvTearConf	Similaire au message de type ResvConf, mais est optionnellement envoyé à l'émetteur d'un message ResvTear pour confirmer qu'une réservation réseau donnée est supprimée.
		Hello	C'est un message particulier qui s'envoie entre noeuds voisins directement connectés entre eux.
Groupe PathErr et ResvErr : qui sont messages destinés au contrôle (remontées d?erreurs etc) :		PathErr	Il est envoyé par un récepteur d'un message Path qui détecte une erreur dans ce message.
		ResvErr	Il est envoyé aussi par un récepteur d'un message Resv qui détecte une erreur dans ce message.

Nous allons maintenant analyser en profondeur le format d'un message RSVP-TE typique. On voit qu'en général, un message RSVP-TE est constitué d'un en-tête commun (common header) et d'un nombre variable d'objets selon le type spécifique de message (Voir figure II.8 ci-dessous).

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
Version (4 bits)	Flags (4 bits)	Message type (8 bits)	RSVP Checksum (16 bits)
Send TTL (8 bits)		Rserved (8 bits)	RSVP length (16 bits)
Objets

Figure II.8 : Format général des messages RSVP-TE ? Version (4 bits) : il renseigne sur la version du protocole RSVP utilisé ; ? Flags (4 bits) : il n'est pas bien définit pour l'instant ;

> Message Type (8 bits): 1 = message Path ; 2 = message Resv ; 3 = message pathErr ; 4 = message ResvErr ; 5 = message pathTear ; 6 = message ResvTear ; 7 = message ResvConf ; 10 = message ResvTearConf ; 20 = message Hello ;

> RSVP Checksum (16 bits) : Il est surtout utilisé pour la détection d'erreur et s'appuie sur les mêmes principes que le Checksum utilisé dans IP ;

> Send TTL (8 bits) : Il contient la valeur du TTL (Time To Live), dans le paquet IP, avec lequel ce message a été envoyé : il impose une durée de vie du paquet ;

> RSVP Length (16 bits) : La longueur de message RSVP en octets,'common header'' inclus. La valeur de ce champ est donc toujours supérieure à 8. Nous venons de détailler l'intérieur des messages RSVP-TE à l'intérieur desquels se trouvent des champs objets ; comment se présente le format des objets RSVP-TE ?

> Object Length (16 bits) : C'est un champ dont la valeur est toujours supérieure à

4, il indique la longueur de l'objet RSVP en octets en incluant l'en-tête de l'objet ;

> C-Type (8 bits) : Il donne le type auquel correspond la classe de l'objet ;

On constate que chaque classe a son propre espace de numéro C-Type. Par exemple :

> La classe SESSION a 4 C-Types : IPv4, IPv6, LSP_TUNNEL_IPv4, et LSP_TUNNEL_IPv6. Les numéros assignés à ces C-Types sont 1, 2, 7 et 8.

> LABEL_REQUEST a trois C-Types: Without Label Range, With ATM Label Range, and With Frame Relay Label Range avec les numéros de C-Types 1, 2 et 3.

De ce fait, pour identifier le contenu d'un message, on doit prendre en compte les numéros de classe et le numéro de C-Type. On peut voir les classes et C-Types comme une sorte de la numérotation hiérarchique. Voir la structure des messages RSVP-TE en général nous permet dont d'entrer dans le fonctionnement d'RSVP-TE à proprement parler.

RSVP-TE est un mécanisme de signalisation utilisé pour réserver des ressources à travers un réseau : ce n'est pas un protocole de routage car, toute décision de routage est faite par IGP. RSVP-TE a principalement trois fonctions de base à savoir :

? La suppression des chemins (Path teardown) ; ? La signalisation des erreurs (Error signalling).

RSVP-TE est un "soft-state protocol" : car il a besoin de rafraîchir périodiquement ses réservations dans le réseau ; ce qui le différentie des "hard-state protocol", qui par contre signalent leurs requêtes une seule fois et supposent qu'elles restent maintenues jusqu'à sa résiliation explicite.

? L'établissement, le maintien, la suppression des chemins et la signalisation des erreurs :

L'établissement et la maintenance des chemins sont des concepts très proches utilisant certes les mêmes formats de messages mais cependant subtilement différents.

Lorsque l'ingress LER (appelé aussi MPLS-TE tunnel headend ou headend tout cour) a terminé sa procédure CSPF pour un tunnel particulier, il signale alors le chemin trouvé à travers le réseau ; il réalise ainsi cette opération en envoyant un message path au prochain noeud dans le chemin calculé vers la destination désirée. Ce message path contient un objet EXPLICIT_ROUTE qui lui, contient le chemin calculé par CSPF sous forme d'une séquence de noeuds. Puis, l'ingress LER ajoute un objet LABEL_REQUEST pour indiquer qu'une association de label est requise pour ce chemin et quel type de protocole réseau sera utilisé sur le chemin qui sera ainsi établit. Enfin, un objet

SESSION_ATTRIBUTE est ajouté au message path pour faciliter l'identification de la session et les diagnostics, et, le message path est acheminé vers l'Egress LER (appelé aussi MPLS TE tunnel tail ou tail) en suivant la route spécifiée dans l'objet EXPLICIT_ROUTE. Lorsque le message path avance dans le réseau, chaque LSR intermédiaire effectue les deux actions importantes à savoir :

? Le "contrôle d'admission" : qui est la vérification de la quantité de bande passante demandée par le message path par utilisation des informations contenues dans les objets SESSION_ATTRIBUTE, SENDER_TSPEC et POLICY_DATA. Tant que le contrôle d'admission ne valide pas le message Path, il n'y a aucune réservation possible ; c'est alors que le LSR intermédiaire crée un nouveau message path et l'envoie au "next hop" (en se référant à l'objet EXPLICIT_ROUTE).

Les messages path refont cette procédure avec tous les routeurs du chemin à établir jusqu'à atteinte du dernier noeud dans l'EXPICITE_ROUTE. Le 'tunnel tail?? réalise alors le contrôle d'admission du message path, exactement comme n'importe quel noeud intermédiaire ; s'il réalise qu'il est la destination du message path, il répond par un message Resv (qui est une sorte d?acquittement (ACK) pour le saut précédent (Previous Hop, PHOP) ; en plus, il témoigne la réussite de la réservation, et contient aussi le ?incoming label?? que le ?Previous Hop?? doit utiliser pour l'envoie de paquets de données le long du TE-LSP jusqu'au ?tail??. En effet, L'objet LABEL_REQUEST (message path) réclame aux LSR traversés et au ?tail?? une association de label pour la session.)

En général, le'tail'' répond au LABEL_REQUEST en incluant un objet LABEL dans son message de réponse Resv. Puis le message Resv est renvoyé vers le headend, en suivant le chemin inverse à celui spécifié dans l'objet EXPLICIT_ROUTE. Chaque LSR qui reçoit le message Resv contenant l'objet LABEL utilisera ce label pour le trafic de donnée sortant. Si le LSR n'est pas le headend, il alloue un nouveau label qu'il place dans l'objet LABEL du message Resv, et qu'il fait transiter sur le chemin inverse (grâce à l'information PHOP qu'il aura mémorisée lors du passage du message path pendant le processus d'aller).

Quand le message Resv arrive au headend, le TE-LSP est effectivement créé. À l'issue de la création de ce LSP, des messages de rafraîchissement RSVP-TE devront être émis périodiquement afin de maintenir le LSP créé (soft-state protocol).

2. La signalisation des erreurs ; le maintien et la suppression des chemins :

? Le maintien des chemins : Le maintien des chemins s'apparente très proche de l'établissement de ceux-ci ; en effet, environ toute les 30 secondes, le headend envoie un message path par le tunnel qui a été établit ; si un LSR envoie quatre messages path successifs et ne reçoit pas de message Resv correspondant, il considère la réservation supprimée et envoie un message dans le sens inverse indiquant que la réservation est alors annulée. Cependant, ne quittons pas des yeux que : les messages Path et Resv sont tous les deux envoyés d'une façon indépendante et asynchrone d'un voisin à un autre. Or sachant que les deux messages ne sont pas connectés (totalement indépendant), il est clair qu'un message Resv utilisé pour rafraîchir une réservation existante n'est pas envoyé en réponse à un message path, comme c'est le cas d'ICMP Echo Reply qui est envoyé en réponse à un ICMP Echo Request : on n'a donc pas de comportement Ping/ACK avec les messages Path et Resv.

? La suppression des chemins : La suppression des chemins peut être vue comme le processus inverse de l'établissement des chemins. En effet, lorsqu'un noeud du réseau décide de la fin d'une réservation, immédiatement il se permet d'envoyer un PathTear le long du même chemin suivi par le message path et un ResvTear le long du même chemin suivi par le message Resv. Les messages ResvTear sont envoyés en réponse aux messages PathTear pour signaler que le tunnel tail a supprimé la réservation du réseau. Tout comme les messages de rafraîchissement, les messages PathTear n'ont point besoin de traverser la totalité des noeuds le long du chemin pour que leur effet se face ressentir.

? La signalisation des erreurs : Tout comme dans les réseaux purement IP, ici un accent est aussi porté sur la signalisation des erreurs au sein du réseau

(Bande passante non disponible, boucle de routage, routeur intermédiaire ne prend pas en charge MPLS, message corrompu, création de label impossible, etc.). Le mécanisme de signalisation des erreurs dans MPLS est réalisée par le protocole de signalisation RSVP-TE. Plus précisément, ces erreurs sont signalées par les messages PathErr ou ResvErr. En effet, une erreur détectée dans un message path est traitée par un message PathErr, et une erreur détectée dans un message Resv est traitée par un message ResvErr ; les messages d'erreurs sont envoyés ensuite vers la source de l'erreur ; le PathErr est envoyé vers le headend, et un ResvErr est envoyé vers le tail. Une fois que les LSP sont établies, les paquets labélisés peuvent alors être routés ou même reroutés (en cas de panne) dans le réseau.

Conception et déploiement de la technologie MPLS dans un réseau métropolitain

2.2.4-) Le routage dans MPLS

2.2.4.1-) Le protocole de réservation de ressources RSVP-TE