La Couche Réseau Le Protocole X.25: Michel Gardie

La couche rseau Le protocole X.
25
Michel Gardie
GET/INT/LOR/RIP
20 dcembre 2004
Rseau / X.25
Informations La version de ce document la date dimpression et de rvision est temporaire. Quelkes feautes dortaugrafe dovent encorre traner dans les paragraffes deij raidyjs. Il est hors de question que nous nous excusions pour cela (faut quand mme pas rver !). Mais, vous pouvez nous signaler toute erreur ou omission.
email : Michel.Gardie@int-evry.fr
Historique du document : 1990 FRANCE TELECOM INT/DSR/TI 1992, 1993 INT/DSR/TI 1994, 1995, 1996, 1997, 1999 INT/LOR/AIGRI 2002, 2003 INT/LOR/RIP Les premires versions du document ont t crites sous Word, il y a de cela bien longtemps. LaTeX a servi par la suite comme outil de rdaction. Puis, FrameMaker 5.1 a servi de plateforme pour la rdaction des versions subsquentes. StarOffice 5.2 est loutil qui a servi produire cette version partir des sources FrameMaker, suivi par OpenOffice 1.0.1 comme plateforme finale de rdaction. La date de conversion FrameMaker StarOffice a eu lieu le lundi 29 septembre 2003. La transformation sous OpenOffice a galement eu lieu partir du 29 septembre 2003.
Dernire modification : lundi 20 dcembre 2004
Table des matires

Chapitre1. La couche rseau.................................................................................................................7 1.1. Situation de la couche rseau.................................................................................................... 7 1.1.1. Rappels sur le modle OSI................................................................................................ 7 1.1.2. Rappel de quelques dfinitions du modle OSI................................................................. 7 1.2. Rle de la couche rseau...........................................................................................................9 1.3. Services fournis la couche transport.....................................................................................10 1.3.1. Services de base.............................................................................................................. 10 1.3.1.1. Transfert des NSDU changes entre les utilisateurs.............................................. 10 1.3.1.2. Routage et relais...................................................................................................... 10 1.3.1.3. Segmentation et groupage....................................................................................... 10 1.3.1.4. Adressage................................................................................................................ 10 1.3.2. Services lis aux connexions rseau................................................................................ 11 1.3.2.1. Connexions rseau...................................................................................................11 1.3.2.2. Multiplexage de connexions rseau......................................................................... 11 1.3.2.3. Identification unique de connexion rseau...............................................................11 1.3.2.4. Choix de la qualit de service.................................................................................. 12 1.3.2.5. Notification des erreurs........................................................................................... 12 1.3.2.6. Maintien en squence...............................................................................................12 1.3.2.7. Contrle de flux.......................................................................................................12 1.3.2.8. Libration................................................................................................................ 12 1.3.3. Services optionnels..........................................................................................................12 1.3.3.1. Transfert exprs de NSDU...................................................................................... 13 1.3.3.2. Rinitialisation......................................................................................................... 13 1.3.3.3. Confirmation de remise des donnes....................................................................... 13 1.3.3.4. Dtection derreurs..................................................................................................13 1.3.3.5. Reprise sur erreur.................................................................................................... 13 Chapitre2. Gnralits sur le protocole X.25......................................................................................14 2.1. Prsentation de X.25...............................................................................................................14 2.1.1. Niveau physique.............................................................................................................. 14 2.1.2. Niveau trame................................................................................................................... 15 2.1.3. Niveau paquet................................................................................................................. 16 2.1.3.1. Gestion de circuit virtuel......................................................................................... 16 2.1.3.2. Voie logique............................................................................................................ 17 2.1.3.3. Contrle de flux.......................................................................................................17 2.1.3.4. Multiplexage............................................................................................................ 17 Chapitre3. Procdures X.25................................................................................................................19 3.1. Etablissement dun circuit virtuel............................................................................................ 19 3.1.1. Choix des voies logiques................................................................................................. 19 3.1.2. Demande dtablissement ct appelant..........................................................................19 3.1.3. Demande dtablissement ct appel.............................................................................20 3.1.4. Rponse une demande dtablissement ct appel..................................................... 21
GET/INT/LOR 3 / 60 La couche rseau ; le protocole X.25
3.1.5. Confirmation dtablissement ct appelant....................................................................21 3.2. Libration dun circuit virtuel................................................................................................. 21 3.2.1. Libration par un ETTD..................................................................................................21 3.2.2. Refus dappel...................................................................................................................22 3.2.3. Libration par le rseau................................................................................................... 22 3.2.4. Transfert des donnes......................................................................................................24 3.2.5. Segmentation des messages.............................................................................................24 3.2.6. Contrle de flux...............................................................................................................25 3.2.7. Numrotation.................................................................................................................. 27 3.2.8. Description de la fentre..................................................................................................27 3.2.9. Donnes exprs (interruption).........................................................................................29 3.3. Gestion des incidents...............................................................................................................29 3.3.1. Procdure de rinitialisation............................................................................................ 30 3.3.2. Procdure de reprise........................................................................................................31 3.3.3. Autres erreurs..................................................................................................................32 3.4. Collisions.................................................................................................................................32 3.4.1. Collision dappel..............................................................................................................33 3.4.2. Collision de libration......................................................................................................33 3.4.3. Collision de rinitialisation.............................................................................................. 33 3.4.4. Collision de reprise.......................................................................................................... 33 Chapitre4. Description des paquets.................................................................................................... 34 4.1. Format gnral des paquets.....................................................................................................34 4.1.1. Identification gnrale du format.....................................................................................34 4.1.2. Numro de voie logique.................................................................................................. 35 4.1.3. Identification du type de paquet...................................................................................... 35 4.2. Appel.......................................................................................................................................36 4.2.1. Bloc dadresse................................................................................................................. 37 4.2.1.1. Format non TOA/NPI (normal)...........................................................................37 4.2.1.1.1. Champ des longueurs dadresses..................................................................... 37 4.2.1.1.2. Champ dadresses............................................................................................ 37 4.2.1.2. Format TOA/NPI (adressage tendu)..................................................................38 4.2.1.2.1. Champs des longueurs dadresses....................................................................38 4.2.1.2.2. Champ dadresses............................................................................................ 38 4.2.1.2.3. Exemples..........................................................................................................39 4.2.2. Champ de longueur du champ de facilits....................................................................... 40 4.2.3. Champ de facilits........................................................................................................... 40 4.2.4. Champ des donnes de lutilisateur................................................................................. 40 4.3. Confirmation dappel.............................................................................................................. 40 4.4. Libration................................................................................................................................ 41 4.4.1. Champ de cause de libration.......................................................................................... 41 4.4.2. Champ de diagnostic....................................................................................................... 43 4.5. Confirmation de libration.......................................................................................................43 4.6. Donnes.................................................................................................................................. 43 4.6.1. Champ de donnes.......................................................................................................... 43 4.6.2. Numro de voie logique.................................................................................................. 44 4.6.3. Numros de squence P(R) et P(S).................................................................................44 4.6.4. Elments binaires M, Q, et D.......................................................................................... 44 4.7. Paquets RR et RNR................................................................................................................ 45 4.8. Interruption et confirmation dinterruption............................................................................. 46 4.9. Rinitialisation et confirmation de rinitialisation................................................................... 47 4.10. Reprise et confirmation de reprise.........................................................................................48
4.11. Diagnostic............................................................................................................................. 49 Chapitre5. Services complmentaires................................................................................................. 50 5.1. Gnralits.............................................................................................................................. 50 5.2. Services non demands par champ de facilits........................................................................50 5.2.1. Numrotation squentielle tendue des paquets..............................................................50 5.2.2. Modification du bit D...................................................................................................... 50 5.2.3. Retransmission des paquets.............................................................................................50 5.2.4. Interdiction des appels larrive....................................................................................50 5.2.5. Interdiction des appels au dpart.....................................................................................50 5.2.6. Voie logique unidirectionnelle au dpart.........................................................................50 5.2.7. Voie logique unidirectionnelle larrive........................................................................51 5.2.8. Longueur de paquet par dfaut non standard..................................................................51 5.2.9. Longueur de fentre par dfaut non standard..................................................................51 5.2.10. Attribution de la classe de dbit par dfaut................................................................... 51 5.2.11. Acceptation de la taxation larrive............................................................................ 51 5.3. Codage du champ de facilits..................................................................................................51 5.3.1. Classes de codes.............................................................................................................. 51 5.3.2. Codage des codes............................................................................................................52 5.3.3. Codage des paramtres................................................................................................... 52 5.3.4. Catgories de codes.........................................................................................................52 5.4. Services demands par champ de facilits...............................................................................53 5.4.1. Ngociation des paramtres de contrle de flux............................................................. 53 5.4.1.1. Tailles de paquets.................................................................................................... 53 5.4.1.2. Tailles de fentre......................................................................................................54 5.4.1.3. Ngociation de la classe de dbit.............................................................................54 5.4.2. Groupe ferm dusagers.................................................................................................. 54 5.4.3. Groupe ferm dusagers bilatral.................................................................................... 54 5.4.4. Slection rapide et taxation larrive............................................................................ 54 5.4.4.1. Slection rapide....................................................................................................... 54 5.4.4.2. Acceptation de la slection rapide........................................................................... 54 5.4.4.3. Taxation larrive..................................................................................................54 5.4.4.4. Codage.....................................................................................................................55 5.4.5. Avertissement de taxation............................................................................................... 55 5.4.6. Identification dusager du rseau.....................................................................................55 5.4.7. Avis de taxation...............................................................................................................55 5.4.8. Choix de rseaux de transit............................................................................................. 55 5.4.9. Groupe de recherche....................................................................................................... 55 5.4.10. Transfert dappel........................................................................................................... 55 5.4.11. Notification du transfert dappel................................................................................... 55 5.4.12. Slection du dlai de transit...........................................................................................56 5.5. Services optionnels ITU..........................................................................................................56 5.5.1. Extension dadresse appelant.......................................................................................... 56 5.5.2. Extension dadresse appel............................................................................................. 56 5.5.3. Classe de dbit minimum................................................................................................. 57 5.5.4. Dlai de transit bout-en-bout...........................................................................................57 5.5.5. Donnes exprs............................................................................................................... 57 Chapitre6. Tables des diagnostics....................................................................................................... 58 Chapitre7. Classes de dbits................................................................................................................60
GET/INT/LOR
5 / 60
La couche rseau ; le protocole X.25
Index des figures

Figure 1. Concepts OSI........................................................................................................................ 8 Figure 2. Sous-rseaux relais.............................................................................................................. 11 Figure 3. Accs par rseau commutation de circuits........................................................................14 Figure 4. Accs par liaison spcialise................................................................................................ 15 Figure 5. Accs par rseau commut.................................................................................................. 15 Figure 6. Accs par rseau RNIS........................................................................................................15 Figure 7. Niveau trame ; liaison unique.............................................................................................. 16 Figure 8. Circuit virtuel.......................................................................................................................16 Figure 9. Exemple de multiplexage.....................................................................................................18 Figure 10. Procdure d'appel.............................................................................................................. 20 Figure 11. Procdure de libration......................................................................................................22 Figure 12. Refus d'tablissement d'appel.............................................................................................23 Figure 13. Libration par le rseau..................................................................................................... 23 Figure 14. Segmentation des messages...............................................................................................25 Figure 15. Segmentation-rassemblage...............................................................................................26 Figure 16. Exemple numrique de contrle de flux............................................................................ 26 Figure 17. Fonctionnement de la fentre.............................................................................................28 Figure 18. Mcanisme d'interruption.................................................................................................. 29 Figure 19. Mcanisme de rinitialisation.............................................................................................30 Figure 20. Mcanisme de reprise........................................................................................................ 31 Figure 21. Format gnral des paquets............................................................................................... 34 Figure 22. Format du champ identificateur gnral de format ...................................................... 34 Figure 23. Structure d'un paquet d'appel............................................................................................ 36 Figure 24. Bloc d'adresses (A = 0)......................................................................................................37 Figure 25. Bloc d'adresses (A = 1)......................................................................................................38 Figure 26. Structure d'un paquet de confirmation d'appel.................................................................. 41 Figure 27. Structure d'un paquet de libration....................................................................................42 Figure 28. Structure d'un paquet de confirmation de libration..........................................................43 Figure 29. Structure d'un paquet de donnes ; format normal............................................................ 44 Figure 30. Structure d'un paquet de donnes ; format tendu............................................................ 44 Figure 31. Paquet RR : prt recevoir ; format normal .................................................................... 45 Figure 32. Paquet RR : prt recevoir ; format tendu......................................................................45 Figure 33. Paquet RNR : non prt recevoir ; format normal............................................................46 Figure 34. Paquet RNR : non prt recevoir ; format tendu............................................................ 46 Figure 35. Paquet d'interruption......................................................................................................... 46 Figure 36. Paquet de confirmation d'interruption............................................................................... 47 Figure 37. Paquet de rinitialisation....................................................................................................48 Figure 38. Paquet de confirmation de rinitialisation..........................................................................48 Figure 39. Paquet de reprise............................................................................................................... 49 Figure 40. Paquet de confirmation de reprise..................................................................................... 49 Figure 41. Paquet de diagnostic..........................................................................................................49
GET/INT/LOR
6 / 60
Chapitre1. La couche rseau

1.1. Situation de la couche rseau
La couche rseau est la troisime couche du modle de rfrence OSI.
1.1.1. Rappels sur le modle OSI

Le modle OSI dfinit des procdures normalises qui permettent linterconnexion, suivie dun change effectif dinformations entre systmes1. En particulier, le modle permet de dfinir un interfonctionnement entre diffrents rseaux, du mme type ou de types diffrents, de faon pouvoir tablir une communication sur une combinaison de rseaux aussi facilement que sur un rseau unique. Pour laborer le modle de rfrence, une technique de structuration de base a t utilise: la structuration en couches. Selon cette technique, on considre que chaque systme est logiquement compos dun ensemble ordonn de sous-systmes. Les sous-systmes adjacents communiquent travers leur frontire commune. Lensemble des sous-systmes de mme rang constitue une couche. Sept couches ont t dfinies dans le modle de rfrence. De la couche la plus basse la couche la plus leve, on trouve les couches physique, liaison de donnes, rseau, transport, session, prsentation et application. Les couches 1 6, ainsi que le support physique contribuent llaboration progressive des services de communication. La couche application est la plus leve. Elle donne au(x) processus dapplication le moyen daccder lenvironnement OSI. La couche prsentation se charge de la reprsentation des informations. Elle permet de transfrer les donnes des applications sous une syntaxe commune, indpendamment de la reprsentation relle des donnes. La couche session fournit les moyens permettant dorganiser et de synchroniser les dialogues, ainsi que de grer les changes de donnes entre applications. La couche transport assure un transfert de donnes de bout en bout, fiable et dun bon rapport qualit/prix. La couche rseau prend en charge les problmes de routage et de relais. La couche liaison de donnes dtecte et corrige, dans la mesure du possible, les erreurs pouvant se produire dans la couche physique. Elle participe galement la gestion de la couche physique. La couche physique, enfin, fournit les moyens mcaniques, lectriques, fonctionnels et procduraux ncessaires lactivation, au maintien et la dsactivation des connexions physiques destines la transmission de bits.
1.1.2. Rappel de quelques dfinitions du modle OSI

La figure 1, Concepts OSI , schmatise les principaux concepts OSI ; nous en donnons ci-dessous une dfinition succinte de chacun deux.
1 Un systme est un ensemble dun ou plusieurs ordinateurs, le logiciel associ, des priphriques, des terminaux, des oprateurs, des processus physiques, des moyens de transfert dinformations, etc., qui forment un tout autonome mme dexcuter les oprations de traitement des informations et/ou de transfert des informations. GET/INT/LOR 7 / 60 La couche rseau ; le protocole X.25
entit transport
entit transport NSAP
entit transport
NCEP
entit rseau
entit rseau
entit rseau
Connexions rseau
Figure 1. Concepts OSI
1. Une entit rseau dialogue avec une entit transport via un point daccs appel NSAP (network service access point) afin de lui fournir un service. Ce service se matrialise par lchange de primitives2. Il existe quatre types de primitives : a) La requte : lentit transport demande lentit rseau dactiver un service. b) Lindication : lentit rseau avise lentit transport de lactivation dun service. c) La rponse : cest la rponse faite par lentit transport une indication reue de lentit rseau. d) La confirmation : lentit rseau avise lentit transport que le service qui a t demand est actif. Tous les services nutilisent pas systmatiquement la totalit des primitives. De nombreux services se contentent, en effet, des deux premires.
2 Une primitive est souvent ralise sous la forme dune ou plusieurs requtes entre logiciels de communications sur les machines relles. GET/INT/LOR 8 / 60 La couche rseau ; le protocole X.25
2. Les points ci-dessous concernent les rseaux fonctionnant en mode connect3. a) Le protocole de la couche rseau permet aux entits transport dtablir des connexions au travers desquelles seront changes des donnes. Les donnes changes entre une entit rseau et une entit transport sont appeles units de donnes du service rseau (NSDU : network service data unit) . b) Les entits de transport dialoguent travers la couche rseau en utilisant les connexions rseau et les services offerts par la couche rseau (et les couches de niveau infrieur). c) Les identificateurs dextrmit de connexion rseau (ncep : network connection endpoint) servent identifier une connexion rseau de manire unique en un point daccs. d) Un utilisateur4 du service rseau appelant est un utilisateur qui met une demande dtablissement de connexion rseau. e) Un utilisateur du service rseau appel est un utilisateur avec lequel un autre utilisateur du service rseau souhaite tablir une connexion rseau. (Ils sont tous deux dfinis par rapport une seule connexion rseau ; ceci signifie quun utilisateur peut tre au mme moment appelant et appel, mais bien sr, pas avec la mme connexion). Lutilisateur appel reoit la demande dtablissement de rseau. Il peut : i. soit laccepter (la connexion sera tablie), ii. soit la refuser. 3. Les points ci-dessous concernent les rseaux fonctionnant en mode datagramme5. a) Le protocole de la couche rseau permet aux entits transport dchanger des units de donnes du service rseau (NSDU). Les NSDU sont achemines indpendant les unes des autres. b) Les entits de transport dialoguent travers la couche rseau en utilisant un service unique offert par celle-ci (transfert de donnes). c) La notion de ncep nexiste pas. Les dfinitions qui suivent concernent principalement les rseaux fonctionnant en mode connect. Pour les rseaux fonctionnant en mode datagramme, il suffit dignorer tous les paragraphes faisant rfrence au concept de connexion.
1.2. Rle de la couche rseau

La couche rseau fournit : 1. les moyens dtablir, de maintenir et de librer des connexions rseau entre des systmes dsirant communiquer.
3 Le mode connect est mis en uvre par les rseaux de type CONS : Connection-oriented Network Service. Le rseau tlphonique, les rseaux RNIS (Numris en France), commutation de paquets version circuit virtuel (X.25 ; exemple Transpac) sont des rseaux fonctionnant en mode connect. 4 Le terme utilisateur est un terme gnral dsignant indiffremment toute entit utilisant les services rseau. Cela peut donc reprsenter une entit transport comme une entit applicative. 5 Le mode datagrame (ou non connect) est mis en uvre par le rseaux de type CLNS : Connectionless Network Service. Les rseaux participant au rseau INTERNET sont des rseaux fonctionnant en mode datagrame. GET/INT/LOR 9 / 60 La couche rseau ; le protocole X.25
2. des fonctions et des procdures permettant aux entits de transport dchanger des NSDU en utilisant des connexions rseau (rseaux orients connexion), ou en utilisant des datagrammes (pour les rseaux sans connexion). 3. elle rend les entits de transport indpendantes des problmes de routage et de relais. 4. elle rend les entits de transport indpendantes des problmes lis ltablissement et au fonctionnement dune connexion rseau donne, y compris dans le cas o plusieurs sousrseaux sont utiliss en tandem ou en parallle. 5. elle masque aux entits de transport la faon dont les ressources des couches infrieures (par exemple les connexions de liaison de donnes) sont utilises pour fournir des connexions rseau. 6. elle effectue galement ladministration des rseaux (taxation, identification dabonn, exploitation, etc.).
1.3. Services fournis la couche transport

1.3.1. Services de base
Parmi tous les services de base de la couche rseau, le plus fondamental est bien entendu le transfert transparent des donnes (NSDU) entre les utilisateurs du service rseau. La faon dont les ressources de communication sont mises en uvre pour raliser ce service est donc invisible lutilisateur. 1.3.1.1. Transfert des NSDU changes entre les utilisateurs Les NSDU sont transfres sous forme de squence de paquets6 de donnes. Il ny a pas de limite impose sur la taille des NSDU7. 1.3.1.2. Routage et relais Pour relier deux entits rseau qui se trouvent dans des systmes dextrmit, il est parfois ncessaire de faire intervenir des systmes intermdiaires relais (cf. figure 2, Sous-rseaux relais , page 11). Les fonctions de routage dterminent un itinraire appropri travers les systmes intermdiaires relais. 1.3.1.3. Segmentation et groupage La couche rseau peut segmenter et/ou grouper des NSDU afin de faciliter leur transfert. La segmentation consiste dcouper une NSDU en plusieurs paquets (NPDU8). Lopration inverse sappelle rassemblage . Le groupage consiste transmettre sous forme dune seule NPDU plusieurs NSDU. Lopration inverse sappelle dgroupage . 1.3.1.4. Adressage Le service rseau utilise un systme dadressage (NSAP) qui permet chacun de ses utilisateurs de sidentifier de faon non ambigu parmi les autres utilisateurs du service rseau.
6 Le terme paquet est tout fait gnrique et ne suppose aucune rfrence particulire un protocole donn. 7 Il est vident que les NSDU seront quand mme bornes par les possibilits des machines relles. 8 NPDU = Network Protocol Data Unit = unit de donnes du protocole de rseau = le plus souvent un paquet. GET/INT/LOR 10 / 60 La couche rseau ; le protocole X.25
Systme extrmit Systmes intermdiaires relais
Systme extrmit
Figure 2. Sous-rseaux relais
1.3.2. Services lis aux connexions rseau.

Les paragraphes ci-dessous ne concernent bien sr que les rseaux pour lesquels la notion de connexion a un sens. 1.3.2.1. Connexions rseau Une connexion rseau fournit les moyens de transfrer des donnes entre entits transport identifies par des adresses rseau (NSAP). La couche rseau fournit les moyens dtablir, de maintenir et de librer des connexions rseau. Une connexion rseau est soit une connexion point--point, soit une connexion multipoint9 Il peut y avoir plusieurs connexions rseau entre les deux membres dune mme paire dadresses rseau. Les connexions rseau entre entits transport sont assures laide des connexions liaison fournies par la couche liaison de donnes. Une connexion rseau peut galement tre fournie sous forme de connexions de sous-rseaux en tandem, cest--dire en utilisant plusieurs sous-rseaux distincts mis en srie. 1.3.2.2. Multiplexage de connexions rseau Cette fonction peut tre utilise pour multiplexer des connexions rseau sur des connexions liaison, en vue doptimiser leur utilisation. En cas de connexions de sous-rseaux en tandem, un multiplexage sur des connexions de sous-rseaux particulires peut galement tre effectu pour optimiser leur utilisation. 1.3.2.3. Identification unique de connexion rseau Afin dtablir de manire unique une connexion rseau, la couche rseau fournit lentit de transport une identification de connexion de rseau (ncep) associe avec ladresse rseau.
9 Le terme anglais utilis pour ce type de connexion est multicast , par opposition aux connexions unicast (point--point), ou au trafic de type broadcast (diffusion). Dailleurs, dans ce dernier cas, on ne peut pas parler de connexion. GET/INT/LOR 11 / 60 La couche rseau ; le protocole X.25
1.3.2.4. Choix de la qualit de service A ltablissement de la connexion rseau, lutilisateur peut demander une certaine qualit de service caractrise par exemple par: 1. le dbit, 2. le temps de transit, 3. le taux derreur rsiduel, 4. la fiabilit, 5. le dlai dtablissement dune connexion rseau, 6. etc. Cette fonction permet deffectuer un choix de service dune faon telle quon puisse garantir le mme service aux deux extrmits dune connexion rseau quand elle emprunte plusieurs sousrseaux de qualits diffrentes. 1.3.2.5. Notification des erreurs Les erreurs irrcuprables dtectes par la couche rseau sont signales aux entits de transport. Ceci peut conduire ventuellement la libration de la connexion ou sa purge. 1.3.2.6. Maintien en squence La couche rseau doit, sur une connexion de rseau donne, assurer la remise des NSDU dans leur ordre dexpdition. 1.3.2.7. Contrle de flux Une entit transport rceptrice peut faire interrompre par le service rseau le transfert des NSDU travers le point daccs au service. Cette condition de contrle de flux peut ou non se propager lautre extrmit de la connexion rseau pour sy rpercuter sur lentit transport expditrice. Cette fonction existe si le service de contrle de flux est demand (ou disponible). 1.3.2.8. Libration Une entit de transport peut demander la libration dune connexion de rseau. Le service rseau ne garantit pas la remise des donnes confies avant la demande de libration et se trouvant toujours en transit. La connexion rseau est libre quelle que soit la raction de lentit de transport correspondante. La libration peut galement tre demande par la couche rseau elle-mme.
1.3.3. Services optionnels

Les services dcrits ci-aprs sont optionnels, ce qui signifie que : 1. dune manire gnrale, lutilisateur doit demander le service; 2. le prestataire du service rseau peut : a) soit honorer la demande, b) soit indiquer que le service nest pas disponible.
GET/INT/LOR
12 / 60
1.3.3.1. Transfert exprs de NSDU Le transfert exprs de NSDU fournit un moyen additionnel dchange dinformations sur une connexion rseau. Les NSDU exprs sont dune longueur limite et leur transfert est soumis un contrle de flux diffrent de celui des donnes normales. Les donnes exprs peuvent ventuellement doubler des donnes normales. Elles ne doivent jamais arriver en retard , cest--dire tre dpasses par des donnes normales. 1.3.3.2. Rinitialisation La rinitialisation est utilise pour remettre la connexion rseau dans un tat dfini connu des deux extrmits et synchroniser les activits des deux utilisateurs du service rseau. Ce mcanisme peut avoir un effet destructif sur des donnes en transit. 1.3.3.3. Confirmation de remise des donnes. Dans certaines circonstances, lutilisateur de la couche rseau peut confirmer la rception des donnes. 1.3.3.4. Dtection derreurs Les fonctions de dtection derreurs servent surveiller le maintien de la qualit de service sur une connexion rseau. Dans la couche rseau, la dtection derreurs utilise les notifications derreurs fournies par la couche liaison. Des moyens additionnels de dtection derreurs peuvent tre ncessaires pour assurer la qualit de service requise. 1.3.3.5. Reprise sur erreur Cette fonction permet la reprise sur erreurs pralablement dtectes. Elle peut varier suivant la qualit du service rseau fournie.
GET/INT/LOR
13 / 60
Chapitre2. Gnralits sur le protocole X.25

2.1. Prsentation de X.25
Dfinie en 1976, la recommandation X.25 de lITU a pour but de dcrire : Linterface entre ETTD et ETCD pour terminaux fonctionnant en mode paquet et raccords par circuit spcialis des rseaux publics de donnes . Les informations contenues dans ce document sont conformes la recommandation ITU-T X.25 (mars 1993). Cette norme dfinit trois niveaux indpendants de protocole ou dinterface permettant linterconnexion dETTD au travers dun rseau commutation de paquets. Elle ne dfinit en aucun cas les protocoles mis en uvre au sein des rseaux commutation de paquets. Les trois niveaux dfinis par X.25 correspondent aux trois premires couches du modle de rfrence OSI (physique, liaison et rseau), mais comme ils ont t dfinis avant lapparition du fameux modle, ils sont dnomms respectivement niveaux physique, trame et paquet.
2.1.1. Niveau physique

Les rseaux commutation de paquets peuvent offrir une ou plusieurs des interfaces physiques suivantes. Ils peuvent bien sr en offrir dautres. 1. Recommandation ITU-T X.21 ; (cf. figure 3, Accs par rseau commutation de circuits , infra) 2. Recommandation ITU-T X.21bis ; (cf. figure 4, Accs par liaison spcialise , page 15) 3. Recommandations ITU-T de la srie V ; (cf. figure 5, Accs par rseau commut , page 15) 4. Recommandation ITU-T X.31. (cf. figure 6, Accs par rseau RNIS , page 15)
usager interface X.21
Rseau commutation de circuits
Rseau commutation de paquets
Figure 3. Accs par rseau commutation de circuits
GET/INT/LOR
14 / 60
usager
Liaison spcialise
interface X.21 bis
Figure 4. Accs par liaison spcialise
usager interfaces V
Rseau commut
Figure 5. Accs par rseau commut
usager
Rseau numrique intgration de donnes interfaces X.31
Figure 6. Accs par rseau RNIS
2.1.2. Niveau trame

Le niveau trame correspond la couche liaison de donnes du modle de rfrence OSI. Deux types de procdures sont utilisables ce niveau : 1. procdure liaison unique (identique au mode LAPB du protocole HDLC) ; 2. procdure multi-liaison (plusieurs supports physiques).
GET/INT/LOR
15 / 60
LAPB
usager
Figure 7. Niveau trame ; liaison unique
Lobjectif du niveau trame est de se prmunir contre les erreurs de transmission pouvant survenir entre lusager et le rseau. Le niveau trame permet galement un contrle de flux global au niveau de linterface usager-rseau.
2.1.3. Niveau paquet

Lobjectif du niveau paquet est de permettre linterconnexion entre deux usagers du rseau par lintermdiaire de ce lon appelle un circuit virtuel. Un usager peut ouvrir (crer) plusieurs circuits virtuels ce qui lui permet de pouvoir grer plusieurs communications simultanment (multiplexage). 2.1.3.1. Gestion de circuit virtuel Un circuit virtuel consiste en une mise en communication de deux usagers.
Rseau commutation de paquets usager usager
Figure 8. Circuit virtuel
On distingue deux types de circuits virtuels : 1. les circuits virtuels permanents (CVP) qui sont des circuits tablis et maintenus de faon permanente par le rseau (plutt rares) ; 2. les circuits virtuels commuts (CVC) qui sont des circuits tablis et librs chaque communication sur demande dun usager. Le niveau paquet gre les circuits virtuels tablis par lusager avec ses correspondants en assurant : 1. ltablissement et la libration des circuits virtuels commuts,
2. le transfert des donnes sous forme de paquets, 3. le contrle du transfert des donnes, 4. la gestion des erreurs. Les niveaux physique (bit) et liaison de donnes (trame) dun ETTD sont purement locaux, cest-dire quils nont aucune interaction avec ceux de lautre ETTD. Les actions prises au niveau paquet sont par contre rpercutes au niveau paquet de lautre ETTD10. Les donnes dun ETTD sont intgralement transmises lautre ETTD. Un ETTD peut, dans les limites de la capacit de sa liaison physique, tablir et utiliser plusieurs circuits virtuels simultanment (cf. Sections 2.1.3.2 et 2.1.3.4). 2.1.3.2. Voie logique Afin de permettre la coexistence un instant donn de plusieurs communications virtuelles, on utilise des identifiants de communication appels numro de voie logique. Un numro de voie logique est attribu lors de labonnement chaque circuit virtuel permanent. Dans le cas dune communication commute, le numro de voie logique est attribu lors de la phase dtablissement du circuit virtuel. 2.1.3.3. Contrle de flux Le contrle de flux permet un rcepteur dinformation de limiter la vitesse laquelle un metteur met ses paquets de donnes. Le contrle de flux ne sexerce habituellement pas de bout en bout. Lorsque labonn rcepteur de donnes ne peut plus continuer recevoir des donnes, il signale cet tat de fait au nud du rseau auquel il est rattach. Ce dernier peut rpercuter ce contrle vers labonn metteur des donnes. 2.1.3.4. Multiplexage Le multiplexage (cf. figure 9, Exemple de multiplexage , page 18) permet un abonn dtablir plusieurs communications (appeles circuits virtuels) sur un mme support physique, ou plus prcisment sur une mme liaison daccs entre labonn et le rseau11. Dans la figure 9, le circuit virtuel entre les usagers A et B emprunte la voie logique n 1 sur la liaison daccs de A, et la voie logique n 2 sur la liaison daccs de B. Ainsi, lorsquun paquet est mis entre A et le rseau ( destination de B), il utilise la voie logique numro 1 ; lors de lmission de ce paquet entre le rseau et B, il utilise la voie logique numro 2. Simultanment, le circuit virtuel entre les usagers A et C emprunte la voie logique n 2 sur la liaison daccs de A, et la voie n 1 sur celle de C. Enfin, le circuit virtuel entre les usagers A et D emprunte la voie logique n 3 sur la liaison daccs de A, et la voie n 1 sur celle de D. Les numros de voie logique ont une signification locale, entre un usager et le rseau.
10 Cela ne signifie pas quil y ait un contrle de bout en bout. 11 Cette dernire remarque est importante, puisque la liaison daccs peut tre constitue de plusieurs supports physiques (cas de la liaison multiligne). GET/INT/LOR 17 / 60 La couche rseau ; le protocole X.25
VL1 2 VL2 Abonn B VL1 VL2 VL3 Abonn A 1 2 3 1 VL1 Abonn C
VL1 Abonn D
Figure 9. Exemple de multiplexage
GET/INT/LOR
18 / 60
Chapitre3. Procdures X.25

Ce chapitre a pour but de dcrire les mcanismes fondamentaux que doivent mettre en uvre les rseaux commutation de paquets, ainsi que les ETTD (usagers) dsirant sy raccorder. Ce sont : 1. Les procdures dtablissement et de libration des communications ; 2. Les procdures pour le transfert des donnes ; 3. Les procdures de contrle de flux ; 4. Les procdures de gestion des incidents. Le service de circuit virtuel permanent (CVP) utilise les procdures 2 4 ; le service de circuit virtuel commut (CVC) utilise toutes les procdures. La structure des paquets utiliss pour mettre en uvre ces procdures est dcrite en section 4, page 34. A ces procdures grant le service de commutation, sajoutent des procdures permettant la gestion de services complmentaires (galement appels facilits ) dcrits en section 5, page 50. Les noms des paquets utiliss dans les chronogrammes sont en anglais pour des raisons de place. En outre, la majorit des produits analyseurs de protocole affiche le nom des paquets en anglais.
3.1. Etablissement dun circuit virtuel

Lobjectif de ltablissement dun circuit virtuel est de crer un chemin travers un rseau commutation de paquet, de le marquer (de faon ce que les paquets suivants empruntent ce chemin, quel que soit le sens de transmission), et de rserver des ressources dans les nuds de commutation de faon permettre le passage de ces paquets. La figure 10 prsente le principe gnral dune procdure dappel. Dans cette figure, n et n reprsentent les numros de voie logique.
3.1.1. Choix des voies logiques.

Dune manire gnrale, un usager12 dispose dune gamme de voies logiques convenue avec le rseau13 auquel il est raccord. La manire de choisir une voie logique libre est la suivante : 1. un usager doit choisir la premire voie logique libre dont le numro didentification est le plus lev possible dans la gamme des numros qui lui sont attribus. 2. Le rseau doit, par contre, choisir la premire voie logique libre dont le numro didentification est le plus bas possible dans la gamme des numros attribus lusager.
3.1.2. Demande dtablissement ct appelant

Un ETTD dsirant tablir une communication (autrement dit un circuit virtuel) met un paquet dappel [call] sur une voie logique libre (cest--dire qui nest pas dj affecte un autre circuit virtuel). Ce paquet dappel est souvent appel paquet dappel sortant . Le paquet dappel sortant contient les champs suivants :
12 Dans la recommandation X.25, lusager est appel ETTD. 13 Egalement appel ETCD dans la recommandation X.25. GET/INT/LOR 19 / 60 La couche rseau ; le protocole X.25
1. le numro de voie logique choisi par lappelant (cf. Section 3.1.1, page 19); 2. ladresse de lappel ; 3. ventuellement ladresse de lappelant ; 4. ventuellement un champ de facilits demandant des options ou des services complmentaires ; 5. enfin, des donnes dappel (facultatives).
ETTD A ETCD A rseau ETCD B ETTD B
n call
n call
n ca
ll co
nf
ll n ca
conf
n d
ata
n da
ta
n d
a ta
n dat
n d a
ta
n da
ta
Figure 10. Procdure d'appel
3.1.3. Demande dtablissement ct appel

Le rseau remet lappel un paquet dappel dit entrant. Le paquet dappel entrant utilise une voie logique parmi les voies logiques libres (cf. Section 3.1.1, page 19). Le paquet dappel entrant contient les informations suivantes : 1. le numro de voie logique choisie par le rseau ; 2. ladresse de lappelant ; 3. ventuellement ladresse de lappel ; 4. un champ de facilits (facultatif ; dpend du rseau) ;
5. des donnes dappel (si elles taient prsentes dans le paquet dappel mis par lappelant).
3.1.4. Rponse une demande dtablissement ct appel

Lappel peut : 1. accepter lappel en mettant un paquet de confirmation dappel [call conf], en utilisant la mme voie logique indique dans le paquet dappel entrant. 2. refuser lappel en mettant un paquet de libration [clear] (cf. Section 3.2, page 21 ainsi que figure 12, Refus d'tablissement d'appel , page 23). 3. ne pas rpondre avant un certain dlai14. Dans ce cas, le rseau considre que lappel est dans un tat o il est incapable de rpondre et entame une procdure de libration en mettant vers lappelant un paquet de libration [clear].
3.1.5. Confirmation dtablissement ct appelant

Lorsque lappelant reoit un paquet de confirmation dappel [call conf] sur la voie logique o il avait effectu son appel, il considre que la communication a t accepte par lappel. Sil reoit autre chose (en particulier un paquet de libration [clear]), il doit considrer que le circuit virtuel na pas t tabli.
3.2. Libration dun circuit virtuel

Trois cas peuvent se produire conduisant la libration dun circuit virtuel : 1. la communication peut tre normalement libre par un des deux usagers. 2. la communication peut galement tre libre par un des deux correspondants suite un refus dappel, 3. ou enfin, le rseau lui-mme peut dtruire une communication (gnralement suite une erreur).
3.2.1. Libration par un ETTD

La figure 11 prsente le principe gnral dune procdure de libration. Un ETTD peut tout moment rompre une communication en mettant un paquet de libration [clear]. Le rseau confirme immdiatement la libration du circuit virtuel en rpondant par un paquet de confirmation de libration [clear conf]. Ceci permet au numro de voie logique dtre de nouveau disponible pour une nouvelle communication. La libration progresse ensuite travers le rseau pour atteindre lautre extrmit. A lautre extrmit, le rseau transmet un paquet de libration qui doit tre confirm immdiatement par lusager.
14 Le dlai de non rponse un paquet dappel est le temporisateur T1 de la recommandation X.25. Il na absolu ment rien voir avec le temporisateur T1 du protocole HDLC ; le temporisateur T1 dHDLC permet de dtecter les pertes de trames. GET/INT/LOR 21 / 60 La couche rseau ; le protocole X.25
ETTD A
ETCD A
rseau
ETCD B
ETTD B
n clear
n clear
n cle
ar
conf
ear n c l
c onf
Figure 11. Procdure de libration
3.2.2. Refus dappel

Un ETTD demand peut galement refuser une communication entrante en mettant un paquet de libration au lieu dun paquet de confirmation dappel (cf. figure 12, page 23). Un ETTD demandeur peut galement faire chouer une communication aprs avoir mis son paquet dappel en mettant immdiatement un paquet de libration avant de recevoir le paquet de confirmation dappel. Ceci correspond au cas de lutilisateur qui raccroche avant que lappel nait abouti. Lorsque lETTD a mis son paquet de libration, le rseau met en retour un paquet de confirmation de libration [clear conf]. Ce paquet peut avoir une signification locale (cas le plus courant), soit une signification de bout-en-bout (ceci dpend des Administrations de rseaux).
3.2.3. Libration par le rseau

Dans ce contexte, on appelera rseau le nud local du rseau, ou un nud intermdiaire ou encore lETTD distant. La figure 13, page 23 prsente une telle libration. Le rseau indique ainsi : 1. la libration dun communication dj tablie ; 2. le refus de ltablissement dune communication. Le rseau met un paquet de libration. Ce paquet indique la cause de la libration ou du refus. LETTD rcepteur rpond par un paquet de confirmation de libration [clear conf].
GET/INT/LOR
22 / 60
ETTD A
ETCD A
rseau
ETCD B
ETTD B
n call
n call
n cl
n cl
ear
ar n cle
ear c
o nf
n dat
Figure 12. Refus d'tablissement d'appel
ETTD A
ETCD A
rseau
ETCD B
ETTD B
ar n cle
n clear
n clea
r conf
ear n c l
conf
Figure 13. Libration par le rseau
GET/INT/LOR
23 / 60
3.2.4. Transfert des donnes

La procdure de transfert des donnes sapplique chaque voie logique utilise. Le transfert des donnes est assur, dans les deux sens, par les paquets de donnes [data] et les paquets dinterruption [int]. Caractristiques gnrales du transfert : 1. toutes les donnes dusager (dans les paquets de donnes et dinterruption) sont transmises en transparence sans que le rseau introduise daltration, 2. lordre des lments binaires dans les paquets de donnes et dinterruption est conserv, 3. les squences de paquets sont transfres comme des squences de paquets compltes (cf. Section 3.2.5). Le transfert des donnes ne peut seffectuer que si la voie logique est dans ltat transfert de donnes (la voie logique dun circuit virtuel permanent se trouve toujours dans cet tat, sauf pendant le droulement de la procdure de reprise). Durant cette priode, un ETTD peut recevoir : 1. des paquets de donnes transportant des informations ; 2. des paquets dinterruption transportant galement des informations ; ces paquets ne sont pas soumis au contrle de flux (voir Section 3.2.9, page 29) ; 3. des paquets de contrle de flux limitant la vitesse de transfert des paquets de donnes (cf. Section 3.2.6, page 25) ; 4. des paquets de rinitialisation utiliss pour rgler les diffrents cas derreurs ou dincidents se produisant au niveau du rseau ou des quipements (cf. Section 3.3, page 29).
3.2.5. Segmentation des messages

La longueur du champ de donnes dans un paquet de donnes tant born, si un ETTD veut transmettre un message de longueur suprieure cette borne, il doit le dcouper en plusieurs paquets (segmentation). Il est alors possible dindiquer la dlimitation du message au destinataire laide dun bit dnomm M (M = More data). Le destinataire peut ainsi reconstruire le message initial (rassemblage). La figure 14 rsume ce mcanisme. La figure 15 donne une autre version de lexemple prcdent.
GET/INT/LOR
24 / 60
300 octets Segmentation 128 octets M=1 128 octets M=1 Rseau 44 octets M=0 Segmentation
32 octets M=1 32 octets M=1
32 octets M=1 32 octets M=1 300 octets
32 octets M=1 12 octets M=0 Rassemblage
Figure 14. Segmentation des messages
3.2.6. Contrle de flux

Le rythme de transfert des donnes sur un circuit virtuel est limit, entre autres choses , par les possibilits de rception du destinataire. Il est donc ncessaire que la transmission des donnes par le rseau vers le destinataire soit asservie par le rcepteur lui-mme: il met pour cela des autorisations dmission vers le rseau. Ce contrle de flux est rpercut par le rseau vers labonn metteur, galement sous forme dautorisations dmission. Le contrle de flux seffectue indpendamment sur chaque sens de transmission de chacun des circuits virtuels dun usager. (cf. figure 16, page 26) (cf. section 3.2.7, page 27 et section 3.2.8, page 27). Dans lexemple numrique de la figure 16, lETTD A transmet le paquet n 5 et est prt recevoir un paquet de donnes portant un numro P(S) = 3. Le rseau rpond lETTD A quil est prt recevoir le paquet de donnes n 6. Du ct de lETTD B, cest le rseau qui transmet le paquet de donnes n 4 tout en tant prt recevoir un paquet n 2. LETTD B, quant lui, est prt recevoir le paquet n 5.
GET/INT/LOR
25 / 60
ETTD A
ETCD A
rseau
ETCD B
ETTD B
D 0,0
M [1 2
8]
D 0,0 M D 1,0 M D 2,0 M [32] [32] [32] [32] [32] [32] [32] [32] [32]
D 1,0
M [ 12
8]
D 3,0 M D 4,0 M D 5,0 M D 6,0 M
D 2,0
[4 4]
D 7,0 M D 0,0 M D 1,0
[12]
Figure 15. Segmentation-rassemblage
ETTD A
ETCD A
rseau
ETCD B
ETTD B
D 5, 3
D 4, 2
RR 6
RR 5
Figure 16. Exemple numrique de contrle de flux
GET/INT/LOR
26 / 60
3.2.7. Numrotation
Le contrle de flux est mis en uvre grce une fentre danticipation (cf. Section 3.2.8, page 27). Pour grer celle-ci, les paquets comportent des compteurs dmission et de rception : P(S) et P(R). Deux types de numrotations sont possibles pour ces compteurs : 1. de 0 7 (numrotation modulo 8) ; 2. de 0 127 (numrotation modulo 128). Sur chaque sens de transmission dune voie logique, les paquets de donnes en mission sont numrots en squence par le champ P(S). Les autorisations dmission pour lautre sens sont fournies par le champ P(R) qui indique le numro du prochain paquet que lon est prt recevoir. Si lextrmit concerne na pas de paquets de donnes transmettre, elle utilise, pour contrler le flux quelle reoit, les paquets RR ou paquets RNR qui comprennent essentiellement le numro de voie logique et le champ P(R). Les paquets RR sont utiliss soit par lETTD soit par le rseau pour indiquer quil est prt recevoir les W paquets qui sont lintrieur de la fentre, en partant de numro de squence P(R), P(R) tant le numro indiqu dans le paquet RR (cf. section 4.7, page 45). Les paquets RNR sont utiliss soit par lETTD, soit par le rseau pour indiquer une incapacit temporaire accepter des paquets de donnes supplmentaires sur une voie logique donne. Lorsquil reoit un paquet RNR, le rseau ou lETTD cesse de transmettre des paquets de donnes sur la voie logique concerne, mais la fentre est mise jour par le numro de squence P(R) du paquet RNR (cf. section 4.7, page 45). Ltat de non prt recevoir indiqu par la transmission dun paquet RNR est annul soit par la transmission dans le mme sens dun paquet RR, soit par une procdure de rinitialisation. La transmission dun RR aprs un RNR, au niveau des paquets, ne doit pas tre considre comme une demande de retransmission des paquets ayant dj t transmis.
3.2.8. Description de la fentre

Afin dviter des temps morts dans la transmission, on utilise un mcanisme danticipation sur les autorisations dmission en transmettant un numro de squence P(R). Ce numro de squence est transmis : 1. soit en mettant des paquets de donnes, 2. soit en mettant des paquets RR ou RNR. Labonn (ou bien le rseau) indique ainsi quil est prt recevoir un ou plusieurs paquets de donnes. Le premier paquet de donnes quil peut recevoir porte un numro de squence P(S) dont la valeur est celle de P(R) transmise auparavant. Le dernier paquet de donnes quil peut recevoir porte un numro de squence P(S) tel que : P S =P RW 1 W o W est un paramtre appel taille de fentre. La valeur W =2 est recommande comme valeur standard. La longueur maximale du champ de donnes des paquets de donnes et la taille de fentre W sont trs souvent appels paramtres de contrle de flux. Ils sont figs le plus souvent labonnement ou lors de ltablissement de chaque
GET/INT/LOR
27 / 60
circuit virtuel si le service de ngociation des paramtres de contrle de flux a t choisi labonnement.
taille de fentre : 2
DATA P(S)= 0
Donnes en provenance de lapplication
Donnes vers lapplication
RR P(R
)=1
Donnes en provenance de lapplication
DATA
RR P(
P(S)=
R)=2
Donnes en provenance de lapplication Donnes en provenance de lapplication Donnes en provenance de lapplication
P( DATA
Lapplication ne vient pas chercher tout de suite les donnes Donnes vers lapplication Donnes vers lapplication
S)=2
P DATA
(S)=3
fentre ferme
RR P(
R)=4
fentre rouverte
DATA P(
S)=4
les donnes peuvent enfin partir
Figure 17. Fonctionnement de la fentre
La figure 17 prsente un exemple de fonctionnement du contrle de flux : lorsque labonn dsire ralentir ou arrter momentanment le flux des paquets de donnes que lui transmet le rseau sur un circuit virtuel, il cesse de transmettre les autorisations dmettre. Ce dernier rpercute ce blocage lautre extrmit avec un dcalage qui dpend des possibilits de stockage pour ce circuit virtuel. Lorsque labonn accepte nouveau de recevoir des donnes, il envoie une autorisation dmettre en faisant progresser le numro de squence P(R), et le rseau lve le blocage lautre extrmit du circuit virtuel.
GET/INT/LOR
28 / 60
3.2.9. Donnes exprs (interruption)

Le mcanisme dinterruption (cf. figure 18) permet un ETTD de transmettre jusqu 32 octets de donnes sans que ceux-ci soient soumis aux rgles de contrle de flux. Cest--dire quun paquet dinterruption peut tre mis mme si la fentre est ferme. Le paquet dinterruption [int] (cf. section 4.8, page 46) peut donc dpasser les paquets de donnes lorsque le contrle de flux les ralentit. Cette procdure ne peut tre utilise que dans ltat transfert des donnes.
n int
n int
n in
t con
tc n in
onf
Figure 18. Mcanisme d'interruption
LETTD distant confirme la rception de ce paquet en mettant un paquet de confirmation dinterruption [int conf] (cf. section 4.8, page 46). Il est interdit dmettre un autre paquet dinterruption [int] tant que le premier na pas t confirm.
3.3. Gestion des incidents

Afin de rgler les divers cas derreurs ou dincidents pouvant se produire au niveau du rseau ou des quipements connects, les ETTD ou le rseau peuvent mettre : 1. un paquet de rinitialisation [reset] qui concerne un seul circuit virtuel, 2. un paquet de libration [clear] (un seul circuit virtuel), 3. un paquet de reprise [restart] qui concerne lensemble des circuits virtuels dun ETTD. 4. un paquet de diagnostic [diag] (mis seulement par le rseau) concernant lensemble des voies logiques. Chacun de ces paquets est mis avec un octet de cause et un de diagnostic (ce dernier est appel explication de diagnostic dans le cas du paquet de diagnostic) prcisant la nature de lerreur ou de lincident dtects.
GET/INT/LOR
29 / 60
3.3.1. Procdure de rinitialisation

Ce mcanisme permet la rinitialisation (cf. figure 19) dune communication virtuelle ou dun circuit virtuel permanent, ce qui a pour consquence la perte de paquets de donnes et dinterruption en transit dans le rseau. Cela se traduit galement par la remise zro de la numrotation des paquets de donnes du circuit virtuel, aux deux extrmits et dans les deux sens de transmission. Ce mcanisme peut tre utilis pour purger un circuit virtuel.
n RESE
n DA TA
T
n RESE T
ignor
S n RE
ET C
ONF
ignor
n IN
T TC ESE ONF
n DA
trait
TA
n R
Figure 19. Mcanisme de rinitialisation
Rinitialisation par lETTD LETTD dsirant provoquer la rinitialisation dun circuit virtuel met un paquet de rinitialisation [reset] (cf. section 4.9, page 47). La voie logique passe dans un tat o les paquets de donnes, dinterruption, RR et RNR sont ignors. Le rseau confirme la rinitialisation en transmettant lETTD un paquet de confirmation de rinitialisation [reset conf]. Rinitialisation par le rseau Le rseau peut galement provoquer une rinitialisation en transmettant un paquet de rinitialisation [reset], ce qui place la voie logique dans un tat o les paquets de donnes, dinterruption, RR et RNR sont ignors. LETTD rpond en transmettant un paquet de confirmation de rinitialisation [reset conf]. Causes et diagnostics de rinitialisation Tout paquet de rinitialisation est muni de deux champs cause de rinitialisation et diagnostic qui prcisent la raison de la rinitialisation. Dans le cas o la rinitialisation est provoque par un abonn, celui-ci a la possibilit dinsrer dans le champ diagnostic (cf. section 6, Tables des diagnostics , page 58) un code prcisant son correspondant les raisons de la rinitialisation. Les valeurs du champ de cause sont donnes par le tableau 6, page 47.
GET/INT/LOR
30 / 60
3.3.2. Procdure de reprise

La procdure de reprise (voir figure 20) sert initialiser ou rinitialiser linterface ETTD/ETCD au niveau de la gestion des paquets. Elle libre simultanment tous les circuits virtuels circuit virtuel commuts et rinitialise tous les circuits virtuels permanents. Reprise par lETTD A nimporte quel moment un ETTD peut demander une reprise en transmettant un paquet de reprise [restart] (cf. section 4.10, page 48).
ETTD A
ETCD A
rseau
ETCDs
ETTDs
0 RES
TART
n CLEA R
0R
AR EST
TC
ONF
N R CO LEA C
Abonn A
m CLEA
mC
LE
ON AR C
Abonn B
p RESE
ET C RE S
ONF
Abonn C circuit vituel permanent
Figure 20. Mcanisme de reprise
Le rseau confirme la reprise en mettant un paquet de confirmation de reprise [restart conf]. Toutes les voies logiques commutes du ct de lETTD demandeur de la reprise sont libres; toutes les voies logiques permanentes sont rinitialises. La libration des voies logiques commutes est bien entendu communique aux ETTD distants qui reoivent un paquet dindication de libration [clear]. La rinitialisation des voies logiques permanentes est galement communique aux ETTD distants sous la forme dun paquet dindication de rinitialisation [reset].
Reprise par le rseau Le rseau peut indiquer une reprise en transmettant un paquet de reprise [restart]. Dans cet tat, le rseau ignore tous les paquets, sauf ceux de demande de reprise et de paquet de confirmation de reprise. LETTD confirme la reprise en mettant un paquet de confirmation de reprise [restart conf]. L galement, les voies logiques commutes sont toutes libres, et les voies logiques permanentes sont toutes rinitialises. Causes et diagnostics de reprise Le paquet de reprise comporte des champs de cause (cf. tableau 7, page 4848) et de diagnostic (cf. section 6, Tables des diagnostics , page 58) qui en prcisent les raisons.Dans le cas o la reprise est provoque par un ETTD, celui-ci peut utiliser le champ de diagnostic son gr, et sa valeur sera transmise lETTD distant (octet de diagnostic du paquet dindication de libration remis lETTD distant). Consquences dune reprise Tous les paquets de donnes et dinterruption mis par lETTD (ou le rseau) avant le dclenchement dune procdure de libration, de rinitialisation ou de reprise sont transmis lETTD distant avant que lETCD distant transmette lindication correspondante linterface distante, ou sont mis au rebut par le rseau. Aucun paquet de donnes ou paquet dinterruption mis par un ETTD (ou le rseau) aprs lachvement dune procdure de rinitialisation linterface locale nest remis lETTD distant avant lachvement de la procdure de rinitialisation correspondante linterface distante. Quand un ETTD dclenche une procdure de libration, de rinitialisation ou de reprise son interface locale, tous les paquets de donnes et dinterruption, qui ont t remis par lETTD distant (ou par le rseau) avant que lindication correspondante ait t transmise lETTD distant sont remis lETTD dorigine avant la confirmation par lETCD de la demande de libration, de rinitialisation ou de reprise, ou bien sont mis au rebut par le rseau.
3.3.3. Autres erreurs

Le paquet de diagnostic [diag] (cf. section 4.11, page 49) est utilis par certains rseaux (exemple : Transpac) pour indiquer des conditions derreur, dans des circonstances o les mthodes habituelles dindication (rinitialisation, libration et reprise avec cause et diagnostic) sont inapplicables. Le paquet diagnostic fournit une information sur les erreurs qui sont considres comme incorrigibles au niveau paquet ; linformation fournie permet une analyse des erreurs et une correction par des couches plus leves, si cela est souhait ou possible. Un paquet de diagnostic [diag] est mis une seule fois par apparition particulire dune condition derreur. Il nest pas ncessaire que lETTD mette une confirmation lorsquil reoit un paquet de diagnostic.
3.4. Collisions
Plusieurs types de collisions peuvent se produire : 1. la collision dappel ; 2. la collision de libration ;
3. la collision de rinitialisation ; 4. la collision de reprise.
3.4.1. Collision dappel

Une collision dappel se produit lorsque lETTD et le rseau utilisent la mme voie logique, le premier pour mettre un paquet dappel sortant, le second pour mettre un paquet dappel entrant. Dans ce cas, le rseau traite le paquet dappel sortant et ne tient pas compte du paquet dappel entrant.
3.4.2. Collision de libration

Une collision de libration intervient lorsquun ETTD et le rseau transmettent simultanment un paquet de libration prcisant la mme voie logique. Dans une telle situation, le rseau et lETTD considrent que la libration est acheve ; ils nattendent pas de paquet de confirmation de libration. La voie logique passe ltat prt.
3.4.3. Collision de rinitialisation

Il peut se produire une collision de rinitialisation lorsque lETTD et le rseau mettent simultanment un paquet de rinitialisation prcisant la mme voie logique. Dans ce cas, lETTD et lETCD considrent que la rinitialisation est acheve.
3.4.4. Collision de reprise

Il se produit une collision de reprise lorsquun ETTD et un ETCD mettent simultanment un paquet de reprise. Dans un tel cas, lETCD et lETTD considrent que la reprise est termine et nattendent pas de paquet de confirmation de reprise.
GET/INT/LOR
33 / 60
Chapitre4. Description des paquets

4.1. Format gnral des paquets
La figure 21 prcise le format gnral de tous les paquets.
8 7 6 5 4 3 2 1
identification gnrale du format numro de voie logique identification du type de paquet
suite du paquet
Figure 21. Format gnral des paquets
Remarque : dans la figure 21 les lments binaires dun octet sont numrots de 8 1, llment binaire 1 tant llment binaire de poids faible, transmis en premier. Les octets dun paquet sont numrots la suite partir de 1 ; ils sont transmis dans cet ordre. Le format des trois premiers octets dun paquet est le mme quel que soit le type dun paquet.
4.1.1. Identification gnrale du format

Ce demi-octet sert indiquer le format gnral du paquet. Il occupe les lments binaires 5 8 du premier octet. Le bit 8 est appel bit Q (bit qualificatif de donnes) ou A (bit dadresse). Le bit 7 est appel bit D (bit de confirmation de remise ; D = delivery). Les bits 6 et 7 permettent de faire la distinction entre une numrotation modulo 8 ( 01 ) et numrotation modulo 128 ( 10 ).
A/Q
Figure 22. Format du champ identificateur gnral de format
GET/INT/LOR
34 / 60
bit 8 Le bit 8 est le bit A dans les paquets de connexion (call et call conf) et les paquets de libration (clear et clear conf) ; il permet de spcifier la structure du bloc dadresse. Ce mme bit 8 reprsente le bit Q (qualificatif de donnes) dans les paquets de donnes. Le bit 8 est 0 dans tous les autres paquets. bit 7 Le bit 7 est le bit D (delivery) dans les paquets dappel et de de confirmation dappel (call et call conf) ainsi que dans les paquets de donnes. Il permet dobtenir une confirmation de bout en bout des paquets de donnes. Il est 0 dans tous les autres paquets. bits 6 et 5 Ces bits permettent de dfinir le modulo de la numrotation utilise dans les paquets de donnes et les paquets RR, RNR et REJ. XY = 01 : modulo 8 XY = 10 : modulo 128 XY = 11 : modulo 32768 (non dvelopp dans ce document).
4.1.2. Numro de voie logique

Ce champ est prsent dans tous les paquets sauf les paquets de paquet de reprise et paquet de diagnostic (il est cod 0 dans ce cas l). Sa signification est locale linterface ETTD/ETCD.
4.1.3. Identification du type de paquet

Le tableau 1 rsume les diffrentes possibilits. Remarque : un lment binaire not x peut prendre la valeur 0 ou 1 .
Tableau 1. Identification de type de paquet
Paquet appel confirmation dappel libration confirmation de libration donnes interruption confirmation dinterruption RR modulo 8 RR modulo 128 RNR modulo 8 RNR modulo 128
8765 4321 0000 1011 0000 1111 0001 0011 0001 0111 xxxx xxx0 0010 0011 0010 0111 xxx0 0001 0000 0001 xxx0 0101 0000 0101
GET/INT/LOR
35 / 60
Paquet REJ modulo 8 REJ modulo 128 rinitialisation confirmation de rinitialisation reprise confirmation de reprise diagnostic demande denregistrement acceptation denregistrement
8765 4321 xxx0 1001 0000 1001 0001 1011 0001 1111 1111 1011 1111 1111 1111 0001 1111 0011 1111 0111
4.2. Appel
La figure 23 donne la structure gnrale dun paquet dappel. La longueur maximale dun paquet dappel ne doit pas dpasser 259 octets.
8 A 7 Q 6 X 5 X 4 3 2 1
numro de voie logique 0 0 0 0 1 0 1 1
bloc dadresses
longueur du champ de facilits
champ de facilits
donnes dappel de lutilisateur (16 ou 128 octets maximum)
Figure 23. Structure d'un paquet d'appel
GET/INT/LOR
36 / 60
4.2.1. Bloc dadresse

Le bloc dadresse possde deux formats selon la valeur du bit A du champ identificateur gnral de format. Le premier format est appel non TOA/NPI 15 ; il est slectionn avec A = 0. Ce format est compatible avec des adresses conformes ITU-T X.121 ou ITU-T X.301 dont la longueur ne dpasse pas 15 chiffres. Le second format, appel TOA/NPI , est slectionn avec A = 1. Ce format est utilisable pour : 1. des adresses conformes ITU-T X.121 ou ITU-T X.301 dont la longueur est suprieure 15 chiffres ; 2. des adresses de remplacement (non conformes ITU-T X.121 ou ITU-T X.301 ; par exemple des adresses IP). Le bloc dadresse du format TOA/NPI contient (outre ladresse proprement dite) des champs permettant de spcifier le type dadresse (TOA = type of address) et lidentification du plan de numrotage (NPI = numbering plan identifier). 4.2.1.1. Format non TOA/NPI (normal) Adresses conformes X.121 / X.301 de longueur infrieures ou gales 15 chiffres. La figure 24 donne le format du bloc dadresse quand A = 0.
longueur de ladresse de lappelant
longueur de ladresse de lappel
adresses de lappel et de lappelant dans cet ordre

0 0 0 0
Figure 24. Bloc d'adresses (A = 0)
4.2.1.1.1. Champ des longueurs dadresses Loctet 4 est affect aux indicateurs de longueur de champ pour les adresses des ETTD appelant et appel, et indiquent la longueur exprime en demi-octets des adresses de lETTD appel et appelant. 4.2.1.1.2. Champ dadresses Loctet 5 et les octets suivants contiennent ladresse de lETTD appel, lorsquelle est prsente, suivie de ladresse de lETTD appelant lorsquelle est prsente. Chaque chiffre dadresse est cod sur un demi-octet. Si le nombre total de chiffres est un nombre impair, on complte par un demioctet de zros.
15 TOA/NPI = type of address / numbering plan identifier ; type dadresse / identificateur de plan de numrotage. GET/INT/LOR 37 / 60 La couche rseau ; le protocole X.25
4.2.1.2. Format TOA/NPI (adressage tendu) Ce format est utilis pour des adresses comportant plus de 15 chiffres (X.121 ou X.301) ou non conformes X.121 / X.301. La figure 25 donne le format du bloc dadresse quand A = 1.
longueur de ladresse de lappel longueur de ladresse de lappelant
champs dadresses de lappel et de lappelant dans cet ordre
Figure 25. Bloc d'adresses (A = 1)
4.2.1.2.1. Champs des longueurs dadresses Ces champs ont une longueur de 1 octet. Ils indiquent la longueur, compte en demi-octets, des adresses dappelant et dappel. La valeur maximale dun indicateur de longueur ne doit pas dpasser 17 si ladresse est conforme X.121 ou X.301. Cette valeur maximale ne sapplique pas si le champ de type dadresse indique une adresse de remplacement (non conforme X.121 / X.301). 4.2.1.2.2. Champ dadresses Chaque champ dadresse contient trois sous-champs : 1. sous-champ TOA (cod sur 4 bits) (cf tableau 2) 2. sous-champ NPI (cod sur 4 bits) a) un codage pour des adresses dites de remplacement (cf. tableau 4) ; b) un codage pour les autres types dadresses (cf. tableau 3). 3. sous-champ des chiffres de ladresse.
Tableau 2. Codage du sous-champ TOA
Bits 0000 0001 numro international17
Type dadresse numro dpendant du rseau16
16 Dans ce cas, les chiffres dadresses prsents aprs les sous-champs TAO et NPI sont organiss conformment au plan de numrotage du rseau (indiqu par le sous-champ NPI). Par exemple, un prfixe ou un code dchappement pourrait tre prsent. GET/INT/LOR 38 / 60 La couche rseau ; le protocole X.25
Bits 0010 0101 dfinir numro nationala adresse de remplacement18
Type dadresse
adresse complmentaire seule
Tableau 3. Codage du sous-champ NPI
Bits 0001 0011 dfinir E.164 X.121 Dpendant du rseau20
Plan de numrotage19
Tableau 4. Codage NPI pour adresses de remplacement
Bits 0000 0001 0010 0011 4.2.1.2.3. Exemples
Directive de codages Adresse mnmonique code conformment T.50 Adresse OSI conformment X.213 / ISO 8348 Adresse MAC conforme ISO 8802 Adresse IP conforme RFC 877
Un abonn X.25 standard, dadresse X.121 1911509860615, dsire appeler une station dadresse IP 157.159.100.40 (on suppose que linterconnexion est possible). On obtiendra : A = 1 (adresse TOA/NPI) 1. adresse de lappel a) TOA = 05 (adresse de remplacement) b) NPI = 03 (adresse IP conforme RFC 877) c) chiffres de ladresse : 157 159 100 40 raison dun nombre par octet (soit 4 octets). 2. adresse de lappelant : a) TOA = 00 (numro dpendant du rseau)
17 Comme dans la recommandation ITU-T Q.931, le prfixe ou le code dchappement ne doivent pas tre inclus dans le sous-champ des chiffres dadresses. a Mme remarque que pour le numro international. 18 Lorsque le TOA indique une adresse de remplacement, le sous-champ NPI est interprt comme une directive de codage conformment au Tableau 4. 19 Un mcanisme quivalent celui fourni par les chiffres dchappement, dfini dans X.121, nest pas encore dfini pour servir avec les possibilits TOA/NPI ; ce mcanisme nutilisera pas le sous-champ NPI. Jusqu ce quun mcanisme de ce type soit disponible (ventuellement, un service complmentaire), seul le point de code X.121 est utilis. Les codes dchappement X.121 sont appliqus et, en cas dutilisation, le sous-champ TOA indique le numro dpendant du rseau. 20 Dans ce cas, les chiffres dadresses prsents aprs les sous-champs TAO et NPI sont organiss conformment au plan de numrotage du rseau (indiqu par le sous-champ NPI). Par exemple, un prfixe ou un code dchappement pourrait tre prsent. GET/INT/LOR 39 / 60 La couche rseau ; le protocole X.25
b) NPI = 03 (adresse X.121) c) chiffres de ladresse : 1911509860615 raison dun chiffre par demi-octet. Un abonn X.25 standard, dadresse X.121 1911509860615, dsire appeler une station dadresse X.121 191150396. On obtient: A=0 (addresses non TOA/NPI) 1. adresse de lappel : a) longueur de lappel = 9 b) chiffres de ladresse : 191150396 raison dun chiffre par demi-octet. 2. adresse de lappelant : a) longueur de lappelant : 13 b) chiffres de ladresse : 1911509860615 raison dun chiffre par demi-octet.
4.2.2. Champ de longueur du champ de facilits

Les lments binaires 7 1 de loctet suivant le bloc champ dadresse indiquent la longueur en octets du champ de facilits.
4.2.3. Champ de facilits

Le champ de facilits nest prsent que lorsque lETTD utilise une facilit optionnelle. Le champ contient un nombre entier doctets. La longueur maximale de ce champ dpend des facilits qui sont demandes. (cf. section 5, Services complmentaires ).
4.2.4. Champ des donnes de lutilisateur

Faisant suite au champ de facilits, le champ des donnes de lutilisateur peut contenir jusqu 16 (en standard) ou 128 octets. Ce champ est bien entendu optionnel. La variante de 128 octets doit tre demande dans le champ de facilits.
4.3. Confirmation dappel

La figure 26, page 41, donne la structure gnrale dun paquet de confirmation dappel. Les trois premiers octets du paquet de confirmation dappel sont obligatoires. Les octets suivants sont optionnels et peuvent ne pas tre prsents. Le bloc dadresses nest prsent que si des adresses sont utilises. Toutefois, si aucune adresse nest prsente, et quil existe un champ de facilits, il est ncessaire dinscrire la valeur zro dans le champ des longueurs dadresses (selon la version non TOA/NPI). Le bloc dadresses peut par exemple tre utilis pour indiquer que lETTD qui a confirm lappel nest pas celui qui tait initialement appel (transfert dappel).
GET/INT/LOR
40 / 60
8 A
7 Q
6 X
5 X
bloc dadresses
longueur du champ de facilits

Optionnel
champ de facilits
donnes dappel de lutilisateur (128 octets maximum)
Figure 26. Structure d'un paquet de confirmation d'appel
4.4. Libration
La Figure 27, page 42, donne la structure gnrale dun paquet de libration.
4.4.1. Champ de cause de libration

Loctet 4 dun paquet de libration est le champ de cause de libration; il indique la cause de la libration de la communication. Les diffrentes valeur de cet octet sont prsentes dans le tableau 5. Dans les paquets de libration mis par un ETTD, loctet de cause ne peut avoir que la valeur origine ETTD du tableau 5.
Tableau 5. Causes de libration
Cause origine ETTD

21
87654321 00000000 1xxxxxxx 00000001 00001001 00010001
hexadcimal 00 yx 01 09 11
numro occup drangement erreur de procdure distante
21 Lorsque le bit 8 est mis 1, les bits reprsents par x sont ceux inclus par lETTD distant dans le champ de cause. GET/INT/LOR 41 / 60 La couche rseau ; le protocole X.25
Cause acceptation de la taxation larrive non souscrite destination incompatible acceptation de la slection rapide non souscrite navire absent demande de service complmentaire non valide accs interdit erreur de procdure locale saturation du rseau numro inconnu EPR en drangement
87654321 00011001 00100001 00101001 00111001 00000011 00001011 00010011 00000101 00001101 00010101
hexadcimal 19 21 29 39 03 0B 13 05 0D 15
8 A
7 0
6 X
5 X
CAUSE DIAGNOSTIC
bloc dadresses
longueur du champ de facilits champ de facilits
Optionnel
donnes dappel de lutilisateur (128 octets maximum)

Figure 27. Structure d'un paquet de libration
GET/INT/LOR
42 / 60
4.4.2. Champ de diagnostic

Cet octet contient linformation supplmentaire sur la cause de la libration de la communication (voir la section 6, Tables des diagnostics , pour la liste des codes de diagnostic mis par le rseau). Dans le cas o la cause de la libration est origine ETTD, loctet de diagnostic est fourni par lETTD qui libre la communication. Le contenu smantique de loctet de diagnostic dpend alors de lETTD.
4.5. Confirmation de libration

La Figure 28, Structure dun paquet de confirmation de libration, donne la structure gnrale dun paquet de confirmation de libration. Les champs de ce paquet ont la mme signification et le mme codage que ceux du paquet de libration.
8 A 7 0 6 X 5 X 4 3 2 1
bloc dadresses
Optionnel
longueur du champ de facilits champ de facilits
Figure 28. Structure d'un paquet de confirmation de libration
4.6. Donnes
La figure 29, page 44, donne la structure dun paquet de donnes au format normal de numrotation (modulo 8) et la figure 30 donne celle au format tendu (modulo 128).
4.6.1. Champ de donnes

La longueur maximale normalise du champ de donnes est de 128 octets. De plus, les Administrations peuvent permettre des longueurs de champs maximum de 16, 32, 64, 256, 512, 1024, 2048 et 4096 octets. La longueur maximum du champ de donnes peut tre ngocie communication par communication. Naturellement, le champ de donnes peut contenir un nombre de bits infrieur ou gal au maximum choisi. Certains rseaux exigent que le champ de donnes contienne un nombre entier doctets.
8 Q
7 D
6 0
5 1
numro de voie logique P(R) M P(S) 0
champ de donnes de lutilisateur
Figure 29. Structure d'un paquet de donnes ; format normal
8 Q
7 D
6 1
5 0
numro de voie logique P(S) P(R) champ de donnes de lutilisateur

Figure 30. Structure d'un paquet de donnes ; format tendu
0 M
4.6.2. Numro de voie logique

Le numro de voie logique identifie localement le circuit virtuel.
4.6.3. Numros de squence P(R) et P(S).

Le champ P(R) est utilis pour indiquer le numro de squence du prochain paquet de donnes que lon peut recevoir. Le champ P(S) est utilis pour indiquer le numro de squence du paquet de donnes que lon met.
4.6.4. Elments binaires M, Q, et D

Llment binaire M (more data) est utilis pour grer la segmentation des NSDU (cf. Section 3.2.5, page 24). Le bit M est 0 sil ny a pas de donnes suivre, et 1 sil y en a.
Le bit Q (qualify) permet aux ETTD de dsigner deux niveaux de donnes, par exem ple pour transmettre des messages de supervision par le mme canal que les messages ordinaires22. Le bit D (delivery) indique si lETTD souhaite ou non recevoir un accus de rception de remise de bout-en-bout pour les donnes quil transmet. Tous les rseaux ne savent pas traiter le bit D.
4.7. Paquets RR et RNR

Les Figure 31, et Figure 32, donnent les deux structures dun paquet RR (Receiver Ready). Les Figure 33 et Figure 34, donnent les deux structures dun paquet RNR (Receiver Not Ready).
8 0 7 0 6 0 5 1 4 3 2 1
numro de voie logique P(R) 0 0 0 0 1
Figure 31. Paquet RR : prt recevoir ; format normal
8 0
7 0
6 1
5 0
numro de voie logique 0 0 0 0 P(R)

Figure 32. Paquet RR : prt recevoir ; format tendu
1 0
22 Le protocole X.29 utilise le bit Q. Les messages X.29 sont transmis avec Q=1. Les messages non X.29 sont transmis avec Q=0. La numrotation des paquets P(S) et P(R) est indpendante de la valeur de Q. GET/INT/LOR 45 / 60 La couche rseau ; le protocole X.25
8 8 0 0
7 7 0 0
6 6 0 1
5 5 1 0
4 4
3 3
2 2
1 1
numro de voie logique numro de voie logique 0 P(R) 0 0 0 0 0 0 1 1 0 0 1 1
Figure 33. Paquet RNR : non prt recevoir ; format normal P(R) 0
Figure 34. Paquet RNR : non prt recevoir ; format tendu
4.8. Interruption et confirmation dinterruption

Les Figure 35 et Figure 36 prsentent respectivement la structure dun paquet dinterruption et celle dun paquet de confirmation dinterruption. Vous noterez avec intrt (je nen doute pas) quil faut obligatoirement au moins un octet de donnes. Ceci date de lre prhistorique (ou presque) de la gense dX.25. A cette poque, les concepteurs avait eu lide de pouvoir transmettre rapidement (do labsence de contrle de flux) un paquet devant interrompre un processus tournant sur une machine distante (quelque chose comme un contrle-C ou un break ). Ce paquet fut appel paquet dinterruption. Loctet de donnes (le plus souvent 00 ) pouvait servir dinformation complmentaire (par exemple, le code du caractre correspondant linterruption) En 1988, ce paquet sest vu transform en une sorte de paquet de donnes exprs en ayant son champ de donnes allong jusqu 32 octets.
8 0
7 0
6 0
5 1
Donnes de l'utilisateur (1 32 octets)

Figure 35. Paquet d'interruption
GET/INT/LOR
46 / 60
8 0
7 0
6 0
5 1
Figure 36. Paquet de confirmation d'interruption
4.9. Rinitialisation et confirmation de rinitialisation

Les Figure 37 et Figure 38 prsentent respectivement la structure dun paquet de rinitialisation et de confirmation de rinitialisation. Le Tableau 6, quant lui, prsente les diverses causes de rinitialisation. Certaines causes ne concernent que les circuits virtuels permanents (CVP).
Tableau 6. Causes de rinitialisation
Cause 00 / 1xxxxxxx 01 03 05 07 09 0F 11 1D
Signification par abonn distant

23
Commentaire CVP
drangement de labonn distant erreur de procdure distante erreur de procdure locale saturation du rseau ETTD distant oprationnel rseau oprationnel destination incompatible rseau en drangement
CVP CVP CVP
23 lorsque le bit 8 de loctet de cause est mis 1, les autres bits de loctet de cause sont ceux inclus par lETTD distant dans le champ de cause de rinitialisation GET/INT/LOR 47 / 60 La couche rseau ; le protocole X.25
8 0
7 0
6 0
5 1
CAUSE DIAGNOSTIC
Figure 37. Paquet de rinitialisation
8 0
7 0
6 0
5 1
Figure 38. Paquet de confirmation de rinitialisation
4.10. Reprise et confirmation de reprise

Les Figure 39, et Figure 40, prsentent respectivement la structure dun paquet de reprise et de confirmation de reprise. La voie logique utilise pour ces paquets est toujours la voie zro. Cette voie est considre comme tant rserve au service du rseau. Le tableau 7 donne les diverses causes de reprise.
Tableau 7. Causes de reprise
Cause 00 / 1xxxxxxx 01 03 07 7F origine ETTD
Signification erreur de procdure locale saturation du rseau rseau oprationnel Enregistrement/annulation confirm24
24 Peut tre reu seulement si le service complmentaire denregistrement en ligne des services complmentaires est utilis. GET/INT/LOR 48 / 60 La couche rseau ; le protocole X.25
8 8 0 0 0 0 1 1
7 7 0 0 0 0 1 1
6 6 0 0 0 0 1 1
5 5 1 1 0 0 1
4 4 0 0 0 0 1
3 3 0 0 0 0 0 1
2 2 0 0 0 0 1 1
1 1 0 0 0 0 1 1
1 1 CAUSE DIAGNOSTIC
Figure 40. Paquet de confirmation de reprise
4.11. Diagnostic
Figure 39. Paquet de reprise
La Figure 41 prsente la structure dun paquet de diagnostic. La voie logique utilise pour ce paquet est toujours la voie zro. Cette voie est considre comme tant rserve au service du rseau. Loctet de code de diagnostic est donn en section 6, Tables des diagnostics .
8 0 0 1
7 0 0 1
6 X 0 1
5 X 0 1
4 0 0 0
3 0 0 0
2 0 0 0
1 0 0 1
CODE DE DIAGNOSTIC EXPLICATION DE DIAGNOSTIC

Figure 41. Paquet de diagnostic
GET/INT/LOR
49 / 60
Chapitre5. Services complmentaires

5.1. Gnralits
Ces services complmentaires (ou facilits) offerts aux ETTD sont disponibles sur demande de lETTD demandeur si celui-ci y a souscrit pour une priode donne. Ils peuvent tre mis en uvre de diverses manires : 1. Au moment de ltablissement des circuits virtuels avec ventuellement ngociation au moment de ltablissement du circuit. La demande est effectue par lintermdiaire du paquet dappel (champ de facilits) (cf. section 5.4, page 53). 2. Systmatiquement chaque tablissement sans ngociation (cest--dire par abonnement) (cf. section 5.2).
5.2. Services non demands par champ de facilits

5.2.1. Numrotation squentielle tendue des paquets
Elle sapplique toutes les voies logiques de linterface ETTD/rseau. Ce service assure une numrotation tendue squentielle des paquets de donnes modulo 128.
5.2.2. Modification du bit D

Ce service sapplique toutes les communications virtuelles de linterface ETTD/ rseau. Il est uniquement destin aux ETTD dsirant fonctionner avec la signification de numro de squence P(R) de bout-en-bout dans un rseau national.
5.2.3. Retransmission des paquets

Ce service sapplique toutes les communications de linterface ETTD/rseau. Il permet un ETTD de demander un rseau la retransmission des paquets dun ou plusieurs paquets de donnes conscutifs mis par le rseau. Pour cela, lETTD transmet un paquet de rejet (REJ) prcisant le numro de voie logique et un numro de squence P(R). Le rseau retransmet les paquets de donnes en commenant P(R).
5.2.4. Interdiction des appels larrive

Ce service sapplique toutes les communications de linterface ETTD/rseau. Labonnement ce service empche les communications entrantes dtre prsentes lETTD. LETTD peut tablir des communications de dpart.
5.2.5. Interdiction des appels au dpart

Ce service sapplique toutes les communications de linterface ETTD/rseau. Labonnement ce service empche le rseau daccepter les communications sortantes en provenance de lETTD. LETTD peut recevoir des communications entrantes.
5.2.6. Voie logique unidirectionnelle au dpart

Labonnement ce service empche les communications entrantes dtre prsentes lETTD sur la voie logique. LETTD ne peut tablir que des communications de dpart sur cette voie.
5.2.7. Voie logique unidirectionnelle larrive

Labonnement ce service empche les communications sortantes dtre acceptes par le rseau sur la voie logique. LETTD ne peut recevoir que des communications entrantes sur cette voie.
5.2.8. Longueur de paquet par dfaut non standard

Labonnement ce service complmentaire permet de choisir les longueurs de paquets par dfaut parmi celles de la liste de longueurs de paquets tablie par lAdministration. En labsence dabonnement, la longueur par dfaut est de 128 octets. Des valeurs autres que celles qui ont t choisies pour la longueur des paquets par dfaut peuvent tre ngocies pour une communication virtuelle au moyen du service complmentaire de ngociation des paramtres de contrle de flux.
5.2.9. Longueur de fentre par dfaut non standard

Labonnement ce service complmentaire permet de choisir la taille de longueur de fentre par dfaut non standard parmi celles de la liste tablie par lAdministration. En labsence dabonnement, la taille de fentre par dfaut est de 2. Des valeurs autres que celles qui ont t choisies pour la taille de fentre par dfaut peuvent tre ngocies pour une communication virtuelle au moyen du service complmentaire de ngociation des paramtres de contrle de flux.
5.2.10. Attribution de la classe de dbit par dfaut

En cas dabonnement ce service, les classes de dbit par dfaut sont choisies dans la liste tablie par lAdministration. Des valeurs autres que celles qui ont t choisies pour les classes de dbit par dfaut peuvent tre ngocies pour une communication virtuelle au moyen du service complmentaire de ngociation de la classe de dbit (cf. section 7, Classes de dbits ).
5.2.11. Acceptation de la taxation larrive

Ce service permet un rseau de remettre un ETTD des paquets dappels entrants comportant le service de la taxation larrive ;
5.3. Codage du champ de facilits

Le champ de facilits contient un lment de facilit pour chaque service ou groupe de services demands. Le premier octet de chaque lment indique le code du ou des services demands. Les octets restants contiennent ventuellement un champ de longueur de paramtre de service, suivi du paramtre de service lui-mme.
5.3.1. Classes de codes

Dans le but de spcifier des paramtres de service composs de 1, 2, 3 ou dun nombre variable doctets, les codes de service sont diviss en quatre classes. Les bits 8 et 7 de chaque code de service permettent la distinction de ces classes. Le codage gnral des classe est montr par le tableau 8.
GET/INT/LOR
51 / 60
Tableau 8. Codage des classes de codes de service
Classe A B C D
87654321 00XXXXXX 01XXXXXX 10XXXXXX 11XXXXXX
Signification paramtre un octet paramtre deux octets paramtre trois octets paramtre de longueur variable
5.3.2. Codage des codes

Le tableau 9 indique le code de chaque service optionnel (en hexadcimal).
Tableau 9. Codage des codes de service
Service Taille de paquet Taille de fentre Ngociation de classe de dbit Slection de GFU (format normal) Slection de GFU (format tendu) Slection de groupe ferm bilatral Slection rapide Taxation larrive Identification dusager du rseau Informations de taxation service demand indication dunit montaire indication de distance indication du segment de taxation indication de la dure dappel 04 C5 42 43 02 03 47 41 01 01 C6
Code
non dfini C2 C1 44 C4 C3 49
Choix de rseaux de transit (format normal) Choix de rseaux de transit (format tendu) Notification de transfert dappel Slection du dlai de transit
5.3.3. Codage des paramtres

Le codage des paramtres de service dpend du service demand.
5.3.4. Catgories de codes

Il y a quatre catgories de codes : 1. services X.25 (cf. section 5.4, page 53) ;
2. services non-X.25 fournis par le rseau local ; 3. services non-X.25 fournis par le rseau distant (dans le cas de communications traversant plusieurs rseaux) ; 4. services ITU optionnels (cf. Section 5.5, page 56). Des marqueurs de facilits, composs de deux octets, sont utiliss pour sparer les requtes X.25 (catgorie 1) des trois autres catgories dcrites ci-dessus. Lorsque plusieurs catgories sont simultanment prsentes, les marqueurs de facilits sont utiliss pour sparer ces catgories les unes des autres. Dans ce cas, toutefois, les services X.25 doivent prcder les autres catgories de service, et les services ITU (catgorie 4) doivent suivre toutes les autres catgories. Le premier octet dun marqueur de facilits est un code de service dont tous les bits sont zro. Les valeurs pour le codage du second octet, qui est un paramtre de service dpend de la catgorie de facilits, sont les suivantes:
5.4. Services demands par champ de facilits

5.4.1. Ngociation des paramtres de contrle de flux
Labonnement ce service permet la ngociation des paramtres de contrle de flux communication par communication. Les paramtres considrs sont la longueur du paquet et la taille de la fentre. Il nest pas ncessaire que les longueurs de paquets et les tailles de fentres soient les mmes aux deux extrmits dune communication virtuelle. 5.4.1.1. Tailles de paquets Paramtre sur deux octets : octet 1 : octet 2 : taille des paquets sens appel - appelant taille des paquets sens appelant - appel
Le tableau 10 donne le codage des tailles de paquets. Le principe de codage est simple puisquil obit la relation : code=log 2 taille
Tableau 10. Codage des tailles de paquets
code 4 5 6 7 8 9 10 11 12
taille de paquet 16 32 64 128 256 512 1024 2048 4096
GET/INT/LOR
53 / 60
5.4.1.2. Tailles de fentre Le paramtre est sur deux octets : octet 1: octet 2: taille de la fentre sens appel - appelant taille de la fentre sens appelant -appel
5.4.1.3. Ngociation de la classe de dbit Labonnement ce service permet la ngociation des classes de dbit communication par communication. Les classes de dbit sont considres indpendamment pour chaque sens de transmission. Le paramtre est sur un octet : Bits 8765: Bits 4321: sens appel - appelant sens appelant - appel
Voir la section 7 pour le codage binaire des dbits.
5.4.2. Groupe ferm dusagers

Lensemble des services complmentaires facultatifs de groupes ferms (GFU) permet aux usagers de constituer des groupes dETTD dont laccs larrive et/ou au dpart est limit. Diffrentes combinaisons de limitations daccs destination et/ou en provenance des ETTD bnficiant dun ou de plusieurs de ces services se traduisent par diffrentes combinaisons daccessibilit.
5.4.3. Groupe ferm dusagers bilatral

Lensemble des services complmentaires facultatifs de groupes ferms bilatraux (GFUB) permet deux ETTD de constituer des relations bilatrales leur permettant de communiquer entre eux, tout en excluant les communications avec les autres ETTD avec lesquels une relation de ce type na pas t tablie. Diffrentes combinaisons de limitations daccs applicables aux ETTD bnficiant de ces services se traduisent par diffrentes combinaisons daccessibilit.
5.4.4. Slection rapide et taxation larrive

5.4.4.1. Slection rapide Ce service peut tre demand par un ETTD pour une communication virtuelle. Le service de slection rapide, sil est demand dans un paquet dappel et sil nindique aucune restriction de rponse, permet ce paquet de contenir jusqu 128 octets de donnes ; il autorise le rseau transmettre, pendant la dure de ltat attente de lETTD, un paquet de confirmation dappel ou de libration comportant un champ de donnes pouvant comporter jusqu 128 octets, et dans le cas o la communication est tablie, il autorise la transmission dun paquet de libration ayant jusqu 128 octets de donnes. 5.4.4.2. Acceptation de la slection rapide Ce service permet un rseau de remettre un ETTD des paquets dappels entrants comportant le service de la slection rapide;. 5.4.4.3. Taxation larrive Un ETTD peut demander le service de taxation larrive pour une communication virtuelle donne. En cas dacceptation, la communication sera taxe labonn appel.
5.4.4.4. Codage bit 1 =0 bit 1 = 1 bit 8 = 0 bit 8 = 1 bit 8 = 1 bit 7 = 0 ou 1 bit 7 = 0 bit 7 = 1 taxation non demande taxation demande slection non demande slection demande sans restriction slection demande avec restriction
5.4.5. Avertissement de taxation

Labonnement ce service permet dempcher ltablissement de communications qui doivent tre payes par labonn. Le rseau ne transmet pas les paquets dappels entrants comportant la facilits de taxation larrive. Le rseau fait en sorte que les taxes soient imputes un autre abonn (parfaitement identifi) chaque fois quun appel est demand par lETTD.
5.4.6. Identification dusager du rseau

Cette facilit permet lETTD dindiquer dans son paquet dappel des informations sur la facturation et la scurit des rseaux utiliss.
5.4.7. Avis de taxation

Un ETTD peut demander ce service pour une communication virtuelle donne, ou peut sabonner ce service pour une priode donne. Si lETTD est celui qui doit tre tax, il peut demander recevoir dans son paquet de libration ou de confirmation de libration des informations de taxation.
5.4.8. Choix de rseaux de transit

Ce service permet lETTD appelant dindiquer une squence dun ou plusieurs rseaux de transit par lintermdiaire desquels la communication doit tre achemine.
5.4.9. Groupe de recherche

Ce service complmentaire rpartit les appels entrants dont ladresse est associe un groupe de recherche travers un groupement donn dinterfaces ETTD/rseau.
5.4.10. Transfert dappel

Cette facilit permet le transfert dun appel quand lETTD demand est occup ou hors service. Le service de base est limit gnralement un seul transfert dappel.
5.4.11. Notification du transfert dappel

Cette facilit permet davertir lETTD demandeur que son appel a t transfr, la raison du transfert et ladresse vers o a t effectu le transfert.
GET/INT/LOR
55 / 60
5.4.12. Slection du dlai de transit

Le dlai de transit choisi peut tre indiqu par lETTD appelant dans son paquet dappel. Le rseau, si cela est possible, alloue des ressources et tablit un routage de manire respecter le dlai de transit demand. Codage: Le paramtre contient deux octets. Le dlai de transit est exprim en millisecondes et cod en binaire sur les deux octets. Le bit 8 de loctet 1 est le bit de plus fort poids, et le bit 1 de loctet 2 est le bit de plus faible poids.
5.5. Services optionnels ITU

Le Tableau 11 indique le code de chaque service ITU optionnel (en hexadcimal).
Tableau 11. Codage des codes de service ITU
Service Extension dadresse appelant Extension dadresse appel Ngociation de classe de dbit minimum Dlai de transit de bout-en-bout Ngociation des donnes exprs C9 0A
Code CB
CA 0B
5.5.1. Extension dadresse appelant

Loctet suivant le code de service indique la longueur du paramtre en octets. Cette longueur vaut n + 1 o n est le nombre doctets ncessaires pour coder ladresse. Le premier octet du paramtre indique, dans les bits 8 et 7, lusage de ladresse dextension, comme indiqu par le Tableau 12.
Tableau 12. Usage des adresses d'extension
Bits 8 0 0 1 1 0 1 0 1 7
Usage transport dune adresse complte OSI de NSAP transport dune adresse partielle OSI de NSAP transport dune adresse non-OSI rserv
Les bits suivants du premier octets indique la longueur de ladresse proprement dite (longueur maximum: 40 chiffres). Les adresses sont codes raison de deux chiffres par octets.
5.5.2. Extension dadresse appel

Voir la Section 5.5.1, page 56.
GET/INT/LOR
56 / 60
5.5.3. Classe de dbit minimum

Pour le codage, voir la Section 5.4.1.3, page 54.
5.5.4. Dlai de transit bout-en-bout

Loctet suivant le code de paramtre donne la longueur en octets du paramtre. Il peut prendre les valeurs de 2, 4 ou 6. Les deux premiers octets du paramtre contiennent le dlai de transit cumul. Les octets 3 et 4 (optionnels) contiennent la valeur cible pour le dlai. Les octets 5 et 6 (optionnels) contiennent le dlai maximum acceptable. Les valeurs sont toutes exprimes en millisecondes et codes en binaire.
5.5.5. Donnes exprs

Bit 1 du paramtre = 0 Bit 1 du paramtre = 1 pas dutilisation des donnes exprs. utilisation des donnes exprs.
GET/INT/LOR
57 / 60
Chapitre6. Tables des diagnostics

Le tableau ci-dessous prsente les diffrentes valeurs normalises pouvant tre insres dans les octets de diagnostic des paquets de libration, de rinitialisation, de reprise et de diagnostic.
Tableau 13. Codage des octets de diagnostics
Diagnostic aucun renseignement supplmentaire P(S) non valable P(R) non valable type de paquet non valable pour ltat r1 pour ltat r2 pour ltat r3 pour ltat p1 pour ltat p2 pour ltat p3 pour ltat p4 pour ltat p5 pour ltat p6 pour ltat p7 pour ltat d1 pour ltat d2 pour ltat d3 paquet non autoris paquet non identifiable appel sur voie logique unidirectionnelle type de paquet non valable sur circuit virtuel permanent paquet sur voie logique non attribue pas dabonnement REJ paquet trop court paquet trop long identificateur gnral de format non valable paquet de reprise ou denregistrement avec voie logique non nulle type de paquet incompatible avec le service complmentaire confirmation dinterruption non autorise interruption non autorise rejet non autoris
GET/INT/LOR 58 / 60
dc. 0 1 2 16 17 18 19 20 21 22 23 24 25 26 27 28 29 32 33 34 35 36 37 38 39 40 41 42 43 44 45
hex. 00 01 02 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D
Diagnostic fin de course du temporisateur pour appel entrant pour indication de libration pour indication de rinitialisation pour indication de reprise difficults dtablissement de communication code de service complmentaire non autoris paramtre de service complmentaire non autoris numro du demand non valable numro du demandeur non valable longueur de service complmentaire non valable interdiction dappels larrive aucune voie logique disponible collision dappel service complmentaire demand en double longueur dadresse de valeur autre que 0 longueur de service complmentaire autre que 0 service complmentaire attendu et non fourni service complmentaire spcifi par CCITT non valable divers code de cause incorrect en provenance de lETTD non alignements des octets lments Q mis des valeurs incompatibles problmes au niveau international problme du rseau distant problme de protocole international liaison internationale hors service liaison internationale occupe problme de service compl. dans le rseau de transit problme de service compl. dans le rseau distant problme dacheminement international problme dacheminement momentan DNIC (Data Network Identifier Code) appel inconnu opration de maintenance
dc. 48 49 50 51 52 64 65 66 67 68 69 70 71 72 73 74 75 76 77 80 81 82 83 112 113 114 115 116 117 118 119 120 121 122
hex. 30 31 32 33 34 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 50 51 52 53 70 71 72 73 74 75 76 77 78 79 7A
GET/INT/LOR
59 / 60
Chapitre7. Classes de dbits

Les classes de dbit ci-dessous sont utiliss dans le champ de facilits (cf. section 5.2.10, Attribution de la classe de dbit par dfaut la page 51) (cf. section 5.4.1.3., Ngociation de la classe de dbit , la page 54) (cf. section 5.5.3, Classe de dbit minimum , la page 57).
Tableau 14. Codage des classes de dbits de base
Codage binaire 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
Dbit (bit/s) rserv rserv rserv 75 150 300 600 1200 2400 4800 9600 19200 48000 64000 128000 192000
GET/INT/LOR
60 / 60

La Couche Réseau Le Protocole X.25: Michel Gardie

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

La Couche Réseau Le Protocole X.25: Michel Gardie

Transféré par

Droits d'auteur :

Formats disponibles

La couche rseau Le protocole X.

Dernire modification : lundi 20 dcembre 2004

Table des matires

La couche rseau ; le protocole X.25

Index des figures

La couche rseau ; le protocole X.25

Chapitre1. La couche rseau

1.1.1. Rappels sur le modle OSI

1.1.2. Rappel de quelques dfinitions du modle OSI

entit transport NSAP

Figure 1. Concepts OSI

1.2. Rle de la couche rseau

1.3. Services fournis la couche transport

Systme extrmit Systmes intermdiaires relais

Figure 2. Sous-rseaux relais

1.3.2. Services lis aux connexions rseau.

1.3.3. Services optionnels

La couche rseau ; le protocole X.25

La couche rseau ; le protocole X.25

Chapitre2. Gnralits sur le protocole X.25

2.1.1. Niveau physique

usager interface X.21

Rseau commutation de circuits

Rseau commutation de paquets

Figure 3. Accs par rseau commutation de circuits

La couche rseau ; le protocole X.25

Rseau commutation de paquets

interface X.21 bis

Figure 4. Accs par liaison spcialise

Rseau commutation de paquets

Figure 5. Accs par rseau commut

Rseau numrique intgration de donnes interfaces X.31

Rseau commutation de paquets

Figure 6. Accs par rseau RNIS

2.1.2. Niveau trame

La couche rseau ; le protocole X.25

Rseau commutation de paquets

Figure 7. Niveau trame ; liaison unique

2.1.3. Niveau paquet

Figure 8. Circuit virtuel

VL1 2 VL2 Abonn B VL1 VL2 VL3 Abonn A 1 2 3 1 VL1 Abonn C

Figure 9. Exemple de multiplexage

La couche rseau ; le protocole X.25

Chapitre3. Procdures X.25

3.1. Etablissement dun circuit virtuel

3.1.1. Choix des voies logiques.

3.1.2. Demande dtablissement ct appelant

Figure 10. Procdure d'appel

3.1.3. Demande dtablissement ct appel

3.1.4. Rponse une demande dtablissement ct appel

3.1.5. Confirmation dtablissement ct appelant

3.2. Libration dun circuit virtuel

3.2.1. Libration par un ETTD

Figure 11. Procdure de libration

3.2.2. Refus dappel

3.2.3. Libration par le rseau

La couche rseau ; le protocole X.25

Figure 12. Refus d'tablissement d'appel

Figure 13. Libration par le rseau

La couche rseau ; le protocole X.25

3.2.4. Transfert des donnes

3.2.5. Segmentation des messages

La couche rseau ; le protocole X.25