Spécification et implémentation d’une architecture de ...

50
jeudi 18 novembre 2004 1 Spécification et implémentation d’une architecture de signalisation à gestion automatique de la QdS dans un environnement IP multi domaines Thèse de Guillaume AURIOL Directeur des Recherches : Christophe CHASSOT Groupe OLC

Transcript of Spécification et implémentation d’une architecture de ...

Semaire 08/11/2004Spécification et implémentation d’une architecture de signalisation à gestion automatique de la QdS dans un environnement IP multi domaines
Thèse de Guillaume AURIOL Directeur des Recherches : Christophe CHASSOT
Groupe OLC
Contexte et problématique
Problématique et contribution
M ULTI SERVICES
3 aspects dans la problématique Nouvelles applications • Multimédias : audio, vidéo,… • Besoins spécifiques / média d’ordre et de fiabilité partiels • Garantie sur le débit et le délai
• Protocoles de Transport, pour plus de fonctionnalités et de services
Multi flux, multi homing,… : SCTP Multi contrôles de congestion, … : DCCP Multi flux, ordre et fiabilité partiels, … : FPTP
• Services IP, pour d’autres garanties que le BE IntServ DiffServ
1 domaine = 1 gestion indépendante de la QdS, du routage,…
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 4
Problématique et contribution (suite)
Contribution : Plan de signalisation inter domaines d’une architecture multi services à QdS garantie
Hypothèses Environnement IP DiffServ sur chaque AS (3 services)
Plan de signalisation intra domaine résolu Nombre limité de flux à QdS dans l’Internet
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 5
Motivation Dans les propositions d’architecture pour env. IP multi domaines à QdS [Tequila], [Cadenus], [Aquila]
Application
RTP
Lien effectué par appli / proxy : - Inexistant avec le niveau Transport - Basique avec le niveau IP
- Qualité TB => service IP « GOLD » - Qualité B => service IP « SILVER » - Qualité ∅ => service IP « BE »
pas de lien « suffisant » entre : Niveau applicatif Système de communication (Transport / IP)
⇒ Utilisation sous optimale des ressources des AS
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 6
Cadre de notre proposition Architecture à QdS garantie « intégrant » niveaux Application,Transport et IP
Application
UDP,FPTP,TCP
RTP
Apte à établir le lien (de façon transparente pour l’application)
Besoins applicatifs Perf. d’un canal de bout en bout résultant de la mise en œuvre :
D’un protocole de Transport
D’un type de service IP
En optimisant les ressources IP
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 7
Position / architectures de signalisation Optimisation de l’utilisation des ressources par le choix automatique des services IP et Transport
Protocole permettant de centraliser Besoins applicatifs Caractéristiques des services IP des AS traversés
Heuristique de sélection des services
Intégration du plan de signalisation avec le protocole de routage inter domaines (BGP)
Implémentation du système proposé Spécification (UML) du plan de signalisation Implémentation (Java)
Intégration plan signalisation et plan communication Tests avec applications MM
jeudi 18 novembre 2004 8
PLAN
Architecture de communication à QdS garantie
Caractérisation des performances des services
Proposition d’architecture de signalisation Test du système de communication
Conclusions et perspectives
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Partie 1 : État de l’art
Signalisation multi domaines
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Situation 2 problèmes majeurs
Définition homogène des contrats de services Gestion des ressources (bande passante)
Évaluation des disponibilités des ressources
Réservations des ressources
Propositions Modèles de contrat (SLA+SLS) Protocoles adaptés à la gestion (BGP,BGRP,COPS,…)
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 12
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Définition homogène des contrats de services Propositions de SLA (+SLS) standard
entre 2 opérateurs / 1 opérateur et 1 client
[Tequila], [Cadenus], [Eurescom]
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 13
Identification Service Name: “P1008 Virtual Leased Line” [S] Service Description: “This service …“ [S] Service PDB: “EF-PHB” [S] Seller Identifier: “VLL Plc” [S] Buyer Identifier: “Network Provider Plc” [B] Validity Period Start Date: “1 March 2001” [B] End Date: “1 March 2002” [B] Traffic Identification Identification Header Fields: DESTINATION_ADDRESS_FIELDS & PROTOCOL_PORT_NUMBER [S->B] Destination Address: “134.148.156.0” [B] Destination Address Mask: “255.255.255.0” [B] Protocol-Port Range Protocol: “TCP” [S -> B] Source Port Start: UNSPECIFIED Source Port End: UNSPECIFIED Destination Port Start: 1000 [B] Destination Port End: 1050 [B]
Définition des services [Eurescom]
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Traffic Profile Traffic Profile Algorithm: Leaky_Bucket MTU Size: 1500 [S ->B] Mean Rate: 64 KB/s [S -> B] Burst Size: 1.2 MB [S] Time Interval: 10 Sec [S] QoS Delay Descriptor Delay Priority: UNSPECIFIED Mean Delay: “50 ms” [S] Mean RTT: “105 ms” [S] Loss Descriptor Loss Priority: UNSPECIFIED Mean Loss: 10-9 [S] Throughput Mean Throughput: “64 KB/s” [S] Service Reliability Availability: 99% [S] …
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 14
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Évaluation des disponibilités des ressources Proposition [Aquila - basée sur BGP]
Utilisation normale de BGP : annonce des routes Extension proposée : utilisation d’un champ d’en tête BGP pour informer de l’état d’utilisation du lien
Domaine X
Domaine Y
Domaine Z
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 15
Réservation des ressources Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Domaine X Domaine Y Domaine Z
Proposition : COPS multi domaines [2Tiers]
Propagation des requêtes de réservation entre Bandwidth Broker via COPS
Requête
COPSCOPS
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Architecture de notre système
caractérisation des services
Applications MMApplications MM
Plan signalisation Plan communication
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Partie 3
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
……
GS
UDP
AS
FPTP
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
API Quantification des besoins des applications
Paramètres de QdS
τr : taux de paquet que l'application souhaite recevoir
τd [0,b] : taux de paquet que l'application souhaite recevoir dans un intervalle de temps [0,b]
Sémantiques de garantie Absolue : strict respect du paramètre Moyenne : respect statistique du paramètre
Caractérisation du trafic (débit moyen)
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 20
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
API Primitives de service
sendData(String sessionName , int flowNumber , byte[ ] Data)
byte[ ] receiveData(String sessionName , int flowNumber)
closeChannel(String sessionName , int flowNumber)
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Primitives de service (alternative)
00
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Partie 3
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 23
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Démarche
Campagnes de simulation ns 2
Multi domaines Étude mathématique
[ Campagne d’émulation Dummynet ]
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Mesures sur plate-forme expérimentale @IRS
Rc
RbRENATER2
(ATM)
LAAS
Rc
Rb
LIP6
n flux supplémentaires
Influence de la ≠ charge entre deux flux à QdS Influence du nombre de flux à QdS Influence de la ≠ de classe pour un état donné de charge du réseau trafic BE saturant
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 25
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Mesures en simulation ns 2
BE AS Rb Rx Rc
Rc
RbRENATER2
(ATM)
LAAS
Rc
Rb
↑ du nombre de routeurs de coeur
Convergence sur un routeur de coeur
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 26
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Résultats (sur les flux en AS)
Paramètres étudiés Fonction de répartition du délai des paquets d'un flux Pourcentage de pertes
Mesures @IRS Impact
Charge du réseau en trafic BE Configuration de la plate-forme (poids WFQ, taille file d’attente,…)
Faible impact ≠ charge entre flux à QdS Nombre de flux à QdS
Simulations ns 2 Faible impact lors de l'augmentation
Du nombre de flux sur un routeur de bordure Du nombre de routeurs de cœur traversés
Impact de la convergence sur un routeur de cœur
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 27
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Modèle de caractérisation des services Modélisation de la fonction de répartition du délai pour un flux (entre 2 points du réseau et pour une charge donnée de BE)
Pourcentage de paquets reçus
y3
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Modèle de caractérisation des services (suite)
Environnement multi domaines
fX fYE R
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Partie 4
Principe Spécification Implémentation Test
Objectifs
Application
Fonct° de rép… .
Contraintes de QdS
N°2 : Liaison entre besoins applicatifs et services du système
N°1 : Gestion inter domaines des réservations
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 31
Équipements Hôtes d’extrémité
Routeurs de bordure Bandwidth Brokers
Domaine DiffServ AS2
R3 R4
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Réseau d’entreprise
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Équipements (suite)
Contenu d’un BB SLA contracté avec tous les clients de l’AS Caractérisation des services entre un point d’entrée et un point de sortie de l’AS Tables BGP
domaine DiffServ AS2
R3 R4
Distinction comportementale BB local = premier BB rencontré Rôle = Centraliser contraintes applicatives et perf. des AS
BB distant = autre BB Rôle = Répondre aux sollicitations d’un BB local
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 33
Architectures et Protocoles Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
… IP
QdS
canal
QdS
bordure
BB distant
BB distant
BB distant
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
3 questions
Comment : Un BB connaît-il les points d’entrée et de sortie de son AS ? (et donc qu’elle est la fonction de répartition)
Un BB connaît-il l’adresse du prochain BB à contacter ?
Un BB local peut-il choisir le service adapté à la communication ?
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 35
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Tables de routage Indispensables sur un BB (BGP)
Quels sont les point d’entrée et de sortie de l’AS ?
Quelle est l’@ IP du prochain BB à contacter ?
Table BGP du BB
23.32.5.3 4
193.168.4.1
AS 4 AS 3
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Tables de QdS Indispensables sur un BB
Adresse des clients Trafic souscrit / trafic disponible pour chaque classe Caract. des services entre client / point de sortie Client
192.168.6.0 AS
sousc AS
dispo GS
500 450 200 180
Points de sortie t 1 y 1 t 2 y 2 t 3 y 3 t 4 y 4 t 5 y 5
AS 23 0% 34 7% … … … … … …Point 1 GS
AS
22
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Algorithme de sélection des services Exécuté sur le BB local Objectif : trouver, si possible, les services pour satisfaire la requête de l’application
Paramètres QdS de
(convolution) des services
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 38
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Spécification en UML
Utilisation de logiciel TAU de Telelogic Modélisation de l’architecture de communication
Simulation de l’architecture de communication
Modélisation des comportements des équipements Spécification des mécanismes de
Maintien des ressources
Détection d’un équipement hors service,…
Spécification du double comportement d’un BB local et distant
Simulation pour différents scénarios
Diagrammes d’état idle
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
true
Diagrammes de séquences
Release Resources Release
: BBRemote : BBRemote
: BBRemote : BBRemote
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 41
De la spécif. à l’implémentation et au test Spécification UML 2
Conception le système Test le système par simulation de scénarios Détection des erreurs avant l’implémentation
Implémentation du modèle UML 2 en Java
Test du système de communication Définition de scénarios de tests Déploiement d’une plate-forme expérimentale (LAAS) Intégration des applications MM avec le système Validation expérimentale du comportement des BB
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 42
Plate-forme LAAS
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Routeur émulateur
Routeur émulateur
? 0.12 0.18
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
VLA N3
0.30 ms
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Résultats : test du comportement du BB local
BB
AS3
AS4
AS5
gui15
gui13
gui17
BBgui29
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Résultats : test du comportement du BB local
BB
BB
AS3
AS4
AS5
gui15
gui13
gui17
gui29
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Partie 5
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Conclusions
Thèse Spécification et implémentation d’une architecture
de signalisation dans un environnement : Multi services au niveau IP (DiffServ ) Multi protocoles au niveau Transport (TCP,UDP,FPTP) Multi domaines
pour un système de com. offrant des garanties de QdS par flux
À des applications MM type visioconférence Qui optimise les ressources de réseau par le choix automatique des services (Transport / IP)
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 48
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Conclusions (suite)
Contributions Modèle des performances des services Transport et IP dans un contexte mono puis multi domaines Spécification et implémentation d’une architecture de signalisation pour le multi domaines DiffServ
Plate-forme émulant le comportement d’un environnement DiffServ multi domaines
Déploiement et test du système sur la plate-forme Intégration plan signalisation et plan communication Tests d’application MM
jeudi 18 novembre 2004 Thèse Guillaume AURIOL 49
Partie 1 Partie 2 Partie 3 Partie 4 Partie 5
Perspectives Évaluation de l’optimisation des ressources
Étude de la mise à l’échelle vis-à-vis Du nombre de connexions TCP par BB De la surcharge du réseau / PDU de signalisation Du maintien des tables de routage, de QdS
Intégration de protocoles applicatifs (SIP) Intégration de nouveaux protocoles de Transport Lien entre signalisation inter et intra domaine

Questions ?
Spécification et implémentation d’une architecture de signalisation à gestion automatique de la QdS dans un environnement IP m
Contexte et problématique
Problématique et contribution
Situation
Définition des services [Eurescom]
Réservation des ressources
API
API
Résultats (sur les flux en AS)
Modèle de caractérisation des services
Modèle de caractérisation des services (suite)
Architecture de signalisation multi domaines
Objectifs
Équipements
Spécification en UML
Diagrammes d’état
Diagrammes de séquences
Plate-forme LAAS
Résultats : test du comportement du BB local
Résultats : test du comportement du BB local
Conclusions et perspectives