Diplôme d'etudes Approfondies Réseaux de télécommunications

UNIVERSITE LIBANAISE (Faculté de Génie) UNIVERSITE SAINT-JOSEPH (Faculté d'ingénierie) Sous l'égide de l'agence Universitaire de la Francophonie AUF Diplôme d'etudes Approfondies Réseaux de télécommunications < Représentation sémantique des informations de Gestion des politiques> Par <CHRISTINE JARDAK> Encadré par : M. Maroun Chamoun Soutenance le 22-Décembre-2004 devant le jury composé de MM. Samir Tohmé Président Mohamad Zoaeter Membre Wajdi Najem Membre Imad Mougharbel Membre Nicolas Rouhana Membre Mahmoud Doughan Membre Maroun Chamoun Membre

Remerciements Je tiens à remercier Mr. Maroun CHAMOUN, le responsable de mon projet, pour son aide, son orientation, ses conseils et surtout son temps précieux, indispensables pour la bonne réalisation de ce projet. 2

SUJET La gestion des politiques repose sur l exécution d un ensemble de règles qui dictent les droits d accès aux ressources et qui permettent d établir un lien entre les profiles utilisateurs, les applications et les services demandés. Elle permet de résoudre les problèmes de sécurité en contrôlant l accès aux ressources, ainsi qu elle permet d assurer une qualité de service (QoS) par réservation de ressources suivant des classes de services différenciées. Pour pouvoir mettre en œuvre, il convient de définir une ou plusieurs politiques sur différents nœuds du réseau, sachant qu une politique n est que l ensemble de règles permettant d implémenter la qualité de service demandée, et donc la manière dont on va utiliser le réseau, notamment qui va faire quoi, et dans quelle condition. Dans ce cadre trois paramètres sont essentiels : l utilisateur, le service et le temps. L une des approches de politiques de mise en œuvre envisagée est COPS (Common Open Poilicy Services). COPS est un protocole qui va permettre aux routeurs et aux différents équipements du réseau d échanger des informations avec un serveur centralisé qui stocke l ensemble des politiques. Le modèle de politique utilisé s appuie sur les cinq éléments suivants : - Un répertoire de politiques qui contient l ensemble de règles définissant la façon Dont on va utiliser le réseau. - Un éditeur de politiques pour la définition des politiques - Le PDP (Policy Decision Point) : Application centralisée qui réalise le contrôle D admission en se basant sur les politiques d utilisation du réseau, l état du réseau et les messages de réservations des ressources. - Le PEP (Policy Enforcement Point) : Les routeurs qui sont responsables de la Mise en exécution et la vérification des décisions qui ont été prises par le PDP. - Le protocole COPS qui permet au PDP et au PEP de communiquer. 3

On peut définir l architecture globale de la politique sous COPS en reprenant ces cinq éléments : Edition Editeur de politique Répertoire de politiques Policy Decision Point (PDP) COPS Policy Enforcement Point (PEP) Notre approche consiste à définir des objets sémantiques en XML pour la définition et la représentation des informations et des règles de politiques de COPS. Travail demandé : 1. Etude du protocole COPS. 2. Etude des standards de la représentation sémantique (RDF, RDF schéma, ontologies, OWL, etc, ) 3. Conception et implémentation d un outil de définition des règles de politique. Ces règles de politiques doivent être définies en SWRL (Semantic Web Rule Language). 4. Définition d une Ontologie pour représenter la PIB (Policy Information Base). 5. Pour valider cette définition, il faudra intégrer l ontologie représentant la PIB, a la plateforme active à base de services Web (ASWA) pour la gestion de politique déjà développée a l ESIB. 4

SOMMAIRE PARTIE I CHAPITRE 1: PBN (Policy Based Networking ) p 7 CHAPITRE 2: COPS (Common Open Policy Service) p 11 CHAPITRE 3: COPS-PR (Common Open Policy Service-Provisioning) p 17 CHAPITRE 4: PIB (Policy Information Base). p 24 CHAPITRE 5: SPPI (Structure of Policy Provisioning Information)...p 28 PARTIE II CHAPITRE 1: Ontologie & OWL (Ontology Web Editor).p 35 CHAPITRE 2: Editeurs d Ontologie p 47 CHAPITRE 3: Ajout d un Plugin à Protégé.p 54 CHAPITRE 4: Implémentation du protocol COPS..p 62 CHAPITRE 5: OWL Rules Language (ORL)..p 68 Conclusion...p 78 Perspectives p 79 Références...p 80 5

PARTIE I 6

CHAPITRE 1 PBN (Policy Based Networking) 1-Définition : La gestion des politiques repose sur l exécution d un ensemble de règles qui Dictent les droits d accès aux ressources. L architecture PBN (Policy Based Networking), est une approche orientée gestion des politiques. 2-Objectif : Son objectif est de délivrer une architecture compréhensive qui permet de grouper tous les utilisateurs, les applications, et les informations politiques dans des actions politiques sur le réseau. Le but de PBN est de pouvoir forcer. Des politiques sur les nœuds du réseau et de pouvoir gérer le système Globalement. 3-Architecture de base : Un système PBN est formé des composants suivants : -Policy management tool : Son travail est d aider le Network Manager a construire et a déployer des politiques, de même il fait du monitoring pour l environnement des politiques. Le policy management tool peut être vu comme une interface entre le Network Manager et le Policy repository -Policy repository : Est un environnement de stockage dans lequel on dépose les politiques, leurs conditions, leurs actions,.en d autres mots c est une base de données. -Policy Decision Point (PDP) : Est une entité logique qui produit les politiques de décisions pour elle même ou bien pour les autres éléments du réseau qui demandent de telles décisions, le PDP peut être par exemple un serveur. -Policy Enforcement Point (PEP) : Es tune entité logique qui reçoit les politiques de décisions du PDP et les appliqués, le PEP a la capacité de prendre une décision de politique 7

locale via LPDP, qui est un PDP Local mais comme le PDP est le centre de décision, donc le PEP doit lui communiquer cette décision locale. Nous illustrons cette architecture avec tous ses éléments par ce schema: Policy management tool Network Manager P E P COPS PDP P E P COPS Policy Repository 4-Fonctionnement : COPS est un protocole de signalisation de type requette / réponse basé sur TCP. En effet c est le client PEP qui est responsable d initier une connection TCP avec PDP. Une fois cette connexion est établie le PEP commence à envoyer des requêtes de configurations au PDP et donc il reçoit de la part du PDP des contextes de politiques, donc des configurations qu il essaie d appliquer. Ainsi le PDP peut configurer les PEPs, de même les PEPs peuvent envoyer des rapports au PDP pour lui notifier de leurs configurations, et pour lui reprocher s ils ont pu installer la configuration reçue ou pas. Tous ces messages entre les PEPs et le PDP sont transportés par le protocole COPS qu on détaillera dans le chapitre suivant. 8

5-Difficulté de PBN : Après avoir compris l architecture PBN, il est nécessaire de savoir que la difficulté de cette Réside dans la translation des politiques, c.a.d la transformation d une politique, d une forme de représentation a une autre forme de représentation qui peut être comprise par les PEP, il sera nécessaire donc de convertir les entrées d une PIB qui sont des named data structure a un format de ligne de commande. C est ce qu on appelle mapping des politiques qui est très important. 6-Exemples d utilisation d une architecture PBN : 6.1-Exemple 1 : Contrôle d admission Cet exemple concerne les schémas de contrôle d admission, ces schémas sont responsables d assurer que les ressources demandées sont disponibles. De plus ces schémas doivent avoir la possibilité de déployer des contraintes temporelles,d identification et de permission. La Policy Based Admission control, a la possibilité de forcer des règles qui ont des dépendances temporelles ex : Un groupe d utilisateurs peut être permis de faire des réservations seulement Durant les OFF-PEAK HOURS, de même la PBAC, devra supporter les politiques qui prennent en compte l identité de l utilisateur qui demande un certain service ou bien une certaine ressource ex : Une réservation RSVP peut être acceptée ou rejetée dépendamment de l ID du user et Ses droits. 6.2-Exemple 2 : QoS avec Diffserv La qualité de service permet d assurer des services réseau qui seront conformes avec les paramètres spécifiés dans le SLA (Service Level Agreement). La QoS est caractérisée par le délai, le dépit, taux de pertes, Avec Diffserv on distingue des classes, et chaque classe doit être traitée d une manière différente de façon à assurer la QoS demandée pour chaque classe, pour faire ceci on pourra proposer une architecture PBN, ou il y a des politiques qui spécifient pour chaque classe ce qu on doit faire. 9

7-Nouvelle Extension de l architecture PBN : La plupart des systèmes appliquent l architecture PBN pour contrôler les équipements de périphérie du réseau ex : routeurs, coupes-feux, passerelles, Les futurs systèmes vont considérer les terminaux des utilisateurs comme étant les PEPs, et cela pour assurer une classification plus fine d un coté et pour traiter les problèmes de classification qui peuvent augmenter lorsque le trafic de l utilisateur sort crypté du terminal. Avec cette solution on résoud deux problèmes : 1-problèmes de congestion du réseau 2-problèmes d adaptation de la QoS Pour pouvoir évoluer vers cette nouvelle extension, il faut quand même étendre le protocole COPS pour pouvoir supporter de nouveaux Client-Type qui permettent d interfacer directement l utilisateur avec le PDP, la nouvelle extension du protocole COPS sera COPS-SLS ( Service Level Specification) le schéma de la nouvelle Architecture sera donc : Policy management tool Network Manager PEP COPS-SLS PDP COPS-SLS PEP Policy Repository 10

CHAPITRE 2 COPS (Common Open Policy Service) 1-Généralités : Le Groupe de travail RAP de l IETF, a développé COPS en tant que protocole de politique pour un usage dans des systèmes de gestion de politique réseau. COPS présente une approche révolutionnaire pour la gestion proactive d équipement de réseau. Il a été développé en comparaison aux protocoles traditionnels de gestion de réseau tel que SNMP, lequel s est avéré incapable de supporter efficacement une gestion de politique réseau. La pile du protocole COPS peut être conceptuellement divisée en 3 couches distinctes : le protocole de base, les directives d usage du type client, et la représentation de données de politique. Ces trois couches ainsi que beaucoup d autres avantages offerts par COPS par rapport à des protocoles traditionnels des gestions de réseau, permettent à COPS de s adapter tout à fait à l environnement de gestion de politique réseau. 2-Les objectifs : Le but du protocole COPS est un protocole de requêtes/réponses utiliser pour échanger des informations de politique entre un point de décision de politique (PDP) et ses clients, autrement dit les points de renforcement de politique (PEPs). Le PEP est un routeur ou tout autre équipement qui gère du trafic IP et établit un contrôle d admission basé sur une politique pour des flux d information. Le PDP, qui a une vue sur l ensemble de la zone du réseau (par exemple un système autonome) a travers ses PEPs, décide s il doit ou non accepter l entrée d un flux d informations spécifiques. On suppose qu il existe au moins un PDP par domaine. Ce protocole à deux modèles de gestion de politique qui sont: 11

L Outsourcing où l utilisateur et l administrateur du réseau ne communiquent pas; le PEP envoie une requête à son PDP qui lui autorise ou non l établissement de la connexion. Le protocole utilisé pour gérer la QoS dans le modèle d outsourcing est RSVP. Le provisioning où un contrat, le SLA (Service Level Agreement), est établi entre l utilisateur et l administrateur du réseau pour définir la qualité de service attribuée à l utilisateur. Les politiques définies dans ce contrat sont saisies par l administrateur grâce à une console et sont alors enregistrées dans la Policy Repository qui est le serveur où sont stockées les règles de gestion de politiques. Le provisioning est souvent associé à la technique Diffserv dans laquelle les flots sont classifiés en différentes classes. 3-Caractéristiques : Les principales caractéristiques du protocole COPS sont les suivantes : 1. le protocole utilise un modèle client/serveur ou le PEP envoie des requêtes, Des mises a jour, et des annulations au PDP. Ce dernier transmet à son tour les décisions au PEP. 2. COPS utilise le protocole TCP comme protocole de transport pour un échange fiable des messages entre le serveur de politique et ses clients, sans Nécessiter aucun mécanisme supplémentaire. 3. Le protocole est extensible grâce à la puissance de sa conception et peut supporter des informations spécifiques venants de divers clients sans que de nouvelles modifications lui soient apportées. Il a été pour l administration, la Configuration, et l exécution des règles de politiques qu elles soient signalées «Outsourcing» ou fournies «provisioning». Le protocole peut être étendu pour l administration d une grande variété de protocoles de signalisation ainsi que la configuration des équipements réseau. 4. Le protocole fournit un niveau de sécurité en assurant une authentification et une intégrité des messages. Eventuellement, COPS peut utiliser certains protocoles existants pour la sécurité comme IPSEC pour authentifier et sécuriser le canal de communication entre PDP et PEP. 12

4- L architecture de la gestion des politiques : Cette architecture se résume par le schéma suivant PDP (Policy Decision Point) Le PDP, que l on peut aussi appeler serveur de politiques, est le point central qui doit décider des politiques à appliquer dans le réseau. Il est défini comme une entité logique prenant des décisions politiques pour elle-même ou pour d autres éléments réseau qui demandent ses décisions Le PDP prend des décisions à sa propre initiative ou en réponse à une requête faite par un PEP; pour ce faire, il consulte le Policy Repository. Le PDP récupère les politiques du Policy Repository grâce au protocole LDAP. Une fois qu il a localisé et pris les règles, il vérifie leur condition d application et les transforme en un format adapté compréhensible par les PEPs (PIB: Policy Information Base ou MIB: Management Information Base). PEP (Policy Enforcement Point) Le PEP est un nœud du réseau qui peut être de différents types: routeur, firewall, switch ou une machine cliente. Il dépend d un PDP duquel il prend les politiques qu il doit obligatoirement appliquer. Il doit aussi faire la correspondance entre la représentation externe (PIB ou MIB) et la configuration interne des équipements du réseau. 13

Le PEP doit donc être facilement accessible et paramétrable par le PDP qui doit pouvoir facilement le configurer; il doit rendre compte au PDP de l exécution des décisions, des politiques installées chez lui et des éventuelles modifications, Affin d envoyer une requête au PDP et de pouvoir en recevoir la réponse, le PEP établit une connexion TCP avec lui. 5-Encapsulation des protocoles : 6-La structure des messages COPS : a- Entête COPS: Un message COPS encapsule une série d objets. L entête du message définit principalement le type de client, le type d opération concernée par le message et la longueur totale de celui-ci. L interprétation de tous les objets encapsulés dans un message est relative au champ «Client-Type». Signification de chaque champ : -Version : Indique la version du protocole COPS, la version courante est 1. -reserved : Ce champ est réservé, et doit être mis à 0. -S : Sollicited Message Flag, il est mis a «set»quand le message est Sollicité par un autre message COPS. -Opcode : utilisé pour identifier l opération effectuée, le tableau ci-dessous Indique toutes les valeurs que peur prendre ce champ 14

-Client type : Identifie le client de politique.l interprétation de tous les objets encapsulés est liée à cet identificateur, le tableau ci-dessous indique les valeurs que peut prendre ce champ -Message length : La taille du message en octets, en prenant compte de l entête et tous les objets encapsulés, les messages COPs doivent être alignés sur des intervals de 4 octets. -Data : Contient tous les objets. b- Objets COPS : Tous les objets encapsulés sont constitués d une entête au format identique Suivi du contenu de l objet formé par un ou plusieurs mots de 32 bits 15

Signification des champs : -Length:longueur de l objet en octet -Class : classe de l objet, défini dans le tableau ci-dessus : -Subclass : un champ sur 8 bits. 16

CHAPITRE 3 COPS-PR 1-Définition : COPS-PR est le client-type du protocole COPS crée pour faire la gestion des politiques, il peut être utilisé pour assurer la qualité de service de Diffserv,pourtant l utilisation de COPS-PR n est pas limitée à Diffserv seulement. Les politiques de Diffserv se trouvent dans le SLA, donc lorsque COPS est utilisé pour distribuer ces politiques.un PDP généralement va distribuer des décisions lorsque les SLAs sont mis à jour. Le Client type COPS PR est désigné pour ce travail. 2-Pourquoi COPS-PR pour la gestion des politiques? -Cause 1 : COPS-PR permet d assurer un transport efficace d attributs, des transactions de donnée importante, et permet aussi de renvoyer des rapports d erreurs. -Cause 2 : il y a une seule connexion entre le client et le serveur dans chaque zone De contrôle de politique, qui est identifiée par le client-type, elle garantie donc qu un seul serveur fait la mise a jour pour une configuration particulière. -Cause 3 : il est défini comme étant un real- time event-driven communications Mechanism qui ne demande pas de polling entre PEP et PDP. 17

3-Les messages de COPS-PR entre PEP et PDP : Client Open Client Accept Request PIB Decision Usollicited Decision PIB Report State Client Close PEP PDP -Client Open : Ce message est transmis par le PEP pour demander une connexion en lui indiquant le Type du client, ex : COPS-PR, COPS-RSVP. Ce message contient obligatoirement l identité du PEP dans l objet PEPID en plus une entête commune. Les champs entre crochets sont optionnels. Format de ce message : <Client-Open> : : = <CommonHeader> <PEPID> [<ClientSI>] [<LastPDPAddr>] -Client Accept : Ce message est renvoyé au PEP par le PDP pour confirmer la connexion. Par l objet Keep-Alive Timer le PDP indique au PEP l intervalle de temps maximum a respecter entre deux messages d indication de présence. 18

Format de ce message : <Client-Accept> : : =<CommonHeader> <KA Timer> [<ACCT Timer>] [Integrity] Si le PDP refuse la connexion il renvoie au PEP le message Client-Close. La raison de refus est mentionnée dans l objet ERROR. <Client- Close>: : = <CommonHeader> <Error> [<PDPRedirAddr>][Integrity] -Request : Lorsque la connexion est ouverte le PEP peut ainsi envoyer une requête au PDP, contenant des informations internes concernant le PEP ex : taille maximale de ces queues,sa capacité, des indications concernant sa configuration s il y en a une, une requête est identifiée par un numéro Client Handle, un client peut envoyer plusieurs requêtes de configurations chacune caractérisée par son Client handle, donc il pourra recevoir plusieurs contextes de configurations, mais un seule peut être actif en même temps. Ce message de requête sert à deux buts : 1-C est une demande de recette pour le PDP pourqu il envoie au PEP une configuration qui lui est convenable. 2-cette requête de configuration permet d ouvrir un canal qui permet au PDP d envoyer d une manière asynchrone au PEP, des décisions de politiques et cela lorsqu il décide que c est nécessaire, ces décisions peuvent être une mise à jour ou bien une nouvelle configuration. Format de ce message: <Request Message> : : = <Common Header><Client Handle> <Context> [<IN-Int>] [<OUT-Int>] [LPDPDecision(s)] [Integrity] < LPDPDecision (s) : : = [<Context>] [<LPDPDecision : Flags>] [< LPDPDecision : Stateless Data>] [< LPDPDecision : Replacement Data>] [< LPDPDecision : ClientSI Data>] [< LPDPDecision : Named Data>] 19

-Decision : En réponse au message de requêtes le PDP va étudier le contenu de la requête et aller chercher de la PIB, les politiques conformes au PEP, et donc il va les envoyer dans le message de décision qui porte le même client handle que celui dans la requête. Le PDP peut quand même envoyer des messages de décisions qui ne sont pas sollicités par un message de requête, pour faire une mise à jour de la configuration du PEP. A l aide d un message de décision le PDP peut aussi obliger un PEP de lui envoyer un message de requête, c.a.d ouvrir un nouveau contexte, il peut quand même l obliger à effacer un contexte existent. Ce message peut contenir plusieurs décisions, c.a.d il peut contenir un ensemble de règles qui permettent de supprimer ou bien d ajouter des politiques, il doit être traité par le PEP comme étant une seule transaction, en d autres termes il suffit que le PEP ne supportera une décision pour qu il revienne à sa configuration initiale et ne prenne pas compte de cette nouvelle configuration. Format de ce message : <Decision Message> : : = <CommonHeader> <Client Handle> <Decision (s) <Error> [Integrity] -Report State : Lorsque la décision a été reçue par le PEP, celui-ci utilise le message Report State, pour communiquer au PDP le résultat de la décision, ce message peut être : 1-Success : Le PEP a pu installer toutes les décisions de politiques reçues du PDP dans sa propre PIB 2-Failure : Si une décision a échouer donc le PEP ne prend pas compte de cette nouvelle configuration donc il envoie un report message en indiquant quelle décision a causé l erreur. De même a n importe quel moment le PEP peut envoyer au PDP l état courant de n importe quel contexte dans le message Report-State, c est ce qu on appelle Accounting. Format de ce message : <Report-State> : : = <CommonHeader> <Client Handle> <Report-Type> -Client-Close : Ce message est utilise pour la fermeture de la connexion. 20

4-Format de l objet dans COPS-PR : Length S-Num S-Type EEntE Entier de EE Entier de 32 bits Explication des champs : -Length (2 octets) : indique la longueur de l objet en octet -S-Num (1 octet) : définit l objet ex : PRID, PPRID, -S-Type (1 octet) : décrit le codage spécifique utilisé pour cet objet ex: BER, 5-Les objets de COPS-PR : 5.1-Provisioning Instance Identifier: PRID Il a: S-Num = 1 (Complete PRID), S-Type = 1 (BER), Length = variable. Cet objet est utilisé pour transporter l identificateur d une Provisioning Instance. Cet identificateur est codé en suivant les règles de codage pour le OID (object Identifier) en SNMP, spécifiquemnet il est code en utilisant TLV, Type/Longueur/Valeur. 21

5.2-Prefix Provisioning Instance Identifier: PPRID Il a : S-Num = 2 (Prefix PRID), S-Type = 1 (BER), Length = variable. C est un identificateur de la PRC, on l utilise dans certaines décisions comme les Décisions de remove, si on veut éliminer toutes les PRI d une PRC on lieu de les Enlever chacune en utilisant son PRID, on les enlève toutes ensemble en utilisant Le PPRID de la PRC a laquelle elles appartiennent. 5.3-Encoding Provisioning Instance Data: EPD Il a: S-Num = 3 (EPD), S-Type = 1 (BER), Length = variable. Cet objet est utilisé pour transporter la valeur code d une PRI, c. a.d la valeur de Chaque attribut de cette PRI est codé en appliquant TLV, ensuite on assemble Toutes les valeurs des attributs, en commencant par l attribut ayant le OID le Plus petit arrivant a celui ayant le OID le plus grand. L ensemble forme le EPD 5.4-Global Provisioning Error Object: GPERR Il a : S-Num = 4 (GPERR), S-Type = 1 (for BER), Length = 8. Cet objet est utilisé pour communiquer des erreurs générales exemple : -availmemlow : la taille de la mémoire valable est petite. -maxmsgsizeexceeded: on a dépassé la taille maximale du message -unknownerror -unknowncopsprobject : l objet COPS-PR indiqué est n est pas connu. 22

5.5-PRC Class Provisioning Error Object: CPERR Il a : S-Num = 5 (CPERR), S-Type = 1 (for BER), Length = 8. Il a pour rôle de communiquer de erreurs qui sont en relations avec des PRCs Spécifiques. Exemple de ces erreurs: -prispaceexhausted -attrvalueinvalid : On ne peut plus installer d instances dans cette classe. : la valeur de cet attribut n est pas Valide. -attrvaluesuplimited : la valeur spécifiée pour cet attribut est légale mais n est pas supportée par la Machine. -attrmaxlengthexceeded: la longueur de la valeur de cet attribut dépasse la limite. 5.6-Error PRID Object : ErrorPRID Il a : S-Num = 6 (ErrorPRID), S-Type = 1 (BER), Length = variable. Cet objet est utilisé pour transporter le PRID de l instance qui a causé une erreur D installation. 23

CHAPITRE 4 PIB (Policy Information Base) 1-Définition : La PIB est l équivalent de la MIB pour la gestion de QoS. C est un modèle permettant de décrire en ASN.1 les politiques de gestion et leur format d échange entre le PEP et le PDP. La PIB est utilisée par COPS dans le modèle de provisioning (COPS-PR) où les données échangées sont des politiques qui sont soit envoyées par le PEP pour notifier le PDP, soit imposées par le PDP au PEP sans requête de la part de ce dernier. -La représentation logique de la PIB est une structure arborescente où les branches représentent les classes de provisioning (PRC) et les feuilles représentent les instances de provisioning (PRI) comme ci-dessous: PIB PRC PRI PRI PRC PRI PRI PRI Dans la PIB, toute information est représentée sous forme d une table ou PRC (Provisioning Class) qui est identifiée par un identificateur appelé PPRID (Prefix PRID) ayant un ensemble d attributs et dont les entrées (lignes) sont des PRI (Provisioning Instance), qui sont des instances de la PRC, chaque PRI est identifiée par un identificateur unique appelé PRID (Provisioning Instance Identifier). -La représentation physique de la PIB est une table ou les entrées de la table sont les PRC et chaque PRC contient plusieurs PRI : 24

PRC 1 Attribut 1 Attribut 2 Attribut 3 PRI 1 PRI 2 PRC 2 Attribut 1 Attribut 2 PRI 1 PRI 2 PRI 3 2-Règles de modification ou d extension d une PIB : 2.1-On peut ajouter une PRC a une PIB ou bien supprimer une : Si on a ajouté une nouvelle PRC a une PIB donc celle-la va contenir de nouvelles instances, donc si le PEP utilise cette nouvelle version de la PIB et le PDP utilise l ancienne version (qui ne contient pas cette nouvelle PRC) donc le PEP n a aucune chance de recevoir des PRI de la part du PDP, concernant cette nouvelle PRC, donc il n y a pas de problème. Si le PDP utilise la nouvelle version de la PIB, et le PDP a toujours l ancienne version donc,il se peut que le PDP envoi des PRI de la nouvelle PRC que le PEP ne connaît pas, donc le PEP répond au PDP par une erreur. Si on a enlevé une PRC de la PIB, donc cette nouvelle PIB va contenir une PRC en moins par rapport à l ancienne PIB. Si le PDP a l ancienne version de PIB et le PEP possède la 25

nouvelle, donc le PEP va ignorer les PRI de la PRC enlevée, dans ce cas le PDP ne les envoie pas pour lutter contre les erreurs. 2.2- Un attribut peut être enlevé ou bien supprimé d une PRC : -enlever : Dans COPS-PR les attributs d une PRC sont identifiés par des numéros séquencés. Donc lorsqu on enlève un attribut si le PDP utilise le codage BER, il doit donc envoyer une valeur en ASN.1 pour le type correct, ou une valeur NULL, donc le PEP qui reçoit la valeur NULL va mettre l attribut convenable a sa valeur en défaut, s il n a pas de valeur en défaut il doit envoyer une erreur au PDP. -ajouter : L ajout d un attribut doit être fait après les attributs existants. Si un PEP reçoit une PRI ayant plus d attribut que prévu comme il ignore les attributs en excès donc il envoie un warning au PDP. Alors que s il reçoit Une PRI avec un nombre d attribut inférieur que le nombre prévu donc il assume de mettre les attributs en excès a leur valeur par défaut,et si ces derniers n ont pas de valeur par défaut donc il envoie une erreur pour le PDP. 2.3-Une PRC peut être étendu en définissant une autre PRC la dedans. 3- Les opérations sur une PRI : Une PRI contient une valeur pour chaque attribut défini dans la PRC ou elle se trouve cette PRI comme on a déjà dit à un identificateur qui est le PRID et qui est unique pour le client (qui dans notre cas est le COPS-PR) et pour le contexte existant sur le PEP. Les opérations sont les suivantes : 26

1. Install : cette opération crée ou bien met à jour une PRI, elle a besoin de deux Paramètres : a-prid, pour nommer la PRI b-epd (Encoding Provisioning Instance Data), cet objet comme on le verra par la suite permet de donner les valeurs des attributs. 2. Remove : cette opération permet d enlever des une PRI d une PRC, elle demande un seul paramètre qui est le PRID pour enlever une PRI ou bien le PPRID pour enlever une PRC. N.B : Si on essaie d enlever un PRID ou bien un PPRID qui n existe pas cela devra envoyer un warning au PDP. 27

CHAPITRE 5 SPPI (Structure of Policy Provisioning Information) La structure de la PIB est définie dans le RFC 3159: SPPI. Cette structure est écrite en ASN1 et elle est basée sur la définition du SMI et de la MIB du protocole SNMP. Dans SPPI, il y a la définition de cinq macros nécessaires à la description d une PIB: - Module-Identity - Object-Identity - Object-Type - Object-Group - Module-Compliance Module-Identity Cette macro est utilisée pour définir un module de la PIB, c est à dire un élément qui regroupe toutes les tables (PRC) d une même catégorie: par exemple, toutes les tables concernant le filtrage se trouvent dans un même module, celles concernant la DiffServ dans un autre. La définition de cette macro est la suivante: MODULE-IDENTITY MACRO ::= TYPE NOTATION ::= SubjectPart -- new "LAST-UPDATED" value(update ExtUTCTime) "ORGANIZATION" Text "CONTACT-INFO" Text "DESCRIPTION" Text RevisionPart VALUE NOTATION ::= value(value OBJECT IDENTIFIER) 28

La notion la plus importante de ce module est celle de SubjectPart qui contient les différentes catégories de données décrites dans cette PIB; une catégorie est liée à un Client Type qui est représenté par le même identificateur dans le protocole COPS. Chaque message COPS contient un Client Type dont la valeur permet de définir l instanciation d un ensemble de politiques. Object-Identity Cette macro est utilisé dans les modules de la PIB affin de définir des informations concernant la déclaration d un Object Identifier. La définition de cette macro est la suivante: OBJECT-IDENTITY MACRO ::= TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(value OBJECT IDENTIFIER) Dans cette macro, Status ne peut prendre qu une de ces trois valeurs: current, deprecated et obsolete. ReferPart spécifie une référence (RFC par exemple) Object-Type Cette macro sert à déclarer une table, un attribut ou une entrée. Il est utile de rappeler que tous les attributs définis dans SPPI se trouvent dans une table, la PRC. Chaque PRI ou instance de PRC a donc le même ensemble d attributs. La définition de cette macro est la suivante: OBJECT-TYPE MACRO ::= TYPE NOTATION ::= "SYNTAX" Syntax UnitsPart 29