• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Gestion Basee Sur Les Politiques
 

Gestion Basee Sur Les Politiques

on

  • 666 views

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

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

Statistics

Views

Total Views
666
Views on SlideShare
666
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Gestion Basee Sur Les Politiques Gestion Basee Sur Les Politiques Presentation Transcript

    • GESTION DES RESEAUX BASEE SUR LES POLITIQUES Présenté par Aliou NOKHO Emeric KAMLEU Alie Badara DIAGNE Mamadou DIOUF Djibril SAMBE
    • PLAN DE TRAVAILI. INTRODUCTIONII. ARCHITECTURE DE GESTION DES POLITIQUESIII. MODELE D ’INFORMATION DU SYSTÈME DE GE STION DE POLITIQUESIV. EXEMPLE DE PROTOCOLE DE MISE EN ŒUVRE DES GESTIONS DE POLITIQUES:COPSV. SCENARIOS DE FONCTIONNEMENTVI. CONCLUSION
    • I. INTRODUCTION (1/3)La complexité de la gestion des réseaux de nouvellesgénérations en termes de diversité de services, d’accès,des utilisateurs, etc., rend l’approche classique baséesur le modèle agent/gestionnaire extrêmementcompliquée à mettre en œuvre et à maintenir lorsquel’on veut traiter l’ensemble de ces aspects de manièreunifiée. En effet, dans l’approche classique, il estnécessaire de connaitre l’ensemble des équipements etdes modèles d’informations de gestion. Dès lors, dèsque l’on intègre un nouvel équipement ou unenouvelle activité de gestion, il est nécessaire derépercuter ces changements dans toute l’architecturede gestion.
    • I. INTRODUCTION (2/3)Pour palier à ces différentes contraintes del’approche classique de mise en place degestion du réseau, plusieurs solutions ont étéproposées par l’IETF(internet engineering taskforce) pour définir et introduire de nouvellesapproches de gestion à linstar de la gestionbasée sur les annuaires et les politiques. Notretravail s’intéressera sur cette dernièreapproche bien qu’elles soient étroitementliées.
    • I. INTRODUCTION (3/3)Une politique est un ensemble de règles quirégissent le fonctionnement global du réseau.L’administrateur de réseau définit ces politiquesen fonction des objectifs de l’entreprise. Celles-cipeuvent être diverses selon que l’entreprise estune compagnie ou un operateur. Lorsque lesobjectifs sont complexes, il est intéressant de lesdéfinir sous la forme d’une hiérarchie depolitiques, c’est-à-dire qu’une politique peut êtrecomposée d’autres politiques.
    • II. ARCHITECTURE DE GESTION PAR LES POLITIQUESLa 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.
    • 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.
    • 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.
    • II. ARCHITECTURE DE GESTION PAR LES POLITIQUES LE CADRE DE TARAVAIL POUR LA GESTION A BASE DE POLITIQUESAu 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 :
    • II. ARCHITECTURE DE GESTION PAR LES POLITIQUESLE CADRE DE TARAVAIL POUR LA GESTION ABASE DE POLITIQUES Outils de gestion des politiques PDP Annuaire des Politiques PEP LDPD
    • II. ARCHITECTURE DE GESTION PAR LES POLITIQUES LE CADRE DE TRAVAIL POUR LA GESTION A BASE DE POLITIQUESII. 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
    • 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
    • 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
    • III. MODELES D’INFORMATIONS DU SYSTÈME DE POLITIQUEAu 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.
    • III. MODELES D’INFORMATIONS DU SYSTÈME DE POLITIQUECelles-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.
    • III. MODELES D’INFORMATIONS DU SYSTÈME DE POLITIQUEExemple 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…
    • IV. EXEMPLE DE PROTOCOLE DE MISE EN ŒUVRE DES GESTIONS DE POLITIQUES:COPSCe 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.
    • 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
    • Le nœud de réseauLe 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 nœud de réseauLe 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.
    • Serveur de politiquesLe 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.
    • Le protocole COPSLe 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.
    • Le protocole COPS : le PDUVERSION DRAPEAU CODE TYPE- OPERATION CLIENT LONGUEUR DU MESSAGE OBJETS COPS (1…N) 4 OCTETS
    • 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
    • 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
    • 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
    • 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
    • Le protocole COPS : Fonctionnement OUVERTURE DE SESSION SECURISEE PEP PDP PEP PDP CLIENT-OPEN CLIENT-OPEN CLIENT-ACCEPT CLIENT-ACCEPT AUTENTIFICATION AUTENTIFICATION CORRECTE INCORRECTE
    • 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
    • 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
    • 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
    • V. SCENARIOS DE FONCTIONNEMENT
    • 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 ReqPoste Client Poste Client SCENARIO D’OUTSOURCING
    • 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èsCLIENT CLIENT
    • VI.Conclusion
    • 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.