INQA : La Gestion de la Qualité de Services Dans Une Architecture

SETIT 2009
5th International Conference: Sciences of Electronic,
Technologies of Information and Telecommunications
March 22-26, 2009 – TUNISIA
INQA : La Gestion de la Qualité de Services Dans Une
Architecture IMS
Brahim RAOUYANE*, Mostafa BELLAFKIH* et Daniel RANC**
*INPT
Madinat Al Irfane Rabat Instituts, Maroc
[email protected]
[email protected]
** Telecom SudParis, Evry,
France
[email protected]
Résumé: la normalisation de l’Internet Multimedia Subsystem (IMS) a renouvelé l’architecture de gestion des
services de télécommunication avancés. Néanmoins l’IMS introduit également de nouvelles interrogations, en
particulier concernant la gestion de la Qualité de Service (QoS) considérant les services multimédia invoquant des
technologies tant avancées (UMTS) qu’existantes (POTS, GSM). Dans ce contexte, cet article propose d’étudier tant
d’un point de vue théorique que pratique une architecture de gestion de la QoS de façon transparente et de bout en bout
dans un réseau IMS.
Mots clés : IMS, IntServ, QoS, SIP.
INTRODUCTION
Le potentiel offert aux opérateurs pour proposer de
nouveaux services attrayants s'est considérablement
enrichi par l'introduction des technologies 3G UMTS
[1] [2], améliorant les débits, et par les efforts du
consortium 3GPP pour définir une nouvelle
plateforme de gestion de services: l'IMS (IP
Multimédia
Subsystem)
[3]
[4].Néanmoins,
l'introduction
de
ces
nouvelles
capacités
technologiques induit également des exigence
s’accrues en termes de qualité de service (QoS). Cet
article entre dans le cadre du projet de du projet de
recherche INQA subventionné par Méditélecom, qui
s’intéresse à la mise en oeuvre d’une plateforme IMS
permettant l’expérimentation et la validation de
scénarios de gestion de QoS de bout en bout; à
l’introduction de nouveaux services à itinérance multi
technologies, à QoS garantie; ainsi qu'à l’intégration
d’IMS et de l’architecture de référence NGOSS
(figure 1).
Figure 1. Contexte général du projet INQA
La présente contribution va introduire le contexte
de l’étude INQA en s’intéressant à la voix sur IP et
aux choix entrepris pour la gestion de la QoS et
présentera les différents critères et protocoles de
gestion de la QoS, des simulations et discussions
avant de conclure.
1. Contexte de l’étude
Pour s’assurer qu’une infrastructure IP [3] [4] peut
supporter un service de ToIP, il faut vérifier
l’obtention régulière dans le temps de valeurs de QoS
générant un bon niveau d’écoute humaine. L’étude de
qualification d’un tel réseau IP étudiera les
équipements de ToIP impactant le délai de transit tels
que les routeurs, les passerelles, les proxys, et les
-1-
SETIT2009
donc – par la variation de la quantité de trafic en
transit. Elle impacte fortement les communications
interactives telles que la voix, générant des bruits
désagréables, des craquements voir des blancs. La
valeur maximale de la gigue permet de dimensionner
les buffers pour éviter au maximum les congestions.
On estime qu’une gigue supérieure à 100ms dégrade
trop le service et n’est pas acceptable.
postes téléphoniques IP eux-mêmes [5].
Le coeur de réseau IMS [6] repose sur le protocole
SIP [7,8]. (Figure 2) pour gérer les sessions IP
multimédia, et sur le protocole IP pour le transport du
trafic et de la signalisation associés. Il supporte l'inter
fonctionnement avec les réseaux voix et données IP
fixes et mobiles existants [9], y compris les services
Internet.
- Bande passante ou débit maximum d'une
liaison: c'est le volume de données qu'il est possible de
transférer via celle-ci.
- Perte de Paquet : Il s’agit de la perte pure et
simple d’un ou plusieurs paquets. Les causes possibles
sont soit une erreur sur le CRC de ce paquet, qui est
ainsi détruit, soit un bruit sur la ligne de
transmission,soit une mémoire tampon pleine et ce
paquet n’a pas pu être traité, ou un changement de
routage créant un trou noir.
Un réseau IP est composé d'un ensemble de
routeurs et de liaisons de transmission. Le récepteur et
l’émetteur ont des caractéristiques de délai, débit
maximum et disponibilité. Et les routeurs peuvent
avoir un impact significatif sur le délai, la gigue et la
disponibilité. Afin de garantir la qualité de service,
trois protocoles se sont imposés dans les réseaux IP:
Figure 2. Session SIP sur IMS
Comme le système est basé sur IP, l'IMS héritera
de la plupart des problèmes de QoS de l’Internet [10,
11, 12]. Cependant, contrairement à l’Internet où les
utilisateurs acceptent des dégradations occasionnelles
de QoS, les utilisateurs d'IMS s'attendront très
probablement aux mêmes niveaux de qualité que dans
les réseaux légataires.
−
Intserv (Integrated Service, protocole inclus
dans RSVP, Ressource Reservation Protocol)
−
Diffserv (Differentiated Services)
−
MPLS (MultiProtocol Label Switching)
Aussi notre étude s’intéressera dans la suite à
montrer l’intérêt de la gestion de la bande passante qui
fige les utilisations alors que le protocole Diffserv
donne une différentiation des paquets par leur
marquage.
3. Gestion de QoS avec IntServ et DiffServ
2. Critères de la QoS dans IP
Afin d’avoir une gestion de la QoS de bout-en bout
il faut que tous les routeurs du réseau soient
paramétrés de la même manière. Deux approches
existent: Intserv et DiffServ
Le protocole IP n’a pas été initialement prévu pour
prendre en compte les paramètres de QoS. Les réseaux
en mode paquets ont été développés à une époque où
la bande passante était rare, la stratégie étant
d’occuper le maximum de liens quitte à introduire des
délais supplémentaires dans la transmission des
données.
3.1. IntServ [14]: (Integrated Services)
L’idée est de fournir une QoS garantie sur les
réseaux IP. Dans un modèle IntServ les applications
envoient des requêtes RSVP afin de réserver les
ressources réseau nécessaires. Après une négociation
avec les gestionnaires de QoS déterminant si le service
peut être garanti, les ressources sont réservées ou alors
un message d’erreur est renvoyé au demandeur. Une
fois les ressources réservées, la QoS pourra être
appliquée au sein des routeurs avec des algorithmes de
gestion de files d’attente. Le but principal d’IntServ
est de fournir un lien de communication à qualité
constante en termes de débit et de délai. La principale
limitation d’IntServ réside dans son passage à
l’échelle. En effet, les requêtes RSVP doivent être
mémorisées dans tous les routeurs concernés. Or dans
un réseau à large échelle tel qu’Internet, il y a une
quantité phénoménale de flux concurrents. Une telle
quantité imposerait des stockages très conséquents
dans la mémoire des routeurs.
La caractérisation de la QoS [13] met en jeu
plusieurs critères :
- Délai : le temps écoulé entre l'envoi d'un paquet
par un émetteur et sa réception par le destinataire. Il
est recommandé un délai maximum de 120 ms par
direction pour une conversion interactive entre deux
individus.
- Gigue : la variation du délai de transfert de
paquets IP entre deux points de bout en bout est
définie sur la base des observations d'arrivées de
paquets IP correspondants à des points de mesure
d'entrée et des ortie. Il est causé principalement par la
variation de la longueur des queues dans un réseau et
-2-
SETIT2009
Figure 3. L’effet de shaping sur un trafic variable
3.2. DiffServ [15]: (Differentiated Services)
Pour résoudre les problèmes posés par IntServ. L’IETF
a proposé de marquer les paquets en utilisant le champ
DSCP, mais comment est-il possible d’assurer la QoS
en utilisant ce champ ? Tout d’abord, les paquets
possédant le même DSCP sont agrégés pour former un
Behavior Aggregate (BA). Etant donné que l’on gère
ici un type de flux et non paquet par paquet, la
garantie de QoS n’est pas stricte mais statistique. Il est
important de noter que des paquets provenant de
diverses applications peuvent partager le même BA.
L’écrêtage figure (4), appelé policing permet
de jeter les paquets par ordre de priorité
croissante en fonction d’un seuil maximal de
bande passante définit. Cette méthode est à
l’origine d’une forte perte de paquets.
Sur un noeud DiffServ il faudra ensuite choisir un
PerHop Behavior (PHB) qui définira en fonction du
BA les règles de mise en file d’attente,
d’ordonnancement ou de lissage.
Quatre PHB standards sont définis:
Figure 4. L’effet de policing sur un trafic variable
– Default PHB;
– Class-Selector PHB;
4. Mise en palce d’une stratégie de QoS
– Expedited Forwarding PHB (EF) ;
La gestion de la QoS permet de différencier les
types de trafic (audio, vidéo, voix, types de
données…) afin de leur assigner des règles de
traitement spécifiques. Par exemple, on veut favoriser
le trafic vocal qui possède des contraintes de temps
réel et de débit minimum, par rapport au trafic web ou
ftp moins important.
– Assured Forwarding PHB (AF).
On notera simplement que le PHB EF est utilisé
pour implanter le service Premium et que le PHP AF
est utilisé pour le service Olympic (Gold, Silver,
Bronze).
IntServ et Diffserv peuvent être utilisés d’une
manière complémentaire afin de bénéficier des
possibilités d’IntServ sur des réseaux à large échelle.
Le modèle DiffServ utilise le champ DSCP dans
l’entête IP (v4 ou v6) et différencie le comportement
des routeurs (PHB) ; les routeurs d’extrémité
(Ingress/Egress Edge Routers) positionnent un champ
servant à différencier les paquets et sont responsables
de l’exécution de mécanismes de contrôle d’admission
et de classification. Par ailleurs, les routeurs de cœur
(Core Routers) de réseau appliquent simplement
l’ordonnancement et le contrôle de congestion
approprié suivant la valeur du champ DSCP.
L’idée, présentée est d’avoir des routeurs IntServ
en bordure du réseau et des routeurs DiffServ au
coeur. Il faudra dans ce cas que les requêtés RSVP
soient traduites pour modifier le champ DSCP des
paquets.
3.3. Politique de trafic:
La politique de trafic est en complément des
techniques d’ordonnancement. Elle permet le contrôle,
le lissage et l’écrêtage du trafic pour contrôler le
volume de flux entrant dans le réseau. Trois critères
sont importants, le débit moyen,l e débit crête et la
taille maximum du pic de trafic.
Dans un réseau (figure 5) nous avons trois
localisations de gestion de la QoS : - dans les
terminaux pour assigner et marquer des priorités ; dans les noeuds périphérique (Edge Nodes) c’est la
classification, le marquage des paquets et une
surveillance et lissage de trafic ; - dans les nœuds
centraux c’est un rôle de prévention de la congestion
(contrôle de flux, ordonnancement) et une réaction à la
congestion par un filtre suivi par l’élimination de
paquets.
Deux méthodes existent : le lissage du traffic
(Shaping) [16] et l’écrêtage (Policing) [16] :
Le lissage permet d’éviter les pics de flux
(figure 3) ; lorsque le trafic dépasse un seuil
maximal de bande passante, celui-ci est
retransmis par les applications.
Figure 5. Architecture générale de réseaux internet
-3-
SETIT2009
QoS. De plus, ces mesures nous permettent d’étudier
le seuil d’engorgement du réseau suivant la vitesse et
avec ou sans perturbations. Après les mesures faites
lors des sessions SIP, le résultat le plus intéressant est
le comportement des routeurs et des machines en cas
de saturation.
Pour contrôler le trafic dans un routeur [17] qui
mène vers un réseau IMS nous avons utilisé les
algorithmes de gestion suivants :
a)
Classification de trafic par l’attribution d’un
label à chaque paquet,
b) Marquage/Remarquage des paquets en mode
BA, MA.
c)
L’intérêt de faire des sessions multimédia impose
d’étudier des politiques de QoS du type gestion de la
bande passante avant d’utiliser Diffserv (Figure 5).
Surveillance du trafic : surveiller la
conformité du flux a pour objet de préserver
les
autres
communications
d’un
comportement excessif d’une source en
marquant, modifiant ou refusant un flux non
confirmé,
Lors de cette manipulation on gère une bande passante
pour chaque service, FTP ou VoD, et on remarque que
cette gestion doit être préventive en QoS pour suivre
l’augmentation du trafic.
5.2. Trafic avec QoS: Modèle DiffServ
d) Lissage de trafic : modifier certaines
caractéristiques du flux pour se confirmer
aux usages de buffer,
e)
f)
La gestion de la QoS doit différencier les types de
trafic (audio, vidéo, voix, types de données…) afin de
leur assigner des règles de traitement spécifiques au
lieu de prévoir toujours le maximum de bande
passante pour ne pas pénaliser la VoD par exemple.
Gestion de congestion : La congestion est un
problème au sein du réseau. Une congestion
se traduit souvent par une perte de paquets.
Les paquets sont soient de type TCP ou UDP.
La perte d’un paquet TCP, entraîne la mise en
place d’un algorithme de congestion
avoidance qui va augmenter le trafic
(rémission du paquet TCP). La solution est
l’ordonnancement (FIFO, PQ, CBQ, WFQ)
des paquets et gestion active des files
d’attente,
Dans le cadre d’un réseau exploité pour du trafic
FTP et pour de la VoIP, on doit favoriser le trafic de ce
dernier qui possède des contraintes de temps réel et de
débit minimum, par rapport au FTP.
On peut distinguer différentes phases de
configuration, dues aux diverses étapes de la mise en
place de la QoS :
- Filtrage des flux
contrôle des congestions : par le contrôle de
flux et une réaction avec l’élimination de
paquets.
- Classification du trafic
- Création d’une politique de Service
- Attachement de la politique à une interface
5. Expérimentations :
La première phase consiste à étudier la ToIP dans
une infrastructure IMS [18,19, 20] (Figure 2) en se
basant sur SIP. Nous avons utilisé la plateforme libre
Open IMS [21].
6. Discussion
Lors des manipulations de ToIP, on remar que
d’emblée certaines variations de débit sans pour autant
que des pertes ne soient mesurées :
Nous avons déployé un serveur d’applications
fournissant la VoD (la Vidéo à la Demande) et nous
avons testé une configuration avec deux services
concurrents, la VoD et le transfert de fichiers avec FTP
(Figure 6).
- Tout d’abord, plus on envoie de paquets, et plus
le débit est important. Chose logique. Nous avons
ensuite effectué les mêmes mesures avec des paquets
contenant plus d’informations. La constatation
précédente se vérifie également dans ces exemples.
On distinguera également que plus la taille des
paquets est importante, plus le débit sera important,
pour la même raison que précédemment. En effet, bien
que les mesures donnent une valeur moyenne, lors de
l’expérimentation, nous avons observé que le débit
variait. Cette variation est liée à la file d’attente du
routeur qui se remplit. Une fois que cette dernière est
pleine, le débit diminue. Celui-ci pourra à nouveau
augmenter lorsqu’il y aura de la place dans la file.
Dans l’ensemble des premières mesures, on ne
constate aucune perte. En effet, le débit est supporté
donc aucun paquet n’est perdu. Par contre les mesures
effectuées avec une surcharge de réseau avec (VoD par
exemple) montrent des pertes. Tout comme pour le
débit, cela s’explique en observant les files d’attentes.
Figure 6. Session VoD et FTP avec IMS.
5.1. Trafic sans QoS :
L’objectif de la simulation sans QoS est d’obtenir
des valeurs de référence. En effet, de cette façon nous
pourrons comparer le gain réel de l’utilisation de la
-4-
SETIT2009
En effet, lorsque ces dernières sont pleines, le routeur
détruit les autres paquets qui arrivent. Ce mécanisme
explique donc les pertes détectées.
[7]
Toutefois, il se peut aussi que le problème vienne
des files d’attente des machines.
[8]
Le paramètre de gigue est très important dans les
applications sensibles comme, par exemple, la VoIP.
En effet, si la gigue est trop importante, le service est
fortement dégradé. On estime qu’une gigue supérieure
à 100ms dégrade trop le service et n’est pas
acceptable.
[9]
[10]
[11]
A partir des captures de paquets que nous avons
réalisées, on remarque que deux éléments peuvent
faire augmenter la gigue : la perte de paquets, et le
nombre et la taille du paquet, car les paquets sont
potentiellement plus longs à traiter à la fois par le
routeur et par les machines.
[12]
[13]
7. Conclusion
Les mesures ainsi faites donnent une idée de
l’intérêt de la gestion des files d’attente dans les
routeurs et de l’utilisation d’une politique de gestion
du type DiffServ basé sur la priorité selon le type de
trafic. Aussi lors de l’utilisation de cette procédure et
malgré des trafics concurrents, la VoD continue sans
être perturbée alors que dans la même situation et sans
gestion de priorité la vidéo est très dégradée.
[14]
La politique MPLS est aussi en phase
d’implémentation pour améliorer la QoS dans le
contexte de notre architecture, une étude a priori est
encours de réalisation pour implémenter les protocoles
Diameter [22] et COPS [23] afin d’automatiser les
procédures précédentes de gestion de QoS.
[15]
[16]
[17]
[18]
Enfin toutes ces politiques doivent respecter
l’architecture de référence NGOSS de TMF Forum
[24, 25] qui fait le but final du projet INQA.
[19]
[20]
[21]
[22]
[23]
ACKNOWLEDGMENT
Nous tenons à remercier MEDITELECOM pour
son intérêt au projet INQA et son financement, et
également aux stagiaires de l’INPT qui ont contribué
dans ce projet.
[24]
[25]
[26]
REFERENCES:
[1] www.tech-invite.com/
[2] www.3gpp.org
[3] G. Camarillo, M. A. Garcia-Martin, “The 3G IP
Multimedia Subsystem (IMS)”, John Wiley &
Sons Ltd, 2004.
[4] Camarillo, Gonzalo; "3G IP Multimedia
Subsystem (IMS): Merging the Internet and the
Cellular Worlds". Hoboken, NJ, USA: John Wiley
& Sons, Incorporated, 2005.
[5] Henry Sinnreich. Alan B. Johnston; Internet
Communications Using SIP “Delivering VoIP and
Multimedia Services with Session Initiation
Protocol“Second Edition.
[6] 3GPP TS 24.229, ”IP Multimedia Call Control
Protocol based on Session Initiation Protocol
-5-
(SIP)and
Session
Description
Protocol
(SDP)”,Stage 3
Alan B. Johnston “SIP Understanding the Session
Initiation Protocol “Second Edition.
McGrawHill, Broadband_ Telecommunications
Handbook-VPNS, 3GW, GPRS, MPLS, VoIP,
SIP.2ndEd 2002
Gilles Bertrand. “The IP Multimedia Subsystem in
Next Generation Networks “May 30, 2007
J. Fabini, P. Reichl, A. Poropatich, R. Huber,
N.Jordan: "IMS in a Bottle": Initial Experiences
from an OpenSER-based
Prototype Implementation of the 3GPP IP
Multimedia Subsystem. Proc. International
Conference on Mobile Business (ICMB) business
2006, Copenhagen , Denmark, June 2006.
P. Kurtansky, P. Reichl, J. Fabini, T. Lovric, B.
Stiller: “Efficient Prepaid Charging for the 3GPP
IP Multimedia Subsystem (IMS)”. Proc.
International Conference on Integrated Design and
Process Technology (IDPT'06), Special Session on
"Pricing", San Diego, CA, USA, June 2006.
P. Reichl, S. Bessler, J. Fabini, R. Pailer, and J.
Zeiss: “Implementing a Native IMS Location
Service Enabler over a Prototypical IMS Core
Network Test bed”. Proc.3rd IEEE International
Workshop on Mobile Commerce and Wireless
Services (WMCS'06) in conjunction with IEEE
Joint Conference on Ecommerce Technology
(CEC'06) and Enterprise Computing, ECommerce
and
E-Services
(EEE'06),San
Francisco, USA, June 2006.
Kun I. Park, Ph.D. The MITRE Corporation USA
“QoS in packet networks“.
www.ietf.org/rfc/rfc1633.txt
www.ietf.org/rfc/rfc2475.txt
Christina Hattingh “End-to-End QoS Network “
Tim Szigeti - CCIE No. 9794,
Lucian Gheorghe, “Designing and Implementing
Linux Firewalls and QoS using net filter, iproute2,
NAT andl7-filter” October 2006.
3GPP TS 23.228 “IP Multimedia Subsystem
(IMS),Stage 2”
IETF RFC 1889 “RTP: A Transport Protocol for
Real-Time Applications”
IETF RFC 3261 “SIP: Session Initiation Protocol”
www.openimscore.org
RFC 3588 “Diameter Base Protocol”, September
2003
http://www.ietf.org/rfc/rfc2748.txt
Tele Management Forum 2003 ,GB922 Addendum
4 SQoSv 1.0
www.tmforum.org