WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Problématique de gestion d'un réseau multiservices et son impact sur la GOS. Cas de la gécamines Lubumbashi et Kolwezi.


par Delly MPUNGU
Université Protestante de Lubumbashi - Ingénieur en sciences informatiques, réseaux et télécommunications 2019
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

CHAPITRE 3 : ANALYSE FONCTIONNELLE DU MODELE INTSERV

ET DIFFSERV

3.1. INTRODUCTION

Nous voici au troisième chapitre de notre travail, dans cette partie il sera question d'analyser des différentes fonctionnalités avancées du modèle DIFFSERV et INTSERV à l'aide des diagrammes UML selon les protocoles mis en oeuvre, la réalisation de qualité de service (classification, réservation etc.), les mécanismes fonctionnant au niveau du routeur puis nous ferons un choix sur le modèle à implémenter au sein du réseau de la Gécamines.

3.2. MODELE A DIFFERENCIATION DE SERVICE (DIFFSERV)

3.2.1. PRESENTATION ET PRINCIPE DE FONCTIONNEMENT

Le modèle DiffServ est un modèle de différentiation des services défini par l'IETF dans le RFC 2475, son objectif primordial est d'effectuent un traitement différencié des trafics (données, téléphonies IP, vidéo sur IP etc.), regroupés en quelques classes de services, pour garantir la qualité de service. [9]

Le principe de fonctionnement de DiffServ est la création de diverses classes de services fournissant chacune d'entre elles une qualité de service différente ; ces classes se distinguent les unes des autres par la présence d'un code dans le paquet IP : le DSCP (DiffServ Code Point).

Le marquage des paquets selon la qualité de service qu'il nécessite, se fait en périphérie du réseau, soit à la source directement ou soit au niveau du routeur de bordure et ensuite, les routeurs internes du réseau déterminent la priorité du paquet et le traitent en fonction de celle-ci.

Figure 3. 1. Schéma de principe du modèle DIFFSERV

3.2.2. PRESENTATION D'UN ROUTEUR DIFFSERV DE BORDURE

40

Figure 3. 2. Architecture d'un routeur DIFFSERV de bordure 3.2.3. LE DIAGRAMME DE CAS D'UTILISATION

+ Identification des acteurs

1. Acteur Principale : Routeur Emetteur

2. Acteur Secondaire : Routeur Récepteur

+ Identification des cas d'utilisations :

Avec le routeur de bordure du modèle Diffserv, nous avons retrouvés les quatre cas

d'utilisation suivants :

V' Cas d'utilisation 1 : Classifier paquets

V' Cas d'utilisation 2 : Conditionner l'envoi du trafic

V' Cas d'utilisation 3 : Gérer file d'attente

V' Cas d'utilisation 4 : Ordonnancer le trafic

41

Figure 3. 3. Diagramme de cas d'utilisation DIFFSERV

+ Description textuelle du diagramme de cas d'utilisation du modèle à service différenciés :

Vue le diagramme de cas d'utilisation de ce modèle, voici la description textuelle : V' Cas d'utilisation 1 : Classifier paquets

> Objectif du cas d'utilisation : la classification des paquets en fonction du type de service

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Précondition : le routeur émetteur doit être opérationnel et configuré avec le modèle à service différenciés (Diffserv)

> Scénario nominal : ce routeur sélectionne et classifie les paquets en se basant sur une partie de l'entête du paquet

42

> Scénario alternatif : impossibilité de classifier les paquets si le routeur émetteur est down et aussi si le modèle à service différencié n'est pas configuré sur le réseau

> Post-condition : paquet classifiés

V' Cas d'utilisation 2 : conditionner l'envoi du trafic

> Objectif du cas d'utilisation : adapter le trafic à certaines conditions requises pour l'envoi

> Acteur Principale : Routeur Emetteur > Acteur Secondaire : Routeur Récepteur

> Précondition : le routeur émetteur doit être opérationnel et configuré avec le

modèle à service différenciés (Diffserv)

> Scénario nominal : le trafic doit passer par les composants tels que la

métrologie, le marquage, le lissage ou le rejet des paquets

> Scénario alternatif : impossibilité de Conditionner le trafic si le routeur émetteur est down et aussi si le modèle à service différencié n'est pas

configuré sur le réseau

> Post-condition : trafic conditionné

V' Cas d'utilisation 3 : gérer file d'attente

> Objectif du cas d'utilisation : stocker les paquets selon leur priorités lorsque le

réseau est congestionné

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Précondition : le routeur émetteur doit être opérationnel et configuré avec le

modèle à service différenciés (Diffserv)

> Scénario nominal : utiliser un Algorithme de gestion de la file d'attente en cas

de congestion

> Scénario alternatif : difficulté de gérer la file d'attente si le modèle à service

différenciés n'est pas configuré

> Post-condition : la file d'attente gérée

43

V' Cas d'utilisation 4 : ordonnancer les paquets

> Objectif du cas d'utilisation : arbitrer la sortie des paquets prioritaires sur le

réseau

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Précondition : les paquets doivent être classifiés et les trafics doivent être

conditionnés

> Scénario nominal : autoriser en premier lieu les paquets prioritaires

> Scénario alternatif : difficulté d'ordonnancer le trafic non classifié et les

paquets non conditionnés

> Post-condition : paquets ordonnancés

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Aux âmes bien nées, la valeur n'attend point le nombre des années"   Corneille