La gestion et le contrôle par politique

Les opérateurs de télécommunications et les gestionnaires de réseau ont besoin d’automatiser le processus de configuration des nœuds et des équipements réseau. Cette automatisation vise à la fois à contrôler les flux d’information qui transitent dans ces nœuds et à gérer plus facilement les équipements réseau. De là est née la gestion par politique, à laquelle on peut ajouter le contrôle, qui en fait partie de façon intrinsèque. La terminologie anglo-saxonne correspondante est PBM (Policy-Based Management). Le mot policy est traduit dans ce livre par politique, mais on aurait aussi bien pu choisir règle. Le propos de ce chapitre est de présenter ce nouveau paradigme, consistant à gérer et contrôler les réseaux par l’intermédiaire de politiques. Nous commencerons par introduire les politiques puis détaillerons l’architecture associée au protocole de signalisation utilisé dans cet environnement.

Les politiques 

Une politique s’exprime sous la forme « si condition alors action ». Par exemple, « si l’application est de type parole téléphonique, alors mettre les paquets en priorité Premium ». Cette section s’intéresse à la définition syntaxique et sémantique d’une politique puis examine en détail les politiques et leur utilisation pour le contrôle, ainsi que le protocole de signalisation permettant de transporter les paramètres des politiques 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 discussion entre l’utilisateur et l’opérateur. On utilise pour cette discussion soit le langage naturel, soit des règles déjà préparées par l’opérateur du réseau. Dans ce dernier cas, l’utilisateur ne peut que choisir parmi ces règles la politique qu’il souhaite voir appliquer. On parle alors de politique définie au niveau business. Cette politique doit être traduite dans un langage de niveau réseau permettant de déterminer le protocole réseau de gestion de la qualité de service et son paramétrage. Enfin, il faut traduire ce langage de niveau réseau en un langage de bas niveau correspondant à la programmation des nœuds du réseau, ce que l’on peut appeler la configuration du nœud. Ces différents niveaux de langage, business, réseau et configuration, sont pris en charge par un groupe de travail de l’IETF appelé Policy. Le modèle retenu provient d’un autre groupe de travail, le DMTF (Distributed Management Task Force) et porte le nom de CIM (Common Information Model). Les extensions sont aujourd’hui développées conjointement par les deux groupes de travail. L’objectif de ce travail de normalisation des modèles d’information liés aux différents niveaux de langage est d’obtenir un modèle général qui puisse se décliner en modèles d’information par domaine, ainsi qu’une représentation indépendante des équipements et des implémentations. La figure 30.1 illustre le modèle le plus général possible à partir du modèle de base.Si l’on ne se préoccupe que de la branche QoS, ou qualité de service, la structure des modèles successifs permet de passer de la définition générale d’une politique de qualité de service à la configuration d’un routeur. La figure 30.2 illustre la succession de modèles allant vers de moins en moins d’abstraction et s’approchant de la description d’une configuration.

PCIM (Policy Core Information Model)

PCIM définit le modèle de description des politiques, quel que soit leur domaine d’application. Le réseau est considéré comme une machine à é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 identifiant 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 forment les éléments de base des politiques, et les classes d’association, qui déterminent les relations entre les éléments. Les politiques forment un ensemble de conditions vraies ou fausses qui peuvent être composées pour réaliser une politique plus complexe. Ces politiques forment à leur tour un ensemble d’actions associées aux conditions qui modifient la configuration de un ou plusieurs éléments et qui introduisent des ordres d’exécution, comme la priorité des flots ou l’ordonnancement des paquets dans le réseau. PCIMe (PCIM extension) a pour fonction de rendre le modèle PCIM plus flexible en permettant aux différents domaines d’homogénéiser leurs concepts. Les principales extensions concernent une meilleure gestion des priorités, l’ajout de variables et de valeurs, la définition de variables générales, l’ajout de règles simplifiées fondées sur les variables, la possibilité d’avoir des règles conditionnées par d’autres règles, la condition de filtrage de paquets IP à base de conditions, etc.

QPIM (QoS Policy Information Model)

Le rôle de QPIM est de fournir un format standard pour les politiques de QoS en intégrant les environnements IntServ et DiffServ, tout en restant indépendant des protocoles d’accès, des méthodes de stockage et des techniques de contrôle de QoS (files d’attente, etc.). QPIM doit en outre 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 certains paramètres de RSVP, l’acceptation ou non d’une requête et la conformité au modèle COPS-RSVP et enfin les actions liées aux politiques de provisioning, comme le marquage, le lissage, la perte de paquets, l’ordonnancement, etc. D’autres extensions ont été ajoutées, notamment dix-sept variables liées à RSVP, ainsi que la définition formelle de profils de trafic pour DiffServ et IntServ.

QDDIM (QoS Device Datapath Information Model)

Le modèle QDDIM permet de s’approcher de la configuration des routeurs en étendant QPIM, qui définit des actions sur les paquets, par le biais d’actions sur les équipements tout en restant indépendant des implémentations. Le rôle de QDDIM est de permettre de programmer un routeur ou un équipement réseau, indépendamment de 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 à appliquer sur les composants de l’équipement réseau. 

Architecture d’un contrôle par politique

Le contrôle par politique implique plusieurs composants (voir figure 30.3). Les nœuds du réseau prennent le nom de PEP (Policy Enforcement Point). Les politiques y sont appliquées pour gérer les flux des utilisateurs. Le PDP (Policy Decision Point) est le point qui prend les décisions et choisit les politiques à appliquer aux PEP. La communication entre le PEP et le PDP s’effectue par le biais du protocole COPS (Common Open Policy Service). Le système comporte également une console utilisateur, qui contient des outils de gestion des politiques. Ces derniers permettent notamment d’entrer les politiques dans une base de données, nommée Policy Repository, qui entrepose les règles de politique que le PDP vient rechercher pour les appliquer aux nœuds du réseau. Des variantes de ce schéma de base peuvent inclure plusieurs PDP susceptibles de gé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 à une décentralisation des fonctions du PDP dans des PDP locaux, appelés LPDP (Local Policy Decision Point). En règle générale, un PDP gère un seul domaine administratif, et les règles de politique sont communes à la configuration de l’ensemble des nœuds du domaine. Un problème de cohérence se pose lorsque le client émetteur et le client récepteur ne se trouvent pas dans le même domaine administratif. Dans ce cas, les PDP des deux domaines doivent négocier pour se mettre d’accord sur les règles de politique à adopter 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 pour elle-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 doit décider des politiques à appliquer dans le réseau. Il s’agit en quelque sorte d’un organe de décision, qui recherche les informations dont il a besoin dans de nombreux serveurs communiquant directement avec lui de façon à prendre une décision. Ces serveurs peuvent être locaux, ce qui est le cas le plus général, mais ils peuvent aussi être distants.