FrRelay (C Ang)

TELECOM 98
Frame Relay Principes et applications
Matthieu BRIAND (mattbr@mail.dotcom.fr)

Avril 1997
Abstract
Throughout the history of information technology, there have been many changes in the way in which information is stored, retrieved, presented and used. There seem to be continual improvements in the way in which technology is utilized and the applications to which it is put. However the rate of change in the industry has never seemed to be quite as rapid. The major changes over recent years have included local area networks and the widespread digitalization of the public network infrastructure ; but these changes have taken several years before being generally accepted and used. Frame Relay surfaced as a protocol in its own right in 1989 ; before that it was part of the ISDN standards. Since that time there has been much debate, disagreement, and controversery over the nature of the benefits of this new communications protocol. Many claims have been made as to its capabilities in various situations from data networking (taking over from X25) through LAN interconnection, across WAN, even to the realms of passing voice and video information. However the reality is somewhat removed from many of the claims and the applicability of frame relay is very closely tied into the application and the networking infrastructure. What makes Frame Relay so attractive ? maybe the fact that you pay for a rate that you can outperform in burst speed (Bc) without paying for the extra bits ? maybe the fact that the protocol in itself is very closed to the most popular interconnection protocol in Europe, X25 which makes updates to Frame Relay easier ? the simplicity of the basic Frame Relay protocol compared to ATM ?
Frame Relay is also very original in the fact that instead of trying to correct errors during data transmission, it discards the frames that are causing problems. This is done, for example, when a lot of people are creating what is call a congestion (when too many people are in burst mode). In this case either notification bits (FECN, BECN) or CLLM protocol is used to inform the end user of the problem : the end user will then suspend for a few seconds his data transfer. Virtual circuits (permanent ie PVC or switched ie SVC) are the basis of Frame Relay implementation : they are adressed by DLCI, and the LMI protocol makes their administration simplier. As an interconnection protocol, Frame Relay has two interfaces : one for user to network (UNI), and the other for Network to Network (NNI used for interconnection of frame relay networks). Voice over Frame Relay is not so far away : in 1997 Frame Relay Forum will vote an implementation called VoFR. Market of Frame Relay in France is shared between 3 operators : BT, AT&T and Transpac (FT). Some firms already use Frame Relay for their Wide Area Networks in Europe.
Frame Relay : Principes et applications / EPITA TELECOM 98
Rsum
Les besoins en terme de bande passante ont amen les comits de normalisation rflchir des techniques permettant doptimiser les dbits. Les travaux de lIUT-T dans le cadre du RNIS, Rseau Numrique Intgration de Services ont donn naissance au I.233 (Frame Mode Bearer Services), protocole jug intressant et vite repris par un groupe de constructeurs nomm Groupe des Quatre (Cisco, Nortel, Stratacom et DEC) au dbut des annes 90. A ce groupe vinrent se rajouter dautres constructeurs qui contriburent eux aussi dvelopper ce protocole au sein du Frame Relay Forum. Le Frame Relay ou relayage de trame en franais, a connu un essor important de par ses qualits intrinsques : un dbit minimum garanti dnomm CIR peut tre dpass dans des priodes de burst ce qui permet ladaptation du dbit au type dapplication utilis, le client ne paye quen fonction du dbit minimum garanti demand, cest un protocole simple de niveau 2 qui possde beaucoup de points communs avec le protocole X25 de commutation de paquets, protocole dominant en Europe le march des interconnexions de rseau, ce qui permet dadapter facilement les quipements X25 pour les rendre compatible Frame Relay
Le concept original derrire le Frame Relay est que lors de ces courtes priodes o le dbit garanti, CIR, est dpass, et en cas de congestion (tous les utilisateurs dpassent le dbit garanti en mme temps sur la mme ligne), les trames supplmentaires sont dtruites (en appliquant le principe du Discard Eligibility) et cest lutilisateur de dpart de renvoyer les trames ensuite Pour viter ce type de problme (les congestions) des bits de la trame Frame Relay (BECN et FECN) peuvent tre u tiliss pour notifier les congestions aux n ds du rseau afin de suspendre momentanment le flux en excs. Le u mcanisme CLLM contribue lui aussi avertir le rseau de ce type de problme en utilisant un canal ddi. Frame Relay est bas sur les circuits virtuels, chaque circuit possdant un numro particulier appel DLCI. Un mcanisme de signalisation dnomm LMI permet de connatre le statut de ces circuits virtuels dnomms PVC ou SVC suivant leur nature permanente ou commut. Une interface dinterconnexion de rseaux Frame Relay existe sous le sigle NNI quil faut diffrencier de UNI, qui correspond linterface entre lutilisateur et le rseau Frame Relay. Pour rpondre aux besoins dun grand nombre dutilisateurs, le passage de la voix sur le rseau Frame Relay est en cours de normalisation. Les offres commerciales Frame Relay en France sont dispenss par BT, AT&T et Transpac (FT). De nombreuses socits Europennes croient au Frame Relay en tant que solution dinterconnexion de rseaux, mme sil est menac en cela par lmergence dATM.
SOMMAIRE
Abstract ________________________________________________________________ 2
Introduction _____________________________________________________________ 6
1. Remarques gnrales sur le Frame Relay____________________________________ 7

1.1 Le Frame Relay, une commutation au niveau liaison sans reprise sur erreurs ____________________ 7 1.2 Le Frame Relay : fonctionnalits _____________________________________________________ 8 1.3 Frame Relay : les circuits virtuels ____________________________________________________ 9 1.4 Frame Relay : le mode burst et le CIR ______________________________________________ 10
PRINCIPES _____________________________________________________________ 12
2. Fonctionnement dtaill du protocole ______________________________________ 13
2.1 Linterface physique ____________________________________________________________ 2.2 La trame Frame Relay ____________________________________________________________ 2.3 Mcanisme de gestion des exceptions _______________________________________________ 2.3 Adressage (DLCI) ______________________________________________________________ 2.4 Gestion des congestions (DE,FECN,BECN et CLLM) ____________________________________ 2.4.1 DE_______________________________________________________________________ 2.4.2 FECN, BECN _______________________________________________________________ 2.4.3 CLLM ____________________________________________________________________ 2.5 Signalisation (LMI) _____________________________________________________________ 2.5.1 Signalisation unidirectionnelle __________________________________________________ 2.5.2 Signalisation bidirectionnelle ___________________________________________________ 2.5.3 Signalisation asynchrone______________________________________________________ 2.6 Network to Network Interface (NNI FRF 2.1) _________________________________________ 2.7 Circuit virtuel commut (SVC FRF 4) _______________________________________________ 13 13 15 16 21 21 22 23 27 30 35 36 37 40
3. Les volutions futures du Frame Relay : la voix sur le Frame Relay______________ 43
APPLICATIONS _________________________________________________________ 49
4. Les offres commerciales Frame Relay _____________________________________ 50
4.1 Loffre commerciale des constructeurs de commutateurs __________________________________ 4.2 Loffre commerciale des oprateurs de tlcommunication_________________________________ 4.2.1 Loffre de France Tlcom _____________________________________________________ 4.2.2 Loffre de BT _______________________________________________________________ 4.2.3 Loffre de AT&T ____________________________________________________________ 50 52 53 57 58
5. Prsentation dun matriels spcifiques au Frame Relay : Le FRAD _____________ 59
6. Prsentation de quelques rseaux Frame Relay Europens _____________________ 61

6.1 Le rseau FR Finnpap____________________________________________________________ 61
6.2 Le rseau FR Danzas ____________________________________________________________ 6.3 Le rseau FR AMS______________________________________________________________ 6.4 Le rseau FR Infonie ____________________________________________________________ 6.5 Un exemple de rseau FR transportant de la voix________________________________________
62 63 64 65
Conclusion _____________________________________________________________ 67
ANNEXES ______________________________________________________________ 68
Glossaire (dfini par le Frame Relay Forum) __________________________________ 69
Bibliographie ___________________________________________________________ 71
Brochure publicitaire Transpac : le service Frame Relay ________________________ 71
Etat du march FR en 1996 ________________________________________________ 76
Exemples de normes FRF :_______________________________________________ 102

FRF1.1 (UNI) ____________________________________________________________________103 FRF3.1 (Encapsulation)_____________________________________________________________118 FRF4 (SVC) _____________________________________________________________________130
Introduction
Au cours du temps, de nombreux protocoles de communication ont t dvelopps et implments, certains ont connu le succs, dautres non. Durant les annes 60 et 70, ctait commun pour les fabricants dordinateurs de dvelopper leurs propres protocoles qui utilisaient leurs propres environnements et pas les autres. Pendant les annes 70, IBM publia la premire spcification darchitecture de communication de donnes dite ouverte sous le nom de SNA (Systems Network Architecture). Cest aussi dans les annes 70 quune nouvelle spcification de protocole connue sous le nom de X25 naquit, introduite non pas par un constructeur dordinateur mais par une organisation de standardisation : le CCITT. Issu des travaux du CCITT dans les annes 80 dans le cadre des travaux sur le RNIS (normes : I.233 Frame mode bearer services part 1, Q.922 ISDN data link layer specification for frame mode bearer services, Q.933 ISDN signalling specification for frame mode bearer services, I.370 congestion management for the ISDN frame relaying bearer service, I.372 et I.555) le Frame Relay a t dfini comme un protocole de transfert de donnes caractris par des temps de transit sur le rseaux faibles et une correction derreur trs limit (de telles caractristiques permettaient de mieux sadapter la qualit des lignes qui voluait vers des taux derreur de plus en plus faibles). Certains constructeurs ont jug que le protocole mritait un intrt particulier et ont implment une version en dehors du monde du RNIS. Ce groupe, connu sous le nom de groupe des quatre (DEC, Northern Telecom, Cisco and Stratacom) produisit un document le 18 Septembre 1990 connu sous le nom de Frame Relay Specification with Extensions based on Proposed T1S1 Standards. Ce document fut propos tout vendeur dsireux de limplmenter. Un second groupe de vendeurs fut cr quelques mois aprs cette proposition, le Frame Relay Forum, pour dvelopper cette technologie. Cest cette technologie que nous vous proposons dtudier dans la suite. Ce document a t conu pour rpondre deux objectifs : connaissance thorique du protocole en lui-mme avec un tat de lart des amliorations que la norme a ou va subir depuis sa premire spcification, application pratique de ces connaissances dans le cadre dune mise en rseau (aspect matriel et cot dune telle solution)
Ce document sadresse donc deux publics (un public technique qui lira le document du dbut jusqu la fin et un public plus commercial qui lira la prsentation gnrale de la technologie et continuera en lisant la seconde partie).
1. Remarques gnrales sur le Frame Relay

Avant de se lancer pleinement dans le protocole, nous allons prsenter quelques principes gnraux caractrisant la technologie Frame Relay.
1.1 Le Frame Relay, une commutation au niveau liaison sans reprise sur erreurs
Le but dune commutation au niveau de la liaison, qui se dcline en commutation de trames et en relayage de trames, est damliorer en performance la commutation de paquets (ex : X25) en simplifiant le nombre de niveaux de larchitecture prendre en compte. En reportant la commutation au niveau 2 de larchitecture, on simplifie considrablement le travail des n ds. En effet, dans une commutation de paquets, u on attend de recevoir correctement une trame, avec des retransmissions potentielles, puis on travaille sur le paquet. Un acquittement est envoy vers le n d prcdent et u on garde une copie tant que le n d suivant na pas fait parvenir un acquittement u positif. Un autre avantage du relayage de trames est lintroduction dune signalisation spare du transport des donnes. La mise en place de la connexion de niveau 2 seffectuera par une connexion logique diffrente de celle de lutilisateur. Les n ds u intermdiaires nont donc pas se proccuper de maintenir cette connexion. Les contrles derreurs et de flux sont reports aux extrmits de la connexion. La simplification du travail effectu par les n ds in termdiaires est trs importante. On u considre que lon gagne un ordre de grandeur. Il faut voir le relayage de trames comme une amlioration de la recommandation X25 en simplifiant fortement les fonctionnalits dans les n ds intermdiaires. On u retrouve cependant le mme type de service et finalement des caractristiques assez proches. Pour mieux illustrer ces proprits voici un graphe qui compare les complexits des 2 techniques :
X.25
NO
Frame Relay
NO
Valid Frame
NO
Discard Non-Info Process

NO
Valid Frame
Discard
Information Frame Valid Ack Rotate Window
NO
Error Recovery
Address OK
Discard
NO
Frames Ack Restart timer Stop Timer

NO
Non Congested
Recovery congestion
Sequence OK Send L2 Ack
Error recovery
Level 2
NO
data packet
NO
Supervisory proc Error recovery

NO
Level 3
Active LCN Valid Ack

NO
Error recovery Error recovery
Sequence OK Send L3 Ack
FORWARD PACKET
FORWARD FRAME
Le relayage de trames est une simplification de la commutation de trames, technique aujourdhui inusite : dans les n ds intermdiaires, on commute les trames sans tenir u compte des erreurs potentielles lintrieur de la trame et dune ventuelle reprise sur erreurs, du squencement, du temporisateur de reprise, etc.
1.2 Le Frame Relay : fonctionnalits

La normalisation du Frame Relay sappuie sur la recommandation Q.922 (et plus particulirement sur le noyau de base de cette recommandation : Core Q.922). On utilise les fonctionnalits compltes aux extrmits de la connexion et celles du noyau dans les n ds intermdiaires. Les fonctionnalits de cette recommandation sont les u suivantes : adresse, inspection de la trame pour vrifier quelle possde un nombre entier doctets avant insertion ou aprs extraction des 0 intgrs pour la transparence, inspection de la trame pour vrifier quelle nest ni trop courte, ni trop longue, dtection des erreurs de transmission et demande de retransmission dans les lments extrmits de la connexion, fonction de contrle de flux de bout en bout dlimitation, alignement et transparence des trames, multiplexage et dmultiplexage des trames en utilisant le champ
Les deux dernires fonctionnalits ne font pas partie du noyau et ne sont donc entreprises quaux extrmits de la connexion. On peut comparer les trois types de commutation utiliss pour le transport des donnes informatiques. Les caractristiques sont donnes dans le tableau suivant. Par comparaison, on voit bien que le relayage de trames savre le plus efficace mais seulement si le taux derreurs en ligne est tout fait ngligeable. Les retransmissions de niveau 2 sont obligatoirement effectues de bout en bout ; en effet, on ne soccupe pas de la zone de dtection derreur quau niveau du n d de sorti e du u rseau. Ce relayage de trames na dailleurs de signification que parce que le progrs sur la rduction du taux derreurs en ligne ont t considrable ces dix dernires annes.
Pour mieux cerner les diffrences entre les diffrents types de commutation, voici un tableau qui rsume les diffrences majeures de fonctionnalits entre chaque type :
Paquet (X.25) Formatage Transparence Existence dun CRC Contrle derreurs Contrle de flux Reprise et Redmarrage Oui Oui Oui Oui Oui Oui
Commutation de trames
Relayage de trames
Oui Oui Oui Oui Oui Non
Oui Oui Oui Non Non Non
1.3 Frame Relay : les circuits virtuels

Un des aspects importants du Frame Relay est le type de connexion qui est support. Le Frame Relay a t conu pour tre un protocole simple, et les implmentations initiales manquaient de messages de configuration et de libration dappel. Le protocole en lui-mme ne contient pas dadresse de type rseau.
Linformation dadressage na quune valeur locale (voir la partie sur DLCI). Le Frame Relay a t initialement dfini comme tant un protocole orient connexion permanente : une connexion entre 2 utilisateurs est tablie de faon permanente et ne peut pas tre annule nimporte quand. Ce mode dopration est appel circuit virtuel permanent (CVP ou PVC par la suite) et est tout de mme bien restreint car les utilisateurs ne peuvent pas mettre en place de connections vers dautres utilisateurs la demande. La connexion sera mise en place (par un ingnieur rseau) quand le rseau dmarre et sera disponible de faon permanente jusqu ce que le rseau lui-mme sarrte. Une nouvelle norme, appele circuit virtuel commut (CVC ou SVC par la suite) a t mise en place pour rpondre ce besoin mais elle nest que peu utilise actuellement (voir la partie sur SVC).
1.4 Frame Relay : le mode burst et le CIR

Un des principaux avantages du Frame Relay est sa capacit supporter les pics de charge (bursts) des utilisateurs. Comme il n'y a aucun contrle de flux, les utilisateurs ont la possibilit d'envoyer autant de donnes sur le rseau qu'ils en ont envie et ceci n'importe quel moment. Par contre le gros inconvnients du Frame Relay pour le prestataire de service est qu'il ne sait pas comment dimensionner son rseau en fonction de la bande passante dont ont besoin les diffrents utilisateurs. Le Frame Relay n'a aucun moyen de forcer un utilisateur cesser d'envoyer des donnes si le rseau est satur. Il y a des mcanismes pour signifier l'utilisateur qu'il peut y avoir des problmes l'intrieur du rseau si des donnes continuent y tre envoyes. Le rseau recommande alors de cesser l'envoi de donnes pendant un moment. Mais l'utilisateur ne le fait que s'il respecte le " gentleman's agreement " du rseau. Les messages de notification de congestion sont envoys l'intrieur des trames de donnes. Si l'utilisateur ne respecte pas les conseils du rseau et continu mettre des donnes, la congestion va augmenter et c'est pour cela que le CIR ( committed information rate ) a t cr. Le CIR est le dbit de donnes que l'utilisateur est sur de voir passer dans le rseau n'importe quel moment et sans aucun problme. Le CIR n'a aucun lien avec le dbit rel de la ligne de l'utilisateur. Un utilisateur peut avoir une ligne 2Mbps et avoir, par exemple un CIR de 64Kbps. Cela signifie que l'utilisateur sera toujours sur de passer 64Kbps, mais en pic de charge il pourra faire passer sur la ligne jusqu' 2Mbps. Le prestataire dimensionnera sa ligne en fonction des 64Kbps du CIR et non en fonction du dbit physique de la ligne. Que se passe-t-il quand l'utilisateur souhaite dpasser le CIR ? A partir du moment o lutilisateur opre un dbit de ligne physique suprieur celui planifi, il est donc possible que parfois il veuille faire passer plus de donnes sur le rseau que ce qui est lorigine prvu. Le rseau va tenter de laisser passer ses donnes s'il lui reste de la bande passante libre (lutilisateur dispose ce sujet de 2 indicateurs : le Burst
Dbit nominal

N
Trames rejetes
10
autoris ou Bc et le Burst en excs ou Be Be sajoute Bc : les trames envoyes en Be+Bc sont rejetes voir schma).
Cependant cette procdure a des limites. Un des critres fondamentaux du Frame Relay est que s'il y a des problmes le rseau a le droit de dtruire les trames. C'est une approche logique vu le faible taux d'erreur des lignes du rseau Frame Relay. Comment le rseau distingue les donnes qui ne dpassent pas le CIR et celles qui sont en sus ? Toutes les trames qui ne dpassent pas le CIR contiennent un indicateur, le "discard eligibility". Cet indicateur se trouve dans les trames de donnes et est mis un si les trames dpassent le CIR. Les donnes qui ont l'indicateur DE ( discard eligibility ) positionn un sont susceptibles d'tre dtruites par le rseau. La destruction des donnes marques DE n'intervient que si le rseau est surcharg ou en voie de l'tre. La mthode exacte pour dterminer quelles trames pourront tre marques DE est dtermine par le fabricant des quipements Frame Relay, mais un mcanisme classique est bas sur le CIR et sur le temps : sur une priode de temps T, un compteur est mis jour avec le montant de donnes que lutilisateur envoie sur le rseau. Quand les donnes dpassent le CIR de lutilisateur, le rseau marque les trames fautives avec le bit DE jusqu la fin de la priode T. Cette approche est assez grossire et ne distingue pas les donnes importantes pour l'utilisateur de celles qui ne le sont pas mais le rseau accepte que l'utilisateur marque lui-mme certaines trames DE. Si l'utilisateur marque lui-mme ces trames en DE, elles ne seront pas prises en compte pour le calcul du CIR. Le CIR est particulirement appropri pour l'utilisation dans un contexte de rseau public Frame Relay. Un prestataire de service peut offrir des CIR diffrents tarifs sur des lignes physiques 2Mbps. Il n'y a aucun rapport entre le CIR et le dbit physique de la ligne. Le prestataire de service peut alors offrir d'autres garanties d'acheminement des trames qui respectent le CIR tout en permettant aux utilisateurs de dpasser ce CIR dans des pics de charges, mais leurs risques et prils. Le graphique suivant explicite la diffrence entre CIR et trames marques DE
Trames marques DE Committed Information Rate
temps priode T
11
PRINCIPES
12
2. Fonctionnement dtaill du protocole

Dans cette partie, nous allons dtailler le protocole Frame Relay en nous attachant plus son fonctionnement interne.
2.1 Linterface physique

Le Frame Relay est issu des travaux sur le RNIS : linterface physique est donc linterface daccs classique ou primaire du RNIS. Malgr tout le Frame Relay Forum permet dutiliser de multiples interfaces telles : V.35 , G.703 et G.704, X.21
Toutes ces interfaces autorisant uniquement un dbit de 2,048 Mb/s ; la norme UNI (User to Network Interface) Frame Relay (FRF1) a t amende en Janvier 96 pour ajouter le support des interfaces plus rapides suivantes (norme FRF1.1) : Ansi-530-A-1992, HSSI (High Speed Serial Interface) 52Mb/s, DS3 Interface 44Mb/s, E3 Interface 34Mb/s, V36 et V37 (2-> 10 Mb/s)
2.2 La trame Frame Relay

La plupart des protocoles (comme X25 ou SNA) utilisent une trame drive de la high level data link control procedure HDLC ou de la synchronous data link control procedure SDLC. LAPD est le driv de HDLC utilis dans le RNIS sur lequel le Frame Relay est bas. Rappelons la composition dune trame de type HDLC : Flag Champ dadresse Champ de contrle Champ dinformation FCS Flag
Comme le Frame Relay nimplmente pas toutes les fonctions du HDLC, quelques lments ont t omis et dautres ont t regroups : cest le cas des champs dadresse et de contrle qui ont t regroups dans un champ simple de type header et appel lui aussi champ dadresse.
13
Les champs suivant du HDLC ont t conservs : - Le Flag : de type 01111110 Comme tous les flag, ils indiquent la fin ou le dbut dune trame et permet la synchronisation. Pour viter que cette squence de bits ne se retrouve de nouveau lintrieur de la trame, on ajoute un 0 aprs une squence de 5 bits 1. De la mme faon, le rcepteur recherchera lui aussi 5 bits 1 et enlvera le bit 0 qui suit cette squence. Le champ dinformation :
Il contient les donnes de lutilisateur (donnes brutes ou trames provenant dautres protocoles et encapsules). Le Frame Relay Forum recommande une taille de 1600 octets avec une taille minimale de 1 octets. Ces donnes sont transmises sans tre interprtes. Le FCS ou Frame Check Sequence :
Cest un champ qui sert sassurer que la trame na pas t transmise avec des erreurs. Il fait 2 octets et correspond au polynme (x16 + x12 + x5 + 1) dfini par le CCITT. Le Frame Check Sequence effectue un contrle sur tous les bits de la trame lexception des enttes et enqueues. Voyons maintenant les spcificits de la trame Frame Relay : Flag Champ dadresse Champ dinformation FCS Flag
Composition du champ adresse : (2 octets) Adresse CR EA Adresse FECN BECN DE EA
Le champ adresse : constitu des 6 bits de poids fort du premier octet et des 4 bits de poids fort du second octet. Concatns, ces 10 bits forment ladresse qui reprsente ladresse dun utilisateur du rseau Frame Relay, et on lappelle plus couramment Digital Link Connexion Identifier. Nous verrons par la suite que cette adresse peut tre tendue sur 24 bits. Le bit CR (Commande / Response indication bit) : inutilis ce bit est pass de faon transparente sur le rseau Le bit EA (extended adress bit) : ce bit permet dtendre ladressage : si le bit EA est 0 cela veut dire que ladresse se poursuit dans
Frame Relay : Principes et applications / EPITA TELECOM 98 14
loctet suivant jusqu ce que le bit EA soit mis 1. Malgr tout le standard Frame Relay est une adresse sur 2 octets. Les bits FECN/BECN (Forward/Backward Explicit Congestion Notification bit) : ces 2 bits permettent dindiquer lutilisateur quune congestion a eu lieu dans un sens ou dans lautre. FECN est mis 1 si une congestion a eu lieu dans le sens de traverse de la trame. BECN indique une congestion dans le sens oppos de transport de la trame. Malgr tout il ny a aucune obligation pour lutilisateur du systme de rception de tenir compte de cette information. Nous verrons par la suite les mcanismes lis aux congestions Le bit DE (Discard Eligibility) : ce bit sert lui aussi dans les situations de congestion : sa mise un permet de notifier au rseau que cette trame peut tre dtruite en cas de congestion car elle dpasse le CIR (cf. : supra). Il peut tre mis un par lutilisateur ou le rseau. Il faut aussi noter que des trames nayant pas le bit DE un peuvent aussi tre dtruite en cas de congestion si ncessaire
Tous les champs ci-dessus doivent tre prsent dans chaque trame qui est transporte entre 2 systmes. Il est important de noter qu lintrieur du protocole Frame Relay, il ny a aucune obligation ou mcanisme permettant de passer des messages de signalisation entre utilisateurs (Le protocole LMI Local Management Interface que nous verrons par la suite va dans ce sens). Une autre remarque propos de la comparaison Frame Relay / HDLC : le Frame Relay ne possde pas dinformations de squencement entre trames et donc ne ncessite pas de numro de squence ou de messages de contrle pour confirmer la rception.
2.3 Mcanisme de gestion des exceptions

Nous allons voir comment le protocole Frame Relay gre les erreurs dans les trames. Le principe gnral du Frame Relay est que si une trame est bonne, elle est envoy son destinataire en suivant la route approprie. Par contre, sil y a un problme sur le rseau, par exemple une congestion, les n ds du rseau sont autoriss dtruire la u trame pour corriger le problme. De plus, ces mmes n ds peuvent dtruire les trames juges invalides sans prvenir le u destinataire. Sont dclares invalides, les trames de la forme suivante : une trame qui a moins de 5 octets entre lentte et lenqueue, une trame dont le FCS (contrle de type CRC) est invalide, une trame qui ne contient pas une adresse valide, une trame qui contient un DLCI non support (voir le paragraphe sur le DLCI)
15
rseau -
une trame qui dpasse la taille configure entre lutilisateur et le
une trame qui ne possde pas une entte ou une enqueue
En ce qui concerne le traitement des trames qui dpasseraient la longueur maximale, le groupe des quatre laissait libre au constructeur limplmentation de la procdure effectuer (qui tait en gnral de dtruire la trame). Par contre limplmentation du CCITT et de lANSI y ajoute 2 alternatives supplmentaires : faire suivre une partie de la trame jusquau destinataire puis dtruire la trame (utile pour certains types dquipement qui ne bufferisent pas compltement chaque trame avant de lenvoyer sur le rseau) faire suivre toute la trame jusquau destinataire avec un FCS correct (ce type dimplmentation sera trs peu utilis car la plupart des matriels ont des buffers qui sont configurs pour une taille maximale fixe)
De plus, certaines rgles doivent tre respectes : en cas de non transmission de donnes, on doit envoyer des flags sur le rseau frame relay, le rseau ne peut pas lire ou modifier les donnes contenues dans le champ de donnes de la trame Frame Relay, lexception de celles contenues dans la trame utiliss par le protocole LMI (que nous verrons dans la suite) un des DLCI est rserv pour le protocole LMI et ne peut donc tre utilis
2.3 Adressage (DLCI)

Ladressage en Frame Relay seffectue en donnant un numro de circuit virtuel entre lutilisateur et le rseau et na quune valeur locale. Ces identificateurs locaux sont nomms par le sigle DLCI pour Digital Link Connexion Identifier. Ils peuvent dsigner des circuits virtuels permanents (PVC) comme des circuits virtuels commuts (SVC). Leur fonction correspond celle des LCN, Logical Circuit Number, de X25. Pour mieux illustrer cette valeur locale dun DLCI voici un schma :
16
Utilisateur A Vers C (DLCI 121) Vers D (DLCI 78) Rseau Frame Relay
Utilisateur D Vers B (DLCI 37) Vers A (DLCI 38)
Vers A (DLCI 435)
Vers D (DLCI 78) Utilisateur B
Utilisateur C
Origine Utilisateur A Utilisateur A Utilisateur B
DLCI 121 78 78
Destination Utilisateur C Utilisateur D Utilisateur D
DLCI 435 38 37
Nous voyons bien dans cet exemple que lutilisateur A et lutilisateur B utilisent un mme DLCI sans que cela ne pose un quelconque problme de part la valeur locale de cet identificateur. Comme les DLCI nont seulement quune valeur locale, il est de la responsabilit du rseau de faire la liaison entre le DLCI de dpart de le DLCI darrive en passant par diffrent rseaux de DLCI lintrieur du rseau Frame Relay. Voici comment fonctionne lattribution des DLCI au niveau dun n d de rseau : u chaque n d possde une table de commutation qui associe un u DLCI sur une voie entrante un DLCI sur une voie sortante ainsi quune voie de sortie. A larrive dune trame, le n d de commutation va effectuer le u processus suivant : lecture de la valeur du DLCI, lecture dans lentre de la voie darrive la voie de sortie, remplacement de la valeur du champ DLCI de la trame par la nouvelle valeur, mise dans la file dmission de la voie indique dans la table de la trame
17
Illustrons cette proprit par un exemple : Notre n d Frame Relay possde 4 voies u
V1
DLCI = 10
DLCI = 96
V3 V3 Noeud FR V4 V4
DLCI = 45 DLCI = 56
V2
DLCI = 27 DLCI = 40
Table de commutation de la voie 1 DLCI entrant 10 26 39 Voie de sortie 2 3 4 DLCI sortant 56 64 98
18
Comme nous lavons vu prcdemment le DLCI est cod dans le champ adresse de la trame Frame Relay. Par dfaut la taille du champ adresse est de 2 octets (soit 1023 DLCI possibles) mais les spcifications de lANSI et du CCITT permettent son extension 3 (65535 DLCI) voire 4 octets (8M+ DLCI) grce lutilisation du bit EA (Extended adress) : Si le bit EA est 0, le champ adresse nest pas termin et se poursuit sur l octet suivant Si le bit EA est 1, le champ adresse est termin
Pour mieux illustrer cette proprit, voici les 3 cas possibles de champ adresse : Cas 1 : 2 octets : le plus utilis : 8 7 6 5 4 3 0 2 1 EA=0
DLCI (bits de poids fort)
19
DLCI (bits de poids faible)
FECN BECN DE
EA=1
Cas 2 : 3 octets : spcification ANSI/CCITT 8 7 6 5 4 3 2 0 FECN BECN DE D/C 1 EA=0 EA=0 EA=1
DLCI (bits de poids fort) DLCI DLCI (bits de poids faible)
Cas 3 : 4 octets : spcification ANSI/CCITT 8 7 6 5 4 3 2 0 FECN BECN DE 1 EA=0 EA=0 EA=0 D/C EA=1
DLCI (bits de poids fort) DLCI DLCI DLCI (bits de poids faible)
Les champs de 2 octets peuvent paratre suffisants pour un n d Frame Relay mais les u champs de 3 et 4 octets ont une utilit sur les interfaces Frame Relay de type Network to Network. Une connexion Network to Network est dfinie comme une connexion entre 2 rseaux Frame Relay adjacents (Nous verrons linterface NNI par la suite). Certaines valeurs de DLCI sont rserves pour lusage du rseau :
20
Valeurs DLCI
Champs sur 2 octets 0 1 - 15 Champs sur 3 octets 0 1 - 1023 Champs sur 4 octets 0 1 - 131 071
Fonctions
Canal utilis pour le LMI : intgrit des liens et signalisation des appels Rserv pour utilisation future
16 - 991
1024 - 63 487
131 072 8 126 463
Disponible pour les circuits virtuels (temporaires ou permanents)
992 - 1007
63 488 64 511
8 126 464 8 257 535 8 257 536 8 388 606
Rserv pour la gestion du rseau FR (par exemple pour le CLLM) Rserv pour utilisation future
1008 - 1022
64 512 65 534
1023
65 535
8 388 607
.Utilis pour faire passer des messages de gestion dinterfaces en rapport avec les protocoles de couches suprieures
Ce tableau nous permet de voir que sur les 1023 DLCI dun champ adresse sur 2 octets seulement 976 sont disponibles. De mme avec un champ adresse sur 3 octets, seulement 62 463 DLCI sont disponibles. Le champ sur 4 octets laisse, lui, 7 995 392 possibilits.
2.4 Gestion des congestions (DE,FECN,BECN et CLLM)

Une congestion apparat lorsque tous les utilisateurs dpassent le dbit qui leur est accord : le rseau Frame Relay possde des procdures pour notifier lutilisateur ce type de problme. Nous avons regroup dans cette partie les diffrents moyens mis en vre pour essayer de remdier ce type de problme. u
2.4.1 DE
Nous avons dj vu dans la partie Frame Relay : le mode burst et le CIR comment fonctionnait le bit DE (Discard Eligibility, qui marque les trames qui dpassent le CIR) de la trame Frame Relay.
2.4.2 FECN, BECN

Nous avons aussi pu voir lors de ltude de la trame Frame Relay, les bits FECN (Forward Explicit Congestion Notification) et BECN (Backward Explicit Congestion Notification) : explicitons un peu mieux leur fonctionnement. Ces 2 bits sont dnomms explicit congestion notification bits et sont utiliss pour envoyer des informations lutilisateur final sur ltat du rseau et les congestions qui peuvent y exister. Une congestion peut apparatre lintrieur du rseau sur nimporte quel noeud, et peut affecter soit lintgralit du rseau, ou plus simplement nimporte quel DLCI oprant sur ce noeud. Lors dune congestion, le n d est capable de le notifier au priphrique u distant en changeant ltat du bit de notification de congestion (FECN ou BECN est mis 1) dans les trames Frame Relay. FECN est mis 1 dans les trames qui passent dans la direction de la congestion (quand un FECN est reu par lutilisateur final cela indique que la trame est passe par une zone de congestion lintrieur du rseau). BECN est utilise dans le sens inverse de la congestion (quand un BECN est reu par lutilisateur de dpart cela indique quune congestion a eu lieu lintrieur du rseau). Le principe derrire FECN est que tous les utilisateurs derrire la congestion seront informs du problme et pourront peut tre prendre des dcisions pour allger le problme. Dans de nombreux cas les utilisateurs derrire la congestion utilisent un protocole (encapsul dans la trame FR) qui ncessite des acknowledgement pour les donnes reues. Une mthode pour faire chuter le t afic rseau est de retarder ces r acknowledgements. Cela force lutilisateur de dpart suspendre lenvoi de nouvelles donnes avant la confirmation de la rception des donnes prcdentes. Ceci est un exemple dutilisation des mcanismes de fentrage des protocoles traditionnels audessus du Frame Relay pour rsoudre les problmes rseaux. Le principe derrire BECN est que si un utilisateur reoit un BECN, il sait quil envoie des donnes sur le rseau qui causent ou contribuent une congestion. La meille ure chose serait de suspendre temporairement la transmission de trames sur le rseau pour allger la congestion. Le problme du BECN est quil sera seulement reu par lutilisateur de dpart si les donnes remontent dans la direction inverse, loppos du flot de congestion. Beaucoup dapplications oprent en half duplex (un message est envoy dun utilisateur lautre et lutilisateur de dpart attend que la destination est rpondue avant de renvoyer des informations supplmentaires). Les rseaux Frame Relay typiques transportent du trafic dapplication full duplex. Il y a donc un dialogue continu entre les systmes finaux. Le succs du BECN dpendra donc plus du comportement du priphrique de rception que de celui des applications. Voici un schma qui rsume les sens de passage de FECN et de BECN :
22
Congestion dans cette direction
Priphrique d'accs
BECN
FECN
Priphrique d'accs
2.4.3 CLLM
Un des problmes majeurs avec les mcanismes de gestion de congestion lintrieur du protocole Frame Relay est que les messages de notification de congestion (FECN et BECN) sont transports lintrieur des trames de donnes et ne sont pas envoys lutilisateur sil ne les sollicite pas ( linverse des autres protocoles synchrones qui fournissent des flots de messages de contrle spars). Le principal problme de ce type de fonctionnement est le manque de possibilit dinformer lutilisateur quil congestionne le rseau sil ny a pas de donnes qui passe dans la direction oppose. Le protocole Frame Relay repose sur la mise 1 du bit FECN dans les donnes qui sont envoyes destination, ce qui amne celui qui a envoy les donnes diminuer son trafic momentanment. Ce type de procdure est non seulement, irraliste, mais probablement difficile mettre en vre car elle demande une coordination du contrle u de flux entre chaque extrmits. Pour que la procdure de contrle de flux FECN marche, les priphriques des utilisateurs doivent coordonner leurs protocoles de haut niveau de telle manire quun FECN reu au niveau de la trame signalera aux niveaux suprieurs quune baisse du taux de transfert doit tre signal lutilisateur distant. Cette situation a amen lANSI et le CCITT dvelopper un mcanisme optionnel appel Consolidated Link Layer Management (CLLM). CLLM est utilis sur un DLCI spar de celui du flux de donne et existe pour passer des messages de contrle de niveau couche de liaison du rseau vers lutilisateur. Avec un champ dadresse de 2 octets, le DLCI 1023 est utilis pour le CLLM. Quand un n d du rseau est u congestionn, il peut soit utilis les bits FECN ou BECN lintrieur des trames de donnes sur le DLCI de lutilisateur, soit le message CLLM sur un DLCI de management, ou les deux. Le message CLLM contient une liste de DLCI qui peuvent causer la congestion, et demande implicitement que le propritaire du DLCI suspende temporairement la transmission . Il est aussi possible que le message CLLM transporte une liste de DLCI non actifs. Bien que ces DLCI ne causent pas de congestion, le message indique lutilisateur du rseau Frame Relay que ces DLCI ne doivent pas tre activs sinon ils pourront probablement aggraver la congestion Le message CLLM
23
(pour un champ dadresse de 2 octets) est reprsent dans le schma ci dessous et est contraint la mme taille maximale quune trame de typ e Frame Relay. Il peut tre ncessaire denvoyer plus quun message CLLM si la liste de tous les DLCI affects ne tient pas dans une seule trame. Les formats pour des DLCI de 3 et 4 octets ont t dfini dans les spcifications ANSI/CCITT mais nous les omettrons de cet expos pour plus de clart. Le message CLLM provient de limplmentation ISDN du Frame Relay. A lintrieur du rseau ISDN, le CLLM serait envoy lintrieur dune trame LAPD XID (exchange identification) travers le canal D de lISDN. Le format du message est rest inchang quand il a t transmis limplmentation non ISDN du Frame Relay, mme si beaucoup de champs ne sont pas exactement en rapport. 8 0 1 1 1 1 0 7 1 1 1 0 0 0 6 1 1 1 1 0 0 5 1 1 1 0 0 0 4 1 1 X 1 0 1 3 1 0 X 1 0 1 2 1 R X 1 1 1 1 0 0 1 1 0 1 Drapeau CLLM Octet adresse 1 ( R = Rponse ) CLLM Octet adresse 2 ( X = non pris en compte) Champs de contrle XID Identificateur du format ( 130 ) Identificateur du groupe = 15 Longueur groupe ( octet 1 ) Longueur groupe ( octet 2 ) 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 1 1 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1 1 0 0 0 1 Identificateur de paramtre = 0 (identificateur de paramtre) Longueur du paramtre (4) Valeur paramtre =105 ( en ASCII "I" ) Valeur paramtre =49 ( en ASCII "1" ) Valeur paramtre =50( en ASCII "2" ) Valeur paramtre =50 ( en ASCII "2" ) Identificateur de paramtre=2 (identificateur de cause) Longueur du paramtre (1) Valeur de la cause 0 0 0 0 0 0 1 1 Identificateur de paramtre=3 (identification des DLCI)
24
Signification
DLCI) Longueur du paramtre (2n) Octet 1 valeur du DLCI (1er DLCI) Octet 2 valeur du DLCI (1er DLCI) ... Octet 1 de valeur du DLCI (nime DLCI) Octet 2 de valeur du DLCI (nime DLCI) Frame Check Sequence Frame Check Sequence 0 1 1 1 1 1 1 0 Drapeau
Les champs lintrieur du message CLLM sont dcrits ci-dessous : Informations contenues dans le header (les 8 1ers octets) : Les octets dadresse : Dans lexemple donn, ladressage sur 2 octets est utilis. Si un adressage sur 3 ou 4 octets est utilis (en utilisant le bit EA) les DLCI contenu ultrieurement dans le message seront aussi de ce format. Le champ dadresse contient le DLCI 1023 en format binaire. Il faut noter que ceci reprsente l'usage du CLLM sur des rseaux Frame Relay non ISDN , car quand le Frame Relay est utilis sur un rseau ISDN cette adresse peut tre diffrente. Le bit R est normalement mis 1 pour indiquer une trame de rponse XID, la mthode classique pour transmettre un message CLLM. Le champ de contrle XID : Ce champ indique que la trame reprsente un XID LAPD et est utilis pour garder la compatibilit avec limplmentation ISDN du Frame Relay. Lidentificateur de format : Ce champ est aussi un champ fixe qui a pour valeur 130. Lorigine de cette valeur vient de la spcification ISO 8885, qui le dfinit comme un identificateur dintrt gnral. Le champ de groupe : Lidentificateur de groupe est toujours mis la valeur 15 qui est assigne par lISO 8885 pour indiquer des paramtres privs. Le champ longueur du groupe est un champ de 16 bits qui reprsente la longueur du reste du message Group Value (le nombre doctets entre ce champ et le FCS) Champ Group Value (les octets suivant jusquau FCS) : Champ identificateur de paramtre : Le champ identificateur de paramtre (en anglais : parameter set identifier) consiste en un champ header (indicateur densemble de paramtres privs 0) et un champ de longueur (toujours mis 4) suivi de 4 octets qui
25
contiennent le caractre alphanumrique I122. Cela indique que le message est un ensemble de paramtre priv pour le protocole I.122. Champ identificateur de cause de congestion : Ce champ contient le message qui indique la cause de la congestion du rseau. Le champ consiste en un header (identificateur de cause 2) et un champ de longueur (toujours mis 1). Ceux ci sont suivi par un champ de cause, tabli par le rseau , qui indique la cause de la congestion rseau, et qui est cod conformment au tableau suivant : 2 1 1 1 1 1 1 0 0 1 0 1 0 1 0 1 0 1 Equivalent dcimal : cause de congestion
2 : Congestion de courte dure due un trafic excessif temporaire 3 : Congestion de longue dure due un trafic excessif temporaire 6 : Panne temporaire d'un quipement 7 : Panne de longue dure d'un quipement 10 : Maintenance de courte dure 11 : Maintenance de longue dure 16 : Congestion de courte dure - cause inconnue 17 : Congestion de longue dure - cause inconnue
8 0 0 0 0 0 0 0 0
7 0 0 0 0 0 0 0 0
6 0 0 0 0 0 0 0 0
5 0 0 0 0 0 0 1 1
4 0 0 0 0 1 1 0 0
3 0 0 1 1 0 0 0 0
Si le champ didentificateur de cause est manquant du message CLLM, le message entier sera ignor. Tous les messages de congestion sont considrs comme tant de courte ou de longue dure. Mme si la signification de courte ou longue dure est dpendante de limplmentation, le standard recommande que court terme signifie un problme transitoire qui durera probablement quelques secondes ou minutes, alors que le long terme sappliquera tous les autres cas. Champ identificateur de DLCI : Ce champ contient la liste des DLCI qui sont congestionns. Les adresses DLCI dans la liste sont formates de la mme manire que le champ dadresse DLCI (longueur : 10 bits, bits 8 3 du 1er octet et 8 5 du 2 nd octet, le reste tant rserv pour des usages futurs). Le champ de header contient la valeur 3. Le champ de longueur contient la longueur du champ qui donne les DLCI congestionns (par exemple, si les adresses de 2 octets sont utilises, et n DLCI sont reports, le champ contient la valeur binaire de 2*n). Comme le champ de longueur pour cet ensemble de paramtres fait seulement un octet, un maximum de 255 octets peut tre utilis pour report les DLCI congestionns, si plus est ncessaire, alors plusieurs messages CLLM doivent tre utiliss. Si le champ didentification des DLCI est manquant du message CLLM, le message entier sera ignor.
26
2.5 Signalisation (LMI)

Le protocole Frame Relay comme dcrit jusqu prsent atteint les objectifs qui lui ont t fixs : cest un mcanisme de transport de donnes haute vitesse qui offre la possibilit doffrir de la bande passante la demande pour ses utilisateurs. Comme le protocole est bas sur des PVC il ny a pas besoin de procdure et connexion et de dconnexion de circuits. Il ny a pas non plus de besoin pour un contrle de flux ou des mcanismes de recouvrement derreurs. Frame Relay tel quil est dcrit offre un mcanisme basique de transport de donnes. Malgr tout, le protocole tel quil est dcrit ne permet pas un contrle local ou une gestion de linterface, et il ny a pas non plus de moyen pour que le systme final dtermine le statut de sa connexion. Pour ces raisons, les instances de standardisation ont inclus des mcanismes de signalisation dans le protocole. Laspect important de ces protocoles de signalisations est quils sont dsigns uniquement pour complter le protocole de base Frame Relay en tant que supplment. Il est parfaitement possible dimplmenter une interface Frame Relay et de faire passer des donnes sans mcanismes de signalisation. Ils permettent simplement lutilisateur dobtenir plus dinformation sur le statut du rseau et sont donc considrs comme tant optionnels. Cette gestion se nomme LMI pour Local Management Interface et passe par le DLCI 0. Le but principal du LMI est de fournir lutilisateur le statut et les informations de configurations relatifs aux PVC utiliss par linterface Frame Relay. Le LMI est seulement utilisable au niveau des interfaces entre lutilisateur et le rseau et inclus les fonctionnalits suivantes : notification de laddition, de la suppression et de la prsence de PVC au niveau de linterface, notification de la disponibilit dun PVC pr-configur, un mcanisme de polling qui assure la continuit de la liaison.
Mme si le LMI est considr comme optionnel par l s organismes de normalisation, e beaucoup des amliorations du Frame Relay ont t faits dans cette voix et serviront amliorer lefficacit gnrale du protocole. Voyons plus en dtail le protocole LMI qui sillustre par la trame suivante : 8 0 0 0 0 0 7 1 0 0 0 0 6 1 0 0 0 0 5 1 0 0 0 0 4 1 0 0 0 1 3 1 0 0 0 0 2 1 0 0 1 0 1 0 0 1 1 0 Signification Drapeau En-tte : DLCI = 0, CR = 0 FECN = 0, BECN = 0 Indicateur de trame non numrote Champs identificateur du protocole
27
Rfrence d'appel Type du message Premier dlment dinformation Deuxime lment d'information ... Nime lment d'information Frame Check Sequence Frame Check Sequence
Drapeau
Le protocole LMI se conforme toutes les rgles standard du Frame Relay relatives la structure de trame et aux oprations du protocole. Les champs de la trame LMI sont : Header : Cest le header standard du Frame Relay et il utilise toujours le DLCI 0 pour le champ dadresse. Cest cette adresse qui spcifier que le message est un message LMI car aucun autre trafic ne peut utiliser le DLCI 0. Cela constitue une sorte de signal out-of-band par le fait que toute la signalisation des circuits des utilisateurs (DLCI 16-991) a lieu sur le DLCI 0, aucune signalisation nintervenant lintrieur des circuits utiliss par les utilisateurs. Il est not que quelques vendeurs utilisent le DLCI 1023 pour le LMI (standard du groupe des quatre, 0 tant le standard ANSI/CCITT). Indicateur de trame non numrote : Le protocole LMI est plus proche du protocole LAPD que le protocole de transfert Frame Relay. Une indication de cela se trouve dans la prsence de ce champ qui indique que la trame est une trame non numrote (qui ne contient aucune squence numrote et qui na donc aucune possibilit dtre contrl par un contrle de flux). Ce champ est toujours prsent lintrieur des messages LMI et est toujours cod par 0 0 0 0 0 0 1 1. Lutilisation du LMI de cette faon permet un degr raisonnable de compatibilit pour les services
28
Frame Relay travers des rseaux RNIS ou non RNIS, et une migration douce entre les deux. Identificateur du protocole : Il est toujours mis 0 0 0 0 1 0 0 0 et est retenu pour la compatibilit avec les procdures RNIS du Frame Relay. Dans ces procdures, le discriminateur du protocole est utilis pour distinguer les messages de contrle dappel des autres messages. Rfrence dappel : La rfrence dappel est utilis durant ltablissement des SVC (circuits virtuels commuts nous verrons les SVC dans la suite de cet expos). Les messages qui ne sont pas relatifs ltablissement ou la clture dappels ont ce champ mis 0 0 0 0 0 0 0 0. Type de message : Le but de ce champ est didentifier le type de message de gestion envoy travers le LMI. Il y a un code standard pour le contenu de ce champ qui dpend du type gnral de message et du numro de message spcifique. Il y a actuellement 3 types de messages gnriques : tablissement dappel, clture dappel, et message divers. Cette section parlera seulement des messages divers qui sont relatifs aux PVC. Les autres messages seront rapidement abords dans la partie relative aux SVC. Voici un tableau des codages de messages divers : 8 0 0 0 7 1 1 1 6 1 1 1 5 1 1 4 1 0 3 1 1 2 0 0 1 1 1 Commentaire Message divers Statut Demande de statut
A lintrieur du champ de type de message, le bit 8 est toujours mis 0 pour permettre la possibilit future de lutiliser comme un bit dextension de la mme manire que le bit EA dans le header de la trame Frame Relay. Les bits 7 5 sont mis 1 1 1 indiquant que lon a un message divers. Les bits restant contiennent des numros de messages spcifiques dtaills ci dessus. Elments dinformation : Les lments dinformations contiennent les dtails spcifiques propre au message de gestion LMI. Il y en a gnralement un et habituellement plus dun, lment dinformation lintrie ur dun message. Les lments dinformation peuvent consister en un octet simple ou en une multitude doctets de tailles
diverses. Le codage de la longueur variable de linformation est dcrit par le schma suivant :
8 0
Identificateur dlment dinformation
Longueur du contenu de linformation en octets
Contenu de llment dinformation
Il y a 3 diffrents mcanismes de signalisation lintrieur du LMI : signalisation unidirectionnelle (utilise en UNI) signalisation bidirectionnelle (utilise en NNI) signalisation asynchrone (conseille en cas dutilisation de PVC et de SVC sur la mme connexion) La signalisation unidirectionnelle est la forme basique de polling du LMI, et un mcanisme de signalisation non balanc ou le rseau et lutilisateur utilisent des messages diffrents. Le bidirectionnel est une forme spciale de la signalisation unidirectionnelle dans laquelle le rseau et lutilisateur utilisent tous les deux les mmes procdures. La signalisation asynchrone est une forme diffrente de procdure qui ne se base pas sur des squences de polling.
2.5.1 Signalisation unidirectionnelle

Le LMI unidirectionnel basique est constitu de 2 messages : STATUS et STATUS ENQUIRY. Ils sont utiliss pour raliser diffrentes activits au sein du LMI, incluant
30
une vrification dintgration du lien, la notification de laddition ou de la libration dun PVC et la notification de disponibilit dun PVC. Le LMI implmente une procdure de polling priodique (aussi appele heartbeat process ) qui est un mcanisme pour passer les messages de statuts entre lutilisateur et le rseau. Chaque T391 (paramtre configurable de 5 30s et par dfaut 10s ) secondes, lutilisateur envoie un STATUS ENQUIRY au rseau. Ce STATUS ENQUIRY demande une rponse au rseau pour confirmer lintgrit du lien. Le rseau rpond en envoyant un message STATUS contenant les lments dinformations sur lintgrit du lien. Un compteur est mis jour avec le nombre de cycles de polling qui ont eu lieu. Aprs N391 (paramtre configurable de 1 255 et par dfaut 6) STATUS ENQUIRIES, lutilisateur demande un statut complet la place dune simple intgrit du lien. Le rseau rpond alors avec un message STATUS qui fournit les lments dinformations pour chaque PVC configur sur cette liaison Frame Relay. Si une lment dinformation sur un PVC est manquant du rapport de statut, cela doit tre interprt comme une libration du PVC de linterface Frame Relay.
Utilisateur
status enquiry
Rseau
status (intgrit de la liaison)
status enquiry status (intgrit de la liaison) status enquiry
status (intgrit de la liaison) status (statut complet)
status enquiry
status enquiry
status (intgrit de la liaison)
Le format du message STATUS ENQUIRY dfini par le CCITT est le suivant :
8 0
7 1
6 1
5 1
4 1
3 1
2 1
1 0 Drapeau
Commentaire
31
0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 0
0 0 0 0 0 1 0 0
0 0 0 0 0 1 1 0
0 0 0 1 0 0 0 0
0 0 0 0 0 1 0 0
0 0 1 0 0 0 0 0
0 1 1 0 0 1 1 1
En tte : DLCI = 0 (adr LMI), CR = 0 FECN = 0, BECN = 0 Trame non numrote Champs identificateur du protocole Rfrence d'appel Type du message: Status Enquiry Elment dinformation type de rapport Longueur lment d'information = 1 Type de rapport
0 0
1 0
0 0
1 0
0 0
0 0
1 1
1 0
Elment dinformation vrification de l'intgrit du lien Longueur lment d'information = 2 Numro de squence envoy Numro de squence reu Frame Check Sequence Frame Check Sequence
Drapeau
Il est noter que le message contient toujours 2 lments dinformation, llment dinformation type de rapport et llment dinformation vrification de lintgrit du lien. Llment dinformation type de rapport est requis et peut tre lun des 3 suivant : 8 0 0 0 7 0 0 0 6 0 0 0 5 0 0 0 4 0 0 0 3 0 0 0 2 0 0 1 1 0 1 0 Type de rapport Statut complet Vrification d'intgrit du lien seul Statut asynchrone d'un seul PVC
La requte de statut complet est envoye pour avoir le statut complet de tous les PVC configurs travers linterface. La rapport dintgrit du lien est envoy pour obtenir une squence de nombres intermdiaires. (NB : le statut asynchrone que nous verrons rapidement par la suite possde un rapport de statut qui est envoy pour obtenir des dtails sur un unique PVC)
32
La squence de vrification de lien a t dfinie pour sassurer qu la fois lutilisateur et le rseau sont assurs de la stabilit et de la validit de la connexion physique et logique entre eux. Lintgrit du lien est vrifie par une squence de gnration de nombre et un processus de vrification. Chaque fois que lutilisateur envoie un message STATUS ENQUIRY, le nombre de squences envoyes est incrmentes et plac dans le champ nombre de squence envoyes de llment dinformation de vrification du lien. Lutilisateur place aussi la dernire squence reue dans le champ nombre de squence reue du STATUS ENQUIRY. Llment dinformation intgrit du lien est dtaill ci dessous (version CCITT) :
8 0 0
7 1 0
6 0 0
5 1 0
4 0 0
3 0 0
2 1 1
1 1
Commentaire Identificateur de llment dinformation intgrit du lien
0 Longueur du contenu de la vrification dintgrit de lien (2) Nombre de squences envoyes Nombre de squences reues
Quand le rseau reoit le message STATUS ENQUIRY, il gnre un message STATUS, incrmente son propre nombre de squences, le place dans llment dinformation et renvoie aussi le dernier nombre de squences reu par lutilisateur. Les squences de nombres sont codes binairement de 0 255 de manire cyclique. Le nombre 0 est seulement utilis pour le nombre de squences initialement reu, car cest le seul moment o ce nombre est indfini. Ultrieurement si un 0 est reu, on considre quil y a eu une erreur. Le rapport de statut complet est envoy tous les N391 (voir supra pour la valeur de cette variable) cycles de polling en mettant lindicateur de message STATUS ENQUIRY dans le message STATUS ENQUIRY statut complet. Ds lors le rseau envoie un rapport de statut complet qui contient un lment dinformation pour chaque PVC existant. Le but de ce rapport complet est dinformer lquipement de lutilisateur de laddition de nouveaux PVC et de leurs statuts. On distingue lexistence et la disponibilit des PVC car un PVC nouvellement cr peut tre indisponible pour des raisons de dlais de cration. Pour illustrer ce propos on peut prendre comme exemple, ltablissement dun PVC entre utilisateurs de rseau Frame Relay. Cela prend un certain temps pour tablir une liaison bout bout (ce temps est dpendant de limplmentation choisie). En labsence de mcanisme temps rel pour ltablissement de circuit, lutilisateur est uniquement guid par le contenu du message STATUS. En consquence, pendant que le PVC est tabli, lutilisateur reoit un message de
33
STATUS qui diffrencie entre un circuit qui est en train dtre tabli et un circuit qui est tabli. Tout ceci est rendu possible par lutilisation dindicateur de statut pour les PVC qui diffrencie entre PVC actif et PVC nouveau. Llment dinformation correspondant au statut du PVC est report ci dessous :
8 0
7 1
6 0
5 1
4 0
3 1
2 1
1 1
Longueur du contenu du statut du PVC (ici 3) 0 ext. 1 ext. 1 ext. 0 0 Spare 0 Nouv 0 0 Spare DLCI 0 0 Spare Actif 0 0 DLCI
Llment dinformation statut du PVC contient le DLCI du PVC report et 2 bits qui dterminent si le PVC est nouveau et/ou actif. Le rseau met 1 le bit nouveau ds lors quun PVC est ajout par le centre de gestion du rseau. Le rseau continue de mettre 1 le bit nouveau dans le message de statut complet jusqu ce quil reoive le message STATUS ENQUIRY de la part de lutilisateur et que celui contienne un nombre de squences reues gal au nombre de squences envoyes courant (le nombre de squences envoyes transmis dernirement dans le message STATUS). Ds lors que cette synchronisation a eu lieu le rseau met le bit nouveau lintrieur du message de statut du PVC 0.
34
Lindication dun nouveau PVC ne permet pas lquipement de lutilisateur de commencer transmettre sur ce PVC. Cest seulement lorsque le rseau le met ltat actif que lutilisateur peut transmettre des donnes sur ce PVC particulier. Ce bit actif est mis lorsque le rseau lui-mme est convaincu quun chemin vers la destination existe (quand le PVC est donc pleinement tabli). De part la nature non temps rel du processus, nous pouvons assister aux cas suivant : Le PVC est disponible mais cause de problme de timing dans le message de statut complet des PVC, un seul des utilisateurs est prvenu de ltat actif de ce PVC. Cet utilisateur envoie donc des trames sur le PVC qui sont envoyes la destination avant que celle ci nait reu un message de statut actif Le PVC devient indisponible sur le rseau, mais du des problmes de temps avec les messages de statut complet des PVC, lutilisateur nest pas averti de ltat inactif du PVC. Lutilisateur envoie donc des donnes sur ce PVC. La rponse de lutilisateur ou du rseau nest pas dfini dans la spcification du protocole Frame Relay qui suggre simplement que laction doit tre dpendant de limplmentation. Lapproche la plus probable pour les vendeurs est de dtruire les trames qui sont reus sur un PVC vu comme tant inactif. Une approche plus prfrable est de bufferiser les donnes jusqu ce que le PVC devienne actif.
2.5.2 Signalisation bidirectionnelle

Dans la partie prcdente, les STATUS ENQUIRY provenaient de lutilisateur (ou du DTE) et les messages STATUS provenaient du rseau (ou du DCE). Ce type de procdure peut convenir beaucoup dapplications mais un protocole balanc est prfrable pour garder un meilleur quilibre entre les 2 cts de linterface. Les procdures bidirectionnelles sont considres comme tant une spcification optionnelle du Frame Relay et ne sont utilises que dans le cas daccords bilatraux. Ces procdures bidirectionnelles sont principalement utilises dans le cadre de diffrents rseaux physiques (via linterface NNI que nous verrons par la suite) ce qui permet chaque rseau dinterroger lautre pour avoir des informations de statut. Les procdures bidirectionnelles sont trs proches de celles unidirectionnelles vues prcdemment : elles ne diffrent quen un seul point : les messages STATUS ENQUIRY et STATUS sont gnrs par les 2 cts de linterface. Voici un schma qui illustre ce propos :
35
Utilisateur
status enquiry
Rseau
status
status enquiry status
status
status enquiry
status enquiry status
Dans les procdures bidirectionnelles chaque ct de linterface Frame Relay agit la manire dun utilisateur (DTE) et dun rseau (DCE). Malgr tout mme si chaque ct agit suivant les mmes procdures, les paramtres associs aux compteurs utiliss (N391, T391 etc) peuvent tre diffrents. De plus chaque ct de linterface envoie et reoit des nombres de squences pour chaque direction du flux dinformation. Cela signifie donc que chaque ct de linterface possde un compteur dmission et de rception de squences pour chaque direction du protocole LMI. Les procdures bidirectionnelles sont utiles dans les situations o les quipements rseau doivent interagir (entre des commutateurs Frame Relay par exemple) ou entre des rseaux Frame Relay (via linterface NNI).
2.5.3 Signalisation asynchrone

Lune des faiblesses du protocole LMI est le dlais quil met informer lutilisateur (ou le rseau) de changements concernant les PVC. Par exemple : si le compteurs T391 et N391 (vu prcdemment) sont rgls par dfaut il peut scouler 60 secondes avant que lutilisateur soit inform de ltat inactif dun PVC. Bien videmment pendant ces 60 secondes, lutilisateur aura envoy des informations (avec un CIR de 256Kbps cela quivaut environ 14Mbits de donnes). Cest pour cette raison que lon a cr les messages mise jour asynchrone. Cela consiste en les messages standards STATUS ENQUIRY et STATUS mais envoys ds lors que le statut dun PVC change. Les messages mise jour asynchrone contiennent des informations sur un unique PVC (celui dont le statut a chang). Ce type de message peut tre utilis la place des modes bidirectionnels ou unidirectionnels grce des accords entre les 2 parties qui oprent sur la connexion Frame Relay. Malgr tout, quand les SVC et les PVC oprent sur la mme connexion
36
rseau, il est recommand que seulement les types de messages asynchrones soient utiliss pour faire passer les informations sur les changements de statuts des circuits.
2.6 Network to Network Interface (NNI FRF 2.1)

Prcdemment nous avons tudi linterface UNI (User to Network Interface). UNI est une interface qui permet aux utilisateurs daccder un rseau Frame Relay public ou priv et dtablir un chemin de communication lintrieur du mme rseau. Pour tendre lutilisation du protocole Frame Relay, et pour rendre les connections entre diffrents rseaux Frame Relay possible, il a t ncessaire de fournir une mthode dinterconnexion entre rseaux Frame Relay. Ces diffrents rseaux Frame Relay peuvent tre considrs comme tant des sous rseaux lintrieur dun plus grand rseau. Les interconnections sont notamment ncessaires dans les domaines suivant : Services Frame Relay public (exemple : Transpac) fourni par un oprateur public ou un fournisseur valeur ajoute Des rseaux de transit fournis par un oprateur ou un fournisseur valeur ajoute pour interconnecter 2 rseaux Frame Relay Des rseaux Frame Relay privs utiliss par des compagnies prives pour leurs propres services Frame Relay
On peut localiser linterface NNI au niveau des points suivants : Relay de transit Entre un rseau public Frame Relay de transit et un autre rseau public Frame Relay de transit Entre un rseau priv Frame Relay et un rseau public Frame Relay de transit Relay Entre 2 rseaux privs Frame Relay Entre un rseau priv Frame Relay et un rseau public Frame Entre un rseau public Frame Relay et un rseau public Frame
Quelques-unes de ces possibilits sont illustres ci-dessous :
37
Abonn UNI
Abonn UNI
Rseau FR priv
NNI NNI
Rseau FR priv
NNI
NNI
Rseau FR public
NNI
Rseau FR priv
NNI NNI
UNI Abonn
Rseau FR priv
Le NNI a t conu pour fournir une interface efficace entre 2 sous-rseaux Frame Relay. Le NNI traite les transferts de donnes grande vitesse , la gestion des congestion et le transfert et la signalisation de la disponibilit des PVC. Le NNI est bas sur les mmes standards que lUNI part que le NNI ncessite un LMI bidirectionnel et le mode asynchrone est fortement recommand. Le NNI est bas sur le concept des segments de PVC : chaque segment contient un rseau complet et est li par un UNI dun ct et un NNI de lautre, ou par un NNI des 2 cts. En voici un exemple :
38
UNI segment de PVC
NNI segment de PVC
NNI segment de PVC
UNI
Utilisateur
Rseau Frame Relay
Rseau Frame Relay
Rseau Frame Relay
Utilisateur
PVC multi rseau
On appelle PVC multi-rseau la concatnation de 2 ou plus segments de PVC. Sur un PVC multi-rseau, les rseaux Frame Relay opreront la fois du ct utilisateur et la fois du ct rseau. Au niveau de lUNI, le rseau oprera avec des procdures ct rseau (en rpondant au message STATUS ENQUIRY). Au niveau du NNI, le rseau oprera la fois du ct utilisateur et du ct rseau simultanment (en rpondant aux messages STATUS ENQUIRY et STATUS). Cest donc un service bidirectionnel qui est requis pour le NNI. En plus des procdures bidirectionnelles, le NNI pourrait tre capable de supporter les procdures de messages asynchrones dans chaque direction pour obtenir une mise jour des statuts en temps rel quand cela est ncessaire. Nous pouvons illustrer ce propos par le schma suivant :
Procdures unidirectionnelles UNI
Procdures bidirectionnelles NNI
Procdures unidirectionnelles UNI
Utilisateur DLCI a
segment PVC segment PVC DLCI b
Utilisateur
DLCI c
rseau Frame Relay
rseau Frame Relay
39
Il faut aussi noter que le NNI utilise lui aussi un adressage local avec des DLCI diffrents chaque interface (UNI ou NNI). Comme le NNI implmente des procdures bidirectionnelles, il doit aussi implmenter les timers et compteurs associs. Le NNI implmente des compteurs et des timers spars pour chaque direction lintrieur du NNI, et garde aussi un nombre de squences spar pour e mcanisme de vrification du lien pour chaque direction. l Malgr tout il est fortement recommand que le NNI implmente les mmes valeurs pour les timers et les compteurs de chaque ct du NNI (le compteur de polling, N391, peut lui tre diffrent).
2.7 Circuit virtuel commut (SVC FRF 4)

Il est communment admis que pour que le Frame Relay devienne un protocole de communication rpandu, des mthodes de mise en place et de dconnexion de circuits sont requises. Cela permettra aux utilisateurs dutiliser le Frame Relay pour des objectifs autres que linterconnexion de rseaux, et de faire passer du trafic pour des destinations diffrentes un peu la manire dun rseau X25. Mme si les SVC (CVC en Franais) sont un concept simple, leur implmentation est loin dtre simple. Le protocole SVC est bas sur un sous-ensemble du protocole de signalisation RNIS Q.933 (Signalling Specification for Frame Mode Bearer Service). Tous les messages qui sont utiliss dans les procdures SVC passent par le UNI sur le canal de signalisation (canal 0), et non sur celui de lutilisateur. Les messages qui sont envoys travers ce canal sont formats de la mme manire que les messages LMI classiques (ils contiennent un header et des lments dinformations). Par contre pour les procdures SVC le champ rfrence dappel qui tait auparavant vide est maintenant utilis.
8 0 0 0 0 0 0 0
7 1 0 0 0 0 0 0
6 1 0 0 0 0 0 0
5 1 0 0 0 0 0 0
4 1 0 0 0 1 0 1
3 1 0 0 0 0 0 0
2 1 0 0 1 0 0 0
1 0 0 1 1 0 1 0
Signification Drapeau En-tte : DLCI = 0, CR = 0 FECN = 0, BECN = 0 Indicateur de trame non numrote Champs identificateur du protocole Rfrence d'appel (longueur du champ valeur : ici 1 octet) Rfrence d'appel : Flag sur le bit 8 puis bit 7 1 : valeur de la rfrence dappel
40
Type du message Premier dlment dinformation Deuxime lment d'information ... Nime lment d'information Frame Check Sequence Frame Check Sequence 0 1 1 1 1 1 1 0 Drapeau
Le champ rfrence dappel (voir schma ci dessus) : sa signification est locale et peut tre de 2 ou 3 octets. Le format en 2 octets est le plus rpandu. Le 1er octet indique si la valeur de la rfrence dappel prend 1 ou 2 octets, le 2me octet contient la valeur de la rfrence dappel et le flag pour la rfrence dappel. Ce flag est utilis pour indiquer quel ct de linterface est lorigine de lappel : le ct qui appelle met ce bit 0 et la destination met ce bit 1. Le but de ce flag est de rsoudre les problmes pouvant provenir de demandes simultanes qui allouent la mme rfrence dappel. Une rfrence dappel sur 3 octets est utilise quand un octet additionnel est requis pour tendre la valeur de la rfrence dappel de 7 15 bits. Cela peut tre ncessaire dans le cas dune interface Frame Relay trs rapide qui utilisent beaucoup de circuits, ou dans le cas dune interface NNI. La valeur de la rfrence dappel est choisie par lorigine de lappel quand le message initial de connexion de circuit est dlivr. Le type de message : il y en a 7 qui sont dtaills ci dessous : 8 0 0 0 0 7 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 5 4 3 2 1 Type de message Messages dtablissement dappel Processus dappel Connexion Configuration
41
0 0 0 0 0 0 0
1 1 1 1 1 1 1
0 0 0 0 1 1 1 1 1 1 0 1 1 0 0 1 1 0 0 0 0 1 1 1 1 0 0 0 1 1 1 0
Messages de fin dappel Dconnexion Libration Libration complte Messages divers Status Status enquiry
Elments dinformation : les lments dinformations pour les procdures SVC varieront en fonction du message envoyer. Pour plus dinformations ce sujet se rfrer aux annexes sur la norme FRF 4. Nous terminerons cette introduction sur le fonctionnement complexe des SVC par 2 schmas qui montrent comment on tablit un appel, et comment on le libre. Etablissement dappel :
Utilisateur Configuration Configuration Processus d'appel Rseau Utilisateur
Connection Connection
Libration dappel :
42
Utilisateur Dconnection
Rseau
Utilisateur
Dconnection
Libration Libration
Libration complte
Libration complte
3. Les volutions futures du Frame Relay : la voix sur le Frame Relay

La normalisation de la voix sur Frame Relay, aussi appel VoFR sera un des objectifs du Frame Relay Forum pour 1997. Cette partie expose une courte rflexion sur le transport de la voix sur un rseau Frame Relay. Elle nonce quelques axes de recherche possibles. Bien quun standard officiel soit actuellement en cours de normalisation dans des organisations comme le comit technique du Frame Relay Forum, il ny a pas actuellement de standard ou daccord dimplmentation qui ne soit dfini pour linteroprabilit des quipements de diffrents vendeurs, ou pour le transport de la voix sur des rseaux frame relay publics. En labsence de tels standards, de nombreux vendeurs ont dvelopp des mthodes propritaires pour intgrer la voix sur le Frame Relay. Et mme en labsence de standards, il y a certains utilisateurs qui ont russi dployer de manire satisfaisante la voix sur les rseaux Frame Relay. Ce type de solution savre particulirement intressant pour les gestionnaires de rseau qui souhaiteraient faire passer la tlphonie sur leur rseau Frame Relay et ainsi rduire les cots. A linverse de la plupart des transmissions de donnes qui peuvent supporter les dlais, les communications vocales doivent tre opres en temps rel. Cela signifie donc que les dlais de transmission doivent tre suffisamment court pour rester imperceptibles. Jusqu rcemment, la transmission de la voix sur des paquets tait impossible : notamment cause de la bande passante ncessaire pour la voix, et des dlais de transit. On sest rendu compte que seulement 22% dun dialogue classique comportait des informations ncessaires :
43
Normal Speech Components

22% 22% Essential Components Pauses Repetitive Patterns 56%
La transmission de la voix sous forme de paquets est donc possible en analysant et en ne gardant que les composants essentiels de la voix, plutt quen essayant de digitaliser lensemble de la voix (avec les pauses et les rptitions). Les vendeurs dquipement Frame Relay capable dintgrer la fois la voix et les donnes doivent considrer comment ils vont grer la compression, leffacement dchos, les dlais et les variations de dlais, la perte de trame, et les mcanismes de priorit. Chacune de ces considrations peut affecter la qualit de la voix. Bien que des vendeurs offrant des quipements de transport de la voix sur le Frame Relay peuvent avoir les mmes objectifs concernant la qualit et la performance, chaque vendeur peut choisir de mettre en place ces objectifs en utilisant diffrentes stratgies. Voici quelques explications sur les techniques les plus souvent utilises : Pour la compression de la voix :
La compression de la voix consiste en la suppression des silences et des informations redondantes trouvs dans le langage humain. La compression de la voix est utilise pour rduire le montant dinformation ncessaires pour recrer la voix lautre bout. La voix digitalise et le fax demandent une bande passante importante (ce qui rend leur transmission sur des liaisons lentes trs peu pratique). Lutilisation dalgorithme de compression utilisant peu de bits peut rendre possible la transmission dune voix de qualit sans gaspiller la bande passante. Plusieurs algorithmes peuvent tre utiliss pour enregistrer la voix et rduire le nombre dinformations envoy tout en maintenant un bon niveau de qualit. Un algorithme simple est le ADPCM (Adaptive Delta Pulse Code Modulation) qui rduit la taille ncessaire dun facteur 2 par rapport au PCM (Pulse Code Modulation), un standard de lITU pour la voix digitalise, et consomme 64Kbps tout en tant optimis pour la voix. PCM est lalgorithme communment utilis sur les rseaux tlphoniques. ADPCM peut tre utilis la place de PCM tout en maintenant la mme qualit de voix. Il y a un nombre important de standards de compression vocale (par exemple le ITU G.729) comme dalgorithmes propritaires implments par diffrents vendeurs qui permettent des rductions importantes dans la quantit dinformations ncessaires pour compresser et recrer la voix.
44
Dautres algorithmes de compression essaye de modliser la voix de manire plus efficace (avec moins de bits) en utilisant dautres technologies. Lutilisation de DSP (Digital Signal Processors) est vite rendu ncessaire. Au fur et mesure que les algorithmes passent de 64kbps 32,16,8 et mme 4Kbps et au-dessous, les stratgies pour liminer les bits redondants deviennent de plus en plus sophistiqus. Les processeurs DSP, gnralistes et de cots faibles ainsi que les algorithmes avancs de compression rendent possible la compression de la voix au sein de priphriques de type VoFR. Pour la suppression des chos :
Lcho est un phnomne que lon trouve sur les rseaux de type voix. Lcho apparat quand la voix transmise revient au point do elle a t transmise. Dans les rseaux de voix, les priphriques de suppression des chos quant lintrieur du rseau, les dlais de propagations augmentent jusquau point o les chos apparaissent. Plus longue est la distance, plus il y a de dlais, et plus il y a de chance quil y ait de lcho. La voix transmise sur un rseau Frame Relay va aussi devoir faire face ce type de problme. Avec laugmentation des dlais entre metteur et rcepteur les chos peuvent devenir perceptibles sils ne sont pas supprims. Comme les fournisseurs de rseaux publics Frame Relay nutilisent pas dquipement de suppression dchos dans leurs rseaux, cest au vendeur dquipement dadresser le problme de la suppression dchos dans ses quipements Frame Relay. Pour les dlais et la variation des dlais :
Les rafales et les tailles de trames variables du Frame Relay peuvent rsulter en des dlais variables entre paquets conscutifs. Cette variation dans le temps entre larrive de chaque paquet est appel jitter . Le jitter peut empcher la facult qu lquipement de rception du client final de rgnrer la voix de faon correcte. Comme la voix est par conception une onde continue, un large saut entre les paquets de voix rgnrs peut rsulter en un son distordu. Pour viter de dtruire certaines trames, les donnes peuvent tre buffrises au niveau du dcodeur vocal suffisamment pour permettre de prvoir le pire cas de dlais de type jitter . Les vendeurs dquipement cherche incorporer cette possibilit dans leur quipement. Pour la perte de trames :
La voix, compar aux donnes, peut habituellement plus facilement rsist la perte de paquets. Si un paquet de type VoFR est perdu, lutilisateur ne pourra pas le percevoir dans la plupart des cas. Si une perte de paquet importante a lieu, cest autant inacceptable pour la voix sur Frame Relay que pour le trafic de donnes. Ce nest donc pas un facteur qui ncessite une tude spcifique.
45
Intgration du trafic : support des modems et des fax :
Les vendeurs qui implmentent des technologies de type VoFR semblent imiter les services du RTC. Ds lors, il peut tre envisageable pour VoFR de supporter les services de Fax et de modems. Cette possibilit peut sembler bnfique aux utilisateurs qui ont un fort trafic de fax entre les filiales et le sige de leur socit. Les signaux moduls de type fax et modems peuvent tre dmoduls et transmis sous forme de paquets numriques. Malgr tout, il est difficile de compresser les signaux de fax et de modems de faon efficace pour obtenir lutilisation de la faible bande passante souvent ncessaire pour obtenir une bonne intgration sur le Frame Relay. Quelques vendeurs ont implment des structures o la voix est compresse de manire forte, mais o la dtection dune porteuse fax, entrane la rallocation de la bande passante vers un taux de transfert plus important qui permet des transmissions de fax plus rapides. Priorits :
La voix, le fax et certains types de donnes sont sensibles au dlais. Cela signifie que le dlais de transit ou la variation de dlais excdent une limite spcifique, le niveau de service sera dgrad. Pour minimiser le potentiel de dgradation de service, les vendeurs utilisent une multitude de mcanismes et techniques. Pour minimiser les dlais de trafic de la voix, un mcanisme de priorit qui fournit le service en premier au trafic sensible aux dlais en peut tre utilis. Les vendeurs qui offrent des quipements capables dintgrer la voix sur le Frame Relay peuvent choisir dutiliser une varit de mcanismes propritaires pour assurer un balancement entre la voix et les besoins de transmissions de donnes. Bien quils puissent tre diffrents, le concept reste le mme. Par exemple, chaque trafic en entre peut tre configur parmi une des nombreuses files de priorit. La voix et le fax peuvent tre placs dans la plus file de plus haute priorit, pour une expdition immdiate sur le rseau. Les trafics de donnes de priorits plus faibles peuvent tre buffriss jusqu ce que les paquets de plus hautes priorits soient mis. En voici un exemple :
AUTRE
VOIX
Fragmentation :
La fragmentation est utilise pour dcouper de larges blocs de donnes en de plus petits, moins crateurs de dlais. Cest un autre moyen utilis pour assurer la
46
meilleure qualit de voix possible. La fragmentation essaye dassurer un flot constant de trames de voix, pour minimiser les dlais. Ceci se prsente de cette sorte :
AUTRE
VOIX
La fragmentation implique souvent toutes les donnes du rseau pour garder une qualit de voix consistante. Cest parce que mme si la voix est fragmente, des dlais peuvent encore apparatre si une trame de voix est retenue derrire une large trame de donnes. La fragmentation des paquets de donnes assure aux paquets de voix et de fax une transmission plus rgulire. La fragmentation, spcialement lorsquelle est utilise avec des techniques de priorit, permet un flot de voix consistent. Lobjectif de cette technique et des autres est de permettre la technologie VoFR dassurer un service approchant celui du tlphone public. Interpolation de la voix numrique :
Linterpolation gre la suppression des silences. La nature de la communication vocale assure une pause entre les mots et les phrases. Les algorithmes avancs de compression de la voix, qui identifient et enlve les patterns redondants, rduisent efficacement le montant de donnes transmettre. Linterpolation de la voix numrique utilise des techniques avances de traitement de la voix pour dtecter les priodes de silence et supprimer la transmission de ces informations. En prenant en compte cette technique, lutilisation de la bande passante peut tre rduite. Techniques de multiplexage :
Certains vendeurs dquipement offrent des FRADs (Frame Relay Access Devices) traitant la voix et utilisant diffrentes techniques de multiplexage optimisant la bande passante comme par exemple le Logical Link Multiplexing et le Subchannel Multiplexing. Le Logical Link Multiplexing permet aux trames de voix et de donnes de partager le mme PVC (Permanent Virtual Circuit). Cela peut permettre de diminuer les dpenses portant sur les cots dun PVC et amliore lutilisation du PVC. Le Subchannel Multiplexing est une technique utilis pour combiner de multiples conversations vocales dans une mme trame. En permettant plusieurs de ces conversations dtre mise dans une mme trame, loverhead portant sur les paquets est rduit. Cela peut permettre damliorer la vitesse sur des liaisons lentes. Cette technique peut permettre aux connections basse vitesse de transporter des petits paquets de voix de manire efficace travers le rseau Frame Relay.
Autres considrations :
En plus de fournir des services basiques comme lencapsulation du trafic de donnes pour le transport sur un rseau Frame Relay, les FRADs qui supportent la voix peuvent parfois fournir une connectivit entre les PBX et les autres quipements de voix. Comme consquence, les FRADs supportant la voix devront grer les diffrents types de trafic et saccommoder de leurs besoins.
48
APPLICATIONS
49
4. Les offres commerciales Frame Relay

Les offres commerciales peuvent tre divises en 2 : dune part les offres des constructeurs de commutateurs, dautre part les offres des oprateurs de tlcommunication.
LATM ntant pas pour linstant trs dvelopp, les entreprises non gure le choix pour interconnecter leurs rseaux : soit elles utilisent des liaisons loues (souvent onreuses), soit elles utilisent une solution de partage des liaisons pour diminuer les cots. En Europe, lensemble de ces services est domin par les oprateurs nationaux (mme si depuis 1993, les services de transport de donnes sont ouverts la concurrence). Les USA connaissent un dveloppement des services Frame Relay important tandis que lEurope reste attache au protocole X25
Le schma suivant montre les parts de march des services rseaux :
March europen des services
La libration du march des transports de donnes intervenue le 1er Janvier 1993 et la rseau en 1993 libralisation des supports intervenue en Janvier 1995 risque terme de provoquer une redistribution des cartes en ouvrant le march des oprateurs amricains qui ont investi dans Frame Relay.
Deutsche Telecom Telephonica 4.1 Loffre commerciale des constructeurs de commutateurs 19% Transpac Le march des commutateurs X25 et FR est dcoup de la manire suivante : 14% Autres 11% 18% 19% 19% MDNS SIP
Part de march des constructeurs de commutateurs X25 en Europe

Les commutateurs de paquet couvrent un large spectre et souvrent dautres Telephonics protocoles. Cependant loffre de relais de trame que proposent la plupart des Sprint quipement ne suscite pas un fort engouement. Certains constructeurs comme Motorola, Alcatel, TRT, Telematics proposent 10% des interfaces avec SNA, HDLC, SDLC. Dautres Ericsson 11% comme la SAT, voluent sur le crneau du rseau local avec le support des protocoles 36% Mac, LLC, DLC, IP, et des interfaces Ethernet et Token Ring.BBN Les dbits offerts vont de 64kbit/s 2Mbit /s avec un fort engouement de ce dernier. Nortel
Alcatel Voici un tableau qui rsume quelques-uns uns des quipements disponibles sur le 9% 10% march : Philips 5% Autres
5%
14%
50
Constructeurs
Rfrences
Nombre de lignes
Dbit Nb. De max par paquets ligne commuts Tlcom par seconde 2 Mbit/s 4000
Autres protocoles supports
Alcatel
1100 PSX
<1024
SNA, SDLC, vidotex, FR
1100 MSDX CSEE Unitel 1100
<8000
2 Mbit/s
5000
4 64
1 Mbit/s
700
X.25, X.32, X.29, vidotex X.25, FR
Dynatech comm Ericsson
CPX 20
<= 32
2 Mbit/s
3000
PFS 550
4 1000
2 Mbit/s
1000
IP, SNA, VTS, FR, HDLC
PTA Nortel Magellan DPN-100 Ecom 24
6 8 50002
2 Mbit/s
500 FR, SNA, IPX, source Routing X.25, X.75, X.28, SNA,SDLC, VIP, vidopad
2 Mbit/s 64 7200
OST
8 72 512 kbit/s
800
Ecom 72 SAT Megapac E15 2 2 Mbit/s
1500 1300 Eth, Mac, LLC, IP, OSI, classe3, QLLC, BSC
Megapac VME 21 Telematics Net 25
Min 4 max 2 Mbit/s 72 6 480 384 kbit/s 384 kbit/s 2 Mbit/s
2500
1000
FR, SNA, VIP routage TCP/IP
Smartnet
6 50
1000
TRT
LMX 506
500
FR, HDLC, BSC, VIP, SDLC
51
MCX 212
36
2 Mbit/s
800 4000 1000 5000 1500 5000
MCX 512
36
2 Mbit/s
MCX 512 Y
24
2 Mbit/s
La monte en dbit des liaisons X.25 2 Mbit/s peut contrarier les prtentions du protocole Frame Relay qui se dveloppe outre-Atlantique. Les annonces ATM des oprateurs sont certainement le frein majeur au dveloppement de FR, bien que ce dernier soit considr comme trs bien adapt linterconnexion des rseaux locaux. Frame Relay est propos dsormais au catalogue des principaux oprateurs. Mme si ce service occupe une faible place, on compte en Europe plus de 200 000 raccordements directs X.25 contre simplement 12 000 portes Frame Relay dans le monde fin 93. Le fort potentiel du march de linterconnexion laisse entrevoir un dcollage du march du Frame Relay partir de 1996-1997 comme le montre le graphique suivant : Il passerait ainsi de 179 milliards dcus fin 93 932 milliards en 1997 avec un fort dveloppement des liaisons de plus de 1Mbit/s. La nouvelle technologie de commutation rapide ATM risque cependant de venir modifier les cartes, car elle ncessite des efforts de recherche importants. Tous les acteurs majeurs de cette industrie, sans exception, y investissent. Beaucoup considrent lATM comme une technologie structurante affectant la fois les rseaux longue distance et les rseaux locaux. Il est encore trop tt pour discerner avec certitude limpact de cette nouvelle technologie sur le march de linterconnexion.
4.2 Loffre commerciale des oprateurs de tlcommunication

Le Frame Relay reprsente une bonne affaire pour la plupart des oprateurs : de nombreuses offres sont donc disponibles ! Loffre est ainsi trs riche en Amrique du Nord. Le tableau suivant rsume quelquesunes unes des principales offres existantes dans ce pays : Vendeur Nom du service Type du service Dbit max quipement terminal Stratacom 1,024 Mbit/s commutation Couverture Projets
ATT Data Com. Service Group
Interspan
FR
USA
52
BT Nord Amrique
Express LAN
FR
Tymnet Turbo Eur. (64 kbit./s USA 56) Stratacom 1,024 Mbit/s
USA Londres Paris USA
D, NL, Can, 1Mbit/s Londres, Paris, D, NL, Can FR lien avec MCI
Compuserve Inc.
FrameNet
FR
Infonet Inc.
InfoLAN
Router IP routers 19,2 Network 64 kbit/s
USA, CE, Zone Pacifique USA
US Sprint
FR
1,544 Mbit/s
Williams Tel. Gr.
Wilpak
FR
Stratacom 1,024 Mbit/s
USA
4.2.1 Loffre de France Tlcom

Loffre France Tlcom pour linterconnexion de rseaux locaux se dcline en divers services dont lun, IRLE, se met actuellement en place : IRLE (Interconnexion de Rseaux Locaux dEntreprise) permettra de couvrir une gamme de dbit allant de 4800 bit/s 34 Mbit/s. Rseau multi-protocoles, il fournira les services 802.3, 802.5, FDDI, IP et DecNet en s'appuyant sur la technologie ATM. TRANSREL est un service dinterconnexion sur liens TRANSFIX point point, pour des dbits allant de 64 1920 kbit/s. La tarification se dcompose en un abonnement pour chaque extrmit (3950F pour un rseau Ethernet, 3150F pour un rseau Token Ring chiffres datant de 1994), auquel vient sajouter la location des liaisons spcialises. France Tlcom se charge de la connexion et assure lexploitation et ladministration du service. De manire standard, cette offre fournit les points, assure la supervision et donne des statistiques sur lutilisation du rseau. TRANSPAC, utilisant les techniques X.25 et Frame Relay sur des raccordements hautes vitesses. Chaque raccordement est dfini par son dbit et par linterface quil prsente. Depuis 1991, les dbits de 64,128 et 256 kbit/s sont commercialement offerts. En 1992, sont venus sy ajouter les dbits de 384 kbit/s 2 Mbit/s. Actuellement des volutions vers des vitesses plus lves (155 Mbit/s) sont envisags. Le Frame Relay est apparu dans la gamme TRANSPAC en 1993. (La documentation commerciale de Transpac sur le Frame Relay est jointe en annexe) Les accs multi-services, contrairement au raccordement haute vitesse, qui noffre quune seule interface un dbit donn, permettent de raccorder plusieurs terminaux prsentant des interfaces diffrentes. Un accs
multi-services se compose donc dun raccordement haute vitesse dbit choisi par le client et dun matriel sur lequel sont raccords les terminaux. Cet accs assure aussi les fonctions de multiplexage, concentration et commutation des donnes entre les interfaces locales. TRANSPAC assure linstallation de la configuration et la supervision des accs. Ces accs concentrs sont proposs en utilisant deux catgories dquipements : Un routeur/concentrateur haut dbit supportant les protocoles X.25, relais de trames, IP-DOD, sur des rseaux locaux de type Ethernet et HDLC. Il peut supporter jusqu 7 ports 2 Mbit/s ou 7 rseaux locaux Ethernet. Un concentrateur supportant les protocoles X.25, Frame Relay, HDLC jusqu 512 kbit/s et des vi tesses infrieures X.28, SNA/SDLC etc Le service de commutation repose sur des liaisons virtuelles rapides, qui assurent une capacit de transmission entre deux raccordements haute vitesse dsigns par le client. Cette capacit alloue permet datteindre des dbits allant de 128 kbit/s 2 Mbit/s. Ces raccordements hautes vitesses sont indpendants de la procdure utilise linterface abonn. On peut donc avoir plusieurs LVR (cest ainsi que lon nomme ces raccordements) sur un mme lien physique. On peut aussi, en X.25, tablir plusieurs circuits virtuels commuts (dbits infrieurs 64 Kbit/s) vers dautres correspondants.
54
Les taux de transfert sur un rseau Frame Relay TRANSPAC sont illustrs par le graphe suivant (issu dune documentation commerciale TRANSPAC):
On notera que TRANSPAC nomme le Bc (Burst Committed) par SIR et le Bc+Be par EIR. Les tarifs des services hauts dbits X.25 et Frame Relay sont identiques et se dcomposent en trois parts : les frais de mise en service, labonnement mensuel et le trafic effectu. Les frais de mise en service sappliquent des raccordements dune longueur infrieure quinze kilomtres. Pour des longueurs suprieures un devis est tabli. De plus TRANSPAC ne communiquent tous les prix dont nous venons de parler quaprs avoir ralis une tude du rseau Frame Relay que le client souhaite mettre en vre. Nous ne pouvons donc pas communiquer de listes de prix officielles. u Malgr tout, ce que lon peut dire propos de la facturation du trafic cest quelle repose sur la notion de classe de trafic. Il existe six classes correspondant indiffremment tous les dbits proposs. Une classe de trafic est dfinie par un prix du kilo-octet et un minimum de facturation. Le client choisit la classe en fonction de ses prvisions.
55
Classe 1 2 3 4 5 6
Plancher en F/mois 1000 2000 4000 8000 16000 24000
Prix du Koctet rduit de 20 % 30 % 40 % 50 % 60 % 65 %
Ces tarifs sappliquent des transferts de donnes entre des sites A et B dfinis lavance. Le trafic coul hors des LVR est redevable au prix normal, soit 0.054F le ko (tarifs 1994). Voici un tableau des caractristiques du rseau Frame Relay TRANSPAC daprs une publication de TRANSPAC :
France Tlcom, par lintermdiaire de sa filiale TRANSPAC, exploite l premier e rseau de transmission de donnes au monde utilisant le protocole X.25. Ayant construit sa rputation sur une indiscutable qualit de service, il a choisi de ne pas
56
abandonner les mcanismes de protection qui lui permettent doffrir cette qualit. Il conserve donc ses algorithmes de contrle de flux, tout en augmentant la puissance de ses commutateurs. Loffre de relais de trames nest due qu la pression exerce par le parc important de routeurs et concentrateurs dorigine nord-amricaine dots dune interface de relais de trame et une trs active campagne de publicit des oprateurs amricains ! Le dveloppement de cette activit au niveau europen passe par la socit ATLAS (en association avec Deutsche Telecom) et au niveau international par laccord sign mi-95 avec loprateur amricain Sprint et avec Deutsche Telecom. Cette alliance fournira un service sans coupure et globale, de tlcommunication.
4.2.2 Loffre de BT
Cinquime oprateur mondial, BT ralise une part trs importante de son chiffre daffaire linternational. Pour les transmissions de donnes, la socit propose le GNS, Global Network Service. GNS offre ses services dans plus de 100 pays avec 1200 accs. Ce rseau gr de bout en bout, permet une extension vers les hauts dbits en relais de trames. Dautre part BT joue fond sa carte internationale grce plusieurs filiales dissmines tout autour du monde et son accord avec MCI. Revenons plus en dtail sur le GNS : Le service GNS repose sur le plus grand rseau va leur ajout du monde. Il offre des prestations remarquables en matire de confidentialit, dintgrit de donnes, un grand nombre de conversions de protocoles et de points daccs. GNS constitue la plate-forme partir de laquelle BT propose une gamme complte de services valeur ajoute. Il offre les avantages suivants : un support client, une gestion et un contrle du rseau assurs de bout en bout, une procdure de connexion standard sur lensemble du rseau, le choix dune facturation centralise ou l cale dans la plupart o des devises, un interlocuteur unique pour lensemble des services. Il suffit dindiquer les villes et pays avec lesquels le client dsire communiquer, BT se charge de la mise en place. GNS est un rseau trs souple, construit sur une architecture logicielle scurise. Ladjonction ou la modification dun service se fait par tlchargement sans lintervention sur le site client ! BT a t le premier oprateur proposer un service relais de trames transatlantique. Avec un dbit pouvant atteindre 2Mbit/s, cette technologie permet dinterconnecter des rseaux locaux dans des dlais incomparables. Pour cette interconnexion, BT ne propose que le relais de trames. En effet son offre X.25 ne couvre que les dbits allant de 9600 64 000 bit/s. Cest un service qui sintgre dans loffre GNS et permet des raccordements des dbits de N fois 64 kbit/s. Les dbits proposs sont de 64, 128, 256, 512 kbit/s et 1 et 2 Mbit/s. Limplantation du service couvre la plupart des pays dEurope : Royaume Uni, France, Allemagne, Espagne, Belgique, Italie, Sude, Amrique du Nord, et Japon.
57
Cependant les sites GNS Frame Relay ne sont implants que dans les principaux centres de ces pays. Par exemple, en France, les sites de raccordement au GNS se situent To ulouse, Marseille, Lyon, Paris.
4.2.3 Loffre de AT&T

AT&T, premier transporteur de donnes nord amricain propose en Europe une offre pour la transmission de donnes. Cette offre sarticule sur une surveillance de bout en bout des services, au travers dun seul point de contact. Cest le concept Managed Network Services. Pour supporter cette offre, AT&T a dvelopp dans 16 pays europens un rseau maill de liaisons numriques haut dbit. Les n ds du rseau AT&T sont tous u constitus de commutateurs Net IDNX, assurant ainsi une homognit totale lensemble du rseau. Deux centres de supervision sont installs en Europe : lun Reddich (Grande-Bretagne), lautre prs de Amsterdam. AT&T ajoute ses services une importante valeur ajoute : tude et architecture de rseau, fourniture de boucles locales, coordination technique avec les services des P&T, installation de routeurs, maintenance logicielle des routeurs, facturation des services au forfait, facturation centralise dans une monnaie choisie.
AT&T propose galement un service complet de gestion des tlcommunications de lentreprise travers loffre AMS, Acumaster Management Services, de supervision de rseaux. Les services des liaisons spcialises propose des accs standards numriques ddis de 9.6 128 kbit/s, en utilisant tous les types de protocoles. Ces liaisons sont utilises principalement pour le transfert de fichiers ou la communication entre rseaux locaux. Accunet Packet Service Europe (APS-E) constitue loffre de service X.25, permettant des dbits allant de 2.4 64 kbit/s. Ce rseau, reposant sur une infrastructure prive homogne, permet dviter la mise en place de liaisons internationales coteuses et difficiles grer. Pour linterconnexion des rseaux haut dbit, AT&T propose InterSpan, service de Frame Relay offrant une connectivit transparente entre 20 pays principalement situs en Europe et Amrique du nord. InterSpan offre en standard des accs ddis de 64 kbit/s 2 Mbit/s et intgre la gestion des protocoles, du rseau et des circuits virtuels permanents.
Pour plus dinformation sur les offres commerciales Frame Relay : Une tude sur la rpartition des offres sur le plan mondial est jointe en annexe (Frame Relay 1996 : Carrier and user profile update final report)
5. Prsentation dun matriels spcifiques au Frame Relay : Le FRAD

Les Frame Relay Assembler/ Disassemblers (FRADs) plus connus sous le nom de priphriques daccs au Frame Relay permettent aux protocoles et aux services non Frame Relay davoir accs au service Frame Relay en tant que moyen de transport. Le terme FRAD est originaire du march de la commutation de paquet, march o des priphriques connu sous le nom de PAD (Packet Assembler/disassembler) remplissaient la mme fonction sur des rseaux de commutation de paquets depuis des annes. A linverse de celui ci, le FRAD na pas t standardis si on fait exception des procdures limites dencapsulation multi-protocoles spcifies par le Frame Relay Forum (norme FRF 3.1 en annexe). Les vendeurs ont le choix de dvelopper leur solution propritaire. Un FRAD peut tre un priphrique spar ou une fonction intgre un commutateur Frame Relay. Les protocoles entrent dans le FRAD, sont mapps vers les DLCI appropris, et sont transports travers le rseau Frame Relay vers un FRAD loign, o lopration inverse est effectue. Le mapping en DLCI est gnralement en one-toone : chaque connexion logique de lutilisateur se voit allou un DLCI diffrent. Malgr tout, cela ne signifie pas forcment que chaque utilisateur se voit allou un DLCI diffrent. A lintrieur de SNA par exemple, il est fort probable quun contrleur (contenant plusieurs utilisateurs) se voit attach un FRAD laide dune seule connexion physique, et multiplexera probablement tous les utilisateurs sur un simple DLCI sur le FRAD. En sachant que le FRAD prend un protocole non LAN (ex : SNA, X25, BSC) et le converti en Frame Relay : quel est donc son fonctionnement ? On peut le dcomposer en 3 grandes fonctionnalits : 1.La fonction de prise en compte du multi-protocoles : Les rseaux doivent tre transparents envers les applications et les utilisateurs. En particulier il est important que lutilisateur ne soit pas conscient dtre en face dun rseau Frame Relay ou dun FRAD ; en consquence la fonction de prise en compte du multi-protocoles (en anglais : Multi-protocol handling component) doit agir comme si lutilisateur tait directement reli sa destination. Par exemple dans le cas de SNA, cela ncessite que la fonction continue poller le priphrique SNA la mme cadence, et offre une rponse de polling similaire, comme si la destination tait directement connect. 2. Le composant de protocole de service:
59
Aprs la premire tape nonce ci-dessus, les donnes de lutilisateur passent par la fonction de transformation de protocole de service (en anglais : service protocol transformation function). Le protocole de service est un protocole de la couche transport offrant un niveau dfini de service pour le FRAD. Il prend les lments de protocoles multiples et les encapsule dans un protocole de plus haut niveau prt pour le transport travers le rseau Frame Relay. Cette encapsulation a t mise en place pour corriger les erreurs lintrieur du service Frame Relay. Elle peut aussi lancer des actions de recouvrement de donnes entre FRADs, afin dassurer que chaque donne dtruite par le rseau Frame Relay est retransmise par le FRAD et non par lutilisateur. Cette fonction permet aussi un FRAD dtre dploy lintrieur dun rseau Frame Relay avec un minimum de problmes. Lutilisateur existant continuera dutiliser les mmes applications et ne verra pas les pertes de donnes lintrieur du rseau Frame Relay, mme si le rseau doit dtruire des trames en cas de congestion. Le protocole de service employ par les diffrents vendeurs de FRAD peut tre diffrent mais il sera souvent bas sur le protocole X25. La raison de cela est que les vendeurs de commutateurs de paquets auront pris leurs PAD existant auquel ils auront simplement ajout le Frame Relay en tant quinterface rseau ! 3. Le composant Frame Relay : Les donnes encapsules par le protocole de service passent travers le module logiciel Frame Relay qui mappera un canal utilisateur individuel en un DLCI pour une transmission sur le Frame Relay. Un point a not propos des FRAD est que pour quils puissent offrir les meilleures performances possibles, linterface Frame Relay entre les FRAD et le rseau backbone doit tre rapide. Des vitesses de 2Mbps sont prvoir ; beaucoup moins et les avantages de linfrastructure de rseau Frame Relay seraient perdus. Les bnfices apports par les FRAD sont les suivants : une rduction du cot grce une solution de rseau intgr pour tous les besoins de donnes des utilisateurs, possibilit pour un rseau dutiliser un rseau public Frame Relay de cot plus faible, aussi bien en tant quinfrastructure rseau complte ou en tant quinfrastructure supplmentaire par rapport une infrastructure existante, simplification de la transition entre un rseau de commutation de paquets et un rseau Frame Relay haute vitesse.
Exemples de FRAD : CISCO : FRAD 2502 MOTOROLA : MPRouter 6520
60
6. Prsentation de quelques rseaux Frame Relay Europens

Les schmas de rseaux suivant nous ont t fournis par la socit TRANSPAC : ces diffrents exemples illustrent les diffrentes possibilits dutilisation dun rseau Frame Relay.
6.1 Le rseau FR Finnpap

La socit finlandaise Finnpap vend du papier dans plus de 100 pays et dispose de 50 agences commerciales dans le monde. Le rseau Finnpap fourni comprend 42 accs Transpac Europe rpartis sur 34 sites en Europe dans 15 pays pour une application dInterconnexion de Rseaux Locaux. Le service inclut la fourniture de routeurs en location/maintenance, le secours des Liaisons Loues de raccordement par RNIS et de tous les accs avec fourniture dun Terminal Graphique de Supervision en Finlande. Les protocoles utiliss sont varis : TCP/IP, SNA, DECNET sur Token Ring ou Ethernet, et PPP/SLIP sur les accs supplmentaires par RTC. Le graphe suivant nous montre lorganisation du rseau :
61
6.2 Le rsea u FR Danza s

La socit Danzas, entrepris e de logistiqu e et de transport , souhaitai t raccorde r 23 agences en Europe sur une application informatique client-serveur lie son service de transport rapide international sur toute lEurope. Le rseau fourni se compose dune tole autour dun site central et dune vingtaine de sites dans neuf pays dEurope. Tous les sites sont raccords en FR sauf six sites pr-existants raccords en X25 ; la solution dinterfonctionnement entre FR et X25 est mise en vre Internetworking Function, IWF. Les accs de 64 u Kbit/s 384 Kbit/s sont relis avec des CVP de dbits de CIR asymtriques de 8 64 Kbit/s. Les services incluent la fourniture de routeurs Cisco en location / maintenance, le secours (par RNIS) et la supervision ; les protocoles utiliss sont varis : DECNET, TCP/IP, FR, X25
62
6.3 Le rs eau FR AM S
AMS , quiv alent de lAge nce Natio nale pour lEmp loi en Sude, a retenu Transpac pour la fourniture dun rseau national Frame Relay. Ce rseau, en cours de dploiement, sera le plus grand rseau Frame Relay, public ou priv, de Sude. Lapplication base sur le principe Client/Serveur sous TCP/IP est une configuration en toile. Au total 475 Jobs Centers locaux ou rgionaux routeurs- sont connects au rseau Frame Relay par des liaisons de 64 Kbit/s. Le site central 2 routeurs de grande connectivit est reli au rseau Frame Relay par 8 liaisons 2 Mbit/s 4 par routeur. Chaque Job Center est reli au site central par deux PVC Frame Relay CIR 48 Kbit/s.
63
6.4 Le rseau FR Infonie

Infonie est un exemple dutilisation du rseau Frame Relay comme rseau de backbone. Infonie, fournisseur dinformation en ligne, a mis en place un service couvrant lensemble du territoire franais et accessible partir du RTC ou du RNIS. Le rseau est constitu dun site central situ en rgion parisienne et de 25 sites rgionaux quips de serveurs de communications. Ce rseau comprend des accs tlphoniques et RNIS dans les sites rgionaux, des quipements daccs au rseau fournis par Transpac - , les quipements dextrmit du site central routeurs fournis par Transpac et des fonctions de dbordements sur chaque site rgional quand il y a dpassement de la capacit nominale. Le site central et les sites priphriques sont relis au rseau par 2 accs FR 1 Mbit/s pour le site central et 25 accs FR 512 Kbit/s pour les sites priphriques. Des CVP (PVC) avec CIR de 256 Kbit/s sont configurs entre les sites priphriques et le site central.
64
6.5 Un exemple de rseau FR transportant de la voix

En parallle des applications de donnes, Transpac poursuit son expertise du Frame Relay en exprimentant sur son rseau Frame Relay, les applications de voix. En effet, avec les nouvelles offres voix de plusieurs constructeurs de FRAD comme par exemple Motorola, Philips, ACT, des tests utilisant le service Frame Relay de Transpac ont t effectus. Les rsultats ont permis de mettre en vidence un confort dcoute trs satisfaisant et de pouvoir tendre les applications Frame Relay sur Transpac. Les deux principales applications sont le support de circuits permanents voix entre sites et linterconnexion de PABX. Pour ce deuxime type dapplication, une exprience en grandeur relle a t effectu entre deux sites de Transpac : deux FRAD Motorola MPRouteur 6520 relis via liaisons spcialises au rseau Transpac FR permettent linterconnexion de deux PABX ainsi que de rseaux locaux ddis la visioconfrence. Plus quune exprience ponctuelle, cette utilisation du Frame Relay pour transporter la voix est dsormais une ralit oprationnelle durable entre les sites Transpac de Rennes et de Paris.
65
66
Conclusion
Le Frame Relay est actuellement un protocole dinterconnexion beaucoup moins mdiatis et beaucoup moins connu que son grand rival : lATM. Malgr tout, on peut le considrer comme un concurrent srieux de ce dernier grce aux avantages que celui possde sur son adversaire : le cot des dploiements est beaucoup plus faible, sa technologie proche de X25 facilite la transition avec ce protocole, dominant encore le march des interconnexions de rseaux locaux europens
De plus, certains avantages de lATM, comme le transport des donnes contrainte de temps telle la voix sont progressivement attnus par lapparition de techniques de transport de la voix sur le Frame Relay. Loin de rester passif, le Frame Relay Forum contribue aux dveloppements de ce protocole. Auparavant considr comme tant une solution intermdiaire avant le dploiement universel de lATM everywhere , on tend maintenant tudier les solutions de cohabitation (FRF 5 : Frame Relay/ATM PVC Network Internetworking Implmentation Agreement, et FRF 8 Frame Relay/ATM PVC Service Internetworking Implmentation Agreement en sont des exemples !) entre ces 2 protocoles. Frame Relay est encore au dbut de sa courbe de croissance en Europe et la plupart des oprateurs poussent leurs clients passer de X25 F rame Relay, service souvent factur un cot identique pour un dbit pouvant tre temporairement suprieur ce qui satisfait les attentes des utilisateurs. Le Frame Relay est donc un protocole quil ne faut pas ignorer et dont on sera srement amen entendre parler dans les annes venir !
67
ANNEXES
68
Glossaire (dfini par le Frame Relay Forum)

ANSI : American National Standard Institute. Cest un organisme qui dveloppe et publie des standards pour les USA. ANSI a publi des standards pour la compression de la voix, pour les rseaux . Bc (Committed Burst Size) : Le flot maximum de donnes (en bits) que le rseau autorise transfrer , dans des conditions normales , pendant un intervalle de temps Tc . Be (Excess Burst Size) : Be est le maximum de donnes durant la priode Tc que l'utilisateur peut excder au-dessus de Bc. BECN (Backward Explicit Congestion Notification) : Il s'agit d'un bit positionn par le rseau Frame Relay pour indiquer un DTE que la procdure pour viter une congestion est initialise . CCITT : Le comit consultatif International Tlgraphique et Tlmatique est un comit spcialis de l'Union Internationale des Tlcommunications, elle-mme rattache lOrganisation des Nations Unis. Le CCITT est compos des administrations des Postes des diffrents tats membres. Son rle est de concevoir des standards pour relier divers quipements aux rseaux publics de tlcommunications. CIR (Committed Information Rate) : Le CIR est le dbit de donnes que l'utilisateur est sur de voir passer dans le rseau n'importe quel moment et sans aucun problme. Le CIR n'a aucun lien avec le dbit rel de la ligne de l'utilisateur. Un utilisateur peut avoir une ligne a 2Mbps et avoir, par exemple un CIR de 64Kbps. Cela signifie que l'utilisateur sera toujours sur de passer 64Kbps mais en pic de charge il pourra faire passer sur la ligne jusqu' 2048Kbps. DE (Discard Eligibility) : Le bit DE sert pour indiquer que les trames qui ont t envoyes en excs du CIR , peuvent tre retires si ncessaires. DLCI (Data Link Connexion Identifier) : Les DLCI l'intrieur de la trame Frame Relay sont utiliss pour indiquer les adresses source et destination pour chaque utilisateur. Quand un utilisateur envoie une trame un autre utilisateur, l'quipement origine place le DLCI destination l'intrieur de la trame. Au point destination le rseau place le DLCI de l'quipement origine dans la trame qui doit tre envoy l'quipement destination . FCS : Le Frame Check Sequence est utilis pour contrler que la trame a t reue sans erreurs et consiste en deux octets contenant un code cyclique redondant utilisant le polynme gnrateur du CCITT (X16X12X5+1). FRAD :
Frame Relay Access Device, matriel qui formate les donnes d'autres rseaux pour leur utilisation sur un rseau Frame Relay. HDLC (High Level Data Link Control) : famille de protocoles volus orients bit (pas de notion de caractre) fonctionnant en mode synchrone bidirectionnel, utilisant une procdure de scurit de type code cyclique et une anticipation des changes (envoi des trames sans attendre les accuss de rception) permettant d'optimiser les lignes. Ce type de protocole normalis par l'ISO est trs utilis, notamment dans les rseaux X.25 ou le RNIS. LAPB (Link Access Procedure Balanced) : Version avance de HDLC . Utilise dans la commutation de paquets de rseaux X25. LAPD (Link Access Procedure on the D-Channel) : LAPD est un HDLC driv utilis par RNIS sur lequel est bas le Frame Relay. LMI : Local Management Interface. Le protocole LMI sert contrler et commander la connexion entre l'utilisateur et le rseau. Il s'assure que le lien entre le rseau et l'utilisateur est actif. Il enregistre l'ajout et la suppression des PVC ( permanent virtual circuit ). Enfin il dlivre des messages d'tat sur la disponibilit des circuits intervalle rgulier. NNI : Le NNI est dsign pour faire office d'interface entre 2 sous-rseaux Frame Relay. Le but du NNI est le transfert de donnes haute vitesse, congestion, et le transfert d'informations de circuit. PVC : Permanent Virtual Circuit, SDLC (Synchronous Data Link Control) : protocole dvelopp par IBM dans le cadre de son architecture SNA. Protocole orient bit (pas de notion de caractre), il travaille en mode synchrone bidirectionnel avec contrle de redondance cyclique. Il est l'anctre des protocoles HDLC dont il est trs proche. SVC : Switched Virtual Circuit. UNI : Le Frame Relay UNI est un protocole qui permet l'utilisateur d'accder un rseau public ou priv et d'tablir un chemin de communication avec un autre utilisateur l'intrieur du mme rseau. Vitesse d'accs : La vitesse de l'accs dtermine la rapidit avec laquelle l'utilisateur final peut envoyer ses donnes sur un rseau Frame Relay .
70
Bibliographie
Frame Relay Philip Smith ADDISON-WESLEY (Data communications and networks series) Frame Relay Networks Black MC GRAW HILL Les Rseaux Guy Pujolle EYROLLES Rseaux haut dbit Marc Boisseau Michel Demange Jean-Marie Munier EYROLLES Rseaux haut dbit Pierre Rolin HERMES (Collection rseaux et tlcommunications) The Guide to Frame Relay Networking Heckart FLATIRON PUBLISHING Newsgroup sur la technologie Frame Relay comp.dcom.frame-relay World Wide Web Site du Frame Relay Forum : www.frforum.com Tout surle Frame Relay : www.starburstcom.com/frelay.htm
71
72
Brochure publicitaire Transpac : le service Frame Relay
73
Etat du march FR en 1996
76
Exemples de normes FRF :

FRF1.1 (UNI) FRF3.1 (Encapsulation) FRF4 (SVC)
102

FrRelay (C Ang)

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

FrRelay (C Ang)

Hochgeladen von

Copyright:

Verfügbare Formate

TELECOM 98

Frame Relay Principes et applications

Matthieu BRIAND (mattbr@mail.dotcom.fr)

Frame Relay : Principes et applications / EPITA TELECOM 98

Frame Relay : Principes et applications / EPITA TELECOM 98

1. Remarques gnrales sur le Frame Relay____________________________________ 7

3. Les volutions futures du Frame Relay : la voix sur le Frame Relay______________ 43

5. Prsentation dun matriels spcifiques au Frame Relay : Le FRAD _____________ 59

6. Prsentation de quelques rseaux Frame Relay Europens _____________________ 61

Frame Relay : Principes et applications / EPITA TELECOM 98

Brochure publicitaire Transpac : le service Frame Relay ________________________ 71

Etat du march FR en 1996 ________________________________________________ 76

Exemples de normes FRF :_______________________________________________ 102

Frame Relay : Principes et applications / EPITA TELECOM 98

Frame Relay : Principes et applications / EPITA TELECOM 98

1. Remarques gnrales sur le Frame Relay

Frame Relay : Principes et applications / EPITA TELECOM 98

Discard Non-Info Process

Information Frame Valid Ack Rotate Window

Frames Ack Restart timer Stop Timer

Sequence OK Send L2 Ack

Supervisory proc Error recovery

Active LCN Valid Ack

Error recovery Error recovery

Sequence OK Send L3 Ack

1.2 Le Frame Relay : fonctionnalits

Frame Relay : Principes et applications / EPITA TELECOM 98

Oui Oui Oui Oui Oui Non

Oui Oui Oui Non Non Non

1.3 Frame Relay : les circuits virtuels

Frame Relay : Principes et applications / EPITA TELECOM 98

1.4 Frame Relay : le mode burst et le CIR

Frame Relay : Principes et applications / EPITA TELECOM 98

Frame Relay : Principes et applications / EPITA TELECOM 98

Frame Relay : Principes et applications / EPITA TELECOM 98

2. Fonctionnement dtaill du protocole

2.1 Linterface physique

2.2 La trame Frame Relay

Frame Relay : Principes et applications / EPITA TELECOM 98

Composition du champ adresse : (2 octets) Adresse CR EA Adresse FECN BECN DE EA

2.3 Mcanisme de gestion des exceptions

Frame Relay : Principes et applications / EPITA TELECOM 98

une trame qui dpasse la taille configure entre lutilisateur et le

une trame qui ne possde pas une entte ou une enqueue

2.3 Adressage (DLCI)

Frame Relay : Principes et applications / EPITA TELECOM 98

Utilisateur D Vers B (DLCI 37) Vers A (DLCI 38)

Vers A (DLCI 435)

Vers D (DLCI 78) Utilisateur B

Origine Utilisateur A Utilisateur A Utilisateur B

Destination Utilisateur C Utilisateur D Utilisateur D

Frame Relay : Principes et applications / EPITA TELECOM 98

Table de commutation de la voie 1 DLCI entrant 10 26 39 Voie de sortie 2 3 4 DLCI sortant 56 64 98

Table de commutation de la voie 2 DLCI entrant 11 27 40 Voie de sortie 1 3 4 DLCI sortant 89 96 45

Frame Relay : Principes et applications / EPITA TELECOM 98

Table de commutation de la voie 4 DLCI entrant 55 44 33 Voie de sortie 1 2 3 DLCI sortant 11 78 77

DLCI (bits de poids fort)

Frame Relay : Principes et applications / EPITA TELECOM 98

DLCI (bits de poids faible)

DLCI (bits de poids fort) DLCI DLCI (bits de poids faible)

Frame Relay : Principes et applications / EPITA TELECOM 98

131 072 8 126 463