开云体育

Hi Alice, and welcome to the framestream!

No worries about "sounding clueless", it's a very esoteric subject and
really took me a couple of years to wrap my head around. Nobody has
written about it since the 90ies because, once you actually get down
to nitty-gritty, there's not actually much there?

The way I like to think of X.25 is this:

Imagine it's 1982, you operate a voice telephone network, and many of
your customers use analog modems to communicate across it. You've
recently spent a lot of time and money transitioning your network to
Digital so this seems a bit silly, and maybe it would even be simpler
for you (the phone company) to provide customers with a serial port as
their telco interface instead of a voice pair.

Then, you can bill them for a full channel and you only have to carry
2400 baud or whatever, which (a) probably they won't be saturating
even that anyway and (b) you can multiplex it and a bunch of other
data into a 64k timeslot. It's free money!

So that's what X.25 et alia are: a series of protocols and interface
specifications, such that (assuming access to a conforming network)
you can "dial" from any one serial port to another by typing in the
number of the remote port. Plus all the multi-carrier network interop
and billing stuff that you would expect from a telco.

None of these standards specify what the "internal" architecture of a
commercial network should look like... that's because X.25 started as
a formalization/generalization of the interface already provided by
TYMNET, who were the first but definitely not the only provider in the
space, and American telcos in that era preferred to specify the
customer interface while keeping the switching and transmission as
secret-sauce.

You'll see a lot of references to PADs, this is a fairly simple device
that has a standard async serial port (rs232) on one side and connects
to an X.25 network on the other side. The async port speaks a
protocol called X.3. It's nominally human-accessible but actually
fairly unpleasant to use; I find it even less fun than Hayes AT
commands. Cisco routers that speak X.25 have an X.3 PAD built in.

You can try to read X.3, X.25, X.28, X.29, etc, at this url


n.b.: the way they write is weird, and can be pretty tough to
understand until you cultivate the necessary brain-worms.
whether you do so or not is up to you ...

TELEBAHN per se doesn't really provide anything other than a
number-to-IP mapping system and a few common specifications to ease
interoperation. As such anything that speaks XOT can connect to it,
and (almost*) anything that speaks X.25 can be downstream from that in
your network. Good luck finding gear!

* I assume there's some combination of window size and acknowledgement
settings that would make coexistence difficult, but there aren't too
many knobs to twiddle in the core protocol so maybe not?

Every Cisco router since the 1990s should be able to speak XOT and
X.25 enough to do TELEBAHN; they don't remove stuff. But also they
don't fix it unless someone pays - like, IOS XOT doesn't do IPv6 and
probably never will.

Further hardware is not required but if you find some, that's super
cool and I encourage you to figure out how to plug it in :) The
cables are weird but not too expensive.

All mine is packed away in storage at the moment. I have an 8-port
PAD that works almost acceptably .. it requires manual reconfiguration
on every powerup to layer2 link-up with anything, for unclear reasons.
I think all X.25 gear is probably buggy. I also have a 16-port
"switch" (?) that has not meaningfully responded to any stimulus that
I've given it on the config async port, but it does seem to exchange
layer2 packets on the "uplink" port. But only NAKs. Doesn't like me.

This is the sum total of my ebay watched searches for a few years.
X.25 stuff is pretty thin on the ground, most electronics recyclers
know that there's no money in it.

--
?strid smith (she/her)
=<[ c y b e r ]>=
antique telephone collectors association member #4870