duncan@comp.vuw.ac.nz (Duncan McEwan) (05/26/88)
I need to find out what products are available for linking two geographically remote LAN's via a public x.25 network. I have advertising glossies for Sun's SunLink X.25 product which seems to provide the desired facilities, but which leaves some questions unanswered. 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? 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). Enough about SunLink x.25 specifically! Are there any other products (bridges, routers, other computer vendors x.25 packages) that offer this type of functionality. In particular, do HP offer anything similar? Can one companies product interoperate with anothers (for example, I believe that the Multinet IP/TCP package for VMS does/will offer some facility for tcp/ip over x.25 - is it reasonable to expect a Sun running SunLink x.25 to be able to talk IP with it). I think that is enough questions for one article! Any answers to some or all of the above will be appreciated. Answer by email and if there is any demand I will summarise. --- Duncan Domain: duncan@comp.vuw.ac.nz Path: ...!uunet!vuwcomp!duncan
melohn%sluggo@Sun.COM (Bill Melohn) (05/29/88)
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.
karn@thumper.bellcore.com (Phil R. Karn) (06/01/88)
While we have not used Sun's Sunlink-X25 product, we used the CSNET X25NET software on a VAX and a GTE Telenet X.25 link for some time. Then we upgraded our Internet membership from Steerage Class to First Class by junking X25 and getting a direct HDH connection to an ARPANET PSN. So I think I can make a few general comments from our experiences in running IP over X.25. Yes, it works. But the fact that it does reflects more on the flexibility and robustness of TCP/IP than on any inherent suitability of X.25 for serious computer networking (as opposed to remote slow speed terminal multiplexing, which is what X.25 was designed for and actually does reasonably well). An IP-on-X.25 gateway is a complex beast, mainly because of X.25's many gratuitous complexities. The most obvious is the need to manage connections. Interfaces usually support only a limited number of them. Worse, carriers may decide to charge you for keeping them open even if they're idle. (Fortunately, Telenet doesn't do this. I guess they're satisfied with the $1500 you pay them every month just to have a 9600 bps host access line to their network. This is exclusive of usage sensitive packet charges, more about them later). The usual strategy here is to keep your list of open connections sorted in order of time of last use, so you can close the least recently used connection should you need to open another one. Timers can also be used to close idle connections. Other problems include inherent performance bottlenecks imposed by the carrier's own interpretation of the X.25 protocol. For example, Telenet acts as though the "D-bit" (delivery confirmation bit) in each packet is set. This means that their packet-layer acknowledgements are on an end-to-end basis. Unfortunately, the packet size is limited to 128 bytes, and the packet layer window is only 2 packets. This means you can't send more than 256 bytes on any single virtual circuit per network round trip time. This can severely limit throughput; in our experience we could seldom use more than 1/4 of the bandwidth of our 9600 bps access line with any one virtual circuit. Since almost all of our IP traffic was to one destination (relay.cs.net) this would have been a serious performance bottleneck except for a feature in the gateway code that opened multiple, parallel X.25 virtual circuits to the same destination and dealt outgoing packets to them in round-robin fashion. Tannenbaum calls this "downward multiplexing"; I call it a "kludge". (By the way, this feature comes in very handy when implementing TCP. There's no other Internet path that gives you such a chance to test your packet resequencing code!). But wait, there's more! Not only is an X.25 gateway inordinately complex, but running it can be very expensive. Telenet, as do all X.25 carriers that I'm aware of, charges for each packet sent. There is a nighttime discount, but the figures are still quite high. If you examine the tariffs, you will find that shipping large files over X.25 can be *very* expensive. In fact, it is considerably cheaper to use one of the new 9600 bps dialup modems -- as low as HALF the cost of X.25. Just to give you an idea, the last month before we dumped it in favor of our ARPANET connection, our X.25 path to the Internet through Telenet and relay.cs.net cost us $10,000. And we did NOT run routing packets over the path. Even a leased line to Cambridge would have been considerably cheaper. Based on my own experiences with IP over X.25, one must wonder what they were smoking down at the Pentagon when the DoD decided to specify X.25 as the standard interface to the DDN. Phil
jh@tut.fi (Juha Hein{nen) (06/01/88)
SunLink X.25 indeed allows connecting two IP networks over X.25 but it requires a PVC and cannot dynamically open and close the connection. You may want to check the Cisco router product that also has the later capability. -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
symchych@SKL-CRC.ARPA (Tim Symchych) (06/03/88)
Perhaps another view of IP over X.25 might help. While the original question was asked about Sun X.25, there are a number of networks within the ARPA/Internet that use IP over X.25. The experience that Phil Karn described at Bellcore does not describe our experience in establishing the DRENET and XDRENET here in Canada. There is no doubt in my mind that some implementations of packet switching using CCITT X.25 are poor. We did some testing of various networks about two years ago including ARPANET (1822 Links), Telenet in the USA, SATNET, and the public packet switching networks in the UK and Canada (Datapac). Packets were timed in some great loops, and by network segment to allow us to determine level of service over the various segments. Generally, the packets through Telenet and SATNET suffered the most delay. The X.75 gateways didn't seem to work all that well then either. I'm not sure that X.25 was designed for slow speed terminal multiplexing. NO packet switching network works well at that task. In our own case, use of TCP/IP over X.25 has been shown effective from both points of view: cost and throughput. In Canada, we have at least one first rate X.25 packet switching network. Through eight years of using Datapac for applications, including five years of TCP/IP over X.25, we have found no problems in service or reliability. By the way, I don't work for any of the Bell franchises, nor do I own any of their stock. I just pay the phone bill. We have several hosts and gateways that connect LANs using X.25. I don't agree that X.25 is overly complex, or managing virtual circuits is a big problem. Our gateways and hosts usually do the work in software on board level products. We did some preliminary testing with SunLink using our hosts and one of their software implementations. Everything worked but the Sun stuff has some minor rough edges. For instance, the Sun would only allow one virtual circuit between two hosts even thought our side would allow one per user process. Imagine sharing your TELNET session with an FTP with each IP packet waiting it turn in in the X.25 queue. TELNET over X.25 is bad, but Sun made it worse. I hope they worked on that "kludge". Our tariff structure for communication services is almost the reverse to that in the U.S. Our leased lines cost us dearly, but out packet switching cost much less. If you look at our telco infrastructure, its easy to see why. Our population is spread across the country, and leased lines are nearly always new services. In the way of cost and performance, we have this kind of experience: Rental of 9600 bps X.25 modem with 20 virtual circuits is $390.00 U.S. per month. Traffic charges range from $35.00 to $300.00 U.S. per month per X.25 interface depending on usage and distance. The later is for about 50MB per month to a site 1500 miles away using the Datapac cost formula. On most of our X.25 legs, we get between 50 and 75 per cent of the of the 9600 bps. But this does depend a great deal on the HOST implementation of TCP/IP. In contrast, our 9600 bps HDH line gives us about 80 to 85 per cent of the line speed. Our 56 kbps line gives about 20 to 30 percent of the line speed, but we are not sure that we have hosts at either end to drive it faster. To send a 10 MB file across the country, it would cost about $75.00 U.S.. Thats about the same as it would cost to run the data on to a mag new tape and send it FEDEX. Some of our sites will be running 19.2 bps X.25 service which will double the monthly modem cost, and increase throughput but will be limited by the TCP/IP on the hosts. We expect that these 19.2 links will get us about 12000 bps or just about what we get out of our very expensive 56k bps line between our core gateway and the U. of Rochester. When our core gateway was replaced in Feb/88 with a Butterfly, the measured throughput went up slightly even though the HDH interface was replaced with an X.25 interface. I've tried to figure that one out. I will be the first to agree that our needs and network structure is different than Bellcore. However, I view X.25 packet switches as a low cost backbone that will allow us to operate until we have sufficient traffic levels to support leased lines. If there is a target needing a thumper, it sounds like the implementation of X.25 in Telenet will do. When it comes to bad implementations of TCP/IP, the cry is "burn them at the stake". There are good and bad X.25 implementations, and I recommend burning where it is due.
jon@CS.UCL.AC.UK (Jon Crowcroft) (06/03/88)
>Perhaps another view of IP over X.25 might help. While the original >question was asked about Sun X.25, there are a number of networks within the >ARPA/Internet that use IP over X.25. another e.g. of IP over X.25 is the UK Academic link to the US, which has run over IPSS for some years, as leased lines were rather expensive for the amount of traffic we used to have, and since the SATNET was mainly reserved for research use. A lot of interesting work was done on accounting and access control so that we could forward bills for the IPSS usage to the UK source of any IP packets on a sensible basis. Useful reading... %A R. H. Cole %T User Experience and Evaluation of International X.25 Services %J Proc. Telecoms Today Conf. %I Online %C London %D March 1984 %P 107-118 %K X.25 performance jon
symchych@SKL-CRC.ARPA (Tim Symchych) (06/04/88)
Dan: Yes, there are still versions of IP around in hosts that do not perform well. Regardless of some of the fine work that has been done in end-to-end performance, we still use what comes off the shelf, and if the vendors don't put it out in the product, then we don't have it. Most of our sites have no interest in "patch and run" systems for their users. Many people on this mailing list have covered this problem, including the problems of mixing speeds on segments of the path that traverse ethernet, leased lines and non-IP packet switched nets. Except for ethernet LANS, all our links between hosts use combinations of different link types. I guess that in our case, X.25 is the least of our problems. Something I forgot to mention is that in our PDN connections at 9600, we use 256 byte packets with a window size of up to 7 packets. I also received some hints on the 56 kbps X.25 line to our Butterfly from Dave Capshaw at Lockheed. Seems that some tuning may be possible between the PSN and the Butterfly. regards tim
MRC@PANDA.PANDA.COM.UUCP (06/05/88)
Dan -
I'm responsible for one of the TCP/IP implementations used on a
9600 baud link in Canada. The system is a DEC-2065 running a TOPS-20
with a heavily modified TCP. It has two IP interfaces; a NIA20 to the
local Ethernet and an AN20 to a C/30 PSN using 1822.
This TCP lacks RFNM counting which is a serious deficiency, but
in the case of this link it doesn't really matter all that much since
(at least the last I read) there is only one place for the 1822-grams
to go to. If you're RFNM blocked to the friendly not-so-local gateway,
you can't do anything anyway.
What makes the burden worse, this machine is the only path between
the local Ethernet (which talks TCP/IP and DECnet) and the rest of the
world. It has a rudimentary EGP-speaker that babbles updates to Friend
Gateway.
I've seen no indication of a bottleneck at the DEC-20. Instead,
it seems to be more that the DEC-20 (and the Symbolics Lisp machines
behind it on the Ethernet) are communicating almost exclusively with
the Internet in the US, across two gateways over a long long wire.
There isn't all that much traffic to begin with, so any latency in a
connection can easily stop the line...because there is no other traffic!
-- Mark --
-------LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) (06/05/88)
>Perhaps another view of IP over X.25 might help. While the original >question was asked about Sun X.25, there are a number of networks within the >ARPA/Internet that use IP over X.25. Yet another view. The RSRE Internet Lab connects to two other European Internet sites (one in Holland and one in Germany) and others internal to the UK running IP over X.25. Quality of service is good and at current traffic levels is much cheaper than international/national leased circuits. The software has been developed to pay attention to the fact that real money is being spent e.g. virtual circuits close if IP traffic stops, and of course accounting and access control are well developed. If national X.25 provision by US carriers is seen as less than adequate, by US users, maybe its because they (the carriers) do not see it as a viable commercial market to make a big investment in given the existing 'free' networks like Arpanet, Milnet, NSFnet etc. YES I DO KNOW that they are not really free - that Government, Academic institutions and companies make payments. But in many cases the users at the keyboard are unaware and uncaring of the costs (judged by many of the remarks in this forum some months ago). John
roode@orc.olivetti.COM (David Roode) (06/05/88)
There's no question that X.25 packet switching is a service built on top of point-to-point data circuit (leased line) capability. The tariffs in the U.S treat this as a 'value added' service and prohibit the basic operating companies from competing in the national market. The Public Data Networks offering packet services have to pay the same leased line rates as an end-user, both for backbone circuits and for ties between their switch locations and customer premises. At the same time, the charges for leased line service are obviously much cheaper in the U.S. than they are elsewhere. (It calls for a judgement, but it seems likely that much in excess of costs is recovered in the charges for leased line service in Europe.) As a result, it may be illogical to 'blame' the U.S. Public Data Nets for their charges. European PTT's may subsidize their X.25 offerings. U.S. PDN's see reduced usage volume due to reasonable competition from leased lines. The main service a PDN provides is the sharing of data circuits. So, in the U.S. a smaller fraction of uses see an economic incentive to share costs by making use of a PDN. (It takes a smaller volume of usage to cost justify switching to a leased line in the U.S.) The operating efficiency of the U.S. PDN's may be the same or even higher than the European PTT's in providing PDN service. It appears the hierarchy in terms of increasing cost for a 2400 baud data flow is something like: leased lines at U.S. typical rates Public Data nets at European rates Public Data nets at U.S. rates leased lines at European rates For 300 baud data flow, it is something like: Public Data nets at European rates Public Data nets at U.S. rates leased lines at U.S. typical rates leased lines at European rates For 9600 baud data flow, sequence might be: -or- leased lines/ U.S. rates leased lines/ U.S. rates Public Data nets/ U.S. rates Public Data nets/ U.S. rates Public Data nets/ Europe rates leased lines/Europe rates leased lines/Europe rates Public Data nets/ Europe rates