Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Modeles de Transport de Donnees sur ATM Roland Acra Cisco Systems, Europe Intro

Modeles de Transport de Donnees sur ATM Roland Acra Cisco Systems, Europe Introduction ATM est une technologie de transfert asynchrone destinee a multiplexer de l’information heterogene sur une infrastructure commune: donnee, voix, video, etc. En pratique, il semble que les applications premieres sur ATM, dans sa phase de gestation actuelle, sont surtout le fait de transport de donnees a haut debit. Dans cette etude, nous explorerons les techniques normalisees mises en oeuvre lors du transport de donnees sur ATM. En particulier, nous examinerons les definitions d’interface de service, les couches d’adaptation, les methodes d’encapsulation de donnees sur ATM. Dans un second temps, nous explorerons les details des deux modeles principaux de transport de donnees sur ATM: le modele dit classique, propose par l’IETF, et le modele d’emulation de reseaux locaux (LAN Emulation) propose par l’ATM Forum. Nous examinerons egalement les normes recentes de routage entre noeuds de commutation ATM, les ebauches de normes de transport de donnees multiprotocoles sur ATM (MPOA) de l’ATM Forum et les techniques de diffusion (multicast) de donnees sur ATM, proposees par l’IETF. Normalisation Trois groupes interviennent dans la definition et l’adoption des normes autour d’ATM. L’UIT a ete a l’origine des premieres normes ATM et fait toujours office de corps de normalisation a valeur "officielle". Par ailleurs, le Forum ATM (ATM Forum) a pris une part active dans la normalisation des aspects jusque-la ignores par l’UIT, notamment en ce qui concerne le transport de donnees sur ATM. L’ATM Forum regroupe actuellement tous les acteurs dans le monde ATM: constructeurs, operateurs, utilisateurs. L’IETF (Internet Engineering Task Force) a egalement pris une part tres active dans la normalisation des couches d’interface entre les protocoles de systemes ouverts type TCP/IP et ATM. Ces normes sont complementaires de celles definies par l’ATM Forum, bien que l’on assiste actuellement a une convergence dans certains domaines tels que le transport multiprotocole sur ATM (MPOA). 1. Modele de Reference Deux elements principaux sous-tendent l’architecture ATM, a savoir la transmission en mode connecte, moyennant l’etablissement de circuits virtuels, et l’utilisation de cellules de taille fixe comme unites de transmission de l’information. La pile de protocole ATM comprend, a partir des couches basses, la couche physique, suivie de la couche ATM elle-meme. Une couche dite d’adaptation coiffe la couche ATM. Elle a pour fonction convertir un format d’informations qui peut etre divers (trames video, echantillons de parole, paquets de donnees) en cellules conformes. Deux types d’adaptation particulieres sont preconisees pour le transport de donnees: AAL3/4 et AAL5. Les couches de signalisation, de controle ou de donnees utiles viennent s’apposer au-dessus de la couche d’adaptation. En termes d’interfaces, on peut distinguer l’interface de bord de reseau, connue sous le nom de UNI (User-Network Interface) et l’interface inter-noeuds de commutation connue sous le nom de NNI (Network-Network Interface ou Network-Node Interface). L’interface NNI elle-meme est declinee en variantes publique et privee. 2. Les Couches Dites Basses 2.1. Couches Physiques La technologie ATM peut etre implementee sur plusieurs couches physiques, de type electrique ou optique et pour des distances limitees ou etendues. Au niveau des reseaux locaux, on notera la hierarchie numerique synchrone SDH (Synchronous Digital Hierarchy) permettant des debits allant de 155Mbps jusqu’a 2,4Gbps. SDH a ete normalise pour la transmission sur fibre optique. On trouve egalement la norme 4B/5B (TAXI) sur fibre optique ainsi que des normes pour cable a paires torsadees non-blinde (UTP), a 25Mbps, 51Mbps ou 155Mbps. 2.2. Couches d’Adaptation Les couches d’adaptation destinees au transport des donnees sur ATM sont au nombre de deux: AAL3/4 et AAL5. L’adaptation AAL3/4 est principalement utilisee dans les services publics de type non-connecte sur ATM (SMDS/CBDS). L’adaptation AAL5 est utilisee dans toutes les autres applications de donnees sur ATM, notamment dans les reseaux locaux et les services de type Relais de Trames (Frame Relay) sur ATM. Les couches AAL3/4 et AAL5 fournissent une fonctionnalite identique de fragmentation et de reassemblage, respectivement de paquets de donnees en cellules ATM et inversement. Bien que AAL3/4 presente certains aspects de robustesse supplementaire par rapport a AAL5, c’est de loin AAL5 qui est l’adaptation la plus repandue a ce jour. Cela est du a son adoption dans le reseau local, qui constitue actuellement le terrain le plus fertile de l’expansion d’ATM. 2.3. Signalisation L’etablissement de circuits virtuels ATM se fait de maniere administrative ("a la main") - generalement permanente ou semi-permanente - ou alors par l’utilisation de protocoles de signalisation. Les protocoles de signalisation sont actuellement normalises a l’interface UNI mais aussi, plus recemment, a l’interface NNI. Les normes adoptees sont derivees de la norme UIT Q.2931, qui est elle-meme derivee des normes de la famille Q.93B de signalisation RNIS. La signalisation ATM permet l’etablissement dynamique de circuits virtuels ATM mais aussi et surtout la negociation de parametres associes au circuit virtuel, tels que couche d’adaptation utilisee, taille de paquets maximum sur les equipements de bord, qualite de service souhaitee par les equipements de bord, etc. 2.4. Adressage La signalisation permet de placer des "appels" en bordure du reseau (UNI) ou au sein du reseau (NNI). Afin de signifier au reseau la destination souhaitee, un mode d’adressage est necessaire a l’interface UNI. Historiquement, le premier mode d’adressage ATM s’est base sur les adresses RNIS definies dans la hierarchie UIT E.164 . L’adressage retenu a l’ATM Forum se base sur l’espace d’adressage ISO, dont les adresses sont connues sous le nom de NSAP (Network Service Access Point). Cela permet un champs vaste d’application, qui englobe les adresses E.164 (qui peuvent etre codees en NSAP) mais aussi les adresses de reseaux locaux derivees des normes IEEE 802.X . Les adresses ATM peuvent etre pre-configurees de maniere administrative ("a la main") ou plus dynamiquement grace au protocole d’administration ILMI (Interim Local Management Interface). 3. Modeles d’Interconnexion Deux modeles differents ont ete proposes pour l’interconnexion de reseau dans l’environnement ATM. Le premier modele, connu sous le nom de modele de sous-resezu (subnetwork model), considere ATM comme une couche de sous-reseau (en nomenclature ISO et IP). Il prevoit donc la mise en oeuvre d’ATM "en dessous" des couches de reseau en usage actuellement, au meme titre que FDDI, Ethernet, Token Ring dans les LAN’s ou Frame Relay, SMDS/CBDS, RNIS, X.25 dans les reseaux etendus. Deux architectures ont emerge de la philsophie d’ATM en couche de sous-reseau: il s’agit du modele dit "classique" developpe par l’IETF et du modele dit d’emulation de LAN (LAN Emulation) developpe par l’ATM Forum. Par ailleurs, une modele dit "de parite" (Peer Model) a ete egalement propose. Ce modele preconise l’utilisation d’ATM "aux cotes" des architectures existantes plutot que de maniere sous-jacente. Il preconise des schemas de conversion de piles de protocoles, ainsi que des plans d’adressage et de routage globaux aux architectures diverses. Ce modele est largement moins developpe actuellement, en termes de normalisation et d’adoption dans l’industrie. 3.1. Le Modele Classique Nous examinerons dans cette section les modeles dits "classiques" d’encapsulation de donnees multiprotocoles sur ATM. Ces modeles sont principalement le fruit des travaux de l’IETF et sont codifies sous forme de RFC (Request For Comment), documents normatifs et garants d’interoperabilite de l’IETF. La philosophie du modele classique repose sur l’idee d’utilisation d’ATM comme une couche de sous-reseau (en nomenclature ISO et IP), qui correspondrait typiquement a un sous-reseau IP ou un reseau Novell ou XNS etc. Ce modele prevoit que l’inteconnexion de multiples couches de sous-reseau, qu’elles soient ATM ou autres, se ferait a la couche 3 (reseau) du modele ISO, c’est-a-dire au niveau IP ou CLNP ou IPX etc. ATM n’est alors pas considere comme une couche d’interconnexion globale mais plutot comme une couche de lien parmi d’autres. Une autre caracteristique du modele classique est celle de rendre les couches superieures (IP, CLNP, IPX, etc.) "conscientes" de l’existence de la couche ATM sous-jacente. Cela suppose donc des normes d’encapsulation et de resolution d’adresses par protocole de couche reseau. 3.1.1. Encapsulation Multiprotocole L’IETF a codifie l’encapsulation multiprotocole sur ATM AAL5 par le RFC1483. Ce document permet le multiplexage de protocoles multiples (TCP/IP, ISO CLNP, Novell IPX, DECNet, XNS, Apple, etc.) sur un meme circuit virtuel ATM. Cette encapsulation est actuellement implementee sur une multitude de materiels ATM, notamment les postes de travail et les routeurs. Le principe du multiplexage multiprotocole est base sur l’utilisation des champs ISO NLPID (Network Layer Protocol ID) et des champs IEEE LLC/SNAP (Logical Link Control / Sub-Network Access Point). Ceux-ci identifient de maniere non-ambigue tous protocoles de couche reseau (IP, CLNP, IPX, Apple, Vines, XNS, etc.) mais aussi les protocoles de couche de lien (802.3, 802.4, 802.5, etc.). L’encapsulation multiprotocole permet ainsi d’effectuer du transport de protocoles "routables" (c’est-a-dire munis de couches de reseau) mais aussi de protocoles "pontables" (c’est-a-dire non munis de couches de reseau). 3.1.2. La variante Frame Relay sur ATM Dans les reseaux etendus, les services Frame Relay peuvent etre a leur tour implementes sur ATM. Dans la mesure ou des normes d’encapsulation de donnees multiprotocole sur Frame Relay existaient deja, celles-ci permettent de multiplexer plusieurs protocoles sur des circuits virtuels Frame Relay, eux-meme implementes sur une infrastructure ATM. L’IETF uploads/Litterature/ transport-de-donnes-sur-atm 1 .pdf