On the usefulness of the COSINE S1 Service for NORDUnet ------------------------------------------------------- Olav.Kvittem@delab.sintef.no, 1991-12-04 0) Foreword ----------- This report will try to assess the usefulness of the COSINE S1 Service (IXI production follow-up ) as seen from NORDUnet. It is not possible with the resources used to be fully covering every aspect of the issue. I have tried to make my points with reference to the practical experience of networking in the European community. The evaluation of IXI pilot-service as seen from NORDUnet is done in another report [1]. There is also a IXI project report by the COSINE project team [5]. 1) Introduction & NORDUnet status --------------------------------- The main NORDUnet services are according to [6] TCP/IP DECnet EARN X.25 nodes 30578 3228 69 62 TCP/IP and DECnet nodes are located in Local Area Networks(LANs) in each institution and they use a router to connect to the WAN's. EARN nodes are typically mainframes, while X.25 nodes are typically mail and terminal gateways, directory servers, routers, PADs and some mainframes. Products for running X.25-based services in a LAN is becoming available on various platforms, but they are not likely to be deployed in the NORDUnet community because of existing routers and application base. The Nordic Government OSI-profiles also states that ISO CLNS and not ISO CONS (X.25) should be the preferred LAN technology. TCP/IP generates probably more than 95% of the traffic volume within NORDUnet, while from NORDUnet to Europe it is about 90% and the rest is DECnet 8% and 2% X.400 and X.25. Earn uses TCP/IP for transport. The main usage of IXI from NORDUnet at present is for DECnet to CERN and ESA, the ISO CLNS pilot service and X.400 in that order in traffic volume. Both DECnet and CLNS will be moved to the upcoming E-bone-92 infrastructure. The average utilization of the IXI link was in September 1991 about 7% in average and 58.5% maximum over an hour. 2) IXI evaluation ----------------- The IXI network is at present working quite well. The availability is comparable to that of the RIPE-coordinated network to CERN. The prime limitation factor for availability seems to be line quality. The operation center is doing a good job in discovering most of the problems themselves and then reports to NORDUnet. The performance of the network as such is good, but NORDUnet DECnet has had problems in getting satisfactory end-to-end throughput and availability. The availability is now improved, but the need for bandwidth is greater than the present 64 Kbps on IXI. This is particularly a problem for physicists retrieving large files from CERN. 3) CONS(X.25) problems. ----------------------- There are some problems in making X.25 an end-to-end network service. First, the PTT's does not give away official X.121 addresses to private networks, so most of the academic network has invented their own incompatible addresses. This has lead to a situation where one has had to make a new set of addresses for IXI parallel to the existing local ones. To spread knowledge of these addresses there is currently only manual ways. It is however expected that the full ISO CONS service will be using NSAP-addresses for routing and thereby improve this situation. RARE WG4 is preparing a pilot over IXI for this, whereas at least JANET has had this in production some time using their own upper layers (Colored books). Secondly there are no routing protocols defined that can be used to spread connectivity- and network status information, so one has to maintain manual routing tables in each switch. This is only handlable by restrictive engineering of the networks, which of course can be done. In contrast the standardization for routing protocols for the CLNS service is progressing quite well. 4) Management tools? -------------------- The different X.25-switch manufacturers probably all deliver good management systems, but they are all proprietary, and its very difficult to get a picture of whats going on in another sub-network like IXI. For IXI they aproached the problem by defining echo-points in the switches that can be polled to check reachability. A simple program that did this was made and distributed. NIKHEF has also made a public domain X-based tool that makes a picture of IXI that way. NORDunet/UNINETT has programmed its own management system for their Satelcom switches based on earlier code from NIKHEF. 5) Scalability of X.25 to higher speeds and distributed applications? --------------------------------------------------------------------- At present many X.25 switch vendors are capable of running access links at 2 Megabits per second. The current level of extra-Nordic traffic is 256 Kilobits per second, so X.25-technology would apparently give sufficient capacity for a couple years to come (Estimate NORDUnet double traffic every year). When the speed exceeds 2 megabits and the distance is long, the current X.25 protocol stack needs some adjustments to be able to deliver high enough throughput and efficiency. RARE WG4 has endorsed a report on this subject [2]. It is not known if any activity is done to progress this issue in the standard bodies. In contrast the current stacks for TCP/IP and ISO CLNS are expected to work reasonably up to 100 Mbps, and there are already several vendors delivering reasonably priced routers for ISO CLNS and TCP/IP that supports FDDI LAN (100Mbps) and 34/45 Mbps links. Gigabit end-to-end speeds will probably require reengineering of all the protocols as well as end systems. However there are already pilot networks for 34-140 Mbps operative in Europe. Those will be supporting high bandwidth services, that I feel is not likely to be supported by X.25-switch vendors. For these services, like a multi-party video conference, it would be efficient to be able to send data once to reach all partners (multicast). X.25 does not have mechanisms for handling this at the network level. In contrast much research is being done to support such services on TCP/IP. 6) IXI pilot management organizational considerations ----------------------------------------------------- The IXI operator and also the COSINE Project Team together with IXI-ADMIN does not have much experience in running international TCP/IP and DECnet-services. During the pilot phase little effort has been made to experiment and evaluate usage of IXI for these services. This means that in addition to the basic X.25-service one will have to arrange separate teams of qualified people from the RIPE and HEPnet environments to operate these services. In contrast the E-bone NCC can perform the task of running the backbone and coordinating the offered services (IP and CLNS) with one team of people with appropriate background. RIPE has through NIKHEF provided an IP-service over IXI for some networks. And to NIKHEF 99.9 % of the IXI-traffic is IP traffic and more bandwidth is needed. Most IP traffic is to JANET, IRIS, HEANET and RCCN. Less traffic is to ARIADNE, YUNAC and DFN. NORDUnet IP-traffic goes via a 192 Kbps line to CWI/NIKHEF in Amsterdam. 7) Running IP over X.25. ------------------------ When attaching n IP-routers to each other it creates n-1 circuits on each access link and n(n-1)/2 circuits to watch in the network (for IXI n would initially be over 20 and increasing). This might be troublesome to scale because introducing a new access-point would incur a configuration update on the 20 acess-points that ought to be done fairly synchronously. If given central control over the configuration of each access router however this task should be easy to automate. This problem is in common with any service using any underlying packet/circuit-switched backbone like frame-relay or ATM (see [4] for details). It should be noted that there is work going on to define mechanisms for TCP/IP that would make such configuration scalable [7]. This is contrary to the present RIPE standpoint, which states that routers at central hubs should be used in order to manage the scaling problem[3]. This would cause traffic to leave and REENTER the X.25-network in order to reach the destination, which is very inefficient. There must also be central routers that are necessary for extra-IXI communications, like coordination of links to other continents, other service operators and so-on. 8) Cost considerations of the X.25 technology? ---------------------------------------------- Given the matureness of X.25-products it is fair to assume that installing and running such a network will not exceed the cost of that of a comparable frame-relay or ATM-network. Contrasted to the setup of and concatenation of networks based on multiprotocol routers, the costs are higher for managing a X.25-based network, both for the backbone network and the connecting networks. Concrete examples here can be found from UNINETT and NORDUnet. 9) Coping without IXI ? ----------------------- When the NORDUnet DECnet traffic is moved away from IXI, there is little traffic volume left to support the cost of the access-point (One could take the view that the money is spent on E-bone instead, but that is an operational, value-for-money based decision by the NORDUnet board). The X.400-traffic can be well served by being moved partly to public X.25 and partly to TCP/IP. The PAD service could also be well served by public X.25 or even replaced by telnet/TCP/IP given the increasing IP-connectivity and in Europe. Generally it is the larger institutions that have a public X.25 subscription. For the rest, one possibility would be to support gateways in each country, but then one would have cost reclaim problems, and also by that create an obstacle to usage. A X.25-service will probably be a part of the Ebone-93 network specification. If those network both were setup, one could imagine that interworking would take place and that a subscription to only one of the would be necessary from NORDUnet. The knowledge of accessible databases in IXI has been low in UNINETT. However lately the interest in using IXI from UNINETT for database access to England and Germany has increased. One reason might be that RUNIT has provided a Telnet/PAD gateway for use by UNINETT. 10) Conclusions --------------- The primary need for NORDUnet is TCP/IP and DECnet services. In the future a ISO CLNS base is expected to develop in the academic community through government procurement rules. The need for bandwidth from NORDUnet to Europe is at least 256 Kbps in 1992. The IXI pilot as such has been successful and provides a reasonably good X.25 network service, that is extensible from 64Kbps to a 2 Mbps service. This could provide sufficient capacity for the NORDUnet community for a few years provided that we keep our own US-link. Embedded protocols like TCP/IP and DECnet perform fairly well point to point through the network. The full interconnection of every accesspoints routers is doable at least for TCP/IP without major costs with central adminstrative control over attaching routers. Given the NORDunet service profile with 90% TCP/IP, such a backbone would however be less optimal than a multiprotocol backbone like Ebone-92, which also is expected to have lower management costs and better visibility to status for the attaching networks because of use of standard tools (SNMP). This report show that the present volume and characteristics of X.25-based services is so low that it can not justify the cost of an IXI accesspoint by virtue of cost saving or performance need. The services can well served by alternative means. Some users might however be cut off because of cost and lack of alternatives. One possibility is to share gateways to IXI with via Ebone[8]. 11) References -------------- [1] Olav Kvittem, SINTEF, 1991-05-22 "IXI Pilot Service technical status report as seen from NORDUnet", [2] Bernard Sales, Universite Libre de Bruxelles, "A profile for wide area X.25 operating at 2 Mbps" [3] Tony Bates and Marten Terpstra, 1991-05-31, "IP networking on IXI" [4] RARE Secretariat, 1991-05-02 "EUROPEAN ENGINEERING PLANNING GROUP (EEPG) - Final report" [5] COSINE Project Team, autumn 91, "Evaluation Report on the Pilot IXI Service" [6] Peter Villemoes, "An Update on Nordic Networking for R&D" [7] IETF - IP over Large Public Date Networks (IPLPDN) group [8] EBONE-92 a consortium of European Network Service provides to provide a multiprotocol backbone for 1992.