X.25 au niveau physique

Salut,

On Sun, 2 Nov 2003 15:04:15 +0100, Angelot <OnSePame@OnSePame.fr> wrote:

IP peut être encapsulé dans X.25.

Faut vraiment avoir envie, hein...

Supposons un routeur IP sur Ethernet côté client, et IP sur X.25 côté
réseau, avec un débit de 2 Mbit/s pour fixer les idées. On peut supposer
que le client veuille rejoindre le PAD de Transpac par exemple.

Euh... Un PAD c'est pour des connexions de type asynchrone <-> X.25. Je ne
vois pas bien comment on pourrait parler au PAD en IP sur X.25 (le PAD ne
parle pas IP). L'inverse est tout à fait possible, par contre.

Sur quel niveau physique pourra-t-il le faire ?

La norme ne donne que les protocoles X21 (avec connectique DB25), X21 bis
(analogique) et X.31 (RNIS). I'm confuse !

Je ne vois pas pourquoi? Tu voudrais quoi quoi comme niveau physique?

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Re-bonjour Jacques,

IP peut être encapsulé dans X.25.

Faut vraiment avoir envie, hein...

Probablement. Mais ça existe encore, les réseaux X.25 sont encore en usage,
leur disparition ne commencera à être significative qu'à partir de 2006
semble-t-il. Les administrations doivent avoir des réseaux privés X.25.

Supposons un routeur IP sur Ethernet côté client, et IP sur X.25 côté
réseau, avec un débit de 2 Mbit/s pour fixer les idées. On peut supposer
que le client veuille rejoindre le PAD de Transpac par exemple.

Euh... Un PAD c'est pour des connexions de type asynchrone <-> X.25. Je ne
vois pas bien comment on pourrait parler au PAD en IP sur X.25 (le PAD ne
parle pas IP). L'inverse est tout à fait possible, par contre.

IP encapsulé dans X.25 niveau 3, le PAD ne voit que X.25 en couche réseau :
IP représente de la donnée client de X.25. Le processus d'encapsulation est
décrit dans RFC1356.

PAD uniquement asynchrone, faut que je vois !

Sur quel niveau physique pourra-t-il le faire ?

La norme ne donne que les protocoles X21 (avec connectique DB25), X21
bis

(analogique) et X.31 (RNIS). I'm confuse !

Je ne vois pas pourquoi? Tu voudrais quoi quoi comme niveau physique?

Par exemple, du fractionnel E1.
Si l'entreprise veut utiliser le transport X.25 sur longue distance, par
Transpac par exemple, quelles sont les possibilités physiques de livraison
du débit ? Je suis surpris de ne voir mentionner dans la norme X.25 que les
interfaces X.21, X.21 bis et X.31.

Néanmoins, ces protocoles sont ceux possibles entre ETTD et ETCD. Et, en
fait, entre un ETCD chez le client et un ETCD chez un opérateur, on doit
pouvoir utiliser des protocoles classiques de transport de données : ADSL,
G.703, ATM sur SDH.

Cordialement,
Angelot

Salut,

On Sun, 2 Nov 2003 16:05:01 +0100, Angelot <OnSePame@OnSePame.fr> wrote:

Probablement. Mais ça existe encore, les réseaux X.25 sont encore en
usage,
leur disparition ne commencera à être significative qu'à partir de 2006
semble-t-il. Les administrations doivent avoir des réseaux privés X.25.

Oui, mais de là à vouloir faire de l'IP dessus... On voit plus souvent
l'inverse (transporter du X.25 sur IP pour se débarasser du réseau X.25 en
conservant les équipements terminaux et les applis). Les limites de X.25
(taille des trames, taille des fenêtres...) font que les performances
qu'on peut obtenir sont ridicules. Dans le cas le plus fréquent (trames de
128 octets, fenêtre à 7) On ne peut même pas envoyer un paquet IP de 1500
octets sans attendre!

IP encapsulé dans X.25 niveau 3, le PAD ne voit que X.25 en couche
réseau :
IP représente de la donnée client de X.25. Le processus d'encapsulation
est décrit dans RFC1356.

PAD uniquement asynchrone, faut que je vois !

Ben c'est tout vu pour moi, sauf à faire du SLIP/X.25 ou un truc idiot de
ce genre. Le PAD fait l'interface entre un terminal asynchrone (genre un
Minitel) et le réseau X.25, et convertit des paquets en flux asynchrones
et vice-versa. C'est pas pour rien que ça s'appelle un "Packet
Assembler/Disassembler" si je ne m'abuse.

L'équipement qui fera l'encapsultation d'IP dans X.25 jouera le même role,
mais le résultat sera différent:

Flux asynchrone <-> PAD <-> flux asynchrone encapsulé dans X.25
IP <-> équipement IP/X.25 <-> IP encapsulé dans X.25

Assez logiquement, les deux ne peuvent pas se parler. Il est cependant
possible de faire:

IP sur SLIP ou PPP (asynchrone) <-> PAD <-> IP/SLIP ou PPP/X.25 <-> XXX
<-> IP

XXX sera alors probablement un NAS, qui sur une connexion X.25 trouvera du
SLIP ou du PPP qui sera ensuite décapsulé pour en extraire de l'IP. En
fait, si je me souviens bien, c'est comme ça que le Kiosque Micro v1
fonctionnait. Et c'était une horreur sans nom!

Par exemple, du fractionnel E1.

C'est assimilable à du X.21, c'est du synchrone permanent point-à-point.
Il faut juste définir la façon d'utiliser les IT.

Si l'entreprise veut utiliser le transport X.25 sur longue distance, par
Transpac par exemple,

Vade retro, Satanas! Non, sérieusement, quel intérêt? C'est
super-hyper-mega-cher, et les performances sont archi-pitoyables.

quelles sont les possibilités physiques de livraison du débit ?

En permanent (accès directs):
LLP sur Canal D numéris (9600 bit/s)
14.4 kbit/s
19.2 kbit/s
48 kbit/s
64 kbit/s
128 kbit/s
256 kbit/s

C'est généralement livré en X.21 (sauf LLP bien sûr). Pour les débits les
plus bas on peut avoir du V.35 si je ne m'abuse, peut-être même du V.25.

Néanmoins, ces protocoles sont ceux possibles entre ETTD et ETCD. Et, en
fait, entre un ETCD chez le client et un ETCD chez un opérateur, on doit
pouvoir utiliser des protocoles classiques de transport de données :
ADSL, G.703, ATM sur SDH.

Sachant qu'en France en tous cas, c'est l'opérateur du réseau X.25 qui
fournit la liaison, c'est lui qui choisit le support qui lui plait pour
livrer, et fournit sur des interfaces prédéfinies.

Je ne connais pas d'encapsulation directe X.25/ADSL, vu que c'est presque
toujours de l'ATM. Et je ne suis même pas sûr qu'il existe d'encapsulation
de X.25 sur ATM.

Sérieusement, X.25...

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Bonsoir Jacques,

Merci pour cette discussion et ce détail.

C'est pas pour rien que ça s'appelle un "Packet
Assembler/Disassembler" si je ne m'abuse.

Je n'avais pas percuté sur cette appellation : reconstruire le paquet après
réception asynchrone ou, dans l'autre sens, le dépenailler pour l'écouler
octet par octet.

XXX sera alors probablement un NAS, qui sur une connexion X.25 trouvera du
SLIP ou du PPP qui sera ensuite décapsulé pour en extraire de l'IP.

Sglurps ! rapport avec serveur de stockage NAS ou autre signification ?

C'est généralement livré en X.21 (sauf LLP bien sûr).

J'ai déja vu la connectique DB15 supportant X.21 livré par fraction de 64
kbit/s. Mais que se passe-t-il si le client est à 10 km du point de
livraison ? ça peut-il passer par la ligne téléphonique ?

Et je ne suis même pas sûr qu'il existe d'encapsulation
de X.25 sur ATM.

Il m'a été rapporté que cela existait à plusieurs endroits de Norvège pour
des réseaux interbanques. Je n'en sais pas plus sur la normalisation (ce
n'est pas RFC1483). Pour sûr, ce n'est pas d'une optimisation farouche, les
critères seraient réutilisabilité du matériel et fiabilité de transmission.

Sérieusement, X.25...

On a parfois des surprises chez les clients.

Cordialement,
Angelot

Salut,

On Sun, 2 Nov 2003 22:46:22 +0100, Angelot <OnSePame@OnSePame.fr> wrote:

XXX sera alors probablement un NAS, qui sur une connexion X.25 trouvera
du SLIP ou du PPP qui sera ensuite décapsulé pour en extraire de l'IP.

Sglurps ! rapport avec serveur de stockage NAS ou autre signification ?

Aucun rapport. Network Access Server. Dans le cas le plus fréquent, un
routeur avec plein de ports et plein de modems qui accueille des
communications généralement non permanentes (commutées).

C'est généralement livré en X.21 (sauf LLP bien sûr).

J'ai déja vu la connectique DB15 supportant X.21 livré par fraction de 64
kbit/s. Mais que se passe-t-il si le client est à 10 km du point de
livraison ? ça peut-il passer par la ligne téléphonique ?

Le point de livraison = le client :-) On ne transporte pas le X.21 sur la
ligne, c'est juste une interface. Sur la ligne elle-même, ce sera suivant
les cas de la bande de base (ahhh nostalgie de nos bons vieux erbdb tout
bleus qui chauffaient les salles machines et claquaient une fois par
mois...), du HDB3 (G.703), du xDSL... Et suivant les cas, il faudra une ou
deux paires "classiques" ou de la paire blindée spéciale avec répéteurs
tous les... 3.7 km c'était? Je sais plus...

Et je ne suis même pas sûr qu'il existe d'encapsulation
de X.25 sur ATM.

Il m'a été rapporté que cela existait à plusieurs endroits de Norvège
pour des réseaux interbanques. Je n'en sais pas plus sur la normalisation
(ce n'est pas RFC1483).

Ca peut difficilement être une RFC si c'est du X.25 sur ATM directement,
ça relèverait de l'ITU et pas de l'IETF. La seule option qui me paraîtrait
crédible c'est du X.25/TCP/IP/ATM, mais bon...

Sérieusement, X.25...

On a parfois des surprises chez les clients.

Oui, mais comme je disais, ce sera plutôt X.25 sur IP (pour remplacer un
réseau X.25 cher et peu performant tout en gardant les équipements
terminaux et les applis) que l'inverse. Le seul cas que je connais(sais)
était le Kiosque Micro v1 (bon, et peut-être quelques raccordements
Internet par Transpac au tout début, les pauvres...), mais c'est parce que
Transpac avait un gros réseau X.25 et pas de réseau IP à l'époque.
Maintenant c'est plutôt l'inverse.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/