CHAPITRE IV -

Architectures et protocoles de qualité de

service dans Internet
Les objectifs initiaux de l’Internet étaient de fournir les moyens de connectivité globale (au niveau
mondiale), de permettre à toute personne possédant un ordinateur de communiquer avec les a utres, de
traiter les paquets aussi vite que possible. Aujourd’hui, Internet n’offre quasiment qu’un service best effort.
Internet doit évoluer pour offrir de la QoS.

IETF (Internet Engineering Task Force) a proposé de multiples moyens pour prendre en compte les besoins
de QoS.
Deux techniques ont concouru à faire évoluer la notion de qualité de service QoS : l'architecture Integrated
Services (IntServ), Orienté connexion, un protocole inclus dans RSVP (Resource Reservation Protocol),
destinée à administrer la QoS dans le cadre d'une session d'une seule application, et Differenciated Service
(DiffServ), Orienté agrégation de flux et marquage de paquets qui, plutôt que de traiter chaque session
séparément, agrège le trafic à la QoS identique. Schématiquement, DiffServ et IntServ ont pour mission de
faire passer en priorité les paquets de données les plus urgents (comme la voix sur IP, la vidéo ou les
applications critiques, par exemple).
Integrated Services est le mécanisme le plus simple. Il n'offre pour la gestion du trafic qu'une alternative :
urgent ou non.
DiffServ, pour sa part, permet d'établir une hiérarchie multiniveau des différents flux de données à
transporter (jusqu'à huit niveaux de priorités).

I- INTSERV
Pour la transmission des données prioritaires, IntServ repose sur un mécanisme de réservation des
ressources. Il distingue deux services liés au délai de transit des paquets sur le réseau : les services sans
délai (transfert de fichiers, messagerie) et les services temps réel. Ces derniers sont sensibles à la gigue,
c'est-à-dire à la variation du délai d'acheminement. Dans le premier cas, l'application attend d'avoir reçu
tous les paquets avant de traiter les données. Le service appliqué est de type " au mieux " (Best Effort). Pour
les services temps réel, le modèle IntServ distingue ceux qui tolèrent une légère variation du délai de transit
et ceux qui ne peuvent pas se le permettre.
Dans la pratique, IntServ offre donc trois niveaux de service :
- Le Best Effort (pour le Web, FTP, Mail, etc.) , qui ne garantit pas le délai de transmission, ne définit aucun
mécanisme pour gérer la perte des paquets et ne contrôle pas non plus le délai d'acheminement des paquets
sur le réseau ;
- Le service à charge globale contrôlé (Priority Based QoS) (garantie statistique) , qui différencie les trafics
et leur affecte des codes de priorité en fonction de la sensibilité des applications et, enfin,
- Le service garanti (Guaranteed QoS) (garantie absolue) . Celui-ci livre les données en fonction de
paramètres négociés et de la classe de service demandée.
Integrated Services spécifie également les conditions auxquelles doivent satisfaire les équipements de
réseaux (routeurs et commutateurs) assurant le service. Les routeurs qui n’implantent pas IntServ ignorent
les nouvelles classes de QoS. Pour ce faire, l'IETF a déterminé quatre fonctions de contrôle pour ces
équipements :
- le contrôle de la charge (Packet Scheduler/ Ordonnanceur de paquets) détermine si le flux peut être
admis dans le réseau ;
- la classification répartit les paquets entrants dans les files d'attentes spécifiques des routeurs ;
- le contrôle d'admission s'assure que la qualité de service demandée par un flux peut lui être attribuée
sans affecter les flux existants ;

1
- le RSVP (Protocole de signalisation), réservation des ressources sur l'ensemble des nœuds (routeurs) par
lesquelles doivent transiter les données.

Actuellement, deux services IntServ ont été standardisés :

- Guaranteed Service (GS) : garantie de bande passante et un délai d'acheminement limité. Il fournit une
garantie absolue pour le délai de transfert et la perte de paquet.
- Controlled Load : équivaut à un service Best Effort dans un environnement non surchargé . Il fournit
un service équivalant à celui d’un réseau sous-chargé. Il est utilisable surtout par les applications qui
s’adaptent à la charge du réseau et qui tolèrent la perte de paquet.

Paramètres de caractérisation de QoS et trafic

- NON-IS-HOP : indique si, sur le chemin du flux, il y a des nœuds qui n’implantent pas IntServ.
- NUMBER_OF_IS_HOPS : compte le nombre de nœuds qui implantent IntServ sur le chemin du flux.
- AVAILABLE_PATH_BANDWIDTH : fournit l’information sur la bande passante disponible sur le
chemin du flux.
- MINIMUM_PATH_LATENCY : fournit la latence minimale (i.e. avec délai de séjour en file d’attente -
queuing delay- égal 0) pour les nœuds traversés.
- PATH_MTU : fournit la Minimum Transmission Unit sur le chemin du flux.
- TOCKEN_BUCKET_TSPEC : décrit les caractéristiques du trafic par le débit du seau percé (r), la
capacité maximum du seau (b), le débit de crête (p), la taille minimum de paquet (m) et la taille
maximum de paquet (M).

Limites/inconvénients
- Le nombre de flux individuels peut être très important. Par conséquent, le nombre de messages de contrôle
peut être élevé et nécessite beaucoup de ressources au niveau de chaque routeur.
- Des politiques doivent être mises en place pour déterminer quand, où et pour qui les ressources peuvent
être réservées.
- Des règles de sécurité doivent être mises en place pour garantir que les utilisateurs non autorisés ne
peuvent pas effectuer des réservations de ressources.
- Peu d’industriels ont implanté IntServ à grande échelle.
IntServ : convient seulement aux petits réseaux (problème de passage à l’échelle)

II- RSVP
Le protocole RSVP (Resource ReSerVation Protocol ) est un protocole de signalisation pour demander
la réservation de ressources dans un réseau IP.

Principales caractéristiques de RSVP

– C’est l’application qui initie le processus de réservation (granularité fine de réservation) au moment du
démarrage d’un flux.
– Modèle de réservation orienté Récepteur
– Les réservations sont faites pour chaque flux individuel
– Les flux peuvent être unicast ou multicast
– Il supporte les réservations hétérogènes et permet la renégociation de réservation
– Il permet un bon partage des ressources réservées pour de multiple flux.
– La gestion des réservations s’effectue en mode état soft.

*Un chemin unicast ou multicast est déterminé par un algorithme de routage (sans être sûr que ce chemin
réponde à la QoS exigée).
* La source du flux transmet un message PATH pour indiquer les caractéristiques de son flux. Chaque
routeur traversé garde la trace du flux et des ressources demandées.
* Chaque récepteur a ses propres capacités et spécifie dans un message RESV ses exigences. Chaque
routeur sur le chemin du message RESV confirme les réservations ou les annule. Quand le message RESV
atteint la source, les réservations sont acceptées le long du chemin et le flux de données peut commencer.

2
État soft de RSVP
■ Signifie l’état associé à RSVP (états PATH et RESV) est temporaire
– Il faut le rafraîchir pour qu’il reste valide
– Il est (éventuellement) détruit s’il n’est pas rafraîchi.
■ Rafraîchissement et suppression d’état
– Par envoi périodique de messages (PATH/RESV), toutes les t sec.
– Si un routeur ne reçoit pas de message après n*t sec, il supprime l’état.
■ Comme on est dans IP et pour éviter le surcoût de gestion des états, les messages sont envoyés de
manière non fiable.

Inconvénients
La maintenance des états soft implique que tous les routeurs doivent constamment contrôler et mettre à
jour les états pour chaque flux individuel. La conséquence peut être une congestion de réseau.

Un message RSVP est constitué d'une en-tête et d'un nombre variable d'objets qui dépend du type du message.

Les sept Messages RSVP

– PATH : Mise en place d’un état de réservation le long d’un chemin.
– RESV : Requête de réservation le long d’un chemin.
– PATH_TEAR : Suppression explicite d’un état de réservation.
– RESV_TEAR : Suppression explicite de réservation.
– PATH_ERR : Message d’erreur sur un chemin.
– RESV_ERR : Message d’erreur de réservation.
– RESV_CONFIRM : Confirmation de réservation

<Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [

<POLICY_DATA> ... ] [ <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ] ] (Définit les
caractéristiques du trafic)
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [
<RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA> ... ] <STYLE> <flow descriptor list> ( Définit la QoS
demandée par le récepteur.)

RSVP est un protocole général et ne spécifie ni les types de ressources demandées, ni la quantité de
ressources à réserver.

3
 III- DIFFSERV
Le modèle IntServ associe une QoS à chaque flux que le réseau transporte et s’appuie sur le protocole
RSVP pour effectuer la réservation des ressources dans les routeurs (nœuds) réseau intermédiaires. Un flux
étant considéré comme une connexion réseau entre un équipement source et un ou plusieurs équipements
d’extrémités (plusieurs dans le cas d’une diffusion multicast par exemple), chaque routeur intermédiaire
devait ainsi maintenir dynamiquement une liste des sessions IntServ en cours et, lors de la transmission
d’un paquet IntServ, rechercher dans cette liste le niveau de qualité de service correspondant (processus
coûteux en mémoire d’état du routeur). Ceci posa des problèmes lors de l’application du modèle IntServ aux
réseaux d’envergure (problème de scalabilité) dans lesquels on peut difficilement assurer la conformité de
l’ensemble des routeurs. IntServ est aussi un protocole complexe supportant le multicast et des mécanismes
de filtrage lors des réservations.
Pour pallier à ces problèmes, l’IETF a également proposé le modèle DiffServ dans lequel la QoS est associée
à une agrégation de flots (classe).

1- Principe de fonctionnement
Le modèle DiffServ apporte une QoS différenciée pour chaque classe de service (constituée d’une
agrégation de micro-flux) selon un contrat prédéfini (SLA, Service Level Agreement) avec l’émetteur des
flux de données. Ce contrat définit un ensemble de paramètres (bande passante garantie, pic de données
acceptés, comportement en cas de non-respect du contrat…) ainsi que les micro-flux associés à chaque
classe de service.
On associe ensuite une SLA à un domaine DiffServ. Un domaine DiffServ définit un ensemble de nœuds
réseau appliquant une politique de QoS commune.
Le modèle DiffServ s’articule autour de deux types de traitements :
- les traitements complexes effectués dans les nœuds d’extrémité.
- les traitements simples des nœuds intermédiaires.
Les nœuds d’extrémité sont les premiers équipements réseau auxquelles sont reliés les flux.
Chacun d’eux comporte un ensemble de modules appliquant des mécanismes complexes de QoS
(classification, marking, metering, shaping, dropping).
Les nœuds intermédiaires ont des comportements plus statiques mais aussi plus simples que l’on regroupe
sous le terme de PHB (Per-hop behaviour).

2- Architecture
a- Le champs DSCP :
Le modèle DiffServ a été conçu pour être utilisé avec la couche réseau IP. Il utilise le champ TOS (Type
Of Service) défini initialement dans le protocole IPV4 mais peu utilisé jusqu’à présent et fait partie
intégrante du protocole IPV6 (champs Traffic Class).

4
Le champ TOS a été renommé en DSCP (Differentiated Service Code Point) lors du passage au modèle
diffServ. La signification de chaque bit de l’octet DSCP est détaillée dans le schéma suivant :

• Les bits 0 à 2 : Class Selector

Les codes DSCP de type xxx000 (ou x a la valeur 1 ou 0) correspondent aux classes de services principales.
Ceux-ci seront associées aux PHB qui permettront le traitement différencié des flux dans les rou teurs
intermédiaires.
Plus la valeur de codepoint est élevée, plus le flux correspondant sera prioritaire.

• Les bits 0 à 5 : DSCP (Differentiated Service CodePoint)

Ce champ étend les sélecteurs de classes (bits 0 à 2) via 3 bits supplémentaires. On obtient ainsi une
granularité supplémentaire (8 sous-classes par sélecteur de classe).

• Les bits 6 à 7 : CU (Currently Unused)

Ce champ est actuellement inutilisé et donc ignoré par les routeurs intermédiaires.
Il a pour but de faciliter les extensions futures du protocole.
Les contrats SLA (Service Level Agreement) / TCA (Traffic Conditionning Agreement)
L’intérêt de la QoS est de pouvoir offrir un service adapté à chaque classe.
Ce service est défini au sein d’un contrat appelé SLA entre un client (l’éme tteur des flux de la classe ou un
autre domaine DiffServ) et un opérateur.
Lors d’un contrat SLA pour une classe donnée, on définit le type de service offert ainsi qu’un ensemble de
règles (plus ou moins détaillées suivant le contexte) pour le conditionnement du traffic :
- taux de disponibilité moyen, taux de perte moyen.
- délai borné, délai moyen, gigue moyenne.
- Les types de micro-flux faisant partie de chaque classe.
- La valeur de marquage DSCP (numéro de 0 à 63).
- La bande passante alloué, pics de données acceptés.

5
 - Le choix d’une politique à appliquer (policing) en cas de dépassement du contrat parmi les
possibilités suivantes: Transmission, Rejet des paquets, Abaissement du niveau de priorité
(changement de classe), Lissage des flux (étalement du trafic en excédant dans le temps).
- La taille des buffers de files d’attente.
Suivant les besoins, et éventuellement la criticité d’une classe, on définira une partie ou la totalité de ces
règles.
Remarque : Lorsque les flux d’une classe ne dépassent pas le contrat SLA fixé, on dit qu’ils sont dans le profil
fixé, sinon il sont hors profil.

b- Les domaines DiffServ

Un domaine DiffServ correspond à une zone contigue de nœuds conforme à au modèle DiffServ et ayant
une politique commune de policing et de PHB.

Exemple de domaines DiffServ

On associe généralement un domaine DiffServ à un opérateur de service ou un intranet. L’organisation

responsable du domaine est aussi la garante du respect du contrat SLA établi avec les émetteurs des flux.
Ceci implique une adéquation entre les ressources mises à disposition par l’organisation et les besoins
(bande passante, latence…) du contrat SLA. Si des nœuds réseau à l’intérieur d’un domaine ne sont pas
conformes à DiffServ, les résultats sont alors imprévisibles.

c- Les régions DiffServ :

Ce terme regroupe un ensemble de domaines DiffServ appliquant des contrats de services SLA prédéfinis.
Ces domaines DiffServ effectuent sur leurs nœuds d’extrémité les conditionnements de trafic nécessaires
(TCA) à la correspondance entre leurs PHB et ceux des autres domaines.

3- Le fonctionnement des entités

Le modèle DiffServ est une évolution de IntServ. Contrairement à celui-ci, DiffServ adopte la
philosophie de limiter les temps de traitement des routeurs intermédiaires.
Cela se concrétise par un fonctionnement différent des entités sur les routeurs intermédiaires par rapport
aux routeurs d’extrémité.

a- Les noeuds d’extrémité

Les traitements effectués sur les noeuds d’extrémité sont généralement les plus complexes et
correspondent à un contrat SLA préalablement établi.
Ils ont aussi un rôle particulier d’interfaçage entre les PHB de chacun des deux domaines qu’ils associent.
Les nœuds d’extrémité pourront éventuellement effectuer un reconditionnement des paquets si les règles
de classification et de conditionnement (TCA) ne sont pas les mêmes sur le domaine de destination.
Un contrat SLA d’une organisation X peut par exemple considérer un flux « Gold » (classe de service AF 3)
d’un client Y entrant comme un flux « Silver » (classe AF 2) au sein de son domaine. Dans ce cas, le nœud

6
d’extrémité du domaine DiffServ du client Y devra alors effectuer des opérations de conditionnemen t de
trafic (TCA) pour le trafic sortant.
Les nœuds d’extrémité peuvent aussi être des stations (serveurs ou stations de travail) sur lesquelles
s’exécutent les applications émettant les flux. La station effectue alors généralement une classification des
flux à émettre. Si ce n’est pas le cas, le premier équipement du domaine DiffServ peut jouer le rôle
d’équipement d’extrémité.

• La classification (classifier) :
Cette fonction consiste à détecter les classes de service des micro -flux. La classification peut se faire de
plusieurs manières. Généralement, on se base sur une association d’une ou plusieurs des caractéristiques
de la couche réseau et/ou transport:
- adresse source
- adresse destination
- port source
- port de destination
- type de protocole (TCP ou UDP)

Des mécanismes propriétaires (NBAR) permettent d’étendre les critères de différenciation à la couche
application.
La notion de PHB (Per Hop Behaviour):
Dans les premières RFC DiffServ l’IETF n’avait pas défini de comportement particulier associé aux valeurs
DSCP. Seul un comportement par défaut équivalent à un traitement de type « Best Effort » (traitement au
mieux) avait été défini (valeur DSCP 000000).
Les RFC 2597 et 2598 ont apporté une première normalisation des valeurs en définissant respectivement
deux types de comportement : le PHP AF (Assured Forwarding) et le PHB EF (Expedited Forwarding).
Le PHB AF fournit des niveaux de garantie d’acheminement des paquets.
Il est constitué d’un ensemble de 4 classes de service ayant chacune 3 niveaux de rejet de paquets
différents.

Par exemple, en cas de congestion dans la classe de service 4, les paquets de valeur DSCP 100110 seront
rejetés (drop) en premier lieu.
Le PHB EF est destiné aux paquets nécessitant une haute disponibilité (faible gigue, latence et taux de
perte).
On utilise couramment ce type de comportement pour le passage de données temps réel tel que la voix ou

7
la visio-conférence.
Le PHB EF est associé à une valeur unique DSCP 101110.

• La métrologie (meter) :
Elle consiste à vérifier que les classes des flux entrants ne dépassent pas le contrat (SLA) défini dans le
routeur. Cette information est transmise aux modules de marquage et de shaping/dropping qui
effectueront alors des actions conformes au policing fixé.
Le module de marquage par exemple peut décider qu’en cas de dépassement du contrat, les flux
excédentaires soient marqués avec une priorité moindre. Le module de shaping/dropping peut aussi
rejeter (dropper) tous les paquets excédentaires lorsque le contrat est dépassé.

• Le marquage (marquer) :
C’est dans ce module que sera affecté le champ DSCP (Cf. Figure 4). Les informations fournies en entrée
par le meter et le classifier permettront de faire un choix sur la pr iorité à appliquer à chaque flux.

• Le lissage et le rejet de paquet (shaper, dropper) :

Le lissage peut s’effectuer lorsque les flux d’une classe outrepassent le contrat SLA prédéfini.
Cette fonctionnalité n’est pas systématique et correspond à une règle de policing explicite dans le SLA. Les
paquets sont alors mis en file d’attente afin d’être transmis un peu plus tard lorsque le débit de la classe
sera considéré comme étant dans le profil du contrat.
Le rejet des paquets intervient pour garantir le débit fixé pour chaque classe de service.
Dans le cadre d’un lissage, les files d’attente ayant une taille finie, des dépassements de profil trop
importants peuvent aussi provoquer un rejet des paquets.

b- Les routeurs intermédiaires

Le problème principal d’IntServ a été sa complexité de mise en œuvre dans les équipements intermédiaires
via le mécanisme de réservation de ressources RSVP.
Le modèle DiffServ procède donc différemment en définissant des traitements plus simples dans les
routeurs intermédiaires.
Lors de l’arrivée d’un paquet, le routeur intermédiaire récupère sa valeur DSCP. Il recherche alors une
correspondance avec une recommandation de comportement (PHB) prédéfinie par l’IETF.
Si aucune recommandation ne correspond, il peut avoir défini des comportements particuliers non
normalisés mais correspondant à un contrat SLA convenu avec l’émetteur des flux.
Si ce n’est pas le cas, alors le paquet est traité avec un service « best effort » (BE).

4- Avantages & inconvénients

Comme toute technologie, DiffServ apporte son lot de nouveautés tout en ajoutant un certain
nombre de contraintes et de limitations. Les avantages ont été décrits tout au long de cette partie.
On trouve d’abord la philosophie de limiter les temps de traitement des routeurs intermédiaires
apportant une réponse aux opérateurs de réseaux qui pouvaient difficilement mettre en application sur
l’ensemble de leur infrastructure la complexité induite par IntServ. La normalisation des
PHB (comportements) constitue un deuxième point fort de DiffServ simplifiant l’interconnexion entre les
différents domaines DiffServ.
Pour le reste, DiffServ reprend le principe d’IntServ en normalisant un modèle QoS de niveau 3 permettant
d’être indépendant de la technologie de niveau 2 sous-jacente et offrant une véritable QoS d’extrémité.
DiffServ n’est pas pour autant exempt d’inconvénients. Il nécessite en effet d’établir préalablement un
contrat dans tous les équipements de son domaine. Ceci implique une connaissance approfondie d es
applicatifs pouvant transiter sur le réseau et peut se révéler parfois difficile à appliquer.
Le fonctionnement basé sur l’agrégation de flux implique aussi une perte de granularité des applications
transitant sur le réseau. Cela peut se révéler dans certains cas inadaptés.

8
Conclusion
Le modèle DiffServ fonctionne grâce à cinq modules qui interagissent entre eux pour effectuer le
conditionnement des paquets. Il est architecturé autour du protocole IP dans lequel il s'intègre (champs
TOS). DiffServ introduit la notion de domaines et fixe des comportements prédéfinis pour chaque
équipement.
Ce modèle dont la philosophie est de limiter les temps de traitement dans les équipements réseaux
intermédiaires offre finalement une solution valable répondant a ux besoins actuels des opérateurs. Il
implique toutefois une perte de granularité des flux et l'établissement préalable d'un contrat qui peuvent
dans certains cas se révéler pénalisant.

IV- MPLS
Multiprotocol Label Switching (MPLS) est une solution proposée pour répondre aux problèmes
posés par les réseaux actuels. C'est apparu comme une solution permettant d'organiser la rencontre entre
l'administration de bande passante et le besoin de services pour les nouveaux réseaux IP. MPLS propose des
solutions liées à la scalabilité (adaptation à l'échelle du réseau) et au routage (basé sur la QoS et les mesures
de la QoS). Il peut s'adapter aux réseaux ATM et Frame Relay.

1. Généralités
Au cours de ces dernières années, Internet a évolué et a inspiré le développement de nouvelles
variétés d'applications. Ces applications ont des besoins garantissant en terme de bande passante et de
sécurité de service au sein des backbones. En plus des données traditionnelles, Internet doit maintenant
transporter voix et données multimédia. Les ressources nécessaires pour ces nouveaux services, en terme
de débit et de bande passante, à entraîner une transformation de l'infrastructure d'Internet. Cette
transformation du réseau, d'une infrastructure par paquets à une infrastructure en cellules, a introduit de
l'incertitude dans un réseau jusque-là déterministe.
En plus de ces contraintes sur les ressources, un autre challenge est le transport des données sur le
backbone en offrant différentes classes de services aux utilisateurs. La croissance exponentielle du nombre
d'utilisateurs et le volume du trafic ajoute une nouvelle dimension au problème. Les classes de services
(CoS) et la qualité de service (QoS) doit être pris en compte pour répondre aux différents besoins de chaque
utilisateur du réseau.
En résumé, MPLS jouera un rôle important dans le routage, la commutation, et le passage des paquets
à travers les réseaux de nouvelle génération pour permettre la rencontre en tre les besoins de service et les
utilisateurs du réseau.
2. Routage et commutation de paquet traditionnels
Le déploiement initial d'Internet répond au transfert de données sur le réseau. Pour ça, un simple
routeur logiciel et des interfaces réseaux suffisaient. Au fur et à mesure que la possibilité de supporter des
transmission hauts débits a émergé, des éléments capables de commuter au niveau 2 et au niveau 3 ont dû
être déployés au niveau matériel (hardware).
Ces solutions répondent aux besoins de transfert rapide de paquets lors de la traversée du réseau, mais ne
répondent pas aux besoins en terme de service pour les informations contenues dans les paquets. De plus,
la majorité des protocoles de routage actuellement déployé se basent sur des algorithmes permettant
d'obtenir le passage le plus rapide sur le réseau, mais ne prennent pas en compte d'autres mesures, comme
les délais ou les congestions qui peuvent sérieusement diminuer les performances du réseau. La gestion du
trafic est un objectif pour les administrateurs réseaux.
3. MPLS et ses composants
MPLS est normalisé par l'IETF (Internet Engineering Task Force). Il assure les fonctions suivantes :
- Il spécifie les mécanismes pour administrer les flux de trafic des plusieurs types, comme les flux ent re des
matériels différents, des machines différentes ou même entre des applications différentes
- Il est indépendant des protocoles des couches 2 et 3.
- Il interagit avec des protocoles de routage existant, comme RSVP (resource reservation protocol) et OSPF
(open shortest path first).
- Il supporte les couches de niveau 2 des réseaux IP, ATM, et Frame Relay.

9
 Dans MPLS, la transmission de données se fait sur des label-switched paths (LSP, Chemin à
commutation de label). Les LSP sont une séquence de labels (ou étiquettes) à chaque nœud du chemin allant
de la source à la destination. Les LSP sont établis en fonction du type de transmission des données (control -
driven) ou après détection d'un certain type de données (data-driven). Les labels, qui sont des identifiants
spécifiques au protocole des couches basses, sont distribués suivant le protocole LDP (Label Distribution
Protocol), RSVP ou parfois par les protocoles de routage comme BGP (Border Gateway Protocol) ou OSPF
(open shortest path first).
Chaque paquet de données encapsule et transporte les labels pendant leur acheminement. La
commutation haut débit est possible puisque les labels de longueur fixe sont insérés au tout début du paquet
ou de la cellule et peuvent être utilisés par le hardware pour commuter plous rapidement.

a- LSR et LER
Les éléments qui participent aux mécanismes du protocole MPLS peuvent être séparés en Label Edge
Routers (LER, Routeur d'extrémité supportant les labels ) et Label Switching Routers (LSR, routeur de
commutation des labels).
Un LSR est un routeur haut débit au cœur d'un réseau MPLS qui participe à l'établissement des LSP. Un
LER est un élément à l'extrémité du réseau d'accès ou du réseau MPLS. Les LER peuvent supporter plusieurs
ports connectés à des réseaux différents (ATM, Frame Relay ou Ethernet) et qui fait suivre le trafic sur le
réseau MPLS après établissement des LSP. Le LER joue un rôle fondamental dans l'assignation et la
suppression des labels, au fur et à mesure que le trafic entre et sort du réseau MPLS.

b- FEC
La Forward Equivalence Class (FEC) est la représentation d'un groupe de paquet qui ont en commun les
mêmes besoins quant à leur transport. Tous les paquets d'un tel groupe reçoivent le même traitement au
cours de leur acheminement. Contrairement aux transmissions IP classiques, dans MPLS, un paquet est
assigné à une FEC une seule fois, lors de son entrée sur le réseau. Les FEC sont basés sur les besoins en terme
de service pour certains groupes de paquets, ou même un certain préfixe d'adresses. Chaque LSR se
construit une table pour savoir comment un paquet doit être transmis. Cette table est appelée Label
Information Base (LIB, Base d'information sur les labels).
- Labels et association de labels
Un label, dans sa forme la plus simple, identifie le chemin que le paquet doit suivre. Un label est
transporté ou encapsulé dans l'en-tête de niveau 2 du paquet. Le routeur qui le reçoit examine le paquet
pour déterminer le saut suivant selon son label. Une fois qu'un paquet est labellisé, le reste de son voyage
est basé sur la commutation de labels. Les valeurs du label ont simplement une signification locale. Ces
valeurs peuvent d'ailleurs directement déterminer un chemin virtuel (DLCI en Frame Relay ou VCI et VPI en
ATM).
Les labels sont associés à un FEC suivant une logique ou une politique déterminant cette association.
Cette décision peut se faire sur les critères suivants : Routage unicast vers la destination, gestion du trafic,
multicast, Virtual Private Network (VPN) ou QoS.
Le format générique d'un label est illustré par la figure ci-dessous. Le label peut aussi se situer dans
l'entête de la couche 2, ou entre les couches 2 et 3.

Format de base des labels MPLS

- Label-Switched Paths (LSP)

10
 Un ensemble d'éléments compatibles avec MPLS représente un domaine MPLS. Au sein d'un domaine
MPLS, un chemin est défini pour un paquet donné à partir d'une FEC. MPLS propose les deux solutions
suivantes pour implémenter un LSP :
* Routage saut-par-saut : chaque LSP choisit indépendamment le saut suivant pour un FEC donné. Cette
méthodologie est similaire à celle utilisé dans les réseaux IP courants. Le LSR utilise les protocoles de
routage disponibles, comme OSPF, PNNI (ATM Private Network-to-Network Interface), etc…
* Routage explicite : similaire au source routing. Le premier LSR détermine la liste des nœuds à suivre. Le
chemin spécifié peut être non-optimal. Le long de ce chemin, les ressources peuvent être réservées pour
assurer la QoS voulue au trafic.
Un LSP est unidirectionnel et le trafic de retour doit donc prendre un autre LSP.
- Label Distribution Protocol (LDP)
LDP est un protocole nouveau permettant d'apporter aux LSR les inf ormations d'association des labels
dans un réseau MPLS. Il est utilisé pour associer les labels aux FEC, ce qui crée des LSP. Les sessions LDP
sont établies entre deux éléments du réseau MPLS, qui ne sont pas nécessairement adjacents.
Ces éléments échangent les types suivants de messages LDP :
- Messages de découverte : annoncent et maintiennent la présence d'un LSR dans le réseau.
- Messages de session : Etablissent, maintiennent et terminent les sessions LDP.
- Messages d'avertissement : Créent, changent et effacent des associations entre FEC et labels
- Messages de notification : Permettent d'apporter d'autres informations comme signaler une erreur.

11