Exposée sur la gestion centralisée des équipements informatiques et télécoms basée sur les nouvelles politiques

1. GESTION DES RESEAUX BASEE
SUR LES POLITIQUES
Présenté par
Aliou NOKHO
Emeric KAMLEU
Alie Badara DIAGNE
Mamadou DIOUF
Djibril SAMBE

2. PLAN DE TRAVAIL
I. INTRODUCTION
II. ARCHITECTURE DE GESTION DES
POLITIQUES
III. MODELE D ’INFORMATION DU
SYSTÈME DE GE STION DE
POLITIQUES
IV. EXEMPLE DE PROTOCOLE DE MISE
EN ŒUVRE DES GESTIONS DE
POLITIQUES:COPS
V. SCENARIOS DE FONCTIONNEMENT
VI. CONCLUSION

3. I. INTRODUCTION (1/3)
La complexité de la gestion des réseaux de nouvelles
générations en termes de diversité de services, d’accès,
des utilisateurs, etc., rend l’approche classique basée
sur le modèle agent/gestionnaire extrêmement
compliquée à mettre en œuvre et à maintenir lorsque
l’on veut traiter l’ensemble de ces aspects de manière
unifiée. En effet, dans l’approche classique, il est
nécessaire de connaitre l’ensemble des équipements et
des modèles d’informations de gestion. Dès lors, dès
que l’on intègre un nouvel équipement ou une
nouvelle activité de gestion, il est nécessaire de
répercuter ces changements dans toute l’architecture
de gestion.

4. I. INTRODUCTION (2/3)
Pour palier à ces différentes contraintes de
l’approche classique de mise en place de
gestion du réseau, plusieurs solutions ont été
proposées par l’IETF(internet engineering task
force) pour définir et introduire de nouvelles
approches de gestion à l'instar de la gestion
basée sur les annuaires et les politiques. Notre
travail s’intéressera sur cette dernière
approche bien qu’elles soient étroitement
liées.

5. I. INTRODUCTION (3/3)
Une politique est un ensemble de règles qui
régissent le fonctionnement global du réseau.
L’administrateur de réseau définit ces politiques
en fonction des objectifs de l’entreprise. Celles-ci
peuvent être diverses selon que l’entreprise est
une compagnie ou un operateur. Lorsque les
objectifs sont complexes, il est intéressant de les
définir sous la forme d’une hiérarchie de
politiques, c’est-à-dire qu’une politique peut être
composée d’autres politiques.

6. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
La définition de la politique seule n’est pas
suffisant pour mettre en place une stratégie
globale de gestion : c’est pourquoi il est
nécessaire de définir un cadre de travail pour
la définition de ces politiques de gestion. Mais
avant cette étape, présentons les modes de
réalisation des politiques.

7. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
DIFFERENTES MODES DE REALISATIONS
OUTSOURCING
Dès que le réseau (routeur d’accès en général)
détecte les demandes d’un service
généralement à l’aide d’un protocole de
signalisation, la décision d’accepter, de rejeter
ou de modifier cette demande est déléguée à
une entité externe au réseau laquelle prend
les décisions en se basant sur des règles de
politique préétablies.

8. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
DIFFERENTES MODES DE REALISATIONS
PROVISIONNING
Cette méthode consiste à établir des
agréments au préalable appelés SLA(service
level agreements) et forcés les décisions dans
les réseaux indépendamment du fait que
l’entité concernées par ces politiques
accèdent ou non au service.

9. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
LE CADRE DE TARAVAIL POUR LA GESTION A
BASE DE POLITIQUES
Au niveau de l’IETF, un cadre générique de définition
des politiques de gestion est en cours de définition. Il
identifie principalement deux composants de base et
un protocole de communication entre ces deux
composants :

10. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
LE CADRE DE TARAVAIL POUR LA GESTION A
BASE DE POLITIQUES
Outils de gestion
des politiques
PDP
Annuaire des
Politiques
PEP
LDPD

11. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
LE CADRE DE TRAVAIL POUR LA GESTION A BASE
DE POLITIQUES
II. PEP(Policy Enforcement Point) : applique les
décisions des politiques de gestion qui lui
sont adressé
PDP(Policy Decision Point) : point de décisions
des politiques basées sur un ensemble de
politiques prédéfinies.
COPS(Common Open Policy Service) : un des
protocole permettant le dialogue PDP<=>PEP

12. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
LE ROLE DES DIFFERENTS COMPOSANTS
PDP(Policy Decision Point)
Fonctions :
• Identification des politiques et leur réalisation
• Définition des règles de politiques et les stockent dans une base de règles
de politique (annuaire de politique)
• Visualisation et présentations des règles par de outils simples
• Interprétation des règles introduites et détection d’éventuels conflits avec
des règles déjà présentes
• localisation et transformation des actions sous une forme compatible
avec l’environnement cible

13. II. ARCHITECTURE DE GESTION PAR
LES POLITIQUES
LE ROLE DES DIFFERENTS COMPOSANTS
PEP(Policy Enforcement Point)
Fonctions :
• Application des décisions du PDP au niveau des
éléments physiques ou logiques du réseau
• Interface entre les différents éléments du réseau et
le PDP

14. III. MODELES D’INFORMATIONS DU
SYSTÈME DE POLITIQUE
Au centre du système de politique se trouve la
description des règles de politiques sur lesquels va se
baser le PDP pour prendre des décisions. Dès que
l’on parle de politiques, il est nécessaire de parler de
relations contractuelles entre différents domaines de
politique (ex: ISP). Ceci nécessite la définition
formelle de ce qui est une politique, comment ces
politiques sont représentées, échangées, stockées
etc. Les politiques sont, en fait, le point
d’interopérabilité entre les différentes entités
impliquées dans la gestion.

15. III. MODELES D’INFORMATIONS DU
SYSTÈME DE POLITIQUE
Celles-ci peuvent représentées des aspects abstraits ou
concrets et être complètement dépendantes ou
indépendantes des technologies sous-jacentes selon
leur position dans la hiérarchie de gestion.
L’objectif du modèle d’information des règles de
politique est d’offrir à l’entreprise (l’administrateur)
les moyens de représenter le réseau et de spécifier
les objectifs de fonctionnement de ce réseau à
travers un ensemble de règles.

16. III. MODELES D’INFORMATIONS DU
SYSTÈME DE POLITIQUE
Exemple de modèles d’informations:
Modèle CIM (Common Information Model): Ce modèle
permet le partage de l’intégration d’information
ayant différentes sources homogènes ou
hétérogènes. En particulier il sert à étendre et à
unifier des modèles standard de gestion tels que
SNMP, DMI, etc… en utilisant une approche de
conception orientée objets.
Modèle PCIM (Policy Core Information Model): Ce
modèle peut être utilisé pour définir des politiques
de gestion dans différents domaines tels que la
gestion de la qualité de service, la sécurité etc…

17. IV. EXEMPLE DE PROTOCOLE DE MISE EN ŒUVRE
DES GESTIONS DE POLITIQUES:COPS
Ce protocole met en œuvre un modèle client-serveur
utilisé par les deux modes de gestion par les
politiques: Outsourcing ou Provisionning.
COPS utilise un mode connecté de communication via
TCP pour assurer un transport fiable des messages
échangés entre PDP et PEP. Il est extensible et peut
prendre en compte de nouveaux objets de politique
et supporter différents types d’informations
spécifiques aux clients sans que l’on doive modifier
quoi que ce soit dans le protocole lui-même.

18. IV. EXEMPLE DE PROTOCOLE DE MISE EN ŒUVRE
DES GESTIONS DE POLITIQUES:COPS
MODELE DE BASE (client/serveur)
COPS
PEP PDP
PORT COPS = 3288
LPDP TCP
IP

19. Le nœud de réseau
Le nœud du réseau est normalement le point de
réalisation du PEP. Celui-ci peut aussi contenir
optionnellement un PDP local (LPDP)
permettant de prendre des decisions de
politiques en absence d’un PDP distant mais il
doit toujours informer par la suite le PDP
distant == > on confère une certaine
autonomie au PEP.

20. Le nœud de réseau
Le nœud du réseau est normalement le point de réalisation du PEP.
Celui-ci peut aussi contenir optionnellement un PDP local (LPDP)
permettant de prendre des decisions de politiques en absence d’un
PDP distant mais il doit toujours informer par la suite le PDP distant
== > on confère une certaine autonomie au PEP.
Le PEP est l’initiateur du dialogue PEP/PDP à travers une connexion
TCP sur le numéro de port 3288. Plusieurs PDP peuvent être
associes au PEP. Une fois la connexion établie, le PEP envoie des
requêtes de demandes de configuration ou de décision et attendre
une réponse du PDP.
Le PEP est aussi responsable au PDP d’un changement dans l’etat
d’une requête et de la suppression de tout etat devenu non valable
à cause d’un évenement au niveau du client.

21. Serveur de politiques
Le PDP fonctionne en mode asynchrone et peut aussi envoyer
des decisions sans que celles-ci soient en rapport avec des
requêtes préalables afin de forcer le PEP à changer un etat
précédemment installé, par exemple un configuration
particulière d’une interface d’un routeur.

22. Le protocole COPS
Le protocole COPS a été conçu de manière à pouvoir envoyer de objets
auto-identifiés. Chaque objet transmis contient ainsi les données
nécessaires à l’identification de l’ état des requêtes, du contexte, du
type et de la référence des requêtes préalablement installées, mais
aussi les informations requises pour le reroutage des decisions de
politiques, concernant les rapports d’erreurs et l’intégrité des
informations transmises.
Ainsi, le protocole COPS identifie trois type d’ événements utilisés dans
l’approche OUTSOURCING, nécessitant une décision :
• Arrivée d’un message entrant
• Allocation de ressources locales
• Transfert d’un messages sortant
• ps : un 4ème type d’ événements va être nécessaire pour les clients
qui souhaitent recevoir, dans le cadre du PROVISIONNING , des
infos de configuration de la par du PDP.

23. Le protocole COPS : le PDU
VERSION DRAPEAU CODE TYPE-
OPERATION CLIENT
LONGUEUR DU MESSAGE
OBJETS COPS (1…N)
4 OCTETS

24. Le protocole COPS : LE PDU
 CHAMPS VERSION : 4 Bits identifiant la version du protocole COPS
(actuellement 0x1)
 DRAPEAU : 4 Bits définissant un jeu de code pour les drapeaux;
autrement ce champs est à O
 CODE OPERATION : codé 1 octet; définit le type d’operation
demandé (soit par le PDP ou le PEP) par le message. Ex : Decision,
requête, requête de suppression d’ état, keep- alive (permettant au
PEP et au PDP de vérifier le connexion == > bidirectinnel) …
 TYPE-CLIENT : sur 2 octets, il identifie l’ interprétation qu’il faut
donner à la politique du client. Selon les valeurs du champs l’on sait
s’ils sont assignés aux entreprises, réservées à l’IANA, réservées à
des usages privées d’entreprises ou allouées à la politique « first in
first out ». S’il s’agit d’un message keep - alive, ce champs est à 0.
 LONGUEUR DU MESSAGE : taille du message

25. Le protocole COPS : LE PDU
 OBJETS COPS encapsulent les infos échangées entre PEP/PDU.
COPS définit 16 objets utilisés par ses services pour definir
leur contexte
Identifie la classe
FORMAT SPECIFIQUE D’UN OBJECT d’information
LONGUEUR DE C-NUM C-TYPE
L’OBJET(2 octets)
CONTENU DE L’OBJET
Version de l’information
4 octets

26. Le protocole COPS : LE PDU
 OBJECTS COPS : on peut citer 3 les 16 objets tels que :
 HANDLE OBJECT : permettant d’identifier une requête d’un PEP
particulier. Elle est choisie par le PEP initiateur
 CONTEXTE OBJECT : spécifie le type d’ événements à l’origine de la
requête (contrôle d’admission, allocation de ressource, message en
sortie…)
 DECISION OBJECT : contient les decisions rendues par un PDP en
réponse à une requête d’un PEP en fonction du type de client. Le
champ C-TYPE définit les différentes catégories de decisions

27. Le protocole COPS : les services
 Le Protocole COPS définit 10 services pour spécifier le
dialogue PEP <==>PDP. Chaque service utilise un ou plusieurs
objets COPS prédéfinis.
 REQUEST
 DECISION
 REPORT STATE
 DELETE REQUEST
 SYNCHRONIZE STATE REQUEST
 CLIENT OPEN
 CLIENT CLOSE
 KEEP ALIVE
 SYNCHRONIZE STATE COMPLETE

28. Le protocole COPS : Fonctionnement
 OUVERTURE DE SESSION SECURISEE
PEP PDP PEP PDP
CLIENT-OPEN CLIENT-OPEN
CLIENT-ACCEPT CLIENT-ACCEPT
AUTENTIFICATION AUTENTIFICATION
CORRECTE INCORRECTE

29. Le protocole COPS : Fonctionnement
 OUVERTURE DE SESSION D’ECHANGE
PEP PDP PEP PDP
CLIENT-OPEN CLIENT-OPEN
CLIENT-ACCEPT CLIENT-ACCEPT
CONNEXION ACCEPTEE TYPE DE CLIENT NON
SUPPORTE

30. Le protocole COPS : Fonctionnement
 DEMANDE D’UNE DECISION DU PEP AU PDP
PEP PDP PEP PDP
REQUEST REQUEST
DECISION DECISION
REQUETE RECONNUE ERREUR DE TRAITEMENT

31. Le protocole COPS : Fonctionnement
 DEMANDE D’UNE DECISION DU PEP AU PDP
PEP PDP PEP PDP
keep – alive keep – alive
keep - alive keep – alive
Keep - alive client-close
¼ Timer<T attente<3/4 Timer T attente > Timer

32. V. SCENARIOS DE FONCTIONNEMENT

33. 4 : LIRE LES
POLITIQUES
3 : COPS-RSVP Req 4 ADMINISTRATEUR
PDP
PDP 5
6 : COPS-RSSVP Dec
1:
PEP ANNUAIRE DES
POLITIQUES
DEFINITION
DES
POLITIQUES
PEP
7 : RSVP Req
2 : RSSVP Req
Poste Client Poste Client
SCENARIO D’OUTSOURCING

34. IHM DE GESTION
ET DE CONTROLE
ADMINISTRATEUR
2
•Négociation de SLA 2
•Définition des 3
politiques
PDP
•Contrats 4 Annuaire
de
SLA politiques
SLS REQ
5
DEC
1 6
PIB PIB PIB PIB
PEP PEP PIB
PEP PEP PEP
Réseau Réseau
7 d accès Réseau de l’operateur DiffServ d accès
CLIENT
CLIENT

35. VI.Conclusion

36. La gestion par les politiques offre un cadre global de définition d’une
gestion de la qualité de service par la différenciation des usagers et
des services. Le cadre de travail d »fini offre un moyen de spécifier
différents scénarios de gestion pour implémenter des politiques
d’utilisation basées sur la QoS, la sécurité, ect. Il vise à définir des
composants de déploiement de politiques (PEP) et de prise de
décision (PDP), un protocole d’échange entre ces deux composants,
la relation contractuelle entre l’usager et le fournisseur de
communication (SLA) et l’annuaire LDAP offrant un moyen privilégié
de sauvegarde et d’extraction efficace de ces règles.
Bien que ces travaux soient bien avancés, il reste beaucoup de points
d’ombre (la sécurité, l’unification des modéles d’informations …)
malgré l’existance certains implémentations tel que QPM-COPS de
CISCO. Le sujet est tellement important qu’il est plus que certain
que des résultats rapides tant au niveau de l’IETF qu’au niveau des
constructeurs feront leur apparition dans les années venir.