Gestion des Ressources

Architectures de QoS

Pascal Anelli
Université de la Réunion

Pascal.Anelli@lip6.fr
http://www.lip6.fr/rp/~pan

Gestion des ressources

o Investir dans des outils de gestion des ressources
• Afin que le réseau répond efficacement à une large gamme de demande de service
• Fournir la QoS

o Fournir un contrôle de la QoS au niveau IP

• Aller au delà du best effort
• Activités menées par des WG de l'IETF

o 2 points de vues
• Int-Serv: Changement fondamemental de l'Internet
- Réservation par flot
- Protocole de signalisation RSVP
- Complexe à gérer sur le plan utilisateur
• Diff-Serv: Ajout de classes de services
- Classification en périphérie
- Traitement sur une agrégation de flots dans le réseau
- Approche Diff-Serv
- Complexe à gérer au niveau du dimensionnement et de la gestion des ressources

o Quels outils pour le contrôle de la QoS ? 2

Le Monday, 20 March 2006 -1-

 Composants de la QoS
Modèle simple
1Mits/s
s1 d1

r1 r2
1,5 Mbits/s

s3 d2
Sporadique

• Congestion de R1 par rafales de s2

• Donner une priorité aux paquets du média continu

o Il faut
• Distinguer les paquets
• Traiter les paquets en fonction de leur contrainte de service

o Composant 1: Classification
• Le routeur doit pouvoir distinguer les différentes classes de services
• Faite en fonction d'une marque dans le paquet
3

Composants de la QoS
Eviter les interactions entre les flux
Si le flux discret occupe toute la bande passante par intermitence
Flux = séquence de paquets partageant de même caractéristiques de service

o Composant 2 : Réservation
• Isoler une classe par raport à une autre
• Réservation de bande passante
- Risque de sous utilisation
• Contrainte:
- Utilisation des ressources le plus efficacement possible

Si le flux à contrainte temporelle émet plus que prévu ?

o Composant 3: Contrôle de trafic (ou dit d'accès)

• Surveillance et remise en forme
- A l'entrée du réseau

Le Monday, 20 March 2006 -2-

 Composants de la QoS
1Mits/s
s1 d1

r1 r2
1,5 Mbits/s

1Mits/s
s3 d2

• Plus assez de bande passante, la qualité est dégradée pour les deux flux
• Il vaut mieux bloquer un flux

o Composant 4: Contrôle d'admission

• Signalisation des besoins

o Pour une optimisation des ressources : Routage contraint

• Choix de la route adaptée aux services requis
• Répartition du trafic dans le réseau

Classes de trafic
o Motivation
• Pour que le réseau puisse faire correspondre le service à la demande des applications

o Représentation
• De la demande d'un ensemble d'applications
• Du service fournit par le réseau

o Quels types d'applications?

• Applications interactives
• Applications élastiques

o Garanties de QoS
• Délai de transit pour un débit donné
- Délai = Partie fixe + partie variable
- Rendre la partie variable négligeable (suppression de la gigue et de la perte)
• Débit moyen utile (goodput)
- Taux de perte n'est pas réellement perçu

o 3 Classes
• Best effort
• Garanties statistiques
• Garanties fermes
6

Le Monday, 20 March 2006 -3-

 Classes de Services IntServ
o Principe
• Détermination en fonction des délais

o Best Effort
• pas de garantie

o Controlled Load
• garantie que les applications obtiendront une QoS similaire à la QoS d'un réseau non congestionné
- "Better than best effort"
• pas de limitation de délai ou de perte
• Idée d'un délai moyen
• Equivalent à un service à priorité avec un contrôle d'admission
• performance qualitative: demande relative de QoS et non quantifiable
• Pour des applications tolérantes

o Guaranted
• Garantie un délai maximal de transfert et un débit
- Pas de garantie sur la gigue
- Pas de perte de paquet par file d'attente
• Calcul du délai d'attente maximum
- A partir de la caractérisation du flot (débits, taille max des rafales)
- Réservation de bande passante et de tampons mémoire
• Performance quantitative: demande de QoS quantifiable
7

Architecture Intserv/RSVP
o Qui ?
• 2 groupes de travail de l'IETF
- Travaux souvent confondus
o IntServ (Integration Services)
• Modèle pour la fourniture d'un ensemble de services
- A la session applicative
- S'appuie sur une réservation de ressources et d'etats dans les routeurs
• Des composants nécessaires à la fourniture de ces services
• Travaux débutés en 1994 inspirés par l'approche circuit virtuel
o RSVP (Resource Reservation Protocol)
• Protocole de signalisation (RFC 2205)
• Informer les besoins applicatifs aux réseaux
• Conçu pour demander des réservations IP
• Vu comme LE protocole de
signalisation de Intserv

Le Monday, 20 March 2006 -4-

 Composants de Intserv
o Notion de flot
• Adresse de source, adresse destination, numéro de port

o Description du flot
• Description du flux d'émission
• QoS demandée:
- Selon une classe de service
• Règles pour l'identification du flot concerné

o Contrôle d'admission
• Vérification que la QoS demandée par un flux peut être fournie et que ce nouveau flux ne perturbera pas la
QoS des autres flux

o Classification (Packet classifier)

• Oriente les datagrammes selon la QoS demandée

o Ordonnancement des émissions (Packet scheduler)

• Ordonnancement des datagrammes afin de respecter la QoS demandée

o Protocole de signalisation pour la réservation de ressources (RSVP)

• Allocation de ressources nécessaires pour fournir le service
9

Mécanismes du routeur
o Contrôle d'admission
• Décide si un nouveau flot peut être supporté
- Une session doit déclarer prélablement sa demande et décrire son trafic à émettre:
classe de service et niveau
description du flot
• Chaque routeur effectue le contrôle:
- En fonction de la demande
- En fonction des ressources
• Attention: différent du contrôle d'accès (policing)

o Traitement appliqué au paquet

• Classification
- Associer chaque paquet avec la réservation appropriée
• Disicipline de service:
- Traite de l'ordonnancement
- Attribuer à chaque paquet afin de recevoir le service demandé.
- Equivalent à un contrôle d'accès

10

Le Monday, 20 March 2006 -5-

 Architecture d'un Routeur RSVP

Plan de contrôle Contrôle

Information d’admission
de routage Routage
Signalisation
Daemon
RSVP

Plan utilisateur
•••
datagrammes Ordonnancement
Classificateur
utilisateurs

•••

o Architecture d'un hôte RSVP ?

11

Ordonnanceur
o FIFO

F
I
F
O

• Modifications des caractéristiques temporelles

- gigue
- espacement temporel : débit crête

ª Il faut isoler les flux

o Un autre ordonnancement
• Conserver le partage
• File d'attente par flot
• Politique de service avec une garantie de débit:
- WFQ (Weighted Fair Queuing)
© Eric Horlait 12

Le Monday, 20 March 2006 -6-

 Description de flot
o FlowSpec: Décrire les caractéristiques du flot
• Le trafic émis
• Le service désiré
- Délai
- Débit

o FilterSpec: identifier la (les) source(s)

• IPv4: Adresse source et numéro de port
• IPv6: Adresse source et flow ID

o Session: identifier la (les) destination(s)

• Adresse de destination, protocole ID et numéro de port

13

FlowSpec: Spécification de flot

o Tspec: les caractéristiques du flot
• TSPEC= (r, b, p, m, M)
- r: débit moyen
- b: sporadicité
- p: débit crête
- M: taille de paquet Maximum (MTU)
- m: taille de paquet minimum
Paquet de taille inférieure à m est considéré de taille m: pénalisation des petits paquets
• Défini l'enveloppe du trafic émis
bits r
p

temps

• Mise en œuvre sous la forme d'un token bucket:

o Rspec: le service demandé
• controlled-load: aucune valeur
• guaranteed: le délai maximum
14

Le Monday, 20 March 2006 -7-

 Token bucket
o Fonctionnement
• 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

r Taux de régénération des jetons

TSPEC(r,b,p,M)
b

p
Trafic entrant
M

• Autorise des rafales et borne leur taille

• Détermination de la valeur des paramètres non trivial

15

Protocole RSVP
o Objectif
• Fournir une Signalisation pour la réservation de ressources sur un réseau IP

o Caractéristiques
• Utilise IP
• Réservation simplex: notion de session définie par rapport à la "destination"
• Réservation pour des communications unicast ou multicast
• Orienté récepteur
• Récepteurs hétérogènes
• Styles de réservation différents pour les différentes applications
• Supporte le changement de route ou de membre du groupe
• Protocole de bout en bout
• Indépendant du service
Routeur

o Ne traite pas
• routage Plan de contrôle Routage RSVP
• contrôle d'admission
• contrôle d'autorisation
- autorisation de réserver, de joindre le groupe multicast, etc… Plan utilisateur Tri et Ordon-
• Discipline de service routage -nancement
- Réservation: algorithme local

16

Le Monday, 20 March 2006 -8-

 RSVP: Principe
o La signalisation est constituée d'un flux de messages path et resv
• Pas de réservation pour ce flux
• Remise sans garantie et non acquitée
RESV
PATH Destination

Source

RESV

• Chaque routeur RSVP traversé par un flux RSVP mémorise un état de ce flux

o Soft state
• Notion de contexte applicatif
• Rafraichi par les messages resv
• Après un certain délai L de non réception, l'état est détruit

o Libération immédiate de la réservation

• Messages teardown (démolition)

17

RSVP: Messages
o Message path
• émis "périodiquement" par la source et intercepté par les routeurs
• suit le même chemin que les données
• transporte
- le Tspec de la source au moment de son émission
caractérisation du trafic en rapport avec le Tocken Bucket
- les ADspec des routeurs traversés
caractérisation des retards dus aux routeurs
mis à jour par tous les routeurs RSVP

o Le récepteur choisit calcule la bande passante à réserver en fonction du

Tspec et Adspec reçu

o Message resv
• émis par le(s) destinataire(s)
• demande la réservation en bande passante et en tampon mémoire
• prend le chemin inverse des messages path
• en multicast, les messages resv sont fusionnés
• Transporte le descripteur de flot (Flow Spec):
- FilterSpec: pour la classification
- Tspec du récepteur
- Rspec: pour l'ordonnancement

ª Les routeurs connaissent les flots, les traitements ne sont plus banalisés 18

Le Monday, 20 March 2006 -9-

 Mise en place de la réservation
o Réservation est orientée récepteur
• Pour les communications multicast
- Récepteurs héterogènes
- Groupe dynamique
- Taille de groupe pouvant être importante

o Récepteur
• Des informations des caratéristiques du chemin (C, D) (message PATH)
• Choisi les paramètres de la réservation
• Emet une réservation (message RESV)

o Routeur
• Installe un état à réception d'un message PATH
• A réception d'un message RESV
- Contrôle d'admission
- Effectue une réservation
- Modifie eventuellement les paramètres (R,S)
- Complète l'état avec les informations de la réservation
• propage vers l'amont ou fusionne le message RESV
- Dépend du style de réservation
19

Réservation
o Acheminée par le message RESV

o Identifiée par la paire:

• Session (la destination)
- Unicast ou multicast
• FilterSpec (la source)
- Paramètres pour la classification (tri)

o Exprimée par le FlowSpec

• Identification
• Spécification du trafic émis
• Allocation minimum
• Régle de fusion
- Styles de réservation

20

Le Monday, 20 March 2006 - 10 -

 Réservation GS
o Guaranteed
• Termes Tspec (r, b, p, M)

• Terme Rspec (R, S)

R: Bande passante réservée
S (Slack): Marge temporelle; pour compenser un manque de BP par une augmentation du délai

• Garantie de délai D:

( p − R) (b − M) M n ⎡ Ci ⎤
D≤ + +∑ + Di + S
R (p − r) R i =1 ⎣ R ⎦

- C (en octets): Quantité de données cumulées due au store & forward

- D (en s): Temps d'attente de la libération du support

• Plus R est important, plus le délai est faible

• Sans le terme S: R est le min de la réservation des n routeurs

21

Réservation: CL
o Controlled load

• Terme Tspec seulement du trafic demandé par le récepteur

• R= r est suffisant pour un débit moyen

• Calcul de la taille du tampon mémoire à chaque routeur

22

Le Monday, 20 March 2006 - 11 -

 Styles de réservation
• Déterminent les règles de fusion des messages RESV
• Dédié
- Une réservation par émetteur (Fixed Filter)
- Somme des réservations pour une session
Par émetteur donc
• Partagé
- Une réservation pour un ensemble d'émetteurs
Tous les émetteurs (Wilcard Filter)
Identification explicite (Shared Explicit)
- Réservation à la demande la plus forte pour une session

S1 S1
R1

R1

R2
SE/WF SE/WF
S2 Unicast S2 multicast

23

Exemple

o 4 interfaces (a, b, c, d)

o 3 Sources (S1, S2, S3)

o 3 Récepteurs (R1, R2, R3)

24

Le Monday, 20 March 2006 - 12 -

 Réservation WF

o Réservations sur chaque interface valables pour tous les flots

25

Réservation FF

o Une réservation par source, mais partagée entre les récepteurs

26

Le Monday, 20 March 2006 - 13 -

 Réservation SE
SE(S1) (4B) SE(S3) (B)
(a) (c)
S1 (S3) (B) R1
SE(S2,S3) (4B) (b) (d) R2
S2 et S3 (S1,S2) (4B) SE(S2) (4B)
R3
SE(S1,S2) (2B)

o Une réservation pour toutes les sources à la valeur maximale demandée

par chaque récepteur

27

Mise en oeuvre RSVP

Message RSVP (signalisation)

Démon
Appli. Contrôles
RSVP
des
autorisations

Message de contrôle
d'admission
Contrôles
classifieur

ordonnanceur

28

Le Monday, 20 March 2006 - 14 -

 Mode opératoire
Source

Destination

path

resv

resv

Destination 29

Bilan
o Avantages
• Services proches des différentes types d'application
- Ex: GS pour applications critiques intolérantes
• Conçu pour fournir des garanties absolues
• Le flot peut être contrôlé par le routeur
• QoS pour unicast ou multicast
• Styles de réservation tendent à augmenter le taux d'utilisation des ressources réservées
• Adaptation "automatique" au changement de routes

o Inconvénients
• Service de bout en bout garanti si tous les routeurs sont Intserv
• Problème de facteur d'échelle
- Un état par flot (state overhead)
- Réservation par agrégation: sujet de recherche
- Traitement des messages RSVP (message overhead)
• Impraticable pour les flots à durée de vie courte
- Latence dans la réservation (accrue en cas de perte)
• Facturation du service complexe
• RSVP complexe
- Support du multicast: QoS et Multicast deux problèmes très complexes
• Qos et Multicast: effets de bord
- Réservation faite par le récepteur, codage fait par l‘émetteur -> gaspillage de ressources
Cas de plusieurs sources hétérogènes
- "Free ride"
30

Le Monday, 20 March 2006 - 15 -

 Architecture DiffServ
o DiffServ (Differentiated Services)
• groupe de travail à l'IETF (fev 1998)
• Seconde tentative du support de QoS

o Actuellement
• Un seul service: best-effort
• Proposition Int-serv/RSVP: services micro flux
- Solution complexe

o Pour traiter les difficultés de IntServ/RSVP

• Facteur d'échelle:
- Dans les réseaux haut-débit
• Modèle de service fléxible
- Offrir par exemple des classe de service relative
• Une signalisation plus simple
- Les applications veulent spécifier un service qualitatif

ª Une autre réponse simple et insensible au facteur d'échelle

31

Modèle DiffServ
o Conforme à la philosophie Internet
• Simple au cœur
• Complexe à la périphérie
• Gestion distribuée (par domaine)

o Approche
• Simples fonctions dans le cœur du réseau et les fonctions complexes au niveau du routeur de borde bordure
(ou l'hôte):
- Modèle du edge-to-edge
• Aucune définition de classes de services
- Fournir les composants fonctionnels pour la construction de classes de service

o Idée:
• Agréger les flots à la périphérie en fonction de leur QoS (BA: Behavior Aggregate)
• Marquer les paquets IP
• Traiter les agrégats au cœur du réseau

o Contraintes de conception
• Pas signalisation échangée (hors-bande)
• Pas de réservation
• Pas de contrôle de congestion concerté
• Services simples à comprendre (marketing) et à mettre en œuvre (performance et déploiement)
• Signalisation "dans la bande"
32

Le Monday, 20 March 2006 - 16 -

 Définition Diff-Serv
o Services différenciés
• Contrôler le partage de la bande passante
• Définition des classes de services par l'opérateur
• Services au niveau des macro flux
- Agrégations de flots
• Traitement d'un paquet en fonction de sa classe
o Diffserv ≠ Intserv

• Pas de spécifications de la QoS voulue

• Choix d'une classe de service proposée

Aucune réservation Diff-serv Réservation stricte

33

Architecture Diff-Serv
Conditionnement Domaine
d’administration Intranet
PHB
PHB PHB PHB Routeur
d’accès
Routeur de Routeur de
PHB Routeur de coeur bordure
bordure

SLA
Service level Agreement

• domaine = un ou plusieurs routeurs (routeur de coeur) ayant une politique commune de DS et

délimité par routeurs de bordure (edge device )

• SLA= contrat décrit :

- le trafic à QoS
- La classe de service à utiliser
- La quantité de trafic admise
- Les actions sur le trafic à QoS
- Autres considérations: heures d'utilisation, tarif, ...

34

Le Monday, 20 March 2006 - 17 -

 Principes
o Modèle hierarchique de gestion des ressources
• Intra-domaine
- Responsabilité de l'ISP: configuration des classes et dimensionnement
• Inter-domaine
- contrat de service (client- fournisseur)
entre deux domaines DS
entre un usager et le domaine DS
- contrat:
caractérisation du trafic par le client
garantie de QoS pour le fournisseur

o Service du réseau
• Politique de conditionnement
- Actions pour rendre conforme le trafic entrant conforme au profil indiqué par le contrat
• Comportement du routeur, le PHB ("Per Hop Behavior")
- Traitement appliqué au paquet
- Service d'un élément réseau
o DiffServ ne décrit pas

• les mécanismes des comportements

• Le nombre de classes
• Les caractéristiques des classes
35

Fonctions de bordure
o Bordure
• Hôte dit " DS-Capable"
• Premier routeur du domaine DS

o Classification
• Nœud de bordure marque les paquets selon des régles spécifiées dans le SLA

o Conditionnement
• Actions sur le trafic entrant
• Contrôle d'accès:
- Limiter la quantité de trafic émis dans la classe
- Action préventive de congestion

36

Le Monday, 20 March 2006 - 18 -

 Fonction de coeur
o Relayage

• Comportement appliqué au paquet selon une marque qui identifie la classe de service

o Dimensionnement

• Pour de la QoS, la classe doit être suffisamment provisionnée

37

Classification
o A la périphérie
• Identification des paquets demandeur de QoS selon les règles du contrat (SLA)
• Classification multi-champ
- Pour marquage du paquet dans l'en-tête IP

o Au cœur
• Classification sur la marque
• La marque = index d'un comportement

o Identification de la classe d'un paquet

• Champ "DS Byte"
- A la place du champ ToS de IPv4 et Class de IPv6
• Valeur "DS codepoint«
- Identifie un comportement dans le routeur 6 bits 2 bits

DSCP CU

38

Le Monday, 20 March 2006 - 19 -

 Comportement de relayage: PHB
o Index
• Indication d'un comportement
• Compatibilité avec les différentes priorités définies dans le champ TOS d'IPv4
- Class Selector (CS): codepoint xxx 000 où x binaire

o Comportement
• Traitement prioritaire
• Exemple:
- Le paquet de classe A est emis avant le paquet de classe B
- Le paquet de classe A obtient au moins x% de la bande passante

o Priorité
• Sémantique ou spatiale
- probabilité de perte (Drop priority)
- "Queue management"
• Temporelle
- délai d'acheminement (Delay priority)
- "Scheduling"

o Gros avantage : aucun état maintenu par les routeurs 39

PHBs
o Expetited Forwarding (EF)
• Obtenir un accès préférentiel au lien
• Pour les flux intéractifs
• Support à un service de ligne louée
• Pas de trafic hors profil

o Assured Forwarding (AF)

• 4 classes avec 3 niveaux de priorité de perte
- 4 priorités temporelles
Non modifiables par le réseau
- 3 priorités spatiales
modifiables par le réseau
• Assurance ≠ garantie
• Admission de trafic opportuniste
- Trafic hors profil
• Support d'un service "better than best effort«
• Exemple:
- Assurance d'un minimum de bande passante
- Assurance de non perte de certaines données

40

Le Monday, 20 March 2006 - 20 -

 Conditionnement
o Action décrite dans le contrat

o Actions
• Marqueur (marker)
- modifie le codepoint et donc le PHB
- pour donner un niveau de priorité différent
• Testeur (meter)
- test le niveau de conformité au profil
• Effaceur (dropper)
- détruit le datagramme, Modification des caractéristiques sémantiques du flot
• Remise en forme (shaper)
- Modification des caractéristiques temporelles du flot

41

Routeur DS
o Architecture
• la différentiation de service intervient dans les interfaces
• la complexité des interfaces est au libre choix des constructeurs
- pas de normalisation stricte

routeur

Interface d'entrée 0 Interface de sortie 0

Interface d'entrée 1 Interface de sortie 1

routage
...
...

Interface d'entrée n Interface de sortie n

42

Le Monday, 20 March 2006 - 21 -

 Applicabilité
o Fournir un service qualitatif relatif
o Améliore le support de certaines applications
o Utilisation première
• Etablissement de VPN

o N'est pas la réponse absolue à QoS IP

o Problème ouvert:
• Union de DiffServ avec RSVP
- problème de conversion des classes
- Opposition des modèles

DiffServ RSVP
RSVP

• Gestion dynamique des classes

43

@IRS : Une mise en œuvre Diff-Serv

o Projet RNRT:
• AIRS: Architecture Intégrée de Réseaux et de Services

o Développer et expérimenter des nouveaux services sur IPv6:

• Qualité de service
• Mobilité
o Expérimentation sur une plate-forme nationale:
• DIS: simulation interactive distribuée
• C/C: Contrôle commande
o Identifier les problèmes techniques de cet environnement

44

Le Monday, 20 March 2006 - 22 -

 Architecture

Hôte
3 services: GS, AS, BE
@IRS Bone
Ac
t iva Routeur de
tio bordure amont
n Routeur de coeur
AS pro
fil
G
S,
Routeur de
bordure aval
Traitement par flux
- Classification
- Classification par classe
- Contrôle d’admission (GS, AS)
- Détection et notification de la congestion (AS)
- Compteur de débit binaire
- Commutation d’étiquettes (EF)
- Conditionneur (Dropper, Marquage)

A Se
ct t
G
iv A
at S
io
n
+
- une discipline de service pour les 3 services
- une discipline d’attente pour AS

45

Interface d'entrée
TCA
profil action
Filtre en-profil
metreur
espaceur
EF marquage
hors-profil
Classificateur

Paquets BE
metreur
MF

TCA
AF en-profil
metreur

hors-profil marquage

edge <iface_name> -f <conf_file> -S

#etc/edge.conf
# src_addr dst_addr fid_min fib_max class A tb_r tb_b qlimit pr
vulcain * 100 120 5 S 2e6 4608 9216 2e6
Alcyon * * * 1 M 1e6 9216 0 2e6

46

Le Monday, 20 March 2006 - 23 -

 Interface de sortie

Classificateur FIFO
EF
BA

PO
AF
Routage
WFQ PQ

BE
µ fixé
FIFO

47

Plate-forme Nationale
LIP6
DEX
AERO Rb1 Rb3
Rb2 VP27
VP11
Rc4 LSIIT

LAAS VP23 Rb1

VP12
Rb1 Rc1 Rc3
VP14 VP13

Rb2 Légende:
IMAG
Rc2 VP29
Lien de coeur Routeur de coeur
INRIA Rc

Lien de bordure d’un

Rb Routeur de bordure
routeur distant du site

Lien de bordure d’un

Rb1 routeur local au site
Site utilisateur
48

Le Monday, 20 March 2006 - 24 -

 Plate-forme au LIP6
o Nominale o Réelle

NT
IPv6
Ethernet •••
Rc Hercule Cyclope
Typhon

Rb X ATM eth0
Janus
ATM
eth1

asx
NT

Ethernet Vulcain

NT

49

Résultat

50

Le Monday, 20 March 2006 - 25 -

 En savoir plus
o Site Web
• http://www-rp.lip6.fr/airs
- Descriptions
- Publications
- Résultats
- Et plus …

51

Bilan
o Avantages
• Traitement complexe en périphérie,
- Concentration de trafics faibles
- Croissance du domaine, augmentation de la périphérique -> "scale"
• Discrimination pour un réseau commercial
- "Meilleur service pour ceux qui paient plus" -> $$$ pour l'ISP
• Pas de délai d'établissement ou de signalisation
- Reste en mode non connecté
- Efficace pour les flots à durée de vie courte
• Provisionnement du domaine
- Méthode à la discrétion de l'administrateur
• Classification
- Simple
• Marquage
- Peut être effectué par le routeur de bordure
• Découpage d'un domaine en plusieurs réseaux virtuels
- Performance de chaque réseau par sa charge admissible

52

Le Monday, 20 March 2006 - 26 -

 Bilan
o Inconvénients
• Service de bout en bout= concaténation d'agréments et de politiques locales
- Service final ???
• Complexité dans
- Provisionnement du réseau
- Configuration
• Echelle de temps différente
- Charge de trafic & le provisionnement
• Difficile de garantir l'absence de congestion locale malgré une charge connue
- Répartition du trafic mauvaise
- Changement de routes
- Solution statique:
Contrat de service entre paires de routeurs de bordure
"Route pinning" mais perte de robustesse
- Solution dynamique:
Contrôle d'admission sur la route, modèle du "bandwidth broker"
Très complexe
• Difficile de garantir la priorité pour des flots de classes différentes
- Signalisation des besoins quantitatifs de bout en bout
• Orienté émetteur
- Signalisation du profil du récepteur
• Multi-destination
53

Le Monday, 20 March 2006 - 27 -