Introduction à l’Ingénierie de Trafic IP

Akram Hakiri (akram.hakiri@gmail.com)

1
Objectif
 Comprendre le fonctionnement de réseaux opérateurs
 Notion de la QoS dans les réseaux opérateurs
 Architecture à QoS garantie IntServ & DiffServ
 MPLS et Ingénierie de trafic
 Contrôle de la QoS par politiques (bandwidth broker)
 Architecture de réseaux NGN
 Introduction à l’hybridation de réseaux satellite/terrestre

2
Prérequis & Apports
 Prérequis
 Architecture de réseaux
 Modèle TCP/IP et Modèle OSI
 Architecture NGN
 Apports
 Rappel sur les réseaux haut débit (ATM et ADSL)
 Comprendre l’architecture de réseaux à QoS, signalisation, politiques
 Comprendre l’approvisionnement de ressources, et le contrôle par politiques
 Architecture NGN
 Comprendre l’hybridation terrestres satellitaires

3
Plan
1. Application Multimédias et Notion de QoS
1. Applications Audio et leurs besoins en QoS
2. Routage à QoS, Ordonnancement et Contrôle d’admission
2. Etude des architectures classiques IP à QoS
 Architectures IntServ-RSVP et DiffServ
3. Ingénierie de trafic et le protocole MPLS
 MPLS, principe de communication de label
 MPLS/VPN et MPLS/BGP
4. Le contrôle de la QoS par politiques de services
 Framework Policy et Signalisation, COPS, et ses extension,
5. Exemple d’architecture à QoS pour les réseaux NGN
 Principes, strate transport, strate service, plan de gestion
 Tequila et EuQoS
6. Les réseaux hybrides satellites et terrestres
 QoS dans les réseaux satellite DVBS/RCS
 Intégration du satellite dans une architecture de QoS IMS

4
Organisation
1. Cours Intégré de 3h par semaine/12 semaines
2. Evaluation des connaissances
1. DS (30% de la note globale)
2. Examen (70% de la note globale)
3. Support de cours
1. Diapositives à fournir à chaque étudiant (PDF ou papiers)
2. Enoncés de TP/TD

 Attention !
 Elimination 3 absences non justifiées (Avis Administration)

5
 Application Multimédias et Notion de QoS

6
Classification des applications multimédias
 Selon l’interactivité
 Non interactives : radio et TV, vidéo à la demande, e-learning...
 Interactives: vidéo surveillance, téléguidage, vidéo conférence, téléphonie
 Selon la criticité
 (Très) critiques : guidage et supervision, télé opération chirurgicale
 (Moyennement) critiques : vidéo conférence, bourse, téléachat
 Non critiques : TV, radio, jeux
 Selon les contraintes temporelles (temps-réel)
 Streaming de données audio/vidéo préalablement stockées
 Streaming 1-à-m temps réel de données audio-vidéo

7
Compression de données
 La qualité du son/image est conséquence directe sur le débit
 L’augmentation de la taille de données et les limitations du
débit ont des conséquences directes sur la qualité de données
multimédia exploitables
 Il faut alors réduire le débit utilisé par les applications
multimédia
 Réduire la quantité d’informations à transmettre, par compression de
données
 On utilise des CODECS pour compresser les données multimédia
 Traitement de signal vidéo avec des transformées temporelles et
8 spatiales (Fourrier)
Exemple de compression multimédia
 Vidéo : pour une image de 1024*1024 pixels avec un pixel codé sur 2
octets
 Avant la compression: 2 Mo de mémoire pour le stockage, un délai de160
secondes sur un réseau 100Kb/s
 Apres la compression de facteur de 10: 0,2 Mo de mémoire, un délai de 16
secondes
 Audio: Signal analogique échantillonné à un rythme constant
 Téléphonie: 8000 échantillons/s ==> 64 kb/s
 Musique CD : 44000 échantillons/s
 Chaque échantillon est quantifié et représenté sur 8 bits (ou 7)
 A la réception le signal numérique est transformé en analogique.

9
Exemples de techniques de compression dans Internet
 Compression de l’audio
 GSM (13 Kb/s); G.729 (8 Kb/s); G.723(6.4 et 5.3 Kb/s)
 MPEG layer 3 (MP3) : 96, 128, 160 ou 320 kb/s
 Compression de la vidéo
 MPEG 2 : pour images animées + son - ‘high quality DVD video’ (3-6 Mb/s)
 MPEG 4 : Object oriented video compression (de 5 kb/s à plus d’un Gb/s)

10
Exigences des applications multimédia
 Manipulation de grandes quantités de données en continue
 Transmission des informations dans un délai borné (RTT borné)
 Partage de ressources (coexistence) avec d’autres applications non multimédia
 Exigences :
 délai, gigue, débit, taux (probabilité) de perte de données
 Les valeurs des exigences changement avec l’évolution technologique
 Tendance actuelle de la demande :
 des délais de plus en plus courts, des débits de plus en plus élevés, des taux de perte
de plus en plus faibles.

11
Exigences des applications multimédia
 Téléphonie et audio conférence:
 Faible débit (~ 64 Kb/s), mais des délais courts (< 250 ms)
 Vidéo à la demande:
 débit élevé (~ 10 Mb/s), latence non critique
 Vidéo conférence:
 débit élevé pour chaque participant (~1.5 Mb/s), délai faible (< 100 ms), états
synchronisés (Lip Sychroniation)
 Jeux interactives distribuées (IUT-T)
 Un délai maximum de 70 ms, une gigue maximale de 20 ms

12
Exigences des applications multimédia

13
Protocole RTP
 Real-Time Transport Protocol (RTP)
 Protocole de transport de données
soumises à des contraintes de temps
réel, tels que des flux média audio ou
vidéo

14
Entête de paquet RTP
 Type de flux (7 bits)
 Numéro de séquence (16 bits) : utilisé pour détecter les pertes
 Estampille (32 bits) : fournit l’instant d’échantillonnage du premier octet du
paquet. Elle est utilisée pour absorber la gigue.
 Identificateur de source de synchronisation (32 bits) : identifie la source du
flux. Chaque flux dans RTP a un identificateur affecté par la source de manière
aléatoire (mais distinct de ceux déjà existants) au début du flux.

15
Champ Type de flux RTP

16
Real-Time Control Protocol (RTCP)
 C'est un protocole de contrôle des flux RTP
 Il fournit les statistiques de bandes passantes et des informations de contrôle
pour un flux RTP (taux de paquets transmis/perdus, la gigue de transfert, etc.)
 Les statistiques sont envoyés dans des paquets rapports par les récepteurs, à
la demande de la source
 Les paquets rapports sont utilisés par la source pour modifier/adapter son
rythme aux conditions du réseau.
 Typiquement, la bande passante utilisée pour RTCP est limitée à 5% de la
bande passante de la session. Cette fraction est partagée entre les demandes
de rapports émises par les sources (25%) et les rapports émis par les
récepteurs (75%)

17
 Multimédia et QoS

18
Aspects liés à la QoS
 Exprime des exigences sur le comportement d’un fournisseur de service
 S’exprime par différents types de paramètres (délai, disponibilité de
service,…)
 Implique différents niveaux de service (déterministe ou autres)
 Nécessite la mise en place de divers mécanismes (réservation, contrôle,...)
 Concerne aussi bien le réseau que les applications
 Concerne à la fois différents types d’équipements et différentes couches

19
Classes (niveaux) de service
 Garantie absolue (déterministe) Quel niveau choisir ?
C’est la nature de
 Probabiliste/stochastique/statistique l’application qui permet de
décider
 Prédictive, à charge contrôlée
 Meilleure que le meilleur effort
 Coercitive (exerce des contraintes)
 Meilleur effort du réseau
 Indifférent

20
Paramètres de QoS
 Aspects temporels
 Temps de transfert, latence, délai, Gigue
 Temps de réponse ( aller-retour)
 Temps d’établissement/fermeture de connexion

21
Paramètres de QoS
 Volume
 Bits/s, Paquets/s
 Pourcentage de bande passante
 Fiabilité/disponibilité/robustesse
 Taux de disponibilité
 MTBF, MTTR
 Paramètres d’erreurs
 Taux d’erreur, taux de perte
 Taux de désordre de paquets
 Erreur d’établissement/fermeture de connexion
22
Autres paramètres de QoS
 Cout
 Pénalité, bonus, prix du service
 Autres
 Maintenabilité, simplicité, interopérabilité, passage à l’échelle, etc.
 Sécurité
 Capacité du contrôle d’accès
 Capacité du chiffrement
 Surcoût des mécanismes de sécurité (sur la performance et le délai)

23
Expression de la QoS
 Déterministe
 Une valeur (délai < 10 ms) ou intervalle de valeurs (délai dans
[ 80 .. 100])
 Probabiliste
 Avec une probabilité P (délai < 100 ms à 90%)
 Statistique
 Expression sur la moyenne, variance, écart type
 Loi de distribution (évaluation de performance)

24
Notion de Contrat de service
 Le contrat de service est dit aussi SLA (Service Level Agreement)
 SLA = Contrat User-Provider, entre utilisateur et fournisseur de service
 SLA Statique ou Dynamique
 SLA est implémenté selon une description de la spécification du service, dite
Service Level Specification (SLS)

25
 Panorama des fonctions de
gestion de QoS

26
 Fonctions mises en œuvre
pour la garantie de QoS

27
Fonctionnement simplifié d’un routeur/commutateur

28
Fonctionnement simplifié d’un routeur/commutateur

29
Eléments du délai de bout-en-bout
 Délais d’attente dans les files d’entrée
 Délais de construction de paquets
 Délais de commutation
 Délais d’attente dans les files de sortie
 Délai de transmission
 Délais de propagation

30
Niveaux de prise en compte de la QoS

Problèmes à résoudre?
• Modèles d’expression de QoS
• Fonctions de gestion de QoS
• Validation/vérification de QoS

31
Modèles de trafic

32
Propriétés des modèles de trafic
 Trois propriétés essentielles doivent être respecter pour
modéliser le trafic dans le réseau
 Simplicité d’expression du modèle
 Facilité de test et de vérification
 Faible surcout de l’implémenter dans le réseau
 Challenge
 La simplicité du modèle et sa facilité d’utilisation, risque d’introduire
des pertes de précisons dans le dimensionnement des ressources
(problème de surdimensionnement)

33
Caractérisation de trafic
 Trafic périodique : simple à modéliser
 Trafic apériodique: Souvent difficile à modéliser
 Distribution des instants d’arrivée selon quelle loi (poisson, …) ?
 Taille maximale des rafales?
 Durée minimale d’une rafale?
 Distribution de la taille des rafales?
 Distribution des pertes de messages ?
 Corrélation entre les paquets (pour autoriser les pertes) ?

34
Modèles de trafics fréquemment utilisés
 Modèle périodique: Période, Longueur maximale de paquet
 Modèle-1 avec rafale (Ferrari):
 Lpmax : longueur maxi de paquet
 Xmin (intervalle de temps min entre deux messages successifs)
 Xave (intervalle de temps moyen entre deux messages successifs)
 I (intervalle de temps sur lequel Xave est calculé).
 Modèle-2 avec rafale (Cruz)
 Débit moyen ρ et taille de rafale σ :
 Nombre total de paquets générés n’excède jamais σ + ρT dans tout
intervalle T.
35
Modèles de trafics fréquemment utilisés
 Modèle 3 avec rafale (Seau percé)
 Débit moyen d’écoulement du seau (ρ) et la taille maximale du seau
(σ).
 Eviter le débordement du seau.
 Modèle-4 avec rafale (Seau à jeton)
 Débit moyen de génération de jeton (ρ) et nombre maximal de jetons
en attente (σ).
 La source ne peut transmettre que si elle a des jetons.

36
Modèle de trafic de l’IETF (RFC 2215)
 Spécification à l’aide d’un Tspec
 Taille σ et débit ρ de seau percé
 Débit maximum p
 Taille maximum de paquet M
 Borne sup, A(T), de trafic par intervalle de temps T :
 A(T) ≤ min(M + pT, σ + ρT)
 Autres modèles : probabiliste, stochastique,… (cours
évaluation de performances)
37
Contrôle d’admission
 Objectif
 Est-ce que le nouveau flux peut affecter la QoS des flux déjà acceptés ?
 Est-ce que le nœud peut offrir la QoS requise par le nouveau flux ?
 Est-ce que le nouveau flux a le droit d’utiliser les ressources du nœud ?
 Est-ce que tous les nœuds à traverser acceptent le nouveau flux ?
 Informations utilisées
 Caractéristiques du nouveau trafic et de la QoS demandée
 Etat et historique du réseau
 Date de fin de trafic déjà acceptés
 Perturbations éventuelles de la QoS des trafics déjà acceptés

38 Politique d’utilisation des ressources
Exemples de Contrôle d’admission déterministe

39
Contrôle d’admission statistique
 Pourquoi on en a besoin?
 La plupart des flux sont plutôt à caractère aléatoire
 Eviter le surdimensionnement en rejetant des flux qui pourraient être
acceptés si on fait un peu plus attention à l’allocation des ressources
 Risques d’utilisation de CA statistique
 Apparition de situations de congestion
 Dégradation de la QoS
 Conséquence : CA statistique non adapté aux applications critiques

40
Types de CA statistique
 CA basés sur les débits moyen et maximal
 CA basés sur la bande passante effective cumulée
 CA basés sur l’ingénierie de la courbe de perte
 CA basés sur la variance maximale
 CA basés sur la théorie des larges déviations
 Autres types

41
Exemple 1 : CA statistique basé sur les débits moyen et
maximum: pour la garantie du taux de perte
 Notations
 C : capacité du lien considéré
 Maxj : débit max du flux j
 Avrj : débit moyen du flux j
 Hypothèses
 Toute source j est de type on-off (soit elle émet à son débit max soit elle est
silencieuse)
 Tous les paquets ont la même taille (1 unité)
 Pas de buffer au niveau du lien pour stocker les paquets en attente de transmission

42
Exemple 1 : CA statistique basé sur les débits moyen et
maximum: pour la garantie du taux de perte
 Principe
 La source j étant on/off, la densité de probabilité de son trafic est :

, =
 =
− , =
 Si on considère N flux indépendants qui partagent le même lien, alors la densité de
probabilité du flux agrégé, q(x), est la convolution de , …, : q(x) = ( * *… )
 La probabilité de perte de paquets Pl pour N flux est:
é ∑ ( )
 = = ∑ …
 Test de CA :
 Si Pl(N+1) ≤ Taux de perte requis, alors accepter le N+1ème flux, sinon le refuser

43
Exemple 2 : CA statistique basé sur la bande passante
effective cumulée: Pour la garantie de la bande passante
 Notations
C : capacité du lien; B : taille de queue du routeur

 [0, [: quantité de bits transmis par la source j dans l’intervalle [0, [
 : taux de perte d’une queue de taille maximale B
 ( ) : bande passante effective du flux j
 N : nombre de flux multiplexés
 Test du CA ∑ ( )<
 Exemple de définition de ( ) si peut être définie par une loi
exponentielle =  = + lim [0, [
→
44
Contrôle d’admission basé sur les mesures
 Si les caractéristiques de flux sont peu variables
 Utilisation de la demande maximale et moyenne pour accepter le flux
 Décision et réservation définitives
 Si les caractéristiques de flux sont peu ou pas connues (imprécision de trafic)
 Utiliser une estimation initiale du trafic et réserver les ressources
 Effectuer des mesures sur le trafic et ajuster les réservations en re-estimant le trafic
 Accepter un plus grand nombre de flux
 Coût des mesures et efficacité réelle des ajustements
 Problèmes
 Que faut-il mesurer ? Quand ? Où ?
 Comment définir progressivement des modèles de trafic ?
 Comment évaluer l’apport par rapport au CA sans mesure ?

45
Exemple de contrôle d’admission basé sur les mesures
 Notations
 Chaque source est modélisée par un seau à jetons (ρ, δ). Ainsi, le total
du trafic généré par la source, pendant U unités de temps, ne peut
excéder ρU + δ et la source ne peut transmettre que si elle a des
jetons.
 C : capacité du lien
 v : ratio d’utilisation du lien fixé à l’avance (v≤1). Ainsi, la bande
passante maximale utilisée est vC.
 : pire cas du délai de transfert estimé
 : estimation (en bits) du flux agrégé sur le lien
 N : nombre de flux déjà acceptés
46
Exemple de contrôle d’admission basé sur les mesures
 Test de CA
 Condition sur le délai
 Soient (ρN+1, δN+1) les paramètres du seau à jetons du nouveau flux N+1 et
DmaxN+1, le délai de transfert maxi exigé par ce flux.
 Le pire temps d’attente pour un paquet du flux N+1 est obtenu en supposant
que tous les flux transmettent simultanément un paquet de taille maxi égale à
∑
leur ∶D=
 Le pire temps de transfert estimé, , est utilisé à la place de (D est plus
pessimiste que )
 Le test de CA obtenu est : > +
 Condition sur la bande passante: = ̂+
47
Exemple de contrôle d’admission basé sur les mesures
 Processus de mesure
 Le délai de transfert et débit du flux agrégé sont mesurés périodiquement et sont
adoptés comme valeurs pour les paramètres et ̂
 Pour simplifier, on considère que tous les paquets ont la même taille et que leur temps
de transmission est égal à 1.

48
Exemple de contrôle d’admission basé sur les mesures
 Processus de mesure
 Un échantillon de mesure du délai est obtenu pour chaque transmission de paquet.
 Chaque échantillon de mesure du débit du flux agrégé est obtenu sur une période S.
 Chaque bloc de mesure dure T unités de temps (T= nS).
 A la fin de chaque bloc de mesure, l’échantillon dont la valeur est la plus élevée est
adopté pour estimer et ̂
 Les paramètres et ̂ sont mis à jour immédiatement (i.e. avant la fin du bloc) :
 Si un nouveau flux k est accepté, la mise à jour se fait ainsi = + et ̂ = ̂ +
 Quand une mesure dans le bloc actuel est plus élevée que celle déjà estimée alors, les
paramètres sont mis à jour immédiatement.

49
Problèmes ouverts
 Sur les modèles
 Modèles statistiques efficaces
 Combinaison de modèles pour l’agrégation de flux
 Compromis : Complexité/Précision/Surdimensionnement
 Sur les CA
 CA efficaces utilisables en ligne
 Caractérisation approximative des flux et complexité du CA
 Compromis entre complexité et performance
 CA adapté aux réseaux sans fil
 Contrôle d’admission en cas de AS interconnectés (inter-domaines)
 Chaque système autonome (AS) peut avoir son CA
 Comment avoir une décision de CA de bout en bout optimale ?
 Comment utiliser le CA basé sur les mesures avec des CA locaux hétérogènes ?

50
 Routage à QoS

51
Notion de routage à QoS
 C’est le mécanisme de routage qui permet l’établissement du chemin pour
flux en tenant compte de la disponibilité des ressources du réseau et des
exigences de QoS des flux [RFC2386]
 Les protocoles de routages incluent les paramètres de QoS tels que la bande
passante disponible, l’utilisation des liens, les ressources de calcul des nœuds,
le délai et la gigue
 Fonctions
 Collecter les informations sur les états des réseaux
 Trouver le meilleur chemin aux flux en fonction de leurs contraintes de QoS
 Changement de chemin s’il y a une dégradation progressive de la QoS
 Optimiser l’utilisation des ressources réseau

52
Principes généraux du routage à QoS
 Sélection de chemin
 A la demande (pour chaque paquet, pour chaque flux, …)
 Périodiquement et stockage dans une table
 Pré-calcul basé sur les algorithmes de Bellman-Ford et Dijkstra

53
Composants du routage

54
Classes d’algorithmes de routage
 Routage par la source
 Chaque routeur a une vue locale du réseau (mise à jour périodique ou non)
 Sélection du chemin par la source et notification de ce chemin aux autres nœuds
 Peu efficace pour les réseaux de grande taille
 Routage distribué (hop by hop)
 Sélection du prochain nœud seulement
 Informations d’état échangées avec les voisins
 Difficulté de partage et d’échange d’informations d’état
 Routage hiérarchique
 Hiérarchisation des nœuds (agrégation)
 Réduction de la complexité de gestion des états
 Partitionnement du réseau peut conduire à des cliques dans le réseau

55
Routage intra domaine et inter domaines

56
Algorithmes de routage à QoS
 Critères de classement
 Contraintes prises en compte délai, gigue, bande passante, …)
 Stratégie du routage (par la source, distribué, hiérarchique)
 Complexité de l’algorithme
 Complexité de la communication pour maintenir les informations
d’état
 Propriétés
 Complexité (traitement et messages) faible
 Passage à l’échelle
 Coexistence de routage à QoS avec routage best effort
57
Formalisation des problèmes de routage à QoS

58
Exemple de chemins à QoS

59
Exemple de chemins à QoS

60
Formalisation des problèmes de routage à QoS
 Problème du chemin (le plus court) avec contraintes de QoS
 Enoncé du problème dans le cas unicast
 Etant donné : une source s, une destination d, les vecteurs-poids associés aux arcs, un
vecteur de besoins de QoS B, trouver un chemin p de s à d tel que :

61
62
Problèmes de routage à QoS

63
Problèmes de routage à QoS à 1 métrique

64
Problèmes de routage à QoS à m métriques

65
Principes de résolution
 Prise en compte contrainte par contrainte
 PS = Sélection des chemins respectant QoS1
 PS2 = Sélection parmi l’ensemble PS1 des chemins respectant QoS2
 ….
 PSm = Sélection parmi PSm-1 des chemins respectant QoSm
 Prise en compte d’une contrainte et optimisation de critère(s)
 Sélection de chemins respectant la contrainte QoSx
 Optimisation d’un critère simple ou composé

66
Principes de résolution
 Utilisation de métrique composée

67
Eléments sur les coûts du routage à QoS
 Traitement/calcul
 Calcul des chemins (souvent NP-complet)
 Calcul lié aux échanges d’état
 Stockage
 Informations de topologie du réseau
 Informations d’état (sur différentes métriques)
 Table de routage courante, tables de routage pré-calculées
 Bande passante (paquets liés au routage)
 Facteurs de coût du routage
 Fréquence de sélection des chemins
 Métriques
 Facteurs de complexité (nombre de nœuds/liens, entrées de la table de routage,…)
 Compromis précision/surcoût

68
Exemples d’algorithmes de routage à QoS
 Exemple 1 : Extension de Dijkstra’s Shortest path algorithm (Cas Unicast)

69
70
 Ordonnancement de paquets

71
Approches de gestion de files d’attente
 Attente dans les files de sortie Liens Liens
Nœud de commutation
 Tout paquet est placé dans sa file de d’entrée De sortie
sortie dès son arrivée. File File
 Avantage : c’est la plus performante au d’attente d’attente
niveau débit

Attente dans Attente dans les

les files d’entrée files de sortie
Autres techniques

72
Approches de gestion de files d’attente
 Attente dans les files d’entrée
 Les paquets arrivant sur un port d’entrée sont placés dans une file d’attente associée
à ce port et servis en FIFO
 Inconvénient : « Head-of-line blocking » (lorsque le premier paquet de la file est
bloqué, car son lien de sortie est occupé, tous les autres paquets sont bloqués, même
si leur lien de sortie sont libres).
 Attente dans les files de sortie virtuelles (évite le « Head-of-line blocking »)
 A chaque port d’entrée sont associées autant de files d’attente que de liens de sortie
utilisés par les paquets arrivant sur ce port. Tout paquet attend dans sa file de sortie
 Attente dans une file unique
 Tous les paquets arrivant au routeur sont placés dans une file d’attente unique avant
d’être servis. C’est la plus simple, mais la moins efficace pour la garantie de QoS.

73
Ordonnancement de paquets
 Algorithme d’ordonnancement de paquets = Discipline de service

74
Classification des algorithmes d’ordonnancement
 Déterminisme
 Garantie déterministe
 Garantie non déterministe (Probabiliste, meilleur effort)
 Paramètres de QoS
 Garantie d’un seul paramètre de QoS (Délai, débit…)
 Garantie de plusieurs paramètres de QoS
 Priorité
 Stratégies fondées sur des priorités fixes
 Stratégies Round Robin
 Conservation
 Stratégies sans oisiveté (work-conserving)
 Stratégies avec oisiveté (non-work-conserving)

75
Loi de conservation de Kleinrock (1971)
 Formule de Little (1956) : E(t) = E(n) /λ
 E(t) : moyenne de temps de réponse
 E(N) : moyenne du nombre de clients dans la file
 λ : taux d’arrivée des clients
 La loi de conservation de Kleinrock stipule que : Si l’ordonnanceur est
conservatif alors, quelque soit la discipline choisie : ∑ =
 peut être considéré comme un délai pondéré pour la connexion k.
 N connexions géré par un ordonnanceur.
 le débit moyen de la connexion k.
 le délai moyen de traitement par paquet de la connexion k.
 le délai moyen de séjour en file d’attente par paquet de la connexion k.

76
Loi de conservation
 Cette loi signifie que, pour tout ordonnanceur conservatif, la somme des
délais pondérés est constante. Donc si on offre à une connexion un délai plus
court, on le fait au détriment des autres connexions qui vont avoir un délai
plus élevé
 Tout ordonnanceur non conservatif ne peut que conduire à une somme de
poids pondérés supérieure à celle d’un ordonnanceur conservatif (à cause des
temps d’oisiveté).
 FIFO est la discipline conservative la plus simple. Donc la somme des délais
pondérés de FIFO peut être considérée comme une borne inférieure pour
toutes les disciplines de service

77
Disciplines de service
 Conservatives  Non conservatives
 FP (Fixed Priority)  Jitter EDD
 FQ (Fair Queueing)  Stop-and-Go
 WFQ (Weighted Fair Queueing)  HRR (Hierarchical Round Robin)
 WF2Q (Worst-case FairWeighted Fair  RCSP (Rate Controlled Static Priority)
Queueing)
 SCFQ (Self-Clocked Fair Queueing)
 Virtual CLocks
 Delay EDD (Delay Earliest Due Date)

78
Ordonnancement FIFO
 Naturelle (la première qui vient à l’esprit)
 Non équitable
 Ne permet pas la garantie de QoS (en général)

79
Ordonnancement FP
 FP (Fixed Priority) = PQ (Priority Queueing)
 Une priorité fixe est associée à chaque flux (connexion) ou à chaque paquet
 Les paquets de priorité élevée sont servis d’abord

80
Round Robin (RR) de base pour les tâches
 Une seule queue pour toutes les tâches (processus).
 Servir pendant Δt chaque tâche. Si la tâche n’a pas fini la recycler en queue.
 Ordonnancement largement utilisé dans les systèmes non temps réel.

81
Weighted Round Robin (WRR)
 Associer à chaque flux un poids normalisé en fonction de la taille
moyenne de paquet du flux.
 Servir les queues à tour de rôle et en fonction de leurs poids.
 Avantages :
 Prise en compte de l’importance (poids) de chaque flux
 Protection des flux les uns contre les autres.
 Inconvénients :
 pénalise les flux à faibles poids.

82
WRR pour flux périodiques
 Chaque connexion est définie par (Pi, Di, ei)
 Pi : intervalle minimum d’arrivée de message sur la connexion i,
 Di : délai de bout en bout
 ei : nombre de paquet par message
 L’ordonnanceur fonctionne de manière cyclique et chaque tour est défini par un
nombre de slots maximum, RL.
 La longueur d’un slot est égale à 1 et correspond à la durée de transmission du paquet
le plus long. A chaque tour, les connexions sont servies à tour de rôle.
 l’ordonnanceur de chaque routeur affecte à chaque connexion en poids (en fonction
de , ) et contenu dans la demande de connexion qui indique le nombre de
slots affectés à cette connexion, à chaque tour.
 Si la demande peut être satisfaite, les slots sont réservés, sinon aucun slot n’est réservé
et les routeurs ayant déjà réservé des slots pour cette connexion sont avertis pour
annuler leur réservation.

83
WRR pour flux périodiques
 Trois conditions à respecter pour garantir les contraintes temporelles

 Avec la discipline WRR, le délai de bout en bout d’un message de la connexion

i traversant m routeurs ayant tous la même valeur pour RL est Wi :

 Le contrôle de gigue est difficile à réaliser.

84
Problèmes posés par l’utilisation de WRR
 Avec des paquets de tailles et des poids différents, on a besoin de connaître la
taille moyenne de paquets à l’avance. Cette taille moyenne est parfois difficile à
connaître a priori (ce qui rend WRR non équitable)
 Si la différence entre les tailles min et max) de paquets ou entre les poids min
et max) est importante, la durée d’un tour peut être élevée, conduisant à de
longues périodes de non équité.
 Conséquence :
 WRR est une discipline efficace pour des paquets de petites tailles avec des durées de
tour petites (c’est le cas d’ATM par exemple).

85
Ordonnancement PS « Processor Sharing »
 Temps partagé simple du processeur (pour l’ordonnancement de tâches)

 PS n’est pas implantable pour les paquets (sinon on risque de transmettre des
paquets contenant moins d’un bit)  Generalized PS

86
Ordonnancement GPS « Generalized Processor Sharing »
 PS + équité en tenant compte de l’allocation préalable des tâches (poids φi)
 GPS garantit un temps d’exécution (ci) selon le poids φi

87
Ordonnancement PGPS et WFQ
 PGPS « Packet Generalized Processor Sharing » (Parekh et Gallager 1993)
 GPS : l’interruption de tâche peut se faire à n’importe quel moment => non applicable
directement aux réseaux  PGPS = version de GPS appliquée aux réseaux
 PS + équité en tenant compte de l’allocation préalable des connexions (poids φi)

GPS garantit le débit

88
Technique «Weighted Fair-Queueing » (Demers, Keshav et
Shenker 1989)

89
Ordonnancement WFQ
 WFQ = une mise en œuvre de PGPS
 Principe général de WFQ
 V(t) : temps virtuel du système qui capte progression de la quantité de service
normalisé à l’instant t . V(t) peut être défini par :

90
Ordonnancement WFQ
 Pour tout paquet k de la connexion i à transmettre, on associe :

 Temps de début : = + ( ); : instant d’arrivée du

paquet k
 Temps de fin : = +
 L’ordonnancement se fait sur la base des temps de fin

91
Ordonnancement WFQ: Performances
 Hypothèse Notations:
 Le flux C est conforme à un seau percé
• c : flux/connexion
( ) • s : routeur
 Tous les routeurs sur le chemin implantent WFQ • ∅ : poids de la connexion c au niveau de s
 Borne de débit garanti : • : débit du flux c transitant par s
∅ • : ensemble des connexions passant
 = par s
∑ ∈ ∅
• : débit du lien de sortie de s
 Borne de délai garantie de bout-en-bout :
• : nombre de routeurs sur la route de c
( )
 +∑ + • : taille max de paquet du flux c
• : taille max de paquet transitant
par s : délai de propagation sur le tout
le chemin
92
Ordonnancement WFQ: Mise en œuvre
 On étudie la stratégie WFQ pour chaque lien de sortie dans le réseau
considéré.
 n : nombre de connexions passant par un lien de sortie donné
 : proportion de la bande passante allouée à la connexion i sur le lien de sortie au
moment de l’établissement de connexion.
 U : somme des proportions de bande passante allouées à toutes les connexions
sur le lien de sortie considéré (U≤ 1)
 Une connexion est dite inactive si elle n’a aucun paquet en attente dans
la file du lien de sortie ou en cours de transmission sur le lien de sortie ;
sinon elle est dite active.

93
Ordonnancement WFQ: Mise en œuvre
 Les paquets en sortie associés à une connexion i sont placés dans la file du lien de
sortie.
 Les paquets d’une même connexion sont servis selon l’ordre FIFO ; mais l’ensemble
des paquets n’est pas servi en FIFO.
 Un paquet d’une connexion est prêt pour transmission quand il est le premier des
paquets en attente pour cette connexion.
 Pour gérer les paquets prêts des différentes connexions actives, une file à
priorité FP est utilisée par l’ordonnanceur. Chaque connexion active i a une
entrée ( , ) dans la file FP. Cette entrée est insérée dans la file FP selon
son échéance exprimée en temps virtuel (etv).
 Les paquets prêts sont transmis selon l’ordre donné par la file FP (c-à-d, selon
l’ordre des échéances virtuelles).

94
Ordonnancement de paquets
 Après un temps d’inactivité du lien de sortie (car il n’y avait aucun paquet à
transmettre), quand le premier paquet arrive, sur une connexion i, l’ordonnanceur
calcule l’échéance virtuelle et la place avec i en tête de la file FP. La transmission
de ce paquet commence immédiatement (car la file du lien de sortie était vide au
moment de cette arrivée).
 Quand un lien de sortie est actif (c-à-d qu’il y a un paquet en cours de transmission
sur ce lien), l’ordonnanceur calcule pour tout paquet qui arrive, sur une
connexion i qui est inactive, et l’insère dans la file FP. Si cette connexion i était active,
le paquet arrivé est mis en file d’attente de la connexion sans traitement.
 Lorsqu’un paquet termine sa transmission, il est retiré de la file d’attente et son
entrée est retirée de la file FP. Si la connexion i, qui est la source du paquet qui vient
de terminer sa transmission, est active, l’ordonnanceur calcule l’échéance virtuelle
de son nouveau paquet prêt et l’insère dans la file FP. Ensuite, il commence la
transmission du paquet dont l’entrée est la première dans la file FP.

95
Calcul des nombres de fin pour un lien de sortie

96
 Exemple

97
 Contrôle de congestion et gestion des files
d’attentes

98
Principe de l’allocation des ressources
 Ressources = CPU, mémoire, bande passante
 QoS fournie dépend des ressources allouées pour le service
 Politique d’allocation des ressources droits d’utiliser des ressources, coûts,
etc.
 Allocation de ressources:
 Sans Négociation : rigide (tout ou rien), sûre
 Avec Négociation : à la connexion, flexible, complexe
 Avec Renégociation : s’adapter au réseau à tout moment, transmettre à
moindre coût, (très) complexe

99
Stratégies d’allocation de ressources
 Stratégies d’allocation de ressources : Allocation non statistique ou statique
 Allocation non statistique (“peak bandwidth allocation”)
 Allouer une capacité maximale s’il reste encore assez de bande passante
 Adaptée au trafic à rythme fixe (CBR)
 Risque de sous-utilisation du réseau
 Allocation statistique
 L’allocation ne se fait pas sur la base du débit maximum de connexion
 La somme des débits correspondant aux connexions acceptées peut être supérieure à
celui des ports de sortie du nœud.
 Adaptée à des flux variables (VBR)
 Difficulté de prédire la garantie de QoS

100
Problèmes de la réservation de ressources
 Des ressources réservée mais non utilisées : Perte
 Ressources minimales/moyennes à réserver : difficiles à déterminer

101
Allocation de ressources
 Gestion de buffers (tampons ou queues)
 Gestion de buffers (un flux / une file, une file partagée entre plusieurs flux)
 Mémoire de stockage des paquets limitée ⇒ Contrôler son utilisation
 Deux décisions majeures :
 Quand rejeter les paquets ?
 Quels paquets rejeter ?
 Contrôle et traitement de trafic
 Contrôle de congestion
 Contrôle de trafic de l’utilisateur
 Façonnage du trafic de l’utilisateur (« traffic shaping »)
 Marquage de paquets

102
Allocation adaptative (locale)
 Avantages
 Chaque source connaît le meilleur moyen de réduire ses exigences.
 Chaque source peut appliquer une stratégie qui dépend de sa classe.
 Inconvénients
 La dégradation de QoS peut venir d’autres sources “non disciplinées”.

103
Allocation adaptative (globale)
 Avantages
 Meilleure utilisation des ressources.
 Les surcharges de réseau peuvent être limitée par réduction des demandes.
 Inconvénients
 Surcoût important.

104
Initiation de la réservation de ressources

105
Problème de congestion
 Flux aléatoires + Mémoire limitée + bande passante limitée ⇒ Possibilité de
congestion
 Effets négatifs : taux de perte élevé latence élevée
 Nécessité de contrôle de congestion

106
Suppression de paquets

107
Stratégies de suppression de paquets
 Politique de suppression de paquets  Quels paquets supprimer et dans
quelles conditions ?
 Rejeter sans distinction les paquets arrivant en fonction de l’état courant des buffers
 Utiliser des seuils de congestion (anticiper les situations de congestion)
 Utiliser les données des contrats utilisateur pour rejeter les paquets hors profil
 Affecter des priorités basses aux paquets hors profil
 Méthodes : réactives vs préventives
Compromis:
 Techniques de contrôle de congestion Complexité/ Performance/Prévision
 – RED (“Random Early Detection”) &
Détermination des seuils
 – Variantes de RED (FRED, WRED…)
 – ECN (“Explicit Congestion Notification”)
 – Autres

108
Propriétés de stratégies de contrôle de congestion
 Anticipation des situations de congestion (aspects probabilistes)
 Notification aux sources qui persistent à dépasser leur limite
 Rendement du réseau (‘throughput’) élevé
 Latence limitée
 Adaptation aux bursts (rafales de paquets)
 Taille des queues appropriée (pas de surdimensionnement
inutile)
 Complexité d’implantation réduite
 Équité au niveau du rejet de paquets
109
Discipline de service: FIFO
 FIFO : technique la plus simple pour gérer les files d’attente de routeurs.
 une seule queue par interface de sortie (servir le paquet en tête)
 mettre en queue le paquet arrivant si file non pleine
 rejeter le dernier paquet si queue pleine

 FIFO a le mérite de ne pas poser de problème au fonctionnement

d’Internet fondé sur le principe du meilleur effort. Pas de contraintes
pour l’implantation de routeurs IP.

110
Limites (inconvénients) de FIFO :
 Impossible de différencier les trafics (car on a une seule queue) :
 les paquets arrivant sont rejetés sans distinction en cas de queue saturée.
 Donc on ne prend pas en compte l’importance des paquets.
 Il n’y a pas d’isolation de flux.
 Un flux qui persiste à envoyer plus de paquets finit par avoir plus de service par
rapport aux autres qui s’auto limitent.
 Inconvénients du rejet en fin de queue (‘drop-tail’):
 Les routeurs doivent avoir des queues de taille importante pour maintenir un taux
d’utilisation élevé.
 Des buffers larges impliquent des latences importantes
 Nécessité d’utiliser des méthodes de gestion actives

111
Technique RED (Random Early Detection)
 RED : technique la plus populaire pour l’évitement de congestion
 Proposée par Floyd et Jacobson (1993) pour gérer les flux TCP
 Gestion de queue avec des seuils - technique de gestion active (préventive)

112
Algorithme de la technique RED
 Pour chaque paquet arrivant: estimation d’une taille moyenne de queue Qmoy :
 Qmoy = (1-w)Qmoy + w*Qreel w<<1 (ex. w=0.002)
 /* Qreel : taille réelle de la queue de paquets acceptés et non encore transmis.
 Cette variable est incrémentée à chaque acceptation de nouveau paquet et
décrémentée à chaque transmission de paquet. */

113
Algorithme de la technique RED
 Rejet/marquage probabiliste en fonction de la taille moyenne de
queue
 Si Qmoy < SeuilMin : pas de rejet/marquage du paquet arrivant
 Si Qmoy ≥ SeuilMax : rejet/marquage systématique du paques arrivant
 Si SeuilMin ≤ Qmoy < SeuilMax : rejet/marquage avec une probabilité pa,
calculée comme suit :
 pb = Pmax*(Qmoy - SeuilMin)/(SeuilMax – SeuilMin)
 pa = pb/(1 – pb*compte)
 Compte = nombre de paquets reçus depuis le dernier paquet
marqué/rejeté pendant que la condition SeuilMin ≤ Qmoy < SeuilMax
reste satisfaite.
114
Explication des paramètres de RED
 Si l’on admet que l’on peut accepter des rafales de L paquets au maximum, alors le poids w doit
( )
respecter : + 1 + <
 Par exemple :
 SeuilMin = 5 et L = 50 conduit à choisir w ≤ 0 0042
 La variation de Q (i.e. la sensibilité de Q aux rafales) dépend de la valeur de w.
moy moy

 Si w est très petit alors, Q répond lentement aux changements de la queue réelle.
moy

 Les valeurs de SeuilMin et SeuilMax dépendent de la taille moyenne de queue désirée. Cette taille
influe sur le délai moyen d’attente en queue. En général, SeuilMax est fixé au moins au double de
SeuilMin.
 Pmax désigne une borne supérieure pour la probabilité de marquage de paquet.
 Le nombre de paquets marqués/rejetés avant d’atteindre le seuil de congestion dépend de cette
valeur.
 Pmax est fixée selon les besoins (est-ce que l’on veut anticiper de manière forte ou non les situations
de congestion).
 Les auteurs de RED (Floyd et Jacobson) préconisent que la valeur de Pmax ne doit pas être
supérieure à 0.1.

115
Exemple de fonctionnement de RED

116
Exemple de fonctionnement de RED

117
Exemple de fonctionnement de RED

118
Exemple de fonctionnement de RED

119
Exemple de fonctionnement de RED

120
Exemple de fonctionnement de RED

121
Limites (inconvénients de RED)
 Perturbation par les flux qui se comportent mal
 Sensible au nombre de sources
 Difficultés de choisir les paramètres (seuils et Pmax)
 Variantes de RED
 FRED (Flow RED)
 CBT RED ( Class Based Threshold RED) : analogue à FRED
 SRED (Stabilized RED)
 DRED (Dynamic RED)
 WRED (Weighted RED)
 ARED (Adaptative RED)

122
 Chapitre 1: Architecture IntServ

Akram Hakiri

123
Motivation
 L’internet est basé fournit une seule classe de service (Best-effort)
 C’est-à-dire le réseau ne garantie rien quant à la livraison des données
 Les applications actuelles sont élastiques (FTP, HTTP, etc.)
 Tolèrent le délai et les pertes
 Peuvent s’adapter à la congestion
 Les applications « temps-réel » ne sont pas élastiques (streaming, SNMP)
 Ne tolèrent pas le retard (délai) et les pertes
 Que doit-on modifier:
 Ces applications pour être plus adaptatives ?
 Ou bien, Internet pour supporter le trafic inélastique ?

124
Améliorer la QoS IP
 Les groupes IETF proposent de nouvelles approches pour
contrôler la QoS dans les réseaux IP
 Fournir plusieurs catégories de service ou classes de services
 Garantir le contrat de service
 Dimensionnent des ressources réseaux (routeurs)
 IETF propose:
 Integrated Services (IntServ)
 Differentiated Services (DiffServ)
 Resource ReSerVation Protocol (RSVP)

125
Principes de garantie de la QoS
 Une application VoIP à 1Mbps et une application FTP à 1,5Mbps,
qui partagent un lien de 1,5Mbps
 Les rafales FTP congestionnent R1 et cause la perte de paquets voix
 On doit donner une certaine priorité au trafic VoIP par rapport à FTP

126
Principe 1
 Principe1: On doit marquer les paquets pour que le
routeur peut distinguer les différentes classes de trafic, et utilise
de nouvelles politiques pour traiter chaque classe

127
Principe 2
 Fournir une protection (isolation) à une classe par rapport aux autres
classes
 Principe 2: Réguler le trafic (trafic policing) pour s’assurer que les sources
respectent les exigences en bande passante
 Le marquage et la régulation du trafic doivent se faire sur les bords du réseau

128
Principe 3
 En plus du marquage et régulation, allouer une partie de la bande passante à
chaque flux d’application, peut conduire à une utilisation inefficace des
ressources, si l’un des flux n’utilise pas sa BP allouée,
 Principe 3: Tout en fournissant l’isolation du trafic, il est souhaitable
d'utiliser les ressources aussi efficacement que possible.

129
Principe 4
 Le réseau ne peut supporter du trafic au delà de la capacité de ces liens
 Principe 4: besoin du contrôle d’admission (Call Admission
Control), l’application déclare ces besoins, le réseau peut accepter la
demande de connexion ou la bloquer s’il ne peut satisfaire sa demande

130
Résumé

131
IETF IntServ (1994)
 Réservation par flot
 Traitement des flux individuels de paquets, chaque flux
demande un niveau de service différent du réseau
 Le niveau de service quantifiable mathématiquement
 Débit minimum, un débit crête, probabilité de perte, un délai
 Problèmes
 Complexité de mise en œuvre
 Résistance au facteur d’échelle
 Complexité de la facturation
132
Les composants IntServ
 Type du modèle de service
 Que promet le réseau?
 Interface de service
 Comment l’application peut décrire ces besoins ?
 Ordonnancement de paquets
 Comment le réseau répond-il aux promesses?
 Établir la garantie
 Comment la promesse est-elle transmise au réseau?
 Comment l'admission de nouvelles applications est-elle contrôlée?

133
Modèle de service
 Le réseau peut supporter des flux de trafic avec différentes
"qualité de service".
 Meilleur effort
 Services prédictifs ou différenciés
 Forte garantie sur le niveau de service (en temps réel)
 L'ensemble de services pris en charge sur un réseau spécifique
peut être considéré comme un modèle de service.
 Modèle qui peut être utilisé pour sélectionner un service
 e.g., compromis entre le coût et la performance
 Architecture réseau qui prend en charge l'ensemble des services
134  Considère les interactions entre les services
Modèle de service
 Service garanti (Guaranteed Service, GS)
 Cible les applications temps-réel « dure »
 L'utilisateur spécifie les caractéristiques de trafic et les
exigences de service.
 Nécessite un contrôle d'admission à chacun des routeurs.
 Le réseau peut garantir mathématiquement la bande
passante, le délai et la gigue.

135
Modèle de service
 Charge contrôlée (Controlled Load, CL)
 Cible les applications adaptative aux conditions du réseau non
congestionné dans une certaine fenêtre de performance .
 L'utilisateur spécifie les caractéristiques du trafic et la bande
passante.
 Nécessite un contrôle d'admission à chacun des routeurs.
 La garantie n'est pas aussi forte qu'avec le service garanti.
 par exemple, contrôle d'admission basé sur la mesure.
 Best-effort
136
Interface de service
 La session doit d'abord déclarer son exigence de QoS et
caractériser le trafic qu'il enverra à travers le réseau
 R-Spec: définit la QoS demandée par le récepteur (ex. le débit
r)
 T-Spec: définit les caractéristiques de trafic (profil de trafic)
de l’émetteur (ex., seau percé avec, un débit r et une longueur
de la file d'attente b).
 Un protocole de signalisation est nécessaire pour transporter
les spécifications R-Spec et T-Spec aux routeurs où la
réservation est nécessaire;
 RSVP est le protocole de signalisation.

137
Ordonnancement de paquets

138
Ordonnancement de paquets
 Les paquets arrivant sur un port d’entrée sont placés dans
une file d’attente associée à ce port et servis selon un
algorithme d’ordonnancement
 Service garantie
 Utilise le filtre seau à jeton pour caractériser le trafic
 Décrit par le débit « r » et la taille du seau « b »
 Utilise l’algorithme d’ordonnancement WFQ dans le routeur
 Une borne maximale au pire-cas pour le délai d’attente = b/r

139
Contrôle d’admission
 L’admission d’une session ou connexion
 les routeurs admettront les connexions en fonction des
spécifications R-Spec et T-Spec et en fonction des ressources
actuelle allouée à d'autres appels.

140
Réservation des ressource (RSVP)

141
Réservation des ressources (RSVP)
 RSVP est un protocole de signalisation qui avertit les
nœuds intermédiaires de l’arrivée de données
correspondant à une QoS prédéfinie.
 RSVP définie un session définie par le triple [DestIP@,
Protocol-ID, DestPort]
 L’adresse de destination peut être unicast ou multicast

142
Réservation des ressources (RSVP)
 La demande de réservation de ressources est formée
par le descripteur de trafic, qui est formé par deux
éléments : Flowspec et filter spec
 Flowspec définie la QoS désirée, c’est-à-dire, la classe de
service, R-Spec et T-Spec
 Filter Spec, définie la spécification de la session, c’est-à-
dire, l’ensemble de paquets de données (flux) pour
recevoir la QoS définie dans FlowSpec
143
Réservation des ressources (RSVP)

RSVP FlowSpec Classe de Service

R-Spec
T-Spec
Filter Spec Adresse IP de l’émetteur
Num de port [TCP/UDP]
de l’émetteur

144
Réservation des ressources (RSVP)

145
Réservation des ressources (RSVP)
 La réservation de ressources se fait sur les nœuds
intermédiaires qui possèdent la fonctionnalité RSVP
 Ces nœuds mémorisent les informations d’états et
communiquent entre eux périodiquement pour mettre à
jour leurs tables de d’état,
 L’émetteur envoie un message PATH qui dresse la liste
des nœuds intermédiaires à emprunter par les messages
RSVP de demande de QoS.
146
Réservation des ressources (RSVP)
 La demande de réservation de la QoS est faite
obligatoirement par le récepteur, qui connait les
caractéristiques du flots lorsqu’il reçoit le message
PATH de l’émetteur
 Cette demande de QoS arrive à l’émetteur sous forme
de message RSVP

147
Réservation des ressources (RSVP)
 Les parties essentielles d'un message PATH, du point de
vue de la réservation, sont les parties Adspec et
Sender_Tspec.
 ADSPEC représente, au nœud courant, un résumé de la
somme des ressources disponible en terme de débit et
de délai sur le chemin de donné,
 L’initiateur d’une réservation sur un chemin y insère ses
propres infos de capacité.
148
 Description de flot
 FilterSpec: identifier la (les) source(s)
 IPv4: Adresse source et numéro de port
 IPv6: Adresse source et flow ID
 Session: identifier la (les) destination(s)
 Adresse de destination, protocole ID et numéro de port
 FlowSpec: décrire les caractéristiques du flot
 Le trafic émis (TSpec)
 Le service désiré (RSpec)

149
 Spécification de flot : TSpec
 TSPEC= (r, b, p, m, M)
r
 r: débit moyen bits
p

 b: sporadicité
 p: débit crête b

 M: taille de paquet maximum (MTU)

M
 m: taille de paquet minimum
 Défini l'enveloppe du trafic émis
temps

150
 Modélisation : Token bucket
 Description d'un flux selon :
 Une sporadicité : b
 Un débit moyen : r
 Une file de jeton de capacité maximale b est remplie avec un débit r
 Un jeton est consommé à chaque émission d'un octet
 Un datagramme de longueur M peut sortir de la file principale si et seulement s'il y a M
jetons
Taux de régénération des jetons
r

b Capacité en jetons
TSPEC(r, b, p, M)
p Débit crête
Trafic entrant
M
151
Taille de paquet
 Chapitre 2: Architecture DiffServ

Akram Hakiri

152
Differentiated Services (DiffServ 1998)
 L’objectif est de faire face aux défaillances d’IntServ et RSVP
 Scalabilité: le maintien des états par les routeurs dans les
grands réseaux est difficile en raison du grand nombre de flux
 Flexibilité du modèle de service: IntServ n’a que deux
classes (GS, CL), il est souhaitable de fournir plus de classes
qualitatives, et offrir une distinction de classes « relative »
 Simplifier la signalisation (mieux que RSVP): plusieurs
applications et utilisateurs veulent simplement une notion de
service plus qualitative
153
DiffServ - Motivation
 Faire une enfoncement plus fin à la bordure du réseau
 Généralement, les liens à la bordure sont plus fins
 Étiqueter des paquets avec un champ.
 Estampille de priorité
 Le réseau de cœur utilise uniquement le champs de priorité
pour gérer la QoS
 Un petit nombre de niveaux de priorité avec un comportement
d’acheminement bien défini
 Peut être manipulé rapidement

154
DiffServ
 DiffServ défini une architecture et un ensemble de
comportements
 Il incombe aux fournisseurs de services de définir et d'implémenter
des services de bout en bout au-dessus de cette architecture.
 Offre un modèle de service plus souple; différents fournisseurs
peuvent offrir un service différent.
 La motivation principale de DiffServ est la scalabilité
 Garder le cœur du réseau simple
 DiffServ supporte la QoS pour les agrégats de flux.

155
Architecture DiffServ

156
Fonctions du routeur DiffServ

157
Fonctions du routeur DiffServ
 Classification : marque les paquets selon les règles de
classification à préciser.
 Mesure: vérifie si le trafic est conforme au profil négocié.
 Marquage: marque le trafic conforme au profil.
 Conditionnement: retarde et réachemine, rejette ou
remarque l'autre trafic.
 Shaper : retarde certains paquets pour les rendre conformes à certain
rythme.
 Dropper : écarte (élimine) certains paquets non conformes ou ayant
un taux de rejet exigé plus élevé que celui des autres paquets
158
Classification et conditionnement
 Le paquet est marqué dans le champs type de service (Type of
Service ou TOS) dans l’entête IPv4 et la classe de trafic (Traffic
Class ou TC) dans l’entête IPv6.

159
Classification et conditionnement
6 bits sont utilisés pour le
Differentiated Service
Code Point (DSCP) et
déterminent le PHB que
le paquet recevra.
 Les 2 autres bits sont
actuellement non utilisés.

160
161
 Modèle DiffServ

162
 Modèle DiffServ

163
Fonctions du routeur de cœur
 Acheminement des paquets: selon le PHB (“Per-
Hop-Behavior” ) associé à chaque classe de trafic
particulière,
 Le PHB est strictement basé sur le marquage de classe
(aucun autre champ d'en-tête ne peut être utilisé pour
influencer PHB).
 GROS AVANTAGE!
 Aucune information d'état à maintenir par les
routeurs!

164
PHB (“Per-Hop-Behavior” )
 Le PHB est le traitement par saut subit un paquet marqué par un champs
DSCP
 Le PHB entraîne un comportement de performance de transmission
observable (mesurable) différent pour différentes classes de service
 PHB ne spécifie pas le mécanisme à utiliser pour assurer la performance du
comportement PHB
 Agrégation du traitement: les paquets de même classe de trafic sont
traités de la même manière
 Exemples de PHB
 La classe A obtient x% de la bande passante sur un lien sortant à des intervalles
de temps d'une longueur spécifiée.
 Les paquets de classe A sortent d'abord avant les paquets de la classe B.
165
PHB (“Per-Hop-Behavior” )
 Groupes de PHB standardisés
 Expedited Forwarding (RFC 2598 – Juin 1999)
 Assured Forwarding (RFC 2597 Juin 1999)
 Best effort (RFC 2474 – Déc 1998) Code DSCP = ‘000000’

 Remarque:
 PHB corresponde à un DSCP recommandé par l’IETF,
mais les operateurs réseaux peuvent choisir les siens,
mais il aurait un problème d’interopérabilité

166
Expedited Forwarding (EF) (DSCP =‘101110’)
 Garantie un certain débit minimal pour le trafic EF
 Permet l’isolation du trafic: la garantie pour le trafic EF n’est
pas influencée par les autres classes de trafic (plus prioritaire).
 Peut fonctionner correctement si le trafic à la source ne dépasse
pas une borne maximale (débit crête)
 Il offre une bande passante garantie, une faible latence, une faible gigue
et faible probabilité de perte
 Exemple:
 Adapté à la VoIP et les lignes virtuelles louées (ex.VPN)

167
Assured Forwarding
 AF définit 4 classes avec une certaine bande passante et des
files d’attentes qui leur sont attribués.
 L’objectif est d’offrir différents niveaux de services, en terme de
débit (Gold, Silver, Bronze, etc.)
 Chaque classe, défini 3 niveaux de rejet (drop precedence) en
cas de congestion
 Le délai et la gigue ne pas garanties, et la probabilité de perte
est non quantifiable mais dépend du DSCP
 Le trafic non conforme sera remarqué

168
Assured Forwarding

169
Limites du modèle DiffServ
 La fourniture de la QoS par agrégation de flux ne permet
d’avoir la QoS de bout-en-bout pour chaque flux
 Les contrat de service sont statiques, ne répond pas à
l’évolution du besoin de l’utilisateur
 DiffServ est orienté émetteur, ne connais rien sur la
capacité du récepteur (SIP)

170
Limites du modèle DiffServ
 Nombre limité de classes de services, souvent
surdimensionné, en agrégeant deux flux de 10ms et 50ms
 Implantations efficaces des blocs fonctionnels (scheduling,
routing, meter, shaping…)
 Les solutions possibles
 Réservation de ressources dynamiques : stratégies et
signalisation
 DiffServ sur MPLS, GMPLS, DiffServ et réseaux ad hoc,
réseaux de capteurs
171
IntServ vs DiffServ (Résumé)

172
IntServ & DiffServ

173
 Chapitre 3: Multi Protocol Label Switching

Akram Hakiri

174
MPLS - Motivation
 Les opérateurs veulent :
 Empiler deux environnements IP & ATM sur une même
architecture (service AAL5)
 Bénéficier l’universalité de l’adressage IP et la puissance de
transfert de l’ATM (QoS)
 Deux problèmes qui se posent:
 la conversion d’une adresse IP (1500 octets) en cellules ATM
(53 octets)
 Conversion d’une adresse IP en couple VPI/VCI !!
175
MPLS - Motivation
 Emulation LAN (protocole LANE)
 Remplacer un sous-réseau IP par un réseau ATM (conserver les interfaces UNI)
 Une adresse MAC comme intermédiaire entre l’adresse IP et l’adresse ATM pour
interconnecter des switches ATM avec des terminaux LAN
 Mais, nécessite une double correspondance IP-MAC et MAC-ATM
 Le protocole CIOA (Classical IP over ATM), mais limité à un seul réseau
ATM
 Utiliser un serveur de routes lorsqu’il y a plusieurs routes ATM
 MPOA (Multi Protocol Over ATM),
 PNNI (Private Network Node Interface)
 NHRP (Next Hop Resolution Protocol),
176
MPLS-Motivation
 Nécessité d’avoir une expédition ultra-rapide et offrir la QoS ATM
 un seul protocole plus homogène qui regroupe IP et ATM
 MPLS: Multi Protocol Label Switching
 MPLS + IP forme un mécanisme puissant combinant les points forts
des deux technologies de commutation (circuit et paquets IP).

177
MPLS
 Comme MPLS est multi-protocoles, il faut aussi des
labels multi protocoles
 Comme ATM et Ethernet, il utilise la commutation d’une
référence, dite étiquette, mais d’autres types de trames
LAP-M et PPP
 MPLS crée un chemin pour les étiquettes, qui n’est autre
que le circuit virtuel ATM
 Les paquets IP qui suivent ce chemin sont commutés
dans les routeurs IP.
178
MPLS et le modèle OSI
 MPLS est un protocole de la couche 2,5

Applications

TCP UDP
IP
MPLS MPλS
PPP FR ATM Ethernet DWDM
Physical

179
Types de Trames MPLS
Entête Cellule ATM VPI VCI PTI CLP HEC DATA

Label

Entête PPP PPP Header Label Layer 3 Header

Shim header

Entête Ethernet MAC Header Label Layer 3 Header

180
Routage conventionnel (rappel)
Dest Out
Construction de table 47.1 1
de routage 47.2 2 1 47.1
47.3 3 3
Dest Out 1 2
47.1 1 3
2
47.2 2
47.3 3
1
47.3 3 47.2

181
Routage conventionnel (rappel)
D e s t O u t
D e s t O u t
4 7 .1 1
Transmission 4
4
7 .1
7 .2
1
2
4 7 .2 2

traditionnelle IP 4 7 .3 3
4 7 .3 3

1 47.1
D e s t O u t IP 47.1.1.1
1 2 IP 47.1.1.1
4 7 .1 1 3
4 7 .2 2 2
4 7 .3 3
IP 47.1.1.1
1
47.3 3 47.2

2
IP 47.1.1.1

182
Routage IP conventionnel (1/2)
 Sur chaque routeur les paquets sont analysé pour
déterminer le prochain saut, selon la table de routage.
 La procédure est répétée dans tous routeurs traversés
 Problème:
 Il n’est pas toujours nécessaire d’analyser le contenu de
toute l’en-tête IP à chaque passage par un routeur
 Il serait préférable de réaliser ce traitement à la bordure du
réseau d’accès, à l’entrée et à la sortie du cœur du réseau

183
Pourquoi MPLS
 Solution:
 réduire le temps de traitements dans les routeurs afin de
gagner en performance!!
 C’est le principale avantage de MPLS:
 l’entête IP est analysée une seule fois par le routeur de
bordure « Ingress »
 Le routeur de bordure affecte a une classe « FEC » identifiée
un « Label »
 Les autres Routeurs commutent le paquet selon le Label sans
184 analyser d’entête IP
Label MPLS
 Définit dans la RFC 3031, il permet d’identifier une FEC

Label Exp S TTL

(20 bits) (3 bits) (1 bit) (8bits)
Label = 20 bits
Exp = Expérimental, 3 bits
S = Indique le bas de pile, permet d’empiler des labels, 1bit
TTL = Time to live, 8 bits
185
Composants d’un réseau MPLS
 Label Edge Router (Ingress LER)
 Pousse une étiquette dans l’entête de paquet IP et expédie
le paquet
 Label Switch Router (LSR)
 Réalise la commutation d’étiquettes dans le réseau de cœur
 Label Edge Router (Egress LER)
 Supprime l’étiquette à la sortie du réseau MPLS

186
Composants d’un réseau MPLS

187
Commutation de Labels
• Chaque trame encapsulant un paquet IP qui entre dans le
réseau MPLS se voit ajouter par le LSR d’entrée, un label
au niveau de l’en-tête permettant d’acheminer la trame
dans le réseau.
• Les chemins sont préalablement ouverts par un
protocole de réservation de ressources, RSVP ou LDP.
• À la sortie du réseau, le label ajouté à l’en-tête de la
trame est supprimée par le LSR de sortie, ou Egress LSR.
188
Commutation de labels sur LSR d’entrée

189
Commutation de labels
sur LSR de cœur

190
Commutation de labels sur LSR de sortie

191
Label Switched Path (LSP)
 Le routage saut par saut (hop-by-hop).
 Les LSRs sont indépendants les uns des autres
 LSR utilise un protocole de routage comme OSPF
 Pour des sous-réseaux ATM, PNNI
 Le routage explicite (identique au routage à la source)
 Le LER d’entrée du domaine MPLS spécifie la liste des nœuds
par lesquels la signalisation a été routée,
 le choix de cette route pouvant avoir été contraint par des
demandes de qualité de service.
192
Établissement du LSP
 Il
existe deux modes pour l’établissement d’un LSP
MPLS :
 Mode non connecté
 les
LSP sont établis par le protocole LDP et suivent le plus
court chemin IP
 Mode connecté
 Les chemins sont établis par le protocole RSVP-TE, et suivent un
chemin explicite, indépendant du chemin IP
 les chemins sont établis en fonction des contraintes de trafic et
des ressources disponibles (bande passante, délai...)
193
Label Distribution Protocol (LDP )
 LDP est le protocole de distribution des labels MPLS
 Ce protocole tient compte des adresses unicast et
multicast
 Le routage est explicite et est géré par les nœuds de
sortie.
 Les échanges s’effectuent sous le protocole TCP pour
assurer une qualité acceptable

194
Label Distribution Protocol (LDP )
 Le protocole LDP comprend les messages suivants :
 Message de découverte (DISCOVERY MESSAGE), qui
annonce et maintient la présence d’un LSR dans le réseau.
 Message de session (SESSION MESSAGE), qui établit,
maintient et termine des sessions entre des ports LDP.
 Message d’avertissement (ADVERTISEMENT MESSAGE),
qui crée, maintient et détruit la correspondance entre les
références et les FEC.
 Message de notification (NOTIFICATION MESSAGE), qui
donne des informations d’erreur ou de problème.
195
Techniques de distributions de Labels
 Basé sur la topologie, il utilise les messages destinés au
routage comme OSPF
 Basé sur la demande, il utilise une demande d’ouverture
d’un chemin pour un flot (RSVP-TE) en tenant en compte les
ressources réseau
 Basé sur le trafic, à la réception d’un paquet, une référence
est assignée à la trame qui le transporte.
 Par Protocol MPLS dédié, il utilise le protocole LDP ou le
protocole Constraint-based routing LDP (support de la QoS)
196
Exemple de distribution des labels (1/4)
 Avant de fixer les labels et de les expédier, il faut que les
tables de routages soient construite (OSPF, RIP, BGP,
etc.)
 Chaque LSR associe un label à chaque FEC
 Ensuite, les labels sont communiquées aux autres LSR en
prenant le chemin inverse des données.

197
Exemple de distribution des labels (2/4)
 Construction de table d’expédition (par OSPF…)

198
Exemple de distribution des labels (3/4)
 Distribution de label

199
Exemple de distribution des labels (4/4)
 Les paquets empruntent le LSP

200
Forwarding Equivalence Class (FEC)
 Une classe représente une destination ou un ensemble
de destinations ayant le même préfixe dans l’adresse IP.
 un paquet qui a une destination donnée appartient à une
classe et suit une route commune (même traitement)
avec les autres paquets de cette classe.
 Cela définit un arbre, dont la racine est le destinataire et
dont les feuilles sont les émetteurs.
 Les paquets n’ont plus qu’à suivre l’arbre jusqu’à la
racine
201
 Exemple de classe d’équivalence (FEC)

202
Exemple de classe d’équivalence (FEC)
 Dans cet exemple, les terminaux 1, 2 et 3 souhaitent
émettre un flux de paquets IP vers la station terminale 4.
 Pour cela, la station 1 émet ses trames (encapsulant les
paquets IP) avec la référence 28, qui est commutée vers
la référence 47 puis commutée vers les références 77
puis 13 puis 36.
 Le flot partant de la station 2 est commuté de 53 en 156
puis en 77, 13 et 36.
203
Exemple de classe d’équivalence (FEC)
 Enfin, letroisième flot, partant de la station 3, est
commuté à partir des valeurs 134 puis 197, 13 et 36.
 On voit que l’agrégation s’effectue sur les deux premiers
flots avec la seule valeur 77 et que les trois flux sont
agrégés sur les valeurs 13 et 36.
 La station 4 aurait pu être remplacée par un sous-
réseau, ce qui aurait certainement permis d’agréger
beaucoup plus de flux et d’avoir une granularité moins
fine.
204
Exemple de classe d’équivalence (FEC)
 le récepteur est la machine 1 et la FEC est déterminée
par l’arbre dont les feuilles sont les machines terminales
1, 2 et 3.
 La classe d’équivalence, en descendant l’arbre à partir de
1, commence par les références 28 puis 47 et se
continue par les branches 77 puis 13 puis 36.

205
Exemple de classe d’équivalence (FEC)
À partir de 2, les références 53 puis 156 sont utilisées
pour aller vers la racine.
 À partir de 3, ce sont les références 134 et 197 qui sont
utilisées.
 Toutes les références que nous venons de citer
appartiennent à la même classe d’équivalence.
 Il y a une correspondance entre FEC et classe de QoS.

206
Utilisation de MPLS
 MPLS offre trois fonctions essentielles :
 l’encapsulation de trafic (tunneling MPLS) utilisée pour le
support des réseaux privés virtuels (VPN),
 l’ingénierie de trafic incluant un contrôle d’admission et
l’optimisation de la bande passante, qui permet de partager
la charge et d’éviter les congestions,
 la protection de trafic permettant un reroutage en moins de
50 ms en cas de panne.
 Supporter la qualité de service (QoS)
 Routage multicast

207
Routage multicast (rappel)
 Multicast (RFC1112): Le datagramme est envoyé d’une source
vers un groupe de destinations (@IP de classe D (IPv4))
 224.0.0.0 ~ 239.255.255.255
 le protocole IGMP (Internet Group Management Protocol) est
utilisé par les membres pour rejoinder un groupe multicast
 Les membres joignent et quittent le groupe et indiquent cela aux
routeurs
 La source peut ne pas appartenir au groupe multicast
 Les routeurs écoutent toutes les adresses multicast et utilisent
des protocoles de routage multicast pour gérer les groupes
208
Routage multicast (rappel)
 Multicast au niveau application  Multicast IP
 Plusieurs destinations unicast  Groupe multicast

R R
S S
R R

R R
209
MPLS Multicast- Motivation
 La croissance des flux multicast avec de fortes
contraintes de bande passante et de disponibilité (IPTV,
visioconférence multipoint, jeux en réseau)
 Le besoin de transporter ces flux multicast dans des
réseaux privés virtuels (VPN)
 Ceci nécessite de disposer de fonctions de
 D’encapsulation (Tunneling) multicast,
 TE multicast (optimisation des arbres, contrôle d’admission)
 Protection multicast.
210
Multicast MPLS
 L’IETF a étendu l’architecture MPLS afin de supporter
efficacement le transport des flux multicast
 Repose sur l’établissement de LSP MPLS point-à-multipoint
(P2MP), ou arbres MPLS
 Il s’agit de LSP avec un LSR de tête appelé «LSR racine» et un
ensemble de LSR destinations appelés «LSR feuilles», avec une
réplication du trafic sur les routeurs de transit.
 Le multicast MPLS hérite de toutes les propriétés de MPLS.
 Il permet l’encapsulation de trafic multicast dans des tunnels
pour le support de VPNs
211
 Racine
Exemple de P2MP LSPs

Bronche Feuille

Feuille

Feuille
212 Feuille
Mise en place des Arbres MPLS
 Consiste à étendre les protocoles LDP et RSVP-TE pour
offrir deux modes pour l’établissement des arbres, le
mode non connecté et le mode connecté
 Mode non connecté
 Repose sur une extension du protocole LDP, appelée
«multicast LDP» (MLDP)
 Les arbres LDP suivent le plus court chemin vers la racine.

213
Mise en place des Arbres MPLS
 Mode connecté
 Repose sur une extension du protocole RSVP-TE dite «P2MP RSVP-
TE»,
 Les arbres P2MP RSVP-TE sont établis de façon explicite et
empruntent des chemins indépendants des chemins IP, en respectant
des contraintes d’ingénierie de trafic (bande passante...).
 Le mode connecté permet un contrôle d’admission et une
optimisation des arbres.
 Il permet également de protéger les arbres sur une extension des
mécanismes de protection MPLS Fast Reroute, appelée « P2MP MPLS
Fast Reroute ».
214
Multicast LDP (MLDP)
 Le protocole multicast LDP (MLDP) est une extension du
protocole LDP mettant en place des LSP P2MP.
 Les LSP P2MP LDP sont construits sur le plus court chemin
vers le LSR racine.
 Leur établissement est initié par les LSR feuilles et les LSR de
transit ne maintiennent pas l’information sur les feuilles mais
uniquement sur les LSR voisins dans l’arbre.
 MLDP passe donc très bien à l’échelle, la taille d’un état étant
indépendante du nombre de feuilles de l’arbre.
215
Multicast LDP (MLDP)
 MLDP est bien adapté aux opérateurs de VPN MPLS qui
ont déjà déployé LDP pour le transport de trafic unicast
et veulent offrir des services multicast.

216
Construction de P2MP LSP avec LDP
 Étape 1: tous les nœuds feuilles trouvent l'identité du LSP
 Par une application qui utilise P2MP LSP avec LDP
 L'identité comprend l'adresse du nœud racine
 Étape 2: :Chaque nœud feuille initialise la configuration P2MP
LSP par envoi du message LDP Label Mapping vers la racine
 Envoie un message (upstream) vers le LSR qui se trouve sur le chemin
vers la racine
 Utilise une route unicast vers la racine
 Le message de mappage d'étiquette porte l'identité du LSP
 Encodé comme élément P2MP FEC (Forwarding Equivalence Class)
217
Construction de P2MP LSP avec LDP
 Étape 3: chaque nœud intermédiaire entre la feuille et la racine
propage le message de mapping de label LDP (LDP Label
Mapping) vers la racine
 Envoie le message (upstream) uniquement au LSR sur le chemin vers la
racine
 Utilise une route unicast vers la racine

218
Élément P2MP FEC
 Tous les nœuds feuilles d'un même P2MP LSP donné doivent
utiliser le même classe d’équivalence élément PECMP FEC pour
cet LSP
 Par une application qui utilise P2MP LSP avec LDP
 L‘élément P2MP FEC transporte deux information:
 L’adresse du nœud racine
 Une valeur opaque qui doit être unique au moins dans le contexte du
nœud root
 L'élément P2MP FEC forme un identifiant globalement unique
pour un P2MP LSP
219
Élément P2MP FEC
 L'élément
P2MP FEC n'a pas besoin de spécifier
directement quels paquets sont mappés dans le P2MP
LSP
 Il y a un mapping indirect (ex. par auto-découverte dans VPN
multicast)
 L'élément
P2MP FEC est transporté dans les messages
« LDP Label Mapping” et “Label Withdraw”
 Ce qui permet de créer une liaison d'étiquette pour un
élément FEC P2MP donné (pour un P2P PSP)
220
 Exemple de signalisation LDP P2MP

221
Construction de P2MP LSP avec RSVP-TE
 Étape
1: la racine trouve les adresses IP de touts le
nœuds filles
 Par une application qui utilise P2MP LSP avec RSVP-TE
 Étape
2: la racine calcule les chemins à partir de lui-
même vers tous les nœuds feuilles
 Soit par le protocole Constrained Shortest Path First (CSPF),
ou bien de manière approximative avec le protocole
constrained minimum cost tree (aka Steiner tree)
 Supporte les mêmes contraintes d'ingénierie de trafic que
222 LSP point-à-point avec RSVP-TE
Construction de P2MP LSP avec RSVP-TE
 Étape
3: Root utilise RSVP-TE pour configurer le
chemin P2MP LSP
 Établitl'état de transmission de l'étiquette
 peut impliquer des réserves de ressources

223
Signalisation RSVP-TE pour P2MP LSP
 RSVP-TE pour P2MP LSP est une extension de RSVP-TE
pour les communication point à point
 Modifications minimale de l’échange RSVP-TE classique
 Composants de RSVP-TE pour P2MP LSP
 P2MP Tunnel
 P2MP LSP
 Un ou plusieurs labels par tunnels P2MP
 S2L sub-LSP
 Un ou plusieurs sous-labels par P2MP LSP
 Messages Path et Resv
224
Tunnel P2MP
 Le tunnel P2MP est identifié par l'objet P2MP SESSION qui
comprend:
 Extended Tunnel ID : adresse IPv4 / IPv6 du nœud racine du tunnel
 P2MP ID: Identifiant logique 32 bits du tunnel P2MP
 Unique dans le contexte du nœud racine
 Tunnel ID: identifiant sur 16 bits
 Unique dans le contexte du nœud racine

 Le triplet <Extended Tunnel ID, P2MP ID, Tunnel ID> forme un

identifiant globalement unique pour un tunnel P2MP
 Le tunnel P2MP comprend un ou plusieurs P2MP LSP
225
 Tous ces LSP P2MP ont la même racine et le même ensemble de feuille
Labels P2MP LSP
 P2MP LSP est une instance spécifique d'un tunnel P2MP
 P2MP LSP est identifié par une combinaison des objets
P2MP SESSION et P2MP SENDER_TEMPLATE
 L'objet P2MP SENDER_TEMPLATE comprend
 IPv4/IPv6 Tunnel Sender Address : adresse du nœud racine du
LSP (même que Extended Tunnel ID )
 LSP ID: identifie une instance spécifique d'un tunnel P2MP
 Chaque P2MP LSP comprend plusieurs sous-LSPs S2L
226
Sous-labels « S2L Sub-LSP »
 P2MP LSP comprend plusieurs S2L Sub-LSPs, un pour chaque
nœud feuille,
 S2L Sub-LSP est un LSP de la racine à une feuille particulière
 Le S2L Sub-LSP est représenté par:
 Objet S2L_SUB_LSP
 Identifie un S2L_SUB_LSP particulier, qui est l’adresse destination du
nœud feuille (unicast)
 Objet ERO or sub-ERO:
 Représente la route explicite de la racine à la feuille
 Peut être compressé, si plusieurs S2L_SUB_LSP sont portés dans le
227 même message Path
Messages Path et RSVP
 Un P2MP LSP peut être signalé en utilisant un ou
plusieurs messages Path/Resv
 Chacun de ces messages Path/Resv peut signaler un ou
plusieurs sous-LSPs S2L
 Exemple particuliers:
 Un message Path/Resv séparé pour chaque Sub-LSP S2L d'un
P2MP LSP donné
 Un seul message Path/Resv pour tous les Sub-LSP S2L d'un
P2MP LSP donné
228
Exemple de signalisation
RSVP-TE P2MP
229
MPLS et QoS – DiffServ (rappel)
 MPLS ne définie pas une nouvelle architecture de QoS, il utilise
DiffServ
 Le principe de DiffServ reste inchangé:
 TCA (Traffic Conditioning Agreement) et PHB
 Classification, marquage, régulation (policing), mise en forme
(shaping) sur la bordure du réseau
 Gestion des files d’attentes (FIFO, WFQ, WRR) et ordonnancent de
paquets utilisés pour implémenter le PHB
 Définitions du PHB  Expedited Forwarding (EF): low delay/jitter/loss
 Assured Forwarding (AF): low loss
 Default (DF): No guarantees (best effort)
230
231
MPLS QoS (les nouveautés)
 Problèmes:
 Comment transmettre les paquets agrégés et classifié?
 Comment réaliser l’interaction entre les informations MPLS
DiffServ et les informations DiffServ encapsulées (par
exemple IP DSCP) .
 Solution
 Les classes de trafic et les précédences IP sont inférés du
champ EXP (3bits)
 La RFC3270 ne spécifie pas des valeurs aux bits EXP pour le
PHB DiffServ (EF/AF/DF)
232
QoS MPLS – Classes de Trafic
 Typiquement, on a entre 3 et 5 classes de service (real
time, video, interactive, business, BE)
 le réseau MPLS à QoS doit garantir :
 le délai, la gigue et les pertes pour le trafic temps-réel,
 le délai et les pertes pour la vidéo interactive (data)
 La somme de la bande passante engagée ne doit pas dépasser
la capacité du lien (sinon, lissage de trafic)
 Il existe d’autres classes réservées pour le contrôle et la
gestion du réseau (par l’opérateur)
233
QoS MPLS – Classes de Trafic
 MPLS à QoS doit garantir :
 le délai, la gigue et les pertes pour le
trafic temps-réel,
 le délai et les pertes pour la vidéo
interactive (data)
 La somme de la bande passante engagée
ne doit pas dépasser la capacité du lien
(sinon, lissage de trafic)
 Il existe d’autres classes réservées pour
le contrôle et la gestion du réseau (par
l’opérateur)
234
 IP SLA entre Sites
 Site vers réseau (point-to-cloud),
garantie pour le trafic conforme
 Chaque site peut envoyer x% paquets
de la classe n vers le réseau par SLA
 Chaque site peut recevoir x%
paquets de la classe n vers le réseau
par SLA
 Pas de garantie inter-sites (point-to-
point)
235
DiffServ Tunneling Modes
 Plusieurs modes d’interaction:
 RFC 2983 définie les modèles (uniform, pipe)
pour DiffServ avec des Tunnels IP
 RFC 3270 définie les modèles [uniform, pipe,
short-pipe] pour MPLS
 Les deux approches sont pertinentes
uniquement lors de opérations Push-Pull
 L'étiquette NULL explicite peut être utilisée
pour les services gérés

236
MPLS DiffServ Tunneling Modes

237
Uniform Mode

238
Pipe Mode

239
Short Pipe Mode

240
MPLS et QoS
 MPLS est amené à inter fonctionner
avec DiffServ, car LDP supporte avant
tout de la QoS à faible granularité.
 IntServ et DiffServ sont donc 2
mécanismes complémentaires
permettant d'établir une QoS
consistante sur les réseaux MPLS et
non MPLS.

241
Ingénierie du trafic (TE)-Motivation
 L'ingénierie du trafic permet à un administrateur de réseau de rendre le
chemin déterministe et de contourner les chemins routés hop-by-hop
routés.
 Un administrateur peut choisir de définir explicitement le chemin entre
les stations pour assurer la QoS ou faire en sorte que le trafic suit un
chemin spécifié pour réduire le chargement du trafic à travers certains
bonds.
 L'administrateur réseau peut réduire la congestion en forçant les
paquets à dépasser des segments surchargés.
 L'ingénierie du trafic permet de définir une politique de transfert de
paquet indépendamment des protocoles de routage dynamique.

242
Ingénierie du trafic (TE)-Motivation
 Améliorer les performances des routeurs en traitant les paquets IP
directement au niveau 2 (commutation) sans avoir à remonter
systématiquement au niveau 3 (routage) à chaque bond.
 Commute un paquet IP à partir d'un " label " revient à utiliser le label
entrant comme pointeur dans un tableau dont la case correspondante
contient l'interface de sortie vers laquelle le paquet doit être envoyé,
ainsi que le nouveau label à lui affecter.
 Une telle opération, qui correspond exactement au traitement du champ
VPI/VCI d'une cellule entrant dans un commutateur ATM, est à priori
beaucoup plus simple que l'opération classique de routage d'un paquet
IP.
243
MPLS et l’ingénierie de trafic
 Par " Traffic Engineering MPLS ", il faut comprendre:
 établissement de connexions à la demande,
 gestion de trafic ,
 gestion des routes,
 gestion des ressources,
 gestion de l'écoulement de flux de trafic à travers un réseau IP.
 via un Label Switched Path (LSP), MPLS permet d'imposer le
chemin que les paquets IP doivent suivre pour atteindre une
destination donnée. Un LSP est donc unidirectionnel.

244
Ingénierie du trafic (TE)
 Ingénierie du trafic (TE)
 Effectuer des calculs pour déterminer les ressources à affecter à un chemin
lorsque le système est relativement statique.
 Si le système est dynamique, des chemins doivent s’ouvrir et se fermer pour
satisfaire à des contraintes qui s’expriment sur des laps de temps plus courts.
 Dans RSVP-TE, il n’y a pas de négociation de labels: C’est le plan de gestion qui
prend à sa charge cette négociation.
 L’IETF a introduit dans l’architecture MPLS:
 un routage à base de contrainte
 et un protocole de routage interne à état des liens étendu afin de réaliser une
ingénierie de trafic efficace.

245
MPLS et l’ingénierie de trafic
 MPLS et ses LSPs constituent dès lors un outil de gestion et
d'optimisation de l'utilisation des ressources d'un réseau IP
 Traffic Engineering " de LSP MPLS s'apparente à la fonction Soft
PVC unidirectionnel qui existe en commutation ATM
 La principale différence entre un LSP MPLS et un Soft PVC ATM
est qu'il est possible d'associer à un Soft PVC une catégorie de
service ATM, ainsi que des paramètres de trafic et de QoS.
 Dans un réseau MPLS simple, établir des LSP revient alors à
établir des Soft PVC UBR unidirectionnels : on marque un chemin
à travers le réseau sans lui associer de ressources.

246
MPLS et l’ingénierie de trafic

Overload !!
LER 1 LER 4 IP
IP Overload !!
IP L
IP L

Forward to IP L
LSR 2
LSR 3 LSR 2 LSR 3
LSR 4
LSR X

 Pour activer l'ingénierie du trafic, la décision d'acheminement de bout

en bout est déterminée par un noeud d'entrée.

247
MPLS et VPN
 Les VPNs (RFC 2547) est l’une des applications les plus répandue de
MPLS
 Il permet d’offrir des services réseau IP privé sur le réseau IP public
 On peut utiliser un adressage privé sur un réseau public.
 Il utilise la couche IP (VPN niveau 3)
 Il permet de supporter la QoS, et offre une scalabilité aisée
 Accès contrôlé et protégé (isolé) vis-à-vis des autres flux sur l'infrastructure
public.
 Utilise des labels (au lieu des @IP) pour interconnecter des sites distants
 Chaque site a ses propres adresses privées

248
VPN MPLS
 On peut implémenter plusieurs VPNs sur un même réseau MPLS
 Un identifient « Route Distinguisher » permet de différencier les routes
 Route Distinguisher : sur 8 octets ajouté au préfixe IP (4 octets) pour étendre
l’adressage
 Pour Interdire le routage inter-VPNs, MPLS implémente une table de routage
spécifique (Virtual Routing and Forwarding table  VRF)
 Isolation de trafic: Chaque VPN possède sa VRF et ne voient pas les autres routes
MPLS

249
 MPLS et VPN
 Les informations de routage à l'intérieur
d'un VPN sont distribuées de la manière
suivante :
1. du site client vers le VBG (VPN Border
Gateway) source : via RIP, OSPF ou en routage
statique
2. au niveau du VBG source : exportation vers
BGP
3. entre VBG source et VBG destination : via BGP
4. au niveau du VBG destination : importation à
partir de BGP
5. du VBG destination vers le site client : via RIP,
OSPF ou en routage statique

250
MPLS et VPN
 Le VBG source applique 2 labels au paquet de data lorsqu'un VPN est utilisé
(Cisco utilise une autre méthode: La VPN-IP@ = 96 bits: 64 bits identifiant le
VPN et 32 bits de l'@ IP-V4 classique).
 le premier label (extérieur) identifie le chemin vers le VBG destination, et change à
chaque bond
 le second label (intérieur) spécifie le VPN-ID attribué au VPN et n'est pas modifié
entre le VBG source et le VBG destination
 Cette paire de labels permet d'implémenter aisément les mécanismes des VPN dans
MPLS:

251
Extensions du MPLS
 Generalized Multi Protocol Label Switching (GMPLS)
pour étendre MPLS aux réseaux optiques
 Virtual Private LAN Services (VPLS) pour la gestion de
VPNs multipoint de niveau 2
 Découpler les technologies du cœur de réseau des accès
 Pas de gestion de table de routage sur les PE

252
GMPLS
 GMPLS est proposé pour la signalisation dans les réseaux optiques
 Les opérateurs réseau veulent transporter une grande quantité
d’information de manière fiable
Carry applications
 Problèmes: IP
and services
 Complexité dans la gestion de couches multiples ATM Traffic Engineering
 Utilisation de bande passante inefficace SONET/SDH Transport/Protection

 Pas évolutif DWDM Capacity

 Solutions
 Éliminer les couches intermédiaires  IP sur réseaux optiques (IP/WDM)
 Besoin d’un protocole qui réalise les fonctions des couches intermédiaires
(GMPLS)
253
GMPLS
 La sélection de l'architecture peut être basée sur la décision commerciale
 GMPLS fournit un plan de contrôle commun qui
 supporte plusieurs types de trafic (ATM, IP, SONET and etc.)
 Supporte les modèles overlay et peer-to-peer
 Support multifournisseurs
 Effectue un approvisionnement rapide

UNI UNI

Overlay Model Peer Model

254
GMPLS
 GMPLS applique les techniques du plan de contrôle MPLS aux
commutateurs optiques, et les algorithmes de routage IP pour gérer les
chemins optiques

255
Interfaces de contrôle GMPLS
 GMPLS a apporté quelques modifications sur MPLS:
 Séparation de la voie de signalisation et de données
 Supporter plus d'interfaces de contrôle
 Packet Switch Capable (PSC)
 Router/ATM Switch/Frame Reply Switch
 Time Division Multiplexing Capable (TDMC) PSC TDMC LSC
 SONET/SDH ADM/Digital Crossconnects FSC
 Lambda Switch Capable (LSC) TDMC
 All Optical ADM or Optical Crossconnects (OXC)
 Fiber-Switch Capable (FSC)
LSC

256
GMPLS – Label suggéré
 Problème:
 la configuration d’un routeur optique prend beaucoup de temps
 Solution
 Chaque LSR sélectionne une étiquette (Étiquette suggérée) et signale cette
étiquette à LSR en aval, et commencez à programmer son commutateur.
 Ce qui réduit la surcharge du LSR lors de sa configuration
No suggested label with suggested label
Program Switch λ1 X λ2
Request Request Suggested Label = λ1 Suggested Label = λ2

Map Label = λ1 Map Label = λ2 Reserved Label = λ4 Reserved Label = λ3

Program Switch λ1 X λ2 Make sure the programming

request has completed
257
 MPLS = Harmonisation des solutions aux problèmes
d’interconnexion

258
Conclusion
 Augmentation de besoin pour supporter la QoS sur Internet
 Les solutions traditionnelles (par hop vs par application)
 DiffServ vs IntServ
 DiffServ + IntServ + MPLS
 Il manquent le provisionnement de la QoS de bout en bout
 La signalisation de la QoS
 La déclaration de niveau de service (SLA & SLS)
 Intégration de novelles technologies (WIMAX, 3G, 4G, 5G)
Besoin de nouvelles architectures à QoS E2E
259
 Chapitre 4: Contrôle par politique

Akram Hakiri

260
Motivation
 Croissance exponentielle des réseaux, en taille et en volume
 Une grande variété de périphériques gérés (non seulement les
routeurs, commutateurs, etc.) et les ressources.
 Un grand nombre de services de réseau différents
 Réseaux convergents (données, voix, vidéo, web)
 Nouveaux services (VPN,VoIP, IPTV)
 Complexité croissante de MPLS, DiffServ et IntServ-RSVP
 Besoin d’améliorer le niveau d’abstraction et d’automatisation
du management du réseau
Besoin de solutions évolutives de gestion des réseaux
261
Techniques classiques - CLI
 CLI (Command Line Interface)
 Chaque équipement est programmé individuellement pour implémenter les
objectifs de l’administrateur, même pour implémenter les mêmes objectifs
 Lorsque la topologie change, l’administrateur doit mettre à jour les routeurs
indépendamment
 Problèmes
 Problèmes d'évolutivité SIGNIFICATIFS
 Problèmes de cohérence
 Difficile de mettre en œuvre des politiques complexes
 Manque d'automatisation
 Besoin de personnel hautement spécialisé
 Difficile de surveiller le réseau
262
Techniques classiques - SNMP
 Simple Network Management Protocol (SNMP)
 Les périphériques sont gérés de manière unifiée
 Augmentation du niveau d'abstraction
 Autorisé une certaine automatisation
 Problème
 SNMP a été conçu pour la surveillance – pas pour configurer des
périphériques
 Problèmes d'évolutivité et d'efficacité
 Les équipements sont fixent et dépendant du fournisseur
 La configuration dépend toujours du rôle, des capacités, limitations du
263 périphérique, du fabricant et de la topologie globale du réseau
Le contrôle par politique (PBN)
 Une approche moderne de management du réseau moderne
 Basée sur des politiques et des stratégies abstraites de haut
niveau (PBN--Policy Based Network)
 Le contrôle par politiques tente de
 Augmenter le niveau d'abstraction
 Automatisez le management du réseau
 Centraliser et simplifier les configurations du réseau
 Simplifier la supervision
 Augmenter la flexibilité de gestion
 Il faut une architecture évolué pour implémenter les politiques
264
Architecture PBN
 Deux éléments clés Business/Control
Policies

 Policy Decision Point (PDP)

Other
Services &
Directory
Events
 Policy Enforcement Point (PEP) Service

 Principe de fonctionnement Network State/Events

 L’administrateur édite une politique abstraite avec

un outil d’édition Policy Console

 Les politiques sont envoyées pour décrire le

comportement du réseau avec un niveau élevé
d'abstraction PDP PDP
 Les politiques sont traitées par les PDP Manager Decision Making

 Les politiques sont distribuées aux PEP en tant

que données de configuration – commandes Decision Enforcement

(après avoir été transformées sur la forme PEP PEP PEP PEP

appropriée)
Devices

265
Avantages du PBN
 Gestion centralisée Business/Control
Policies
Other

 Évolutivité
Services &
Directory
Events
Service

 Haute abstraction Network State/Events

 facile à déterminer et à contrôler le

comportement
Policy Console

 Automatisation  Consistance
 Changement dynamique des politiques PDP PDP
Manager Decision Making

 nouveaux types de politiques, flexibilité

Decision Enforcement
 Il faut un protocole pour implémenter PEP PEP PEP PEP

PBN  COPS !! Devices

266
Common Open Policy Service -- COPS
 COPS est un protocole de requête et de réponse simple, utilisé
pour échanger des informations entre PDP et PEP [RFC 2748]
 PEP : Policy Enforcement Point
 Routeurs
 PDP : Policy Decision Point
 Serveurs contenant des base de données de politique
 COPS utilise des règles de négociées simples pour assurer QoS
 l'allocation des ressources, des priorités et de l'autorisation
hiérarchique, etc.

267
COPS
 Basé sur un modèle client serveur classique
 Utilise TCP pour l’échange de messages (fiabilité)
 Affectation des ressources aux priorités souhaitées des services.
 Programmer les équipements de manière autonome
 COPS permet au routeur (PEP) de communiquer avec PDP à propos
de l'allocation des ressources demandées pour différents types de
trafic
 Contrôle d'admission: constate s'il existe suffisamment de ressources
pour satisfaire la demande
 Contrôle de la politique: vérifie si la demande doit être considérée
(considère la priorité).
268
 COPS – les messages
 OPN: Open Connection
OPN
 CAT: Connection Accept
CAT
 CC: Connection Close
KA PDP1
 KA: Keep Alive
KA
KA

PEP CC

OPN

CAT
PDP2

CC
269
COPS – les messages
 REQ: Request
REQ
 DEC: Decision
DEC
 RPT: Report
RPT

 SSQ: Synch. Request

 SSC: Synch. Complete DEC

PEP RPT PDP

SSQ

SSC

RPT

270
Rôle du PDP
 Reçoit les politiques de haut niveau
 Surveille les événements réseau
 Enregistre les capacités/limitations des PEP
 Produit et met à jour les données de configuration des PEP selon
les politiques du réseau et l'état du réseau
 Lier les stratégies avec l'état du réseau
 Produit les données de configuration APPROPRIÉES selon le type
de chaque PEP spécifique, son rôle, ses capacités et ses limites
 L'intelligence du modèle de contrôle par politiques est
principalement concentrée au niveau PDP
271
Rôle du PEP
Reçoit des données de configuration
Business/Control
 Policies
Other

du PDP
Services &
Directory
Events
Service

 Installe les instructions du PDP

Network State/Events

 rapporte au PDP l'application réussie Policy Console

de la décision.
 Le PEP peut contenir et gérer PDP PDP

différents types clients (routeurs, etc)

Manager Decision Making

 Il doit garder la synchronisation avec le

Decision Enforcement
PEP PEP PEP PEP

PDP Devices

272
Exemple de politiques
 Le trafic de la machine 10.1.1.x doit avoir une priorité
haute  Remarquer le trafic de cette machine avec DSCP=6
 La politique reste toujours valide même si:
 Changements de topologie (les nœuds sont ajoutés,
supprimés, ou remplacés)
 le sous-réseau " 10.1.1.x " est modifié/étendu
 Les services réseau changent (DiffServ est remplacé par
RSVP)

273
Base de données de politiques (Serveur LDAP)
 Serveur LDAP (Leightweight Directory Business/Control
Policies

Access Protocol)
Other
Services &
Directory
Events
Service

 Stocker les informations relatives Network State/Events

aux politiques Policy Console

 Utilisateurs et profils de trafic des

applications PDP PDP
Manager

Rôle des périphériques réseau

Decision Making

Decision Enforcement

 Sauvegarder les politiques et les PEP PEP PEP PEP

distribuer aux PDP Devices

 Représentation standard ou non

274 standard des politiques
Provisionnement de la QoS avec COPS
 COPS peut aussi jouer le rôle d’un gestionnaire de
bande passante (Bandwidth Broker)
 Un « Bandwidth Broker » propose d’autres services
 Service-Level Agreement (SLA)
 Service-Level Objective (SLO)
 Service-Level Specification (SLS)
 Traffic-Conditioning Agreement (TCA)

275
Mode de fonctionnement
 COPS peut aussi interroger d’autres entités telles qu’un
serveur d’authentification ou encore un bandwidth broker en
utilisant SNMP
 Ce modèle générique de contrôle de réseau par politique
permet de réaliser deux modes de contrôle distinctes :
 l’outsourcing
 et la configuration (aussi appelé provisionning).

276
Mode Outsourcing
 un routeur détecte un nouveau évènement et ne Current
Policies
peut pas la traiter avec la configuration actuelle, il state

envoie une requête au PDP 3 PROCESS

PDP
 Le PDP consulte la base de données de 4

REQ
politiques et renvoie la décision prise à partir des

DEC
2

règles de politique.
 Il est utilisé avec le modèle IntServ-RSVP, lorsque New
Event
5
le routeur reçoit un message RESV et doit 1
INSTALL
décider d’accepter ou de refuser la réservation PEP
Device
de ressource
277
Mode Provisioning (configuration)
 Lorsque des évènements extérieurs Policies
Current
state
impliquent une modification de la
configuration des routeurs, le PDP peut A CHANGE
PDP
communiquer à ces derniers des nouvelles
B
règles à appliquer au travers du protocole

DEC
COPS.
 Ce modèle peut donc pallier à la principale PEP C
INSTALL, UPDATE,
faiblesse de DiffServ dont la configuration des DELETE
CONFIGURATION
classes de service est statique DATA

Device

278
Extension de COPS
 COPS a fait l’objet de différentes extensions :
 COPS-RSVP [RFC 2749] l’utilisation de COPS dans un
contexte IntServ/RSVP
 COPS-PR [RFC 3084] qui s’oriente vers le provisionnement de
politique de QoS dans un environnement DiffServ.
 COPS-ODRA: COPS Usage for Outsourcing Diffserv
Resource Allocation
 COPS-DRA: COPS Usage for Diffserv Resource Allocation

279
COPS usage for RSVP (RFC 2749)
 Définie un type de client (PEP) COPS pour RSVP
 Fournit une surveillance et un contrôle centralisés de
RSVP
 Fonctions du PEP-RSVP
 Contrôle d'admission
 Classification des données
 Gestion de la bande passante (mise en file d'attente)
 Police de données
 Rapport d'utilisation RSVP
280
COPS usage for RSVP (RFC 2749)
 Exemple d’opérations COPS-RSVP
 Un routeur (PEP) reçoit les requêtes PATH/RESV
 Il essaye de traiter et de servir les requêtes localement
 Si le PEP ne peut pas servir les requêtes localement, il
communique avec le PDP
 Ensuite, il effectuer le contrôle d'admission conformément à
la décision PDP

281
Exemple (VoIP) COPS-RSVP
 Comme c’est RSVP est le protocole de signalisation, il a alors besoin de
certaines informations:
 User Authentication (AUTH_USER)
 Application Identification (AUTH_APP)
  Solves application flow classification issues 
 DCLASS (DSCP)
 TCLASS (802.1p)
 SENDER_TSPEC / FLOW_SPEC
 Token Bucket Rate, Token Bucket Size, Peak Data Rate
 SENDER_TEMPLATE / FILTER_SPEC
 Source IP Address and Port number
 SESSION
 Destination IP Address and Port number
282
Exemple (VoIP) COPS-RSVP
DiffServ
Domain
Egress
Ingress DS PEP
Interior
Access PEP Nodes
Network Access
Network
Host
1 Host
Policy 2
Server
(PDP)
283
Exemple (VoIP) COPS-RSVP
Media Gatekeeper,
Call Gateway Proxy, etc.
Signalling Controller

Gateway
IP Network
PSTN Control

Host

Media Media
Flows Gateway

284
RSVP Signaling Architectural
Overview
• Hosts initiate and respond to RSVP messages
– Reservation initiation, failure, termination or network policy change
• Edge Routers Police BW and Policy Reservations
– DS Edge Routers maintain RSVP soft-state
– DS Core Routers do not maintain RSVP soft-state
• Use DiffServ or TE’d paths to provide QoS assurances in the core
• Admission Control decided by Policy Server (PDP) or Router LDP
• RSVP messages flow end-to-end
• RSVP Reservations must be made separately in each directions
• RSVP-enabled hosts benefit
– Non-RSVP-aware hosts either:
• Achieve no QoS
• Use other access technology-specific QoS
• Use proprietary mechanisms

285
RSVP Reservation
- DS Edge Node DiffServ Domain

DS
Access Interior
Ingress Nodes 5. Process Egress
Network Path Msg.
1. Path PEP 3. P-HOP 4. Path PEP

Access
Host 1 Network
Host 2

Policy
2. COPS-RSVP Server
(PDP)  If no BW is available for reservation,
PEP initiates Path failure

1. Host 1 initiates Path Msg.

2. Path Message encapsulated in COPS-RSVP message. PDP instructs ingress PEP to forward Path
Msg. and keep soft-state for reservation 
3. Ingress PEP adds egress interface to P-HOP (Route pinning). Router Alert Option disabled.

4. DS Interior Nodes forward Path Message

286
5. Egress PEP processes Path Msg. and enables Router Alert Option
RSVP Reservation
- DS Edge Node (cont.) DiffServ Domain

DS
Interior
Ingress Nodes Egress
Access PEP PEP
Network Path

6. Resv
Host 1 Host 2
Access
Network

Policy 8. COPS-PR
Server
(PDP)
9. COPS-RSVP
7. COPS-RSVP

6. Host 2 generates Resv Msg.

7. If no BW available, PDP informs Egress PEP to generate ResvErr to Host 1. If reservation

accepted, Egress PEP forwards Resv to Host 1.

8. If reservation succeeds, PDP sends new filters down to PEP

9. Resv message sent by Ingress PEP to PDP to confirm reservation. PDP can return DCLASS object
to 287
be sent in Resv msg. sent to Host 1.
RSVP Reservation
- DS Edge Node (cont.)
DiffServ Domain

DS
Interior
Ingress Nodes Egress
Access PEP PEP
Network Path

11. Resv
Host 2
Host 1 Access
Network

10. COPS-PR
Policy
Server
(PDP)

10. PDP sends new filters down to PEP.

11. Ingress PEP accepts reservation by sending RESV message to Host 1. If PDP rejected
reservation, PEP sends ResvErr back to interface specified inside RSVP N-HOP object.
288
RSVP Reservation
- DS Boundary Node
• The following steps are introduced into the reservation if there are RSVP-capable Boundary
Nodes interconnecting DS Domains
DS Domain 1 DS Domain 2

DS DS
Ingress Interior Interior Egress
Edge Boundary
Node PEP Node Edge
PEP 4b. New PEP
Path P-HOP 4c. Path

Access
Host 1 Network Access Host 2
Network
4a. COPS-RSVP

 If no BW is available for
Policy reservation, PEP initiates
Server Path failure
(PDP)

4a. Path Msg. encapsulated in COPS-RSVP message. PDP instructs boundary PEP to forward Path Msg.
and keep soft-state for reservation 
4b. Boundary PEP adds its egress interface to RSVP P-HOP object
289
4c. DS Interior Nodes forward Path Message
RSVP Reservation
- DS Boundary Node (cont.)
DS Domain 1 DS Domain 2

DS DS
Ingress Interior Interior Egress
Edge Node Boundary Node Edge
PEP PEP
PEP
Path Path
8c. Resv
Resv
Host 1 Access Host 2
Network
Access
Network
8b. COPS-PR
8a. COPS-RSVP

Policy
Server
(PDP)

8a. If no BW available, PDP informs boundary PEP to generate ResvErr to Host 1. If reservation
accepted, Egress PEP forwards Resv to Host 1.
8b. If reservation succeeds, PDP sends new filters down to PEP

8c. Boundary PEP admits reservation by sending RESV message to Host 1. If PDP rejected reservation,
PEP sends ResvErr back to interface specified in RSVP N-HOP object.
290
 RSVP/DiffServ & COPS
Client (QoS)
PDP: “Allow PATH” or “Reject PATH”
Using COPS PR Push
Service Agreement for
RSVP Session (5tuple):
PATH Mark PHB = EF; Meter = TB2

RSVP-enabled Differentiated
campus network service PDP: “You may
network(s) Reserve Bandwidth
up to TB2”
COPS PDP
RSVP-enabled
campus network
RESV Client

291
291 Client: “Yes, Reserve Bandwidth”
 COPS Request-Decision Sequence
Interacting Across COPS Client-Types

 COPS-PR Request State

PDP Initiates Continuous
Request for Decision Report Transactional Decisions
Device A’s (Install on (Installed
A Filters Filters From Server
Policy
1,2,&3 ) 1,2,&3 )  COPS-RSVP Transacts New
Data
Configuration PEP Filtered Request State for Each New
Data RSVP State
PDP  COPS-PR Installs updated
filters/meters/actions
RSVP Decision: Report
RESV Forward RESV
corresponding to RSVP
Request message installed events
 PEP Reports Status
Data Outsourcing PEP Filtered  State Removed when No
Data
Longer Applicable 292
292
The COPS-PR Protocol (RFC 3084)
 C’est une extension de COPS, même mode que PR
 Le PEP sert toujours les événements selon les politiques
pré-téléchargées - le PDP conserve ces politiques à jour
 C’est un mode simplifié de COPS, mais ne convient pas
à toutes les zones de gestion (ex. RSVP)
 Initialement conçu pour DiffServ, mais semble adapté à
plusieurs zones de gestion
 Ce mode était de plus en plus utilisé !!

293
Policy Information Base (PIB)
 La PIB a été introduite pour COPS-
PR pour envoyer les données sur les
capabilités d’un routeur (PEP) vers
le PDP
 Elle transporte les politiques à
installer/mettre à jour du PDP vers
le PEP
 Ressemble à la structure du MIB
(Management Information Base)
 Structure en arbre de
provisionnement de classe, chacune
a des instances de provisionnement

294
Policy Information Base (PIB)
 Modules du PIB
 Policy Framework : contient des informations générales
 QoS IP : filtres IP spécifiques, classificateurs, actions
 QoS IEEE 802: filtre et classe spécifique 802.1P/Q (précédence IP)
 Règles du PIB
 Chaine de caractère, le PDP l’utiliser pour envoyer les ordres, etc.

295
Exemple PIB

PRID VALUE
2.1.3.2.1 (100,2)
2.1.3.1.2 (4,NO)
2.2.1.2.1 (100,2,10)
2.2.1.2.2 (100,1,11)
2.2.1.1.1 (128.1.1.1,6)
296 2.2.1.1.2 (128.1.1.2,6)
COPS-PR Example 1
Policy:
if traffic to IPs 128.1.1.1 or 128.1.1.2 has DSCP=4
then remark it with DSCP=6

Event: PDP->PEP DEC PIB (@ PEP)

PEP connects Install:

2.1.3.2.1  (100,2) 2.1.3.2.1  (100,2)
2.1.3.1.2  (6,NO) 2.1.3.1.2  (6,NO)
2.2.1.2.1  (100,2,10) 2.2.1.2.1  (100,2,10)
2.2.1.2.2  (100,1,11) 2.2.1.2.2  (100,1,11)
2.2.1.1.1  (128.1.1.1,4) 2.2.1.1.1  (128.1.1.1,4)
2.2.1.1.2  (128.1.1.2,4) 2.2.1.1.2  (128.1.1.2,4)

297
 COPS-PR Example 2
Policy: if traffic to engineers has DSCP=4 then remark it with
DSCP=6
Event: PDP->PEP DEC PIB (@ PEP)
PEP connects <NULL>
<EMPTY>
No Engineer is logged
Two Engineers log on at 128.1.1.1 and Install: 2.1.3.2.1  (100,2)
128.1.1.2 2.1.3.2.1  (100,2) 2.1.3.1.2  (6,NO)
if traffic to 128.1.1.1 2.1.3.1.2  (6,NO) 2.2.1.2.1  (100,2,10)
2.2.1.2.1  (100,2,10) 2.2.1.2.2  (100,1,11)
or 128.1.1.2 has DSCP=4 2.2.1.2.2  (100,1,11) 2.2.1.1.1  (128.1.1.1,4)
then remark with DSCP=6 2.2.1.1.1  (128.1.1.1,4) 2.2.1.1.2  (128.1.1.2,4)
Engineer at 128.1.1.2 logs out 2.2.1.1.2  (128.1.1.2,4)
Remove: 2.1.3.2.1  (100,2)
if traffic to 128.1.1.1 has 2.2.1.2.2 2.1.3.1.2  (6,NO)
DSCP=4 2.2.1.1.2 2.2.1.2.1  (100,2,10)
2.2.1.1.1  (128.1.1.1,4)
then remark with DSCP=6
An Engineer logs to 128.1.1.3 Install:
(similar to the first case) 2.2.1.2.2  (100,1,11)
298 Similar to the first case
2.2.1.1.2  (128.1.1.3,4)
Chapitre 5: Approche IUT-NGN (TEQUILA &
EuQoS)

299
 TEQUILA: Traffic Engineering for Quality of Service in the
Internet at Large Scale
 Objectifs:
 Spécifier, valider et implémenter des service et outils pour TE
 Planification, dimensionnement, et contrôle dynamique du trafic
 Management de la QoS de bout-en-bout sur DiffServ
 Définition du « Service Level Specification (SLS) »
 Négociation, Monitoring and Renforcement de SLSs
Ingénierie de trafic intra et inter-domaines pour répondre au SLS
Protocoles et mécanismes de négociation, de routage à QoS, de supervision et de
renforcement de SLS de bout-en-bout

300
 TEQUILA: Architecture
 L’architecture de TEQUILA suppose un réseau Internet multi domaines, formé
par plusieurs systèmes autonomes (AS).
 Chaque AS est formé de routeurs d'accès (Edge Routers) et de routeurs de
bordure (Core Routers)
 Les routeurs d'accès connectent les réseaux d'accès des clients aux ASs via
des protocoles de routage intra-domaine, comme OSPF, IS-IS et RIP2
 Les routeurs de bordure connectent les ASs entre eux, possiblement via un
protocole eBGP, selon une topologie Mesh
 Chaque AS est administré par un seul et unique administrateur

301
 Bandwidth broker (BB)
 C’est un gestionnaire de:
 bande passante qui traite les échanges avec le SLS
 Ressources qui assure la réservation, contrôle d’admission et l'ingénierie de trafic
 Configuration réseau, car il permet de renforcer la QoS

302
 Négociation du SLS pour application multimédia

303
 Négociation du SLS pour application multimedia

304
 TEQUILA: TE
 Négociation de QoS entre domaines différents à travers différents
Bandwidth broker qui coordonnent entre eux
 On trouve des mécanismes de négociation au niveau session comme SIP

305
 TEQUILA: TE

306
 ????? End-to-end Path
?
Access ? AS
Access network
network ?????? ??????????
DOMAIN
? AS
?
??????????
DOMAI
DOMAIN?
N Access
AS
? network
AS ?
AS
?
Access network AS
?
DOMAIN DOMAIN ?? Access network
???????
307
 Solutions classiques
 Utiliser un chemin de signalisation pour forcer chemin de données (sur le chemin)
 Chemin de contrôle ou de signalisation utilise un protocole IntServ RSVP
 Utiliser un protocole de session comme SIP (TEQUILA)
 Et les données envoyées sur cette voie de QoS
 Mais, cette approche est difficile à maintenir et déployer
 L’approche EuQoS
 Sélectionner le chemin de données avec BGP modifié pour EUQoS
 Introduire un gestionnaire de bande passante plus étendu (Resource Manager)
 Tirer la signalisation de chemin de données (off-path)
 Envoyer des données sur le (QoS) chemin de données

308
 Architecture globale d’EUQoS
USER 1 Application Level USER 2

Application QoS-based end-to-end signaling

Appli Appli

Virtual Network Level

Technology Independent Sub-layer
EBB/RMs

RM1 RMi RMj RMk RM2

Com RA1 Ressource Allocators RA2 Com

RAi RAj RAk Prot

Prot
QoS QoS QoS Access
Access Network Network
Network Network
Network i k
j 2
1

309 Network technology Dependent sub-layer

 EuQoS Framework
 Les composants de l’architecture EUQoS:
 Signaling & Service Negotiation
 Signalisation sur le plan de service (SIP)
 Signalisation dépendant de la technologie (COPS)
 Signalisation indépendante de la technologie (NSIS)
 Traffic Engineering and Resource Optimisation (TERO),
 Basé sur MPLS et ces variants: creation d’un tunnel virtuel de bout-
en-bout avec support de la QoS
 Le gestionnaire de bande passante (Bandwidth Broker) réalise ces
fonction via un Resource Allocator (RA) et un Resource Manager
(RM)
310
 EuQoS Framework
 Admission Control, Failure Management:
 Inter-domain CAC, Intra-domain CAC
 La fonction CAC peut être basée sur la demande de QoS de l’application, par exemple le débit
crête lors de la demande de l’allocation de ressource
 La gestion/tolérance aux fautes par réplication
 Monitoring and Measurement,
 fournir des outils adéquats pour le suivi de la livraison QoS dans le réseau opérationnel
 Operation, Administration and Maintenance (OAM)
 Security and AAA, Charging
 Authentifier et autoriser les abonnés EuQoS.
 SSN notifie une information de session convenu
 CHAR demande les enregistrements comptables pour les abonnés liées

311
 Sélection du chemin de données: qBGP avec classe de
service QoS

BR3-x
BR3-out
BR3-in
BR4-in
AS 3
BR3-y

AS 4
BR4-out
BR5-in

AS 5 Receiver
Sender
BRout
BR6-in
Access AS 6
Network
312
Commencer à partir du chemin de données

BR4-in

AS 4
BR4-out

313
 Ajouter un Bandwidth Broker & Resource Manager par
domaine

BR4-in

EBB4

AS 4
BR4-out

314
 Utiliser ce BB pendant la phase de signalisation

BR4-in

EBB4

BR4-out

315
 Utiliser un chemin de signalisation lors de la phase de
signalisation

BR4-in

EBB4

AS 4
BR4-out

 Et Utiliser le chemin de données pendant la phase de données

316
 Et finalement, intégrer pour tous les domaines
EBB3
BR3-out

BR4-in
EBB4
AS 3

AS 4
BR4-out
EBB5 BR5-in
Receiver
AS 5
Sender

BR5-out BR6-in

317
Data Signaling EBB6 AS 6
Indépendance de la technologie réseau sous-jacente

318
 AQ-SSN Contrôle d’admission
EQ-SAP
NSIS
ResCom ResCom
EBB/RM1 EBB/RM2 EBB/RM3

ResCom-Ack ResCom-Ack

Res-Ack Res-Ack
ResCom ResCom ResCom Res-Ack
Com-Ack
Com-Ack Com-Ack

RA1 RA2 RA3

ResCom: Reserve and Commit Message Request

ResCom-Ack : Reserve and Commit Message Ack
Res-Ack : Reserve Message Ack ; Com-Ack : Commit Message Ack
319
 Établissement du chemin de bout-en-bout, multi-
domaines, multi ASs

LOOSE
PATH

BGP-based LOOSE Path :

resources are checked in each domain
by its EBB/RM

Access Core Core Access

320 AS1 AS2 AS3 AS4

 MPLS et Path Computation Element (PCE)
 PCE est une entité capable de calculer les chemins pour un seul ou un ensemble de
services.

3: Path Response 2: Path Computation

PCC PCE
1: Path Request TED

 PCE [RFC 4655--2006] est capable de trouver une voie appropriée pour le transport
de données entre une source et une destination

321
 MPLS et Path Computation Element (PCE)
 L’architecture PCE définie deux entités:
 PCC (Path Computation Client) demande l’établissement du chemin MPLS
 PCE (Path Computation Element) un nœud du réseau, un serveur dédié ou une plateforme de calcul haute
performance qui permet de calculer le chemin de bout-en-bout
 Les PCEs des domaines collaborent pour calculer un dur chemin inter-domaine

322
 Création du chemin de bout-en-bout
BGP

BGP
and
PCE

PCE

Access Core Core Access

323 AS1 AS2 AS3 AS4

 Protocole de signalisation

324
 Protocole de signalisation

325
 Protocole de signalisation

326
 Protocole de signalisation

327
 Implémentation de la QoS

328
 Exemple de déploiement de CoS

329
 Scénario multi-domaines

330
 Scénario multi-domaines

331
 Classes de service (CoS)

332
 Résumé des composants EUQoS

333
 Conclusion
 EUQoS présente une architecture évoluée de fourniture de la QoS
 Adresse des besoins variées en multi-domaines, multi-technologies, hétérogènes
 La signalisation est déduite à partir du protocole de routage (qBGP), qui permet de tirer le chemin de
signalisation entre Bandwidth Brokers
 Comme TEQUILA, EUQoS aussi utilise des équipements réseaux propriétaires pour implémenter la
QoS
 Le plan de contrôle est toujours dans le routeur, il n’est pas possible de contrôler le chemin de
signalisation en dehors du plan de données
 De nouveaux services et applications apparaissent toujours, et l’architecture client-serveur ou 3-tiers
ne sont pas suffisantes
 Problème d’adressage au niveau IPv4 et de déploiement de IPv6
 besoin d’une infrastructure réseau différente, flexible et capable de supporter le nouveau trafic
  cloud computing, virtualisation du réseau, SDN et Internet des Objets

334
 Chapitre 6: Les réseaux hybrides satellites et
terrestres

335