Xref: utzoo comp.protocols.misc:279 comp.dcom.lans:1421 comp.protocols.tcp-ip:3682
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!sluggo!melohn
From: melohn%sluggo@Sun.COM (Bill Melohn)
Newsgroups: comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Linking LAN's via Public X.25
Message-ID: <54821@sun.uucp>
Date: 28 May 88 22:17:55 GMT
References: <13652@comp.vuw.ac.nz>
Sender: news@sun.uucp
Reply-To: melohn@sun.UUCP (Bill Melohn)
Organization: Sun Microsystems, Mountain View
Lines: 45

In article <13652@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>From what I can tell SunLink X.25 does allow carrying IP packets from one lan
>to another via an x.25 virtual circuit.  What I would like to know is how
>transparent this is.  Does one host on the local ip lan (not necessarily the
>Sun running SunLink x.25) just ask to send an ip packet to a node on the
>remote lan, causing SunLink X.25 to open a VC to transmit the packet?

The X.25 virtual circuit is treated exactly the same as a dedicated
serial line connecting two IP hosts together. Routing information
about networks on either side of the link is passed across the link
via the standard Unix RIP. In the resulting internet, any host can
access any other host using whatever IP based services are desired
(note, protocols like NFS require some mount parameter tweaking in
order to not timeout over slower, long haul links).

>Assuming this is the way it works, does SunLink multiplex datagrams from
>several tcp or udp sources over the one VC, and if so, at what point does it
>close the VC?  Are the local and remote lans on different class C ip networks
>(I guess they must be to allow packets to be routed to the host with
>the x.25)?  How are the ip addresses mapped into x.121 addresses?
>Finally from an economic point of view how reasonable is it to send ip
>over x.25 bearing in mind the relatively large tcp + ip headers,
>particularly when you are paying for both connect time and number of
>segments sent (a segment is 64 octets, and NZ telcoms charge for
>unfilled segments as one full one).

As explained above, each VC is treated like a virtual point to point
wire connecting each pair of hosts via the public data network. Each
VC used for IP has a network interface associated with it, with an IP
address of its own. An X.25 circuit manager user process is provided,
which establishes the X.25 virtual circuits to each of the remote
hosts based on a config file, and binds the VCs to the IP network
interfaces used by the kernel routing code. The manager attempts to
keep the VCs connected all the time. This can be expensive if you are
paying for connect time, but since processes like the routing daemon
tend to wake up and send information on a regular basis, the IP
circuits tend to stay active even when they aren't actively being used
for user data transfer.

We are investigating ways to make it practical to create X.25 virtual
circuits only when needed for end-user data transfer, while still
maintaining full routing capabilities and connectivity information.
Our implementation of X.25 Standard services does this on the DDN,
where the X.121 to IP address mapping is fixed, and where routing can
be done by use of a default route to, and redirects from, a core
gateway.