La signalisation

La signalisation

Le transport de l’information de commande, ou signalisation, est un aspect capital de l’infrastructure des réseaux. On peut même dire que l’avenir des réseaux réside dans la capacité de les piloter et d’automatiser leur configuration. L’objectif est de signaler une information, par exemple celle de déclencher les processus de mise en place de l’infrastructure, afin qu’une application puisse se dérouler. La signalisation est depuis longtemps étudiée par les organismes de normalisation, et plus particulièrement par l’UIT-T. Elle a beaucoup évolué au cours des dix dernières années et va continuer à devoir s’adapter aux bouleversements du monde IP. Ce chapitre ne vise pas à dresser un panorama exhaustif des protocoles de signalisation. Nous en abordons un grand nombre dans l’ensemble de l’ouvrage, en les introduisant directement dans les chapitres traitant des architectures ou des protocoles de service concernés. Le présent chapitre se contente d’introduire quelques notions de base et de les accompagner d’un certain nombre d’exemples éloquents, qui, même s’ils sont introduits par ailleurs dans l’ouvrage, représentent des cas importants. Nous commençons par donner les raisons d’être de la signalisation et présenter les principales fonctions dont elle s’occupe. Nous introduisons ensuite les exemples de signalisation les plus importants, avec les protocoles RSVP, COPS et SIP, ainsi que les protocoles associés au concept de middle box. Nous terminons avec le CCITT n˚ 7, qui a longtemps été la norme de signalisation la plus répandue, du fait de son adoption ancienne par les réseaux de type circuit, notamment le réseau téléphonique.

Caractéristiques de la signalisation 

La signalisation désigne les moyens à mettre en œuvre pour transmettre une information telle que l’ouverture ou la fermeture d’un chemin. Elle existe dans tous les réseaux, y compris ceux qui, comme IP, souhaitent la réduire au minimum afin de préserver la simplicité du système. La signalisation doit donc être capable de fonctionner selon toutes les techniques du monde des réseaux, en particulier des réseaux IP. La signalisation demande généralement un mode routé. En effet, il faut indiquer à qui la signalisation est adressée et, pour cela, exhiber l’adresse complète du récepteur dans le paquet de signalisation. Tous les réseaux commutés ont donc besoin d’un réseau routé pour mettre en œuvre la signalisation. La signalisation est capable de prendre en charge des services à différents niveaux de l’architecture. Par exemple, elle doit être capable d’effectuer une négociation de SLA, de demander l’authentification d’un utilisateur, de collecter des informations sur les ressources disponibles, etc. Le protocole de signalisation doit être extensible de façon à permettre l’arrivée de nouveaux services de façon simple. Le protocole de signalisation doit de plus être modulaire et flexible, afin de répondre aux besoins de chaque application particulière. La modularité facilite l’ajout de nouveaux modules lors des phases de développement. Fonctionnement de la signalisation Un protocole de signalisation comporte deux modes de fonctionnement : dans la bande (inband) et hors bande (outband). Dans le premier cas, les messages de signalisation sont transportés dans le chemin de données, tandis que dans le second ils sont indépendants du chemin suivi par les données. Une autre caractéristique de la signalisation est la possibilité de couplage (path-coupled) ou au contraire de découplage du chemin (path-decoupled). Dans le premier cas, la signalisation suit les données dans la bande ou hors bande en empruntant la même succession de nœuds. Par exemple, le protocole RSVP est path-coupled et le protocole COPS path-decoupled. La signalisation doit être capable de fonctionner à la fois dans les modes interdomaines et intradomaines. La signalisation doit également pouvoir fonctionner en modes bout-enbout, bordure à bordure et end-to-edge (signalisation entre un end-host et un edge-node). Dans l’environnement Internet hétérogène actuel, il existe un grand nombre de protocoles de signalisation, plus ou moins adaptés aux différentes applications. Cette grande diversité a poussé l’IETF à créer le groupe de travail NSIS (Next Step in Networking) afin de proposer une nouvelle norme unique destinée à rassembler toutes les précédentes. D’une façon générale, un protocole de signalisation doit pouvoir coopérer avec d’autres protocoles. Pour ce faire, il doit être capable de transporter les messages d’autres protocoles de signalisation. Il est aussi possible de définir des interfaces permettant de transformer un message concernant un protocole en un message concernant un autre protocole. La signalisation doit supporter la gestion de toutes les ressources du réseau. Elle prend en charge le transport des informations permettant d’exprimer les demandes des applications en terme de réservation et d’allocation de ressources. Pour ce faire, la signalisation interagit avec des entités spécifiques, telles que les serveurs de gestion de ressource, comme les bandwidth brokers, ou serveurs de bande passante. Enfin, la signalisation doit supporter la négociation de SLA entre un utilisateur et un fournisseur ou entre fournisseurs et la configuration des entités dans le réseau selon le nouveau SLA. La signalisation peut supporter le monitoring des services et les états des entités dans le réseau et prendre en charge la facturation des services. Afin de valider les demandes de service d’un utilisateur, la signalisation est aussi utilisée pour réaliser une authentification. Elle permet en ce cas de transporter les informations nécessaires à cette interaction. Ce transport doit être suffisamment générique pour autoriser les mécanismes existants et à venir. La sécurité La signalisation joue un rôle très important dans la sécurisation d’un réseau. En premier lieu, elle doit être elle-même sécurisée. Les primitives doivent pouvoir s’authentifier pour garantir qu’elles ne proviennent pas d’attaquants. La signalisation doit aussi implémenter des moyens de protection des messages de signalisation contre leur modification malicieuse. Elle doit en outre permettre de détecter qu’un ancien message est réutilisé, afin d’éviter le rejeu, et de cacher les informations de topologie du réseau. Elle peut enfin supporter des mécanismes de confidentialité des informations, tels que le chiffrement. Les protocoles de signalisation peuvent coopérer avec les protocoles d’authentification et les agréments de clés (Key Agreement) pour négocier les associations de sécurité. La signalisation doit aussi posséder des moyens pour négocier des mécanismes de sécurité selon les besoins des applications et des utilisateurs. La mobilité La signalisation joue un rôle important dans la gestion de la mobilité. Elle intervient dans les diverses actions à effectuer quand le mobile change de cellule, quand il effectue un roaming, lorsqu’il négocie son SLA ou bien pour la mise en place d’une application. Quand un handover a lieu, la signalisation doit être capable de rétablir la connexion et de reconstituer rapidement et efficacement les états installés dans la nouvelle station de base. Le processus de rétablissement peut être local ou de bout en bout. Si le réseau mobile est surchargé, la signalisation des handovers doit avoir une priorité plus élevée que celle d’une signalisation démarrant une nouvelle connexion. La charge du réseau Dans une situation normale, le trafic de signalisation occupe une part peu importante du trafic du réseau. Cependant, dans certaines situations de congestion, de panne ou de problème, le trafic de signalisation peut augmenter de façon significative et créer une sévère congestion de la signalisation dans le réseau. Par exemple, une erreur de routage d’un paquet de signalisation peut entraîner une explosion en chaîne des messages de notification. Un protocole de signalisation doit être capable de maintenir la stabilité de la signalisation. La signalisation doit être robuste, efficace et consommer le moins possible de ressource dans le réseau. Ce dernier doit être capable de fonctionner, même dans le cas d’une forte congestion. Le réseau doit être capable d’assigner une priorité aux messages de signalisation. Cela permet de réduire les délais de transit des signalisations correspondant à des applications fortement prioritaires. Il faut également faire attention aux attaques par déni de service, qui peuvent saturer le réseau par des messages de signalisation de haute priorité. Le protocole de signalisation doit permettre de regrouper des messages de signalisation. Cela peut concerner, par exemple, le regroupement des messages de rafraîchissement, comme RSVP, afin d’éviter de rafraîchir individuellement les états de réservation, ou soft-state. La signalisation doit pouvoir passer l’échelle (scalabilité), c’est-à-dire s’appliquer à un petit réseau aussi bien qu’à un immense réseau de plusieurs millions de nœuds. Elle doit aussi être capable de prendre en charge et de modifier les différents mécanismes de sécurité en fonction des besoins en performance des applications.

Le protocole RSVP

 Le protocole RSVP (Resource reSerVation Protocol) est conçu pour supporter la réservation unicast et multicast de ressources de bout en bout. Repris dans l’environnement IntServ (Integrated Services), RSVP est un protocole de signalisation modulaire, qui offre la possibilité de définir de nouveaux objets pour des extensions à venir. Il supporte le soft-state, fonctionne en mode path-coupled et fait la réservation en mode receiver-initiator, c’est-à-dire depuis le récepteur vers l’émetteur. Des extensions de RSVP ont été proposées pour permettre la livraison fiable de messages de signalisation (message ACK/NACK) et le regroupement des messages de rafraîchissement dans un seul message SREFRESH. Une autre proposition d’extension permet l’agrégation des demandes de réservation de ressources pour augmenter la performance et la scalabilité du protocole. Caractéristiques de RSVP Une caractéristique importante de RSVP est de permettre la réservation de ressources dans un mode multicast. Il est difficile d’utiliser le mode émetteur vers récepteur pour prendre en charge la réservation de ressources en multicast puisqu’on ne connaît pas les caractéristiques du récepteur au démarrage de la demande de réservation. C’est la raison pour laquelle RSVP fonctionne en mode récepteur vers émetteur. Dans ce mode, c’est le récepteur des données qui déclenche et maintient la réservation des ressources dans le réseau. En d’autres termes, l’émetteur envoie une demande au récepteur, lequel déclenche la primitive de réservation de ressources et l’envoie vers l’émetteur. Le paquet portant cette primitive effectue la réservation dans les nœuds traversés en allant du récepteur vers l’émetteur. La raison de ce choix tient à la nécessité d’effectuer une réservation adéquate puisque la primitive de réservation connaît les caractéristiques de l’émetteur et du récepteur, et pas seulement celles de l’émetteur. Par exemple, si l’émetteur demande un débit de 1 Mbit/s mais que le récepteur ne puisse recevoir qu’un débit de 128 Kbit/s, il est inutile de réserver une bande passante de 1 Mbit/s, 128 Kbit/s suffisant. Le maintien d’une réservation repose sur la notion de soft-state au niveau des nœuds intermédiaires et d’extrémité. Les soft-states sont des états périodiquement réactivés, permettant de mettre à jour dynamiquement le chemin à réserver en fonction des arrivées et des départs de participants et des changements de route. L’état de réservation peut donc être périssable, grâce à l’usage d’un temporisateur.Les autres caractéristiques importantes de RSVP sont les suivantes : • RSVP transporte et maintient des paramètres de contrôle de trafic (QoS) et de contrôle de politique (Policy Control) qui lui sont opaques. En fait, RSVP véhicule des structures d’objets définissables en dehors de lui. • RSVP est pris en charge aussi bien par IPv4 qu’IPv6. Les composants du protocole sont définis pour cela pour IPv4 comme pour IPv6. Par exemple, les objets FILTER_SPEC sont définis différemment en IPv4 et en IPv6. • RSVP est unidirectionnel. Il n’établit donc de réservation pour les flux de données que dans un seul sens. La réservation de ressources pour des transferts bidirectionnels requiert deux sessions RSVP indépendantes. • RSVP n’est pas un protocole de routage. La signalisation RSVP utilise des protocoles de routage qui déterminent le chemin vers la destination. Précisons que RSVP fournit un mode opératoire transparent aux routeurs qui ne le supportent pas. Les routeurs non RSVP-aware routent les paquets IP qui transportent les messages RSVP comme des paquets normaux. Fonctionnement de RSVP Le protocole de signalisation RSVP met en place une connexion logique appelée session. Une session RSVP est définie par les trois éléments suivants : • adresse IP destination (unicast ou multicast) ; • identifiant du protocole sur IP ; • port destination (optionnel pour IPv4), TCP ou UDP. Le modèle RSVP se fonde sur l’échange de deux messages fondamentaux, les messages Path et Resv (voir figure 31.1) : • Le message Path (à l’initiative de l’émetteur) permet à l’émetteur du flux de données de spécifier les caractéristiques du trafic qu’il va générer. • Le message Resv (à l’initiative du récepteur) permet à un récepteur ayant préalablement reçu un message Path de spécifier la QoS requise et de déclencher la réservation sur le chemin. Ce message suit le même chemin que celui du message Path mais dans le sens inverse. Les principaux messages qui ont été définis dans RSVP sont les suivants : • Message d’erreur : – PathErr, envoyé à l’émetteur qui a créé l’erreur. – ResvErr, envoyé vers le récepteur pour notifier une erreur en fusionnant les demandes de réservation.