Guy Pujolle - Accueil - Librairie Eyrolles · Les opérateurs de télécommunications et les gestionnaires de réseau souhaitent ... rel, soit des règles déjà préparées par l’opérateur

Guy Pujolle Avec la contribution de Olivier Salvatori

© Groupe Eyrolles, 2002

ISBN : 2-212-11086-3

833

CHAPITRE

30La gestion et le contrôle par politique

Les opérateurs de télécommunications et les gestionnaires de réseau souhaitentdepuis de nombreuses années automatiser le processus de configuration des nœuds etdes équipements réseau. Cette automatisation a pour but à la fois de contrôler les fluxd’information qui transitent dans ces nœuds et de gérer plus facilement les équipe-ments réseau. De là est née la gestion par politique, à laquelle on peut ajouter lecontrôle, qui en fait partie de façon intrinsèque. La terminologie anglo-saxonne cor-respondante est PBM (Policy-Based Management). Le mot policy est traduit dans celivre par politique, mais on aurait aussi bien pu choisir règle.

Le propos de ce chapitre est de présenter ce nouveau paradigme de réseau, géré etcontrôlé par l’intermédiaire de politiques. Nous commencerons par introduire lespolitiques puis détaillerons l’architecture associée au protocole de signalisation utilisédans cet environnement.

LES POLITIQUESUne politique s’exprime sous la forme « si condition alors action ». Par exemple, « sil’application est de type parole téléphonique, alors mettre les paquets en priorité Pre-mium ». Dans cette section, nous allons dans un premier temps nous intéresser à ladéfinition syntaxique et sémantique d’une politique. Ensuite, nous examinerons endétail la description des politiques et leur utilisation pour le contrôle, puis nous termi-nerons par le protocole de signalisation permettant de transporter les paramètres despolitiques et les différentes solutions pour mettre en œuvre le contrôle par politique.

Une politique peut se définir à différents niveaux. Le niveau le plus haut correspond àcelui de l’utilisateur, la détermination d’une politique s’effectuant par une discussionentre l’utilisateur et l’opérateur. On utilise pour cette discussion soit le langage natu-rel, soit des règles déjà préparées par l’opérateur du réseau. Dans ce derniers cas,l’utilisateur ne peut que choisir parmi ces règles la politique qu’il souhaite voir appli-quer. On parle alors de politique définie au niveau business. Cette politique doit êtretraduite dans un langage de niveau réseau permettant de déterminer le protocoleréseau de gestion de la qualité de service et son paramétrage. Enfin, il faut traduire celangage de niveau réseau en un langage de bas niveau correspondant à la programma-tion des nœuds du réseau, ce que l’on peut appeler la configuration du nœud.


Partie X • Le contrôle et la gestion

834

Ces différents niveaux de langage (niveau business, niveau réseau, niveau configura-tion) sont pris en charge par un groupe de travail de l’IETF (Internet Engineering TaskForce) appelé Policy. Le modèle retenu provient d’un autre groupe de travail, leDMTF (Distributed Management Task Force) et porte le nom de CIM (CommonInformation Model). Les extensions sont aujourd’hui développées conjointement parles deux groupes de travail.

L’objectif de ce travail de normalisation des modèles d’information liés aux différentsniveaux de langage est d’obtenir un modèle général qui puisse se décliner en modèlesd’information par domaine, ainsi qu’une représentation indépendante des équipe-ments et des implémentations. La figure 30.1 illustre le modèle le plus général possi-ble à partir du modèle de base.

Si l’on ne se préoccupe que de la branche QoS, ou qualité de service, la structure desmodèles successifs permet de passer de la définition générale d’une politique de qua-lité de service à la configuration d’un routeur.

La figure 30.2 illustre la succession de modèles allant vers de moins en moins d’abs-traction et s’approchant de la description d’une configuration. Les sigles seront expli-qués dans la suite de ce chapitre.

PCIM (Policy Core Information Model)

PCIM (Policy Core Information Model) définit le modèle de description des politi-ques, quel que soit leur domaine d’application. Le réseau est considéré comme unemachine à états, c’est-à-dire un système qui ne peut prendre que des états définis àl’avance. Les politiques servent dès lors à contrôler les changements d’état en identi-fiant l’état courant et en définissant les transitions possibles.

Le modèle est fondé sur deux hiérarchies de classes, les classes structurelles, qui for-ment les éléments de base des politiques, et les classes d’association, qui déterminentles relations entre les éléments. Les politiques forment un ensemble de conditionsvraies ou fausses qui peuvent être composées pour réaliser une politique plus complexe.

FIGURE 30.1 • La structure du modèle CIM


Chapitre 30 • La gestion et le contrôle par politique

835

Ces politiques forment à leur tour un ensemble d’actions associées aux conditions quimodifient la configuration d’un ou de plusieurs éléments et qui introduisent des ordresd’exécution, comme la priorité des flots ou l’ordonnancement des paquets dans leréseau.

PCIMe (PCIM extension) a pour fonction de rendre le modèle PCIM plus flexible enpermettant aux différents domaines d’homogénéiser leurs concepts. Les principalesextensions concernent une meilleure gestion des priorités, l’ajout de variables et devaleurs, la définition de variables générales, l’ajout de règles simplifiées fondées surles variables, la possibilité d’avoir des règles conditionnées par d’autres règles, lacondition de filtrage de paquets IP à base de conditions, etc.

QPIM (QoS Policy Information Model)

Le rôle de QPIM (QoS Policy Information Model) est de fournir un format standardpour les politiques de QoS en intégrant les environnements IntServ et DiffServ, touten restant indépendant des protocoles d’accès, des méthodes de stockage et des tech-niques de contrôle de QoS (files d’attente, etc.). Enfin, QPIM doit faciliter une repré-sentation formelle de règles abstraites humaines

Les actions possibles sur la définition de la QoS sont le classement par catégorie,l’adéquation par rapport aux fonctionnalités de RSVP, comme la modification de cer-tains paramètres de RSVP, l’acceptation ou non d’une requête et la conformité aumodèle COPS-RSVP, et enfin les actions liées aux politiques de provisioning, commele marquage, le lissage, la perte de paquets, l’ordonnancement, etc. D’autres exten-sions ont été ajoutées, notamment dix-sept variables liées à RSVP, ainsi que la défini-tion formelle de profils de trafic pour DiffServ et IntServ.

FIGURE 30.2 • La structure des modèles associés à la QOS



836

QDDIM (QoS Device Datapath Information Model)

Le modèle QDDIM permet de s’approcher de la configuration des routeurs en éten-dant QPIM, qui définit des actions sur les paquets, en définissant des actions sur leséquipements tout en restant indépendant des implémentations. Le rôle de QDDIM estde permettre de programmer un routeur ou un équipement réseau, indépendammentde l’équipementier qui le commercialise. Pour cela, QDDIM utilise une syntaxe géné-rale permettant de décrire précisément l’action que doit apporter la politique à appli-quer sur les composants de l’équipement réseau.

L’ARCHITECTURE D’UN CONTRÔLE PAR POLITIQUELe contrôle par politique implique plusieurs composants illustrés à la figure 30.3. Lesnœuds du réseau prennent le nom de PEP (Policy Enforcement Point). Les politiquesy sont appliquées pour gérer le flux des utilisateurs. Le PDP (Policy Decision Point)est le point qui prend les décisions et choisit les politiques à appliquer aux PEP. Lacommunication entre le PEP et le PDP s’effectue par le protocole COPS (CommonOpen Policy Server). Le système comporte également une console utilisateur, quicontient des outils de gestion des politiques. Ces derniers permettent notammentd’entrer les politiques dans une base de données, nommée policy repository, quientrepose les règles de politique que le PDP vient rechercher pour les appliquer auxnœuds du réseau.

FIGURE 30.3 • L’architecture d’un système géré par politique



837

Des variantes de ce schéma de base peuvent inclure plusieurs PDP susceptibles degérer un même nœud de transfert du réseau. Dans ce cas, les PDP ont des rôles diffé-rents, comme nous le verrons par la suite. Une autre variante correspond à unedécentralisation des fonctions du PDP dans des PDP locaux, appelés LPDP (LocalPolicy Decision Point). En règle générale, un seul PDP gère un domaine administra-tif, et les règles de politique sont communes à la configuration de l’ensemble desnœuds du domaine.

Un problème de cohérence se pose lorsque le client émetteur et le client récepteur nese trouvent pas dans le même domaine administratif. Dans ce cas, les PDP des deuxdomaines doivent négocier pour se mettre d’accord sur les règles de politique à adop-ter pour que la communication se déroule de bout en bout avec la qualité voulue.Ce cas est illustré à la figure 30.4.

Le PDP (Policy Decision Point)

Le PDP est défini comme une entité logique prenant des décisions politiques pourelle-même ou pour d’autres éléments réseau qui demandent ses décisions. Le PDP,que l’on peut aussi appeler serveur de politiques, est donc le point central qui doitdécider des politiques à appliquer dans le réseau. Le PDP est en quelque sorte unorgane de décision qui recherche les informations dont il a besoin dans de nombreuxserveurs qui communiquent directement avec lui de façon à prendre une décision. Cesserveurs peuvent être locaux, ce qui est le cas le plus général, mais ils peuvent aussiêtre distants.

La figure 30.5 illustre un PDP et ses serveurs principaux.

Les principaux serveurs sont, dans l’ordre :

• Le policy repository, dans lequel le PDP vient rechercher les règles de politique.Cette mémoire communique avec le PDP par le protocole LDAP, ce qui expliqueson nom de serveur LDAP.

FIGURE 30.4 • L’architecture de gestion par politique sur une interconnexion de deux domaines administratifs



838

• Un bandwidth broker, qui gère la bande passante disponible dans le réseau. Ce ser-veur de bande passante connaît la topologie et les caractéristiques du réseau, ce quilui permet de distribuer les ressources du réseau à bon escient.

• Un serveur de gestion de la sécurité au moment de la connexion, qui est générale-ment un serveur AAA (Authentication, Autorization and Accounting). Ce serveurpeut également gérer la sécurité du transport de l’information sur les supports phy-siques.

• Un serveur de mobilité, qui peut être apte à gérer la continuité de la qualité de service.

• Un serveur de facturation, qui se révélera essentiel dans les prochains réseaux Inter-net qui délivreront de la qualité de service.

Il peut exister des serveurs complémentaires, comme la PIB (Policy InformationBase), qui garde en mémoire les modèles informationnels qui peuvent être utiliséspour représenter une politique sous une syntaxe particulière. D’autres serveurs serévéleront sûrement très importants à l’avenir, comme le serveur de métrologie et detuning, qui doit être capable de vérifier que les ressources qui ont été mises à la dispo-sition d’un utilisateur l’ont bien été effectivement.

FIGURE 30.5 • Le PDP et ses serveurs



839

Le rôle du PDP consiste à identifier les règles de politique qui sont applicables auxdifférents PEP et à déterminer les règles à appliquer stratégiquement à ces PEP. LePDP doit également se préoccuper de la traduction des règles de politique dans desformats compréhensibles des nœuds comme les PIB. De plus, il doit pouvoir commu-niquer avec d’autres serveurs internes pour prendre ses décisions. Enfin, le PDPassure la distribution des configurations. En résumé, le PDP décide des règles à appli-quer et envoie les ordres de configuration aux nœuds du réseau.

Les PEP (Policy Enforcement Point)

Les PEP sont des entités logiques qui appliquent les décisions politiques prises par lePDP dont elles dépendent. Les PEP sont généralement les nœuds du réseau, qui peu-vent être de différents types : routeur, commutateur ou LSR (Label-Switched Router).Un PEP peut également être un firewall ou un équipement intermédiaire entre le clientet le réseau. Le client peut lui-même posséder un client PEP sur son terminal. Dansles réseaux de mobiles à cartes à puce, il est fréquent de considérer qu’un PEP d’accèsse trouve sur la carte à puce. Son rôle est essentiellement réduit à la gestion de la sécu-rité et non de la qualité de service, mais il est imaginable de mettre de la gestion deQoS sur les cartes à puce dès que celles-ci seront assez puissantes pour effectuer cettegestion sans faiblir.

Un PEP doit être facilement accessible et paramétrable par le PDP de sorte qu’il soitpossible de le configurer sans problème. Il peut être configuré par un message COPSmais aussi par une requête SNMP (Simple Network Management Protocol) ou unecommande CLI (Command Line Interface), qui est la commande la plus simple pourconfigurer manuellement un équipement de réseau. Le PEP fait le lien entre la repré-sentation externe (PIB ou MIB) et la configuration interne de l’équipement et doit êtrecapable de recevoir des requêtes de différents types provenant de l’utilisateur. En par-ticulier, le PEP doit être apte à comprendre les requêtes RSVP (Resource reSerVationProtocol). Le PEP s’assure de la cohérence des politiques locales et surveille leurbonne application. Enfin, il peut intégrer des fonctions d’ingénierie ou de facturation.

COPS (COMMON OPEN POLICY SERVICE) COPS est le protocole de signalisation développé par l’IETF pour transporter lesdemandes de configuration et retourner les politiques à appliquer. Au départ, le proto-cole COPS devait permettre de prolonger RSVP vers le PDP et assurer les fonctionsde contrôle d’admission au réseau en les fondant sur des politiques.

C’est un protocole requête-réponse simple pour l’échange d’informations de politi-ques entre un serveur de politique, ou PDP (Policy Decision Point), et un client, ouPEP (Policy Enforcement Point). La figure 30.6 illustre ce schéma de base.



840

Le PEP peut être un routeur supportant RSVP ou un routeur supportant un service degestion de la qualité de service comme DiffServ ou encore un nœud appliquant uncontrôle quelconque. Le PEP fournit des informations au PDP concernant les déci-sions prises et les politiques installées. COPS transporte les messages d’erreur faisantsuite à la détection d’un problème lors de l’installation d’une politique ou à un échecdétecté lors de l’installation de la configuration sur le PEP.

Le PEP est responsable de la mise en place d’une connexion TCP avec le PDP. LePEP utilise cette connexion TCP pour envoyer des requêtes et recevoir les décisionsdu PDP. Le PEP doit rendre compte au PDP de l’exécution de ces décisions. Demême, le PEP est responsable de la notification au PDP des modifications du PEP.Le PEP est en outre responsable de la suppression d’un état devenu inacceptable à lasuite d’une modification demandée par le client ou d’une décision prise et envoyéepar le PDP.

Le PEP peut être configuré et commandé par une décision locale via son LPDP (LocalPolicy Decision Point). Le PEP doit faire parvenir les caractéristiques de cette déci-sion locale au PDP, lequel prend la décision finale. Si cette décision est différente decelle définie en local, le PDP l’envoie au PEP pour application.

La figure 30.7 décrit le système de communication entre un PDP et un PEP.

FIGURE 30.6 • Fonctionnement du protocole COPS

FIGURE 30.7 • L’architecture de base d’un environnement contrôlé par politique



841

Le PDP est la composante de l’environnement PBN (Policy Base Network) quicontrôle directement le PEP. Le PDP choisit parmi les politiques disponibles dans labase, ou policy repository, qui contient les informations de politique, la politiqueadaptée pour configurer le routeur.

Les règles de politique utilisées par le PDP sont saisies par la console de gestion del’opérateur puis mises à disposition du PDP par le policy repository où elles sontdéposées. À l’intérieur des nœuds, le PEP peut être accompagné d’un LPDP (LocalPDP), dont le but est de remplacer le PDP en cas de besoin. La présence du LPDP estfacultative. Ce point de contrôle local est utilisé pour prendre une décision locale enabsence du PDP.

Le PDP peut utiliser différents mécanismes et protocoles de communication avec desserveurs qui lui sont attachés pour réaliser des fonctions spécifiques, comme l’authen-tification, la facturation ou le stockage d’informations de politique.

Le fonctionnement général du modèle de gestion par politique est illustré à lafigure 30.8.

Les caractéristiques principales du protocole COPS

Le protocole emploie un modèle client-serveur, dans lequel le PEP envoie des messa-ges de requête (Request), de mise à jour (Update) et de suppression (Delete) au PDP.Le PDP retourne des messages contenant les décisions prises.

FIGURE 30.8 • Fonctionnement global d’un environnement de contrôle par politique



842

TCP est utilisé comme protocole de transport pour fiabiliser l’échange des messagesentre le PEP et le PDP. Aucun mécanisme supplémentaire n’est à mettre en œuvrepour réaliser une communication fiable entre un PDP et un PEP. Le protocole estextensible, la communication pouvant prendre en charge plusieurs types d’informa-tions (Client Specific Information) sans exiger de modifications de la part du proto-cole COPS.

Le protocole fournit les éléments de sécurité nécessaires pour l’authentification, laprotection contre des attaques malveillantes et l’intégrité du message. COPS peutaussi utiliser d’autres protocoles spécifiques pour gérer les problèmes de sécurité.Ainsi, IPsec ou TLS (Transaction Layer Security) peuvent être mis en œuvre pourauthentifier et sécuriser la connexion entre le PEP et le PDP.

Les états des configurations mises en place par la communication sous forme derequêtes-décisions sont partagés entre le PEP et le PDP. Les décisions du PDP peu-vent être émises d’une manière asynchrone, c’est-à-dire à tout instant, pour modifierl’état du système installé. Le protocole permet au PDP d’envoyer l’information deconfiguration au PEP et permet au PDP de supprimer les états du PEP lorsqu’ils nesont plus valides.

La figure 30.9 illustre un message COPS comprenant un en-tête avec différentschamps de contrôle, suivi des champs objet. Chaque champ objet est composé de lamême façon, en commençant par la longueur de l’objet, la définition de l’objet, letype d’objet et enfin le contenu et les valeurs associées de l’objet. La figure 30.10décrit l’échange des messages dans une communication COPS.

FIGURE 30.9 • Un message COPS



843

COPS et les modèles de gestion par politique

Les deux modèles principaux de gestion et de contrôle par politique sont le provisio-ning et l’outsourcing.

Dans le cas de l’outsourcing (Outsourcing Policy Model), le PDP reçoit les requêtes(Policy Requests) de demande de configuration de la part des PEP et décide ou nonl’autorisation de la connexion en temps réel sans qu’un lien préalable ait été tisséentre l’utilisateur et l’opérateur du réseau. Si la demande d’accès est acceptée, le PDPenvoie la configuration proposée au nœud d’accès, qui la propose à son tour au clientdemandeur.

Le fonctionnement général de l’outsourcing est le suivant : le client effectue unedemande de connexion à un réseau auquel il n’est pas abonné. Cette demande appelleune décision concernant l’accès au réseau : l’opérateur accepte ou non la connexiondu client. Le client doit donc faire une requête au réseau. Le protocole RSVP est levecteur le plus classique pour effectuer cette demande. Celle-ci arrive au nœudd’entrée du réseau, ou edge router, qui la dirige vers le PDP grâce à une requêteCOPS. Une fois la décision prise par le PDP, une réponse transitant par le protocoleCOPS indique au nœud d’entrée si la demande RSVP est acceptée ou non. En casd’acceptation, la requête RSVP peut continuer son chemin pour ouvrir une routesatisfaisant la demande de l’émetteur. Nous détaillerons cette solution un peu plusloin dans ce chapitre.

FIGURE 30.10 • L’échange de messages dans une communication COPS



844

Dans le cas du provisioning (Provisioning Policy Model) les politiques sont entrées àla console de gestion de l’opérateur à la suite d’une discussion entre le client et l’opé-rateur. Cette discussion débouche sur un SLA (Service Level Agreement), qui corres-pond à un contrat entre l’utilisateur et le gestionnaire du réseau détaillant lescaractéristiques du service qui doit être rendu par l’opérateur et les dispositions admi-nistratives en cas de problème. La partie technique du SLA s’appelle le SLS (ServiceLevel Specification). Le SLS donne lieu à l’introduction de politiques dans la basede données de l’opérateur, politiques qui devront être appliquées dès que le clientprésentera un flux à l’entrée du réseau.

Les politiques sont distribuées en temps réel par le PDP. Le PDP décide si la politiquedoit être installée en permanence dans les PEP traversés par le client ou non, suivantles caractéristiques techniques de la demande du client. Si les politiques sont implan-tées directement dans les nœuds, le PDP les envoie au travers d’une commandeCOPS. Les nœuds d’accès sont alors prêts à recevoir les demandes d’accès des flotsnégociés dans le SLA-SLS. Les nœuds d’accès sont capables de traiter en temps réelces demandes. Le provisioning est souvent associé à la technique DiffServ, danslaquelle les flots peuvent être classifiés suivant diverses classes. Dans ce cas, lespaquets des clients entrants sont marqués avec la priorité négociée dans le SLS ettransmis aux routeurs par la politique correspondante. La figure 30.11 illustre le fonc-tionnement d’une politique de provisioning associée à DiffServ.

FIGURE 30.11 • Fonctionnement d’une solution de provisioning



845

La figure 30.12 présente les requêtes échangées entre le PDP et le PEP pour une com-munication de type provisioning (PR) avec un protocole COPS qui prend alors le nomde COPS-PR. Cette communication s’effectue par l’émission d’une requête REQ duPEP vers le PDP. Le PDP répond par une commande DEC précisant la configurationà mettre en œuvre dans le PEP.

La pile du protocole COPS peut être divisée en trois couches conceptuelles distinc-tes : le protocole de base, les directives dépendant du type de client (client-type) et lareprésentation des données de politique (Policy Data Représentation).

L’IETF a proposé COPS comme protocole de communication pour faciliter l’échangedes informations de politique entre le PDP et les PEP. Avant d’effectuer un échangede données de politique, le PEP doit initialiser la communication en ouvrant uneconnexion TCP avec le PDP. C’est là une des différences les plus importantes par rap-port aux systèmes de gestion classiques de réseau, comme SNMP, dans lesquels leserveur initialise la communication avec le client avant d’envoyer l’information deconfiguration en utilisant une connexion UDP. L’utilisation d’une connexion TCPaugmente la fiabilité du protocole COPS.

COPS-RSVP et le modèle d’outsourcing

RSVP a été choisi comme protocole de signalisation entre le client et le réseau pourgérer la QoS, ou qualité de service dans le modèle d’outsourcing. À la suite de l’arri-vée d’un message RSVP dans le nœud d’accès, un protocole COPS spécifique est misen jeu : COPS-RSVP, qui utilise les objets de RSVP.

Quand le PEP reçoit un message RSVP sollicitant une décision pour la configurationdes nœuds que son flot va traverser, les objets de RSVP sont encapsulés à l’intérieurde l’objet Signaled ClientSI dans un message de requête COPS qui est envoyé auPDP. Le PDP décide alors si ce message RSVP doit être accepté ou non puis envoie sadécision au PEP par un message de réponse. D’autres informations de supervisionpeuvent être envoyées par le PDP, suite à la même requête, si le PDP s’aperçoit que ladécision politique originale a besoin d’être modifiée ou supprimée.

FIGURE 30.12 • Le fonctionnement de COPS-PR sous DiffServ



846

Dans le cas où le PDP détecte l’absence d’un objet RSVP essentiel dans la requête, ildoit retourner un message d’erreur <ERROR> dans le message de décision, qui doitindiquer MANDATORY CLIENT-SPECIFIC INFO MISSING. Dans le cas où le PDP détectel’absence d’un objet RSVP optionnel dans la requête, il retourne une décision néga-tive.

Pour chaque message de décision reçu, le PEP envoie un rapport au PDP qui inclut lesactions prises pour assurer que les politiques décidées par le PDP ont été convenable-ment installées et pour détecter d’éventuelles anomalies. Ainsi, le PDP reste bieninformé de la politique installée dans le PEP.

Dans le protocole RSVP, l’objet Policy Data joue le rôle d’un container de transportdes messages RSVP qui arrivent au PEP, le PEP communiquant l’objet Policy Data auPDP. Le PDP prend alors une décision fondée sur le contenu de l’objet Policy Data.Le PDP peut aussi modifier ou remplacer le Policy Data par un message OutgoingRSVP, qui permet à RSVP de se propager dans le réseau.

COPS-PR et le modèle de provisioning Le provisioning n’inclut pas de mécanisme de signalisation de QoS mais comporte unmodèle de type push. La configuration des routeurs est effectuée par le PDP en« poussant » l’information de configuration dans les nœuds une fois le SLA négociéavec l’utilisateur. Le mot provisioning (approvisionnement) provient de cette solutiondans laquelle on réserve des ressources à l’avance, l’utilisateur les trouvant mises à sadisposition dans les nœuds du réseau lorsqu’il se connecte.

Au départ, le PDP choisit les règles de politique qu’il appliquera à un utilisateur enconsidérant les informations du SLA-SLS négocié au départ avec l’utilisateur. Cesdécisions sont ensuite envoyées d’une manière asynchrone du PDP au PEP pour réa-liser la configuration décidée par le PDP. Le PDP effectue un calcul de probabilité enfonction de tous les SLA-SLS des clients abonnés puis envoie l’information de confi-guration au PEP, telle que le changement de politique demandé directement par l’uti-lisateur en modifiant son abonnement, à une heure prédéterminée, à l’expiration d’uncompte, etc. Le PEP confirme que l’installation de configuration est réussie à la suitedu message de configuration.

Le protocole COPS-PR peut être utilisé pour mettre en place différentes configura-tions de gestion de la qualité de service, comme DiffServ, MPLS, etc. Les donnéestransportées par COPS-PR forment un ensemble de données de politique. Ces don-nées prennent le nom de PIB (Policy Information Base), ou base de données desinformations de politiques. La PIB est utilisée avec le protocole COPS et, dans le casdu provisioning, avec COPS-PR. Ce modèle décrit le format des informations de poli-tique échangées entre le PEP et le PDP. La PIB contient des informations décrivant leservice et les techniques de classification des paquets. Elle est extensible, de sorte àpermettre l’adjonction de nouveaux types de paramètres.

Interactions entre PEP et PDP

Au démarrage d’un PEP, celui-ci ouvre une connexion COPS avec son PDP. Quand laconnexion est établie, le PEP envoie au PDP des informations à propos de lui-mêmesous forme d’une requête de configuration. Ces informations incluent des informations



847

qui spécifient ce client, telles que type de matériel et de logiciel utilisé et informationsnécessaires à une configuration. Durant cette phase, le client peut spécifier la taillemaximale du message COPS-PR.

Le PDP répond a cette requête de configuration en faisant un Download pourl’ensemble des politiques acceptées par le PDP concernant ce PEP. À la réception deces politiques de configuration, le PEP les organise et les installe. Si le PDP changeson comportement ou est averti par le PEP d’un changement de contexte, suite, parexemple, à une panne, le PDP envoie une nouvelle configuration avec les primitivesINSTALL, UPDATE et DELETE pour modifier la configuration du PEP. Si la configura-tion du PEP doit changer de manière radicale, suite à une demande de configurationnon disponible dans le nœud, le PEP envoie de façon asynchrone de nouvelles infor-mations au PDP dans un message UPDATE REQUEST CONFIGURATION. En recevantcette requête, le PDP fait parvenir au PEP les informations nécessaires à la gestion del’implantation de la nouvelle politique et, bien sûr, à l’effacement des politiques quine sont plus nécessaires.

Nous avons vu que COPS utilisait une connexion TCP entre le PEP et le PDP. Laconnexion TCP est initialisée par le PEP. Chaque serveur PDP écoute la connexionsur le port 3288. Il existe au moins un PDP par domaine administratif. Le PEP peutobtenir l’adresse du PDP par le service de gestion du réseau ou par le mécanisme delocalisation de service, ou SRVLOC (Service Location). Un PEP peut supporter plu-sieurs type de clients. Dans ce cas, il doit envoyer plusieurs messages CLIENT-OPEN,tels que chacune des connexions spécifie un type de client particulier.

Le PEP effectue sa requête à un ou plusieurs PDP au travers d’une ou de plusieursconnexions TCP. Un PDP qui a une adresse et un numéro de port peut supporter plu-sieurs types de clients. Il est donc possible qu’un PEP ouvre plusieurs connexionsavec plusieurs PDP. C’est le cas lorsqu’il y a physiquement plusieurs PDP supportantdifférents types de clients. Il faut bien noter que pour une classe de client donnée(client type), il n’y a qu’un PDP par domaine administratif. La figure 30.13 illustre cetype d’architecture.

Pour distinguer les différents types de clients, le client est identifié dans chaque mes-sage. Les classes de clients peuvent se servir de données propres à leur classe etréclamer l’application de politiques spécifiques.

Le PEP doit passer par les étapes suivantes pour arriver à une décision politique :

1. Un événement local ou un message demande au PEP de se configurer suivant unepolitique particulière. Le PEP créé une requête COPS qui contient des informa-tions provenant du message de demande d’admission et les éléments de politiqueà appliquer.

2. Le PEP peut consulter une base de données de configuration locale (Local Confi-guration Database) pour identifier un ensemble d’éléments de politique (PolicyElement) qui peut être évalué localement. Le PEP passe alors la requête au LPDP(au cas où il en possède un), lequel, à son tour, renvoie une décision, appeléerésultat partiel.

3. Le PEP émet une requête contenant tous les éléments de politique, accompagnésdu résultat partiel du LPDP, vers le PDP, qui prend la décision finale.

4. Le PDP retourne la décision finale au PEP et indique la politique à implanter dansle nœud.



848

Le PDP doit éventuellement être informé de l’échec du LPDP en ce qui concerne ladécision locale à prendre ainsi que de l’échec de l’admission, par manque de ressour-ces, par exemple. Le PDP peut, à tout moment, envoyer des notifications au PEP pourdemander une modification concernant une décision, générer une erreur de politique(Policy Error) ou envoyer un message d’avertissement (Warning Message).

La sécurité dans COPS

La sécurité dans COPS est négociée une fois pour toutes au début de la connexion etcouvre ainsi toutes les communications utilisant cette connexion. Si une sécurité par-ticulière est demandée pour une connexion, elle doit être négociée durant l’échangeinitial, pendant la phase CLIENT-OPEN/CLIENT-ACCEPT, en spécifiant un CLIENT-TYPEégal à zéro (CLIENT-TYPE = 0 est réservé à la négociation de la sécurité).

Si un PEP n’est pas configuré pour utiliser la version COPS Sécurity avec un PDP, lePEP envoie tout simplement au PDP un message CLIENT-OPEN pour un CLIENT-TYPEdisponible. Le PEP envoie sa demande de sécurité au PDP à l’aide d’un messageCLIENT-OPEN possédant un CLIENT-TYPE = 0 avant même d’ouvrir un autre CLIENT-TYPE. Si le PDP reçoit un message CLIENT-OPEN avec un CLIENT-TYPE = 0 aprèsqu’un autre CLIENT-TYPE a été ouvert avec succès, le PDP doit retourner un messageCLIENT-CLOSE avec CLIENT-TYPE = 0 pour ce PEP.

FIGURE 30.13 • Une architecture à plusieurs PDP



849

Le premier message CLIENT-OPEN doit spécifier un CLIENT-TYPE = 0 et doit indiquerle PEP ID (identité du PEP) et l’objet d’intégrité de COPS. Cet objet d’intégritécontient un numéro de séquence initialisé par le PEP, que le PDP doit incrémenterdurant la communication suivant l’échange du message initial CLIENT-OPEN/CLIENT-ACCEPT. La valeur de l’ID identifie l’algorithme et la clé utilisés pour sécuriser lacommunication. Le PDP accepte l’algorithme et la clé de sécurité du PEP en validantle message reçu en utilisant la clé identifiée par la valeur de l’ID. Le PDP doit envoyerun message CLIENT-ACCEPT avec un CLIENT-TYPE = 0 au PEP en portant un objetd’intégrité. Cet objet d’intégrité contient le numéro de séquence initialisé par le PDP,numéro que le PEP doit incrémenter durant toute la communication avec le PDP.

CONCLUSIONLe contrôle et la gestion par politique ont été lancés par les grands opérateurs et leséquipementiers de télécommunications pour faciliter le contrôle et la gestion de leursréseaux. Jusqu’à une époque récente, les routeurs et les commutateurs étaient confi-gurés à la main, grâce à des lignes de commande émises depuis une console opéra-teur. L’idée du contrôle par politique consiste à automatiser ce processus, depuis lademande utilisateur jusqu’à la configuration.

Cette solution du contrôle et de la gestion par un serveur centralisé se heurte à l’oppo-sition des partisans d’un Internet totalement décentralisé, dans lequel aucune res-source capitale n’est centralisée.

Il est certain que cette technique de contrôle a un bel avenir devant elle mais qu’ellepeut être transformée en un système un peu moins centralisé avec l’aide des PDPlocaux, qui devraient se trouver dans chaque PEP du réseau.

RÉFÉRENCES

La RFC décrivant le protocole RSVP utilisé pour la signalisation utilisateur dans le cadre dessystèmes gérés par politique :

B. BRADEN, L. ZHANG, S. BERSON, S. HERZOG, S. JAMIN – Resource ReSerVationProtocol (RSVP)-Functional Specification, IETF RFC 2205, septembre 1997

Les systèmes experts font une entrée en force dans le domaine de la gestion de réseau. L’articlesuivant fait le point sur le sujet :

L. BERNSTEIN, C.-M. YUHAS – “Expert Systems in Network Management-TheSecond Revolution”, IEEE Journal on Selected Areas in Communications, vol. 6, 5,pp. 784-787, juin 1988



850

La RFC de l’IETF qui décrit le protocole COPS et l’architecture qui l’accompagne :

D. DURHAM, J. BOYLE, R. COHEN, S. HERZOG, R. RAJAN, A. SASTRY – The COPS(Common Open Policy Service) Protocol, IETF RFC 2748, janvier 2000

La RFC complémentaire à la précédente pour l’intégration de RSVP dans l’architecture de ges-tion par politique :

S. HERZOG, J. BOYLE, R. COHEN, D. DURHAM, R. RAJAN, A. SASTRY – COPSusage for RSVP, IETF RFC 2749, janvier 2000

Un des white papers disponibles sur la gestion par politique :

IPHighway – http://www.iphighway.com/whitepapers.htm

La RFC décrivant le service DiffServ :

K. NICHOLS, S. BLAKE, F. BAKER, D. BLACK – Definition of the Differentiated Ser-vices Field (DS Field) in the IP4 and IP6 Headers, IETF RFC 2474, décem-bre 1998

La première description d’une gestion par politique adaptée aux solutions IntServ et DiffServ :

R. RAJAN, D. VERMA, S. KAMAT, E. FELSTAINE, S. HERZOG – A Policy frameworkfor Integrated and Differentiated Services in the Internet, IEEE Network, septem-bre-octobre 1999

La RFC décrivant l’architecture de gestion et de contrôle par politique :

R. YAVATKAR, D. PENDARAKIS, R. GUERIN – A Framework for Policy-BasedAdmission Control, IETF RFC 2753, janvier 2000


Documents

Guy Pujolle - Accueil - Librairie Eyrolles · Les opérateurs de télécommunications et les gestionnaires de réseau souhaitent ... rel, soit des règles déjà préparées par l’opérateur