Quelle Place pour ATM dans les réseaux?

par Jean-Yves Le Boudec, Laboratoire Réseaux de Communication DI-EPFL, E-mail: leboudec@di.epfl.ch

Table des matières

A l'heure où le grand public commence à découvrir l'Internet, les professionnels des réseaux voient gonfler sur l'horizon la vague ATM. Or l'Internet et ATM représentent des technologies fondamentalement différentes, par leur architecture, et peut être surtout par l'héritage des milieux qui les ont développées. Que représentent ces technologies? Que nous préparent ces prochaines années? Quelle place prendra ATM dans les réseaux? Ce sont les questions auxquelles s'attaque ce court article.

retour à la table des matières

Aux Origines furent IP et X.25

L'Internet est né dans les années septante; sa base en est le protocole IP (Internet Protocol) . Comme nos perspicaces lecteurs n'auront pas manqué de le remarquer, le nom même indique qu'il s'agit d'une technologie d'interconnexion de réseaux. A l'origine, lesdits réseaux étaient par exemple des Ethernets, et un des buts d'IP fut de vaincre les limitations de distance et de taille de ces derniers. Pour ce faire, on donna simplement à chaque réseau un numéro de network, et à chaque ordinateur sur un réseau un numéro de host. Entre les réseaux, on place des routeurs, dans lesquels on écrit, par un moyen maintenant automatique, des tables de routage qui permettent d'envoyer les paquets aux bons endroits.

Une des caractéristiques essentielles d' IP est que le protocole est sans connexion. Cela signifie que pour envoyer un paquet IP, un ordinateur n'a besoin d'autre chose que d'y écrire l'adresse du destinataire, comme on envoie une lettre à la poste. Bien sûr, le paquet n'atteindra sa destination finale que si toutes les tables de routage sont correctement écrites dans le réseau. Ceci est la fonction du protocole de routage, qui fonctionne entre routeurs. Les routeurs ne maintiennent pas d'information sur les communications individuelles; ils se contentent de savoir par où il faut les envoyer (figure 1).

Figure 1: mode de transfert sans connexion, illustrant les tables de routages

Un des objectifs, présent à la conception d'IP, qui explique le choix d'un mode sans connexion, fut de permettre le développement de réseaux dans un cadre non directif et sans opérateur central. Le choix du mode sans connexion est aussi le choix de la simplicité - un avantage décisif dans le monde très complexe des protocoles. Le même choix fut arrêté par presque tous les réseaux constructeurs de seconde génération, (Nous appelons réseaux de première génération les réseaux d'entreprises, tels SNA, construits autour des grands ordinateurs centraux (mainframes). Ils supportent le mode de calcul centralisé. Les réseaux de seconde génération sont construits autour des réseaux locaux (Ethernet, Token Ring) et supportent le mode de calcul client-serveur. ) : c'est le cas d'AppleTalk et d'IPX (Novell). Par contre, les réseaux de première génération (SNA) et certains réseaux de seconde génération (APPN), emploient une technique avec connexion: quand un ordinateur désire communiquer avec un autre, il lui faut auparavant, par un échange de messages de contrôle avec un routeur (par exemple un routeur APPN), établir une connexion à travers tout le réseau. Tous les routeurs entre source et destination sont impliqués dans ce flux de contrôle, et autorisent ou rejettent la connexion. A la fin de la phase de contrôle, l'ordinateur source peut envoyer des données sur la connexion. Tous les routeurs impliqués maintiennent une machine d'état finie reflétant l'état de la connexion (Figure 2).

Figure 2: mode de transfert avec connexion, montrant les tables de connexions ("conn Id" = identificateur local de connexion). Les numéros sur la figure sont ceux des ports d'entrées-sorties. La figure montre deux connexions. La première relie A à B en passant par C1 et C2, et est identifiée par un "conn Id" égal à 1 sur tous les liens.
La deuxième relie A à C en passant par C1, C2 et C4 et est identifiée par un "conn Id" égal à 2 entre A et C1 comme entre C1 et C2, et égal à 1 sur les autres liens

La figure illustre que les tables de routage pour un routeur de protocole avec connexion possèdent une entrée par connexion, non par réseau destinataire comme dans le cas sans connexion. (Notre discussion porte exclusivement à ce point sur la couche réseau, (dont la fonction est de porter les paquets de données d'un ordinateur source à un ordinateur destination). En dernier ressort, la communication entre deux systèmes est très souvent avec connexion, indépendamment du ou des réseaux employés. Ainsi le célèbre protocole de transport TCP est avec connexion. Au titre de protocole de transport, TCP est implanté dans les ordinateurs source et destination, mais pas dans les routeurs. ) Elles sont donc beaucoup plus volumineuses. Le mode orienté connexion est plus complexe, tant pour les ordinateurs utilisant le service que pour les routeurs. Par contre, il a l'avantage d'un meilleur contrôle sur les flux de trafic. On peut par exemple garantir qu'une fraction déterminée de la capacité du réseau est réservée en priorité aux flux de trafic interactifs dont la qualité est vitale pour l'entreprise (ainsi des transactions de réservation pour une compagnie aérienne). Les réseaux dédiés aux missions critiques de l'entreprise préfèrent donc souvent une technique avec connexion (SNA, APPN, Frame Relay).

Les réseaux publics préfèrent aussi une technique avec connexion, pour la même raison du meilleur contrôle sur les flux de trafic, et en particulier à des fins de facturation. Ce fut le cas du protocole réseau de la recommandation X.25, qui fut à peu près contemporain d'IP, et qui, par simplification des fonctions de réseau, a donné Frame Relay. Dans le cas des réseaux publics, le routeur de paquet est généralement appelé commutateur, le mot routeur étant évité dans ce contexte.

retour à la table des matières

ATM est arrivé

 ATM (Asynchronous Transfer Mode) fut choisi par l'organe central de normalisation du monde des Télécoms (l'ITU) dans la fin des années huitante. ATM est l'héritier direct de Frame Relay, dont il diffère par l'emploi de paquets de petite taille et fixe (appelées cellules ). ATM est donc orienté connexion. En pratique, les fonctions de routage de cellule sont implantées en hardware, contrairement à la plupart des routeurs IP ou des commutateurs X25 ou Frame Relay. Dans le cas d'ATM, on parle aussi de commutateur plutôt que de routeur de cellules.

ATM ajoute aux technologies qui l'ont précédé la possibilité de garantir capacité et qualité des services par connexion . Ainsi on peut établir une connexion entre deux systèmes ATM et spécifier par exemple qu'on souhaite pour cette connexion un débit garanti de 3 Mb/s, un délai maximum de 100 ms, une variation de délai inférieure à 5 ms, et un taux de pertes de cellules inférieur à 10(puissance 10). Par comparaison, les technologies réseau mentionnées plus haut ne permettent pas des garanties aussi fortes.

De telles garanties sont nécessaires pour pouvoir transporter sur ATM les circuits numériques (à 64 kb/s, 2 Mb/s, 34 Mb/s,...) qui forment les services essentiels des opérateurs de Télécom. Elles sont aussi utiles pour établir des connexions multimédias, par exemple pour transporter des flux audio ou vidéo.

retour à la table des matières

ATM pour les Réseaux Locaux

 Défini à l'origine pour les besoins des réseaux publics, ATM s'est imposé rapidement comme la technologie de choix pour les réseaux locaux d'entreprise (les LANs ). Pourquoi cette évolution?

Pour le comprendre, il faut d'abord se rappeler que les réseaux locaux résolvent avant tout un problème de câblage. A l'origine, ils sont basés sur des techniques de partage du support: avec Ethernet comme avec le Token Ring ou FDDI, le réseau est construit autour d'une méthode d'accès qui permet à plusieurs ordinateurs d'utiliser des câbles communs pour communiquer entre eux. Dans le premier cas, la méthode d'accès consiste à autoriser plusieurs ordinateurs à essayer d'émettre en même temps, quitte à se répéter s'il y a eu collision. Dans les deux autres cas, c'est un jeton qui, transmis d'un ordinateur à l'autre, commande l'accès au réseau: seul l'ordinateur en possession du jeton a le droit d'émettre. Ces techniques de réseau local sont bien adaptées au caractère extrêmement sporadique du trafic entre ordinateurs. Par contre, elles entraînent des contraintes importantes de taille et de configuration. D'une part, la méthode d'accès impose une limite à l'étendue géographique du réseau (2 kilomètres de câble au maximum pour Ethernet) et au nombre d'ordinateurs connectés (rarement plus de la centaine). D'autre part, tous les ordinateurs sur un même réseau partagent les mêmes câbles et il n'est pas possible d'isoler un ordinateur des autres. L'isolation est souhaitée pour des raisons de performance ou de sécurité; le trafic étant très irrégulier, on souhaite souvent dans les entreprises pouvoir isoler un groupe de travail pour éviter qu'il ne monopolise le réseau, ou au contraire pour éviter qu'il ne soit gêné par le reste du trafic. On cite ainsi l'exemple de l'entreprise de courtage en bourse où, au moment où le comptable lance l'opération quotidienne de bouclement, le reste du réseau de l'entreprise est paralysé pendant 15 minutes.

Afin de compenser ces limitations des réseaux locaux, on a vu apparaître un ensemble complexe de techniques d'accompagnement: concentrateurs, ponts et routeurs. Les concentrateurs sont des équipements qui permettent de mettre en place plusieurs réseaux locaux parallèles, et d'obtenir par là un certain découplage entre la localisation d'un ordinateur et le réseau auquel il est connecté. Pour reprendre l'exemple précédent, avec un concentrateur on peut créer, sous certaines conditions, un réseau dédié à la comptabilité, et un autre au reste des opérations, tout en permettant à ces deux réseaux de coexister sur les mêmes mètres carrés. Les ponts et routeurs, quant à eux, permettent d'interconnecter les différents réseaux locaux ainsi créés par des partitions; ils permettent aussi de s'affranchir des limites de taille et d'étendue.

L'ensemble ainsi obtenu est cependant très complexe à mettre en oeuvre et à gérer, à cause de la multiplicité des technologies mises en jeu; chaque élément (ordinateur, concentrateur, pont, routeur) doit être correctement configuré, les concepts et les techniques étant pour chacun différents. Quand on ajoute à la gestion de ces éléments celle des serveurs (de fichier, d'applications), on considère en général qu'une entreprise a besoin d'une personne à temps plein par cinquantaine d'utilisateurs en réseau. Une des raisons principales de cette complexité est, paradoxalement, enracinée dans le principe même d'Ethernet, Token Ring et FDDI, à savoir, le principe de l'accès partagé. Une solution alternative est la commutation (layer 2 switching ). Avec une technologie de commutation, chaque ordinateur est connecté par une liaison point à point à un noeud du réseau, et les communications entre ordinateurs passent nécessairement par ces noeuds. Les noeuds du réseau sont des composants actifs, qui doivent analyser l'en-tête de chaque paquet afin de l'acheminer. Ces noeuds sont donc des commutateurs tels que nous les avons rencontrés dans les sections précédentes. Les ponts et les routeurs sont de tels commutateurs. On a vu ainsi apparaître des commutateurs Ethernet, Token Ring ou FDDI (switched LANs ); avec ces commutateurs il n'y a plus d'accès partagé (ils ne gardent les noms d'Ethernet, Token Ring et FDDI que parce qu'ils permettent de connecter des ordinateurs possédant ces interfaces). Au contraire, le trafic de port à port est commuté sans conflit (Figure 3). Pour la petite histoire, ces commutateurs ont en fait des ponts entre réseaux locaux réduits à un seul élément.

Figure 3: Accès partagé à gauche contre commutation à droite. A gauche, quand A parle à D, tout le réseau est occupé. A droite, A et E peuvent envoyer des paquets en même temps.

Une solution à base de commutation résout tous les problèmes mentionnés plus haut. En particulier, et à condition de posséder la technologie pour interconnecter les commutateurs entre eux (routage, découverte des adresses, etc.), ils permettent de créer des réseaux de toutes tailles et de toute étendue géographique, comme on le connaît pour le téléphone.

Au moment où l'ITU spécifiait l'ATM pour le RNIS à large bande, l'industrie des réseaux locaux était donc à la recherche d'un standard définissant une technologie de commutation. Le choix s'est alors tout naturellement porté sur ATM, non tant à cause des qualités intrinsèques des choix techniques arrêtés par l'ITU (le concept de paquet de taille fixe, la cellule, est peu adapté au monde des données), mais plutôt pour la valeur en soi d'un standard stable et durable.

C'est ainsi qu'ATM est apparu comme la technologie de choix pour les réseaux locaux. Le réseau local moderne sera donc de plus en plus construit autour d'ATM (Figure 4):

Figure 4. ATM dans le réseau local. A à H utilisent Switched Ethernet, I et J utilisent ATM natif. Les commutateurs d'Ethernet utilisent ATM entre eux. Entre Switched Ethernet et ATM, les ordinateurs communiquent par LAN Emulation, ou par IP sur ATM.

retour à la table des matières

IP sur ATM

La mise en oeuvre d'ATM requiert le portage des protocoles réseau (tels que IP, APPN mentionnés plus haut): en effet, sans cela, un ordinateur connecté par ATM ne pourrait parler qu'à un autre ordinateur ATM. Rappelons qu'IP permet justement d'interconnecter des réseaux tels qu' Ethernet et Token Ring. Il est donc relativement simple d'ajouter ATM à cette liste, ce qui fut fait par l'IETF (Internet Engineering Task Force ) dans une série de RFCs (Requests For Comments , nom cryptique donné aux documents officiels de l'IETF). La solution spécifiée à l'heure actuelle (Figure 5), utilise ce qu'on appelle le modèle classique . Il fonctionne, dans les grands traits, de la façon suivante. Les ordinateurs ont des adresses IP (A1, A2) et des adresses ATM (a1, a2 ).

Figure 5: le modèle classique d'IP sur ATM

Il existe en fait une petite précision à apporter à cette description, qui a trait au concept IP de réseau logique . Un réseau logique est un ensemble d'adresses qui dans la pratique, correspond par exemple à tous les systèmes connectés au même Ethernet. Entre réseaux logiques, on communique par des routeurs; à l'intérieur d'un réseau logique, on n'utilise pas le routeur, mais directement le réseau Ethernet (par exemple). Le scénario précédent d'IP sur ATM ne s'applique que si les ordinateurs 1 et 2 sont définis comme appartenant au même réseau logique. Sinon la communication entre les ordinateurs 1 et 2 requiert l'intermédiaire d'un routeur, même si une connexion directe est possible par ailleurs. Or, les réseaux logiques sont utilisés comme unités administratives: ainsi il existe dans les entreprises d'une certaine taille un réseau logique par petite unité; cela permet de rationaliser la gestion des adresses IP; malheureusement, de ce fait, il n'est guère concevable de demander que tous les systèmes ATM ayant à communiquer entre eux appartiennent au même réseau logique. Avec le modèle classique, il peut donc être nécessaire d'utiliser des routeurs comme intermédiaires, même à l'intérieur d'un ensemble d'ordinateurs tous connectés à ATM. Le modèle classique utilise donc ATM comme un Ethernet (d'où son nom), et ne permet pas en général d'utiliser ATM de bout en bout.

Une solution à ce problème est en voie d'élaboration (NHRP, Next Hop Resolution Protocol ) et devrait être finalisée prochainement. Cette solution autoriserait des systèmes appartenant à des réseaux logiques différents à établir des connexions ATM directes entre eux. Cela représente une déviation du protocole IP original (qui impose l'emploi de routeurs entre réseaux logiques) et représente un changement logiciel plus important. Les problèmes à résoudre, et qui sont discutés à l'IETF à l'heure actuelle, concernent la présence de boucles persistantes introduites par cette déviation du protocole IP, si on l'utilise sans autre dans un environnement utilisant, lui, les protocoles existant. Ce problème n'existe pas avec le modèle classique.

Pour mémoire, il existe, à côté d'IP sur ATM, une autre solution pour interconnecter des systèmes utilisant IP et d'autres protocoles. Il s'agit de LAN emulation, qui est aujourd'hui spécifié par l'ATM Forum, et dont l'objet est d'émuler l'accès Ethernet ou Token Ring pour un système connecté à ATM. Cela permet de réutiliser tel quel le code de protocoles existants (par exemple IP, mais aussi AppleTalk, NetBIOS, APPN, IPX...), avec les mêmes limitations, déjà mentionnées, que le modèle classique d'IP sur ATM.

retour à la table des matières

ATM de bout en bout, RSVP

Nous avons présenté jusqu'ici les concepts fondamentaux d'IP et d'ATM, et comment on peut utiliser IP sur ATM. Dans tous les cas ainsi décrits, ATM intervient dans le même rôle qu'Ethernet ou Token Ring; le but d'IP sur ATM, comme de LAN Emulation, est précisément d'éviter de rendre visible aux applications les spécificités d'ATM. L'avantage principal d'utiliser ATM dans un tel contexte est, d'une part l'augmentation de capacité du réseau, d'autre part, la possibilité de configurer des réseaux logiques indépendants de la localisation.

Il est cependant un caractère d'ATM qu'il est intéressant de rendre visible aux applications: c'est la réservation de ressources, rendue possible parce qu'ATM utilise des connexions. La garantie de ressources est nécessaire pour transporter des flux tels que la vidéo ou l'audio avec une qualité commerciale. Il existe bien des expériences de transport de flux vidéo sur l'Internet, donc sans connexion ni garantie, mais la qualité est variable, imprévisible, et, au moins pour la vidéo, insuffisante pour des utilisateurs aux exigences habituelles.

Pour offrir des garanties de ressources, une solution est d'utiliser ATM de bout en bout. La Figure 6 illustre un scénario, tiré du projet Web sur ATM (voir plus loin dans cet article). Un client Web utilise l'Internet pour naviguer à travers les bases d'information; à la fin de cette phase de navigation, il obtient l'adresse (URL) d'un serveur où se trouve une séquence vidéo qu'il désire accéder. En même temps que l'URL du serveur, nous supposons qu'il obtient aussi l'adresse ATM du serveur, une identification de l'objet vidéo dans le serveur, et peut-être aussi son prix. Dans une seconde phase, le client établit alors une connexion ATM au serveur, sur laquelle la séquence vidéo est transmise. La qualité de la transmission est garantie à partir de ce moment, et l'utilisateur peut utiliser la connexion pour des fonctions de pause, avance accélérée, etc, utilisant le serveur comme un magnétoscope distant (remote VCR ).

Figure 6: magnétoscope distant dans le projet "Web sur ATM"

La figure 6 suppose un scénario de la double pile (dual protocol stack ). Le client Web implante, côte à côte, les protocoles TCP/IP sur ATM (pour la navigation sur le Web), et une pile ATM native (pour ATM de bout en bout vers le serveur). La double pile a l'avantage de la simplicité conceptuelle, et de la compatibilité avec l'Internet.

ATM de bout en bout a cependant l'inconvénient d'être... de bout en bout. Si un seul maillon de la chaîne entre le client et le serveur vidéo ne supporte pas ATM, alors le scénario n'est pas réalisable. Comme l'introduction d'ATM requiert, en général, le changement de carte d'interface de communication (sans parler du réseau), il faudra compter pendant longtemps avec des domaines sans ATM. Contrairement à IP, ATM n'est pas une technologie d'interconnexion.

Le multimédia a donc besoin d'un IP avec réservation . Plusieurs essais en ce sens ont déjà eu lieu: des protocoles tels que ST et ST.II jouent ce rôle et sont pour partie disponibles dans certains produits UNIX. Pour des raisons qu'il est trop long d'expliquer ici, l'IETF se tourne plutôt vers RSVP (Resource reSerVation Protocol), dont la standardisation est attendue pour la fin de cette année. Avec RSVP, il est possible de réserver les ressources nécessaires à une communication. Contrairement à ATM, RSVP est un protocole d'accompagnement d'IP, et ne demande pas de nouvelle carte d'interface de communication sur les ordinateurs. Cependant, pour fonctionner correctement, RSVP demande que les routeurs soient modifiés pour effectuer toutes les tâches liées à la réservation - tâches pour lesquelles les équipement actuels n'ont pas été conçus. Par contre, RSVP fonctionne (bien ou mal) même si une partie du réseau n'est pas capable d'effectuer la réservation. S'il existe suffisamment de capacité sur ladite partie, la communication multimédia sera de bonne qualité; sinon, pas. Enfin, contrairement à ATM, RSVP supporte très bien la communication de groupe (multicast ) (RSVP continuera d'exister avec IP version 6, la nouvelle version d'IP qui sera aussi stabilisée vers la fin de cette année. IP version 6 incorporera un concept de flow identification, ce qui revient à introduire, à côté du mode sans connexion, un mode avec connexion.).

Quelle est donc la place d'ATM dans un monde utilisant IP et RSVP ? Et quel est l'intérêt de RSVP si l'on possède ATM ? Comme toujours dans les réseaux, la réponse est mitigée:

En conséquence, on peut donc conjecturer à l'heure actuelle qu'ATM va s'implanter dans les réseaux locaux, soit directement, soit comme technologie d'interconnexion entre commutateurs (switched Ethernet, switched Token Ring) , et de même, les réseaux publics offriront des services large bande en utilisant une base ATM. Par contre, RSVP risque bien de s'imposer dans tous les cas où l'hétérogénéité est la règle. En particulier, on verra RSVP implanté même sur ATM, pour permettre à des systèmes ATM d'utiliser des communications à réservation de ressources avec des systèmes non ATM.

retour à la table des matières

Web sur ATM

La discussion précédente illustre la complexité de l'introduction d'ATM dans un monde d'ordinateurs, où les protocoles sont déjà légion. Contrairement à ce qu'on a pu écrire imprudemment, ATM ne va pas simplifier la gestion de réseaux dans un premier temps, bien au contraire. Un des problèmes essentiels est de préserver la possibilité de communication universelle offerte par IP (et les protocoles qui l'accompagnent), tout en tirant parti des bénéfices de performance, garantie de ressource, et facilités de gestion, offerts par ATM.

Le projet Web sur ATM a été lancé par la section de systèmes de communication (SSC) dans ce contexte. Son but est d'apporter des solutions permettant d'offrir la qualité ATM, et en particulier la qualité garantie, à un service Internet tel que le Web. Le projet regroupe des laboratoire du DI et du DE: LRC (coordinateur), LIG, LTI, LTS et TCOM. Les objectifs du projet sont:

Pour pouvoir implanter nos solutions nouvelles dans un environnement réel, le projet a besoin, pour les protocoles de bas niveau (RSVP et TCP en particulier) d'un système UNIX librement accessible; notre choix s'est porté sur LINUX, pour lequel nous développons donc maintenant le sous-système ATM. Les protocoles seront non seulement implantés dans un système réel, mais seront aussi développés avec le souci d'obtenir des spécifications propres et prouvées.

retour à la table des matières

Conclusion

 ATM apparaît dans un double rôle: comme successeur des Ethernet, Token Ring et FDDI dans les réseaux locaux, et comme infrastructure pour les réseaux publics. Un premier enjeu est de savoir si, dans les réseaux locaux, ATM restera limité aux fonctions d'infrastructure (à l'intérieur du réseau, entre concentrateurs et commutateurs), ou bien s'il s'imposera jusque dans les ordinateurs individuels. Un deuxième enjeu concerne la concurrence avec les protocoles de la famille TCP/IP qui, tels RSVP, permettent de réserver des ressources de bout en bout. Dans tous les cas, nous pensons qu'ATM sera la principale technologie nouvelle dans les réseaux pour les dix prochaines années, mais que le monde nouveau ainsi créé continuera d'être hétérogène.


article paru dans le Flash informatique, numéro spécial-été du 5 septembre 1995